Re: support for atomic commit of transactions across channels #fabric
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 ----- |
|