Re: [Din] Minimal assumption for interoperable blockchain systems
Jehan Tremback <jehan@altheamesh.com> Mon, 04 June 2018 19:29 UTC
Return-Path: <jehan@altheamesh.com>
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 388DD130DCC for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 12:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 o_yBDCbXKJgR for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 12:29:35 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E1C130DC0 for <din@irtf.org>; Mon, 4 Jun 2018 12:29:35 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9DEA121E3E for <din@irtf.org>; Mon, 4 Jun 2018 15:29:34 -0400 (EDT)
Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Mon, 04 Jun 2018 15:29:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZRwjEC HtNyWsFCp+tHkRm26lN3BEYEm+PWayNCGjldY=; b=NzP6nuVQDqplawrPG7t6o2 1ZsJxYwW8nWcuUaI0WbcV+fGJLvFRH6C7nnPe9U5YSOFJgL5c98AYDLtN4t1o0qf x1Tw6trpTDx/CWeMJHamRwx3XI/plwXIu0Ma/l+MJGmETSB7u68jhfZNg96UlvIs dAllyJw0zi/88C097RK0ZjptitJJO1irmsmsDRaJoTK6cFtft4X41kH1fqM7wUVi 68XCgq/Zh5aLcZ7pUaWrJMmO9bjOGi2E7m/Az//SGT1Ia2/E2XmCXT8OzigBgA/H Ongdq4ZvpSly7bKw6B7aOsqUGC7/eAxJR+/pl/pXe3xkCmJQ0tdx2+QQREy5zNRA ==
X-ME-Proxy: <xmx:HpMVW2o135vJu_HZJdbNoWa14E72KSTHFSwZuTG1uBI4bOPJbFnzXQ>
X-ME-Proxy: <xmx:HpMVWy6yphuB6K1D6HSq8QmOzMj7ifMgcBdQB4PLuyaHCtCb7wl17A>
X-ME-Proxy: <xmx:HpMVW4WyBpSENAk-I2uxPsJXNAdd7Uq3M9wCPz7xotueNLKWogUQEA>
X-ME-Proxy: <xmx:HpMVW4vLt_7yTThbOonO36l1tPcMQoDhQV-QXEZis8XTEVnk-IrWyQ>
X-ME-Proxy: <xmx:HpMVW1qomYDiBm7VCqk-BC2Z-Vhe7raw6IpqxLUVlBtIkDKBUgVYYQ>
X-ME-Proxy: <xmx:HpMVW8jtzJo3q8nFbmYcwjitTeBU5UC9hmGXePHn41js16pPFQJduQ>
X-ME-Sender: <xms:HpMVWx_JGBqB8JN7p0KhX0ft-4uzkqXgMMvgGwvQRU5NxvUb_GI2Vw>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3B23E419B; Mon, 4 Jun 2018 15:29:34 -0400 (EDT)
Message-Id: <1528140574.155626.1396147592.6E286D5C@webmail.messagingengine.com>
From: Jehan Tremback <jehan@altheamesh.com>
To: din@irtf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_15281405741556261"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-fb4a77ea
Date: Mon, 04 Jun 2018 15:29:34 -0400
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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/TG-uKzp5D8MIKWtcFMCGaTkE3SM>
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: Mon, 04 Jun 2018 19:29:38 -0000
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 jehan@altheamesh.com On Mon, Jun 4, 2018, at 3:17 PM, Thomas Hardjono wrote: > > >>> 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 > _______________________________________________ > Din mailing list > 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