Re: Hyperledger Besu Proposal is Live

Virgil Griffith <virgil@...>

> Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

Sounds reasonable.  Besu has some valuable things to contribute to the Hyperledger ecosystem, but probably the more salient is encouraging the larger sharing between the Ethereum and Hyperledger worlds even outside of Besu.  I see several natural points of contact between Hyperledger and Besu + the larger Ethereum ecosystem:

(1) I can commit to getting Ursa used in as many Ethereum-related projects as possible.  Right now that's not easy because there's no direct way to compile Rust to EVM.  But after Ethereum moves to WebAssembly, this will become possible.  But I will push for this.

(2) It's plausible that Ethereum could contribute to Hyperledger Explorer.  We currently have several opensource blockchain explorers, such as:

I'm not on these block explorer teams, but given the overlap it seems plausible there's some common components so there's less duplicated work in both camps.

(3) It's plausible that Besu and other Ethereum clients (geth, parity, etc) can start contributing to the Caliper tool for improving performance of Ethereum clients.  This also seems a natural point of collaboration.


On Tue, Aug 27, 2019 at 14:11:08, Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <> wrote:
Hi Jon,
Thanks for the thoughtful response.
  • Pluggable consensus has been in active discussion in the Architecture working group. Unfortunately participation in such cross dlt architectural conversations has dropped, at least under the aegis of the AWG. We have had conversations of how to reboot the WGs and you should join the conversation.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.
  • There has been no support to bring "consistent technical principles". Working Groups and other cross-dlt areas where such work should take place are languishing and there are many actively campaigning against WGs. However this again has nothing to do with whether we should approve Besu or not.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.
  • HL is unique in its sheltering  of multiple DLT solutions, there is no comparable consortium and we are inventing the integrative concepts around such co-opetition. I am also an advocate of a full offering (integrating documentation, deployment, operational support, simple and intuitive UIs, adherence to regulation demonstrable with security audits, monitoring and self-healing),  having had some experience importing dlt solutions into highly regulated enterprises. 
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

  • The arrival of new projects into Hyperledger, especially something backed by large networks who are new to Hyperledger will stimulate work in all areas. When there is competition, people will be forced to improve their offerings to stay relevant.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.


  • In short, I am against holding Besu to a different standard than the existing platforms in Hyperledger. Let us be consistent. Getting new blood and new ideas into HL will make a difference in existing dlts as well. The new entrants may revive interest in cross-dlt efforts like the working groups and SIGs. 
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)


Join to automatically receive all group messages.