Re: [Din] Minimal assumption for interoperable blockchain systems

Jehan Tremback <jehan@altheamesh.com> Sun, 03 June 2018 21:50 UTC

Return-Path: <jehan@altheamesh.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 6D780126BF3 for <din@ietfa.amsl.com>; Sun, 3 Jun 2018 14:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 efEg-xQwx1nB for <din@ietfa.amsl.com>; Sun, 3 Jun 2018 14:50:07 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E88C124234 for <din@irtf.org>; Sun, 3 Jun 2018 14:50:07 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D1C5721149 for <din@irtf.org>; Sun, 3 Jun 2018 17:50:05 -0400 (EDT)
Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sun, 03 Jun 2018 17:50:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gyUM6U xHAIdAoFqyXXZ/0GlvI1v5LfQnJh+ZnqZDh18=; b=jmpHveVHmNRsJAm0UcV9Tb QsdoXOZ7NqCncn4a3SaCgkF3Ul9a/FnZl72uHDrwLCHSQFyMjvoFbQJGOU8YCk4e SaYVM+DlUAkEhaKwrwKvIySvyqHUYENIlsWeAangDWqZaBMPTVbHTzGBCiDu60eG 7vFDIERjZlcFAkleh38LlbxJuf7fFXLLtft0X3t5Ol/MElxVoSfHTg6jv64RcARO K1gyrbv3N9sIP/CpWmOMgWR8IT1GnPZt5fqmhNpr6GQDspKfZ9Z+WuqhqU2eMzSd +ptmR8vkGZ4pqs7E2/8tzGISvhqCDBO7WCeQAr9oOKfNRUoyGB4RybXplM2Uq02w ==
X-ME-Proxy: <xmx:jWIUW0jKKl7reT7fwz_VB4cO6lYeUkBTWXOaSXwn1EY9HdOED-KYVw>
X-ME-Proxy: <xmx:jWIUW63edE3NmQnB_qDsxBPDxxAIcvgzzS0479a40cbGafRocmZciw>
X-ME-Proxy: <xmx:jWIUW2hzj_X-RLkAwtHgAe2BPIkSouS3aUW59yPq2O-vqlLujJlSbw>
X-ME-Proxy: <xmx:jWIUWyfhOVJNdG-IQfrcKWKM0JtGmHo1PWBtyQxKQLmU5HKNwPr4EA>
X-ME-Proxy: <xmx:jWIUWxn7zOy1PixU9RqRwq0tOS9PUJZWt8jMqcYC8erc-bwGNyHDfA>
X-ME-Proxy: <xmx:jWIUW_nW4AkJ-TAYQSsruHmbZRji486Cu-di7kILR9vi4PpnaNguKg>
X-ME-Sender: <xms:jWIUW9clRUnDeVn4myp7bFsq2fWMEh-MT34Pyb2vJpVqwUvKSOv2oQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 474FEBA50D; Sun, 3 Jun 2018 17:50:05 -0400 (EDT)
Message-Id: <1528062605.1487185.1394957608.1F05953C@webmail.messagingengine.com>
From: Jehan Tremback <jehan@altheamesh.com>
To: din@irtf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_152806260514871855"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6
In-Reply-To: <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
Date: Sun, 03 Jun 2018 17:50:05 -0400
References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> <CAEeTejLDkAq_K_Yv0Ga-SArQH-AakK1FdG=bFC8oquYbtUzTkg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/9oDOX6qnUMlGnIEUsCsJ0IryAgs>
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 21:50:11 -0000

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