Re: Hyperledger Besu Proposal is Live

Silas Davis

Hello list,

Others will be aware that as a maintainer of Hyperledger Burrow - 'the Ethereum project' of Hyperledger - that we are likely to be most affected by the accession of Pantheon/Besu into Hyperledger.

I have had several weeks to reflect on this and talk with various people including meeting with some of the PegaSys team. I believe that on balance the benefits of Pantheon joining Hyperledger outweigh the costs.

The first category of costs and benefits, which are closest to my heart, are those relating to Burrow. Ultimately I think the costs of a technically energetic and competent project joining Hyperledger and competing (or out-competing) an existing project do not in principle justify rejecting such a project. That would be a form of protectionism and ultimately counterproductive. In any case I will enumerate the costs to Burrow as I see them:

1. Ethereum users coming to Hyperledger are unlikely to choose Burrow over Besu - Besu is a drop-in mainnet replacement and Burrow is not. We have a number of minor to medium differences the prevent this - RPC layer, signing, serialisation, p2p layer, consensus layer.

2. So far there has not been sufficient community interest to resolve the issues above. I see no reason to believe that is likely to change soon. However I do think it is _even less likely_ once Besu were to join. And it is reasonable to imagine that Besu will reduce the big end of our contributor funnel (though see my coda on this below)

3. Burrow has so far not implemented the EEA client spec - and is unlikely to in monolithic form. Besu being validated by being in Hyperledger and EEA client spec compliant pressures the space for projects that do things differently (this is a both a good thing in terms of longer term standardisation and a bad thing in terms of innovation).

The benefits to Burrow:

1. This has provided something of a kick up the arse to the Burrow project to do a bit of a better job and describing what we have _outside_ of including an 'EVM' implementation. We are also a bridge to Tendermint/Cosmos, have an innovative state mechanism, a Solidity/SQL mapping layer, and experimental WASM support over the Ethereum account model. As I have mentioned in our previous quarterly report work is underway to do this (start here: plus we have a blog post coming, plus more docs on core features.

2. Having spoken with members of the PegaSys protocol team we think there might be some fruitful space for us to explore with building a two-way peg between Pantheon and Burrow terminated by Solidity contracts (our lingua franca) - shipping state between the two and providing access to Burrow as a sidechain (including Monax's own Agreements Network, and the wider Cosmos ecosystem in time) from Ethereum and public Ethereum to Burrow for value transfer. This is still a WIP, but there may be something, and we might be able to do something simple that works before the loftier interchain proposals are fully baked.

Moving on to the substance of the proposal I think Pantheon would bring the following benefits to Hyperledger:

1. An EEA client spec compliant eth client, that may help Hyperledger capture Ethereum-land people in a way that Burrow has not be able to.

2. The above but Apache 2 licensed - obvious given our requirements - but this is the core differentiator between Geth, Parity, and Quorum.

3. A high quality codebase - having browsed PRs, issues, and code on Github - _despite_ being written in Java...

4. A rebalancing of Hyperledger towards public and public-permissioned use cases and frameworks - there is an ambivalence towards 'layer 1' that I find surprising

5. The resources of one of the largest blockchain organisations

The downsides being:

1. Fragmentation in terms of languages and tooling - I think this is legitimate, but also a partially solved problem with GRPC, thrift, etc that blur linkable library with micro-service. Sometimes you do want to share code though and that gets worth the more languages we support.

2. Fragmentation in terms of community - this is more severe and I do not know if that would be the effect. Convergence is a slippery term - but I would not like to see us develop a 'public chain people'/'private chain people' divide. To some extent a project like Pantheon is meant to bridge this.

3. The Ethereum community has some engineering peccadilloes that we may not want to inherit, such as Not Invented Here syndrome, need to put everything in 256 bits, sometimes overly grandiose approaches to things. Avoiding 2 above could be good for both communities.

4. 'Besu' would lexicographically sort above all other frameworks - a huge incursion into 'Burrow's domain

Ultimately Pantheon will continue to exist inside or outside Hyperledger. Ethereum is far from perfect, but is has the very strong advantage of being the second most capitalised permissionless blockchain with a smart contract model sufficient for doing interesting things. I think Hyperledger should embrace integrating with that ecosystem, while eschewing being dominated by it.


On Thu, 8 Aug 2019 at 19:23, <grace.hartley@...> wrote:

Hi All,

We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 

We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team

Joseph Lubin, ConsenSys, joseph.lubin@...
Daniel Heyman, ConsenSys/ PegSys, daniel.heyman@...
Rob Dawson, ConsenSys/ PegaSys, rob.dawson@...
Grace Hartley, ConsenSys/PegaSys, grace.hartley@...
Danno Ferrin, ConsenSys/PegaSys, danno.ferrin@...

Join to automatically receive all group messages.