Subject: [Din] Minimal assumption for interoperable blockchain systems

From: Thomas Hardjono <[email-masked]>
Date: Sun, 3 Jun 2018 13:51:42 +0000

Here is a question I'd like to throw out to this community regarding "interoperable blockchain systems" -- a topic which will undoubtedly come to the forefront (assuming it doesn't get drowned-out or killed by the barrage of hype about BC):

-- Minimal assumption: What is the minimal assumption for interoperable blockchain systems with regards to the notion of transaction units. In other words, what is the “datagram” equivalent of transactions – namely the transaction unit that is semantically understandable (processable) by multiple different blockchain systems.

This is a question we posed in our recent discussion paper:

https://arxiv.org/pdf/1805.05934.pdf

Would love to get your thoughts on this "datagram" equivalent question (or if this framework of thought is even the correct one).

Best

-- thomas --

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 3 Jun 2018 15:12:50 +0100

looks sane (as did interledger) but we're missing (I think, but may be I
missed it too) one of the big challenges for this compared with scaling
(which is what you have to address in internetworking stuff whether
subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's a
fundamentally difficult piece of distributed ledgers- consistency

one thing the e2e model did for thinking (amongst many) was to think in an
intensely relaxed way about consistency - IP doesn't care if the source is
still where it was when the packet reaches the destination (or even first
hop router. BGP doesn't care (much) about IGP convergance when announcing
(or withdrawing) prefixes and (most) AS paths. WWW doesn't care if the
remote page (server, site or content) are there when you add a URL to your
site - all this is "fixed up later" by some eventual consistency protocol
(in IPs case, TCP;  in the IGP/BGPs case the linkstate and path vector and
a lot of magic pixie dust and luck; in the WWW case, search/rank&shame and
later maintenance) -

so for inter-ledger type thinking, we're connecting systems that
fundamentally care about consistency - but define its eventuality
differently - so a basic building block of an interoperabilty or
inter-domain protocol would be to convey (and somehow reconcile) that
variation in notion of how long before we agree about an append in domain
1, when were' 5 ledger domain hops away...

which reminds me, am I allowed to coin that term "ledgerdomain" ? :-)

On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono <[email-masked]> wrote:

>
> Here is a question I'd like to throw out to this community regarding
> "interoperable blockchain systems" -- a topic which will undoubtedly come
> to the forefront (assuming it doesn't get drowned-out or killed by the
> barrage of hype about BC):
>
> -- Minimal assumption: What is the minimal assumption for interoperable
> blockchain systems with regards to the notion of transaction units. In
> other words, what is the “datagram” equivalent of transactions – namely the
> transaction unit that is semantically understandable (processable) by
> multiple different blockchain systems.
>
> Would love to get your thoughts on this "datagram" equivalent question (or
> if this framework of thought is even the correct one).
>
>
> Best
>
>
> -- thomas --
>
> _______________________________________________
> Din mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/din
>

---

From: Jehan Tremback <[email-masked]>
Date: Sun, 03 Jun 2018 17:50:05 -0400

No citation of
https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/ibc? This
was the original work along these lines from around 2 years ago IIRC.
Should be in production soon if they meet their launch schedule. I'd
appreciate a comparison with tradecoin and an analysis of what trade-in
does differently.
--
  Jehan Tremback
  [email-masked]

On Sun, Jun 3, 2018, at 10:12 AM, Jon Crowcroft wrote:
> looks sane (as did interledger) but we're missing (I think, but may be
> I missed it too) one of the big challenges for this compared with
> scaling (which is what you have to address in internetworking stuff
> whether subnetworks with IP or IGPs with BGP, or serice+content with
> WWW - that's a fundamentally difficult piece of distributed ledgers-
> consistency> 
> one thing the e2e model did for thinking (amongst many) was to think
> in an intensely relaxed way about consistency - IP doesn't care if the
> source is still where it was when the packet reaches the destination
> (or even first hop router. BGP doesn't care (much) about IGP
> convergance when announcing (or withdrawing) prefixes and (most) AS
> paths.. WWW doesn't care if the remote page (server, site or content)
> are there when you add a URL to your site - all this is "fixed up
> later" by some eventual consistency protocol (in IPs case, TCP;  in
> the IGP/BGPs case the linkstate and path vector and a lot of magic
> pixie dust and luck; in the WWW case, search/rank&shame and later
> maintenance) -> 
> differently - so a basic building block of an interoperabilty or inter-
> domain protocol would be to convey (and somehow reconcile) that
> variation in notion of how long before we agree about an append in
> domain 1, when were' 5 ledger domain hops away...> 
> which reminds me, am I allowed to coin that term "ledgerdomain" ? :-)> 
> On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono
> <[email-masked]> wrote:>> 
>> "interoperable blockchain systems" -- a topic which will undoubtedly
>> come to the forefront (assuming it doesn't get drowned-out or killed
>> by the barrage of hype about BC):>> 
>>  -- Minimal assumption: What is the minimal assumption for
>>  interoperable blockchain systems with regards to the notion of
>>  transaction units. In other words, what is the “datagram” equivalent
>>  of transactions – namely the transaction unit that is semantically
>>  understandable (processable) by multiple different blockchain
>>  systems.>> 
>>  Would love to get your thoughts on this "datagram" equivalent
>>  question (or if this framework of thought is even the correct one).>> 
>> 
>>  Best
>> 
>> 
>>  -- thomas -- 
>> 
> _________________________________________________
> Din mailing list
> [email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 4 Jun 2018 08:19:43 +0100

i hadn't been tracking where the tendermint stuff had been going - in your
current ibc spec, you implement causal ordering (It looks pretty much like
virtual synchrony, no?) - this is fine in terms of semantics, but i'm
worred about (as per my prev. ressponse) scalability....

On Sun, Jun 3, 2018 at 10:50 PM, Jehan Tremback <[email-masked]>
wrote:

> No citation of https://github.com/cosmos/cosmos-sdk/tree/develop/docs/
> spec/ibc? This was the original work along these lines from around 2
> years ago IIRC. Should be in production soon if they meet their launch
> schedule. I'd appreciate a comparison with tradecoin and an analysis of
> what trade-in does differently.
>
> --
>   Jehan Tremback
>   [email-masked]
>
>
>
> (or withdrawing) prefixes and (most) AS paths.. WWW doesn't care if the
> *_______________________________________________*
> Din mailing list
> [email-masked]
> https://www.irtf..org/mailman/listinfo/din
> <https://www.irtf.org/mailman/listinfo/din>
>
>
>

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Mon, 4 Jun 2018 13:20:43 +0100

i think its not just the tech (consistency) - also handling governance
across DAOs is a major issue..

regards

On 3 June 2018 at 15:12, Jon Crowcroft <[email-masked]> wrote:

>> Would love to get your thoughts on this "datagram" equivalent question
>> (or if this framework of thought is even the correct one).
>>
>>
>> Best
>>
>>
>> -- thomas --
>>

-- 

Arjuna Sathiaseelan | http://sathiaseelan.org

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 4 Jun 2018 19:17:33 +0000

>>> From: [email-masked] [[email-masked]]
>>> ...
>>> so for inter-ledger type thinking, we're connecting systems
>>> that fundamentally care about consistency - but define its 
>>> eventuality differently - so a basic building block of an 
>>> interoperabilty or inter-domain protocol would be to 
>>> convey (and somehow reconcile) that variation in notion 
>>> of how long before we agree about an append in domain 1, 
>>> when were' 5 ledger domain hops away...

Jon, this is excellent.

I've been struggling to find words to use for what you refer to as "consistency", particularly with regards to the end-state ("eventuality").

I'm assuming that at a high level, the "eventuality" is defined as some data-string being recorded on the ledger of a BC (i.e. all distributed P2P nodes of the BC).

As you correctly intuited, the consistency-problem is more difficult for cross-ledger transactions.

A simple example with 1 entity only:  Alice wants to "move" her registered land-deed from BC1 to BC2 (direct, no hops). 

-- How many transactions does Alice's Application need to transmit? (one only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and then BC1 again).

Any thoughts how how to define  "consistency" more specific/technically?

-- thomas -- 

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jon Crowcroft [[email-masked]]
Sent: Sunday, June 03, 2018 10:12 AM
To: Thomas Hardjono
Cc: [email-masked]
Subject: Re: [Din] Minimal assumption for interoperable blockchain systems

looks sane (as did interledger) but we're missing (I think, but may be I missed it too) one of the big challenges for this compared with scaling (which is what you have to address in internetworking stuff whether subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's a fundamentally difficult piece of distributed ledgers- consistency

one thing the e2e model did for thinking (amongst many) was to think in an intensely relaxed way about consistency - IP doesn't care if the source is still where it was when the packet reaches the destination (or even first hop router. BGP doesn't care (much) about IGP convergance when announcing (or withdrawing) prefixes and (most) AS paths. WWW doesn't care if the remote page (server, site or content) are there when you add a URL to your site - all this is "fixed up later" by some eventual consistency protocol (in IPs case, TCP;  in the IGP/BGPs case the linkstate and path vector and a lot of magic pixie dust and luck; in the WWW case, search/rank&shame and later maintenance) -

so for inter-ledger type thinking, we're connecting systems that fundamentally care about consistency - but define its eventuality differently - so a basic building block of an interoperabilty or inter-domain protocol would be to convey (and somehow reconcile) that variation in notion of how long before we agree about an append in domain 1, when were' 5 ledger domain hops away...

On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

Best

-- thomas --

_______________________________________________
Din mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/din

---

From: Jehan Tremback <[email-masked]>
Date: Mon, 04 Jun 2018 15:29:34 -0400

I’m not on the cosmos team, although I do know them. I’ll try to see if
one of their team members have time to join this discussion. I don’t
have the expertise to do either protocol justice.
--
  Jehan Tremback
  [email-masked]

On Mon, Jun 4, 2018, at 3:17 PM, Thomas Hardjono wrote:
> I've been struggling to find words to use for what you refer to as
> "consistency", particularly with regards to the end-state
> ("eventuality").
>
> I'm assuming that at a high level, the "eventuality" is defined as
> some> data-string being recorded on the ledger of a BC (i.e. all distributed> P2P nodes of the BC).
>
> As you correctly intuited, the consistency-problem is more
> difficult for> cross-ledger transactions.
>
> A simple example with 1 entity only:  Alice wants to "move" her
> registered land-deed from BC1 to BC2 (direct, no hops).
>
> -- How many transactions does Alice's Application need to
> transmit? (one> only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and
> then BC1> again).
>
> Any thoughts how how to define  "consistency" more
> specific/technically?>
>
> -- thomas --
>
>
>
> looks sane (as did interledger) but we're missing (I think, but
> may be I> missed it too) one of the big challenges for this compared with
> scaling> (which is what you have to address in internetworking stuff whether
> subnetworks with IP or IGPs with BGP, or serice+content with WWW -
> that's a fundamentally difficult piece of distributed ledgers-
> consistency
>
> one thing the e2e model did for thinking (amongst many) was to
> think in> an intensely relaxed way about consistency - IP doesn't care if the
> source is still where it was when the packet reaches the
> destination (or> even first hop router. BGP doesn't care (much) about IGP convergance
> when announcing (or withdrawing) prefixes and (most) AS paths. WWW
> doesn't care if the remote page (server, site or content) are
> there when> you add a URL to your site - all this is "fixed up later" by some
> eventual consistency protocol (in IPs case, TCP;  in the IGP/BGPs case> the linkstate and path vector and a lot of magic pixie dust and
> luck; in> the WWW case, search/rank&shame and later maintenance) -
>
> differently - so a basic building block of an interoperabilty or inter-> domain protocol would be to convey (and somehow reconcile) that
> domain 1, when were' 5 ledger domain hops away...
>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> come to the forefront (assuming it doesn't get drowned-out or
> killed by> the barrage of hype about BC):
>
> interoperable> blockchain systems with regards to the notion of transaction units. In> other words, what is the “datagram” equivalent of transactions
> – namely> the transaction unit that is semantically understandable (processable)> by multiple different blockchain systems.
>
> Would love to get your thoughts on this "datagram" equivalent question> (or if this framework of thought is even the correct one).
>
>
> Best
>
>
> -- thomas --
>

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 05 Jun 2018 15:01:45 +0100

strawman - 

design a standard description for consistency algo used by each BC
(there are some semi-formal ways of describing such algos...)

form a full interconnect of blochain systems and exchange
descriptions which should form a partial order on the graph (guess)

compute which interconnects make sense and which ones cannot...

proceed....

> "consistency", particularly with regards to the end-state ("eventuality").
> 
> I'm assuming that at a high level, the "eventuality" is defined as some 
> data-string being recorded on the ledger of a BC (i.e. all distributed 
> P2P nodes of the BC).
> 
> -- How many transactions does Alice's Application need to transmit? (one 
> only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and then BC1 
> again).
> 
> subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's 
> a fundamentally difficult piece of distributed ledgers- consistency
> 
> one thing the e2e model did for thinking (amongst many) was to think in 
> an intensely relaxed way about consistency - IP doesn't care if the 
> source is still where it was when the packet reaches the destination (or 
> even first hop router. BGP doesn't care (much) about IGP convergance when 
> announcing (or withdrawing) prefixes and (most) AS paths. WWW doesn't 
> care if the remote page (server, site or content) are there when you add 
> a URL to your site - all this is "fixed up later" by some eventual 
> consistency protocol (in IPs case, TCP;  in the IGP/BGPs case the 
> linkstate and path vector and a lot of magic pixie dust and luck; in the 
> WWW case, search/rank&shame and later maintenance) -
> 
> other words, what is the “datagram” equivalent of transactions – 
> namely the transaction unit that is semantically understandable 
> (processable) by multiple different blockchain systems.
>

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 06 Jun 2018 11:09:13 +0100

oh, plus you could have semantically equivalent blockchains, but
with different performance parameters, so we can sort those on tightness
of temporal bounds on consistency....but that's easy ...

for the stuff below, this might be useful:
https://arxiv.org/pdf/1707.01747.pdf

> that's
> domain
> come

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 7 Jun 2018 13:08:46 +0000

>>> of temporal bounds on consistency....but that's easy ...

Right.  Assuming the gateway paradigm is the correct design framework, each Gateway will form a "mental picture" (graph) of its adjacent BC systems based on the exchange of the temporal parameters. 

The term "adjacent" here means other BC systems which "interoperable" (compatible) with it.

>>> https://arxiv.org/pdf/1707.01747.pdf

Thanks Jon -- I'll read through this paper.

-- thomas -- 

________________________________________
From: Jon Crowcroft [[email-masked]]
Sent: Wednesday, June 06, 2018 6:09 AM
To: Jon Crowcroft
Cc: Thomas Hardjono; [email-masked]
Subject: Re: [Din] Minimal assumption for interoperable blockchain systems