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

From: Thomas Hardjono <[email-masked]>
Date: Tue, 1 Jun 2021 21:07:55 +0000

Folks,

Here are the summary notes from last week's meeting.  Apologies for the delay.

-- thomas --

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

Date: Tuesday 25 May 2021.

(a) Attendees:

Denis Avrilionis
Rafael Belchior
Miguel Correia
Shiping Chen
Clair Facer
Martin Hargreaves
Gilbert Verdian
Luke Riley
Tom McGary
John Robotham
Thomas Hardjono

(b) IETF Note Well slide

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

(c) Updates on discovery work (Shiping/thomas)

-- Currently writing up a new draft-00 to discuss some of the options with regards to gateway discovery.

-- Luke suggested we use the term DLN for decentralized ledger networks.

-- Shiping provided an overview of two approaches:  (i) a network-layer based approach (based on DNS), and (ii) an application-layer approach.

-- For option (i), if we follow the STMP inspiration (MTA model) then some gateway information will need to be placed in the DNS records (Shiping illustrated with the CNAME record).

-- After finding the endpoint of the remote gateway, then some proof (that the endpoint is a gateway) must be provided. Shiping illustrated with a certificate (e.g. X509).

-- Martin asked about the use of the AS number in the example (e.g. in the US it is assigned by ARIN), and Thomas responded that in the case of ISPs the AS numbers are either well-known (e.g. public list from ARIN), or the numbers can be manually exchanged when ISPs peer with one nother (i.e. peering agreement).

-- Tom suggested the possibility of adding the IP address of a gateway to the certificate. Martin suggested also Secure DNS or DNSSEC, the more trust mechanisms is preferred because gateways are sensitive.

-- Miguel concurs that DNS/DNSSEC is a reliable infrastructure, so its a good area to look at. Miguel asked about the example (G2.DLT1.com), how do you know of G2 is a true gateway.  Can the Resource Records (RR) to hold the information. A digital certificate may be the best approach because the certificate can hold business information.

-- Martin suggested that we are fundamentally looking at two (2) different questions: (a) are we looking to connect to an organization, versus (b) are we looking to connect to a decentralized network. The draft should clarify this distinction.

-- Martin explained further that the goal should be to answer the question:  which DLN networks does an Organization have gateways for. This assumes you already know the organization. Whereas the current DNS-based example seems to be searching for a gateways (connected to DLNs), without knowing the Organization who own the gateways.

-- Thomas agrees, perhaps the search should be at the application layer (e.g. "I want to connect to the JPMC network") and I need to look for a gateway to that network/DLN. Martin suggest that if that is the strategy then the first step is to look for members of the network (e.g. "member organizations of the JPMC network") and then look for gateways belonging to these member organizations.

-- Thomas suggest that even in ISP peering (i.e. BGP routers), that the ISPs picks up the phone and establish business agreements (peering contract) before the BGP endpoints communicate with each other.

-- For the draft Shiping & Thomas will explain this question (i.e. Martin's fundamental question).

(d) Updates on crash recovery work (Rafael)

-- Rafael just uploaded a new revision of the crash recovery draft.  See: https://www.ietf.org/archive/id/draft-belchior-gateway-recovery-02.txt

-- The logging model stays the same, but the APIs have some changes.

-- The basic primitives are:  (a) retrieving a log entry (Fig 2), and (b) obtaining the difference between a given log and the current log (Fig 3).

-- Examples: GET getLogLength Host: example.org, versus:   GET getLogDiff Host: example.org 

-- The basic combination of commands and endpoint APIs shown in Figure 2 (Page 7) should be sufficient to cover the majority (or all) use-cases.

-- Section 5.2 has made explicit the separate Phases, while Section 5.3 is ODAP-specific (i.e. these messages are tailored for the ODAP protocol). These are:  RECOVER, RECOVER-UDPDATE, RECOVER-SUCCESS and ROLLBACK.

-- Figure 6 provides a basic example of two gateways G1 and G2.

o  Gateway G1 writes:  [1]: writeLogEntry <1, 1, init-validate>  

o  And then G1 crashes soon after (before the init stage is completed), and it recovers in step [3].

o  G1 tells G2 that it has recovered in message [4] <1, 2, RECOVER>, and G2 must correspondingly read from the log in step [5] getLogEntry(i).

o  Gateway G2 then sends its status log to G1 in message [7] <1,3,RECOVER-UPDATE> 

o  G1 process the log/updates and records the sync (within its log) in step [9] <1,4,writeLogEntry>

o  Then G1 tells G2 that it is now in sync, via message [10] <1,5,RECOVER-UPDATE-ACK>

o  Gateway G2 agrees with G1 via message [11] <1,6,RECOVER-SUCESS> 

o  Then gateway G1 logs this new state in step [12]: <1,7,init-validateNext>  

-- Denis asks if there is trust between G1 and G2, and Rafael concurs that there must be some trust between G1 and G2 (e.g. established using the certs and SSL).

-- Denis suggest that they may need to be an architecture pattern using a replicated log service.

-- Thomas suggest we add some text to the draft to explain the notion of "decentralized log", perhaps even looking at decentralized storage services like IPFS.

-- Luke asks if we should add some hashes into the logs. Rafael state that the draft tries to capture this in Section 4 in the "Last_entry_hash" field.

(e) Witness/Notary blockchain (rough idea from Thomas).

-- The idea of a blockchain which records only the hash value and signature (and nothing else). This is essentially the same as the original Haber-Stornetta design  (AT&T Labs) from their 1993 paper that is cited in the Nakamoto paper. Thomas states that several research papers also mention the idea of a "witness blockchain".

-- The writer (signer) must retain the context metadata off-chain.

-- It maybe useful for dispute resolution (e.g. between G1 and G2).

-- There are other use-cases, such as taxation-related cases where the hash of some state is stored on-chain, but data being off-chain (e.g. for privacy reasons).

-- There is already RFC3852 that defines the CMS standard (Cryptographic Message Syntax).  For this scenario, the body of the transaction would be the CMS SignedData type.

--  The CMS SignedData type would carry (a) the DigestAlgorithm-ID field of the CMS envelope, (b) the EncapsulatedData field (meaning our hash value), and (c) the Signature of the entity creating the CMS SignedData blob.

-- The idea would be to use the same signature-key for signing the CMS SignedData blob and for signing the transaction sent to the notary-blockchain.

-- This would allow any third party to validate that signer/creator of the blob and the signer/creator of the transaction are the same entity.

(f) Next meeting is 8 June 2021.

-------