Re: Hyperledger Besu Proposal is Live


VIPIN BHARATHAN
 

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.
  • 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.
  • 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. 
  • The comparison of public and private consensus algorithms is interesting and I do agree with many of RGBs points. However for large networks, BFT solutions that support liveness and safety at scale (i.e. where there is a linear  or log not quadratic or higher order relation to N) should be adopted. But what does this have to do with Besu? The fact that it will offer a link between private and public dlts could lead to emergent effects, which none of us can predict at this point.
  • 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.
  • Ursa adoption in Ethereum is being worked on, Virgil has been leading this effort and hopefully Besu will join this effort.
  • 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. 
Best,
Vipin

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant
vip@...


From: tsc@... <tsc@...> on behalf of Jon Geater via Lists.Hyperledger.Org <jon.geater=jitsuin.com@...>
Sent: Sunday, August 25, 2019 10:56 AM
To: vipinsun@... <vipinsun@...>; Silas Davis <silas@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
 
Thanks Vipin, that does bring some clear points to draw the discussion around.  However if you consider the parallel thread about architecture it’s quite possible to see these virtues as vices.

If we want to have pluggable consensus, widespread proper use of Ursa and all those other great things that adoption of the Hyperledger code bases promises then at some point we need to have architectural constraints and adherence throughout all the frameworks and projects.  Early on, the more overlapping co-opetitive projects we add the better: competition drives quality and features and ideas.  But as time goes on and numbers grow it can lead to fragmentation, redundant work, and lower overall progress.  Especially if (as is almost inevitable with multiple projects with different provenance) they have a different idea of where architectural layers should be drawn and where the functional responsibilities of major objects lie.  That’s the path to adapters, proxies and so on, which is in turn a path to potential problems.

I’ve worked at the leading edge of large technology ecosystems for a long time now and something that constantly comes up is that there is ‘good differentiation’, where different offerings provide stability and choice to consumers while competing on niche or value-add offers; and ‘bad differentiation’, where suppliers compromise consumer choice by insisting on being different in layers that should be standardised and enabling.  This is not just about standardizing APIs or protocols: it’s also all around the peripheral stuff: keeping documentation up to date; learning and deploying management systems and administrative functionality; differences in system design assumptions that lead to subtle operational problems; differences in cryptographic design assumptions that lead to subtle security problems; etc.  

I don’t want to seem negative, either towards new proposals in general, or Besu in particular. But to address your first bullet, when you have a mission and a stable of existing projects, ‘technical merit’ is not an absolute, objective, or independent measure.  It’s absolutely right that we discuss the technical fit and feature overlap of new projects with old, including the ‘gymnastic’ aspects, because it might be (as others have noted) that we _should_ accept the new thing but should then also guide older things in different directions so as not to ride too many horses in the same race.

We’re discussing TCF next week.  I won’t write much about that here because it’s such a huge (different) topic.  But imagine trying to write a proper threat analysis or system composition or whatever if everylayer of every one of those stacks had differently opinionated versions of the same concepts.  It would make a great Ph.D. thesis but it won’t catch on.

Again, not against Besu at all.  The mature, stable, battle-hardened aspects you mention are great strengths, we need those.  All I’m trying to say is that we can’t make these decisions in isolation and as Hyperledger we do need to judge proposals against consistent technical principles across all the projects and frameworks, otherwise we’re not a community and force multiplier, we’re just a giant repo.  Whatever the decisions made it wouldn’t be great to see that rationale and the external effects reflected.

Regards

Jon

Jon Geater
Chief Technology Officer, Jitsuin
+44 7500 786537

Join tsc@lists.hyperledger.org to automatically receive all group messages.