Key Points

1. well architected framework to quickly delivery DLT solutions as services
2. pre-built interfaces to multiple public and permissioned blockchain networks: Ethereum, Besu, Fabric, Corda, Quorum .. more
3. interfaces allow adding new implementation services
4. API contracts defined by OpenAPI model
5. DLT adapters invoke the DLT smart contracts as atomic async transactions
6. Integrates both on-chain, off-chain data, processes
7. Supports multiple signer and multiple network integration
8. Compare to other models:  DAML, ChainLink, Cacti project
9. Consider extensions for DLT Object CRUDS MDG using A-SDP life cycle and interfaces for workflow, rules, other DSLs
10. Consider open-source governance for all extensions in community for faster approvals and adoption ( see TOIP model )

References

Key Concepts

https://www.hyperledger.org/blog/2022/04/13/introducing-hyperledger-firefly-1-0-the-supernode-for-enterprise-web3-applications

The Firefly Commercial Slide

Firefly Features and Services

Hyperledger_FireFly-Project-Webinar_Series-.pdf

Hyperledger_FireFly-Project-Webinar_Series-.pdf file

Hyperledger_FireFly-Project-Webinar_Series-.pdf link

_firefly-supernode-p2-software-tools.jpg

Keys

SSO but no OICD support - depends on Kerberos SSO services

what is billable vs open-source?

_firefly-web-dev-life-cycle1.jpg

write contract and publish to firefly

_firefly-runtime-api-services-v1.jpg

only the Kaleido billable runtime or ?

_firefly-data-flows-p1.jpg

integration concepts for other data, frameworks?

entry / exit points?

smart file store events / notifications?  << uses the persistent event bus

are all state changes recorded in sequence for on-chain and off-chain stores to support transaction replay when needed?

how is private data recovered for nodes?

how is the private data mapping defined for a use case?

_firefly-token-support-v1.jpg

JEPL maps for process flows

_firefly-event-orchestration-v1.jpg

Firefly Core OS Architecture v1.2

Firefly Enterprise Architecture v1.2

Tutorial - Open source blockchain development: Get started with Hyperledger FireFly - Nicko Guyer

https://opensource.com/article/22/9/blockchain-hyperledger-firefly?sc_cid=7016000000127ECAAY%20by%20@US&hss_channel=lcp-10851358&utm_content=221669010&utm_medium=social&utm_source=linkedin

Firefly v1.1 Overview Announcement

https://www.hyperledger.org/blog/2022/09/12/hyperledger-firefly-v1-1-is-now-available

https://github.com/hyperledger/firefly

https://hyperledger.github.io/firefly/

https://discord.com/channels/905194001349627914/928377875827154984

the new release of Hyperledger FireFly exciting. Developments to the stack make it radically simple for developers to launch production-ready apps on both public and private chains and manage multiple applications from a single console with multi-tenant support, plugin flexibility, and pluggable security. 

Introducing Web3 Gateway Mode

Hyperledger FireFly can now operate in two modes. The first is familiar to current users of the stack. Consortium Mode is used to build consortiums or multi-party business networks where data needs to be agreed to and shared among the group. Use cases for Consortium Mode have included healthcare and insurance consortiums, supply chain participants, financial networks, and other examples where companies come together to streamline how they do business. 

This release introduces the new Web3 Gateway Mode. Gateway Mode is used when the main goal of the Supernode is to connect to a public blockchain. Where previously developers could use a public tether to access popular public chains, this new mode acts as a doorway into the full world of web3 with support for popular public chains including Ethereum, Polygon, Avalanche, Optimism, BNB Chain, Arbitrum, Moonbeam, Fantom and more. 

The worlds of public and private blockchain are merging. Enterprises are eager to tap into the reach, security, and decentralization of public chains. At the same time, public chain players are looking to optimize throughput, scalability, and gas fees in ways that have long been familiar to enterprise networks. This release of Hyperledger FireFly offers a stack to build for both worlds. 

Public Blockchain Support

Along with the ability to connect across public chains, Hyperledger FireFly 1.1 has new tools and support to simplify public use cases for the enterprise. 

• FireFly Transaction Manager, an all new EVM Connector, handles the complex concerns of public chains, including gas estimation, resubmission policies, and more.
• FireFly Signer can be used for transaction signing in networks where it is necessary to separate private keys from the blockchain node.
• Enhanced Gateway Support makes it easy to keep private data private, while interacting with public chains.

Hyperledger FireFly 1.1 allows developers to access both public and private chains simultaneously, while building in guardrails specific to the enterprise space, ensuring new applications meet both user and compliance requirements.

Multi-tenant Support for Consortiums

Hyperledger FireFly 1.1 adds namespace isolation for segregating data and operations. Inside the Supernode, each namespace is an isolated environment within a FireFly runtime. This allows independent configuration of plugin and infrastructure components, API security, identity broadcasting, on-chain data indexing, and management of how data should be shared. 

Namespaces work in both modes. Consortium Namespaces can be used when multiple parties need to share on- and off-chain data and agree upon the ordering and authenticity of that data. While Web3 Gateway Namespaces are available when interacting directly with a blockchain, without assuming that the interaction needs to conform to FireFly’s multi-party system model.

A single FireFly node can run multiple namespaces in either mode at the same time. This lets developers build flows that coordinate between public chains and private consortiums. The diagram below illustrates the visibility and control available to an organization as they run multiple applications from a single console, each segregated to meet security requirements. 

Multiple Instances of Plugins

With the new release, a single FireFly node can now use several instances of each type of plugin that is available. As we illustrated above, we’re connecting to multiple blockchains simultaneously, often for different use cases or goals. The ability to run different plugins in each namespace means a developer has greater agility to coordinate flows for each chain or consortium. 

Pluggable API Security

The flexibility to connect to multiple applications and multiple chains is only valuable in the enterprise space if it can be matched with the appropriate security, both for the integrity of the network and for compliance standards. 

With Hyperledger FireFly 1.1, API Security can be enabled at several levels. This includes on any service or on a specific namespace. 

With two different modes of operation, tenant isolation, flexibility of plugins, and tailored security at any level, the ability of a developer to deploy and manage applications with the right functionality and permissioned access is greatly increased. 

The Next-gen Platform 

Hyperledger FireFly v1.0 was a welcomed addition to the blockchain developer’s toolkit. It brought to blockchain the convenience of a rich middleware stack common in the Web 2.0 space. 

With the new release, Hyperledger FireFly is positioning enterprises to harness the benefits of both public and private blockchain technologies. It gives developers the ability to quickly launch multiple applications, tailor each to the desired business logic and security requirements—all while providing a gateway into the wider world of web3. 

Hyperledger FireFly 1.1 is another step toward bringing the Enterprise closer to realizing the full potential of web3—both with permissioned chains and connections to public ecosystems. If that’s something you’re interested in, we invite you to come be part of our community. You can learn more in the FireFly docs and download the CLI on the FireFly Github. If you have any questions, find us in the FireFly channel on the Hyperledger Discord.

Nicko Guyer's Hyperledger Public Sector on Firefly v1.1

FireFly Public Sector SIG.pdf

Firefly v1.1 Overview - youtube - Nicko Guyer - 2022

Nicko Guyer's Hyperledger Mtg on Firefly v1.1 on Deployments

At Hyperledger Global Forum, the Hyperledger FireFly community was pleased to announce the release of version 1.1. This release makes it possible for Hyperledger FireFly users to deploy multiple blockchain applications connecting to multiple chains, including leading public blockchains like Ethereum, Polygon, Avalanche, Optimism, BNB Chain, Arbitrum, Moonbeam, Fantom and more.

In this webinar, Nicko Guyer, Hyperledger FireFly maintainer and Community Lead, will take you through the new functionality in 1.1, including:

• Web3 Gateway Mode: Use Web3 Gateway Mode to connect to public blockchains including Ethereum, Polygon, Avalanche, Optimism, BNB Chain, Arbitrum, Moonbeam, and Fantom.
• Public Blockchain Support: Leverage new tools to simplify public use cases, including FireFly Transaction Manager, FireFly Signer, and Enhanced Gateway Support.
• Consortium Mode: Use Consortium Mode to build multi-party business networks where data needs to be agreed to and shared among the group.
• Multi-tenant Support: Use new namespace isolation to segregate and configure API security, identity broadcasting, on-chain data indexing, and data sharing.
• Multiple Instances of Plugins: Use several instances of each type of plugin in a single FireFly node.
• Pluggable API Security: Enable API Security at several levels and on any service or namespace.

Firefly Concepts on Atomic Token Swaps using HTLC model

https://docs.kaleido.io/kaleido-services/token-swaps/

https://docs.kaleido.io/kaleido-services/token-swaps/usage/

https://docs.kaleido.io/kaleido-services/token-swaps/architecture/

https://docs.kaleido.io/kaleido-services/token-swaps/htlc/

https://github.com/kaleido-io/token-sample-htlc

Hashed Timelock Contracts (HTLCs) for Ethereum:

• HashedTimelock.sol - HTLC for native ETH token
• HashedTimelockERC20.sol - HTLC for ERC20 tokens
• HashedTimelockERC721.sol - HTLC for ERC721 tokens

Example of atomic token swap cross chain

https://github.com/chatch/xcat

•  Protocol API Scenario 1 (Stellar side initiated)
• Protocol API Scenario 2 (Ethereum side initiated)
• Built in communication channel (Telehash Links?)

Potential Value Opportunities

Kaleido Enables Swift’s New CBDC Sandbox with Broad Industry Participation

https://www.kaleido.io/blockchain-blog/kaleido-and-swift-launch-cbdc-sandbox

Kaleido is proud to announce the completion of a new CBDC sandbox for Swift, the global provider of secure financial messaging services. Eighteen central banks and commercial banks are actively participating in testing to accelerate a path to full deployment.  

The sandbox demonstrates that CBDC-initiated cross-border payments can plug into Swift’s enhanced platform exactly as real-time gross settlement (RTGS) payments do. This is facilitated using Swift's newly designed CBDC connector gateway. The goal of the experiment is to assess the potential to use CBDCs in cross-border payments and get real-time feedback on potential strategies.

“Kaleido’s sandbox enabled us to deploy the technical infrastructure developed for our CBDC experiments in an open testing environment. As such, the sandbox is an important component in getting the feedback from our community that we need to develop further iterations of our CBDC solution,” said Nick Kerigan, Managing Director, Head of Innovation, Swift.

Kaleido has a "build your own CBDC" model to create sandbox test environments

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles