idnits 2.17.00 (12 Aug 2021)
/tmp/idnits16543/draft-hardjono-blockchain-interop-arch-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 7, 2021) is 188 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'HTLC21' is mentioned on line 375, but not defined
== Missing Reference: 'RATS' is mentioned on line 641, but not defined
== Missing Reference: 'HS19' is mentioned on line 941, but not defined
== Unused Reference: 'RFC2119' is defined on line 998, but no explicit
reference was found in the text
== Unused Reference: 'ABCH20' is defined on line 1005, but no explicit
reference was found in the text
== Unused Reference: 'BVGC20' is defined on line 1021, but no explicit
reference was found in the text
== Unused Reference: 'HLP19' is defined on line 1040, but no explicit
reference was found in the text
== Outdated reference: A later version (-03) exists of
draft-belchior-gateway-recovery-01
== Outdated reference: A later version (-03) exists of
draft-hargreaves-odap-01
== Outdated reference: A later version (-06) exists of
draft-richardson-t2trg-idevid-considerations-01
Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force T. Hardjono
3 Internet-Draft MIT
4 Intended status: Informational M. Hargreaves
5 Expires: May 11, 2022 Quant Network
6 N. Smith
7 Intel
8 V. Ramakrishna
9 IBM
10 November 7, 2021
12 Interoperability Architecture for DLT Gateways
13 draft-hardjono-blockchain-interop-arch-03
15 Abstract
17 With the increasing interest in the potential use of blockchains and
18 decentralized ledger technology (DLT) networksorks for virtual asset
19 management, there is a need for these networks to have
20 interoperability to support applications and services built atop
21 these networks. An interoperability architecture for DLT networks is
22 therefore needed in order to permit the secure flow of digital assets
23 different DLT networks, satisfying the properties of transfer
24 atomicity, consistency and durability. The architecture must
25 recognize that there are different DLT networks and that the interior
26 constructs in these networks maybe incompatible with one another.
27 This document proposes an interoperability architecture based on DLT
28 Gateways, which are points of interconnection between networks.
29 Among others, the gateways implement one or more protocols for the
30 transfer (or exchange) digital assets between DLT networks. A
31 gateway belonging to a DLT network peers with another gateway
32 belonging to a different DLT network to perform the asset transfer
33 between the two networks.
35 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at https://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on May 11, 2022.
51 Copyright Notice
53 Copyright (c) 2021 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (https://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 3. Assumptions and Principles . . . . . . . . . . . . . . . . . 6
71 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6
72 3.2. Operational Assumptions . . . . . . . . . . . . . . . . . 7
73 4. Interoperability Modes . . . . . . . . . . . . . . . . . . . 7
74 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9
75 5.1. Goal of Architecture . . . . . . . . . . . . . . . . . . 9
76 5.2. Overview of Asset Transfer . . . . . . . . . . . . . . . 10
77 5.3. Desirable Properties of Asset Transfer . . . . . . . . . 10
78 5.4. Event log-data, crash recovery and backup gateways . . . 11
79 5.5. Overview of the Phases in Asset Transfer . . . . . . . . 12
80 6. Pre-transfer Verification of Asset and Identities (Phase 1) . 13
81 7. Evidence of asset locking or escrow (Phase 2) . . . . . . . . 15
82 8. Transfer Commitment (Phase 3) . . . . . . . . . . . . . . . . 17
83 9. Related Open Issues . . . . . . . . . . . . . . . . . . . . . 19
84 9.1. Global identification of blockchain systems and public-
85 keys . . . . . . . . . . . . . . . . . . . . . . . . . . 19
86 9.2. Discovery of gateways in DLT Networks . . . . . . . . . . 20
87 9.3. Remote gateway discovery . . . . . . . . . . . . . . . . 20
88 9.4. Commitment protocols and forms of commitment evidence . . 20
89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
90 11. Policy Considerations . . . . . . . . . . . . . . . . . . . . 21
91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
92 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
93 12.2. Informative References . . . . . . . . . . . . . . . . . 22
94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
96 1. Introduction
98 Currently there is little technical interoperability between
99 decentralized ledger technology (DLT) networks. This results in the
100 difficulty in transferring or exchanging virtual (digital) assets
101 from one DLT network to another directly.
103 The existing solutions involve a third party that mediates the
104 transfer. This mediating third party is typically an asset-exchange
105 entity (i.e. crypto-exchange) operating in a centralized hub-spoke
106 fashion. This reliance on a third party results not only in delays
107 in transfers, but also in the need for asset owner to have a business
108 relationship (e.g. open accounts) at the mediating third party. Many
109 of these solutions centralize control at the hands of the mediating
110 party, thereby diminishing the autonomy of blockchains and DLT
111 networks, and limits their scalability.
113 This document proposes an interoperability architecture based on DLT
114 Gateways, which are points of interconnection between networks.
115 There are several services that may be offered by a DLT gateway, one
116 of which being the direct transfer of a digital asset from one DLT
117 network to another via pairs of gateways without a mediating third
118 party. A given DLT network may have one or more gateways to perform
119 a unidirectional direct transfer of digital assets to another DLT
120 network possessing one or more compatible gateway. Similar to the
121 notion of border gateways in interdomain routing (e.g. running the
122 BGPv4 protocol), a DLT gateway belonging to an origin DLT network is
123 said to peer with another gateway is a destination DLT network. Both
124 gateways must implement an asset transfer protocol that must satisfy
125 certain security, privacy and atomicity requirements.
127 The purpose of this architecture document is to provide technical
128 framework within which to define the required properties of a DLT
129 gateway that supports an atomic asset transfer protocol, such as ODAP
130 [ODAP]. These properties include the security, reliability and data
131 privacy of digital asset transfers between pairs of gateways
132 belonging to differing DLT networks.
134 2. Terminology
136 There following are some terminology used in the current document.
137 We borrow terminology from NIST and ISO as much as possible,
138 introducing new terms only when needed:
140 o Blockchain system: Blockchains are distributed digital ledgers of
141 cryptographically signed transactions that are grouped into
142 blocks. Each block is cryptographically linked to the previous
143 one (making it tamper evident) after validation and undergoing a
144 consensus decision. As new blocks are added, older blocks become
145 more difficult to modify (creating tamper resistance). New blocks
146 are replicated across copies of the ledger within the network, and
147 any conflicts are resolved automatically using established rules
148 [NIST].
150 o Distributed ledger technology (DLT) system: Technology that
151 enables the operation and use of distributed ledgers, where the
152 ledger is shared (replicated) across a set of DLT nodes and
153 synchronized between the DLT nodes using a consensus mechanism
154 [ISO].
156 o DLT Network: A generic term for blockchain systems.
158 o Resource Domain: Resource Domain: The collection of resources and
159 entities participating within a blockchain or DLT network. The
160 domain denotes an boundary for permissible or authorized actions
161 on resources.
163 o Interior Resources: The various interior protocols, data
164 structures and cryptographic constructs that are a core part of a
165 blockchain or DLT network. Examples of interior resources include
166 the ledger (blocks of confirmed transaction data), public keys on
167 the ledger, consensus protocol, incentive mechanisms, transaction
168 propagation networks, etc.
170 o Exterior Resources: The various resources that are outside a
171 blockchain or DLT network, and are not part of the operations of
172 the network. Examples include data located at third parties such
173 as asset registries, ledgers of other DLT network, PKI
174 infrastructures, etc.
176 o Nodes: The nodes of the blockchain or DLT system which form the
177 peer-to-peer network, which collectively maintain the shared
178 ledger in the system by following a consensus algorithm.
180 o DLT Gateway: a DLT gateway is the collection of services,
181 controlled by one legal entity, which connects to a minimum of one
182 DLT network to provide read and write access to the ledger of that
183 DLT network. A DLT gateway implements an atomic digital asset
184 transfer protocol, such as ODAP [ODAP], via a DLT-neutral data
185 formats and local storage logs. A gateway does not implement an
186 interior consensus protocol.
188 o DLT address: This is the public-key of an entity as known within a
189 DLT network or blockchain system, employed to transact on the DLT
190 network and recorded on the ledger of the DLT network. Also
191 referred to as the transaction public key.
193 o Entity public-key pair: This the private-public key pairs of an
194 entity used for interactions outside the DLT network (e.g. TLS
195 1.3). The term is used to distinguish this public-key from the
196 blockchain address.
198 o Asset transfer protocol: The gateway-to-gateway technical protocol
199 used by two gateways to perform a unidirectional transfer of a
200 virtual (digital_ asset.
202 o Asset profile: The prospectus of a regulated asset that includes
203 information and resources describing the virtual asset. This
204 includes, among others, the asset name/code, issuing authority,
205 denomination, jurisdiction, and the URLs and mechanisms to
206 validate the information. The asset profile is independent from
207 the specific instantiation of the asset (on a DLT network or
208 otherwise) and independent from its instance-ownership
209 information.
211 o Virtual Asset: A virtual asset is a digital representation of
212 value that can be digitally traded, or transferred as defined by
213 the FATF [FATF]. We use the term interchangeably with ?digital
214 asset?.
216 o Virtual Asset Service Provider (VASP): Legal entity handling
217 virtual assets as defined by the FATF [FATF].
219 o Originator: Person or organization seeking the transfer of virtual
220 asset to a beneficiary
222 o Beneficiary: Person or organization receiving the transferred
223 virtual asset from an originator.
225 o Travel Rule information: Data regarding the VASPs, originators and
226 beneficiaries involved in an asset transfer, as defined by the
227 FATF [FATF] and as required by the jurisdiction of operations of
228 the VASPs.
230 o Gateway device identity: The identity of the device implementing
231 the gateway functions. The term is used in the sense of IDevID
232 (IEEE 802.1AR) or EK/AIK (in TPM1.2 and TPM2.0) [IDevID].
234 o Gateway owner: The VASP who legally owns and operates a gateway
235 within a DLT network.
237 o Asset locking or escrow: The conditional mechanism used within a
238 DLT network to make an asset temporarily unavailable for use by
239 its owner. The condition of the asset release can be based on a
240 duration of time (e.g. hash time locks) or other parameters.
242 o Gateway crash recovery: The local process by which a crashed
243 gateway (i.e. device or system fault) is returned back into a
244 consistent and operational state, ready to resume the asset
245 transfer protocol with the peer gateway prior to the crash event.
247 Further terminology definitions can be found in [NIST] and [ISO].
248 The term 'blockchain' and 'distributed ledger technology' (DLT) are
249 used interchangeably in this document.
251 3. Assumptions and Principles
253 The following assumptions and principles underlie the design of the
254 current gateway architecture, and correspond to the design principles
255 of the Internet architecture.
257 3.1. Design Principles
259 o Opaque DLT resources: The interior resources of each DLT network
260 is assumed to be opaque to (hidden from) external entities. Any
261 resources to be made accessible to an external entity must be made
262 explicitly accessible by a gateway with proper authorization.
264 o Externalization of value: The gateway protocol is agnostic
265 (oblivious) to the economic or monetary value of the virtual asset
266 being transferred.
268 The opaque resources principle permits the interoperability
269 architecture to be applied in cases where one (or both) DLT networks
270 are permissioned (private). It is the analog of the autonomous
271 systems principle in IP networking [Clar88], where interior routes in
272 local subnets are not visible to other external networks.
274 The value-externalization principle permits asset transfer protocols
275 to be designed for efficiency, security and reliability - independent
276 of the changes in the perceived economic value of the virtual asset.
277 It is the analog of the end-to-end principle in the Internet
278 architecture [SRC84], where contextual information (economic value)
279 is placed at the endpoints of the transaction. In the case of a
280 transfer of virtual assets, the originator and beneficiary at the
281 respective DLT networks are assumed to have a common agreement
282 regarding the economic value of the asset. This context of the
283 economic meaning of the value of the asset is assumed to exists at
284 the end-points, namely at the originator and beneficiary.
286 3.2. Operational Assumptions
288 The following conditions are assumed to have occurred, leading to the
289 invocation of the asset transfer protocol between two gateways:
291 o Application layer transfer request: The transfer request from an
292 originator in the origin DLT network is assumed to have occurred
293 prior to the execution of the asset transfer protocol.
295 o Identification of originator and beneficiary: The originator and
296 beneficiary are assumed to have been identified and that consent
297 has been obtained from both parties regarding the asset transfer.
299 o Identification of origin and destination DLT networks: The origin
300 and destination DLT networks is assumed to have been identified.
302 o Selection of gateway: The two gateway at the origin and
303 destination DLT networks respectively is assumed to have been
304 identified and selected.
306 o Identification of gateway-owners (VASP): The VASP operating the
307 gateway are assumed to have been identified and their status
308 verified [FATF].
310 4. Interoperability Modes
312 Before delving into the architecture, it would be instructive to
313 survey the different modes (or categories) of operations that
314 necessitate interoperability between two blockchain/DLT network,
315 virtual asset transfer being one such category.
317 We can reason about this in terms of the interdependencies between
318 business processes in two independent systems. In one category, a
319 ledger state update in one system depends on an update in the other.
320 In other words, a write operation must be performed on both ledgers
321 to maintain integrity of the collective system; if either ledger lies
322 in a blockchain system or DLT network, a new block is also added.
323 From this, one can infer that both writes, or ledger state updates,
324 must occur atomically (either both happen or neither does) across
325 both systems despite their independence and lack of a central
326 coordinator.
328 The category of atomic writes can further be classified into asset
329 transfers and asset exchanges. In the former, a virtual asset is
330 expunged in one system while atomically being recreated in the other;
331 the owner and recipient need only have accounts in their respective
332 DLT networks. In the latter, two virtual assets are exchanged in two
333 distinct networks atomically; they simply switch ownership without
334 their profile records leaving their respective systems' ledgers. In
335 this scenario, both owners must have accounts in both networks.
337 Moving back up the categorization hierarchy, we can identify a
338 different category in which a ledger state update in one system
339 depends on already recorded state in the ledger of another. In other
340 words, a write operation must be performed in one ledger after
341 reading state from another. The use case under this category can be
342 termed data transfer or data sharing, where the advancement of a
343 business workflow in one system depends on the advancement of a
344 different workflow in another without requiring an atomic operation
345 across the two systems. Here, it is useful to distinguish data from
346 asset; the former can be copied in and across systems without losing
347 its integrity whereas the latter must have an unambiguous ownership
348 record at all times.
350 Cross DLT-System Dependency
351 |
352 |
353 +-----------------------------------+
354 | |
355 | |
356 +--------------------+ +--------------------+
357 | Bidirectional | | Unidirectional |
358 | (Write <--> Write) | | (Read --> Write) |
359 +--------------------+ +--------------------+
360 | |
361 | |
362 +------------------+ |
363 | | |
364 | | |
365 +----------------+ +----------------+ +-----------------+
366 | Asset Transfer | | Asset Exchange | | Data Transfer |
367 +----------------+ +----------------+ +-----------------+
369 Figure 1
371 Though the rest of this document focuses on a gateway architecture to
372 facilitate virtual asset transfers, the same architecture can also be
373 used for asset exchanges and data transfers. Interested readers can
374 find out more about cross DLT-system asset exchanges by referring to
375 literature on Hashed Time Lock Contracts [HTLC21], on cross network
376 data transfers [Abebe19][Abebe21], and on ledger state views and
377 addresses [DLVIEW].
379 5. Architecture
381 5.1. Goal of Architecture
383 The goal of the interoperability architecture is to permit two (2)
384 Gateways belonging to distinct DLT networks to conduct a virtual
385 asset transfer between them, in a secure and non-repudiable manner
386 while ensuring the asset does not exist simultaneously on both
387 networks (double-spend problem).
389 The virtual asset as understood by the two gateway is a digital
390 representation of value, expressed in an standard digital format in a
391 way meaningful to the gateway syntactically and semantically.
393 The syntactic representation of the virtual asset between the two
394 gateways need not bear any resemblance to the syntactic asset
395 representation within their respective DLT networks.
397 The architecture recognizes that there are different DLT networks
398 currently in operation and evolving, and that in many cases the
399 interior technical constructs in these DLT networks maybe
400 incompatible with one another.
402 The architecture therefore assumes that certain types of computer
403 systems (i.e. gateway) will be equipped with an asset transfer
404 protocol and with other relevant resources that permits greater
405 interoperability across these DLT networks.
407 The resources within a DLT network (e.g. ledgers, public-keys,
408 consensus protocols, etc.) are assumed to be opaque to external
409 entities in order to permit a resilient and scalable protocol design
410 that is not dependent on the interior constructs of particular
411 blockchain system or DLT network. This ensures that the virtual
412 asset transfer protocol between gateways is not conditioned or
413 dependent on these local technical constructs. The role of a gateway
414 therefore is also to mask (hide) the complexity of the interior
415 constructs of the DLT network that it represents. Overall this
416 approach ensures that a given DLT network operates as a true
417 autonomous system.
419 The current architecture focuses on unidirectional asset transfers,
420 although the building blocks in this architecture can be used to
421 support protocols for bidirectional transfers (conditional two
422 unidirectional transfers), atomic asset exchanges and data transfers.
424 For simplicity the current architecture employs two (2) gateways in
425 the respective DLT networks, but collective multi-gateway transfers
426 (i.e. multiple gateways at each side) [HS2019] may be developed based
427 on the building blocks and constructs identified in the current
428 architecture.
430 5.2. Overview of Asset Transfer
432 An asset transfer between two DLT networks is carried out by two (2)
433 gateway in a direct interaction (unmediated), where the gateway
434 represents the two respective DLT networks.
436 A successful transfer results in the asset being extinguished
437 (deleted) or marked on the origin ledger by the origin-gateway, and
438 for the asset to be introduced by the destination-gateway into the
439 destination ledger.
441 The mechanism to extinguish or introduce an asset from/into a ledger
442 is dependent on the specific blockchain or DLT network. The task of
443 the respective gateway is to implement the relevant mechanism to
444 modify the ledger of their corresponding DLT networks in such a way
445 that together the two DLT networks maintain consistency from the
446 asset perspective, while observing the design principles of the
447 architecture.
449 An asset transfer protocol that can satisfy the properties of
450 atomicity and consistency in the case of two private DLT networks
451 should also satisfy the same properties in the case when one or both
452 are public.
454 5.3. Desirable Properties of Asset Transfer
456 The desirable features of asset transfers between two gateway
457 include, but not limited, to the following:
459 o Atomicity: Transfer must either commit or entirely fail (failure
460 means no change to asset ownership).
462 o Consistency: Transfer (commit or fail) always leaves the ledgers
463 of both DLT networks to be in a consistent state (asset located in
464 the ledger of one DLT network only).
466 o Isolation: While transfer occurring, asset ownership cannot be
467 modified (no double-spend).
469 o Durability: Once a transfer has been committed, must remain so
470 regardless of gateway crashes.
472 o Verifiable by authorized third parties: With proper authorization
473 to access relevant interior resources, third party entities must
474 be able at any time to perform audit-validation of the two
475 respective ledgers for asset transfers across the corresponding
476 DLT networks.
478 o Containment of side-effects: Any effects due to errors or
479 security/integrity breaches in a DLT network during an asset
480 transfer must be contained within that network.
482 An implementation of the asset transfer protocol should satisfy these
483 properties, independent of whether the implementation employs
484 stateful messaging or stateless messaging between the two gateways.
486 5.4. Event log-data, crash recovery and backup gateways
488 Implementations of gateway should maintain event logs and checkpoints
489 for the purpose of gateway crash recovery. The log-data generated by
490 a gateway should be considered as an interior resource accessible to
491 other authorized gateways within the same DLT network.
493 Mechanisms used to select or elect a gateway in a DLT network for a
494 given asset transfer could be extended to include the selection of a
495 backup gateways. The primary gateway and the backup gateway may or
496 may not belong to the same owner (VASP).
498 Some DLT networks may utilize the ledger itself as means to retain
499 the log-data, allowing other nodes in the DLT network to have
500 visibility and access to the gateway log-data. Other DLT networks
501 may employ off-chain storage that is accessible to all gateway in the
502 same authorization domain. In such cases, to provide event-
503 sequencing integrity the gateway may store a hash of the log- data on
504 the ledger of the DLT network prior to writing the log-data to the
505 off-chain storage.
507 The mechanism used to provide gateway crash-recovery is dependent on
508 the DLT network and the gateway implementation. For interoperability
509 purposes the information contained in the log and the format of the
510 log-data should be standardized, permitting vendors of gateway
511 products to reduce development costs over time. Similarly, in order
512 to ensure a high degree of interoperability across crash-recovery
513 protocol implementations [BCH21], a standardized interface (e.g.
514 REST APIs) should be defined for read/ write access to the log-
515 storage. The interface should hide the details of the log-storage
516 from the gateway itself, and it should be independent of the gateway
517 recovery strategy (e.g. self-healing, primary-backup, etc.).
519 The resumption of an interrupted transfer (e.g. due to gateway crash,
520 network failure, etc.) should take into consideration the aspects of
521 secure channel establishment and the aspects of the transfer protocol
522 resumption. In some cases, a new secure channel (e.g. TLS session)
523 must be established between the two gateways, within which the asset
524 transfer protocol could be continued from the last checkpoint prior
525 to the interruption. However, in other cases both the secure channel
526 and the transfer protocol may need to be started completely afresh
527 (no resumption).
529 The log-data collected by a gateway acts also as a checkpoint
530 mechanism to assist the recovered (or backup) gateway in continuing
531 the transfer. The point at which to re-start the transfer protocol
532 flow is dependent on the implementation of the gateway recovery
533 strategy. Some owners (VASPs) of gateways may choose to start afresh
534 the transfer of the asset, and not to resume partially completed
535 transfers (e.g. for easier legal audit purposes).
537 5.5. Overview of the Phases in Asset Transfer
539 The interaction between two gateways in an asset transfer is
540 summarized in Figure 2, where the origin DLT network is DLN1 and the
541 destination network is DLN2. The gateways are denoted as G1 and G2
542 respectively.
544 Originator Beneficiary
545 | |
546 +-------------+ +-------------+
547 | Client | | Client |
548 | Application | | Application |
549 | (App1) | | (App2) |
550 +-------------+ +-------------+
551 | |
552 | (Phases) |
553 V V
554 +-------------+ |<-----(1)----->| +-------------+
555 | DLT Network | +----+ +----+ | DLT Network |
556 | DLN1 | |Gate| |Gate| | DLN2 |
557 | |--|way |<-----(2)----->|way |--| |
558 | +---------+ | | G1 | | G2 | | +---------+ |
559 | |Ledger L1| | +----+ +----+ | |Ledger L2| |
560 | +---------+ | |<-----(3)----->| | +---------+ |
561 +-------------+ +-------------+
563 Figure 2
565 The phases are summarized as follows.
567 o Phase 0: Initiation of transfer at the application layer. The two
568 applications utilized by the originator and beneficiary is assumed
569 to interact as part of the asset transfer. In this phase, the
570 applications App1 and App2 may establish some context information
571 (e.g. Session-ID) that will be made available to their respective
572 gateways G1 and G2. The legal verification of the identities of
573 the Originator and Beneficiary may occur in this phase [FATF].
574 This phase is outside the scope of the current architecture.
576 o Phase 1: Pre-transfer Verification of Asset and Identities. In
577 this phase the gateways G1 and G2 must mutually identify
578 themselves and authenticate that both possess gateway-
579 capabilities. Gateway G1 must communicate to G2 the asset-profile
580 of the asset to be transferred, while G2 must validate that it has
581 the ability to support this type of asset in the ledger of its DLT
582 network.
584 o Phase 2: Evidence of asset locking or escrow. In this phase,
585 gateway G1 must provide gateway G2 with sufficient evidence that
586 the asset on DLN1 is in a locked state (or escrowed) under the
587 control of G1 on ledger L1, and safe from double-spend by its
588 current owner (the originator).
590 o Phase 3: Transfer commitment. In this phase gateways G1 and G2
591 commit to the unidirectional asset transfer.
593 These phases will be further discussed below.
595 6. Pre-transfer Verification of Asset and Identities (Phase 1)
597 The primary purpose of the first phase is to verify the various
598 information relating to the asset to be transferred, the correct
599 identities of the originator and beneficiary (as provided by the
600 respective applications), the identity and legal status of the
601 entities (VASPs) who own and operate the gateways, the type of the
602 DLT network, and network parameters, and the device-identities of the
603 gateways.
605 Orig L1 G1 G2 L2 Benef
606 | | | | | |
607 |---request------->| | | |
608 | | | | | |
609 ..|.....|............|....................|............|.....|..
610 | | | Phase 1 | | |
611 | | | | | |
612 | | (1.1)|<-----VASP id------>| | |
613 | | | | | |
614 | | | | | |
615 | | (1.2)|<--Asset Profile--->| | |
616 | | | | | |
617 | | | | | |
618 | | (1.3)|<--Orig/Benef id--->| | |
619 | | | | | |
620 ..|.....|............|....................|............|.....|..
621 | | | | | |
623 Figure 3
625 This phase starts with the assumption that in DLN1 the gateway to
626 process the asset transfer to DLN2 has been selected (namely gateway
627 G1). It also assumes that the destination DLN2 has been identified
628 where the beneficiary address is located, and that gateway G2 in DLN2
629 has been identified that will peer with G1 to perform the transfer.
631 There are several steps that may occur in Phase 1:
633 o Secure channel establishment between G1 and G2: This includes the
634 mutual verification of the gateway device identities and the
635 exchange of the relevant parameters for secure channel
636 establishment. In cases where device attestation [RATS] is
637 required, the mutual attestation protocol must occur between G1
638 and G2 prior to proceeding to the next phase.
640 o Mutual device attestations: In cases where device attestation
641 [RATS] is required, each gateway must yield attestation evidence
642 to the other regarding its configuration. A gateway may take on
643 the role as a attestation verifier, or it may rely on an external
644 verifier to appraise the received evidence.
646 o Validation of the gateway ownership: There must be a means for
647 gateway G1 and G2 to verify their respective ownerships (i.e.
648 VASP1 owning G1 and VASP2 owning G2 respectively). Examples of
649 ownership verification mechanism include the chaining of the
650 gateway-device X.509 certificate up to the VASP entity
651 certificate, directories of gateways and VASPs, and others.
653 o Validation of VASP status: In some jurisdictions limitations may
654 be placed for regulated VASPs to transact only with other
655 similarly regulated VASPs. Examples of mechanisms used to
656 validate a VASP legal status include VASP directories, Extended
657 Validation (EV) X.509 certificates for VASPs, and others.
659 o Identification and validation of asset profile: Both gateways must
660 agree on the type of asset being transferred based on the profile
661 of the asset. Gateway G1 must communicate the asset-profile
662 identification to gateway G2, who in turn must validate both the
663 legal status of the asset as well as the technical capability of
664 DLN2 to digitally represent the asset type within its ledger L2.
665 The policies governing DLT network DLN2 with regards to
666 permissible incoming assets must be enforced by G2.
668 o Exchange of Travel Rule information and validation: In
669 jurisdictions where the Travel Rule policies regarding originator
670 and beneficiary information is enforced [FATF], the owners of
671 gateways G1 and G2 must comply to the Travel Rule. Mechanisms
672 must be used to permit gateways G1 and G2 to make available
673 originator/beneficiary information to one another in such away
674 that the Travel Rule information can be logged as part of the
675 asset transfer history.
677 o Negotiation of asset transfer protocol parameters: Gateway G1 and
678 G2 must agree on the parameters to be employed within the asset
679 transfer protocol. Examples include endpoints definitions for
680 resources, type of commitment flows (e.g. 2PC or 3PC), lock-time
681 durations, and others [ODAP].
683 7. Evidence of asset locking or escrow (Phase 2)
685 The asset transfer protocol can commence when both gateways G1 and G2
686 have completed the verifications in Phase 1.
688 The steps of Phase 2 are summarized in Figure 4, and broadly consists
689 of the following:
691 o Commencement (2.1): Gateway G1 indicates the start of the asset
692 transfer protocol by sending a transfer-commence message to
693 gateway G2. Among others, the message must include a
694 cryptographic hash of the information agreed-upon in Phase 1 (e.g.
695 asset profile, gateway identities, originator/beneficiary public
696 keys, etc.).
698 o Acknowledgement (2.2): The gateway G2 must send an explicit
699 acknowledgement of the receipt of the commence message, which
700 should include a hash of commencement message (2.1) and other
701 relevant session parameters.
703 o G1 lock/escrow asset (2.3): Gateway G1 proceeds to lock or escrow
704 the asset belonging to the originator on ledger L1. This prevents
705 other transactions from changing the state of the asset in L1
706 until such time the lock by G1 is finalized or released. A time-
707 lock or escrow may also be employed. The mode of the escrow may
708 depend on the fundamental ledger architecture of the respective
709 DLN1 and DLN2 in question (e.g. account-based, UTXO, or other).
711 o G2 logs incoming asset (2.4): Gateway G2 correspondingly writes a
712 non-committing log (passive transaction) on ledger L2 indicating
713 an imminent arrival of the asset to L2. This may act as a
714 notification for the beneficiary regarding the asset transfer.
716 o Lock Evidence (2.5): Gateway G1 sends a digitally signed evidence
717 regarding the lock (escrow) performed by G1 on the asset on ledger
718 L1. The signature by G1 is performed using its entity public-key
719 pair. This signifies that G1 (i.e. its owner VASP) is legally
720 standing behind its assertion regarding the lock/escrow on the
721 asset performed by G1.
723 o Evidence receipt (2.6): If gateway G2 accepts the evidence, G2
724 then responds with a digitally signed receipt message which
725 includes a hash of the previous lock-evidence message. Otherwise,
726 if G2 declines the evidence then G2 can ignore the transfer and
727 let it time-out (i.e. transfer failed). The signature by G2 is
728 performed using its entity public-key pair.
730 Orig L1 G1 G2 L2 Benef
731 | | | (Phase 1) | | |
732 | | | | | |
733 ..|.....|............|....................|............|.....|..
734 | | | Phase 2 | | |
735 | | | | | |
736 | | (2.1)|-----Commence------>| | |
737 | | | | | |
738 | | |<-------ACK---------|(2.2) | |
739 | | | | | |
740 | | | | | |
741 | |<---Lock----|(2.3) | | |
742 | | | (2.4)|----Log---->| |
743 | | | | | |
744 | | | | | |
745 | | (2.5)|---Lock Evidence--->| | |
746 | | | | | |
747 | | |<-----Receipt-------|(2.6) | |
748 | | | | | |
749 ..|.....|............|....................|............|.....|..
750 | | | | | |
752 Figure 4
754 The precise form of the evidence in step 2.5 is dependent on the type
755 of ledger technology in DLN1, and must be previously agreed upon
756 between G1 and G2 in Phase 1.
758 The purpose of this evidence is for dispute resolution between G1 and
759 G2 (i.e. the VASP entities who own and operate G1 and G2
760 respectively) in the case that double-spend is later detected.
762 The gateway G2 must return a digitally signed receipt to G1 of this
763 evidence in order to cover G1 (exculpatory proof) in the case of
764 later denial by G2.
766 8. Transfer Commitment (Phase 3)
768 In Phase 3 the gateways G1 and G2 finalizes to the asset transfer by
769 performing a commitment protocol (e.g. 2PC or 3PC) as a process (sub-
770 protocol) embedded within the overall asset transfer protocol.
772 Upon receiving the evidence-receipt message in the previous phase, G1
773 begins the commitment (see Figure 5):
775 o Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for
776 the commitment of the transfer. This message must include a hash
777 of the previous messages (message 2.5 and 2.6).
779 o Ack-prepare (3.2): Gateway G2 acknowledges the commit-prepare
780 message.
782 o Lock-final (3.3): Gateway G1 issues a lock-finalization
783 transaction or escrow finalization on ledger L1 that signals the
784 permanent extinguishment of the asset from DLN1. This transaction
785 must include a hash reference to the lock transaction on L1
786 previously in step (2.3). This indicates that the asset is no
787 longer associated with the public-key of its previous owner
788 (originator) and that the asset instance is no longer recognized
789 on the ledger L1.
791 o Commit-final (3.4): Gateway G1 indicates to G2 that G1 has
792 performed a local lock/escrow finalization on L1. This message
793 must be digitally signed by G1 and should include the block number
794 and transaction number (of the confirmed block) on ledger L1.
796 o Asset-create (3.5): Gateway G2 issues a transaction on ledger L2
797 to create (re-generate) the asset, associated with the public-key
798 of the beneficiary. This transaction must include a hash of the
799 previous message (3.4) and hash reference to the log-incoming
800 transaction on L2 previously in step (2.4). These hash references
801 connects the newly re-generated asset with the overall transfer
802 event originating from gateway G1.
804 o Ack-final (3.6): Gateway G2 indicates to G1 that G2 has performed
805 an asset-regeneration transaction on L2. This message must be
806 digitally signed by G2 and should include the block number and
807 transaction number (of the confirmed block) on ledger L2.
809 o Location-record (3.7): Gateway G1 has the option to record the
810 block number and transaction number (as reported by G2 in the
811 previous step) to ledger L1. This transaction should include a
812 hash reference to the confirmed lock-finalization transaction on
813 L1 from step 3.3. This information may aid in future search,
814 audit and accountability purposes from a legal perspective.
816 o Transfer complete (3.8): Gateway G1 must explicitly close the
817 asset transfer session with gateway G2. This allows both sides to
818 close down the secure channel established in Phase 1.
820 Orig L1 G1 G2 L2 Benef
821 | | | (Phase 2) | | |
822 | | | | | |
823 ..|.....|............|....................|............|.....|..
824 | | | Phase 3 | | |
825 | | | | | |
826 | | (3.1)|--Commit Prepare--->| | |
827 | | | | | |
828 | | |<-----ACK-Prep------|(3.2) | |
829 | | | | | |
830 | | | | | |
831 | |<--Final----|(3.3) | | |
832 | | | | | |
833 | | (3.4)|----Commit Final--->| | |
834 | | | | | |
835 | | | (3.5)|---Create-->| |
836 | | | | | |
837 | | |<-----ACK-Final-----|(3.6) | |
838 | | | | | |
839 | | | | | |
840 | |<--Record---|(3.7) | | |
841 | | | | | |
842 | | (3.8)|---Complete/End---->| | |
843 | | | | | |
844 ..|.....|............|....................|............|.....|..
845 | | | | | |
847 Figure 5
849 9. Related Open Issues
851 There are a number of open issues that are related to the asset
852 transfer protocol between gateways. Some of the issues are due to
853 the fact that blockchain technology is relatively new, and that
854 technical constructs designed for interoperability have yet to be
855 addressed. Some of the issues are due to the nascency of the virtual
856 asset industry and lack of conventions, and therefore require
857 industry collaboration to determine the standard conventions.
859 9.1. Global identification of blockchain systems and public-keys
861 There is currently no standard nomenclature to identify a DLT network
862 in a globally unique manner. The analog to this is the AS-numbers
863 associated with IP routing autonomous systems.
865 Furthermore, an address (public-key) may not be unique to one DLT
866 network. An entity (e.g. user) may in fact employ the same public-
867 key simultaneously at multiple distinct DLT networks. Thus, there is
868 no convention today with regards to the application of a key within a
869 given DLT network (comparable to the principal/ domain convention in
870 Internet host naming).
872 However, in order to perform an asset transfer from one DLT network
873 to another, there needs to be mechanism that resolves the beneficiary
874 identifier (as known to the originator) to the correct public-key and
875 DLT network as intended by the originator.
877 9.2. Discovery of gateways in DLT Networks
879 A given DLT network must possess the capability to select or
880 designate gateway that will perform an asset transfer.
882 A number of DLT networks already employ consensus mechanisms that
883 elect a gateway to perform the transaction processing (e.g. proof of
884 stake in Ethereum). The same consensus mechanisms may be used to
885 elect the gateway (e.g. out of a pool of available gateways in the
886 DLT network).
888 9.3. Remote gateway discovery
890 Related to the ability to discover other DLT networks globally is the
891 ability to discover the remote gateways for these other DLT networks.
892 A discovery mechanism for external entities (e.g. for gateway G1) to
893 look for gateways (e.g. remote gateway G2) is required in order for
894 gateways to quickly and efficiently peer without human intervention.
895 The discovery mechanism may employ the available information at
896 gateway G1, such as the originator/beneficiary public keys, the VASPs
897 (owners of the gateways) and other parameters.
899 Other approaches may also be employed, such as incorporating the
900 gateway identities within a VASP's configuration file (e.g. at a
901 well-known location), and within a global directory of regulated
902 VASPs. Approaches similar to the DNS infrastructure may provide an
903 alternative architecture for solving this problem.
905 9.4. Commitment protocols and forms of commitment evidence
907 Within Phase 2, the gateways must implement one (or more)
908 transactional commitment protocols that permit the coordination
909 between two gateways, and the final commitment of the asset transfer.
911 The choice of the commitment protocol (type/version) and the
912 corresponding commitment evidence must be negotiated between the
913 gateways during Phase 1.
915 For example, in Phase 2 and Phase 3 discussed above the gateways G1
916 and G2 may implement the classic 2 Phase Commit (2PC) protocol
917 [Gray81] as a means to ensure efficient and non-disputable
918 commitments to the asset transfer.
920 Historically, transactional commitment protocols employ locking
921 mechanisms to prevent update conflicts on the data item in question.
922 When used within the context of virtual asset transfers across DLT
923 networks, the fact that an asset has been locked by G1 (as the 2PC
924 coordinator) must be communicated to G2 (as the 2PC participant) in
925 an indisputable manner.
927 The exact form of this evidence of asset-locking must be standardized
928 (for the given transactional commitment protocol) to eliminate any
929 ambiguity.
931 10. Security Considerations
933 As a DLT network hold an increasing number of virtual assets, it may
934 become attractive to attackers seeking to compromise the
935 cryptographic keys of the entities, services and its end-users.
937 Gateways are of particular interest to attackers because they enable
938 the transferal of virtual assets to external DLT networks, which may
939 or may not be regulated. As such, hardening technologies and tamper-
940 resistant crypto-processors (e.g. TPM, SGX) should be used for
941 implementations of gateways [HS19].
943 11. Policy Considerations
945 Virtual asset transfers must be policy-driven in the sense that it
946 must observe and enforce the policies defined for the DLT network.
947 Resources that make-up a DLT network are owned and operated by
948 entities (e.g. legal persons or organizations), and these entities
949 typically operate within regulatory jurisdictions [FATF]. It is the
950 responsibility of these entities to translate regulatory policies
951 into functions on DLT networks that comply to the relevant regulatory
952 policies.
954 At the application layer, asset transfers must take into
955 consideration the legal status of assets and incorporate relevant
956 asset-related policies into their business logic. These policies
957 must permeate down to the gateways that implement the functions of
958 asset transaction processing.
960 The smart contract abstraction, based on replicated shared code/state
961 on the ledger [Herl19], must additionally incorporate the notion of
962 policy into the abstraction.
964 12. References
966 12.1. Normative References
968 [BCH21] Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway
969 Crash Recovery Mechanism, IETF, draft-belchior-gateway-
970 recovery-01.", March 2021,
971 .
974 [DLVIEW] Ramakrishna, V., Pandit, V., Nishad, S., Narayanam, K.,
975 and D. Vinayagamurthy , "Views and View Addresses for
976 Blockchain/DLT Interoperability, IETF Draft", November
977 2021.
979 [FATF] FATF, "International Standards on Combating Money
980 Laundering and the Financing of Terrorism and
981 Proliferation - FATF Revision of Recommendation 15
982 (Updated June 2021)", October 2018, .
986 [ISO] ISO, "Blockchain and distributed ledger technologies-
987 Vocabulary (ISO:22739:2020)", July 2020,
988 .
990 [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
991 Blockchain Technology Overview (NISTR-8202)", October
992 2018, .
994 [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset
995 Protocol, IETF, draft-hargreaves-odap-01.", November 2020,
996 .
998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
999 Requirement Levels", BCP 14, RFC 2119,
1000 DOI 10.17487/RFC2119, March 1997,
1001 .
1003 12.2. Informative References
1005 [ABCH20] Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and
1006 T. Hardjono, "Proposal for a Comprehensive Crypto Asset
1007 Taxonomy", May 2020, .
1009 [Abebe19] Abebe, E., Behl, D., Govindarajan, C., Hu, Y.,
1010 Karunamoorthy, D., Novotny, P., Pandit, V., Ramakrishna,
1011 V., and C. Vecchiola, "Enabling Enterprise Blockchain
1012 Interoperability with Trusted Data Transfer (Middleware
1013 2019, Industry Track)", December 2019,
1014 .
1016 [Abebe21] Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit,
1017 V., Ramakrishna, V., and J. Yu, "Verifiable Observation of
1018 Permissioned Ledgers (ICBC2021)", May 2021,
1019 .
1021 [BVGC20] Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
1022 Correia, "A Survey on Blockchain Interoperability: Past,
1023 Present, and Future Trends", May 2020,
1024 .
1026 [Clar88] Clark, D., "The Design Philosophy of the DARPA Internet
1027 Protocols, ACM Computer Communication Review, Proc SIGCOMM
1028 88, vol. 18, no. 4, pp. 106-114", August 1988.
1030 [Gray81] Gray, J., "The Transaction Concept: Virtues and
1031 Limitations, in VLDB Proceedings of the 7th International
1032 Conference, Cannes, France, September 1981, pp. 144-154",
1033 September 1981.
1035 [Herl19] Herlihy, M., "Blockchains From a Distributed Computing
1036 Perspective, Communications of the ACM, vol. 62, no. 2,
1037 pp. 78-85", February 2019,
1038 .
1040 [HLP19] Hardjono, T., Lipton, A., and A. Pentland, "Towards and
1041 Interoperability Architecture for Blockchain Autonomous
1042 Systems, IEEE Transactions on Engineering Management",
1043 June 2019, .
1045 [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted
1046 Computing Base for Blockchain Infrastructure Security,
1047 Frontiers Journal, Special Issue on Blockchain Technology,
1048 Vol. 2, No. 24", December 2019,
1049 .
1051 [IDevID] Richardson, M. and J. Yang, "A Taxonomy of operational
1052 security of manufacturer installed keys and anchors. IETF
1053 draft-richardson-t2trg-idevid-considerations-01", August
1054 2020, .
1057 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
1058 in System Design, ACM Transactions on Computer Systems,
1059 vol. 2, no. 4, pp. 277-288", November 1984.
1061 Authors' Addresses
1063 Thomas Hardjono
1064 MIT
1066 Email: hardjono@mit.edu
1068 Martin Hargreaves
1069 Quant Network
1071 Email: martin.hargreaves@quant.network
1073 Ned Smith
1074 Intel
1076 Email: ned.smith@intel.com
1078 Venkatraman Ramakrishna
1079 IBM
1081 Email: vramakr2@in.ibm.com