Re: [Din] Minimal assumption for interoperable blockchain systems

Thomas Hardjono <hardjono@mit.edu> Mon, 04 June 2018 19:17 UTC

Return-Path: <hardjono@mit.edu>
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 D4539130DDB for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 12:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 lXVHCKrivZyB for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 12:17:44 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F93E130DCE for <din@irtf.org>; Mon, 4 Jun 2018 12:17:44 -0700 (PDT)
X-AuditID: 12074424-1bdff700000014b0-f8-5b1590572617
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 95.45.05296.750951B5; Mon, 4 Jun 2018 15:17:43 -0400 (EDT)
Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w54JHgYo012073; Mon, 4 Jun 2018 15:17:42 -0400
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w54JHLqe004464; Mon, 4 Jun 2018 15:17:40 -0400
Received: from W92EXCAS23.exchange.mit.edu (18.7.71.38) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 4 Jun 2018 15:17:15 -0400
Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.177]) by w92excas23.exchange.mit.edu ([18.7.71.38]) with mapi id 14.03.0352.000; Mon, 4 Jun 2018 15:17:34 -0400
From: Thomas Hardjono <hardjono@mit.edu>
To: "jon.crowcroft@cl.cam.ac.uk" <jon.crowcroft@cl.cam.ac.uk>
CC: "din@irtf.org" <din@irtf.org>
Thread-Topic: [Din] Minimal assumption for interoperable blockchain systems
Thread-Index: AQHT+0CmDYm4GElA7Ua0jKaUNEZ41qRO1nUAgAFpmmc=
Date: Mon, 4 Jun 2018 19:17:33 +0000
Message-ID: <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu>
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
In-Reply-To: <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [18.7.71.71]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsUixG6nohs+QTTa4NZrOYulH/eyWDy4+ITJ gclja+txFo/JGw+zBTBFcdmkpOZklqUW6dslcGVsn36DqeC9YsWcxzfYGxjPS3cxcnBICJhI fDkHZHJxCAksZpI42L+RHcLZzyixfGY/E4RzlFHiz5Q2qMx2IGfiPpYuRk4gZxWjxL/v7iA2 m4CGRNuPXnYQW0TAVuLgxcNgNrOAokTX5CYmEFtYwEvi1L2VTBA13hKffp1nhLCtJA59+Q5m swioSJycfhKshlcgSOL+io9sEIunM0r8/n2aDSTBKRAosXfSBLAGRgExie+n1jBBLBOXuPVk PpgtISAosWj2HmYIW0zi366HbBC2nMSE3xOhjjOQeH9uPjOErS2xbOFrZojFghInZz5hmcAo MQvJ2FlIWmYhaZmFpGUBI8sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2M4Ch0 UdnB2N3jfYhRgINRiYdXw0o0Wog1say4MvcQoyQHk5Iob3waUIgvKT+lMiOxOCO+qDQntfgQ owQHs5II7+kCoBxvSmJlVWpRPkxKmoNFSZw3dxFjtJBAemJJanZqakFqEUxWhoNDSYK3vR+o UbAoNT21Ii0zpwQhzcTBCTKcB2j4NJAa3uKCxNzizHSI/ClGY447bT09zBwd76f0MAux5OXn pUqJ85qDlAqAlGaU5sFNgyRST/5XjOJAzwnzPu0DquIBJmG4ea+AVjEBrXpWIQyyqiQRISXV wNjx4p6KQMbjlavf21yLmx29geVdR3qOwNG1KyIjpc1bpn74++HlFs7FlmZ67t2zi7m/LWIJ +VQqoySvmVX6P2+/w5mOM4xmJpLtHmz8UT8dn9i6/reoMWt9rKC07tGE/V/VzV5qO75UtWH9 3reYa92FWxohNfd11WJvSb3y5VnO3DNzwpmSpUosxRmJhlrMRcWJAJOX5eR/AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/7eDvWfryDsl4oldpgU3JxZS6TlY>
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:17:52 -0000

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