Introduction to Central Bank Digital Currencies (2/2)

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.

R3’S CORDA

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

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.

JP MORGAN’S QUORUM

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.

COMPARING CORDA, FABRIC, AND QUORUM

Several CBDC proof-of-concept and prototype projects have been conducted to date (see part 1). These projects have generally been spearheaded by a central bank, yet in collaboration with financial institutions (who use existing financial market infrastructure) and developers of enterprise level Distributed Ledger Technology. The following is a brief comparison between the three most prominent contenders (Corda, Fabric, Quorum), largely based on the findings of previous CBDC projects.

Privacy: Corda only seeks to achieve consensus among parties of an agreement on the state of that specific agreement as it evolves, as opposed to seeking agreement on the state of a globally distributed ledger. Hyperledger Fabric offers the ability to set up shared channels (each one a ledger) between parties, with transaction within the channel being private to outside parties. It is worth noting that channel-level account balances can be viewed by channel participants. Regulators (e.g. a central bank) can be included in channels for compliance purposes. Quorum achieves privacy via public and individual private state trees, with the public state tree storing vanilla Ethereum transactions and hashes of encrypted private smart contract changes. Quorum thus offers and requires both private and public smart contract transactions. The private contracts enable private transactions between two parties, while public transactions are used to distribute zero knowledge proofs for verification on the Quorum network.

Scalability & Performance: Due to its design, Corda is not a proper blockchain. This not only alleviates privacy concerns, but also makes scaling significantly easier compared to traditional DLTs. The addition of a new participant only requires the installation of a new node to the existing network. In Fabric, [N x (N-1) / 2] + M channels are required to operate, with N = number of participating nodes, and M = number of multilateral channels. The network complexity rises with each new participant, and participants need to maintain and move funds between individual channel-level accounts for each channel. Quorum’s vastly improves upon the performance of Ethereum by virtue of being a permissioned network, yet there is further room for improvement with regards to the speed of running zero knowledge proofs.

Resiliency: While Corda can continue to operate should individual bank nodes go offline, the use of a single notary node (e.g. central bank) to achieve consensus over uniqueness is a potential point of weakness. This can be rectified with a notary node operated by multiple parties, although at the expense of added complexity. Fabric involves a blockchain, but an orderer is required to order transactions into blocks. The Ubin 2 prototype is built on a single orderer, which introduces a single point of failure. A multi-node ordering service could solve this issue. Propagating hashes of private transactions to the global ledger improves resilience in Quorum. This use of a central ledger ensures significant resilience, and under the tested Raft consensus method the consensus leader could be rotated with each transaction for added resilience. This may or may not be possible in the usage scenario of CBDC, and the consensus leader could thus constitute a point of weakness.

Finality: Of crucial importance to financial service providers. The use of a notary node ensures certain transaction finality in Corda, with a notary signature indicating that input states are thus far unspent. Fabric’s ordered node orders a transaction into a block, and sends it out to channel participants for commitment to the shared channel ledger. The transaction is finalized upon commitment. The Raft consensus method tried alongside Quorum relies on a consensus leader to commit blocks to the chain after verification. Once a block has been committed, the chain cannot be reversed since there is no concept of mining involved, and finality is thus achieved.

Figrue 4, A Brief Summary of Corda, Fabric, and Quorum

Originally published at https://www.standardkepler.com

Standard Kepler is Asia’s leading blockchain financial services provider, offering market changing research insights, in addition to holistic advisory, crypto trading, and custodian services. We take great pride in being able to offer professional services that are trusted for our honesty and driven by technology. Headquartered in Hong Kong, Standard Kepler’s management team previously served in JP Morgan, Macquarie Capital, State Street, and KPMG.

REFERENCES

Bank of Canada; Payments Canada; R3. 2017. Project Jasper: Outline.

Bank of Canada; Payments Canada; R3. 2017. Project Jasper: A Canadian Experiment with DLT for Domestic Interbank Payments Settlement.

Bank of Canada. 2018. Project Jasper: Are distributed wholesale payment systems feasible yet?

Bank of Canada; TMX Group; Payments Canada; Accenture; R3. 2018. Jasper Phase 3: Securities settlement using DLT.

Corda. 2018. The Corda Platform: An Introduction.

Deutsche Bank Research. 2018. Why would we use crypto euros?

European Central Bank. 2018. Stella: BOJ/ECB joint research project on DLT.

Hyperledger. 2018. An Introduction to Hyperledger.

JP Morgan. Quorum Whitepaper.

Monetary Authority of Singapore; Deloitte; Bank of America Merrill Lynch; BCS Information Systems; Credit Suisse; DBS Bank; HSBC; J.P Morgan; Mitsubishi UFJ Financial Group; OCBC Bank; R3; Singapore Exchange; UOB Bank. 2017. Project Ubin; SGD on Distributed Ledger.

Monetary Authority of Singapore; The Association of Banks in Singapore; Monetary Authority of Singapore. 2017. Project Ubin Phase 2.

Monetary Authority of Singapore; SGX; Anquan Capital; Deloitte; Nasdaq. 2018. Project Ubin: Delivery versus Payment on DLT. South African Reserve Bank. 2018. Project Khokha: Exploring the use of DLT for interbank payments settlement in South Africa.

Sveriges Riksbank (Swedish Central Bank). 2017. The Riksbank’s ekrona project report 1.

Sveriges Riksbank (Swedish Central Bank). 2018. The Riksbank’s ekrona project report 2.

Sveriges Riksbank (Swedish Central Bank). 2018. Economic commentaries: Are Bitcoin and other crypto-assets money?

Introduction to Central Bank Digital Currencies (2/2) was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.