Re: [Blockchain-interop] Scope of work -- RE: New rev of blockchain gateway interoperability architecture draft -- FW: New Version Notification .....

[Thomas Hardjono <[e-mail]>]

Apologies, I meant "Michael" (not Richard)

>> Following-up on Richard's question regarding the problem statement (that we are seeking to solve).



________________________________________
From: Blockchain-interop [[e-mail]] on behalf of Thomas Hardjono [[e-mail]]
Sent: Friday, November 6, 2020 12:34 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Blockchain-interop] Scope of work -- RE: New rev of blockchain gateway interoperability architecture draft -- FW: New Version Notification .....

Following-up on Richard's question regarding the problem statement (that we are seeking to solve).

>>> There is skepticism (within the ietf) about the validity of blockchain technology.
>>> We need to be very clear about the problem, including use cases,
>>> if the goal of this work is to eventually rally a wg.


The following is a proposed scope of work for the WG should it be approved.  As you can see, the focus is on the gateway-to-gateway protocol, with very little (nothing) on DLTs and blockchains.


Scope of Work statement:

The goal is to develop a standard protocol that enables two (2) gateway nodes belonging to distinct DLT systems to conduct an asset transfer unidirectional, in a secure and non-repudiable manner. The protocol must ensure that the asset exists only on one of the DLT systems at any time, and that the transfer is not dependent on any third party.

For a unidirectional transfer between gateways, the properties of atomicity, consistency, isolation and durability must be satisfied. The protocol must be agnostic (oblivious) to the higher-layer economic value of the asset being transferred.

The interior resources within a DLT system (e.g. ledgers, public-keys, consensus protocols, etc.) behind a gateway are assumed to be opaque to the peer (opposite) gateway and the DLT system behind it. This leads to a protocol design that is scalable and not dependent on the interior technical constructs of any particular DLT system. It also permits better integration with existing legacy (non-DLT) systems.

The current effort focuses on unidirectional asset transfers, although the resulting building blocks can be used to support designs for bidirectional transfers (e.g. conditional two unidirectional transfers implementing swaps).

The focus of the work is the interaction between gateways. The following are the work items that are within scope for the gateways:

•       API-endpoint definitions (RESTful APIs).
•       Resource identifiers.
•       Message flows, payloads and functions.
•       Some terminology (extending NISTIR-8202 or ISO-22739).

Deliverables
•       Architecture document.
•       Asset transfer protocol specification (ODAP).
•       Use-cases document.
•       Asset profile JSON structure definition [optional].
•       Log metadata definition (JSON) for crash recovery [optional].


Out of Scope
-- Blockchain systems and DLT systems;
-- Consensus protocols, BFT protocols; proof of work; proof of stake; etc.
-- Cryptocurrencies and other forms of tokenized assets.
-- Incentives mechanisms and economic models; etc.
-- Zero-knowledge proof (ZKP) protocols;
-- Authentication & Authorization protocols;


Related IETF Working Groups
-- OAUTH and GNAP (relevant for authorization) -- in so far as authorization tokens are used.
-- TLS WG  -- in so far as TLS is assumed to be used between gateways.
-- PKIX WG (relevant for X.509 certificates)
-- RATS WG (relevant for device attestations)




________________________________________
From: Thomas Hardjono
Sent: Tuesday, October 27, 2020 12:19 PM
To: Michael McBride; [e-mail]
Subject: RE: New rev of blockchain gateway interoperability architecture draft -- FW: New Version Notification .....

Thanks Michael,

>>> It looks like the gateway could be what many of us would term an oracle?
>>> If so, the oracle (or gateway) could be responsible not only
>>> for on/off chain transactions but also for DLT interoperability.

I tend not to use the term "Oracle" because it has different meanings to different people (too confusing, even NISTR 8202 does not define it).

The gateway in our case has the task of moving virtual assets whose provenance (and authenticity & legitimacy) has been established previously (by other entities).  So a gateway is not asserting any truthful statement about the asset original or value (which is what Oracles are thought to do).


>>> Which leads to the need for a use case and/or problem statement document.

We will be uploading a short use-case document very soon.

The problem statement is basically simple:  a gateway-to-gateway protocol that can satisfy the properties mentioned in the arch draft.


>>> There is skepticism (within the ietf) about the validity of blockchain technology.
>>> We need to be very clear about the problem, including use cases,
>>> if the goal of this work is to eventually rally a wg.

Interestingly, we are not actually addressing any blockchain/DLT problem. The scope of work is limited only to 2 gateways and the things that need to occur between them for a proper transfer.

Looking the Figures in the draft, the word "blockchain/DLT" in the figures should be able to be substituted with the word "database", and if designed correctly the gateway-to-gateway transfer protocol should work just as well.

Best


-- thomas --



________________________________________
From: Michael McBride [[e-mail]]
Sent: Monday, October 26, 2020 7:42 PM
To: Thomas Hardjono; [e-mail]
Subject: RE: New rev of blockchain gateway interoperability architecture draft -- FW: New Version Notification .....

Hi Thomas,

Great document. It looks like the gateway could be what many of us would term an oracle? If so, the oracle (or gateway) could be responsible not only for on/off chain transactions but also for DLT interoperability.

Which leads to the need for a use case and/or problem statement document. There is skepticism (within the ietf) about the validity of blockchain technology. We need to be very clear about the problem, including use cases, if the goal of this work is to eventually rally a wg.

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[e-mail]> On Behalf Of Thomas Hardjono
Sent: Monday, October 26, 2020 10:14 AM
To: [e-mail]
Subject: [Blockchain-interop] New rev of blockchain gateway interoperability architecture draft -- FW: New Version Notification .....


Folks,

Below is a revision of the blockchain gateway interoperability architecture draft.

It now goes into further details of each of the phases.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hardjono-blockchain-interop-arch%2F&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=6uu3zd4yRZjmgednPF4dsjrs86DXE8JGFieImvJQW%2BY%3D&amp;reserved=0

Best


-- thomas --

________________________________________
From: [e-mail] [[e-mail]]
Sent: Monday, October 26, 2020 1:09 PM
To: Ned Smith; Martin Hargreaves; Thomas Hardjono
Subject: New Version Notification for draft-hardjono-blockchain-interop-arch-01.txt

A new version of I-D, draft-hardjono-blockchain-interop-arch-01.txt
has been successfully submitted by Thomas Hardjono and posted to the IETF repository.

Name:           draft-hardjono-blockchain-interop-arch
Revision:       01
Title:          An Interoperability Architecture for Blockchain Gateways
Document date:  2020-10-27
Group:          Individual Submission
Pages:          20
URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hardjono-blockchain-interop-arch-01.txt&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=rmv8jnYLjZuGvYPglwk7nrhrb%2BkFZFFZy57kLJUaEGc%3D&amp;reserved=0
Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hardjono-blockchain-interop-arch%2F&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=6uu3zd4yRZjmgednPF4dsjrs86DXE8JGFieImvJQW%2BY%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hardjono-blockchain-interop-arch&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=KLy6P58VkIL4IU065QzFEv7UuG7jRBeXRB25GTqW6KE%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hardjono-blockchain-interop-arch-01&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2B1B5w4hx4Hn8Xqfp4yhG4LN0xRwXywyxKX5o3vtQ66Y%3D&amp;reserved=0
Diff:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-hardjono-blockchain-interop-arch-01&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=1eI9LDhuLsWvk37uIkmxLcIpiuA5ZgqlM7dzYpqdjhI%3D&amp;reserved=0

Abstract:
   With the increasing interest in the potential use of blockchain
   systems for virtual assets, there is a need for these assets to have
   mobility across blockchain systems.  An interoperability architecture
   for blockchain systems is needed in order to permit the secure flow
   of virtual assets between blockchain systems, satisfying the
   properties of transfer atomicity, consistency and durability.  The
   architecture must recognize that there are different blockchain
   systems, and that the interior constructs in these blockchains maybe
   incompatible with one another.  Gateway nodes perform the transfer of
   virtual assets between blockchain systems while masking the
   complexity of the interior constructs of the blockchain that they
   represent.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Blockchain-interop mailing list
[e-mail]
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%7Ce37dda00e3e344006e9108d879d28fcd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637393292548341856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=79HXXAFK%2FXlpnSAWBm5he4stIxOpJ%2BpJQAFm6Z9RZsE%3D&amp;reserved=0

--
Blockchain-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/blockchain-interop