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 >
- Re: [Din] Minimal assumption for interoperable bl… Jon Crowcroft
- Re: [Din] Minimal assumption for interoperable bl… Thomas Hardjono
- [Din] Minimal assumption for interoperable blockc… Thomas Hardjono
- Re: [Din] Minimal assumption for interoperable bl… Jon Crowcroft
- Re: [Din] Minimal assumption for interoperable bl… Jehan Tremback
- Re: [Din] Minimal assumption for interoperable bl… Jon Crowcroft
- Re: [Din] Minimal assumption for interoperable bl… Arjuna Sathiaseelan
- Re: [Din] Minimal assumption for interoperable bl… Thomas Hardjono
- Re: [Din] Minimal assumption for interoperable bl… Jehan Tremback
- Re: [Din] Minimal assumption for interoperable bl… Jon Crowcroft