Re: [Din] Minimal assumption for interoperable blockchain systems

Thomas Hardjono <hardjono@mit.edu> Thu, 07 June 2018 13:08 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 431D8130E9D for <din@ietfa.amsl.com>; Thu, 7 Jun 2018 06:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 IeMHPf2cg010 for <din@ietfa.amsl.com>; Thu, 7 Jun 2018 06:08:56 -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 E530E130E60 for <din@irtf.org>; Thu, 7 Jun 2018 06:08:55 -0700 (PDT)
X-AuditID: 12074424-fbbff700000019fe-b0-5b192e66da7f
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 9E.68.06654.66E291B5; Thu, 7 Jun 2018 09:08:54 -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 w57D8smI020763; Thu, 7 Jun 2018 09:08:54 -0400
Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w57D8k4B008108; Thu, 7 Jun 2018 09:08:51 -0400
Received: from W92EXCAS21.exchange.mit.edu (18.7.71.34) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jun 2018 09:07:57 -0400
Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.177]) by W92EXCAS21.exchange.mit.edu ([18.7.71.34]) with mapi id 14.03.0352.000; Thu, 7 Jun 2018 09:08:47 -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+0CmDYm4GElA7Ua0jKaUNEZ41qRO1nUAgAFpmmeAAbf3gIABUV2AgAF/ANM=
Date: Thu, 7 Jun 2018 13:08:46 +0000
Message-ID: <5E393DF26B791A428E5F003BB6C5342AFD23D9E9@OC11EXPO33.exchange.mit.edu>
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com> <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> <E1fQCWv-0005Th-VA@mta2.cl.cam.ac.uk>,<E1fQVNR-0001Qo-9c@mta2.cl.cam.ac.uk>
In-Reply-To: <E1fQVNR-0001Qo-9c@mta2.cl.cam.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [18.7.71.72]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLKsWRmVeSWpSXmKPExsUixG6nopumJxlt8H62tcXSj3tZLB5cfMLk wOSxtfU4i8fkjYfZApiiuGxSUnMyy1KL9O0SuDL6bi5hKphrVLHz2Vz2BsYJGl2MnBwSAiYS XfM3sXcxcnEICSxmkthytAPK2c8osfHnXGYI5xijxM7FrVDONkaJiy1HoZxVjBI3p55hAhnG JqAh0fajlx3EFhGwlZh5YyEjiM0soCjRNbkJrEZYwEvi1L2VTBA13hKffp1nhLD9JN6/ncMG YrMIqEgcu7kQaAEHB69AkMSFK94Qu9YxSczp38ACUsMpYCTxa+EhZhCbUUBM4vupNUwQu8Ql bj2ZzwTxnKDEotl7mCFsMYl/ux6yQdhyEl83dbFD1BtIvD83nxnC1pZYtvA1mM0L1Hty5hOW CYwSs5CMnYWkZRaSlllIWhYwsqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdfLzSzRS00p3cQI jkMXlR2M3T3ehxgFOBiVeHhvPBSPFmJNLCuuzD3EKMnBpCTKu0hZIlqILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCG/iJbFoId6UxMqq1KJ8mJQ0B4uSOG/uIsZoIYH0xJLU7NTUgtQimKwMB4eS BG+SrmS0kGBRanpqRVpmTglCmomDE2Q4D9DwMB2gGt7igsTc4sx0iPwpRmOOO209PcwcHe+n 9DALseTl56VKifPGgowTACnNKM2DmwZOpZzMoq8YxYGeE+Y1AqniAaZhuHmvgFYxAa3yYAZb VZKIkJJqYKz6Z3eGy7FCevZLZQWd7EuugUY2eUrn9t2/XZJRIbt90YVEQ+4d/BpVhV1mEomc XyZcOv/Y7oZRZHSciYHLhEn3w/LlD19zWRyqJ65R+EJrkoxRmautgVyKurX/xhMPVM7P/d/D vfeQfJb3zI4/6zyyrqTN9Sx9zv3s3X7Flg+Rpul9jA5PlViKMxINtZiLihMBS/fvJoADAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/tbkooEwpmLM6APHDuXj7MX3leZQ>
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: Thu, 07 Jun 2018 13:09:00 -0000

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

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

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.


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

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


-- thomas -- 


________________________________________
From: Jon Crowcroft [Jon.Crowcroft@cl.cam.ac.uk]
Sent: Wednesday, June 06, 2018 6:09 AM
To: Jon Crowcroft
Cc: Thomas Hardjono; din@irtf.org
Subject: Re: [Din] Minimal assumption for interoperable blockchain systems

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

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