In a recent blog post, Brian Behlendorf, executive director of the Hyperledger project, announced that the Hyperledger Technical Steering Committee has approved a proposal, submitted by Monax and Intel, to incubate the first Ethereum derived project called Burrow, a permissionable smart contract machine.
The Burrow project has been an open source project since December 2014 and was previously known as eris-db. On the Hyperledger Burrow GitHub page, the project is described as:
Hyperledger Burrow is a permissioned blockchain node that executes smart contract code following the Ethereum specification. Burrow is built for a multi-chain universe with application specific optimization in mind. Burrow as a node is constructed out of three main components; the consensus engine, the permissioned Ethereum virtual machine and the rpc gateway.
In the past, there has been some perceptions about the Ethereum and Hyperledger communities competing against each other. Behlendorf explains this does not have to be the case:
First, and foremost, having an Ethereum derived project under the Hyperledger umbrella should send a strong message that any positioning of the Hyperledger and Ethereum communities as competitive is incorrect. The blockchain technology community still has many technical challenges to solve, and many different possible approaches to solving them. “Permissioned” and “unpermissioned” represent two ends of a range of options for configuring a distributed ledger, not a binary choice. Choices we can make at the smart contract layer are even more complex. Being able to collaborate on various approaches to these problems is fundamentally important to getting really innovative ideas into production-quality code as quickly as possible.
Since the Burrow project executes smart contract code based upon the Ethereum specification, there are now opportunities for integration with Hyperledger distributed ledger projects. Behlendorf explains:
With an Apache licensed Ethereum Virtual Machine (EVM), other distributed ledger projects in Hyperledger (e.g. Fabric, Sawtooth Lake and Iroha), can now experiment with integrating the EVM into their respective platforms. There is still much work to do to make this happen, of course, but the prospect of this is now much more tangible. This also marks the start of a productive relationship with the broader Ethereum community, including the Enterprise Ethereum Alliance.
Monax Industries was part of the recent Enterprise Ethereum Alliance announcement, and much like Hyperledger, focuses on bringing blockchain technologies to the enterprise. In a recent blog post, Casey Kuhlman, CEO of Monax Industries, describes some of their motivations for also joining the Hyperledger project:
1. Open Source without Participation is Just Showing Off
Our eris:db codebase has been open sourced since 2014, but we have (for all intents and purposes) carried almost the entire load ourselves. We have designed and built the code, its documentation, built example applications, answered questions on various developer forums, along with implementing and manning our own support systems.
However, interest in ethereum style smart contract interpreters within enterprise (long, our bread and butter) has reached a tipping point. Currently, our eris:db codebase has reached a point of interest where our company can no longer respond to the entirety of the demand alone. We now need the community of enterprise smart contract users to assist us in moving this codebase forward.
2. Collaborating is in Our DNA
In the past twelve months we have taken a hard line stance on this with respect to our commercial engagements and we have not been directly involved in the building of a pilot or POC unless it has been a collaborative delivery. In other words, we have consistently partnered to deliver ecosystem application POCs and pilots, even when the end-using customer has balked at our collaborative approach.
Namely, if we as Monax are going to get our software into production in enterprises, then we need to prove not only the technology itself, but also develop the mechanisms to build and deliver that software collaboratively. The old one-to-one approach dominated by account managers walking the halls of incumbent enterprises pitching the IT company’s “new” thing may still work for a lot of technology, but it isn’t likely to work for blockchains and smart contracts.
3. Our Users Need More Expertise Than We Can Solely Provide
We have said it before, and we’ll say it again, but 2017 in the enterprise blockchain applications is about the race to production. And production readiness requires expertise. In order to support production grade applications, we (the “enterprise blockchain” industry) first need to have platforms that can readily support production grade applications for enterprise. And this requires a lot of expertise. Expertise which very few companies on earth wholly have in-house.
