Choosing an Enterprise Blockchain: An exhaustive guide
The current state of Blockchain
For those of you familiar with Gartner’s hype cycle, it will be immediately clear where Blockchain as an emerging technology resides, and in turn where it is headed.
2017 saw heady heights for the Crypto space (Peak of Inflated Expectations), followed in 2018 by a descent only seen in nascent, emerging asset classes where volatility is generally at it’s highest.
There is perhaps an argument to say this caused irreparable damage within the Blockchain industry — proponents of this view should think again.
With any ‘peak’, there will always be those seeking to prey on others, promising a quick buck or unrealistic expectations. I think it’s fair to say the majority of those projects or persons have now been identified and disposed of.
So whilst on the face of it Blockchain has experienced a tough 18 months, the technology as a whole is better for it.
PwC have undertaken a survey of 600 executives outlining the state of Blockchain adoption within organisations.
Take careful note of three points in the sub-header:
84% of respondents are actively involved with blockchain
45% believe trust could delay adoption
28% say interoperability of systems is a key for success
84% are actively involved. If your organisation is not already exploring blockchain, they soon will be.
And it is fair to say that public blockchains are not yet fit for purpose, leaving enterprise blockchain firmly front of mind for executive decision makers.
I believe I am one of few uniquely positioned to opine on the current era of Enterprise DLT: Hyperledger-trained; with years of experience developing in/on Ethereum; and Corda certified.
The key tenets of Enterprise DLT
Enterprise DLT (Distributed Ledger Technology) needs to solve five challenges to be fit for purpose — namely: Inherent Data Privacy; Technical Soundness; Scalability; Settlement Finality and Interoperability.
I’ll be comparing Enterprise Ethereum (Quorum), Hyperledger Fabric and Corda with regards to the above tenets. There are others, but they’re considered more specialist and in the interest of brevity I’ll compare these three at a high-level.
Disclaimer: At Ivno we have made the choice to develop on R3’s Corda. I will attempt to remain impartial given my love for Ethereum’s vision and the well-intentioned OS Hyperledger but apologise in advance for any bias.
Inherent Data Privacy
I think it’s fair to state that organisations are generally unwilling to share competitive advantage with others in the market. Should competitors be able to parse proprietary data on the chain, it’s unlikely to be suitable for the majority of organisations in capitalist society.
All of the below utilise peer permissioning to ensure only known parties may join the network.
Quorum
Separates states into public/private (Tessera), utilising P2P encrypted messages.
Whilst it offers the choice for private data transfer — human, business logic or programmer error is unaccounted for with the potential for accidentally leaked data. Further, Quorum leans on a zero-knowledge proof security layer (ZSL) utilising zk-SNARKS, a cryptographic technique which is relatively untested and not quantum-resistant. This should be carefully considered as your data may be exposed as quantum computing progresses (generally fine for some organisations, but nation states or financial infrastructure? Not so much).
Hyperledger Fabric
Offers the concept of ‘channels’, which whilst protecting privacy from those outside the channel, also creates a silo for assets and negatively affects interoperability (I’ll come to this later). It’s also fair to say it might become onerous and progressively more difficult having to manage creation and maintenance of channels prior to being able to privately interact with parties.
Hyperledger also offers zk-SNARKS (see above).
The combination of channels and zero-knowledge data proofs do allow for a fairly substantive privacy model, but come with high overheads both in terms of programming and processing.
Hyperledger Fabric has also undergone a number of re-architectures due to inherent privacy design issues, so keep that in mind when considering backwards-compatibility of your application.
Corda
Utilises a peer-to-peer transaction model, which deals with privacy inherently. Data is only ever exposed to those who “need to know”, generally meaning the counterparties and the Notary.
Note: Notaries in Corda may be validating or non-validating meaning they receive the data in full or merely protect against double-spends, respectively. For data protection non-validating notaries should be used.
Identities (X.509) may be obscured as per preference, and transaction tear-offs may be used to hide the chain of provenance of a State.
Work is underway to incorporate a secure enclave in the form of Intel SGX, allowing encryption of the entire ledger — running the entire DJVM within the enclave.
A peer-to-peer model is generally more at risk of data tampering, whereby data-at-rest (on disk or within the database) may be tampered with and perhaps even pass verification should all parties to the transaction collude. Corda’s threat model mitigates this with the use of Notary consensus, as the Notary would refuse to advance the state of a tampered asset. An attacker would need to collude with all relevant parties and also require controlling access to specific notary infrastructure.
Technical Soundness
Enterprise DLT should offer the least friction in terms of upskilling developers, use tried and tested technology, and protect against future changes in protocols or languages.
Quorum
Uses Solidity for smart contract programming, which is a double-edged sword.
In terms of public blockchains, the EVM and Solidity are by a significant distance the most popular for decentralised applications, meaning skill crossover from public to private Ethereum chains is a distinct advantage.
However, from personal experience and from various infamous events, (The DAO hack, Parity’s multi-signature wallet hack, and the accidental freezing of Parity’s Wallets and the loss of over 500,000 ETH) Solidity-introduced programming error can be devastating in it’s effects.
It’s fair to say that Ethereum’s exceptional team of core developers have realised this, and are replacing the EVM with eWASM. I expect Quorum will have to follow suit in time.
A lengthy list of all Ethereum Smart Contract attacks here.
Hyperledger Fabric
Utilises ‘Chaincode’ for smart contracts, intelligently encouraging a mix of nascent and more perennial core smart contract languages — offering Golang, Java and NodeJS. Support for other languages are incoming: Python.
Interestingly, Hyperledger Fabric supports Ethereum — in a move which I suspect is intended to garner developer skillshare from other EVM-driven blockchains in the short-term.
Corda
Leans heavily on tried and tested technology choices: Java (or Kotlin), AMQP and SQL databases with support for Oracle, PostgreSQL, SQLServer & Azure SQL.
Smart contracts are written using Corda’s flow engine, which undertakes the heavy-lifting such as collecting signatures enabling developers to focus on core business logic and providing a remarkably short learning-curve.
Transactions on Corda rely on the existing legal structures familiar to Enterprises, with legal prose (know as Ricardian Contract) included within transactions. on Corda Code is not law, law is law.
Scalability
Often considered the ‘holy grail’ of Blockchain and DLT, and in some cases the bottleneck to mass adoption — scalability and transactions per second (TPS) for Enterprise purposes needs to be considerable.
The Scalability Trilemma dictates that when scalability increases, it’s usually either decentralisation or security that suffers. Enterprise DLT have found novel techniques to mitigate this.
Reported figures should be taken with a pinch of salt due to the number of variables involved: network setup; hardware; scenario overfitting; latency considerations; business logic; privacy techniques and consensus algorithms (PBFT for example) all have the potential to affect throughput significantly.
Quorum
Generally a high throughput of around 100-200 TPS dependant on network design, setup and hardware resource, although needs tinkering to the situation and and proper design and setup isn’t trivial.
Hyperledger Fabric
Between 2,000–a reported 20,000 TPS. Very impressive and enterprise-grade, but suffers from other design problems (see interoperability) as a result.
Corda
Corda Enterprise offers multithreading and increase throughput significantly beyond the OS figures. DTCC recently proved 6,300TPS (or 115,000,000 daily trades) through 170 disparate cloud-based nodes.
Note: The DTCC study reached 20,000 TPS with each full ‘trade’ requiring several consequent Corda Transactions. This could be better expressed as 6,300 TRADEs per second.
Settlement Finality
It is an undisputable fact that proof of work consensus chains such as public Bitcoin or Ethereum are unfit for enterprise usage. Once a block is committed to the ledger, it is only exponentially less likely to revert as the chain grows, and can never be considered to have mathematical finality. Nic Carter has a fantastic article on this which I would highly recommend.
Be very aware of 51% attacks (ETC I’m looking at you!) and even ‘long-range’ attacks on public chains.
Settlement finality is largely binary: either a transaction is able to be considered final or it isn’t. All three solutions discussed in this post offer variants on methods of finality, but all may claim to support a forward-only ledger and thus I will not delve into specifics here. All three pass the test.
Interoperability
Let’s consider for a second that we’re in the 1970s— Satoshi is but a wee boy/girl/group/nation-state/AI/thing.
Everyone understands that the Internet has the potential to change the world, but it’s not immediately clear how. ‘The Internet’ is actually a set of disparate intranets, using disparate programming languages and no standard protocol design.
Until Blockchain has it’s TCP/IP moment and standards are agreed — protocols such as Polkadot and Cosmos look promising and pioneering work is being done such as Jasper/Ubin) — inter-blockchain interoperability is, for now, distant.
So for ease of comparison, let’s compare intra-blockchain interoperability: how applications within the same DLT network may interoperate.
Quorum
Enterprise Ethereum, under the guidance of the Enterprise Ethereum Alliance, is heading in the right direction with it’s Client Specification V3. There’s no saying when, or who, will adopt these standards, though I suspect members of the EEA will move towards it and allow the movement of applications between Enterprise Ethereum clients.
Solidity allows contracts to call other contracts, though this can present security implications such as re-entrancy, so tread with caution.
Hyperledger Fabric
Whilst ‘channels’ allow considerable speed increases and explicit privacy, they also come with a considerable disadvantage.
There is a distinct lack of interoperability between channels. There are solutions in the form of Hash Time Locked Contracts and Hashed Timelock Agreements, but it’s fair to say that assets are stranded within channels and largely need re-issuance within other channels — at the expense of losing provenance.
In my humble opinion (and that of Richard Gendal Brown, Corda’s CTO), this is a plaster-fix over a substantial design flaw.
Corda
One of Corda’s key principles is interoperability. From the ground-up, Cordapps were designed to be interoperable with one another. The emergence of the Corda Network allows an ‘internet of nodes’ to exchange assets or data via a secure layer.
Corda Settler even allows modules to be created to connect external payment rails.
Conclusion
When choosing an Enterprise Blockchain, as with any software, you must consider the pros and cons of the frameworks available and how each suits the design of your application. I hope my musings above have provided some insight.
There is no ‘one size fits all’ approach within DLT, and perhaps that’s a net positive. Specialised networks are able to offer unique services, ecosystems and promises — and as we drive steadily towards interoperability between DLT, we are likely to see incredible efficiencies within Enterprise.
Distributed Ledger Technology is already here and is changing the world, one block at a time.
