Introduction to Central Bank Digital Currencies (2/2)

By Standard Kepler Research

This is 2/2 for the series of Central Bank Digital Currencies by Standard Kepler Research

In the previous article we have discussed Central Bank Digital Currencies as one of the potential use case of DLT based systems.

In this article, we are going into the detail of how CBDC can be implemented and why banks may want to do it. By comparing the threemost possible options of DLT based systems(Corda, Hyperledger Fabric, and Quorum) in four different aspects: 1.) Privacy, 2.) Scalability & Performance, 3.) Resiliency and 4.) Finality.


Corda argues that the essence of blockchain is “ensuring that data held by different actors is, and remains, consistent as operations are applied to update that data, and that this forms the foundation on which reliable transactions are built.” This view allows Corda to pursue the advantages of DLT without utilizing a blockchain.

[Corda] is heavily inspired by blockchain systems, but without the design choices that make traditional blockchains inappropriate for many financial transactions.” Corda defines its ledger as a set of immutable state objects. This ledger acts as a reliable single source for the Corda platform, yet it does not make transactions nor entries on this ledger globally visible. Cryptographic hashes are instead utilized to identify parties and data and ensure that only parties that are part of a agreement can see relevant ledger details.

Corda seeks to achieve consensus among parties of an agreement on the state of that specific agreement as it evolves. This “per agreement” approach is in contrast to systems (e.g. Bitcoin) that seek to achieve consensus on the state of an entire ledger. Updates to the Corda ledger are applied using txs that consume existing state objects and create new state objects (there is no native cryptocurrency involved). The validity of a transaction can be checked independently by parties by running the contract code. However, a predetermined observer node is required to reach consensus over uniqueness. Importantly, this observer node only checks consumed input states, and does not need to see the full content of a transaction. There is no concept of mining in Corda.

Figure 1, Transaction Flow of Fund Transfers in R3 Corda (by KEPLERLAB.IO)

On Corda, state objects represent an agreement between parties. This agreement is governed by contract code that is linked to legal prose. Transactions in turn transition state objects through a lifecycle, and transaction protocols enable parties to coordinate actions without a central controller. Combined, these components are referred to as CorDapps, and need to be built by developers on the platform.

Corda is a timely reminder that a blockchain is only a way to implement a distributed ledger, but not all distributed ledgers necessarily employ blockchains. Hyperledger Fabric and Quorum are two other ways of building distributed ledgers. CBDC Project Ubin 2 interestingly compares all three, a comparison we will return to.


Hyperledger Fabric is part of the Hyperledger family of projects hosted by the Linux Foundation. These projects have all been designed to be modular, with the intention of offering greater flexibility to customers and developers alike. In theory, this allows developers to experiment with different components without affecting the rest of the system, allowing for a Lego-like approach to building solutions for diverse problems from a fixed set of components. Fabric further runs distributed applications written in general-purpose programming languages, without depending on a native cryptocurrency.

The concept of channels is also at the core of Fabric. The system is built on a network of bilateral channels between participants, with each bilateral channel forming one ledger. By establishing such channels, data privacy can be maintained within the channel and away from other system participants. A third party, such as a monetary authority, can be included in the channel for purposes of transaction recording and monitoring. Multilateral channels can also be created, such as in the case of Singaporean project Ubin, where participating banks are linked by multilateral funding and netting channels. Such a funding channel allows participants to move funds between their individual channel-level accounts. Note that the number of bilateral channels, and thus system complexity, grows with each new system participant.

Figure 2, Transaction Flow of Fund Transfers in Hyperledger Fabric (by KEPLERLAB.IO)

Any blockchain that sees usage within financial market infrastructure must provide immediate finality, rendering consensus algorithms such as proof of work and proof of stake unviable. Fabric prevents double spending attacks via a system endorsements and an orderer. Participating nodes validate a transaction against the system endorsement policy (defined by the chaincode) to ensure the validity of the transaction and its signatures (see Figure 2). An orderer packages endorsed transactions into blocks, and broadcasts these blocks to the channel participants. These subsequently validate the transactions before they are committed to the ledger. It is also possible to include a consensus mechanism that allows for a multiple node ordering service.

Several proof of concept Central Bank Digital Currency (CBDC) systems have been built on Hyperledger Fabric, most notably so Singaporean Ubin 2 and Japanese-European Stella 1 & 2.


Achieving appropriate levels of privacy is a core requirement in enterprise blockchain. How a blockchain achieves this is a question with many possible answers, ranging from the relative simplicity of bilateral channels to the use of data heavy zero knowledge proof transactions. JP Morgan’s Quorum sets out to build on the work already done by Ethereum, and to turn Ethereum into an “enterprise-ready distributed ledger and smart contract platform”.

All nodes in a Quorum network run the same set of components. However, these components differ somewhat from Ethereum. Foremost is the introduction of private state trees. The Quorum blockchain (just like Ethereum) saves information in the form of states, and transactions modify states on the blockchain. Quorum nodes have a public and individual private state trees, with the public state tree storing vanilla Ethereum transactions and hashes of encrypted private smart contract changes.

A Zero Knowledge Security Layer (ZSL) developed by the team behind Zcash is another core component of Quorum. ZSL enables the transfer of assets on the network without revealing the sender, receiver, nor the quantity of the asset. Hashed values of the initial balance, transaction amount, and final balance are submitted by the sender and receiver to a proof generator off-chain. They are subsequently submitted to the Quorum chain for verification by other nodes on the network, following which the transaction is confirmed and balances are updated.

Figure 3, Transaction Flow of Fund Transfers in JP Morgan’s Quorum (by KEPLERLAB.IO)

Quorum thus requires both private and public smart contract transactions. The private contracts enable private transactions between two parties, while public transactions are used to distribute ZSL proofs for verification on the Quorum network. The transaction flow under Quorum is visualized in Figure 3, and narrated most succinctly by the Ubin Phase 2 whitepaper itself: “A payment instruction for fund transfer is initiated from the sender’s dApp. The dApp invokes the private contract to generate a private transaction. The sender’s dApp then invokes a public transaction which will be executed by all nodes on the Quorum network. The public transaction is created with the hash of payment instruction amounts which will be used as inputs to generate and verify proofs. Hashing is done to maintain data privacy since public transactions are propagated to all nodes in the network.

Transaction finality is another characteristic that is of crucial importance in enterprise settings. Financial institutions are typically unable to handle probabilistic finality, and the probabilistic nature of finality under Ethereum’s Proof-of-Work is thus unsuitable for enterprise applications. Quorum introduces alternative ways of achieving consensus, the one having been evaluated by Singapore’s Monetary Authority for wholesale settlement purposes being “Raft”. Raft has been used for many years in software such as Kubernetes. It relies on the concept of a single leader, who proposes blocks that others validate. This means there is no forking, and as such there is transaction finality. Raft also enables the setting of block times that are significantly faster than is possible under Ethereum.

Having thus far introduced R3’s Corda, Hyperledger Fabric, and JP Morgan’s Quorum, we will next briefly compare all three according to their suitability in supporting wholesale payment systems.

read original article here