Re: [Blockchain-interop] Charter discussion

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

A 2021-01-06 18:09, Miguel Correia escreveu:
> 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)”

I believe that if we specify

> 
> Best,
> Miguel
> 
> 
>> On 6 Jan 2021, at 14:39, Thomas Hardjono <hardjono@mit.edu> wrote:
>> 
>> 
>> 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 --
>> 
>> 
>> --
>> Blockchain-interop mailing list
>> Blockchain-interop@ietf.org
>> https://www.ietf.org/mailman/listinfo/blockchain-interop

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