Date
1 - 4 of 4
support for atomic commit of transactions across channels #fabric
Praveen
Hello everyone,
We have a proposal and design for supporting atomic transactions across channels in Fabric. We have created an issue (https://jira.hyperledger.org/browse/FAB-13437) along with the details of the design. We would love to present this in a community call and get feedback from everyone. The design involves minimal changes to Fabric code and mostly to the ledger component, and we have in-house expertise to develop and contribute this to Fabric in 3 months. It also works seamlessly with upcoming features such as token transactions.
Thanks and regards,
Praveen. |
|
Brian Behlendorf <bbehlendorf@...>
Thanks for bringing this here for
feedback.
One thing I noticed reading more
closely is that this isn't just about transactions across channels
in the same Fabric network, but even across different Fabric
networks. That's very cool!
Another part of Hyperledger, Hyperledger
Quilt, has been working along the same lines, as an
implementation of the Interledger Protocol written
in Java. It was originally written by Ripple and NTT Data and is
now supported by Coil, and ILP is somewhat designed for a payments
use case, so it right now just supports XRP and BTC; but we're working
hard now to reboot the project and bring new contributors
and thinking in. If ILP can be made more general purpose than
just payments of cryptocurrencies and apply to transactions of all
sorts, perhaps it could also be looked at as the bridge between
two Fabric networks? I know that's a bigger lift but then we'd
get interop with other ledger networks potentially more easily.
If not, it'd be great to understand what ILP doesn't yet provide
to make this possible.
Brian
On 3/20/19 11:21 AM, Praveen wrote:
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
|
Praveen
Thanks Brian for your comments.
Yes, the building blocks we have suggested can be a stepping stone to support atomic transactions across Fabric networks, as well as with other heterogeneous networks (e.g., Ethereum). One additional challenge to overcome to support atomic transactions across networks (Fabric or other) would be to address identity interoperability, i.e., how do we know that a client identity in one network corresponds to another identity in the second network? We have some thoughts around this, including leveraging Hyperledger Indy, but we have not included that in this proposal. That can be a natural next step.
With regards to Hyperledger Quilt, ILP and HTLA, we have included slides 19-24 in our deck in the Jira issue to call out the differences. HTLA provides a way to connect two clients who want to exchange cryptocurrencies with each other, through one or more intermediaries. The endorsement model in Fabric creates additional challenges to implement HTLA. Since the secret needs to be revealed to endorsers before commit (if you were to follow HTLA and the platform does not provide hash-lock and timeout capabilities), this creates a security risk. We will need some of the capabilities / building blocks we have suggested to even support HTLAs in Fabric. More details with an example is in the slide deck.
That said, after building the capabilities we have proposed, we can extend ILP to work with Fabric and also extend it to work beyond just cryptocurrency exchange.
Thanks and regards,
Praveen.
----- Original message ----- |
|
David Enyeart
The proposal will be reviewed today April 2nd 10:00am US EDT / 14:00 UTC. Hello everyone, We have a proposal and design for supporting atomic transactions across channels in Fabric. We have created an issue (https://jira.hyperledger.org/browse/FAB-13437) along with the details of the design. We would love to present this in a community call and get feedback from everyone. The design involves minimal changes to Fabric code and mostly to the ledger component, and we have in-house expertise to develop and contribute this to Fabric in 3 months. It also works seamlessly with upcoming features such as token transactions. Thanks and regards, Praveen. |
|