Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (3 August 2021)

From: Thomas Hardjono <[email-masked]>
Date: Mon, 16 Aug 2021 15:02:36 +0000

Folks,

Here are the summary notes from the meeting last week where we had the IPFS presentation.

Please feel free to add or make corrections.

Let me know if I missed anyone in the roll-call.

-- thomas --

----------------------------------------------
Summary Notes from IETF Blockchain Gateway Interoperability group meeting

Date: Tuesday 3 August 2021.

(a) Attendees:

Yiannis Psaras
Dietrich Ayala
Claire Facer
John Robotham
Venkatraman Ramakrishna
Krishnasuri Narayanam
Dhinakaran Vinayagamurthy
Luke Riley
Martin Hargreaves
Rafael Belchior
Shiping Chen
Tom McGarry
Thomas Hardjono

(b) IETF Note Well slide

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

(c) Presentation on IPFS by Yiannis Psaras (Protocol Labs):

-- Yiannis presented an overview of the design and motivation for IPFS.

-- Some background: There are several use-cases for decentralized storage protocols (i.e. IPFS and similar) in the context of our work on blockchain gateways.  One immediate application of IPFS would be to solve the storage needs in crash-recovery scenarios. As mentioned in the crash-recovery draft (Rafael), when two gateways G1 and G2 interact through the three phases, the gateways will need to keep a log of the messages exchanged so far with the opposite gateway. This is to help a crashed gateway to gracefully reboot and resume the asset-transfer session (ODAP) with the opposite gateway.

--  In the Self-Healing recovery strategy, a gateway G2 is assumed to have persistent storage -- either locally (local drive) or remotely (cloud or IPFS).

--  In the Primary-Backup recovery strategy, the assumption is that gateway G2 is dead (no self-healing) and another gateway G2-Prime in the same DLN will pickup from where G2 crashes. However, this means that G2-Prime must have access to the log-files created by G2.  In this case, G2 and G2-Prime could share ahead of time a content-address (CID) to an IPFS storage location for the log-files.  Then, G2-Prime would simply read from that CID address.

-- We can expand this model to a Group Recovery Strategy, where all (or subset) the gateways in a DLN share a default content-address (CID) to an IPFS storage location where they will store their logs. This permits interesting recovery models to be developed, such as the election of a standby gateway (call it gateway G2-PrimeElected) that will perform the recovery in case G2 dies. 

-- There are other challenges that we will need to address in the non-self-healing models employing decentralized storage logs, such as (i) authorization to read/write to the shared storage; (ii) confidentiality of logs (because each of the messages between G1 and G2 carry the Originator/Beneficiary information and details of the the assets being transferred), etc. etc.

-- The presentation by Yiannis covered three (3) foundational areas of IPFS that are relevant to using IPFS:  (i) Content addressing; (ii) Content Routing; (iii) Content Exchange.

-- The following are links to online presentations on these three topics:  Overview:  https://research.protocol.ai/tutorials/resnetlab-on-tour/

(i) Content addressing: https://research.protocol.ai/tutorials/resnetlab-on-tour/content-addressing/

(ii) Content Routing:  https://research.protocol.ai/tutorials/resnetlab-on-tour/content-routing/

(iii) Content Exchange:  https://research.protocol.ai/tutorials/resnetlab-on-tour/content-exchange/

-- There are some interesting topics for this IETF group to explore with regards to standardizing some components of an IPFS-based storage for different specifications that the group is writing.  For example, we could look into standardizing the default Content-Addresses and default APIs for crash-recovery log storage (Rafael's draft), for gateway discovery (e.g. Shiping's draft) and others.

(d) Next meeting:

-- Tue 17 August 2021.

-- Tue 31 August 2021.

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

---

From: Thomas Hardjono <[email-masked]>
Date: Sat, 28 Aug 2021 15:00:37 +0000

Folks,

Here are the summary notes from the meeting last week.

-- thomas --

Date: Tuesday 17 August 2021.

(a) Attendees:

Martin Hargreaves
Shiping Chen
Claire Facer
Denis Avrilionis
Mizanul Chowdury
Venkatraman Ramakrishna
Thomas Hardjono

(b) IETF Note Well slide

(c) Updates on drafts and related work:

 (i) ODAP draft:

-- We are preparing draft v03 on ODAP.

-- The plan with the ODAP work is to split the current document to create one ODAP-Core document, with one or more additional ODAP-related documents.

-- The ODAP-Core will focus on gateway-to-gateway interactions and application-to-gateway interactions.

-- The ODAP-related work steams include:  crash-recovery, resource discovery & access (i.e. resources behind a gateway), asset profiles (and possibly key management).

-- This would allows us to move ODAP-Core faster through the IETF process (nb.  its getting to the 1 year mark for the ODAP work).  The ODAP-Core draft will continue to refer/cite to these other drafts.

-- General consensus in the meeting that the "single core document" approach make sense.

-- Rafael mentioned that in Hyperledger they are implementing ODAP right now, and will have a functional implementation by early September.  It is an implementation of version 1 of ODAP, but can be quickly updated to reflect the latest version.

-- Regarding the ODAP flows, Rafael mentioned the need to reflect the evidence from the (origin) blockchain in the form of a Transaction Receipt.  However, currently the Hyperledger community have no plans to standardize Transaction Receipts.  So this is a work item that this IETF group could standardize.

-- Rafael asks where this Transaction Receipts work could be done (e.g. part of ODAP-Core, or elsewhere such as in the Asset Profile). Thomas mentioned that the Asset Profile is a definition file (i.e. static definition of the digital asset).

-- So the Transaction Receipts could be a separate draft that is then used by ODAP-Core gateways to yield the evidence (e.g. locking/escrow evidence).

 (ii) Crash Recovery draft:

-- Rafael mentions that we need to clarify which is the preferred storage place for logs (centralized or decentralized). Additionally, regardless of this question, we also need to standardize the Interface (to the storage, such as IPFS).

-- There is a close dependency between the ODAP-Core draft and the crash-recovery draft in that there needs to be a 1 to 1 mapping between the ODAP-messages and the log-entries.  However, this cannot proceed until the ODAP-Core messages have been finalized.

-- Denis asked if there is any privacy concerns with regards to the log storage (e.g. the ODAP messages may carry sensitive business information). 

-- Rafael agrees that there maybe privacy concerns and that access-control to the logs may need to be provided.  We first need to know in detail what data in written to the logs. There is also local logs that store business and asset information.  

--  For the decentralized log-storage approach, the shared logs (i.e. accessible to multiple backup gateways) the situation is more complex.

-- Martin mentions that in the decentralized shared log scenario, the gateway (i.e. transacting gateway) may need to stream the logs to different endpoints within its own gateways community (e.g. if the gateways are owned/operated by the consortium group of providers).

-- Martin also pointed out that a gateway may belong to (i.e. active in) distinct consortiums. This means that the logs should not be mistakenly shared with the wrong members of the consortium.  Thomas mentions that if separate log streams need to be encrypted, then if a gateway uses trusted hardware (i.e. keys survive crash and reboot) then separate keys could be used to protect the different logs.

-- Rama asks if a multi-lateral setup is preferred. Martin concurs that multi-lateral is preferred, and that a gateway could be involved in a multi-lateral transaction with other gateways.

-- Rama also point to the need to protect (e.g. encrypt) logs that need to be shared with other entities in multi-lateral setup.

-- Denis asks about the degree of interpretability of the logs by all gateways. Rafael mentions that standardized logs (entries and format) permits other gateways to read and resume sessions. Denis agrees, and mentions the long-standing design principle of separating Behavior from Structure that is applicable to the crash-recovery behaviour and log formats.

 (iii) Discovery draft:

-- Shipping provides a brief report on the Gateway Discovery work.  Shiping is looking into the possibility and benefit of adding part of the negotiations information (from Phase-1) into the discovery protocol. This permits the querying gateway to better select which remote gateways it is willing to peer with. He is also looking at the hardware based gateways (c.f. see the device attestations slides from Thomas from a couple of meetings ago).

-- A student in Australia under the supervision of Shiping has developed a simple prototype of the gateway discovery mechanism.

 (iv) Request to review/comment to Luke's Escrow Interface:

-- We may ask Luke to provide another presentation of this work.

-- Thomas asks if this is relevant to the Transaction Receipts question raised earlier. Martin agrees.

(d) Introductions from Rama and the IBM team.

(e) Next meetings:

-- Tue 31 August 2021.

-- Tue 14 September 2021

-- Tue 28 September 2021

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 31 Aug 2021 23:25:43 +0000

Folks,

Here are the summary notes from the meeting today.

-- thomas --

Date: Tuesday 31 August 2021.

(a) Attendees:

Martin Hargreaves
Shiping Chen
Claire Facer
Himank Gupta
Tom McGarry
Venkatraman Ramakrishna
Vinayaka Pandit
Thomas Hardjono

(b) IETF Note Well slide

(c) Presentation from Rama (IBM):

-- The Weaver slides can be found in our github repo (under Slides):  

https://github.com/CxSci/blockchain-gateway/blob/main/docs/slides/IETF-Blockchain-Interop-Presentation-Aug-31-2021.pdf

-- We will continue discussing the various aspects of Weaver at our next meeting.

(d) Next meetings:

-- Tue 14 September 2021

-- Tue 28 September 2021