Building a CBDC bridge between Hyperledger Fabric and EVM-based blockchains using SATP

Keywords: blockchain interoperability; CBDC; cross-chain bridge; SATP; Hyperledger Fabric; Hyperledger Besu;

This blog post presents a summary of our work that is extensively described in an academic paper 👉Access here 👈.

In today’s financial infrastructure, Central Banks are responsible for issuing and managing money that is provided to the financial institutions based in the countries that are under their umbrella (European Central Bank for all of Europe, Bank of England for the UK, …).

Projects around Central Bank Digital Currencies (CBDC) — digital forms of money — have been emerging in the last few years around the globe, “105 countries, representing over 95 percent of global GDP, are exploring a CBDC” according to the Atlantic Council CBDC tracker.

There is a separation of concerns regarding the management of money and money-like instruments such as CBDCs, and the use of such instruments by the end users. However, they are not disjoint. Users that are in contact with retail businesses must have the ability to use financial instruments (even if indirectly), for example, to pay for the provided services.

We can, therefore, divide the problem into two domains: the one managed by Central Banks and Financial Institutions that have the core management of the CBDC; and retail businesses that leverage the financial services exposed by the latter, to which the end users will interact. Mapping these domains to different blockchain networks, the problem is translated to enabling interoperability between a permissioned consortia ledger managed by Central Banks/Financial Institutions, and retail businesses ledgers that offer services to the end users.

A cross-chain bridge is nothing more than a means to achieve interoperability across different blockchains. Typically, a bridge can take multiple forms, architectures, trust assumptions, etc. It ranges from centralized trusted systems such as centralized exchanges operated by a trusted third party (e.g. Binance), to completely decentralized solutions like light clients and relays where each blockchain maintains a simplified state of the other (e.g. BTC Relay). Naturally, there are different tradeoffs, usually between centralization, trust, and scalability.

There are some requirements for a successful bridging operation between a source chain and a target chain. This operation typically encompasses at least two steps:

1. Locking the asset in the source chain: making it unavailable for being traded; sometimes the assets are effectively deleted depending on the use case.
2. Minting/creating a representation of the same asset in the target chain: these assets are frequently called “wrapped” because they represent assets that exist in the source chain, they are not native.

This is also the concept of two-way-pegging, where the value of a token in a side chain is pegged to the token that is locked in the source chain. Some attacks have been done in cross-chain bridges where the funds locked (in escrow) are stolen, and therefore, the tokens in the side chain lose their peg (in other words, they become worthless) — check this paper for more information on cross-chain attacks.

At the beginning of 2020, Hardjono et al. proposed a new architecture for the blockchain interoperability problem. It would be based on Gateways as the ingress/egress of blockchains, running a Gateway-to-Gateway protocol — today we call it the Secure Asset Transfer Protocol (SATP) — the name changed recently from Open Digital Asset Protocol (ODAP).

A comparison with the time when the Internet was created, and the necessity of having border gateway routers (that act as gateways for smaller networks composing the Internet) motivated this architecture.

The Secure Asset Transfer Protocol intends to standardize a communication protocol between two gateways to transfer digital assets between parties in different networks. This protocol is a work in progress in the scope of the Internet Engineering Task Force (IETF).

It encompasses three phases:

1. Gateways agree on the parameters of the transfer, the Asset being transferred, the sender and recipient of the transfer, enforcement of legal/governance policies, etc.
2. The original asset in the source network is locked (to prevent double spending) and the proof is sent to the counterparty gateway.
3. The asset in the source chain is deleted, and the proof is sent to the counterparty gateway that issues a transaction in the target ledger to create a representation of the same asset.

SATP guarantees atomicity, consistency, integrity, durability, and termination. Additionally, the logs and proofs generated through the execution of the protocol can be accessed for future auditability procedures.

Hyperledger Cactus is a project under the Hyperledger umbrella that aims to solve the interoperability problem. Cactus encompasses two main components:

1. Business Logic Plugins (BLP): capture a certain use case business logic (e.g., there is a SATP BLP implemented that represents the logic each gateway must adhere to).
2. Ledger Connectors: expose an API so that one can interact with the underlying blockchains (e.g., the Fabric connector exposes an API so that any BLP can interact with a Fabric network).

As of the day of writing, Hyperledger Cactus and Weaver (a Hyperledger Labs project) will be merged, being called Hyperledger Cacti. We remain with the first terminology until the complete merge of the two projects occurs. If you’d like to learn more about blockchain interoperability and Hyperledger Cacti, make sure to watch the Hyperledger Cacti workshop available on YouTube.

We leverage SATP’s BLP implementation in Cactus to build our bridge solution as depicted in Figure 1.

To provide higher flexibility to the solution, the bridge entity does not interact directly with the CBDC definition on both chains. Instead, we create an Asset Reference layer in between. This new object intends to represent a certain amount of CBDC that can be bridged. Hence, clients can only initiate bridging operations against asset references, not the CBDC directly.

Regarding the CBDC definition, we provide out-of-the-box support for the ERC20 Token Standard implementation, however, other token representations can be used under certain conditions (they must support certain functionality — explored in more detail in the paper).

The Asset Reference object is defined as follows:

An Asset Reference object is created when a user escrows some tokens in the CBDC smart contract. This means that these smart contracts need to be called on one another. To do so, we leverage the ‘abi.encodeWithSignature’ method. Below there are two snippets that demonstrate portions of the CBDC and Asset Reference smart contract implementation. The example we are considering is the implementation of the escrow function in the CBDC smart contract, which calls the createAssetReference function of the Asset Reference smart contract.

The following image depicts the interaction between all the different components of the system when User A initiates the process of bridging out 100 CBDC to its address in the side chain smart contract. Additionally, User A can transfer these tokens as wished in this chain, for example, to User B, which can later bridge back the 100 CBDC to its corresponding address in the source chain.

Yes, you can try it yourself! Check out the Pull Request in Cacti’s GitHub repository and follow the instructions. You can also check a video demo here.