Re: [Blockchain-interop] Charter discussion

[Thomas Hardjono <[e-mail]>]

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

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
> good to state why - in particular, 3PC might make sense in a scenario
> 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 [[e-mail]]
Sent: Wednesday, January 6, 2021 1:27 PM
To: Miguel Correia
Cc: Thomas Hardjono; Ned Smith ([e-mail]); [e-mail]; Martin Hargreaves
Subject: 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 <[e-mail]> 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
>> [e-mail]
>> 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/