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

[Rafael Belchior <[e-mail]>]

Hello All,

I'll answer inline:

A 2021-10-27 15:10, Thomas Hardjono escreveu:
> 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).

Gateway session, then?

> 
> (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?).

I believe the initiator gateway, which will be the coordinator, should 
choose a session ID. However, this choice should follow a process, 
namely:
1) We need to guarantee each session ID is unique
2) We need to guarantee that the log of each session ID has a 1-1 
mapping to the session (i.e., each log refers to the current session).

For this, the counterparty gateway could check that such session ID is 
unique (using decentralized log storage facilitates this task).

Perhaps sessions could refer previous, related sessions (e.g., a session 
that will roll back the state of an asset-based on a triggered rollback 
of a previous session)?


> 
> (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)

Since APPs are not trusted (in principle), perhaps the safer interaction 
would be GW1-GW2, and each gateway has the responsibility of updating 
its APPs.

> 
> (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).

What happens on the APP layer is not, in principle, the responsibility 
of gateways. What are the reasons why this binding would be necessary?


> (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?

It depends on the definition of view. In our perspective (see page 15 of 
https://arxiv.org/pdf/2011.14465.pdf), it makes sense to bind a view 
with a particular timeframe (i.e., a particular session).

Cheers,
> 
> 
> 
> Best
> 
> 
> --thomas

-- 
-- Rafael Belchior

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