Proposed Graduation Requirement for Projects Integrating with DLTs


Danno Ferrin
 

While we are formalizing (or at least enumerating) criteria for admission to incubation I think now is also an appropriate time to start a discussion about graduation requirements for projects that require integraction with a DLT but themselves are not a DLT. This is something I think we should discuss before we vote on admitting firefly.  I expect there will be other projects this impacts in the future and there needs to be some discussion about how previously incubated projects relate to this.

So here's my red herring.  Once we get a feel for what the TSC's opinion on the details are I can make a formal TSC pull request. It may be a bit wordy and we can iterate to strike sections that are superfluous or implied.

---
Requirement: Multi-DLT Relevance and implementation
For a project to graduate that integrates with a Distributed Ledger Technology/Multi-Party System  (DLT/MPS) that is not part of the graduating project at least two such systems need to integrate with the project, and one of them must be a DLT/MPS hosted by the Hyperledger Project.

For a project to be admitted to incubation that integrates with a DLT/MPS the project needs to demonstrate or document how multiple DLTs/MPSs can be supported by the architecture. Actual implementation of such integration is not required for incubation, but will be required for graduation.

The software integration will be what is required, not the deployed system. i.e. Hyperledger Fabric and Hyperledger Besu, would be two valid integrations but not Ethereum Mainnet and Ethereum Classic, as those are just two instances supported by the same project.

This does not apply to projects themselves that are DLTs/MPSs, or projects that may appear in build toolstreams but don't directly integrate with a DLT/MPS (such as a solidity compiler). The integration can be done either in the project itself or the DLT/MPS can make changes to directly integrate with the project, i.e. it doesn't matter which project "plugs into" the other.  Such integrations need to exist in released software at the time the graduation requirement is fulfilled.
---

Projects that would count as the "one Hyperledger DLT/MPS"
Besu, Burrow, Fabric, Indy, Iroha, Sawtooth

Previously admitted projects this might apply to
Avalon, Cactus, Caliper, Cello, Composer, Explorer, Grid, Quilt, Transact

Previously admitted projects that aren't DLTs this would _not_ apply to:
Aries, Ursa

Aries graduated, so this change could not apply to them anyway even though it wouldn't.  Some projects already have multiple integrations, with Caliper integrating the most.

Something to think about as we formalize the incubation expectations.

--Danno


VIPIN BHARATHAN
 

Danno,

You are well-intentioned, thanks for the time you took to think carefully about this. These proposed rules for incubation/graduation are normative and like all such rules do not account for the variability of the wild.
Case in point: Aries- Aries is a transformative project, which would not graduate if these rules were strictly followed (as you yourself say). 

The lesser number of rules there are, the better- Each project deserves to be evaluated individually. From all I can see Firefly is a worthy project (I have read the HIP in detail), it has diversity of committers, it seems technologically visionary, the HIP is detailed, and it makes sense, at least in this stage of the evolution of Blockchain projects- the fact that it has existing codebase is very similar to the situation with Besu. Firefly is impressive, it would be a mistake not to incubate it. Similar rejection of Hedera three or four years ago made sense to me then, but in retrospect it was a mistake. That was based on a rule that the project had to be a Blockchain and the fact that it did not have a well-written paper backing the technical details. Hedera hashgraph is a well known project now and should have been part of HL.

The debate about community-(i.e. the diversity of the committers), whether or not a project should be incubated etc. based on several criteria raged on from the inception of the HL back in 2015-16. As the original author of the HIP template I wrestled with this quite a bit. My choice was to pare down the normative criteria/rules.  

Thanks

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of Danno Ferrin via lists.hyperledger.org <danno.ferrin=gmail.com@...>
Sent: Monday, June 7, 2021 8:11 PM
To: Hyperledger TSC <tsc@...>
Subject: [Hyperledger TSC] Proposed Graduation Requirement for Projects Integrating with DLTs
 
While we are formalizing (or at least enumerating) criteria for admission to incubation I think now is also an appropriate time to start a discussion about graduation requirements for projects that require integraction with a DLT but themselves are not a DLT. This is something I think we should discuss before we vote on admitting firefly.  I expect there will be other projects this impacts in the future and there needs to be some discussion about how previously incubated projects relate to this.

So here's my red herring.  Once we get a feel for what the TSC's opinion on the details are I can make a formal TSC pull request. It may be a bit wordy and we can iterate to strike sections that are superfluous or implied.

---
Requirement: Multi-DLT Relevance and implementation
For a project to graduate that integrates with a Distributed Ledger Technology/Multi-Party System  (DLT/MPS) that is not part of the graduating project at least two such systems need to integrate with the project, and one of them must be a DLT/MPS hosted by the Hyperledger Project.

For a project to be admitted to incubation that integrates with a DLT/MPS the project needs to demonstrate or document how multiple DLTs/MPSs can be supported by the architecture. Actual implementation of such integration is not required for incubation, but will be required for graduation.

The software integration will be what is required, not the deployed system. i.e. Hyperledger Fabric and Hyperledger Besu, would be two valid integrations but not Ethereum Mainnet and Ethereum Classic, as those are just two instances supported by the same project.

This does not apply to projects themselves that are DLTs/MPSs, or projects that may appear in build toolstreams but don't directly integrate with a DLT/MPS (such as a solidity compiler). The integration can be done either in the project itself or the DLT/MPS can make changes to directly integrate with the project, i.e. it doesn't matter which project "plugs into" the other.  Such integrations need to exist in released software at the time the graduation requirement is fulfilled.
---

Projects that would count as the "one Hyperledger DLT/MPS"
Besu, Burrow, Fabric, Indy, Iroha, Sawtooth

Previously admitted projects this might apply to
Avalon, Cactus, Caliper, Cello, Composer, Explorer, Grid, Quilt, Transact

Previously admitted projects that aren't DLTs this would _not_ apply to:
Aries, Ursa

Aries graduated, so this change could not apply to them anyway even though it wouldn't.  Some projects already have multiple integrations, with Caliper integrating the most.

Something to think about as we formalize the incubation expectations.

--Danno


Angelo De Caro
 

My two cents:

If the prosed project claims to be Multi-DLT, then I would expect integration with at least two DLTs in the Hyperledger ecosystem that are not based on the same technology (Besu and Burrow are both Ethereum-based, they count as one). 

./angelo


Danno Ferrin
 

I think you paint with too broad a brush: the only technology burrow and besu share are that they can run EVM contracts, and in that sense they don't even run them identically.  Based on that standard it can be claimed that Fabric and Burrow are the same. That's about the same as calling Postgres and Maria as the same because they both use SQL. and store data in tables.

Past that surface similarity deeper technological differences arise.  Burrow only supports proof of stake for consensus. Besu doesn't have proof of stake consensus, but proof of work and BFT (also called proof of authority). Burrow can run WASM, Besu doesn't. Besu supports multiple Ethereum public networks, Burrow supports none. They don't even share the same wire protocol.

On Tue, Jun 8, 2021 at 4:21 AM Angelo De Caro <adc@...> wrote:
My two cents:

If the prosed project claims to be Multi-DLT, then I would expect integration with at least two DLTs in the Hyperledger ecosystem that are not based on the same technology (Besu and Burrow are both Ethereum-based, they count as one). 

./angelo


Angelo De Caro
 

Let me disagree here. Borrow and Besu use the Order-Execute paradigm. Fabric uses the Execute-Order-Validate paradigm. This is the most fundamental difference between these DLTs.


Danno Ferrin
 

One thing I didn't add because my proposal was already too long is the fate of projects that are single-dlt and how to handle them.  I think we already have a process where they are folded into their parent projects as sub projects.  This includes new projects that would be propsed, the TSC decision could be to be added to a certain project as a sub-project (assuming the project will accept it). Examples (drawn from past project proposals https://wiki.hyperledger.org/display/TSC/Project+Proposals):

Justina, Fabric Go SDK, Fabric Python SDK, chaintool, Java Chaincode support for Hyperledger Fabric, Exerciser for the Hyperledger Fabric v0.2, Fabric Desktop,

Most of these are from the very early days of hyperledger and these were all folded into fabric.  Explorer looks like it was initially proposed as just Fabric explorer, so I would expect sub projects can gain top level status by growing to multiple DLT/MPSs

The open question would be how to handle a single DLT project proposal for a non-hyperledger DLT.  For example, something for Corda, Polkadot, Hedera, or Cosmos. It may not be worth spending cycles on however because I don't see the advantage of such a project looking for a home in Hyperledger as most of those have their own foundations and divergent communities.

On Mon, Jun 7, 2021 at 6:11 PM Danno Ferrin <danno.ferrin@...> wrote:
While we are formalizing (or at least enumerating) criteria for admission to incubation I think now is also an appropriate time to start a discussion about graduation requirements for projects that require integraction with a DLT but themselves are not a DLT. This is something I think we should discuss before we vote on admitting firefly.  I expect there will be other projects this impacts in the future and there needs to be some discussion about how previously incubated projects relate to this.

So here's my red herring.  Once we get a feel for what the TSC's opinion on the details are I can make a formal TSC pull request. It may be a bit wordy and we can iterate to strike sections that are superfluous or implied.

---
Requirement: Multi-DLT Relevance and implementation
For a project to graduate that integrates with a Distributed Ledger Technology/Multi-Party System  (DLT/MPS) that is not part of the graduating project at least two such systems need to integrate with the project, and one of them must be a DLT/MPS hosted by the Hyperledger Project.

For a project to be admitted to incubation that integrates with a DLT/MPS the project needs to demonstrate or document how multiple DLTs/MPSs can be supported by the architecture. Actual implementation of such integration is not required for incubation, but will be required for graduation.

The software integration will be what is required, not the deployed system. i.e. Hyperledger Fabric and Hyperledger Besu, would be two valid integrations but not Ethereum Mainnet and Ethereum Classic, as those are just two instances supported by the same project.

This does not apply to projects themselves that are DLTs/MPSs, or projects that may appear in build toolstreams but don't directly integrate with a DLT/MPS (such as a solidity compiler). The integration can be done either in the project itself or the DLT/MPS can make changes to directly integrate with the project, i.e. it doesn't matter which project "plugs into" the other.  Such integrations need to exist in released software at the time the graduation requirement is fulfilled.
---

Projects that would count as the "one Hyperledger DLT/MPS"
Besu, Burrow, Fabric, Indy, Iroha, Sawtooth

Previously admitted projects this might apply to
Avalon, Cactus, Caliper, Cello, Composer, Explorer, Grid, Quilt, Transact

Previously admitted projects that aren't DLTs this would _not_ apply to:
Aries, Ursa

Aries graduated, so this change could not apply to them anyway even though it wouldn't.  Some projects already have multiple integrations, with Caliper integrating the most.

Something to think about as we formalize the incubation expectations.

--Danno