Re: [Din] Minimal assumption for interoperable blockchain systems

Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk> Tue, 05 June 2018 14:01 UTC

Return-Path: <Jon.Crowcroft@cl.cam.ac.uk>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1A2131074 for <din@ietfa.amsl.com>; Tue, 5 Jun 2018 07:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3VZdhqN-ZAE for <din@ietfa.amsl.com>; Tue, 5 Jun 2018 07:01:48 -0700 (PDT)
Received: from mta2.cl.cam.ac.uk (mta2.cl.cam.ac.uk [IPv6:2001:630:212:200::25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D812131055 for <din@irtf.org>; Tue, 5 Jun 2018 07:01:48 -0700 (PDT)
Received: from ely.cl.cam.ac.uk ([2001:630:212:238:230:48ff:fefe:c314]) by mta2.cl.cam.ac.uk with esmtp (Exim 4.86_2) (envelope-from <Jon.Crowcroft@cl.cam.ac.uk>) id 1fQCWv-0005Th-VA; Tue, 05 Jun 2018 15:01:45 +0100
From: Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>
To: Thomas Hardjono <hardjono@mit.edu>
cc: "jon.crowcroft@cl.cam.ac.uk" <jon.crowcroft@cl.cam.ac.uk>, "din@irtf.org" <din@irtf.org>
In-reply-to: <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu>
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com> <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu>
Comments: In-reply-to Thomas Hardjono <hardjono@mit.edu> message dated "Mon, 04 Jun 2018 19:17:33 -0000."
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <5853.1528207305.1@ely.cl.cam.ac.uk>
Content-Transfer-Encoding: 8bit
Date: Tue, 05 Jun 2018 15:01:45 +0100
Message-Id: <E1fQCWv-0005Th-VA@mta2.cl.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/BBHvEj8EKhtLfiwNPJMfOwc6o9Q>
Subject: Re: [Din] Minimal assumption for interoperable blockchain systems
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2018 14:01:51 -0000

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

> >>> From: crowcroft@gmail.com [crowcroft@gmail.com]
> >>> ...
> >>> 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: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon 
> Crowcroft [jon.crowcroft@cl.cam.ac.uk]
> Sent: Sunday, June 03, 2018 10:12 AM
> To: Thomas Hardjono
> Cc: din@irtf.org
> 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...
> 
> which reminds me, am I allowed to coin that term "ledgerdomain" ? :-)
> 
> On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono 
> <hardjono@mit.edu<mailto:hardjono@mit.edu>> 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.
> 
> 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 --
> 
> _______________________________________________
> Din mailing list
> Din@irtf.org<mailto:Din@irtf.org>
> https://www.irtf.org/mailman/listinfo/din
>