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

[Thomas Hardjono <[e-mail]>]

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).

-- 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.

-- 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. 

-- 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).

-- 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.

-- 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.

-- 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.

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


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

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