Stuart Popejoy has 15 years experience in building trading systems and exchange backbones for the financial industry. Prior to co-founding Kadena with Will Martino in 2016 and becoming the company’s president, Stuart worked at JPMorgan Chase in the new products division, where he led and developed JPMorgan’s main blockchain product, Juno. Stuart also wrote the algorithmic trading scripts for JPMorgan, which informed his creation of Kadena’s simple, purpose-built smart contract language, Pact.
The views and opinions expressed here are solely those of the author and do not necessarily reflect the views of Cointelegraph.
IBM is a major player in the world of enterprise blockchain, offering a blockchain platform based on Hyperledger Fabric and launching blockchain pilots with large companies like Walmart and Aetna.
As one of many contributors (including recently announced Microsoft and Salesforce) to the nonprofit, the open source Hyperledger Foundation, IBM has made a huge investment in promoting Fabric as a private or “permissioned” blockchain, implying that it offers features in common with well-known blockchains like Bitcoin or Ethereum, while somehow removing any aspects that might be “unsuitable for enterprise.”
However, the technology IBM is actually selling and calling “blockchain” — i.e., Hyperledger Fabric — sacrifices the most important features of a true blockchain, whether permissioned or public. Fabric’s architecture is far more complex than any blockchain platform while also being less secure against tampering and attacks. You would think that a “private” blockchain would at least offer scalability and performance, but Fabric fails here as well. Simply put, pilots built on Fabric will face a complex and insecure deployment that won’t be able to scale with their businesses.
Blockchain options on the market
When I worked at JPMorgan Chase in 2016, I led an emerging technology group that researched and vetted blockchains for the bank’s potential use and strategic investment. This involved in-depth analyses of early versions of Hyperledger, Axoni, Symbiont, Ripple and Ethereum. It was clear back then that the blockchain options on the market were technologically inadequate for real enterprise use cases. Unfortunately, we see these same core problems today with Hyperledger Fabric.
The concerns we raised included: How does a blockchain’s smart contract language safely and simply express complex business rules? How are public-key signatures guaranteed to be valid? Can the system scale to additional participants (nodes) without drastically slowing down performance? And, for a future-thinking enterprise, can you interoperate with other public and private blockchains easily?
Using these questions as a framework, I believe that IBM’s system fundamentally lacks the required elements of a blockchain, with misleading performance numbers and questionable long-term business viability. While my colleagues and I don’t see the numbers game (transactions per second, node count) as the only factor in blockchain adoption, we do think it’s important to educate people on what a blockchain is and is not. This education will hopefully help everyone better understand the landscape of the emerging technology of blockchain.
What blockchain is and isn’t
In order to really understand where IBM’s blockchain stands, we need to look at the very definition of a blockchain itself. A blockchain is, at its core, a decentralized immutable ledger of events or transactions in which truth is enforced by a consensus mechanism. In public blockchains like Bitcoin and Ethereum, this consensus is achieved through Proof of Work, or “mining.” In permissioned blockchain, consensus can be achieved through participants supplying cryptographic signatures to vote on what gets written. Either way, no central authority arbitrates what is true.
IBM’s definition of blockchain captures the distributed and immutable elements of blockchain but conveniently leaves out decentralized consensus –– that’s because Hyperledger Fabric doesn’t require a true consensus mechanism at all. Instead, it suggests using an “ordering service” called Kafka. The problem is that, without enforced, democratized, cryptographically secure voting between participants, you can’t prove that somebody hasn’t tampered with the ledger. A fault-tolerant consensus is a hallmark feature of a blockchain, and without it, IBM’s “blockchain” is little more than a time-stamped list of entries.
Fabric’s architecture exposes numerous vulnerabilities that can be exploited by malicious coordination. For instance, it introduces public-key cryptography “inside the network” with validator signatures, which provide the main security assurance but originate after an externally signed transaction has been submitted. This fundamentally invalidates the proven security model of Bitcoin and other real blockchains, in which the provenance of any transaction is assured only by an external user’s public key signature, and cannot be intermediated in any way by the system. In sharp contrast, the only signatures that matter on Fabric for consensus are those of the validator, while the user signatures disappear into an arbitrary dataset replicated through the network.
Fabric researchers play fast and loose with performance numbers because, fundamentally, Fabric’s architecture cannot scale while maintaining peak performance. Fabric uses a multichain environment (called “channels”) to provide confidentiality between participants. Providing confidentiality is an important feature for private “enterprise” blockchain and necessarily involves trade-offs and complexity, but a multichain solution is a bad choice for scalability. It also makes for a woefully complex deployment, with nonuniform nodes, unreliable smart contracts and proliferating potential points of failure.
Thus, performance numbers for a standard Fabric deployment are unimpressive to start, degrade rapidly as nodes get added and are single-channel: If you want to transact with the whole network across multiple channels, the numbers aren’t even relevant. Even so, when looking at individual channels, this system struggles to get above 800 transactions per second (TPS), but even a 16-channel configuration can barely get above 1,500 TPS, with latencies reaching well into the 10-20 second range at the upper throughputs.
Recent efforts to speed up Fabric have resulted in claims of reaching up to 20,000 TPS, but the changes made to the architecture by researchers move so far from blockchain as to be unrecognizable: Endorsers no longer act as validators and Kafka is enshrined as the only possible ordering service (Fabric, in theory, can accept a true blockchain consensus, but it would be so slow that nobody would ever use it in production). Finally, these are still single-channel numbers, meaning the whole notion of a blockchain as a shared source of truth is invalidated.
Why smart contracts and hybrid options matter
The final points of consideration when looking at blockchains are how they intend to scale beyond private databases and how their tools –– such as their smart contract language –– intend to help businesses succeed on a larger scale. Remember, a smart contract is not just a piece of code; it is a representation of business logic. A smart contract may secure a house on the blockchain, assure a digital identity, or even represent an escrow transaction between people buying and selling a used car. It is important that a smart contract is reliable and always does what it says it will.
When it comes to building anything on a blockchain, you need to be able to represent what you want to do (buy, sell, package data, etc.) through smart contracts. The easier or simpler your language is to use, the faster you will build the thing you want and get it in front of the eyes of stakeholders. More importantly, you want the smart contract’s function to actually generate revenue or some positive outcome for your business.
Hyperledger Fabric’s smart contracts (“chaincode”) can be written in a number of programming languages, including general Javascript or Go. But there are trade-offs between the convenience of a programmer already knowing a general purpose language and the security and safety that a domain-specific language provides. When the stakes are as high as in blockchain –– where millions of dollars can be lost if the code is buggy or incorrect because it wasn’t designed for blockchain –– the smart contract language must be purpose-built and safe by design. Ideally, it would also be easy to learn and simple to use in the desired blockchain environment. Chaincode largely fails in this regard; we found it took some 150 lines of code just to execute the classic programmer tutorial “hello world.” And this massive amount of code can become a breeding ground for those million-dollar bugs.
Not ready for the future
Increasingly, the most sophisticated observers of blockchain ecosystems are realizing that private and public blockchains will not exist in a vacuum but instead will want to work together: A private network will want to make a token available to consumers on a public blockchain, and a public blockchain’s decentralized application will want to store sensitive information on a private blockchain. Unfortunately, users of IBM Fabric (as well as R3 Corda) could find themselves “cut off” from public blockchains by the sheer incompatibility of the architecture — but also by the inability of their smart contract language to execute seamlessly in both a public and private environment.
As IBM dominates a lot of the enterprise blockchain press cycle with its announcements of partnerships, it is important to look under the hood at what the technology can actually do. IBM’s “blockchain” technology falls short in numerous ways — including security, performance and reliability — and as such, provides an inferior solution for organizations looking to use blockchain to achieve meaningful business improvements. To truly realize the value of blockchain, sophisticated customers will look to challengers offering better tools, better blockchains, and a better vision for the future and how we utilize technology.
