Hyperledger Burrow roadmap to v1.0
Dear fellow marmots,
Hyperledger Burrow sits at the unique intersection of a blockchain node conceived and optimised for business purposes and the Ethereum protocol as the leading smart contract platform. It carries a long history, since 2015 pre-dating Hyperledger itself and performs at a respectable level of well over 100 transactions per second finalized on a global network with full Byzantine Fault Tolerant consensus.
Yet we have not moved Burrow to version 1.0 and that is because we believe the best features are still to come.
1. Firstly, "tooling matters". It is an approach that strongly inspired the Monax platform and a lot of effort went into making it easy to develop Ethereum smart contracts, providing the tooling to compile, deploy and test your smart contracts. As Burrow is introduced into Hyperledger it gives us an opportunity to refocus the tooling requirements on ease of deployment and management of running a permissioned Ethereum chain. A lot of the Ethereum tooling libraries we relied upon previously are GPLv3 licensed and not compatible within the Hyperledger / Apache v2.0 framework. We have already started work on some of the core libraries required for this; and specifically that is the Application Binary Interface (ABI) which defines and converts the data types to the Ethereum specification when formulating transactions. Every cloud has a silver lining; as the blockchain technology matures, the tooling has to evolve with it. The new focus will be on management of chains and production interaction once deployed.
2.a. Secondly, the unique value Hyperledger Burrow brings to the Hyperledger umbrella is the Ethereum protocol implementation. We already have seen the amazing work the Sawtooth team did to implement an Ethereum transaction family on the Sawtooth ledger (see coindesk article here). To support collaborations like this and potentially others, it makes sense to restructure the code slightly, lifting the Ethereum virtual machine (EVM) up as a top-level library that can more cleanly be imported by other ledger projects like Sawtooth. Bringing the EVM up in the stack will help contributions up-to-date. It is important to see the Ethereum protocol as a living and changing specification.
2.b. Secondarily there are specifications outside of the EVM in the blockchain node where we have explicitly made different design choices for the benefit of performance (IAVL tree over a Patricia tree), interoperability with middleware (eg. RPC methods exposing finalisation of consensus), or encoding (we use go-wire encoding, because RLP didn't exist yet when Burrow first saw light of day), that we would like to re-evaluate. While the web3 RPC methods obscure the fact that Burrow can finalise transactions, rather than just returning a transaction id, we see value in implementing web3 RPC to enable smart contract development tooling like Embark or Truffle to work with Burrow. Even more interestingly it gives us a free implementation of the Interledger protocol for Burrow!
With the first point we addresses management of Burrow chains; with the second point we address interaction of Burrow with other systems at a code level; with the third proposal we want to address dynamical interactions of Burrow chains.
3. In designing Burrow we've from the start worked towards a network of many chains running in parallel. This is exemplified eg in that our transaction signatures require a chainId, so that they are only valid on the intended chain. To build the next step on this vision we want to introduce the concept of a parent chain in Burrow. A parent chain can be another (Burrow) permissioned chain, or public Ethereum. The parent chain maintains a genesis contract that allows a new child chain to boot off the parent chain - previously we shipped genesis files around. Introducing this relation allows for horizontal scaling of throughput of the network, or vertical scaling forming a functional tree of chains. When a child chain is running it can report back to the parent chain about the change of validators and their respective stake of voting power. By externalizing the commit root and validator set a child chain inherits the security from its parent chain. This simplifies security management of intricate permissioned networks, or enables projects to run Burrow as an application specific side-chain to public Ethereum. This is another use of InterBockchain Communication (IBC) as introduced by the Cosmos project within Burrow, the first of course, will be the ability to run Burrow as a Cosmos Zone.
Inheriting security from a parent chain, and scaling load over many chains is a good place to get to; probably good enough for meriting v1.0. But what is life without a stretch goal.
4. Hyperledger Burrow is uniquely positioned with the availability of secure native functions to build bridge contracts between the execution of a (Proof-of-Work) parent chain and a Burrow child chain. The ability for a contract on public Ethereum to call into a function on an application-specific Burrow side-chain opens vast opportunities for companies that want to build more performant applications. In return, InterBlockchain Communication messages can be used to return results to the parent chain. This work on bridging Ethereum into side-chains can become a collaboration that benefits multiple projects, and shouldn't be reserved for Hyperledger Burrow.
With this I hope to share with a vision of where we feel this technology can go next. This thread is to welcome input and discussion on these and other points; to detail them further and to flesh them out into tasks.
Hoping to have shared some excitement, and looking forward to the discussion!