idnits 2.17.1
draft-hardjono-blockchain-interop-arch-02.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 (April 21, 2021) is 1101 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RATS' is mentioned on line 558, but not defined
== Missing Reference: 'HS19' is mentioned on line 871, but not defined
== Unused Reference: 'RFC2119' is defined on line 923, but no explicit
reference was found in the text
== Unused Reference: 'ABCH20' is defined on line 930, but no explicit
reference was found in the text
== Unused Reference: 'BVGC20' is defined on line 934, but no explicit
reference was found in the text
== Unused Reference: 'HLP19' is defined on line 953, but no explicit
reference was found in the text
== Outdated reference: A later version (-05) exists of
draft-belchior-gateway-recovery-01
== Outdated reference: A later version (-03) exists of
draft-hargreaves-odap-01
== Outdated reference: A later version (-09) exists of
draft-richardson-t2trg-idevid-considerations-01
Summary: 1 error (**), 0 flaws (~~), 10 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: October 23, 2021 Quant Network
6 N. Smith
7 Intel
8 April 21, 2021
10 An Interoperability Architecture for Blockchain/DLT Gateways
11 draft-hardjono-blockchain-interop-arch-02
13 Abstract
15 With the increasing interest in the potential use of blockchain
16 systems for virtual assets, there is a need for these assets to have
17 mobility across blockchain systems. An interoperability architecture
18 for blockchain systems is needed in order to permit the secure flow
19 of virtual assets between blockchain systems, satisfying the
20 properties of transfer atomicity, consistency and durability. The
21 architecture must recognize that there are different blockchain
22 systems, and that the interior constructs in these blockchains maybe
23 incompatible with one another. Gateway nodes perform the transfer of
24 virtual assets between blockchain systems while masking the
25 complexity of the interior constructs of the blockchain that they
26 represent.
28 Status of This Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at https://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on October 23, 2021.
45 Copyright Notice
47 Copyright (c) 2021 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (https://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 3. Assumptions and Principles . . . . . . . . . . . . . . . . . 6
65 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6
66 3.2. Operational Assumptions . . . . . . . . . . . . . . . . . 7
67 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
68 4.1. Goal of Architecture . . . . . . . . . . . . . . . . . . 7
69 4.2. Overview of Asset Transfer . . . . . . . . . . . . . . . 8
70 4.3. Desirable Properties of Asset Transfer . . . . . . . . . 9
71 4.4. Event log-data, crash recovery and backup gateways . . . 9
72 4.5. Overview of the Phases in Asset Transfer . . . . . . . . 10
73 5. Pre-transfer Verification of Asset and Identities (Phase 1) . 11
74 6. Evidence of asset locking or escrow (Phase 2) . . . . . . . . 13
75 7. Transfer Commitment (Phase 3) . . . . . . . . . . . . . . . . 15
76 8. Related Open Issues . . . . . . . . . . . . . . . . . . . . . 17
77 8.1. Global identification of blockchain systems and public-
78 keys . . . . . . . . . . . . . . . . . . . . . . . . . . 17
79 8.2. Discovery of gateways nodes within a blockchain system . 18
80 8.3. Remote gateway discovery . . . . . . . . . . . . . . . . 18
81 8.4. Commitment protocols and forms of commitment evidence . . 19
82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
83 10. Policy Considerations . . . . . . . . . . . . . . . . . . . . 19
84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
85 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
86 11.2. Informative References . . . . . . . . . . . . . . . . . 21
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
89 1. Introduction
91 Currently there is little technical interoperability between
92 blockchain systems. This results in the difficulty in transferring
93 or migrating virtual assets associated with a public-key (address)
94 from one blockchain or DLT system to another directly.
96 The existing solutions involve a third party that mediates the
97 transfer. This mediating third party is typically an asset-exchange
98 entity (i.e. crypto-exchange) operating in a centralized hub-spoke
99 fashion. This reliance on a third party results not only delays in
100 transfers, but also in the need for asset owner to have a business
101 relationship (e.g. open accounts) at the mediating third party. Many
102 of these solutions centralize control at the hands of the mediating
103 party, thereby diminishing the autonomy of blockchains and DLT
104 systems, and limits their scalability.
106 This This document describes an architecture for gateways for
107 blockchains and DLT systems that permit a direct transfer of assets
108 without a mediating third party. A given blockchain or DLT system
109 may have one or more gateway nodes to perform a unidirectional direct
110 transfer of virtual assets to blockchain or DLT system possessing one
111 or more compatible gateway nodes. Similar to the notion of border
112 gateways in interdomain routing (e.g. running the BGPv4 protocol), a
113 blockchain gateway belonging to an origin blockchain or DLT system is
114 said to peer with another gateway is a destination blockchain or DLT
115 system. Both gateways must implement an asset transfer protocol that
116 must satisfy certain security, privacy and atomicity requirements.
118 The purpose of this architecture document is to provide technical
119 framework within which to discuss the various aspects of a transfer
120 between two gateways, including security aspects and transfer
121 atomicity aspects.
123 2. Terminology
125 There following are some terminology used in the current document:
127 o Blockchain system: Blockchains are distributed digital ledgers of
128 cryptographically signed transactions that are grouped into
129 blocks. Each block is cryptographically linked to the previous
130 one (making it tamper evident) after validation and undergoing a
131 consensus decision. As new blocks are added, older blocks become
132 more difficult to modify (creating tamper resistance). New blocks
133 are replicated across copies of the ledger within the network, and
134 any conflicts are resolved automatically using established rules
135 [NIST].
137 o Distributed ledger technology (DLT) system: Technology that
138 enables the operation and use of distributed ledgers, where the
139 ledger is shared (replicated) across a set of DLT nodes and
140 synchronized between the DLT nodes using a consensus mechanism
141 [ISO].
143 o Resource Domain: Resource Domain: The collection of resources and
144 entities participating within a blockchain or DLT system. The
145 domain denotes an boundary for permissible or authorized actions
146 on resources.
148 o Interior Resources: The various interior protocols, data
149 structures and cryptographic constructs that are a core part of a
150 blockchain or DLT system. Examples of interior resources include
151 the ledger (blocks of confirmed transaction data), public keys on
152 the ledger, consensus protocol, incentive mechanisms, transaction
153 propagation networks, etc.
155 o Exterior Resources: The various resources that are outside a
156 blockchain or DLT system, and are not part of the operations of
157 the system. Examples include data located at third parties such
158 as asset registries, ledgers of other blockchain/DLT systems, PKI
159 infrastructures, etc.
161 o Nodes: The nodes of the blockchain or DLT system which form the
162 peer-to-peer network, which collectively maintain the shared
163 ledger in the system by following a consensus algorithm.
165 o Gateway nodes: The nodes of the blockchain or DLT system that are
166 functionally capable of acting as a gateway in an asset transfer.
167 A gateway node implements the gateway-to-gateway asset transfer
168 protocol. Being a node on the blockchain/DLT system, a gateway
169 has read/write access to the interior resources (e.g. ledger) of
170 the blockchain. It participates in the consensus mechanism
171 deployed for the system. Depending on the blockchain/DLT system
172 implementation, some or all of the nodes may be gateway-capable.
174 o Blockchain address: This is the public-key of an entity as known
175 within a blockchain system, employed to transact on the blockchain
176 network and recorded on the ledger of the blockchain. Also
177 referred to as the transaction public key.
179 o Entity public-key pair: This the private-public key pairs of an
180 entity used for interactions outside the blockchain or DLT system
181 (e.g. TL1.3). The term is used to distinguish this public-key
182 from the blockchain address.
184 o Asset transfer protocol: The gateway-to-gateway technical protocol
185 used by two gateway nodes to perform a unidirectional transfer of
186 a virtual asset.
188 o Asset profile: The prospectus of a regulated asset that includes
189 information and resources describing the virtual asset. This
190 includes, among others, the asset name/code, issuing authority,
191 denomination, jurisdiction, and the URLs and mechanisms to
192 validate the information. The asset profile is independent from
193 the specific instantiation of the asset (on a blockchain or
194 otherwise) and independent from its instance-ownership
195 information.
197 o Virtual Asset: A virtual asset is a digital representation of
198 value that can be digitally traded, or transferred as defined by
199 the FATF [FATF].
201 o Virtual Asset Service Provider (VASP): Legal entity handling
202 virtual assets as defined by the FATF [FATF].
204 o Originator: Person or organization seeking the transfer of virtual
205 asset to a beneficiary
207 o Beneficiary: Person or organization receiving the transferred
208 virtual asset from an originator.
210 o Travel Rule information: Data regarding the VASPs, originators and
211 beneficiaries involved in an asset transfer, as defined by the
212 FATF [FATF] and as required by the jurisdiction of operations of
213 the VASPs.
215 o Gateway device identity: The identity of the device implementing
216 the gateway functions. The term is used in the sense of IDevID
217 (IEEE 802.1AR) or EK/AIK (in TPM1.2 and TPM2.0) [IDevID].
219 o Gateway owner: The VASP who legally owns and operates a gateway
220 node within a blockchain system.
222 o Passive transaction: A transaction aimed at recording some state
223 metadata information on the ledger that does not affect assets
224 recorded on the ledger. A passive transaction can be self-
225 addressed (or has null as destination address) and can be used to
226 signal implicitly to other nodes regarding an state-change of the
227 metadata pertaining to an entity or an asset on the ledger.
229 o Asset locking or escrow: The conditional mechanism used within a
230 blockchain or DLT system to make an asset temporarily unavailable
231 for use by its owner. The condition of the asset release can be
232 based on a duration of time (e.g. hash time locks) or other
233 parameters.
235 o Gateway crash recovery: The local process by which a crashed
236 gateway (i.e. device or system fault) is returned back into a
237 consistent and operational state, ready to resume the asset
238 transfer protocol with the peer gateway prior to the crash event.
240 Further terminology definitions can be found in [NIST] and [ISO].
241 The term 'blockchain' and 'distributed ledger technology' (DLT) are
242 used interchangeably in this document.
244 3. Assumptions and Principles
246 The following assumptions and principles underlie the design of the
247 current interoperability architecture, and correspond to the design
248 principles of the Internet architecture.
250 3.1. Design Principles
252 o Opaque blockchain resources: The interior resources of each
253 blockchain system is assumed to be opaque to (hidden from)
254 external entities. Any resources to be made accessible to an
255 external entity must be made explicitly accessible by a gateway
256 node with proper authorization.
258 o Externalization of value: The gateway protocol is agnostic
259 (oblivious) to the economic or monetary value of the virtual asset
260 being transferred.
262 The opaque resources principle permits the interoperability
263 architecture to be applied in cases where one (or both) blockchain
264 systems are permissioned (private). It is the analog of the
265 autonomous systems principle in IP networking [Clar88], where
266 interior routes in local subnets are not visible to other external
267 autonomous systems.
269 The value-externalization principle permits asset transfer protocols
270 to be designed for efficiency, speed and reliability - independent of
271 the changes in the perceived economic value of the virtual asset. It
272 is the analog of the end-to-end principle in the Internet
273 architecture [SRC84], where contextual information (economic value)
274 is placed at the endpoints of the transaction. In the case of a
275 transfer of virtual assets, the originator and beneficiary at the
276 respective blockchain systems are assumed to have a common agreement
277 regarding the economic value of the asset. This context of the
278 economic meaning of the value of the asset is assumed to exists at
279 the end-points, namely at the originator and beneficiary.
281 3.2. Operational Assumptions
283 The following conditions are assumed to have occurred, leading to the
284 invocation of the asset transfer protocol between two gateway nodes:
286 o Application layer transfer request: The transfer request from an
287 originator in the origin blockchain is assumed to have occurred
288 prior to the execution of the asset transfer protocol.
290 o Identification of originator and beneficiary: The originator and
291 beneficiary are assumed to have been identified and that consent
292 has been obtained from both parties regarding the asset transfer.
294 o Identification of origin and destination blockchain: The origin
295 and destination blockchain systems is assumed to have been
296 identified.
298 o Selection of gateway nodes: The two gateway nodes at the origin
299 and destination blockchain systems respectively is assumed to have
300 been identified and selected.
302 o Identification of gateway-node owners (VASP): The VASP operating
303 the gateway nodes are assumed to have been identified and their
304 legal status verified [FATF].
306 4. Architecture
308 4.1. Goal of Architecture
310 The goal of the interoperability architecture is to permit two (2)
311 gateway nodes belonging to distinct blockchain systems to conduct a
312 virtual asset transfer between them, in a secure and non-repudiable
313 manner while ensuring the asset does not exist simultaneously on both
314 blockchains (double-spend problem).
316 The virtual asset as understood by the two gateway nodes is a digital
317 representation of value, expressed in an standard digital format in a
318 way meaningful to the gateway nodes syntactically and semantically.
320 The syntactic representation of the virtual asset between the two
321 gateways need not bear any resemblance to the syntactic asset
322 representation within their respective blockchain systems.
324 The architecture recognizes that there are different blockchain
325 systems currently in operation and evolving, and that in many cases
326 the interior technical constructs in these blockchains maybe
327 incompatible with one another.
329 The architecture therefore assumes that certain types of nodes
330 (gateway nodes) will be equipped with an asset transfer protocol and
331 with other relevant resources that permits greater interoperability
332 across these incompatible blockchain systems.
334 The resources within a blockchain system (e.g. ledgers, public-keys,
335 consensus protocols, etc.) are assumed to be opaque to external
336 entities in order to permit a resilient and scalable protocol design
337 that is not dependent on the interior constructs of particular
338 blockchain systems. This ensures that the virtual asset transfer
339 protocol between gateways is not conditioned or dependent on these
340 local technical constructs. The role of a gateway therefore is also
341 to mask (hide) the complexity of the interior constructs of the
342 blockchain system that it represents. Overall this approach ensures
343 that a given blockchain system operates as a true autonomous system.
345 The current architecture focuses on unidirectional asset transfers,
346 although the building blocks in this architecture can be used to
347 support protocols for bidirectional transfers (conditional two
348 unidirectional transfers).
350 For simplicity the current architecture employs two (2) gateway nodes
351 in the respective blockchains, but collective multi-node transfers
352 (i.e. multiple nodes at each side) [HS2019] may be developed based on
353 the building blocks and constructs identified in the current
354 architecture.
356 4.2. Overview of Asset Transfer
358 An asset transfer between two blockchain systems is carried out by
359 two (2) gateway nodes in a direct interaction (unmediated), where the
360 gateway represents the two respective blockchain systems.
362 A successful transfer results in the asset being extinguished
363 (deleted) or marked on the origin ledger by the origin-gateway, and
364 for the asset to be introduced by the destination-gateway into the
365 destination ledger.
367 The mechanism to extinguish or introduce an asset from/into a ledger
368 is dependent on the specific blockchain system. The task of the
369 respective gateway is to implement the relevant mechanism to modify
370 the ledger of their corresponding blockchain system in such a way
371 that together the two blockchains maintain consistency from the asset
372 perspective, while observing the design principles of the
373 architecture.
375 An asset transfer protocol that can satisfy the properties of
376 atomicity and consistency in the case of two private blockchain
377 systems, should also satisfy the same properties in the case when one
378 or both are public blockchain systems.
380 4.3. Desirable Properties of Asset Transfer
382 The desirable features of asset transfers between two gateway nodes
383 include, but not limited, to the following:
385 o Atomicity: Transfer must either commit or entirely fail (failure
386 means no change to asset ownership).
388 o Consistency: Transfer (commit or fail) always leaves both
389 blockchains in a consistent state (asset located in the ledger of
390 one blockchain only).
392 o Isolation: While transfer occurring, asset ownership cannot be
393 modified (no double-spend).
395 o Durability: Once a transfer has been committed, must remain so
396 regardless of gateway crashes.
398 o Verifiable by authorized third parties: With proper authorization
399 to access relevant interior resources, third party entities must
400 be able at any time to perform audit-validation of the two
401 respective ledgers for asset transfers across the corresponding
402 blockchain systems.
404 o Containment of side-effects: Any effects due to errors or
405 security/integrity breaches in a blockchain system during an asset
406 transfer must be contained within that blockchain.
408 An implementation of the asset transfer protocol should satisfy these
409 properties, independent of whether the implementation employs
410 stateful messaging or stateless messaging between the two gateways.
412 4.4. Event log-data, crash recovery and backup gateways
414 Implementations of gateway nodes should maintain event logs and
415 checkpoints for the purpose of gateway crash recovery. The log-data
416 generated by a gateway should be considered as an interior resource
417 accessible to other authorized gateway nodes within the same
418 blockchain system
420 Mechanisms used to select or elect a gateway node in a blockchain
421 system for a given asset transfer could be extended to include the
422 selection of a backup gateway node. The primary gateway and the
423 backup gateway may or may not belong to the same owner (VASP).
425 Some blockchain systems may utilize the ledger itself as means to
426 retain the log-data, allowing other nodes in the blockchain to have
427 visibility and access to the gateway log-data. Other blockchain
428 systems may employ off-chain storage that is accessible to all
429 gateway nodes in the blockchain domain. In such cases, to provide
430 event-sequencing integrity the gateway may store a hash of the log-
431 data on the ledger of the blockchain (passive transaction) prior to
432 writing the log-data to the off-chain storage.
434 The mechanism used to provide gateway crash-recovery is dependent on
435 the blockchain system and the gateway implementation. For
436 interoperability purposes the information contained in the log and
437 the format of the log-data should be standardized, permitting vendors
438 of gateway products to reduce development costs over time.
439 Similarly, in order to ensure a high degree of interoperability
440 across crash-recovery protocol implementations [BCH21], a
441 standardized interface (e.g. REST APIs) should be defined for read/
442 write access to the log-storage. The interface should hide the
443 details of the log-storage from the gateway itself, and it should be
444 independent of the node recovery strategy (e.g. self-healing,
445 primary-backup node, etc.).
447 The resumption of an interrupted transfer (e.g. due to gateway crash,
448 network failure, etc.) should take into consideration the aspects of
449 secure channel establishment and the aspects of the transfer protocol
450 resumption. In some cases, a new secure channel (e.g. TLS session)
451 must be established netween the two gateways nodes, within which the
452 asset transfer protocol could be continued from the last checkpoint
453 prior to the interruption. However, in other cases both the secure
454 channel and the transfer protocol may need to be started completely
455 afresh (no resumption).
457 The log-data collected by a gateway node acts also as a checkpoint
458 mechanism to assist the recovered (or backup) gateway node in
459 continuing the transfer. The point at which to re-start the transfer
460 protocol flow is dependent on the implementation of the gateway
461 recovery strategy. Some owners (VASPs) of gateway nodes may choose
462 to start afresh the transfer of the asset, and not to resume
463 partially completed transfers (e.g. for easier legal audit purposes).
465 4.5. Overview of the Phases in Asset Transfer
467 The interaction between two gateways in an asset transfer is
468 summarized in Figure 1, where the origin blockchain is B1 and the
469 destination blockchain is B2. The gateways are denoted as G1 and G2
470 respectively.
472 Originator
473 |
474 +-------------+
475 | Client |
476 |(Application)|
477 +-------------+
478 |
479 | Phases
480 V
481 +-------------+ |<-----(1)----->| +-------------+
482 | Blockchain | +----+ +----+ | Blockchain |
483 | System B1 | |Gate| |Gate| | System B2 |
484 | |--|way |<-----(2)----->|way |--| |
485 | +---------+ | | G1 | | G2 | | +---------+ |
486 | |Ledger L1| | +----+ +----+ | |Ledger L2| |
487 | +---------+ | |<-----(3)----->| | +---------+ |
488 +-------------+ +-------------+
490 Figure 1
492 The three phases are summarized as follows.
494 o Phase 1: Pre-transfer Verification of Asset and Identities. In
495 this phase the gateways G1 and G2 must mutually identify
496 themselves and authenticate that both possess gateway-
497 capabilities. Gateway G1 must communicate to G2 the asset-profile
498 of the asset to be transferred, and that consent have been
499 obtained from the beneficiary regarding accepting the transfer.
501 o Phase 2: Evidence of asset locking or escrow. In this phase,
502 gateway G1 must provide gateway G2 with sufficient evidence that
503 the asset on blockchain B1 is in a locked state (or escrowed)
504 under the control of G1 on ledger L1, and safe from double-spend
505 by its current owner (the originator).
507 o Phase 3: Transfer commitment. In this phase gateways G1 and G2
508 commit to the unidirectional asset transfer.
510 These phases will be further discussed below.
512 5. Pre-transfer Verification of Asset and Identities (Phase 1)
514 The primary purpose of the first phase is to verify the various
515 information relating to the asset to be transferred, the identities
516 of the originator and beneficiary, the identity and legal status of
517 the entities (VASPs) who own and operate the gateways, the blockchain
518 or DLT system type and network parameters, and the device-identities
519 of the gateways.
521 Orig L1 G1 G2 L2 Benef
522 | | | | | |
523 |---request------->| | | |
524 | | | | | |
525 ..|.....|............|....................|............|.....|..
526 | | | Phase 1 | | |
527 | | | | | |
528 | | (1.1)|<-----VASP id------>| | |
529 | | | | | |
530 | | | | | |
531 | | (1.2)|<--Asset Profile--->| | |
532 | | | | | |
533 | | | | | |
534 | | (1.3)|<--Orig/Benef id--->| | |
535 | | | | | |
536 ..|.....|............|....................|............|.....|..
537 | | | | | |
539 Figure 2
541 This phase starts with the assumption that in blockchain B1 the
542 gateway to process the asset transfer to B2 has been selected (namely
543 gateway G1). It also assumes that the destination blockchain B2 has
544 been identified where the beneficiary address is located, and that
545 gateway G2 in blockchain B2 has been identified that will peer with
546 G1 to perform the transfer.
548 There are several steps that may occur in Phase 1 (see Figure 2):
550 o Secure channel establishment between G1 and G2: This includes the
551 mutual verification of the gateway device identities and the
552 exchange of the relevant parameters for secure channel
553 establishment. In cases where device attestation [RATS] is
554 required, the mutual attestation protocol must occur between G1
555 and G2 prior to proceeding to the next phase.
557 o Mutual device attestations: In cases where device attestation
558 [RATS] is required, each gateway must yield attestation evidence
559 to the other regarding its configuration. A gateway may take on
560 the role as a attestation verifier, or it may rely on an external
561 verifier to appraise the received evidence.
563 o Validation of the gateway ownership: There must be a means for
564 gateway G1 and G2 to verify their respective ownerships (i.e.
565 VASP1 owning G1 and VASP2 owning G2 respectively). Examples of
566 ownership verification mechanism include the chaining of the
567 gateway-device X.509 certificate up to the VASP entity
568 certificate, directories of gateways and VASPs, and others.
570 o Validation of VASP status: In some jurisdictions limitations may
571 be placed for regulated VASPs to transact only with other
572 similarly regulated VASPs. Examples of mechanisms used to
573 validate a VASP legal status include VASP directories, Extended
574 Validation (EV) X.509 certificates for VASPs, and others.
576 o Identification and validation of asset profile: Both gateways must
577 agree on the type of asset being transferred based on the profile
578 of the asset. Gateway G1 must communicate the asset-profile
579 identification to gateway G2, who in turn must validate both the
580 legal status of the asset as well as the technical capability of
581 the blockchain B2 to digitally represent the asset type within its
582 ledger L2. The policies governing blockchain B2 with regards to
583 permissible incoming assets must be enforced by G2.
585 o Exchange of Travel Rule information and validation: In
586 jurisdictions where the Travel Rule policies regarding originator
587 and beneficiary information is enforced [FATF], the owners of
588 gateways G1 and G2 must comply to the Travel Rule. Mechanisms
589 must be used to permit gateways G1 and G2 to make available
590 originator/beneficiary information to one another in such away
591 that the Travel Rule information can be logged as part of the
592 asset transfer history.
594 o Negotiation of asset transfer protocol parameters: Gateway G1 and
595 G2 must agree on the parameters to be employed within the asset
596 transfer protocol. Examples include endpoints definitions for
597 resources, type of commitment flows (e.g. 2PC or 3PC), lock-time
598 durations, and others [ODAP].
600 6. Evidence of asset locking or escrow (Phase 2)
602 The asset transfer protocol can commence when both gateways G1 and G2
603 have completed the verifications in Phase 1.
605 The steps of Phase 2 are summarized in Figure 3, and broadly consists
606 of the following:
608 o Commencement (2.1): Gateway G1 indicates the start of the asset
609 transfer protocol by sending a transfer-commence message to
610 gateway G2. Among others, the message must include a
611 cryptographic hash of the information agreed-upon in Phase 1 (e.g.
612 asset profile, gateway identities, originator/beneficiary public
613 keys, etc.).
615 o Acknowledgement (2.2): The gateway G2 must send an explicit
616 acknowledgement of the receipt of the commence message, which
617 should include a hash of commencement message (2.1) and other
618 relevant session parameters.
620 o G1 lock/escrow asset (2.3): Gateway G1 proceeds to lock or escrow
621 the asset belonging to the originator on ledger L1. The lock may
622 take the form of passive transaction that signals to other nodes
623 that the asset is temporarily inaccessible. This signals to other
624 nodes in the blockchain system to ignore other transactions
625 pertaining to the asset until such time the lock by G1 is
626 finalized or released. A time-lock or escrow may also be
627 employed. The mode of the escrow may depend on the fundamental
628 ledger architecture of the respective blockchains B1 and B2 in
629 question (e.g. account-based, UTXO, or other).
631 o G2 log incoming asset (2.4): Gateway G2 correspondingly writes a
632 non-committing log (passive transaction) on ledger L2 indicating
633 an imminent arrival of the asset to L2. This may act as a
634 notification for the beneficiary regarding the asset transfer.
636 o Lock Evidence (2.5): Gateway G1 sends a digitally signed evidence
637 regarding the lock (escrow) performed by G1 on the asset on ledger
638 L1. The signature by G1 is performed using its entity public-key
639 pair. This signifies that G1 (i.e. its owner VASP) is standing
640 behind the assertion regarding the lock/escrow on the asset
641 performed by G1.
643 o Evidence receipt (2.6): If gateway G2 accepts the evidence, G2
644 then responds with a digitally signed receipt message which
645 includes a hash of the previous lock-evidence message. Otherwise,
646 if G2 declines the evidence then G2 can ignore the transfer and
647 let it time-out (i.e. transfer failed). The signature by G2 is
648 performed using its entity public-key pair.
650 Orig L1 G1 G2 L2 Benef
651 | | | (Phase 1) | | |
652 | | | | | |
653 ..|.....|............|....................|............|.....|..
654 | | | Phase 2 | | |
655 | | | | | |
656 | | (2.1)|-----Commence------>| | |
657 | | | | | |
658 | | |<-------ACK---------|(2.2) | |
659 | | | | | |
660 | | | | | |
661 | |<---Lock----|(2.3) | | |
662 | | | (2.4)|----Log---->| |
663 | | | | | |
664 | | | | | |
665 | | (2.5)|---Lock Evidence--->| | |
666 | | | | | |
667 | | |<-----Receipt-------|(2.6) | |
668 | | | | | |
669 ..|.....|............|....................|............|.....|..
670 | | | | | |
672 Figure 3
674 The precise form of the evidence in step 2.5 is dependent on the
675 blockchain system in B1, and must be previously agreed upon between
676 G1 and G2 in Phase 1.
678 The purpose of this evidence is for dispute resolution between G1 and
679 G2 (i.e. the VASP entities who own and operate G1 and G2
680 respectively) in the case that double-spend is later detected.
682 The gateway G2 must return a digitally signed receipt to G1 of this
683 evidence in order to cover G1 (exculpatory proof) in the case of
684 later denial by G2.
686 7. Transfer Commitment (Phase 3)
688 In Phase 3 the gateways G1 and G2 finalizes to the asset transfer by
689 performing a commitment protocol (e.g. 2PC or 3PC) as a process (sub-
690 protocol) embedded within the overall asset transfer protocol.
692 Upon receiving the evidence-receipt message in the previous phase, G1
693 begins the commitment (see Figure 4):
695 o Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for
696 the commitment of the transfer. This message must include a hash
697 of the previous messages (message 2.5 and 2.6).
699 o Ack-prepare (3.2): Gateway G2 acknowledges the commit-prepare
700 message.
702 o Lock-final (3.3): Gateway G1 issues a lock-finalization
703 transaction (passive transaction) or escrow finalization on ledger
704 L1 that signals the permanent extinguishment of the asset
705 blockchain B1. This transaction must include a hash reference to
706 the lock transaction on L1 previously in step (2.3). This
707 indicates that the asset is no longer associated with the public-
708 key of its previous owner (originator) and that the asset instance
709 is no longer recognized on the ledger L1.
711 o Commit-final (3.4): Gateway G1 indicates to G2 that G1 has
712 performed a local lock/escrow finalization on L1. This message
713 must be digitally signed by G1 and should include the block number
714 and transaction number (of the confirmed block) on ledger L1.
716 o Asset-create (3.5): Gateway G2 issues a transaction on ledger L2
717 to create (re-generate) the asset, associated with the public-key
718 of the beneficiary. This transaction must include a hash of the
719 previous message (3.4) and hash reference to the log-incoming
720 transaction on L2 previously in step (2.4). These hash references
721 connects the newly re-generated asset with the overall transfer
722 event originating from gateway G1.
724 o Ack-final (3.6): Gateway G2 indicates to G1 that G2 has performed
725 an asset-regeneration transaction on L2. This message must be
726 digitally signed by G2 and should include the block number and
727 transaction number (of the confirmed block) on ledger L2.
729 o Location-record (3.7): Gateway G1 has the option to record the
730 block number and transaction number (as reported by G2 in the
731 previous step) to ledger L1, using a passive transaction. This
732 transaction should include a hash reference to the confirmed lock-
733 finalization transaction on L1 from step 3.3. This information
734 may aid in future search, audit and accountability purposes from a
735 legal perspective.
737 o Transfer complete (3.8): Gateway G1 must explicitly close the
738 asset transfer session with gateway G2. This allows both sides to
739 close down the secure channel established in Phase 1.
741 Orig L1 G1 G2 L2 Benef
742 | | | (Phase 2) | | |
743 | | | | | |
744 ..|.....|............|....................|............|.....|..
745 | | | Phase 3 | | |
746 | | | | | |
747 | | (3.1)|--Commit Prepare--->| | |
748 | | | | | |
749 | | |<-----ACK-Prep------|(3.2) | |
750 | | | | | |
751 | | | | | |
752 | |<--Final----|(3.3) | | |
753 | | | | | |
754 | | (3.4)|----Commit Final--->| | |
755 | | | | | |
756 | | | (3.5)|---Create-->| |
757 | | | | | |
758 | | |<-----ACK-Final-----|(3.6) | |
759 | | | | | |
760 | | | | | |
761 | |<--Record---|(3.7) | | |
762 | | | | | |
763 | | (3.8)|---Complete/End---->| | |
764 | | | | | |
765 ..|.....|............|....................|............|.....|..
766 | | | | | |
768 Figure 4
770 8. Related Open Issues
772 There are a number of open issues that are related to the asset
773 transfer protocol between gateway nodes. Some of the issues are due
774 to the fact that blockchain technology is relatively new, and that
775 technical constructs designed for interoperability have yet to be
776 addressed. Some of the issues are due to the nascency of the virtual
777 asset industry and lack of conventions, and therefore require
778 industry collaboration to determine the standard conventions.
780 8.1. Global identification of blockchain systems and public-keys
782 There is currently no standard nomenclature to identify blockchain
783 systems in a globally unique manner. The analog to this is the AS-
784 numbers associated with IP routing autonomous systems.
786 Furthermore, an address (public-key) may not be unique to one
787 blockchain system. An entity (e.g. user) may in fact employ the same
788 public-key at multiple distinct blockchain systems simultaneously.
789 Thus, there is no convention today with regards to the application of
790 a key within a given blockchain system (comparable to the principal/
791 domain convention in Internet host naming).
793 However, in order to perform an asset transfer from one blockchain
794 system to another, there needs to be mechanism that resolves the
795 beneficiary identifier (as known to the originator) to the correct
796 public-key and blockchain system as intended by the originator.
798 8.2. Discovery of gateways nodes within a blockchain system
800 A given blockchain system must possess the capability to select or
801 designate gateway nodes that will perform an asset transfer across
802 blockchain systems.
804 A number of blockchain systems already employ consensus mechanisms
805 that elect a node to perform the transaction processing (e.g. proof
806 of stake in Ethereum). The same consensus mechanisms may be used to
807 elect the gateway node.
809 However, there are some blockchain systems that do not elect a single
810 node and which employ a race-to-process strategy (e.g. proof of work
811 in Bitcoin). Since the winner of the proof of work can be any node
812 in the blockchain system, this implies that all the nodes in these
813 types of blockchains must be gateway-capable.
815 8.3. Remote gateway discovery
817 Related to the ability to discover other blockchain/DLT systems
818 globally is the ability to discover the remote gateways for these
819 other blockchain/DLT systems. A discovery mechanism for external
820 entities (e.g. for gateway G1) to look for gateway-capable nodes
821 (e.g. remote gateway G2) is required in order for gateways to quickly
822 and efficiently peer without human intervention. The discovery
823 mechanism may employ the available information at gateway G1, such as
824 the originator/beneficiary public keys, the VASPs (owners of the
825 gateways) and other parameters.
827 Other approaches may also be employed, such as incorporating the
828 gateway identities within a VASP's configuration file (e.g. at a
829 well-known location), and within a global directory of regulated
830 VASPs. Approaches similar to the DNS infrastructure may provide an
831 alternative architecture for solving this problem.
833 8.4. Commitment protocols and forms of commitment evidence
835 Within Phase 2, the gateway nodes must implement one (or more)
836 transactional commitment protocols that permit the coordination
837 between two gateways, and the final commitment of the asset transfer.
839 The choice of the commitment protocol (type/version) and the
840 corresponding commitment evidence must be negotiated between the
841 gateways during Phase 1.
843 For example, in Phase 2 and Phase 3 discussed above the gateways G1
844 and G2 may implement the classic 2 Phase Commit (2PC) protocol
845 [Gray81] as a means to ensure efficient and non-disputable
846 commitments to the asset transfer.
848 Historically, transactional commitment protocols employ locking
849 mechanisms to prevent update conflicts on the data item in question.
850 When used within the context of virtual asset transfers across
851 blockchain systems, the fact that an asset has been locked by G1 (as
852 the 2PC coordinator) must be communicated to G2 (as the 2PC
853 participant) in an indisputable manner.
855 The exact form of this evidence of asset-locking must be standardized
856 (for the given transactional commitment protocol) to eliminate any
857 ambiguity.
859 9. Security Considerations
861 Although the current interoperability architecture for blockchain
862 gateways assumes the externalization of the value of assets, as a
863 blockchain system holds an increasing number of virtual assets it
864 becomes attractive to attackers seeking to obtain cryptographic keys
865 of its nodes and its end-users.
867 Gateway nodes are of particular interest to attackers because they
868 enable the transferal of virtual assets to external blockchain
869 systems, which may or may not be regulated. As such, hardening
870 technologies and tamper-resistant crypto-processors (e.g. TPM, SGX)
871 should be used for implementations of gateways [HS19].
873 10. Policy Considerations
875 Virtual asset transfers must be policy-driven in the sense that it
876 must observe and enforce the policies defined for the blockchain
877 domain. Resources that make-up a blockchain systems are owned and
878 operated by entities (e.g. legal persons or organizations), and these
879 entities typically operate within regulatory jurisdictions [FATF].
880 It is the responsibility of these entities to translate regulatory
881 policies into functions on blockchain systems that comply to the
882 relevant regulatory policies.
884 At the application layer, asset transfers must take into
885 consideration the legal status of assets and incorporate relevant
886 asset-related policies into their business logic. These policies
887 must permeate down to the nodes that implement the functions of asset
888 transaction processing.
890 The smart contract abstraction, based on replicated shared code/state
891 on the ledger [Herl19], must additionally incorporate the notion of
892 policy into the abstraction.
894 11. References
896 11.1. Normative References
898 [BCH21] Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway
899 Crash Recovery Mechanism, IETF, draft-belchior-gateway-
900 recovery-01.", March 2021,
901 .
904 [FATF] FATF, "International Standards on Combating Money
905 Laundering and the Financing of Terrorism and
906 Proliferation - FATF Revision of Recommendation 15",
907 October 2018, .
911 [ISO] ISO, "Blockchain and distributed ledger technologies-
912 Vocabulary (ISO:22739:2020)", July 2020,
913 .
915 [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
916 Blockchain Technology Overview (NISTR-8202)", October
917 2018, .
919 [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset
920 Protocol, IETF, draft-hargreaves-odap-01.", November 2020,
921 .
923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
924 Requirement Levels", BCP 14, RFC 2119,
925 DOI 10.17487/RFC2119, March 1997,
926 .
928 11.2. Informative References
930 [ABCH20] Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and
931 T. Hardjono, "Proposal for a Comprehensive Crypto Asset
932 Taxonomy", May 2020, .
934 [BVGC20] Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
935 Correia, "A Survey on Blockchain Interoperability: Past,
936 Present, and Future Trends", May 2020,
937 .
939 [Clar88] Clark, D., "The Design Philosophy of the DARPA Internet
940 Protocols, ACM Computer Communication Review, Proc SIGCOMM
941 88, vol. 18, no. 4, pp. 106-114", August 1988.
943 [Gray81] Gray, J., "The Transaction Concept: Virtues and
944 Limitations, in VLDB Proceedings of the 7th International
945 Conference, Cannes, France, September 1981, pp. 144-154",
946 September 1981.
948 [Herl19] Herlihy, M., "Blockchains From a Distributed Computing
949 Perspective, Communications of the ACM, vol. 62, no. 2,
950 pp. 78-85", February 2019,
951 .
953 [HLP19] Hardjono, T., Lipton, A., and A. Pentland, "Towards and
954 Interoperability Architecture for Blockchain Autonomous
955 Systems, IEEE Transactions on Engineering Management",
956 June 2019, .
958 [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted
959 Computing Base for Blockchain Infrastructure Security,
960 Frontiers Journal, Special Issue on Blockchain Technology,
961 Vol. 2, No. 24", December 2019,
962 .
964 [IDevID] Richardson, M. and J. Yang, "A Taxonomy of operational
965 security of manufacturer installed keys and anchors. IETF
966 draft-richardson-t2trg-idevid-considerations-01", August
967 2020, .
970 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
971 in System Design, ACM Transactions on Computer Systems,
972 vol. 2, no. 4, pp. 277-288", November 1984.
974 Authors' Addresses
976 Thomas Hardjono
977 MIT
979 Email: hardjono@mit.edu
981 Martin Hargreaves
982 Quant Network
984 Email: martin.hargreaves@quant.network
986 Ned Smith
987 Intel
989 Email: ned.smith@intel.com