Re: [Blockchain-interop] Gateway Slides

[Thomas Hardjono <[e-mail]>]

Tom,

I'm just re-reading your post from last week:

>>>   DLT1:             DLT2:
>>>   
>>>   O->AP->N     N->AP->B
>>>   
>>>   
>>>   Architecturally the GWs would have to connect to the Ns. 
>>>   
>>>   DLT1:                                         DLT2:
>>>   
>>>   O->AP->N –> GW –> GW –> N->AP->B


The question that came to mind is the following:  should the Applications at both ends need to interact first (at the application layer), before the gateways interact (at the gateways layer).

This is so that the gateways (a) know to expect a message from the other, and (b) that the gateways have sufficient context prior to talking to one another.


So the flows looks something like this:

Entities:
O: Originator located in DLT1 (N1). 
B: Beneficiary located in DLT2 (N2). 
AP1: Application used by Originator.
AP2: Application used by Beneficiary.
GW1: Gateway fronting DLT1.
GW2: Gateway fronting DLT2.


O->AP1->AP2->B    [set up asset transfer at Application layer]

AP1->GW1     [Get ready to interact with DLT2]
AP2->GW2     [Expect a request to connect from a Gateway from DLT1]


The asset transfer flow now commences:

AP1->GW1    [Transfer-Commence]
AP1->AP2     [Agree-Commence]
AP2->GW2    [Transfer-Commence]
GW2->GW1   [Ready]

Then lock/escrow evidence is given from GW1 to GW2:

GW1->GW2    [Lock/Escrow Evidence]
GW2->GW1    [Evidence-Receipt]


Then the 2-phase commit (or 3PC) can also occur:

GW1->GW2    [Commit-Prepare]
GW2->GW1    [Ack-Prepare]
GW1->GW2    [Commit-Ready]
GW2->GW1    [Ack-Ready]

(GW1 permanently locks or burns asset in DLT1)

GW1->GW2    [Commit-Final]

(GW2 creates asset in DLT2)

GW2->GW1    [Ack-Final]



--thomas


________________________________________
From: Blockchain-interop [[e-mail]] on behalf of Tom McGarry [[e-mail]]
Sent: Monday, October 18, 2021 4:29 PM
To: [e-mail]
Subject: Re: [Blockchain-interop] Gateway Slides

I do believe that there will be a model where the DLT designates 1 GW, likely one it operates.  So all transactions to and from that DLT will have to go thru that GW.  Of course in that model it could be the AP that has the relationship with the GW.

From: Tecnico Lisboa <[e-mail]>
Date: Monday, October 18, 2021 at 12:48 PM
To: Tom McGarry <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Blockchain-interop] Gateway Slides
Hello,
Yes, I believe so. Perhaps there are different models, though.
Cheers,




On 18 Oct 2021, at 14:47, Tom McGarry <[e-mail]> wrote:

Interesting.  So it would be the AP that has the relationship with the GW?

From: Rafael Belchior <[e-mail]>
Date: Monday, October 18, 2021 at 7:40 AM
To: Tom McGarry <[e-mail]>
Cc: Luke Riley <luke.riley=[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Blockchain-interop] Gateway Slides

Hello Tom,

That's very insightful, thanks for sharing.

In my mental model, the blockchain nodes are always on the end (or in the "middle") of a transaction issued against a gateway;

O->AP->  GW –> N -> GW –> ->AP->B

By the definition we are trying to come up with, it seems that gateways need to connect to a DLT and provide a set of services, otherwise they would be proxies.

Cheers,

A 2021-10-14 20:46, Tom McGarry escreveu:
I had to step out of the meeting on Tuesday early, and was sorry to leave an excellent discussion.  Nice work Luke.

I wanted to share something I was thinking about wrt the Gateway (GW) and the business relationships among the entities involved in transactions

At one end of the transaction is an 1) Originator (O, one transferring asset to a Beneficiary), 2) App Provider (AP, like a wallet provider) and 3) DLT Node (N).  At the other end is 1) N, 2) AP and 3) Beneficiary (B, one receiving an asset from an O).

DLT1:             DLT2:
O->AP->N     N->AP->B

Architecturally the GWs would have to connect to the Ns.

DLT1:                                         DLT2:
O->AP->N –> GW –> GW –> N->AP->B

It seems logical that the business relationship starts with the O and B and goes upstream:

O->AP->N->GW
B->AP->N->GW

The O and B wants to select the AP that provides it the most flexibility, or at least the one that it expects to interoperate with the most.  Same with the AP selecting the N.   Of course many of these roles can be collapsed AP+N, N+GW, AP+N+GW, GW+GW, etc.  But it seems important to track the roles.

In some cases the AP may need to connect to multiple Ns in order to interoperate with multiple DLTs:

DLT1:                                 DLT2:
        N–> GW –> GW –> N->AP->B2
        |
O ->AP
        |                         DLT3:
        N– GW – GW – N-AP-B3

The AP can delegate this function to their N provider:

DLT1:                                 DLT2:
                 GW –> GW –> N->AP->B2
                  |
O ->AP –> N
                   |                 DLT3:
                GW – GW – N-AP-B3

And the N can delegate this function to its GW provider.  I won't bother creating a diagram for that – you get it.

In any event, it seems clear that neither the O nor B selects the GW.  They do by proxy, but if you agree with the roles, they would not directly select a GW.  (They may also select it by selecting a collapsed provider – AP+N+GW.)

As per last week's discussion, I realize there's a model where one end is not a DLT.

Do others see the relationships this way?

I assume there will also be a model where a DLT has only 1 GW chosen by the entity that runs the DLT.  All Ns on that DLT connect to this GW, other GWs can only connect to this one GW.

Are there other models?

I'm not sure these need to be captured in an IETF document, but I needed to think this through myself to understand the flows and relationships.

BTW, the architecture draft, https://datatracker.ietf.org/doc/draft-hardjono-blockchain-interop-arch/, doesn't seem to define what I call the AP.  I thought the AP may be the VASP, but the definition for Gateway Owner, says it is the VASP.  Did I miss it?



From: Blockchain-interop <[e-mail]> on behalf of Luke Riley <luke.riley=[e-mail]>
Date: Tuesday, October 12, 2021 at 11:49 AM
To: [e-mail] <[e-mail]>
Subject: [Blockchain-interop] Gateway Slides
Hi all,

Thanks for the interesting meeting today. I have neatened up the slides on the Gateway definition.

Feel free to digest them. Any comments are welcome, it is a team definition 🙂 after all.

Best wishes,

Luke

Luke Riley​



Head of Research and Development


<https://www.quant.network/>
<image001[56].png><https://www.quant.network/>



[e-mail]<mailto:[e-mail]>


[phone]


www.quant.network


<https://twitter.com/quant_network>
<image002.png><https://twitter.com/quant_network>



<https://www.linkedin.com/company/quantnetwork/>
<image003.png><https://www.linkedin.com/company/quantnetwork/>




The content of this email is confidential and intended for the recipient specified in message only. It is ​strictly forbidden to share any part of this message with any third party, without a written consent of ​the sender. If you received this message by mistake, please reply to this message and follow with its ​deletion, so that we can ensure such a mistake does not occur in the future.
​
​



________________________________
From: Blockchain-interop <[e-mail]> on behalf of Thomas Hardjono <[e-mail]>
Sent: 11 October 2021 20:07
To: [e-mail] <[e-mail]>
Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (28 September 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.


Folks,

Here is the summary notes from our last meeting (Tue Sept 28).

Please feel free to add/correct.


-- thomas --


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

Date: Tuesday 28 September 2021.

(a) Attendees:

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


(b) IETF Note Well slide

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


(c) Plans for IETF112 Side Meeting:

-- We plan to request the IETF for a block of time for a Public Side Meeting at the coming November IETF112, which will operate online only and run on Madrid timezone. https://www.ietf.org/how/meetings/112/

-- The Side Meetings at the IETF are places/locations at IETF F2F meetings where folks get together and discuss some topic of interest. These meetings can be designated as "public" where anyone can attend, or "private" where they are invite-only.

-- The goal for us at IETF112 to provide a report to the broader IETF community about our progress in the past year.

-- Thomas & Martin suggest we request a 2-hour block, where we can have several 20-30 min time-slots for presentations followed by Q&A. We will need to organize our schedule in our coming meetings.

-- We will know the availability of the Side Meeting time-blocks after the IETF Agenda has been finalized (sometime in mid-October).

-- Here is the Preliminary Agenda for IETF112:  https://datatracker.ietf.org/meeting/112/agenda/


(d) Update on Architecture Draft:

-- Thomas had a discussion with Rama, and will be adding two more interoperability modes to the Architecture draft. The Architecture is the top-level document that newcomers will read first, and is also kind of a "guide" to the other drafts in the group.

-- The first one (Asset Transfer) is already covered, and is also the main protocol addressed by ODAP Core.

-- The other two modes are (i) Asset Exchange (atomic swaps synchronized between two blockchains, but asset do not move across) and (ii) Data Sharing (i.e. relevant data/view is "exported" from the ledger of private blockchain).

-- Rama will be adding new sections/texts to the Architecture draft (working on it).

-- There are also other drafts that may need to be written, such as how a blockchain can project a View (as part of the interoperability modes).

-- Thomas agrees and comments that the Validation of views may need to be yet a separate draft/protocol. But the first task is to explain the notion of Projecting a View because many folks in the IETF may not be aware of this concept.

-- John Robotham asks if the notion of an Oracle is related to Data Transfer. Rama explains that a View can be considered as a specific case of an Oracle but with a different the logic, and that a key aspect is the verifiability of the View. For Oracles, its construction need to specify exactly what happens inside the oracle.

-- Denis comments that there is a fundamental difference between the Oracles and the Exchange of Assets, notably in their programmability aspects. The Oracles are more like smart contract code that is executed by the VM on the node, and thus they are behavior-driven.  Whereas here (Views) we are talking about Data Structures, and what we really want is to exchange structured data.

-- Rama agrees and explains further that View must be accessible by entities from outside the blockchain, and one way to achieve this effect is to utilize View Addresses.  A given View Address may in fact refer to (i.e. can de-reference to) a smart contract that generates/computes the structured-data being "exported".  There may be other ways or mechanism (beyond View Addresses) to achieve this but that's for future work.


(e) Update on ODAP Core draft:

-- Martin provided a summary on the current changes to the ODAP draft.

-- The goal of ODAP Core draft is to be truly the core functions, flows and APIs, with other scenario-specific uses of ODAP being further specialized by one or more of Profile documents.

(NOTE: an analogy is with the old SAML2.0 Core specification which defines all the message flows and data structures, but to implement SAML2.0 for browsers you need an additional Browser Profile specification that "binds" these messages & data structures to the browser's capabilities -- which is different from an Native Agent such as an app on a mobile phone).

-- The plan is for the ODAP Core document to describe the use of the Profiles and link to these other document. There are already placeholders for some of these. We want to make ODAP Core as generic as possible, but retaining the core concept of moving assets across blockchains.

-- For example, we will need a specification to cover interior-resource discovery by a local Gateway. We will also need a specification for access-control to those resources. Many of the use-cases are domain-specific, so we will need Profile (of ODAP Core) for those domains.

-- No changes to the message flows in ODAP.

-- Thomas noted that there some uses of the word "client" that could be confusing and need to be corrected.  For example, the word "client" is used for "client application" (i.e. business application software) that interacts with the Gateway.  But the "client" is also used when gateway G1 (the Client) is sending messages to gateway G2 (the Server).

-- Martin discussed the need to define the attribute APIs of the Type-1 APIs (used by applications).  The Type-2 APIs operations need to also be available to the Type-1 APIs.

-- Rama commented that in Weaver has a Type-1 APIs, where clients can submit View-Addresses. Rama would like to see this developed further.  Currently Weaver has a polling mechanism, where Gateways (Relays) can poll one another for updates.



(f) Discussion on the definition of Gateways:

-- Luke (and Rafael) faced an interesting and very relevant question for the group, namely regarding the definition of a "Gateway".

-- Is a node a gateway?  What is a payment gateway? etc. etc.

-- Thomas mentioned that his views maybe biased towards the IP routing world, where a Gateway is like a BGP-Router that implements an intra-domain routing protocol on one side (e.g. OSPF) and an inter-domain protocol on the other side (e.g. BGPv4).

-- The current Architecture draft is ambiguous regarding the definition gateway (e.g. when it says "gateway node").

-- Martin says that a gateway is an edge device that is connected to one or more DLT networks and can talk to other edge devices and applications.  It can be virtualized also.

-- Thomas says that at the minimum, a gateway of a DLT must have Read-access to the internal ledger of that DLT. But can it perform a Write to the ledger and what kinds of Write operations.

-- Martin mentioned that the current assumption is that a gateway maps to one legal entity (i.e. it is owned by one entity). Rama asks if multiple gateways could be used for redundancy (answer is yes).

-- Luke would like to work of this definition problem and formalize it. Martin says yes, we need to include the precise definition in the ODAP Core draft.

-- Rama says the difference may be in their configurations.  In Weaver the gateway is called a Relay. It has two (2) general parts: (a) DLT-independent part that conforms to the specifications, speak a protocol and implements APIs; and (b) the DLT-specific part that Read from the specific types of DLT (using drivers).

-- Rama says the Driver (Client) in Weaver is the part of an organization that participates within the Consortium that runs/owns the DLT networks. The Driver is used for DLT-specific.  In Fabric there is an Ordering service, and gateways can be part of the Ordering services.

-- Martin says that there are open questions, such as if a gateway can perform a Write to the ledger, who does the gateway Write as (in what identity/role capability). Do we think of this case a multi-tenant gateway with multi-identities, etc.  The answers may have some protocol implications.

-- Luke will continue to work on this. Its a topic of interest for everyone in the group.


(g) Updates on Crash-Recovery draft:

-- The current version appears to be stable, and will upload it to the IETF site. With the revision of the ODAP drafts, there may need to be further updates to the Crash-Recovery draft.

-- Thomas mentioned that the ODAP Core draft needs to stabilize and the message flows needs to have more specific payloads. This is because the Crash-Recovery draft needs to log each of the payloads.

-- Martin says that this particularly needed for payloads in Phase-1.

-- Thomas mentioned that the later half of ODAP Core has defined the payloads for Phase-1, Phase-2 and Phase-3.  Is there more details needed by the Crash-Recovery draft? Rafael will review the latest ODAP-Core draft.


(h) Updates on Gateway Discovery draft:

-- Shiping has been working on the next revision, and will send Thomas the file.

-- On the topic of DLN Identification, Shiping presented some slides on a comparison of DLN numbering in ChainID versus Network ID.

-- He presented three (3) possible numbering proposals for the future blockchain systems.

-- Proposal #1:  Reuse NetworkID in combination with the SHA of the public key (e.g. of Alice). So the prefix (front) part of Alice's address identifies the DLN where Alice's public-key is recognized.

-- Proposal #2: Using the domain name, where each DLN has a unique domain name (e.g. DLN.com).  Then Alice's address looks something like:  [e-mail]

-- Proposal #3: Use a Directory (as previously discussed).

-- The Proposal #2 (using a domain name) appears to offer the best trade-off between the degree of decentralization, scalability, security/privacy and standardization.

-- Luke asks about cases, such in Fabric, where the User is identified by a Username and Organization (and Certificate), and often the DLN is opaque to the user.




(i) Future meetings:


-- Tue 12 October 2021

-- Tue 26 October 2021

-- Nov 8-12 is IETF112 week.




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





--
Blockchain-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/blockchain-interop




--
-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/