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