Re: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (13 April 2021)

[Thomas Hardjono <[e-mail]>]

Thanks Luke,

Much appreciate the time & effort in making the slides and presenting.


-- thomas --


________________________________________
From: Luke Riley [[e-mail]]
Sent: Wednesday, April 14, 2021 10:19 AM
To: Thomas Hardjono; [e-mail]
Subject: Re: Summary Notes from IETF Blockchain Gateway Interop meeting (13 April 2021)

Hi all,

Many thanks Thomas for the notes. I've added a few more comments in red below for extra clarifications.

Regards,

Luke

________________________________
From: Blockchain-interop <[e-mail]> on behalf of Thomas Hardjono <[e-mail]>
Sent: 14 April 2021 14:53
To: [e-mail] <[e-mail]>
Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (13 April 2021)

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.


Summary Notes from IETF Blockchain Gateway Interoperability group meeting

Date: Tuesday 13 April, 2021

(a) Attendees

Denis Avrilionis
John Robotham
Luke Riley
Martin Hargreaves
Mizan Chowdhury
Rafael Belchior
Mike McBride
Gilbert Verdian
Thomas Hardjono


(b) IETF Note Well slide

-- This group meeting operates under IETF IP Rules as described in RFC5378 and RFC8179.


(c) Administrative notes:

-- Given that the majority of the regular attendees and draft contributors are based in the Northern Hemisphere, the group may consider having the APAC meetings every 3rd or 4th meeting.


(d) Escrow Types and Interfaces (Luke Riley):

-- Slides from Luke are available on the GitHub repo: https://github.com/CxSci/blockchain-gateway/blob/main/docs/slides/EscrowTypes.pdf

-- The question of escrow relates to several aspects of the asset transfer from the Originator Alice on blockchain/DLT B1 (via gateway G1) to the Beneficiary Bob on blockchain/DLT B2 (via gateway G2).

-- Part of the ODAP protocol is the need for the gateway G1 to temporarily lock or escrow the asset on B1 until either the protocol completes (successful transfer) or fails (escrow reverts back) due to some event (e.g. escrow-time expires, gateway crashes, etc).

-- Luke provided a good overview/discussion regarding the state-machine model for the Lock operation (e.g. issued by G1 on the asset).

-- Therese are summarized as follows:  Lock (Create) establishes the lock; Unlock (Claim) occurs when the recipient claims/retrieves the escrow (e.g. in hash-time lock with secrets); Unlock occurs due to cancellation or abort; Lock-Top-Up when the escrower (i.e. entity who locked the asset) adds additional assets atop the existing locked assets (e.g. in the case of fungible assets).
​---Depending on the escrow type, an escrow can be topped up by a third party (i.e. not the original escrow sender). An example for be a payment channel escrow (in an accounts based DLT).
---The LOCK/UNLOCK sub-verbs may need to be aligned with previous ODAP documentation.

-- The high level categories of escrows can be understood along on three or four dimensions (time based, type of action, permission required). Slide 12 shows a categories-tree, where the leafs indicate the various technical constructs (e.g. multisig) that are available for use today.
​--- Slide 12 placed multi-sig in multiple locations as an example to show the confusion that can arise if you do not think along these multi-dimensional lines when categorising escrow type.
---There are more escrow types than the ones mentioned on those slides, they were just some examples

-- Denis asked if the categories-tree cover both fungible and non-fungible assets. Luke explains that this question has another aspect to it, namely whether the blockchain/DLT is account-based or UTXO-based. The key difference is that in the account-based appraises escrow remains at the same state/location (even though state may change in the balance address), but in the case of UTXO there is a new address/state for the escrow.
​--- I also suggested that NFT escrows could be simpler for escrows as by definition they cannot be topped up in the same way that FT escrows can
--- To clarify, I meant that accounts-based DLT escrows remain at the same state location index even when topped up, as accounts based DLT state is indexed (at a high level) by userId (usually address). Whereas UTXO based DLT escrows will change state location index when topped up as UTXO DLT state is index by UTXOId (TransactionHash+Index) and to top up an UTXO escrow requires it to be spent and another one to be generated.

-- Slide 16 on-wards show a number of attributes that are relevant for the escrow interface. Some of these must be communicated between gateways G1 and G2 during the transfer-setup negotiations (Phase 1). For example, the ExpiryTime value is an important parameter regarding B1 that G1 needs to communicate to G2 (so that G2 can estimate if it will have enough time to finish in the transfer).
​--- Martin suggested to add more params to reflect the categories-tree. E.g. adding permissioned (boolean) and actionRequiredForUnlock (boolean). I will investigate other possibilities

-- Rafael noted that many of these attributes will also be needed for the Log for crash-recovery. For example, if gateway G2 crashes and self-heals then it will need to know these attributes that was provided by G1 in the Phase-1 of the ODAP protocol.
​--- Let me know if/when you want a separate meeting on this Rafeal

-- Rafael also noted the problem of the degree of trust accorded to the smart contracts that implement the escrow/lock. So far we have made the trust assumption that the gateway G1 and G2 are trusted and they they interact over a TLS session.  However, the gateways have no way to know whether a smart contract (in their own respective blockchains/DLTs) is implementing the escrow/lock correctly.  Denis also raises the question pertaining to the possibility that a smart contract may have other side-effects that the gateways are not able to verify.
​--- Unless the smart contract used to escrow the funds for G1 was in fact deployed by G1 and then we are back to the same trust assumptions?

-- Going forward, Thomas suggested that the work Luke is carrying out should be captured in an Informational RFC. An informational document on a "taxonomy of escrows/locks" would be useful for the IETF community broadly, since escrows and locks are very important technical constructs in blockchains/DLTs. Then for the ODAP protocol, an informed choice can be made (based on this taxonomy) for the subset of the escrows/locks to be used by ODAP.
​--- I agreed but suggested it might be good to get more feedback about how the escrow interface works in practice for the crash-recovery mechanism first (i.e. we may find a few more params missing once moving towards implementation integration)

-- The group will continue discussion on the escrow types and interfaces.


(e) Next meeting is Tuesday April 27 (US/UK/EU timezone).

------------------------------------






--
Blockchain-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/blockchain-interop
This message is intended solely for the addressee and may contain privileged and confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Quant Network does not guarantee that this email has not been intercepted and amended or that it is virus free.