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

[Luke Riley <[e-mail]>]

Hi all,

I've uploaded my slides from last night's talk on single-DLN escrows to https://github.com/CxSci/blockchain-gateway/blob/main/docs/slides/EscrowTypes.pdf

Looking forward to see how we integrate this into the ODAP crash-recovery mechanism.

Best wishes,

Luke

________________________________
From: Blockchain-interop <[e-mail]> on behalf of Thomas Hardjono <[e-mail]>
Sent: 31 March 2021 14:18
To: [e-mail] <[e-mail]>
Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (30 March 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 30 March, 2021 (UK/US/EU timezone)

(a) Attendees

Claire Facer
Daniel Lilley
Denis Avrilionis
Himank Gupta
John Robotham
Luke Riley
Martin Hargreaves
Miguel Correia
Mizan Chowdhury
Peter Somogyvari
Rafael Belchior
Shiping Chen
Thomas Hardjono
Tom McGarry



(b) IETF Note Well slide

-- Boilerplate slide on IETF Note Well.  This meeting is operating under IETF IP Rules as described in RFC5378 and RFC8179.


(c) Rosetta APIs discussion (40 mins)

-- Rafael & Thomas introduced the topic of the Rosetta APIs (based on OpenAPI 3.1) as a model that maybe useful for a gateway G1 to interact with its blockchain B1.

-- A standard API (or an abstraction) for the back-facing interaction (G1 to B1, and G2 to B2) is needed for the Crash Recovery model.

-- In the Crash Recovery model, the gateway G2 must keep a log of the Lock Evidence Message from G2, and gateway G1 must keep a log of the Lock Evidence Response Message/Receipt from G2.

-- Luke and Martin have already studied the Rosetta model, but found that there is insufficient information obtainable from its Data API.

-- John mentioned that there numerous private blockchains out there, so it may be difficult to develop an API Abstraction that will satisfy all these blockchains.

-- Denis mentioned that we could perhaps identify the data-items that is needed by G1 from the ledger of B1 for the Lock Evidence Message. These data-items would be the minimal information that must be extracted from the ledger and be used for the Lock Evidence Message. So perhaps a JSON template (for these minimal data-items) could be developed, and for each blockchain a mapping be performed based on the template.

-- Martin & Luke mentioned that a Smart Contract could be defined (abstractly) to perform the Lock on the asset (signal the lock), writing the data-items on the ledger of the blockchain.

-- Thomas suggested that we could perhaps focus on the top 2 or 3 blockchains being used today in private deployments (e.g. Fabric, Corda).  The gateway model is intended to front Legacy systems and even monolithic databases. So it should also work for Corda.

-- Action: group will continue considering this problem.


(d) Gateway Discoverability discussion (10 mins)

-- Shiping gave a brief review on the very early look on blockchain discovery and gateway discoverability.

-- The preferred model is a simple one, re-using as much existing infrastructure as possible (e.g. DNS).

-- The IETF has a number of RFCs dealing with placing keys or certificates in DNS/DNSSEC records (e.g. RFC4034; RFC4035; RFC5702; RFC8624).

-- We will continue this thread at the next meeting.


(e) Next meeting is April 13th (Asia-Pacific 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.