toggle quoted messageShow quoted text
Thanks Angelo for your thoughtful questions, and Arun for offering your view from a customer perspective, which is extremely helpful in keeping us technology vendors on the right track.
I think Angelo you are touching on a very fundamental point about FireFly's design, the abstraction of the blockchain layer. FireFly relies on blockchain for only the most fundamental problems not solvable with any other technologies, and I expanded on this in my response to your question in the HIP pull request discussion here: https://github.com/hyperledger/hyperledger-hip/pull/3#discussion_r644772585
. This abstraction also allows the pluggability of multiple protocols.
Looking forward to talking more on the TSC call soon.
Thanks David for introducing us to the new Hyperledger Labs project.
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.
On Thu, Jun 3, 2021 at 1:03 PM Angelo De Caro <adc@...
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.
Angelo De Caro
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.
Co-founder, Head of Protocol Engineering