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

From: Thomas Hardjono <[email-masked]>
Date: Mon, 27 Sep 2021 14:56:12 +0000

Folks,

Here are the summary notes from the our meeting last wee (Tue Sept 14).

Apologies for the delay.  Please feel free to add/correct.

-- thomas --

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

Date: Tuesday 14 September 2021.

(a) Attendees:

Andre Augusto
Jason Wang
Shiping Chen
Dhinakaran Vinayagamurthy
Krishnasuri Narayanam
Rafael Belchior
Himank Gupta
Tom McGarry
Venkatraman Ramakrishna
Vinayaka Pandit
Denis Avrilionis
Luke Riley
Martin Hargreaves
John Robotham
Thomas Hardjono

(b) IETF Note Well slide

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

(c) ODAP Implementation Update (Jason Wang/Texas A&M):

-- Jason is a student at Texas A&M implementing ODAP features via Hyperledger Cactus.

-- Jason provided an introduction to his implementation of ODAP as a plugin into Cactus. The goal is to implement cross-chain transfers using the ODAP protocol in Cactus.

-- Cactus uses a plugins model, which recognizes ledger plugins, business logic plugins, and a Cactus APIs Server.  End-users (i.e. client-applications) would call any business logic plugins via the API server.

-- There is today no standard way for business logic plugins to perform cross-chain transactions, which is why the ODAP protocol is needed.

-- Cactus also lacks a semantics layer, so there needs to be standards to cover, among others: (i) the format of the exchanged messages, the format of asset profiles & their negotiations, and the format of the transaction receipts/proofs (e.g. evidence that Gateway G2 received the transactions parameters from G1).

-- Jason discussed the 3 phases of ODAP (Transfer initiation, Lock Evidence and Commit Final).

-- A new type operation had to be introduced ("Reverse") in order to reverse an asset transfer, in case errors were discovered at a later time.

-- The log storage options that were considered:  Cloud (centralized), Local storage (on node), IPFS.

-- Recommendations for future work:  Crash recovery tolerance (using write-ahead log approach); Byzantine tolerance (against malicious nodes); Dynamic node execution (to address complex and long business logic execution where nodes can come & leave the network).

-- Rafael congratulated Jason on his internship work implementing this ODAP/Cactus project. 

-- Luke mentioned that many organizations do not like to use IPFS due to the lack of (high-speed) guaranteed data availability. For example, the IPFS node(s) that holds your data may go away permanently and so your data becomes inaccessible.

-- Denis asked about access control of the storage logs. Rafael responded by saying the that current crash-recovery IETF-draft is silent on this topic, and leaves access control to logs as a local implementation concern.

-- Demo by Jason.

-- Slides from Jason can be found in the following location on our Github:  https://bit.ly/3zGMoOZ

(d) Additional transaction types (Rama/IBM)

-- Rama proposed the expansion of the current Architecture draft to include two more "types" of interactions related to different use-cases involving a private/permissioned blockchain network. This is part of the Weaver system being developed by IBM.

-- The first type is the Data Transfer type, which is the exportation of certain data from the ledger of a private blockchain.  The main aspect here is that it is *information* that is being exported out of the blockchain, not a digital asset.  So this is not an asset transfer.  This means that there is no change to the status of assets in the respective blockchains.

-- The second type is the Asset Exchange, which is exemplified today by the "atomic swap".  In summary, two parties (Alice and Bob) are present of both blockchain network B1 and B2.  Alice and Bob agree to perform local swaps in B1 and B2 in a coordinated manner, observing the atomicity principle. This means that either both swaps in B1 and B2 occur (within a specified time), or neither must occur.

-- The Data Transfer type is relevant when blockchain network B2 needs to make an independent decision (e.g. in the context of a local transaction) but B2 is reliant upon state information about an asset located in private blockchain B1.  Thus, B2 needs information (including State Proofs & Consensus finality) from B1 in order to make a decision. Note that B2 is *not* receiving any asset from B1, only state information.

-- An example is in Trade Financing, where two blockchain networks are in operation.  One blockchain network deals with Trade Logistics (such as container shipping logistics and Bills of Lading), where the participants of the network are the shipping carriers, buyers and sellers. The second blockchain network handles Trade Finance (e.g. payments, escrows, etc), where the financial institutions participate in providing short-term loans and guarantees.

-- The Trade Logistics  network holds the Bills of Lading, which is information needed by the Trade Finance blockchain network. Thus, the requirement is for the relevant information about a given bill of lading to be "copied out" of the Trade Logistics network into the Trade Finance network, so that the entities in the Trade Finance network can obtain proof before they commit to funding.

-- Thomas points out that a key aspect here is the finality state of the Bill of Lading in the Trade Logistics network (i.e. its not just any relevant information being exported out).  Thomas also mentioned a discussion we had in the group about gateways copying ledger data (or hash of data) onto an external Witness Blockchain.

-- Luke asked about how to build the state proofs.  Rama explained that the data transfer is relevant for private blockchain networks, and that ultimately it relies on the set of signatures attached to the data being exported.

-- Rama explains that the interaction between the gateways (relays) G1 and G2 consists of Data Queries and Verification Policies. In Fabric, the verification polices are implemented using endorsement logic, where a policy can specify that N out of M entity signatures from private blockchain B1 are required.

-- Rama pointed out a paper that explains in detail the data transfer proofs for permissioned ledgers (Abebe et al. 2021, "Verifiable Observation of Permissioned Ledgers", https://arxiv.org/abs/2012.07339). Rafael recommended we all read that paper at least twice.

-- Thomas suggested that there are several part of the Data Transfer model that could be (need to be) standardized.  For example, the format of the data "packet" (blob) being transferred needs to be standrized to that the receiving blockchain network can understand it.

-- Rama explained the notion of a View Abstraction, which is data (within a permissioned ledger) that is: (i) uniquely addressable, and (ii) externally consumable (i.e. by an external entity).  Another way to see this is to consider a View as a *projection* of state from a ledger. 

-- The operator function to obtain a View is called "getters" and its implementation is dependent on the underlying blockchain system. For example, in Bitcoin a view can be obtained by the Simplified Payment Verification (when inputted a specific transaction ID); (ii) in Corda a view can be obtained by querying the local vault; (iii) in Ethereum a smart contract (with a contract address) can be implemented that expects as input a transaction sent to that address; (iv) in Fabric a view can be implemented using ChainCode.

-- The URL to the Weaver views can be found here: https://github.com/hyperledger-labs/weaver-dlt-interoperability/blob/main/rfcs/models/views.md

-- Rafael asked about who/how to endorse the data transfer (i.e. is it based on signatures).  Rama explained that it is driven by the requirements encoded in the Verification Policy.  So for example, a verification policy in blockchain network B2 may require that 3 out of 4 entities (members of blockchain network B1) sign the data transfer structure.  Gateway G2 will thus expect 3 signatures and will validate them.

-- Rama explained that the View Address is a kind of blockchain URL, and Weaver is developing some tools (SDK) to help this process.

-- Thomas asked about which side (party) initiates the view request. Rama explains that it is driven by the client-application on either side.  Thomas mentioned that the current ODAP draft-02 recognizes 4 types of flows, and lists 4 types of interfaces APIs.  One of them (API Type-1 in ODAP draft-02) is precisely for this situation (i.e. Application tells its Gateway to get evidence from remote blockchain for evidence/proof of the Bill of Lading).  So this is a good match for the Views abstraction proposal.

-- Thomas asks if there some standardized way where the querier can know what type of blockchain systems lies behind a View (e.g. is it Corda, Fabric, Hyperldegr, etc), so that the querier knows what type of answer to receive. Rama explained that the structure of the View Address can often tell you which type of blockchain system is used in the network.

-- Rama would like to add/modify the text of the Architecture draft to include these two other types of interactions. Thomas invites Rama to edit the the Architecture.

(e) Future meetings:

-- Tue 28 September 2021

-- Tue 12 October 2021

-- Tue 26 October 2021

-- Nov 8-12 is IETF112 week.

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