This is the first part of an extensive interview with Hyperledger Director Brian Behlendorf in advance of the Hyperledger Global Forum which takes place in Phoenix USA on March 3-6. Register by February 18th to get the discounted rates. This code will provide a 20% discount for individual and corporate, non-member registration: HGFLEDGER20
Highlights
- Hyperledger to serve as a bridge across the spectrum of permissioned to permissionless blockchains
- Hyperledger has a royal flush of different approaches to enterprise blockchain
- Unsure if there’s room for a seventh, but possible consolidation
- Enterprise Ethereum Alliance compared to Hyperledger: standards versus software
- Permissioned networks need to become more decentralized
- Vast majority of transactions will be on permissioned blockchains indefinitely
The journey started with a 2016 visit to Shanghai
Behlendorf: I guess the kind of biggest thing that came in last year was Hyperledger Besu, and one of my first trips as the leader of this project was to China in 2016 to the second Ethereum Devcon in Shanghai. Mainly I wanted to go because I wanted to learn more about Ethereum. And I actually had met Vitalik and Bo Shen when they did their original ICO fundraise for this a year earlier.
But really, I wanted to see what the developer community was like around it and be super sharp about where we were going to position Hyperledger when it came to permissioned versus permissionless blockchains.
Because certainly at the time, and even to a large extent today, the technology worlds behind public and permissioned are very different and very different consensus mechanisms; very different algorithms; communities of developers with very different ideas about use cases and that sort of thing.
A spectrum from permissioned to public
But what became clear to me while there, was that it was eventually going to be more of a spectrum. That as permissioned blockchains got larger, they would probably need to inherit and learn from the experiences and maybe even adopt some of the algorithms that the public ledger communities were starting to pioneer.
Not so much around proof of work. I think there’s still a lot of skepticism in the enterprise space around that, if only for the energy load, that sort of thing. And not so much for the DAO distributed autonomous organization kind of automated robotization of management kind of ideas.
But partly for how do you do these things really at scale? And so I felt it was important to have an olive branch out to that community. And make sure that as the permissioned side of the blockchain world grew in acceptance and deployment, that we could evolve Hyperledger to a point where it could serve as a bridge across the spectrum.
I was still pretty adamant I did not want Hyperledger to be running a main net or a token. I told people that you’ll never see a hyper coin. I still believe that. And thereby avoid the minting money out of thin air kind of thing.
ConsenSys was part of original 2015 Hyperledger cohort
Like I said, it was important to be close to the technology, and that meant being close to ConsenSys. ConsenSys was one of the companies which was in the initial cohort of companies involved with Hyperledger at the announcement in 2015, and they were around for a year. They kind of went off and focused on public blockchains and the ICO market for a while.
But starting about two years ago, they came back around and realized the enterprise space was going to be important to them. And prior to last year, one project came in called Burrow, which was a tiny piece of Ethereum technology, as well as a relationship with the Enterprise Ethereum Alliance.
So when ConsenSys said: “Hey, we’ve been building this alternative stack for Ethereum enterprise technologies that could run both public main net Ethereum, as well as permissioned blockchains, and we’re building it to be Apache licensed,” it felt like ready-made for Hyperledger.
So a lot of diplomacy, (we had) a lot of conversations with engineers about how open source works, but also how Hyperledger’s community works, through a lot of conversations with the existing Hyperledger community leaders. We brought in Besu and had a very frank and public conversation about how all of this should work. And that led to the project being accepted. And now it’s in.
The royal flush of enterprise blockchain approaches
I’m not going to say that we’re done adding new frameworks. But the six that we have now represent a pretty royal flush of all the different kinds of approaches I think you could take to building enterprise blockchains.
Fabric, which is very much like the granddaddy of the project, it just hit 2.0. You saw the announcement of that. It’s still the most widely deployed enterprise blockchain platform out there. Very flexible, very much an operating system, very generalizable.
And then, we’ve got the one focused on identity (Indy). You’ve got the one focused on digital assets, Iroha. The one focused on being a bridge to public and private being Besu. And then Sawtooth which is still a more experimental platform. Those six (including Burrow), I don’t know if there’s room for a seventh, to be honest.
The community will decide
The good news is it’s not up to me. It’s really up to the community.
The community had to be convinced there is room for Besu, as a number six. I would say we might even consider seeing consolidation before we see expansion of that set, but anything’s possible.
It’s hard for me to say that there’s a major missing approach to building distributed ledger now inside Hyperledger.
Another Ethereum link – Hyperledger Avalon
We’ve had a few other projects come in recently, such as Hyperledger Avalon, which is the main other one that I’ll highlight. Avalon is an implementation, actually again it’s Ethereum related because it is implementing a specification that came out of the Enterprise Ethereum Alliance around what they call the Trusted Compute Framework.
It’s a generalizable way of trying to describe privacy on blockchains, whether that’s implemented through secure enclaves, like Intel’s chips or through zero-knowledge systems. And in doing that it might be a way for us to bring that better balance between confidentiality and auditability, which is the whole point of using blockchains anyways. If you want confidential, don’t put it on a blockchain, right?
But what we also want is the ability to, you know, track spending, the ability to track a diamond as it goes through the supply chain without revealing every intermediary’s complete business flows.
So project Avalon is really about moving us further along those lines as a whole community. It’s more of a library. It’s more of a set of concepts and tools right now. But I hope that we’ll start to see the first deployment of that into at least pilot environments this year.
Q: Can you clarify your relationship with the Enterprise Ethereum Alliance (EEA)? Because as an outsider you look like you have more and more overlap.
So I see some pretty sharp distinctions. One is, and this is true in a lot of other technology domains, it’s really, really good to have a standards body in a domain separate from the leading open source project in a domain or from the open source projects in a domain.
The kinds of stakeholders you want to pull together around a standard. The kinds of IP processes you want to manage in the development of a standard. The fact that (for) a standard, once you eventually set it, it (should) not really be changed all that often. So there’s a lot of pressure when you publish it to make sure you’ve gotten it exactly right.
Whereas with software these days, you know, being agile and publishing updates frequently and continuing to refine and add features, that sort of thing is important.
All of these lead to very different collaboration cultures and different organizational structures, even different agreements between the participants. And so we’ve always said that Hyperledger is not a standards body. And it’s important for somebody else out there to be doing that kind of work.
If not the EEA then another standards body
So if the EEA hadn’t come along, I would expect that you would have seen some other type of enterprise blockchain standards alliance come along that perhaps wasn’t directly focused on Ethereum. And obviously, there’s standards efforts at ISO and the identity related standards work and a couple of other works, and all that is completely compatible with Hyperledger.
It’s nice for the development teams at Hyperledger to have the choice of which standards to implement, how quickly, and potentially even come up with new de facto standards that could eventually get proposed upstream to somebody else’s standards body.
So that’s going to be a pretty sharp distinction between us and the EEA. And that’s borne fruit for us in, for example, project Avalon. Hyperledger being able to now take this standard defined elsewhere and build implementations of it. So that’s something that I think is important to keep in mind. And it’s always good to know where the boundaries are in any relationship like this. That’s just kept it very productive.
Q: Do you have any views on the path of some applications moving onto public?
I think it’s inevitable that there will be some applications running on the public ledger networks. DeFi seems to be the kind of thing taking off there. But I think the vast majority of transactions for a generation at least, and I don’t see any reason why this changes after the generation frankly, will take place on permissioned blockchains.
The reasons for that include a blockchain use case will probably define a certain jurisdictional kind of coverage. This blockchain is governed by the laws of country X or GDPR or something like that. And often, those regulations will have some sort of data residency requirements, and privacy requirements that will be really hard to enforce if you don’t have the ability to bind all the different participants with a copy of the dataset to a set of agreements.
Hopefully, you can use smart contracts and others to provide a lot of confidentiality. But you know, if you and I have some sort of business arrangement and you end up with a copy of data, there’s no smart contract in the world that can delete that data out of your hands if I wished it.
There has to be, in many cases, a contractual relationship between parties that describes the use of that data no matter how thoroughly we’ve encrypted it on whatever blockchain we’re using. And so for most participants, most people, they’ll want that kind of agreement bound into the network.
Permissioned but more decentralized
Now the thing that permissioned networks need to do is themselves be more decentralized than many of the ones that you see today. I think, many of these networks that have launched, they’re still somewhat in their early stages, where it makes sense to have one technology partner to help bootstrap to get everyone on board and push it forward.
But my take is, as soon as they’re in production, you should be open to adding nodes to that network, not only from other end users. If it’s a banking network from other banks, that sort of thing if they qualify and are able to sign whatever participation agreement is required. But also from other technology providers, from other cloud providers or from nodes that are hosted by the end users themselves.
I think if you do that, and then I think if you also make it easy for small and midsize businesses to either participate as kind of fully vested citizens on a blockchain, able to submit transactions, review transactions, confirm the validity of transactions. Or do that through an intermediary of some sort, with the choice of who to trust in doing that. If you make it easy for small, midsize businesses to join these blockchains, then that basically erases the advantage of doing some of these things as a public blockchain, which is accessibility.
Accessibility and blurry lines between permissioned and public
Arguably that’s the main reason why advocates of public blockchains for enterprise use cases are advocates. They say it’s because then you don’t have to ask anybody for permission. You just jump on and start engaging. I have no doubt that even enterprise stuff done on public chains will still implement access control, or KYC (know your customer) or some other type of criteria threshold in order to participate.
And so I think this is why I’m saying that the line between permissioned and public will get awfully blurry. I do think that the vast majority of transactions will be taking place on permissioned blockchains indefinitely. Just because that’s an architectural model that most technologists and most companies are going to find more familiar.
