Composition of Consensus Protocols – Keys to Blockchain MVP Development
By Alveena Bakhshi, Storied Digital and Product Transformation, Veritux
Among its various uses, organizations use blockchain to secure their data, reduce the cost of cross-border transactions, remove inefficiencies in the supply chain, and intellectual property management. Governments are finding a use for blockchain in securing national identity data, notary services, and voting. I posit, sanctions too.
I started exploring blockchains when I was looking for technologies to track the recruitment of at-risk youth as child-soldiers and came upon Provenance. As an example, the company’s software leverages supply chain data to tell you where the shrimp in the linguini on your plate came from. Blockchain is foundational to ESG.
In financial services, blockchains can be revolutionary in asset management, at the same time reducing the costs of back-office and middle-office reconciliation. In view of rising interest rates, however, real-time transactions and shift to fund-then-trade from trade-then-fund, are few of many new revenue opportunities.
Given the multitude of uses, it becomes important for management to weigh in at a policy level on two components of the blockchain MVP development process; consensus mechanism and choice of platform. This commentary addresses the former, leaning on academic research, and the latter, based on prevailing examples.
In a blockchain, a distributed consensus protocol is the key technology that enables a unified transaction ledger without the help of a central authority. The two genres of aforementioned consensus protocols are Proof of Work or PoW-based, and Byzantine Fault Tolerance BFT-based. A hybrid of these enhances performance and scalability.
The Nakamoto Protocol, of Bitcoin, Ethereum, and Litecoin, was the first to resist double-spending attacks, but faced performance hurdles owing to its PoW mechanism. Very high energy consumption, low transaction capacity, and poor scalability led to Proof of Stake (PoS), Proof of Authority (PoA), and Proof of Elapsed Time (PoET) emerging as alternatives.
Designers also turned to Byzantine fault tolerance and multi-party computation, algorithmic State Machine Replication (SMR)-based consensus protocols, to improve performance, especially in permissioned blockchains. Combined with Cryptography, as Asynchronous consensus protocols, they resist severe network conditions with uncertain message delays.
Cryptographic methods are also used to establish trust among nodes, enabling coordinated block proposing schemes such as round-robin and committee-based block generations. These schemes, along with Incentive protocols to encourage honest participation, are a key component of alternative consensus protocols to increase overall system sustainability.
The ‘Five Components’, the core around which protocols have also evolved, are; (i) Block proposal for generating blocks and attaching proofs to resist Sybil attack for instance, range from proof of work, stake, authority, retrievability, proof- of-elapsed-time, round-robin, committee-based, etc. (ii) Block validation for checking proofs referenced above and validity of enclosed transactions; checking for signatures, execution, proof-of-X block proposal, eligibility for committee-based, etc. (iii) Information propagation for disseminating blocks; advertisement-based, block header soliciting, unsolicited block push, relay network, etc. (iv) Block finalization or agreement on the acceptance of validated blocks on servers current state, executing requests and logging the result and are of the type of Longest-chain rule, GHOST rule, BFT, and other Byzantine agreements, checkpoints, etc. And finally, (v) Incentive mechanisms that promote honest participation include Network token rewards such as block rewards, transaction fees, eligibility for issuing new transactions, etc. The following two protocols are introduced to address performance bottlenecks in specific, which cause designs to fail; (vi) Fault Tolerance: SMR-based Practical BFT (PBFT). And with, cryptography, Asynchronous referenced above, are HoneyBadgerBFT which provide high transaction throughput in shorter block cycles, and (vii) ‘Throughput’ or Confirmation latency, commonly measured as Transactions Per Second TPS.
That said, a new blockchain consensus proposal may not cover all of the aforementioned components. In Permissioned blockchains for instance, where participation is sanctioned, the incentive mechanism may have no relevance. Similarly, widespread public or Permissionless blockchains have been so fixated on the first component, ie. Block proposal that they often neglect the others, most likely because of the criticism of the first due to its limited scalability and inefficient energy use. Compared to Permissionless blockchain, the identity-revealing requirement and more effective network governance of Permissioned blockchain make them ideal for internal or multiparty business applications. Its limited size allows for more efficient consensus protocols that achieve higher transaction capacity.
In financial services applications, additional concerns such as risk and volatility also impact consensus protocols and platform choice. Take, for instance, 9th Gear’s FX settlement blockchain for corporations, hedge funds and the interbank market, to expand and create a market for intraday liquidity. 9th Gear chose JP Morgan’s Quorum on Ethereum blockchain, over Ripple’s XRP, which is designed precisely for FX settlement, with maximum speed and minimum cost. Quorum allowed 9th Gear to be Private and Permissioned, and with cryptography it helped them enable real-time settlement such that risk is resolved in pre-trade. 9th Gear further decided to reduce volatility by transacting within cryptocurrency, unlike XRP, where transactions check in and out of standard currency.
As you will have understood, since the early day consensus protocols have been inspired by established research in distributed computing, cryptography and increasingly formal security analysis. The privacy of consensus participants in large-scale permissionless blockchains remains a perennial topic for scientific research. The design and analysis of blockchain consensus protocols are also increasingly leaning into formal scientific research, bringing us to the inescapable discussion of the Security-Decentralization-Scalability conundrum.
Security refers to the blockchain’s consensus security in the presence of malicious players and anti-censorship capability. Decentralization refers to the decentralization profile of the blockchain network, which is normally associated with geographic diversity, connectivity patterns, and synchrony of networked nodes. Scalability means the system needs to remain secure and efficient with rising transaction throughput within the broader context of system performance. In blockchain consensus protocols tailored for a financial application, security is always the top priority. But lower the security requirement, and you have a more scalable protocol design. While a more decentralized network tends to be less synchronized, and more diverse with a sparsity of connections, it challenges censorship and effectively enhances the system. Though reduced synchrony may imply messages are less bounded by delay requirements, it enables better-connected players to gain unfair advantages and impairs consensus security.
In conclusion, there is no one size fits all blockchain consensus protocol. One may cherry-pick individual protocol components to fulfill specific application needs. This composability of blockchain consensus protocol makes progressive protocol improvement, i.e., one individual protocol component to be updated at a time as opposed to an overhaul of the entire protocol. It is not only feasible but also invaluable in scaling established blockchain systems, at the same time as ensuring network-wide consensus and corralling effort.