Re: [Blockchain-interop] Charter discussion

Thomas Hardjono <hardjono@mit.edu> Sun, 10 January 2021 22:16 UTC

Return-Path: <hardjono@mit.edu>
X-Original-To: blockchain-interop@ietfa.amsl.com
Delivered-To: blockchain-interop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11563A0B5B for <blockchain-interop@ietfa.amsl.com>; Sun, 10 Jan 2021 14:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 I5Y0Quvo56g2 for <blockchain-interop@ietfa.amsl.com>; Sun, 10 Jan 2021 14:16:53 -0800 (PST)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 736413A099F for <blockchain-interop@ietf.org>; Sun, 10 Jan 2021 14:16:53 -0800 (PST)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 10AMGnY3029281; Sun, 10 Jan 2021 17:16:49 -0500
Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 10 Jan 2021 17:15:49 -0500
Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by oc11expo23.exchange.mit.edu (18.9.4.88) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 10 Jan 2021 17:16:48 -0500
Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1365.000; Sun, 10 Jan 2021 17:16:48 -0500
From: Thomas Hardjono <hardjono@mit.edu>
To: Michael McBride <michael.mcbride@futurewei.com>, "blockchain-interop@ietf.org" <blockchain-interop@ietf.org>
CC: "Ned Smith (ned.smith@intel.com)" <ned.smith@intel.com>, Martin Hargreaves <martin.hargreaves@quant.network>, Thomas Hardjono <hardjono@mit.edu>
Thread-Topic: Charter discussion
Thread-Index: AQHW5DiJgEdTs1A2i0iiXZJt4RTSmKoeG7LQgANUmjE=
Date: Sun, 10 Jan 2021 22:16:48 +0000
Message-ID: <c68c0683e77b41a09a7a133268cd2f77@oc11expo23.exchange.mit.edu>
References: <46def6cd65464d6d9ea70d5148e9a60b@oc11expo23.exchange.mit.edu>, <BYAPR13MB25826CAFD00801E96F0A63BFF4AE0@BYAPR13MB2582.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB25826CAFD00801E96F0A63BFF4AE0@BYAPR13MB2582.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [73.167.220.69]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/dD-xHCoZrgQO6JqqW7JQw-uH8a8>
Subject: Re: [Blockchain-interop] Charter discussion
X-BeenThere: blockchain-interop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Blockchain Gateway Interoperability Protocol <blockchain-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/blockchain-interop>, <mailto:blockchain-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/blockchain-interop/>
List-Post: <mailto:blockchain-interop@ietf.org>
List-Help: <mailto:blockchain-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/blockchain-interop>, <mailto:blockchain-interop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jan 2021 22:16:56 -0000

Thanks Mike,

We've consciously switched terms from "blockchain" to "DLT" because the later is a broader terminology. The gateway protocol (ODAP) must work regardless of whether one or both are DLT systems (or a blockchains). 

>>> We could, alternatively, specify that the gateway api's provide interoperability between the resources any of the major database platforms

I like this suggestion, but as you correctly stated we are limiting to DLT for now. Finish what's on our plate before going for ice cream.

My understanding from IETF participation over the years and from chartering & chairing the MSEC WG (RFC 3740), a working group has the best chance of succeeding if the charter is concise, with clear deliverables and short timelines (e.g. 6 months).

I was thinking that for 2021 it would be great if we could finish two (or three) of the drafts, and only then consider new items or expand the charter. 

This does not preclude discussions and other drafts (e.g. crash recovery protocol and APIs is complex), but these cannot be deliverables until the Architecture and ODAP are finished.

The key thing is to lay the foundation (with the architecture draft and ODAP draft), and then we can build other things on top of this.

Thoughts?


Best


-- thomas --



________________________________________
From: Michael McBride [michael.mcbride@futurewei.com]
Sent: Friday, January 8, 2021 4:17 PM
To: Thomas Hardjono; blockchain-interop@ietf.org
Cc: Ned Smith (ned.smith@intel.com); Martin Hargreaves
Subject: RE: Charter discussion

Hi Thomas,

The charter is specific to DLT I assume to limit scope. A broader scope would be more compelling, but I get how ietf works.

We could, alternatively, specify that the gateway api's provide interoperability between the resources any of the major database platforms, ie. interoperability between assets in Oracle or MySQL or blockchain using odap. And have DLT interoperability as the first use case. DDGP (Distributed Database Gateway Protocol) WG or something like that. But since we are limiting this to DLT we should perhaps call out the unique characteristics of DLT's in the charter. And mention what we mean by DLTs, ie blockchains vs tangles vs other DLT's. Looks like we are only focusing on Blockchain DLT and that should be clear.

And it could be a bit confusing having a charter titled DLT gateway protocol while having DLT's listed out of scope. Perhaps saying "modifications to the existing Blockchain machinery" is out of scope would help.

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <blockchain-interop-bounces@ietf.org> On Behalf Of Thomas Hardjono
Sent: Wednesday, January 6, 2021 6:39 AM
To: blockchain-interop@ietf.org
Cc: Thomas Hardjono <hardjono@mit.edu>; Ned Smith (ned.smith@intel.com) <ned.smith@intel.com>; Martin Hargreaves <martin.hargreaves@quant.network>
Subject: [Blockchain-interop] Charter discussion


Folks,

It would be great if we could start a Charter discussion so that we can have a draft charter going into IETF110 in the first week of March.

Below is a draft text that is basically taken from our slides at the previous IETF109 SecDispatch.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fslides-109-secdispatch-draft-hardjono-blockchain-interop-arch-00&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ccb789b650f5841231ad208d8b250f67e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637455408106754663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8a2%2FrrBq5t%2Fc34TpJ7Sh8m3bY2%2FdNywuhUgpIZuUnbA%3D&amp;reserved=0

The charter needs to be tight enough that we can deliver within time (e.g. deliver the 3 drafts by end of 2021).

Looking for your inputs.

---------------------------

Proposed name:  DLT Gateway Protocol (DGP)

The goal of DGP is to develop a gateway-to-gateway protocol for virtual asset transfers between distributed ledger technology (DLT) systems.

The gateway protocol must support the unidirectional secure transfer of  the digital representation of an asset between two gateways fronting DLTs, satisfying requirements of atomicity and non-repudiation, and agnostic to the higher-layer economic value of the asset. It must support cases where one or both DLT systems behind the gateways are private (where the interior resources are not externally accessible). Additionally, APIs defined must support cases where one gateway is fronting a Legacy system.

The gateway protocol must satisfy the well-known ACID properties. Atomicity: a transfer must either commit or entirely fail (failure means no change to asset ownership). Consistency: a transfer (commit or fail) must always result in the asset located in one DLT only. Isolation: while a transfer is occurring, the asset ownership cannot be modified (no double-spend). Durability: once a transfer is committed, it must remain so regardless of subsequent gateway crashes.

The gateway protocol will be based on the classic 2-Phase Commit (2PC or 3PC) design.  The interaction channel between the APIs endpoints at the gateways is assumed to be protected using TLS1.2 (TLS1.3).

Proposed Deliverables (2021):
-- Architecture document
-- Gateway protocol document defining APIs and endpoint definitions (ODAP)
-- Use-cases & Requirements document

Optional:
-- Asset Profile JSON specification
-- Log-metadata JSON specification (crash recovery)

Existing drafts:
-- draft-hardjono-blockchain-interop-arch-01
-- draft-hargreaves-odap-01
-- draft-sardon-blockchain-gateways-usecases-00
-- draft-sardon-blockchain-interop-asset-profile-00


Out of scope:
-- Blockchains and DLT systems
-- Consensus & BFT protocols, PoW, PoS, etc.
-- Cryptocurrencies, tokenization, etc.
-- Incentive mechanisms, economic models; etc.
-- Zero-knowledge proof (ZKP) protocols
-- Authentication & Authorization protocols
-- Concurrency control algorithms
-- Identity management & privacy, etc. etc.


---------------------------


Best


-- thomas --


--
Blockchain-interop mailing list
Blockchain-interop@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ccb789b650f5841231ad208d8b250f67e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637455408106754663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=rGn98%2FTW%2BOFS%2FvnaSXMnMXocowkuLlst24L5Jv8Is1o%3D&amp;reserved=0