Re: [Din] Minimal assumption for interoperable blockchain systems

Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk> Mon, 04 June 2018 07:19 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 DA5161241F8 for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 00:19:49 -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 bZRmE0TsLwm5 for <din@ietfa.amsl.com>; Mon, 4 Jun 2018 00:19:47 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 2B61012421A for <din@irtf.org>; Mon, 4 Jun 2018 00:19:46 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id d8-v6so10805023wro.4 for <din@irtf.org>; Mon, 04 Jun 2018 00:19:46 -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=kwLLxdflOqhzvZgUUMeydWbeU6J/fWXtSjNDIqxdIW8=; b=l+7jHXVugkl5gPCV6R9MhmR1OlFyRsr8PN/YT8RE+WXGC2joYtSmeIWTAohbydiUTW OZGtXJrP2KLVpbomZITFyVn+my8IEp2VZl/2AVEPHPE5IpxC5Myi83GAAW70FfhyjL0X x64YYlYiqePLB79i7XY4fWO20GiU1tGKPqDTxmUbeCbvPYxSS99CWRYJ8cc2xLYnzbYj 6E12DvNb0B5eVzzI4V3IB29kHaF+LGn2hzy2lmRhhf/QaL8kabCv13S7Y+zc2onhMEWN HIHuobTV/2GYhpaiMEhY8ZWw4idjmydeFUsGf/sKgTonk6UKz1WlNzJUdJPg36U/kSuD ecIw==
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=kwLLxdflOqhzvZgUUMeydWbeU6J/fWXtSjNDIqxdIW8=; b=b5ufGfzfQDv0S4nM3/B+OasS6ukwJgGpt42ACUbVjWH1sVmgNezNgSWJ4nl0gsVU+6 QQuxiUhzVuiZjmvhlaUN2NIJn6WAok2+l37UeurEcP2v/EXo6iObOPFRH/0qqr/9ajbU iVRtP390UEAJduYgsM6+DqtkmFvOx2IxzEIHS1EAp/wVvrSfmx+3TPEly19XmAdJpQgk 2ghNPbXvhG2d9/mSYFhiQ8j2h/bIUBDLBbg0qTMnwdgytEiIW0ZE1bmkKhLCfKIdCI4R 3V/h+6yckbg/h+Rq+nHNWuA2JKRIsadbYKLgZPtaACgnVykfvWXNkgHGjOMjzLitCnQz Gaiw==
X-Gm-Message-State: ALKqPwczK6E3ANTUciU5D6Ra8diOrr6oByXA8oQ6ndY+0TUiR+02HzvU 5huSKksdAr2qU4l5w37v1sYCzJgqe8g7aikpCj0=
X-Google-Smtp-Source: ADUXVKJqcHjELLxwDs9kM04uQbbB2OgyX4/S12jE/tCpl5Cgjt3fB5MNYFlIuBAJo9ADsEdFxaEWuX81qznwtJXS68o=
X-Received: by 2002:adf:e084:: with SMTP id c4-v6mr14696265wri.199.1528096785244; Mon, 04 Jun 2018 00:19:45 -0700 (PDT)
MIME-Version: 1.0
Sender: crowcroft@gmail.com
Received: by 2002:a1c:589:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 00:19:43 -0700 (PDT)
In-Reply-To: <1528062605.1487185.1394957608.1F05953C@webmail.messagingengine.com>
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com> <1528062605.1487185.1394957608.1F05953C@webmail.messagingengine.com>
From: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Date: Mon, 4 Jun 2018 08:19:43 +0100
X-Google-Sender-Auth: ReG9-ITI9EUAjC_MdgAKEUHsk_I
Message-ID: <CAEeTejKSchACrB1qX6P0VOSfq2Gz0k_UppMBtKjskBztidz=Sg@mail.gmail.com>
To: Jehan Tremback <jehan@altheamesh.com>
Cc: din@irtf.org
Content-Type: multipart/alternative; boundary="0000000000001124f1056dcbc287"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/Ov0WJryO2MOcH-S14B4pl559SS8>
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 07:19:50 -0000

i hadn't been tracking where the tendermint stuff had been going - in your
current ibc spec, you implement causal ordering (It looks pretty much like
virtual synchrony, no?) - this is fine in terms of semantics, but i'm
worred about (as per my prev. ressponse) scalability....

On Sun, Jun 3, 2018 at 10:50 PM, Jehan Tremback <jehan@altheamesh.com>
wrote:

> No citation of https://github.com/cosmos/cosmos-sdk/tree/develop/docs/
> spec/ibc? This was the original work along these lines from around 2
> years ago IIRC. Should be in production soon if they meet their launch
> schedule. I'd appreciate a comparison with tradecoin and an analysis of
> what trade-in does differently.
>
> --
>   Jehan Tremback
>   jehan@altheamesh.com
>
>
>
> On Sun, Jun 3, 2018, at 10:12 AM, Jon Crowcroft 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
> <https://www.irtf.org/mailman/listinfo/din>
>
>
>
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din
>
>