Bank executives today who want to stay abreast of new technologies are compelled to wade through a swamp of buzzwords, none buzzier than "blockchain."
Such is the proliferation of projects—public, permissionless blockchains such as Ethereum's, which anyone can use, alongside private, "permissioned" blockchains such as R3's Corda—and competing schools of thought, each with its loud partisans competing for mindshare at conferences and on social media, that one could be forgiven for feeling lost.
Worse, it can seem as if the word "blockchain" itself risks becoming little more than fairy dust for big corporations to sprinkle on tired old processes to make them sound new and fresh.
Brian Behlendorf, executive director of the Hyperledger Project, which seeks to establish common standards for blockchain technology, isn't concerned. Blockchain projects are evolving rapidly—dozens of companies are now using the distributed ledger network Corda, for instance—and, for now, Behlendorf would rather see a thousand flowers bloom than try to reap the harvest too early.
Hyperledger is distinct in being embedded within the nonprofit Linux Foundation, which has about 1,000 corporate members. Hyperledger itself has about 170 direct partners, including IBM and the
American Banker recently spoke with Behlendorf to learn more about what sets Hyperledger apart, what he thinks success would entail and how the consortium's efforts to roll out production-ready software are going. The following has been edited for length and clarity.
How is Hyperledger different from the other consortia and coalitions that are out there today?
BRIAN BEHLENDORF: We're a part of the Linux Foundation, which has been around for 15 years, acting as the nexus point for development of the Linux operating system, providing governance for both developers and vendors—everybody from the phone markers, to Dell and HP and Oracle and IBM, to people who put it in cars now. The model was: Be a consortium, take funding from these companies in the form of memberships and then fund all the things that enterprises need from a software initiative except for writing the code, because you depend upon the developers in the open source community to write the code. And they'll show up—some of them from those vendors, but some of them from other places in the public. If there's a 15-year-old kid with a good idea and clear communication skills who can work on a team, he should be able to contribute, all the way up to being a core member of the project.
Hyperledger came about when people were saying this model seems to work and it seems to be replicable, and it could solve what seemed to be a problem, especially at that time, in the bitcoin community, where you had the developers at war with each other, the vendors at war with each other.
How do you see Hyperledger in relation to bitcoin and other cryptocurrencies?
In 1969, we went to the moon. We put Americans in a capsule and landed and brought them home. Great. We didn't end up doing much there, because as it turns out, there's not really a lot commercially you can do on the moon, but the fact that we got rockets that could put big, big systems into space meant we could put things into orbit—and you put a camera up there, you put a radio antenna up there, you put all sorts of things in space and suddenly you have a lot of commercial activity. If Ethereum and bitcoin are the moonshot, we're the rocket ship that makes this commercially usable for lots and lots of other activities that might not have been anticipated when your goal was "Get to the moon."
So that's the metaphor. There were lots and lots of ideas, lots of people throwing out proofs of concept and interesting technology, and even companies like IBM and Intel and JPMorgan [Chase] were starting to do their own internal blockchain efforts, but every one of them was hearing, "If we're going to move to something like this, it can't just be you. It can't just be an IBM technology or an Intel technology. It has to be something that's an open standard and open source software," as the Linux Foundation does it best, which is as a multivendor, multistakeholder thing.
One of the first real principles was that there isn't just one way to do [distributed ledger technology]. Because it was pretty clear that [IBM's] Fabric was an interesting technology, an interesting take on consensus and smart contracts—very different from bitcoin and Ethereum, very much focused on permissioned ledgers, where pretty much everything is different from the unpermissioned ones. You're just starting from a different set of assumptions about who's on your network and what their intentions are, and all that. That simplifies the problem in some pretty interesting ways and gives you more flexibility in others. Fabric was one take on that, but Intel had a different take with Sawtooth Lake.
When did the development of Fabric and Sawtooth Lake begin, and why is Hyperledger supporting both?
The announcement [of Hyperledger] was December 2015. The first public code release of both Fabric and Sawtooth was in February [2016]. When I showed up [a few months later], there were those two. Now, these were still early-stage, but they were different enough in architecture and implementation language and everything that it didn't make sense to try to force them together. It made sense to say, "Let's let them both play out according to their own road map, and we'll figure it out later whether it makes sense to merge them into one." We said, "Rather than forcing a top-down architecture, let's let this be organic and bottom-up, and let's go see who else has interesting ideas."
What is the Hyperledger ecosystem like today?
We're up to nine different projects, and they don't all directly compete or directly overlap. There are big differences between Fabric and Sawtooth, but you could still choose one or the other at this point. Down the road, it could be the case that one becomes additive to the other, but we're leaving that up to the developers to decide and for the market, frankly, to tell us. Meanwhile, we have one project that is a developer tool that lets you define what you want to build at a high level and then it goes and builds your smart-contract code for you. It's called Composer, and it's a way of cutting the development time tremendously. We have another, Burrow, that's actually a bridge to the Ethereum community, because it's an implementation of something called the Ethereum Virtual Machine, which is what runs Ethereum contracts written in [the programming language] Solidity.
There are a lot of people who try to paint a Hyperledger-versus-Ethereum picture, but that is really not the case. It's kind of like saying Netscape versus the web. Ethereum is one collection of technologies, one way to do it; the most distinctive thing about Ethereum—putting aside the cryptocurrency, because we've tried actually to not be about the cryptocurrency side of this world—is its smart-contract language. So we have Burrow, and a bunch of other projects, and they're based on this premise that we're not going to have just one big blockchain. It's not going to look like the internet, with one big internet. It's actually going to be lots of different networks, lots of different ledgers, with different degrees of public versus private, different degrees of permission—who's allowed to join and what are the terms for joining—because that's how the business world works, by having consortia.
What does success look like for Hyperledger?
Whenever someone wants to get something done today with an existing use case, where it's clear that a distributed ledger not only helps reinvent how a given network works but also gives us a whole bunch of capability we didn't have before, cuts a lot of costs, cuts a lot of fraud out of the system—success for us is that the first tool they turn to, the default tool, would be something from Hyperledger.org.
And even as we add new projects, those new projects will complement the existing projects. I don't measure us by the number of projects. I measure us by whether we're building a really rich collection of tools and frameworks and building blocks for being able to build these new kinds of systems. And are we helping it to be boring? Can we make this like the plumbing in a business? Businesses don't compete with each other on the quality of their plumbing, but they know that they need it—and they'll pay somebody to come in and install plumbing, or fix it if it breaks. … But it's about building the infrastructure so that everyone can build competing projects and services on top.
So you don't see this project as having a defined endpoint?
I certainly see this as a 25-year or a 50-year kind of project. That's why we're in no rush to declare one toolkit or one platform the winner. We'll figure this out over time. The most important thing to do right now is to have enough projects that really cover the total possible terrain of solutions, and then let Darwin come in. Let the asteroid come at some point in the future. Let the winnowing happen later.
That said, have any production-ready applications using Hyperledger software been launched this year? Or will any launch by the end of 2017?
Yeah, there are 10 or so that have been publicly announced, but there a lot of others that haven't yet. There are different production installations of Fabric out there; a few of Sawtooth emerging as well, though I don't know if any of them are exactly production-quality, they might be late-stage pilots, but there's a bond-issuance chain that Northern Trust has set up, with five or six partners, including the regulators, basically issuing paper and tracking it. Not settling, not paying for it out of that chain, but using it to simplify all of the paperwork that otherwise is normally involved in that.
If Hyperledger's goal is interoperability between blockchains, don't you at some point have to build something that can integrate Fabric and Sawtooth?
We're going to find out over time what it really means, where the useful points of unification are. It's really important not to overstandardize and really to let the market guide you.
Hyperledger Burrow will let you take smart contracts that you've written for the public Ethereum chain and run them on a private ledger with basically no modification. We've seen a group get that running on top of Sawtooth, and there's work going on now to get it running on top of Fabric. So it might be that we have portability between smart contracts and distributed ledger technologies. I think at the end of the day, what happens is, you say, "OK, I want to choose Fabric as my DLT, and I want to be able to use JavaScript as my smart-contract language." There should be enough modularity and enough really good [application programming interface] engineering to make that possible, to allow an independent choice—just like you can choose independently today what database you want to have backing your mobile app.
So you don't think the future lies in everybody learning how to program in [Ethereum's smart-contract language] Solidity, say?
No, for sure not. I can understand organizations looking at this and going, "Agh, this is a mess! Where do I start?" But the reality is, most of the time a company is spending on launching a proof of concept or a pilot or even taking something to production, they're not spending it down on writing actual smart-contract code, because smart-contract code itself is actually pretty simple. Most of your time is going to be spent writing the end-user interface, redefining your business workflow, understanding what your requirements are for your use case. And all of that will be portable even if the technology underneath ends up changing substantially from one year to the next. We're still at an early-enough stage here that people should not freak out about having those options; they should actually see it as the kind of freedom that we need right now to figure it all out.
