Thanks for the thoughtful response.
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.
Chief Technology Officer, Jitsuin
+44 7500 786537