Subject: [Blockchain-interop] Charter discussion

From: Thomas Hardjono <[email-masked]>
Date: Wed, 6 Jan 2021 14:39:23 +0000

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://datatracker.ietf.org/meeting/109/materials/slides-109-secdispatch-draft-hardjono-blockchain-interop-arch-00

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 --

---

From: Miguel Correia <[email-masked]>
Date: Wed, 6 Jan 2021 18:09:11 +0000

Hi,

The proposal is fully inline with what we have been discussing, so I fully agree.

A few details:
- Should we include the draft-belchior-… in the list of drafts?
- When you mention TLS, does it make sense to mention also OpenID Connect?
- When you say "on the classic 2-Phase Commit (2PC or 3PC) design”, we could generalize a bit to “on an atomic commit protocol (e.g., 2PC)”

Best,
Miguel

> On 6 Jan 2021, at 14:39, Thomas Hardjono <[email-masked]> wrote:
> 
> 
> Folks,
> 
> -- 
> Blockchain-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/blockchain-interop

---

From: Rafael Belchior <[email-masked]>
Date: Wed, 06 Jan 2021 18:27:46 +0000

Hello All,

Generally, LGTM. If we state that we are using 2PC OR 3PC it would be 
good to state why - in particular, 3PC might make sense in a scenario 
with more than 2 gateways and more than 1 asset transfer, because it 
handles coordinator crashes.

Regarding the draft on crash recovery, this draft not only shows a 
format for logs that can also be applied to the messaging flow but 
depicts the whole gateway recovery protocol. I believe it is a critical 
component accounting for the gateways' robustness, and thus should be 
included.

Cheers,
Rafael

> - When you say "on the classic 2-Phase Commit (2PC or 3PC) design”, we
> could generalize a bit to “on an atomic commit protocol (e.g., 2PC)”

I believe that if we specify

>> 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.
>> 
>> 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.
>> 
>> 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).
>> 

-- 
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 6 Jan 2021 19:12:14 +0000

Thanks  Miguel,

> - Should we include the draft-belchior-… in the list of drafts?

I agree with Rafael, having a crash-recovery draft is important -- particularly defining (a) how a self-healing gateway can pick-up from the crash point, and (b) defining standard REST APIs for the log-storage.

> - When you mention TLS, does it make sense to mention also OpenID

Probably not, because identity management is out of scope.  I think we are assuming that Clients will be wielding some kind of authorization-token (e.g. OAuth2.0; id_token in OIDC) when accessing APIs at the gateway.

> Rafael:
> If we state that we are using 2PC OR 3PC it would be
> with more than 2 gateways

Good point.  Right now the basic building block is a unidirectional 1-to-1 (no splitting of assets), so 2PC should be enough.

If we design the ODAP protocol correctly, it should permit unidirectional 1-to-N splitting (i.e. involving multiple receiver gateways). In this case, we will need 3PC.

-- thomas --

________________________________________
From: Rafael Belchior [[email-masked]]
Sent: Wednesday, January 6, 2021 1:27 PM
To: Miguel Correia
Cc: Thomas Hardjono; Ned Smith ([email-masked]); [email-masked]; Martin Hargreaves
Subject: Re: [Blockchain-interop] Charter discussion

Hello All,

Cheers,
Rafael

---

From: Michael McBride <[email-masked]>
Date: Fri, 8 Jan 2021 21:17:01 +0000

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 <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Wednesday, January 6, 2021 6:39 AM
To: [email-masked]
Cc: Thomas Hardjono <[email-masked]>; Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>
Subject: [Blockchain-interop] Charter discussion

Folks,

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

Looking for your inputs.

Optional:

Existing drafts:

Out of scope:

Best

-- thomas --

-- 
Blockchain-interop mailing list
[email-masked]
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

---

From: Thomas Hardjono <[email-masked]>
Date: Sun, 10 Jan 2021 22:16:48 +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 [[email-masked]]
Sent: Friday, January 8, 2021 4:17 PM
To: Thomas Hardjono; [email-masked]
Cc: Ned Smith ([email-masked]); Martin Hargreaves
Subject: RE: Charter discussion

Hi Thomas,

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Wednesday, January 6, 2021 6:39 AM
To: [email-masked]
Cc: Thomas Hardjono <[email-masked]>; Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>
Subject: [Blockchain-interop] Charter discussion

Folks,

Looking for your inputs.

Optional:

Existing drafts:

Out of scope:

Best

-- thomas --

---

From: Michael McBride <[email-masked]>
Date: Tue, 12 Jan 2021 19:03:16 +0000

Hi Thomas,

The problem (or feature) with using the DLT term is that implies we are also including tangle (another DLT) interoperability and excluding non DLT databases. In addition to interoperability between blockchain systems, we would also be working on interoperability between blockchain & tangle DLT systems. Is that the intention? If so our first deliverable could be focusing specifically on blockchain and then we, as you said, could either wrap up the work or decide to expand to include tangle. 

The DLT Gateway Protocol is not really accurate unless the plan is to truly provide a gateway protocol to all DLT's (which would be great). Otherwise Blockchain Gateway Protocol would be more appropriate but would be an acronym disaster.

mike

-----Original Message-----
From: Thomas Hardjono <[email-masked]> 
Sent: Sunday, January 10, 2021 2:17 PM
To: Michael McBride <[email-masked]>; [email-masked]
Cc: Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>; Thomas Hardjono <[email-masked]>
Subject: RE: Charter discussion

Thanks Mike,

Thoughts?

Best

-- thomas --

Hi Thomas,

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Wednesday, January 6, 2021 6:39 AM
To: [email-masked]
Cc: Thomas Hardjono <[email-masked]>; Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>
Subject: [Blockchain-interop] Charter discussion

Folks,

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%7Cfe9f662666834b305b6508d8b5b56e33%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637459138141005562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=be6GTFkAuJSVohqTQ7qODO3CwizTE%2Fg42PCUTReS0o0%3D&amp;reserved=0

Looking for your inputs.

Optional:

Existing drafts:

Out of scope:

Best

-- thomas --

--
Blockchain-interop mailing list
[email-masked]
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%7Cfe9f662666834b305b6508d8b5b56e33%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637459138141005562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Ssj9R8lK5G6AGrU0SR0ZlLDz3XEDqqIbjuYFgB5Gbwg%3D&amp;reserved=0

---

From: Luke Riley <[email-masked]>
Date: Tue, 12 Jan 2021 19:29:28 +0000

Hi all,

jumping in.

I think how the internal data is structured (blockchain, blockDAG etc) is less of an issue for this protocol compared to if the ledger is fully replicated between nodes or partially shared. Where ledger data is partially shared (e.g. Corda, Fabric, Quorum, etc), backup gateways need to access the same current state data (regarding the status of the asset transfer), so the backup gateways will need to be more carefully chosen. That can be specified though.

So I think the protocol can remain as a DLT Gateway protocol as long as we make the above assumption clear.

Also Thomas about your previous question "Do you know if ITSA has a standardized APIs (RESTful) to allow checking/validating of token Identification Numbers?", sorry I don't know enough about their progress yet but we (Quant Network) are investigating.

Regards,

Luke
________________________________
From: Blockchain-interop <[email-masked]> on behalf of Michael McBride <[email-masked]>
Sent: 12 January 2021 19:03
To: Thomas Hardjono <[email-masked]>; [email-masked] <[email-masked]>
Cc: Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>
Subject: Re: [Blockchain-interop] Charter discussion

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

Hi Thomas,

mike

-----Original Message-----
From: Thomas Hardjono <[email-masked]>
Sent: Sunday, January 10, 2021 2:17 PM
To: Michael McBride <[email-masked]>; [email-masked]
Cc: Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>; Thomas Hardjono <[email-masked]>
Subject: RE: Charter discussion

Thanks Mike,

Thoughts?

Best

-- thomas --

Hi Thomas,

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Wednesday, January 6, 2021 6:39 AM
To: [email-masked]
Cc: Thomas Hardjono <[email-masked]>; Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>
Subject: [Blockchain-interop] Charter discussion

Folks,

Looking for your inputs.

Optional:

Existing drafts:

Out of scope:

Best

-- thomas --

--
Blockchain-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/blockchain-interop
This message is intended solely for the addressee and may contain privileged and confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Quant Network does not guarantee that this email has not been intercepted and amended or that it is virus free.

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 12 Jan 2021 23:46:34 +0000

Thanks Mike, Luke,

>>> I think how the internal data is structured (blockchain, blockDAG etc) is less of 
>>> an issue for this protocol compared to if the ledger is fully replicated 
>>> between nodes or partially shared.

Correct/agree -- right now going into the BOF at IETF110, we need to have a "minimal mental model" of the problem.  Overall though, the goal really is to permit interoperability between two systems (call these blockchains, DLTs or Legacy databases, etc), fronted by "gateways". Facing inwards a gateway implementation would need to deal with the interior data structures (which we call "resources") of the blockchain/DLT that it fronts.

In some of the texts, we talk about "gateway node" implying that the gateway is either a full-node or a verifier-node (i.e. has at least read access to the shared ledger).

>>> Where ledger data is partially shared (e.g. Corda, Fabric, Quorum, etc), 
>>> backup gateways need to access the same current state data (regarding 
>>> the status of the asset transfer), so the backup gateways will need to be 
>>> more carefully chosen. That can be specified though.

Correct/agree, the backup selection problem can be challenge and the gateways will need to have access to the ledger (or whichever interior data structure is used).  The current crash-recovery draft assumes a self-healing strategy, which carries its own assumptions (e.g. assume keying material in the gateway persists over crashes of the gateway).

-- thomas --

________________________________________
From: Luke Riley [[email-masked]]
Sent: Tuesday, January 12, 2021 2:29 PM
To: Michael McBride; Thomas Hardjono; [email-masked]
Cc: Ned Smith ([email-masked]); Martin Hargreaves
Subject: Re: Charter discussion

Hi all,

jumping in.

Regards,

Luke

Hi Thomas,

mike

-----Original Message-----
From: Thomas Hardjono <[email-masked]>
Sent: Sunday, January 10, 2021 2:17 PM
To: Michael McBride <[email-masked]>; [email-masked]
Cc: Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>; Thomas Hardjono <[email-masked]>
Subject: RE: Charter discussion

Thanks Mike,

Thoughts?

Best

-- thomas --

Hi Thomas,

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Wednesday, January 6, 2021 6:39 AM
To: [email-masked]
Cc: Thomas Hardjono <[email-masked]>; Ned Smith ([email-masked]) <[email-masked]>; Martin Hargreaves <[email-masked]>
Subject: [Blockchain-interop] Charter discussion

Folks,

Looking for your inputs.

Optional:

Existing drafts:

Out of scope:

Best

-- thomas --