Thanks everyone for providing input for my presentation. It was a bit crazy to try and say at least one thing about every single project and WG plus some but the feedback I received was good. I hope this gave attendees a good idea of the breadth of what's going on within Hyperledger and the desire to find out more about whatever piqued their interest.

I was so wired after my presentation that it took me a while to get back to normal speed but it was fun. :-)

Cheers.
--
Arnaud  Le Hors - Senior Technical Staff Member - Open Technologies: Blockchain, Edge Computing, Web - IBM



From:        "Arnaud Le Hors" <lehors@...>
To:        "Hyperledger Maintainers" <maintainers@...>
Date:        05/26/2021 07:42 AM
Subject:        [EXTERNAL] [Hyperledger Maintainers] TSC update at the Global Forum
Sent by:        maintainers@...

---

Hi all, I'll have the opportunity to give an update at the upcoming Global Forum and I'm considering highlighting one major aspect of each project. What is the major development you would like me to highlight about your project that took place ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
Hi all,

I'll have the opportunity to give an update at the upcoming Global Forum and I'm considering highlighting one major aspect of each project. What is the major development you would like me to highlight about your project that took place over the last year or that you are working on?

Note that I have limited time and can't get into any details so all I'm asking is for a bullet or two. My hope is to give people an appetite for finding out more in the follow up sessions.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member - Open Technologies: Blockchain, Edge Computing, Web - IBM

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

My two cents:

An important criteria for me is the design. If the design is complete, sound, and, possibly, already peer reviewed, then even if the code is not complete I'm good with it.

In the case of Firefly, the token design is missing. The token ecosystem is crucial to the applications mentioned. The design must be completed also to make sure that anyone who wants to plug a new DLT knows which are the requirements.

./angelo

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

Hi all,

The project lifecycle document at https://github.com/hyperledger/tsc which is published here:

https://tsc.hyperledger.org/project-lifecycle.html

Pull requests might be a good way to suggest edits, though every TSC member can edit that as well.

On 6/6/21 3:08 PM, Hart Montgomery wrote:

Even if there are not "hard and fast" guidelines, an explanation of things that are likely to make people favor a proposal versus things that are likely to get a proposal rejected would be immensely useful.  For instance, even though it appears to have never been written down anywhere, it has always been an unstated rule that projects without maintainers from at least two distinct companies are not approved.  We've never approved a project without contributions from two different entities, but we've also never put this down on paper either.  So just explaining stuff like this would be very useful.

And that's something we've always advised inbound projects. That was the case here - the proposal specifically mentioned that there was a contributor from Atato and another from Consensys Health "committed to contributing as of this proposal" and I believe would have been part of the initial set of maintainers on the repo. I think that got lost in the conversation as someone who was simply being supportive or was slapped on at the last minute, but the developer from Atato was there on v0.2 of the proposal and had worked with the code before.

I would also suggest that we add text encouraging project proposers to ask individual TSC members for feedback before sending the proposal to the whole group. 

This was also done with a majority of the TSC members, which was very helpful to the proposal, actually. Some signed on as co-sponsors as a result. Some with whom the proposal was shared, though, didn't engage until the very end. It's OK, people get busy.

David wrote:

As a new TSC member who didn't have the benefit of precedent with respect to project proposal evaluations, it was a difficult decision for me whether to speak my mind or not when the process was moving faster than I was comfortable with given a number of unknowns. I've been trying to think about what might have improved the experience for all. I liked Hart's suggestion in RocketChat about project incubation guidelines. For example, for projects that have not been open source previously, perhaps they should be required to start as a lab for a short time so that they can contribute their code in a welcoming environment and get familiar with open source licenses and processes prior to the public scrutiny of a project proposal evaluation.

That has typically been what the Incubation status has been for: https://tsc.hyperledger.org/project-incubation-exit.html

It's one reason we caution projects that have not been open source to not even propose to come in as an Active Status project because that's a pretty high bar. Besu wanted to be Active upon acceptance and had an arguable case to be one, but it was the right thing to not award that out of the chute.

Labs was not started to be the pre-Incubation incubator. It was started as the place for projects that were still finding their footing as a product - perhaps they were just a library, an experiment or hackathon result, an add-on or way of configuring some other project, something presented humbly and not really seeking to build a larger community from the get-go but to get something out there. Labs is also useful for something an exiting HL project comes up with that could be, or is even intended to be, used well beyond that project, which is why I'm guessing there's been some good Fabric components landing there recently. The fact that there have been some Labs which have found each other, combined, and gone on to become projects like Cactus, shouldn't be interpreted as this being either a requirement for a project or a goal of the Labs. Firefly didn't seem to be anything like the other things in Labs, and seemed to be a lot more mature (and in wider production use) than many of the things accepted as a Project over the years.

Brian

-- 
Brian Behlendorf
General Manager for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf

Thanks David for introducing us to the new Hyperledger Labs project.

I wasn't aware about this, it appears to be proposed about a week back https://github.com/hyperledger-labs/hyperledger-labs.github.io/pull/169

Here are my views,

This is a great project. A ready to use blockchain client (Hyperledger Fabric in this case) such as these can save time in HL Fabric adoption. This will benefit many of the end user organizations who otherwise end up spending resources on re-doing common patterns. In addition, this project will also encourage in designing business flows better, through smart contract governance.

However, I am not clear on the design, how it will extend to other protocols? Will it be a smart client per protocol or will it make use of the SDK approach through one smart client for different protocols? Speaking from an adoption point of view, a flexibility to switch between protocols or having one enterprise integration point for multiple protocols underneath is highly beneficial.

Firefly follows the microservice based architecture to solve challenges up the stack. HL Fabric has the concept of channels and private data collections, which are useful in many ways. But implementing a similar solution on Ethereum/Sawtooth etc is not straightforward. Firefly proposes an abstract term MPC, how it is achieved in an application is left to the implementation. An organization can merely make use of Firefly for high availability, use a MQ for data exchange, and have nothing to do with blockchain at all. One of the use cases mentioned in the proposal is to guarantee the provenance through the blockchain. I could not find a complex use case/example with custom smart contract logic. But the discussion so far I had, gives an impression that application designers have to rely on events streamlined at multiple connecting points to make additional decisions. However, these are done through APIs through application designer's preferred auth mechanism instead of making them through blockchain clients. Kind of abstraction.

In the proposal Firefly promises to add support on HL Fabric, and efforts are underway. It will help if FSC can be a means of integrating HL Fabric into Firefly. I am interested to learn more about FSC in the call, and understand if it can be a Firefly connector for HL Fabric. Another point to consider is if we are opening up Hyperledger for projects that span across an application stack upwards blockchain protocol. This was a hot topic in the member summit at least.

Regards,

Arun

On Thu, Jun 3, 2021 at 1:03 PM Angelo De Caro <adc@...> wrote:

Dear Jim,

Thanks for your technical points. I love this discussion.
Indeed, let me add to the conversation another point of view as a TSC member.

I want to start with this statement: Pluggability is as good as the abstraction behind it.
In other words, pluggability per se does not tell us anything. 
It is the abstraction that gives us confidence in the ability to support different implementations.
For example, in theory Fabric has also many pluggability points but in practice it is very hard.

The FireFly proposal does not tell us what's the abstraction used for the Blockchain, for example:
- Is the blockchain used just as time-stamping service?
- What about tokens? Does the abstraction cover both account-based and UTXO? What about privacy?
- The FireFly proposal mentions only Ethereum, Fabric (in design phase, if I understand correctly), and Corda (https://github.com/kaleido-io/firefly-cordaconnect is ~700 lines of Java code). What about Sawtooth and Iroha, for example? I ask cause the Firefly proposal says that it is an "umbrella project".

So, if I understand correctly, and I might be wrong, Firefly seems to be, at the current stage, mono blockchain (Ethereum).
The proposal does not give evidences that other blockchains can be plugged. Which means that given an application developed 
with Firefly, the blockchain can be swapped without changing the application itself (which is a great goal, by the way, if it were realizable).

The same considerations apply to all the pluggability points: Consensus, Zero Knowledge, MPC, all those named.
What's the abstraction that Firefly proposes? 

I think it is important to talk about the above technical points :)

Looking forward for additional discussions.

Thanks much, Jim.

Best,
Angelo De Caro
TSC Member

P.S.: A small comment on the Fabric Smart Client. The philosophy used there is the following: Let's use each blockchain at its maximal potential!
This is because the various DLT platforms are evolving very fast and they are also kind of becoming more specialised. It seems then reasonable to select them based on the functionality they deliver best and then use interoperability protocols to make the DLTs speak to each other. The most proximate gaol of the Fabric Smart Client is to deliver the best possible experience when using Hyperledger Fabric.