These Aren’t the Enterprise Blockchains You’re Looking For
Richard Gendal Brown is a Jedi Master. Beware the mind tricks.
Richard Gendal Brown, CTO of Corda, became one of my all-time favorite people and exemplars of grace when I saw him on-stage taking serious abuse from a belligerent co-panelist arguing that his ideas about blockchain were nonsense. The pugilistic tone and disrespect were entirely lost on Richard, who showed genuine fascination with what the other speaker was saying.
When it was again his turn to speak, his response was trademark Gendal:
“Ah! That’s interesting…so I think what you’re saying is…”
Then he forged both arguments into a sensible vision of how they could work together. It was masterful…Jedi-masterful.
If I ever get to be that good (in both senses of the word), I’d like a sky-blue lightsaber, please.
All Jedi Struggle with the Dark Side
Richard’s graciousness is sometimes less apparent when he writes one of his treatises on blockchain. Unlike in his stage show, he often goes on the offense and picks a fight. The title of one of his recent pieces is a great example: “Busting the Myth of Public Blockchains for Business.”
Richard knows how to capture eyeballs with a bit of controversy. But this makes it hard for the casual reader to pick up on the nuances. Richard has a penchant for slipping in a few Gendalian mind tricks and, if you aren’t careful, he might draw you to conclusions that perhaps you should question.
Three Gendalian Mind Tricks
I’m going to walk through three points Richard recently made, examine what I think is right and wrong about his assertions, and then make the case for a better mental model for all of us to start using, one that I hope helps us do what Richard did on that panel: listen to each other and find a way to work together.
The ‘Who Has the Bigger Ecosystem’ Debate
In his January 14 blog post on gendal.me, Richard questions whether Ethereum’s developer community is as big as its proponents claim.
Perhaps the Ethereum developer community has 250,000 people. Could be more. Could be less. Anyone who has worked in developer ecosystems will tell you that hard figures aren’t easy to pin down.
What I do know is that I was once responsible for the care and feeding of the Hyperledger Fabric developer community. And when I looked around, I knew — having the benefit of three decades of direct experience with how ecosystems evolve — that in a contest against Ethereum for the hearts and minds of developers, corporate innovators and entrepreneurs, I was going to lose.
Colleagues from Gartner put the Ethereum community’s numbers somewhere north of 30 times that of Hyperledger, and last I ran the numbers, Corda didn’t even blip the graph when placed against Hyperledger and Ethereum in terms of community size. I’m just calling the data like I see ‘em.
Yet Richard implied that there are “staggeringly” more developers for Hyperledger and Corda, because there are a million Go developers and twelve million Java developers. He waved his Jedi hands and let the reader conclude that because Fabric is written in Go, and Corda in Java, any Java or Go developer must be ready to build on those platforms.
The Ethereum Pantheon client is written in Java, so that must mean that all Java developers are now ready to be Ethereum developers, right? Of course not. Okay, then maybe it’s about the primary language used to write business logic to a ledger (e.g., Ethereum smart contracts, Fabric chaincode, etc.).
For example, one writes Fabric chaincode in Go. But try using your Golang skills to write chaincode without the help of a brittle abstraction-layer like the recently-deprecated Composer tool. Chaincode is a low-level framework that only a systems developer who dreams of writing machine instructions directly in ones and zeroes could love. But, yeah, it’s in Go, so go knock yourself out.
What should be clear here is that the programming language isn’t really the thing that makes one a competent, active chaincode or smart contract developer. Richard knows this is faulty reasoning, but that’s the Gendalian Jedi mind trick.
Lesson: Make sure you’re wearing your Jabba the Hut cosplay outfit when you read Richard’s stuff.
People get behind Ethereum because they believe in the importance of a global, always-on utility — an evolution of the Internet — that gives people the ability to take control of their identity, to own digital assets and create novel incentive mechanisms without having to set up expensive enterprise infrastructure or pay access fees that would make joining an elitist country club look cheap.
Are there people learning Fabric and Corda? Yep — I used to fund and run the programs that pushed developer education for Fabric. But I’ve never met a single developer that was really passionate about Fabric the way Ethereum developers are. In my experience, they were learning it because they believed that they could get paid by big companies to use it.
There’s nothing wrong with making a living. And if Fabric, Corda, and the like are successful (the way they define success) years from now, there will still be back-office developers slogging away, maintaining those “too embedded to fail” systems. Same as there are still developers today working on maintaining systems written in Cobol.
Bottom line: For as long as I can remember, there have been tools the boss tells you to use, and tools you tell the boss to adopt if they don’t want to lose you. I’m pretty sure I know which one Ethereum is becoming, and I’ve been in the room when developers at major institutions made that exact case: “Use Ethereum or I’m gone.”
Two Rights Don’t Make Richard Not-Wrong
Richard’s second assertion: It’s wrong to say that using private-permissioned instances of Ethereum for enterprise projects gives companies the best way to interop with the public chain.
I have to agree with Richard here, to a degree. If you are looking for a way to have your cake and eat it too — if you want a private network but also the ability to transact with public networks and other private networks — then a private-permissioned instance of Ethereum can’t interoperate with the Ethereum mainnet out-of-the-box any more than a Fabric or Corda network can. That’s just truth — for now.
But I’ll hasten to add, code on two Fabric channels can’t interop either, and they are on the same platform. Nor can Fabric and Corda easily interop. This is the current state of maturity for all distributed ledgers.
Sure, if you believe that the Ethereum skillset is crucial, and that Solidity is essential to learn right now in your corporate project, then using a fork of the same technology as the public mainnet might allow you a modest advantage in finding developers with the necessary skills and in being able to transfer the skills you acquire to wider projects in the future.
But then Richard goes on to assert that Ethereum is on its way to a major 2.0 update, so what you learn building with today’s Ethereum could leave you having to learn new patterns as the community evolves.
Again, Richard is right — sorta. You can expect that by the time your private project is out there in production, the mainnet will have evolved, and you’ll have to learn new stuff if you want to keep up. What he doesn’t mention is that the evolution of Ethereum is what you should be excited about. The upcoming updates to the mainnet are compelling, powerful, and important for business. Of all the blockchain efforts that have been deployed as a global mainnet, Ethereum continues to astound me with its ability to stay innovative.
The lesson: don’t choose technology so that you don’t have to learn more stuff. You always have to learn more stuff.
Here’s the thing. If you are worried about future-proofing your efforts, then the thing to watch isn’t how Ethereum, Fabric, and Corda work today. It’s about the trajectory of their respective roadmaps. Where’s the gravity of the community taking things? You can build more-or-less the same stuff today with IBM Blockchain as you can with Kaleido or Microsoft’s suite of blockchain services. And it is true you can’t easily work across different ledgers with any of them today. But if that’s important to you, consider the natural motives of the different platforms.
While Fabric did surprise me recently with a project called World Wire that can, in a very limited way, send Stellar instructions to run cross-border payments (well played, Jesse Lund!), the Ethereum community is burgeoning with new tools, patterns, and protocols — from on-demand enterprise sidechains and “Layer 2” protocols to movements like OpenLaw and Chainlink — that make deep interop between networks practical, scalable, and secure.
Beyond interop, the thrust of Ethereum core development is about five things, at least four of which businesses care deeply about:
- Decentralization: to allow for a typical consumer laptop to process/validate transactions and help maintain the integrity of the ledger.
- Resilience: to remain live through major network partitions and when very large portions of nodes go offline.
- Security: to utilize crypto and design techniques that allow for a large participation of validators in total and per unit time.
- Simplicity: to minimize complexity, even at the cost of some losses in efficiency.
- Longevity: to select all components such that they are either quantum secure or can be easily swapped out for quantum secure counterparts when available.
(H/T to Exploring Ethereum 2.0 Design Goals, Ben Edgington.)
By contrast, while I haven’t been in charge of the Fabric roadmap for a while, I can say with confidence that simplicity was not, is not, and will never be something that the Fabric team understands or focuses on (beyond liberally repeating the buzzword). They are good at many things, and a few should be nominated for the Turing award, but simplicity — the ability to resist throwing in the kitchen sink and then going next door to rip out the neighbor’s sink to throw on top — is just not in their DNA.
Complexity is the enemy of security. Remember that when something goes wrong with your shiny new consortium network and your private data gets stolen from one of the many attack surfaces in your overly-complicated DLT that lets every party in the network manage a replica of the data. Imagine the fun you’ll have when you discover that the admin of one member’s node wasn’t quite as thorough about security as the others. And if your answer to that problem is to have a trusted cloud provider manage all the nodes for your consortium’s joint venture, then you have to stop and ask yourself why you didn’t just build a nice clean SaaS system in half the time, a quarter of the cost, and twice the security against unauthorized data breaches. (There are, in fact, good reasons to use blockchain today. Read on.)
Real security today is about two things: surveillance resistance and tamper resistance. And this brings us to Gendal’s final mind trick.
If it looks like a duck and quacks like a duck…it might be Richard trying to call an eagle a duck.
Richard’s third assertion is the sketchiest: He concludes that a recent 51% attack on Ethereum Classic (ETC), a relatively small blockchain network that forked from the Ethereum mainnet in 2016, puts the lie to the proposition that Ethereum provides the level of immutability and tamper resistance enterprise ledgers need.
Even under the influence of Richard’s Jedi powers, it is easy to see that ETC is not comparable to the Ethereum mainnet. Many readers brought this up on Twitter. And here’s where Richard Gendals himself. He succumbs to his own mind trick. He argues on Twitter — and I believe his sincerity in those tweets — that a) he stipulated in the article that ETC isn’t the same as the Ethereum mainnet; b) it doesn’t matter that he buried that distinction ‘below the mast’, because he’s pointing out a deeper truth about how Ethereum is not appropriate for securing enterprise systems against the threat of tampering and collusion.
So let’s look at that deeper truth.
First, enterprise instances of Ethereum do not use proof of work, so lest we forget, the exploitation of one small mainnet has no bearing on your choice of protocols for your permissioned network. And if you really want to go advanced on Ethereum permissioned network immediate finality, check out the latest from Pantheon.
Second, a Corda-expert friend points out that because of Corda’s extreme approach to data and business logic segregation, if you wanted to have a single point of truth for some fact across the participants in a Corda network, you’d have to write that functionality from scratch using external oracles.
Third, the ETC case really shows why it’s so important that whatever notary you use for tamper resistance, it needs to be a huge, global, preferrably ASIC resistant network that is proof against centralized control.
Does the Ethereum mainnet fit that bill? Yes. Is it as decentralized as we want it to be in the long-run? Not yet.
Wouldn’t it be nice if companies who are worried about that stepped up and helped make it even more decentralized by running nodes and helping to maintain the integrity of the ledger?
But who cares about decentralization, really? Why should we care? In fact, maybe you shouldn’t care right now. If you run a respected bank, a global enterprise, or a government agency, you might say to yourself, “I can trust me not to do bad things.” If you want to work with a “few close friends” and partners on a “consortium” blockchain, you might be ok with a system that isn’t 99.9999% proof against someone tampering with your data or business rules. You might even like the idea that if you really needed to, you could get together and quietly make a few little edits.
Maybe interop isn’t your thing right now. Maybe you just want to stand up a network with some of your partners, something you know you could have done years ago with technology that was mature in the mid-90s, but blockchain mania is finally getting executives to spend money on cross-company workflows.
In that case, you’re in luck. When we shipped Fabric for the first time, many of us looked at what we had built and said, “Well, I think we just built cross-company BPM” — business process management for consortia. Nothing wrong with that. Older BPM systems used to be focused on single-company operations, so Fabric is an improvement.
The trouble with the cross-company BPM agenda is that companies have to set these networks up between them, orchestrate a lot of governance, get a lot of lawyers into the act, and form what is essentially an extranet. Several of these extranets that have made it into the press are what Richard, in his article, calls “ground-breaking successful enterprise blockchain deployments.” I’d call it business as usual: find a buzzword-compliant technology, do something conventional that you could have done just fine without any new gear, and then announce it breathlessly as an astounding innovation. There’s a lot of money in this racket for companies like IBM and R3. So naturally, the focus is going to be on setting up these walled gardens. This is the trajectory of Fabric and Corda.
I think this “extranets-are-good” mindset is at the heart of why Gendal sees a “deeper truth” behind his claim that Ethereum isn’t the best tool for business. If you want to build extranets to help groups of companies work together a little better, you might be a lot more focused on access controls and surveillance resistance, and you might see true tamper-resistance and immutability, which takes the ability to change things out of your direct control, as a bit of a nuisance. Perhaps you are happy to trade strong global immutability for the convenience and speed of fast finality…if that really were an actual trade-off you have to make. Fair enough.
But if you believe, as I do, that the real paradigm shift beneath all this blockchain buzz is the Internet evolving to handle assets and transactions without relying on centralized parties to manage state, then you have to accept the following:
- No single ledger, no matter how fast and scalable, is capable of, or appropriate for, recording all transactions or running all “on chain” business logic between parties;
- Billions of n-lateral ledgers (bilateral, multilateral) will spring up — ideally on-demand, virtualized, and spread across hosts of independently-run infrastructure — to allow parties to manage confidential, immutable agreements and private transactions;
- The functions on those ledgers (smart contracts, chaincode, etc.) must be able to accept parameters from functions on other ledgers and return parameters to them without running afoul of distributed systems hazards that will become massive as this network-of-stateful-networks grows to Internet scale. This will require either magic fairy dust or a root coordinating ledger and pinning contracts to act as an umpire and confer tamper resistance to sidechains without those ledgers exposing confidential information or even sensitive metadata up to the root chain or to other ledgers.
- Barring us all migrating to a universe where the current laws of physics don’t apply, we are not going to get a tamper-resistant coordinating root chain that is free of central control and also delivers instant (or one-block) finality.
Fortunately on that last one, we don’t really need to have a root coordinating chain that delivers “instant-finality” (“fortunately,” because it wouldn’t be able to scale without handing control of it to some all-powerful third party or small group).
Richard conflates the notions of finality and immutability in his article. But he knows, as any good architect does, that we can get the benefits of one-block or “instant” finality on our sidechains while still using something like an evolved Ethereum mainnet as the root coordinator.
Is there any alternative to the Ethereum mainnet, some network that is more free from the potential for tampering, something more globally distributed or better architected to avoid control by oligarchs? If there is, let me know. We need that to be the root chain of the Internet. Imagine if Fabric or Corda (or, EOS or COSMOS, for that matter) were set up in that role. We would be handing the ultimate point of control to whatever small group controlled their permissioned or quasi-permissioned system.
It’s unfortunate that the blockchain namespace has evolved to call some things sidechains and other things root chains, because really the root chain is the slowest, most limited gear in this watchworks of the stateful Internet I’m describing. It ultimately does one thing…and it’s not trading Cryptokitties.
The root chain just plays umpire and traffic cop. That’s it. And again, you really, really don’t want anything less decentralized than Ethereum (or anything less functionally expressive…otherwise we just could use Bitcoin) as that traffic cop, unless you’re happy wondering whether Dr. Evil has taken control of the world on any given day.
For additional context on the claims around Ethereum mainnet, proof of work, finality and the like, check out this article.
Restoring Balance to the Force
The comforting thing about writing this is that with Richard, he’s listening, eyes wide, really thinking things through. With luck, he will come back with well-considered points that will help bring us together. Maybe he’ll tweet:
“Ah! That’s interesting…so I think what you’re saying is…”
In 2015, Richard and I and many others saw the need to diverge from Ethereum and explore hard problems that we didn’t think the core Ethereum community would prioritize. That was the era of divergence.
But now, 2019 and 2020 need to become a new era of convergence.
Richard said that the arguments of Ethereum proponents were about using Ethereum “rather than” something like Fabric, Sawtooth, or Corda. Those two words are the crux of the problem.
In a stateful Internet, it’s about using Ethereum AND Fabric, Sawtooth, Corda, SAP, Oracle, Chainlink, Tendermint/Cosmos…the list goes on. As long as we have a coordinating root chain like the one I described above, we can have all these other systems,purpose-built for specific jobs, that work together without “enterprise blockchain” becoming a reboot of the balkanized mess we live with today.