Re: [Din] Minimal assumption for interoperable blockchain systems

Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk> Sun, 03 June 2018 14:12 UTC

Return-Path: <crowcroft@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 4F14E127078 for <din@ietfa.amsl.com>; Sun, 3 Jun 2018 07:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level:
X-Spam-Status: No, score=-1.403 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ZfPUFOFKSc4O for <din@ietfa.amsl.com>; Sun, 3 Jun 2018 07:12:53 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 A1AED126CD8 for <din@irtf.org>; Sun, 3 Jun 2018 07:12:52 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id x2-v6so9965357wmh.5 for <din@irtf.org>; Sun, 03 Jun 2018 07:12:52 -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=Ss/9gH3qTpDr7nYOcqEG1bySPTEnkLUMkz3oxhHOECQ=; b=fZKhxx52vkUaNMlu73/ZB64Llj2ocm0A8fG5FfgtOhcsRAQtMQS6QM1c3HCLIHjJ5N Sf5SIVqt2OAYPXVWbtI3u5XPuDNX8BpOh893LO45WA2xY3i1IzaPEuJ2uVOpAtpjXFUG 6BfDKHTDLR/roIn0kcITq32i7x4F+C5GqZlrycwGvpEvuVahexcwPG8pRQDrOYB46yVC CjOLPzUIBXlYYiYwA94MxUwyFd3i6gG69FEiHtJFCIgoLpF91u6J9zgEN9swPzBO3jAO EqAqupH52Dhl9i43XtOzJaRyRTZIwvmNpr6jFhPUEObdsg0pqv1p0nvrIqtSh1HEfVZK Kwvw==
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=Ss/9gH3qTpDr7nYOcqEG1bySPTEnkLUMkz3oxhHOECQ=; b=UGRrXEtrPNi4iAqhqMWk/kMmTgnqjf8IHpugVRvjljDYbid2V5CoeU4puPj7egAuyS Y6veK2egDMp40nHs38zO9f8ZcxXjwMEAsIM3q++BCx98cCayqEyOipvD4HBeFBsx6o5X QR8KFwXegzKXXPvJIH8NvxPaXtzjvnH6vC8ErInluhnm1vdG4ExZaVXMGAaroawsvQO5 vTQyuVrA9fWzKkNYCGmVSBSKpy4xda86atqCndgL7xh8cGF2QppLNP8k7+wtUyBAx4F9 Gwgj986VfRLUt5mMD8Q4jV8WUFCe17TrarPUp9/kFmTruNekGJY6M/TGnLjS9lkIiCeo 0aKA==
X-Gm-Message-State: ALKqPweyl9B1qdLGnsvBX6UGFW6e9NblYtHrxIHKaYq1PwCH7ADcuq3e 5hH+VjjggGwTQTR48gRl5A5tAy/wl8gpVVMB7o8=
X-Google-Smtp-Source: ADUXVKI8fq6v0MoXpmkEPF4zKxo8QZbTyWb8k7WiWWmkkphTfpRn1bNIgzpLYbje2lfcaL4RWOUknf6g43nG+WCUhrM=
X-Received: by 2002:a1c:8ec1:: with SMTP id q184-v6mr7469382wmd.104.1528035170800; Sun, 03 Jun 2018 07:12:50 -0700 (PDT)
MIME-Version: 1.0
Sender: crowcroft@gmail.com
Received: by 2002:a1c:589:0:0:0:0:0 with HTTP; Sun, 3 Jun 2018 07:12:50 -0700 (PDT)
In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>
From: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Date: Sun, 3 Jun 2018 15:12:50 +0100
X-Google-Sender-Auth: DqqHSN_bm1jjXJ_SkbUfS8L47Uo
Message-ID: <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
To: Thomas Hardjono <hardjono@mit.edu>
Cc: "din@irtf.org" <din@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000008f56b9056dbd6999"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/u6tkG9_A9SubUF9BHQZuMYFl7xc>
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: Sun, 03 Jun 2018 14:12:56 -0000

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
>