Re: [Din] Minimal assumption for interoperable blockchain systems

Arjuna Sathiaseelan <arjuna.sathiaseelan@cl.cam.ac.uk> Mon, 04 June 2018 12:20 UTC

Return-Path: <arjuna.sathiaseelan@gmail.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 3F79812D889 for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 05:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 G-vOAz-VqG8w for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 05:20:45 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 4EB0F126DFF for <din@irtf.org>; Mon, 4 Jun 2018 05:20:45 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id p185-v6so5500264itp.4 for <din@irtf.org>; Mon, 04 Jun 2018 05:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Rnjsyca93mE1kN8X7V83AfkJDh1s9NxW8AjkjvXzPK8=; b=D/R6eYjNBpPfzCreO2b1B5+W7w7RAbcyZEa7+Xa0oPElmcZCpuPkzd3Cm0UPXNaY6A 1TFOHoYU8RIX0RpXgJNfTIB0C6aGOFm4xHB6Si2t2hx7a6Oc9s4DwHtkDCxQukA91t5N 2fmFKbG+VXOC0ONexMorntjXGH7FcgGNNjcOB34cvv1UQ+bfeuxTs4FTeV3ZA0MfxUpj 0MZ3oCUrgLvhkV+s3i2jU8QFuXCesd6OGpG5QlnQjSkSHpr4ShzpOtK5G2GzuddPGFq4 ZgvZTX+8lWsNXvU0bCFDxGlWc2Aq8XDgfgI0KLUICzsORGOmqX6p0lRVsr/zdJVkvuzc Pgaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Rnjsyca93mE1kN8X7V83AfkJDh1s9NxW8AjkjvXzPK8=; b=IFR9cznQ4Gxo+yFBYgBslv8/QTPMb2i58g8ZukOXcvyv+dsgcZL95t5eRR1nt2oxKn 1QrpeDzz57O15zTxRMXP6nOBPaExRoohrWYwQxCmjASWya4vOryyPFQF7lGSstXbBsO3 snc5dnA4ML8+uoFedGE94KsLJKB1qpGzGzyEoVnd79cBiQ50m73d9V6jb/Dha3SsIH5N yN8qcC0LBwGMN9rCSGBFDFiw9/FnjDWPilw8B9Fq5S7cEfEZLFTnnL9ia5PvB9wx7UEr dRhXVkqxgMMeHle8HtT/TEIrSwQ25vvuETJLLflL/HE1R2JoMod4QE2E3O8p8zDl4Z0M poYw==
X-Gm-Message-State: ALKqPwc5ToMucQUW9O2C93JAo8GPCSwfjg95UrLBCvupdVBSJKvte8wi UKRU1QOR5UTDF6uNPhjl9nGogW2S3Odl6rFvLkU=
X-Google-Smtp-Source: ADUXVKJhXpeaGiGJ6V9R54zfXtHj/kGcSiTL6DZlBcPGeXQziqUrSDoQ7phV+S0/a3OCvRWmT0gH0xtyltR4BSKLOfY=
X-Received: by 2002:a24:7c13:: with SMTP id a19-v6mr13898131itd.81.1528114844578; Mon, 04 Jun 2018 05:20:44 -0700 (PDT)
MIME-Version: 1.0
Sender: arjuna.sathiaseelan@gmail.com
Received: by 2002:a4f:4543:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 05:20:43 -0700 (PDT)
In-Reply-To: <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
From: Arjuna Sathiaseelan <arjuna.sathiaseelan@cl.cam.ac.uk>
Date: Mon, 4 Jun 2018 13:20:43 +0100
X-Google-Sender-Auth: YB80dizsL72E6_nqPteQQKpi58Y
Message-ID: <CAPaG1AmPQeq43PV=GQ=KhpeJUDMyf-AHgNvQNc47RtmrrNVwCw@mail.gmail.com>
To: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Cc: Thomas Hardjono <hardjono@mit.edu>, "din@irtf.org" <din@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000007cbc1b056dcff6bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/jbCP_poXF2WRuFRMxz0b0hlcRCE>
Subject: Re: [Din] Minimal assumption for interoperable blockchain systems
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.22
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 12:20:48 -0000

i think its not just the tech (consistency) - also handling governance
across DAOs is a major issue..

regards

On 3 June 2018 at 15:12, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk> wrote:

> 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> 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
>> https://www.irtf.org/mailman/listinfo/din
>>
>
>
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din
>
>


-- 

Arjuna Sathiaseelan | http://sathiaseelan.org