CBDC Part 4: An Introduction to JP Morgan’s QuorumBy Apr 22, 2019 3 Min Read
This analysis is provided by our columnist,
THOUGHTS OF THE WEEK
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.
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 the Chart of the Week, 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’s Fabric, and JP Morgan’s Quorum, part 5 of this series will briefly compare all three according to their suitability in supporting wholesale payment systems.
CHART OF THE WEEK
Henry Chan 📧