Subject: [Blockchain-interop] Terminology and Gateway Session IDs

From: Thomas Hardjono <[email-masked]>
Date: Wed, 27 Oct 2021 14:10:39 +0000

I thoughts yesterday’s discussion was very illuminating (thanks Luke and Denis).  

It highlights the fact that we are bringing together concepts and terminologies from three different disciplines: (i) software applications/cloud engineering; (ii) database transactional processing (e.g. 2PC and 3PC, etc.); and (iii) DLT and blockchains (e.g. consensus/BFT, finalization, views, etc.).

Here is the link to Denis’ slides on the Github Repo:

https://bit.ly/3CmxiR1

For our terminology, I was thinking of qualifying the use of the word “transaction” going forward and use the following:

-- Gateway-to-gateway transfer transaction (or simply:  gateway transaction).

-- DLT transaction

-- Application-to-Application Interaction (or simply:  application interaction)

For the session IDs, can we assume there are four (4) different “sessions” used:

(a) Between gateway GW1 and gateway GW2  (who chooses the Session ID).

(b) Between APP1 and GW1 (local session)

(c) Between APP2 and GW2 (local session)

(d) Between APP1 and APP1 (app-layer session)

I have a couple of questions about the Gateway SessionIDs:

(i) In the gateway transaction, which gateway selects the Gateway SessionID? (is it GW1?).

(ii) Can we assume that GW1 will communicate this SessionID up to its APP1, which will then communicate it to APP2 (and then down to GW2).

(iii) Can we assume that APP1 and APP2 will “bind” the Gateway SessionID to their own app-layer session identifier? (nb. the mechanics is out of scope for us, but we still need to state assumptions).

(iv) Do Views use SessionIDs?  That is, when GW1 generates a View Data (as the result of GW2 invoking the View Address from DLT1/N1), is there some "embedded" session numbering associated with the resulting Data?

Best

--thomas