idnits 2.17.1 draft-hardjono-blockchain-interop-arch-01.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 (October 27, 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RATS' is mentioned on line 504, but not defined == Missing Reference: 'HS19' is mentioned on line 782, but not defined == Unused Reference: 'RFC2119' is defined on line 829, but no explicit reference was found in the text == Unused Reference: 'ABCH20' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'BVGC20' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'HLP19' is defined on line 859, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hargreaves-odap-00 == Outdated reference: A later version (-09) exists of draft-richardson-t2trg-idevid-considerations-01 Summary: 1 error (**), 0 flaws (~~), 9 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: April 30, 2021 Quant Network 6 N. Smith 7 Intel 8 October 27, 2020 10 An Interoperability Architecture for Blockchain Gateways 11 draft-hardjono-blockchain-interop-arch-01 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 April 30, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . 5 65 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Operational Assumptions . . . . . . . . . . . . . . . . . 6 67 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Goal of Architecture . . . . . . . . . . . . . . . . . . 6 69 4.2. Overview of Asset Transfer . . . . . . . . . . . . . . . 7 70 4.3. Desirable Properties of Asset Transfer . . . . . . . . . 8 71 4.4. Event log-data, crash recovery and backup gateways . . . 8 72 4.5. Overview of the Phases in Asset Transfer . . . . . . . . 9 73 5. Pre-transfer Verification of Asset and Identities (Phase 1) . 10 74 6. Evidence of asset locking or escrow (Phase 2) . . . . . . . . 12 75 7. Transfer Commitment (Phase 3) . . . . . . . . . . . . . . . . 14 76 8. Related Open Issues . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Global identification of blockchain systems and public- 78 keys . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.2. Selection of gateways nodes within a blockchain system . 16 80 8.3. Commitment protocols and forms of commitment evidence . . 16 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 10. Policy Considerations . . . . . . . . . . . . . . . . . . . . 17 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 11.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 Currently there is little technical interoperability between 91 blockchain systems. This results in the difficulty in transferring 92 or migrating virtual assets associated with a public-key (address) in 93 one blockchain system to another blockchain system. 95 The existing solutions involve a third party that mediates the 96 transfer. This mediating third party is typically an asset-exchange 97 entity (i.e. crypto-exchange) operating in a centralized hub-spoke 98 fashion. This reliance on a third party results not only delays in 99 transfers, but also in the need for key-holders to open accounts at 100 the third party entity. It diminishes the autonomy of a blockchain 101 system and limits its scalability. 103 This document describes an architecture for blockchain gateways that 104 perform the unidirectional transfer of virtual assets between two 105 autonomous blockchain systems which employ the gateways. 107 The purpose of this architecture document is to provide technical 108 framework within which to discuss the various aspects of a transfer 109 between two gateways, including security aspects and transfer 110 commitment aspects. 112 2. Terminology 114 There following are some terminology used in the current document: 116 o Blockchain Domain: The collection of resources and entities 117 participating within a blockchain system. 119 o Interior Resources: The various interior protocols, data 120 structures and cryptographic constructs that are a core part of a 121 blockchain system. Examples of interior resources include the 122 ledger (blocks of confirmed transaction data), public keys on the 123 ledger, consensus protocol, incentive mechanisms, transaction 124 propagation networks, etc. 126 o Exterior Resources: The various resources that are outside a 127 blockchain system, and are not part of the operations of a 128 blockchain. Examples include data located at third parties such 129 as asset registries, ledgers of other blockchains, PKI 130 infrastructures, etc. 132 o Blockchain nodes: The nodes of the blockchain system which form 133 the peer-to-peer network, which collectively maintain the shared 134 ledger in the blockchain by following a consensus algorithm. 136 o Gateway nodes: The nodes of the blockchain system that are 137 functionally capable of acting as a gateway in an asset transfer. 138 Gateway nodes implement the gateway-to-gateway asset transfer 139 protocol. Being a node on the blockchain system, a gateway has 140 read/write access to the interior resources (e.g. ledger) of the 141 blockchain. It participates in the consensus mechanism deployed 142 for the blockchain system. Depending on the blockchain system 143 implementation, some or all of the nodes may be gateway-capable. 145 o Blockchain address: This is the public-key of an entity as known 146 within a blockchain system, employed to transact on the blockchain 147 network and recorded on the ledger of the blockchain. Also 148 referred to as the transaction signing public-key pair. 150 o Entity public-key pair: This the private-public key pairs of an 151 entity used for interactions outside the blockchain system (e.g. 152 TL1.3). The term is used to distinguish this public-key from the 153 blockchain address. 155 o Asset transfer protocol: The gateway-to-gateway technical protocol 156 used by two gateway nodes to perform a unidirectional transfer of 157 a virtual asset. 159 o Asset profile: The prospectus of a regulated asset that includes 160 information and resources describing the virtual asset. This 161 includes the asset name/code, issuing authority, denomination, 162 jurisdiction, and the URLs and mechanisms to validate the 163 information. The asset profile is independent from the specific 164 instantiation of the asset (on a blockchain or otherwise) and 165 independent from its instance-ownership information. 167 o Virtual Asset: A virtual asset is a digital representation of 168 value that can be digitally traded, or transferred as defined by 169 the FATF [FATF]. 171 o Virtual Asset Service Provider (VASP): Legal entity handling 172 virtual assets as defined by the FATF [FATF]. 174 o Originator: Person or organization seeking the transfer of virtual 175 asset to a beneficiary 177 o Beneficiary: Person or organization receiving the transferred 178 virtual asset from an originator. 180 o Travel Rule information: Data regarding the VASPs, originators and 181 beneficiaries involved in an asset transfer, as defined by the 182 FATF [FATF] and as required by the jurisdiction of operations of 183 the VASPs. 185 o Gateway device identity: The identity of the device implementing 186 the gateway functions. The term is used in the sense of IDevID 187 (IEEE 802.1AR) or EK/AIK (in TPM1.2 and TPM2.0) [IDevID]. 189 o Gateway owner: The VASP who legally owns and operates a gateway 190 node within a blockchain system. 192 o Passive transaction: A transaction aimed at recording some state 193 metadata information on the ledger that does not affect assets 194 recorded on the ledger. A passive transaction can be self- 195 addressed (or has null as destination address) and can be used to 196 signal implicitly to other nodes regarding an state-change of the 197 metadata pertaining to an entity or an asset on the ledger. 199 Further terminology definitions can be found in [NIST] and [ISO]. 200 The term 'blockchain' and 'distributed ledger technology' (DLT) are 201 used interchangeably in this document. 203 3. Assumptions and Principles 205 The following assumptions and principles underlie the design of the 206 current interoperability architecture, and correspond to the design 207 principles of the Internet architecture. 209 3.1. Design Principles 211 o Opaque blockchain resources: The interior resources of each 212 blockchain system is assumed to be opaque to (hidden from) 213 external entities. Any resources to be made accessible to an 214 external entity must be made explicitly accessible by a gateway 215 node with proper authorization. 217 o Externalization of value: The gateway protocol is agnostic 218 (oblivious) to the economic or monetary value of the virtual asset 219 being transferred. 221 The opaque resources principle permits the interoperability 222 architecture to be applied in cases where one (or both) blockchain 223 systems are permissioned (private). It is the analog of the 224 autonomous systems principle in IP networking [Clar88], where 225 interior routes in local subnets are not visible to other external 226 autonomous systems. 228 The value-externalization principle permits asset transfer protocols 229 to be designed for efficiency, speed and reliability - independent of 230 the changes in the perceived economic value of the virtual asset. It 231 is the analog of the end-to-end principle in the Internet 232 architecture [SRC84], where contextual information (economic value) 233 is placed at the endpoints of the transaction. In the case of a 234 transfer of virtual assets, the originator and beneficiary at the 235 respective blockchain systems are assumed to have a common agreement 236 regarding the economic value of the asset. 238 3.2. Operational Assumptions 240 The following conditions are assumed to have occurred, leading to the 241 invocation of the asset transfer protocol between two gateway nodes: 243 o Application layer transfer request: The transfer request from an 244 originator in the origin blockchain is assumed to have occurred 245 prior to the execution of the asset transfer protocol. 247 o Identification of originator and beneficiary: The originator and 248 beneficiary are assumed to have been identified and that consent 249 has been obtained from both parties regarding the asset transfer. 251 o Identification of origin and destination blockchain: The origin 252 and destination blockchain systems is assumed to have been 253 identified. 255 o Selection of gateway nodes: The two gateway nodes at the origin 256 and destination blockchain systems respectively is assumed to have 257 been selected. 259 o Identification of gateway-node owners (VASP): The VASP operating 260 the gateway nodes are assumed to have been identified and their 261 legal status verified. 263 4. Architecture 265 4.1. Goal of Architecture 267 The goal of the interoperability architecture is to permit two (2) 268 gateway nodes belonging to distinct blockchain systems to conduct a 269 virtual asset transfer between them, in a secure and non-repudiable 270 manner while ensuring the asset does not exist simultaneously on both 271 blockchains (double-spend problem). 273 The virtual asset as understood by the two gateway nodes is a digital 274 representation of value, expressed in an standard digital format in a 275 way meaningful to the gateway nodes syntactically and semantically. 277 The syntactic representation of the virtual asset between the two 278 gateways need not bear any resemblance to the syntactic asset 279 representation within their respective blockchain systems. 281 The architecture recognizes that there different blockchain systems 282 currently in operation and evolving, and that in many cases the 283 interior technical constructs in these blockchains maybe incompatible 284 with one another. 286 The architecture therefore assumes that certain types of nodes 287 (gateway nodes) will be equipped with an asset transfer protocol and 288 other relevant resources that permits greater interoperability across 289 these incompatible blockchain systems. 291 The resources within a blockchain system (e.g. ledgers, public-keys, 292 consensus protocols, etc.) are assumed to be opaque to external 293 entities in order to permit a resilient and scalable protocol design 294 that is not dependent on the interior constructs of particular 295 blockchain systems. This ensures that the virtual asset transfer 296 protocol between gateways is not conditioned or dependent on these 297 local technical constructs. The role of a gateway therefore is also 298 to mask (hide) the complexity of the interior constructs of the 299 blockchain system that it represents. Overall this approach ensures 300 that a given blockchain system operates as a true autonomous system. 302 The current architecture focuses on unidirectional asset transfers, 303 although the building blocks in this architecture can be used to 304 support protocols for bidirectional transfers (conditional two 305 unidirectional transfers). 307 For simplicity the current architecture employs two (2) gateway nodes 308 in the respective blockchains, but collective multi-node transfers 309 (i.e. multiple nodes at each side) [HS2019] may be developed based on 310 the building blocks and constructs identified in the current 311 architecture. 313 4.2. Overview of Asset Transfer 315 An asset transfer between two blockchain systems is carried out by 316 two (2) gateway nodes in a direct interaction (unmediated), where the 317 gateway represents the two respective blockchain systems. 319 A successful transfer results in the asset being extinguished 320 (deleted) or marked on the origin ledger by the origin-gateway, and 321 for the asset to be introduced by the destination-gateway into the 322 destination ledger. 324 The mechanism to extinguish or introduce an asset from/into a ledger 325 is dependent on the specific blockchain system. The task of the 326 respective gateway is to implement the relevant mechanism to modify 327 the ledger of their corresponding blockchain system in such a way 328 that together the two blockchains maintain consistency from the asset 329 perspective, while observing the design principles of the 330 architecture. 332 An asset transfer protocol that can satisfy the properties of 333 atomicity and consistency in the case of two private blockchain 334 systems, should also do in the case when one or both are public 335 blockchain systems. 337 4.3. Desirable Properties of Asset Transfer 339 The desirable features of asset transfers between two gateway nodes 340 include, but not limited, to the following: 342 o Atomicity: Transfer must either commit or entirely fail (failure 343 means no change to asset ownership). 345 o Consistency: Transfer (commit or fail) always leaves both 346 blockchains in a consistent state (asset located in one blockchain 347 only). 349 o Isolation: While transfer occurring, asset ownership cannot be 350 modified (no double-spend). 352 o Durability: Once a transfer has been committed, must remain so 353 regardless of gateway crashes. 355 o Verifiable by authorized third parties: With proper authorization 356 to access relevant interior resources, third party entities must 357 be able at any time to perform audit-validation of the two 358 respective ledgers for asset transfers across the corresponding 359 blockchain systems. 361 o Containment of side-effects: Any effects due to errors or 362 security/integrity breaches in a blockchain system during an asset 363 transfer must be contained within that blockchain. 365 An implementation of the asset transfer protocol should satisfy these 366 properties, independent of whether the implementation employs 367 stateful messaging or stateless messaging between the two gateways. 369 4.4. Event log-data, crash recovery and backup gateways 371 Implementations of gateway nodes should maintain event logs and 372 checkpoints for the purpose of gateway crash recovery. The log-data 373 generated by a gateway should be considered as an interior resource 374 accessible to other authorized gateway nodes within the same 375 blockchain system 376 Mechanisms used to select or elect a gateway node in a blockchain 377 system for a given asset transfer could be extended to include the 378 selection of a backup gateway node. The primary gateway and the 379 backup gateway may or may not belong to the same owner (VASP). 381 Some blockchain systems may utilize the ledger itself as means to 382 retain the log-data, allowing other nodes in the blockchain to have 383 visibility and access to the gateway log-data. In these cases, the 384 gateway node may employ its transaction-signing key pair to issue a 385 passive transaction (e.g. self-addressed, no asset) on the ledger, 386 incorporating details of the transfer event. 388 Other blockchain systems may employ off-chain storage that is 389 accessible to all gateway nodes in the blockchain domain. In such 390 cases, to provide event-sequencing integrity the gateway may store a 391 hash of the log-data on the ledger of the blockchain (passive 392 transaction) prior to writing the log-data to the off-chain storage. 394 The mechanism used to provide gateway crash-recovery is dependent on 395 the blockchain system and the gateway implementation. For 396 interoperability purposes the information contained in the log and 397 the format of the log-data should be standardized, permitting vendors 398 of gateway products to reduce development costs over time. 400 The resumption of an interrupted transfer (e.g. due to gateway crash, 401 network failure, etc.) should take into consideration the aspects of 402 secure channel establishment and the aspects of the transfer protocol 403 resumption. In some cases, a new secure channel (e.g. TLS session) 404 must be established with the backup gateway node, within which the 405 asset transfer protocol could be continued from the last checkpoint 406 prior to the interruption. However, in other cases both the secure 407 channel and the transfer protocol must be started completely afresh 408 (no resumption). 410 The log-data collected by a gateway node acts also as a checkpoint 411 mechanism to assist the backup gateway node in continuing the 412 transfer. The point at which to re-start the transfer protocol flow 413 is dependent on the implementation of the gateway. Some owners 414 (VASPs) of gateway nodes may choose to start afresh the transfer of 415 the asset, and not to resume partially completed transfers. 417 4.5. Overview of the Phases in Asset Transfer 419 The interaction between two gateways in an asset transfer is 420 summarized in Figure 1, where the origin blockchain is B1 and the 421 destination blockchain is B2. The gateways are denoted as G1 and G2 422 respectively. 424 Originator 425 | 426 +-------------+ 427 | Client | 428 |(Application)| 429 +-------------+ 430 | 431 | Phases 432 V 433 +-------------+ |<-----(1)----->| +-------------+ 434 | Blockchain | +----+ +----+ | Blockchain | 435 | System B1 | |Gate| |Gate| | System B2 | 436 | |--|way |<-----(2)----->|way |--| | 437 | +---------+ | | G1 | | G2 | | +---------+ | 438 | |Ledger L1| | +----+ +----+ | |Ledger L2| | 439 | +---------+ | |<-----(3)----->| | +---------+ | 440 +-------------+ +-------------+ 442 Figure 1 444 The three phases are summarized as follows. 446 o Phase 1: Pre-transfer Verification of Asset and Identities. In 447 this phase the gateways G1 and G2 must mutually identify 448 themselves and authenticate that both possess gateway- 449 capabilities. Gateway G1 must communicate to G2 the asset-profile 450 of the asset to be transferred, and that consent have been 451 obtained from the beneficiary regarding accepting the transfer. 453 o Phase 2: Evidence of asset locking or escrow. In this phase, 454 gateway G1 must provide gateway G2 with sufficient evidence that 455 the asset on blockchain B1 is in a locked state (or escrowed) 456 under the control of G1 on ledger L1, and safe from double-spend 457 on the part of its current owner (the originator). 459 o Phase 3: Transfer commitment. In this phase gateways G1 and G2 460 commits to the transaction 462 These phases will be further discussed below. 464 5. Pre-transfer Verification of Asset and Identities (Phase 1) 466 The primary purpose of the first phase is to verify the various 467 information relating to the asset to be transferred, the identities 468 of the originator and beneficiary, the identity and legal status of 469 the entities (VASPs) who own and operate the gateways, and the 470 device-identities of the gateways. 472 This phase starts with the assumption that in blockchain B1 the 473 gateway to process the asset transfer to B2 has been selected (namely 474 gateway G1). It also assumes that the destination blockchain B2 has 475 been identified where the beneficiary address is located, and that 476 gateway G2 in blockchain B2 has been identified that will peer with 477 G1 to perform the transfer. 479 Orig L1 G1 G2 L2 Benef 480 | | | | | | 481 |---request------->| | | | 482 | | | | | | 483 ..|.....|............|....................|............|.....|.. 484 | | | Phase 1 | | | 485 | | | | | | 486 | | (1.1)|<-----VASP id------>| | | 487 | | | | | | 488 | | | | | | 489 | | (1.2)|<--Asset Profile--->| | | 490 | | | | | | 491 | | | | | | 492 | | (1.3)|<--Orig/Benef id--->| | | 493 | | | | | | 494 ..|.....|............|....................|............|.....|.. 495 | | | | | | 497 Figure 2 499 There are several steps that may occur in Phase 1 (see Figure 2): 501 o Secure channel establishment between G1 and G2: This includes the 502 mutual verification of the gateway device identities and the 503 exchange of the relevant parameters for secure channel 504 establishment. In cases where device attestation [RATS] is 505 required, the mutual attestation protocol must occur between G1 506 and G2 prior to proceeding to the next phase. 508 o Validation of the gateway ownership: There must be a means for 509 gateway G1 and G2 to verify their respective ownerships (i.e. 510 VASP1 owning G1 and VASP2 owning G2 respectively). Examples of 511 ownership verification mechanism include the chaining of the 512 gateway-device X.509 certificate up to the VASP entity 513 certificate, directories of gateways and VASPs, and others. 515 o Validation of VASP status: In some jurisdictions limitations may 516 be placed for regulated VASPs to transact only with other 517 similarly regulated VASPs. Examples of mechanisms used to 518 validate a VASP legal status include VASP directories, Extended 519 Validation (EV) X.509 certificates for VASPs, and others. 521 o Delivery and validation of asset profile: Gateway G1 must deliver 522 to G2 the asset-profile for the virtual asset to be transferred. 523 Gateway G2 must validate the authenticity of the statements 524 (claims) found in the asset profile. The policies governing 525 blockchain B2 with regards to permissible incoming assets must be 526 enforced by G2. 528 o Exchange of Travel Rule information: In jurisdictions where the 529 Travel Rule policies regarding originator and beneficiary 530 information is enforced, the gateways G1 and G2 must exchange this 531 information [FATF]. 533 o o Negotiation of asset transfer protocol parameters: Gateway G1 534 and G2 must agree on the parameters to be employed within the 535 asset transfer protocol. Examples include endpoints definitions 536 for resources, type of commitment flows (e.g. 2PC or 3PC), lock- 537 time durations, and others [ODAP]. 539 6. Evidence of asset locking or escrow (Phase 2) 541 The asset transfer protocol can commence when both gateways G1 and G2 542 have completed the verifications in Phase 1. 544 The steps of Phase 2 is shown in Figure 3, and broadly consists of 545 the following: 547 o Commencement (2.1): Gateway G1 indicates the start of the asset 548 transfer protocol by sending a transfer-commence message to 549 gateway G2. Among others, the message must include a 550 cryptographic hash of the information agreed-upon in Phase 1 (e.g. 551 asset profile, gateway identities, originator/beneficiary public 552 keys). 554 o Acknowledgement (2.2): The gateway G2 must send an explicit 555 acknowledgement of the commence message, which should include a 556 hash of commencement message and other relevant session 557 parameters. 559 o G1 lock/escrow asset (2.3): Gateway G1 proceeds to lock or escrow 560 the asset belonging to the originator on ledger L1. The lock may 561 take the form of passive transaction that signals to other nodes 562 that the asset is temporarily inaccessible. This signals to other 563 nodes in the blockchain system to ignore other transactions 564 pertaining to the asset until such time the lock by G1 is 565 finalized or released. 567 o G2 log incoming (2.4): Gateway G2 correspondingly writes a log 568 (passive transaction) on ledger L2 indicating an imminent arrival 569 of the asset to L2. This may act as a notification for the 570 beneficiary regarding the asset transfer. 572 o Lock Evidence (2.5): Gateway G1 sends a digitally signed evidence 573 regarding the lock (escrow) performed by G1 on the asset on ledger 574 L1. The signature by G1 is performed using its entity public-key 575 pair. 577 o Evidence receipt (2.6): If gateway G2 accepts the evidence, G2 578 then responds with a digitally signed receipt message which 579 includes a hash of the previous lock-evidence message. Otherwise, 580 if G2 declines the evidence then G2 can ignore the transfer and 581 let it time-out (i.e. transfer failed). 583 Orig L1 G1 G2 L2 Benef 584 | | | (Phase 1) | | | 585 | | | | | | 586 ..|.....|............|....................|............|.....|.. 587 | | | Phase 2 | | | 588 | | | | | | 589 | | (2.1)|-----Commence------>| | | 590 | | | | | | 591 | | |<-------ACK---------|(2.2) | | 592 | | | | | | 593 | | | | | | 594 | |<---Lock----|(2.3) | | | 595 | | | (2.4)|----Log---->| | 596 | | | | | | 597 | | | | | | 598 | | (2.5)|---Lock Evidence--->| | | 599 | | | | | | 600 | | |<-----Receipt-------|(2.6) | | 601 | | | | | | 602 ..|.....|............|....................|............|.....|.. 603 | | | | | | 605 Figure 3 607 The precise form of the evidence in step 2.5 is dependent on the 608 blockchain system in B1, and must be previously agreed upon between 609 G1 and G2 in Phase 1. 611 The purpose of this evidence is for dispute resolution between G1 and 612 G2 (i.e. entities who own and operate G1 and G2 respectively) in the 613 case that double-spend is later detected. 615 The gateway G2 must return a digitally signed receipt to G1 of this 616 evidence in order to cover G1 (exculpatory proof) in the case of 617 later denial by G2. 619 7. Transfer Commitment (Phase 3) 621 In Phase 3 the gateways G1 and G2 finalizes to the asset transfer by 622 performing a commitment protocol (e.g. 2PC or 3PC) as a process (sub- 623 protocol) embedded within the overall asset transfer protocol. 625 Upon receiving the evidence-receipt message in the previous phase, G1 626 begins the commitment (see Figure 4): 628 o Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for 629 the commitment of the transfer. This message must include a hash 630 of the previous messages (message 2.5 and 2.6). 632 o Ack-prepare (3.2): Gateway G2 acknowledges the commit-prepare 633 message. 635 o Lock-final (3.3): Gateway G1 issues a lock-finalization 636 transaction (passive) on ledger L1 that signals the permanent 637 extinguishment of the asset. This transaction must include a hash 638 reference to the lock transaction on L1 previously in step (2.3). 639 This indicates that the asset is no longer associated with the 640 public-key of its previous owner (originator) and that the asset 641 instance is no longer recognized on the ledger L1. 643 o Commit-final (3.4): Gateway G1 indicates to G2 that G1 has 644 performed a local lock-finalization on L1. This message must be 645 digitally signed by G1 and should include the block number and 646 transaction number (of the confirmed block) on ledger L1. 648 o Asset-create (3.5): Gateway issues a transaction on ledger L2 to 649 create the asset, associated with the public-key of the 650 beneficiary. This transaction must include a hash of the previous 651 message (3.4) and hash reference to the log-incoming transaction 652 on L2 previously in step (2.4). These hash references connects 653 the newly created asset with the overall transfer event 654 originating from gateway G1. 656 o Ack-final (3.6): Gateway G2 indicates to G1 that G2 has performed 657 an asset-creation transaction on L2. This message must be 658 digitally signed by G2 and should include the block number and 659 transaction number (of the confirmed block) on ledger L2. 661 o Location-record (3.7): Gateway G1 has the option to record the 662 block number and transaction number (as reported by G2 in the 663 previous step) to ledger L1, using a passive transaction. This 664 transaction should include a hash reference to the confirmed lock- 665 finalization transaction on L1 from step 3.3. This information 666 may aid in future search, audit and accountability purposes from a 667 legal perspective. 669 o Transfer complete (3.8): Gateway G1 must explicitly close the 670 asset transfer session with gateway G2. This allows both sides to 671 close down the secure channel established in Phase 1. 673 Orig L1 G1 G2 L2 Benef 674 | | | (Phase 2) | | | 675 | | | | | | 676 ..|.....|............|....................|............|.....|.. 677 | | | Phase 3 | | | 678 | | | | | | 679 | | (3.1)|--Commit Prepare--->| | | 680 | | | | | | 681 | | |<-----ACK-Prep------|(3.2) | | 682 | | | | | | 683 | | | | | | 684 | |<--Final----|(3.3) | | | 685 | | | | | | 686 | | (3.4)|----Commit Final--->| | | 687 | | | | | | 688 | | | (3.5)|---Create-->| | 689 | | | | | | 690 | | |<-----ACK-Final-----|(3.6) | | 691 | | | | | | 692 | | | | | | 693 | |<--Record---|(3.7) | | | 694 | | | | | | 695 | | (3.8)|---Complete/End---->| | | 696 | | | | | | 697 ..|.....|............|....................|............|.....|.. 698 | | | | | | 700 Figure 4 702 8. Related Open Issues 704 There are a number of open issues that are related to the asset 705 transfer protocol between gateway nodes. Some of the issues are due 706 to the fact that blockchain technology is relatively new, and that 707 technical constructs designed for interoperability have yet to be 708 addressed. Some of the issues are due to the nascency of the virtual 709 asset industry and lack of conventions, and therefore require 710 industry collaboration to determine these. 712 8.1. Global identification of blockchain systems and public-keys 714 There is currently no standard nomenclature to identify blockchain 715 systems in a globally unique manner. The analog to this is the AS- 716 numbers associated with IP routing autonomous systems. 718 Furthermore, an address (public-key) may not be unique to one 719 blockchain system. An entity (e.g. user) may in fact employ the same 720 public-key at multiple distinct blockchain systems simultaneously. 722 However, in order to perform an asset transfer from one blockchain 723 system to another, there needs to be mechanism that resolves the 724 beneficiary identifier (as known to the originator) to the correct 725 public-key and blockchain system as intended by the originator. 727 8.2. Selection of gateways nodes within a blockchain system 729 A given blockchain system must possess the capability to select or 730 designate gateway nodes that will perform an asset transfer across 731 blockchain systems. 733 A number of blockchain systems already employ consensus mechanisms 734 that elect a node to perform the transaction processing (e.g. proof 735 of stake in Ethereum). The same consensus mechanisms may be used to 736 elect the gateway node. 738 However, there are some blockchain systems that do not elect a single 739 node and which employ a race-to-process strategy (e.g. proof of work 740 in Bitcoin). Since the winner of the proof of work can be any node 741 in the blockchain system, this implies that all the nodes in these 742 types of blockchains must be gateway-capable. 744 8.3. Commitment protocols and forms of commitment evidence 746 Within Phase 2, the gateway nodes must implement one (or more) 747 transactional commitment protocols that permit the coordination 748 between two gateways, and the final commitment of the asset transfer. 750 The choice of the commitment protocol (type/version) and the 751 corresponding commitment evidence must be negotiated between the 752 gateways during Phase 1. 754 For example, in Phase 2 and Phase 3 discussed above the gateways G1 755 and G2 may implement the classic 2 Phase Commit (2PC) protocol 756 [Gray81] as a means to ensure efficient and non-disputable 757 commitments to the asset transfer. 759 Historically, transactional commitment protocols employ locking 760 mechanisms to prevent update conflicts on the data item in question. 761 When used within the context of virtual asset transfers across 762 blockchain systems, the fact that an asset has been locked by G1 (as 763 the 2PC coordinator) must be communicated to G2 (as the 2PC 764 participant) in an indisputable manner. 766 The exact form of this evidence of asset-locking must be standardized 767 (for the given transactional commitment protocol) to eliminate any 768 ambiguity. 770 9. Security Considerations 772 Although the current interoperability architecture for blockchain 773 gateways assumes the externalization of the value of assets, as a 774 blockchain system holds an increasing number of virtual assets it 775 becomes attractive to attackers seeking to obtain cryptographic keys 776 of its nodes and its end-users. 778 Gateway nodes are of particular interest to attackers because they 779 enable the transferal of virtual assets to external blockchain 780 systems, which may or may not be regulated. As such, hardening 781 technologies and tamper-resistant crypto-processors (e.g. TPM, SGX) 782 should be used for implementations of gateways [HS19]. 784 10. Policy Considerations 786 Virtual asset transfers must be policy-driven in the sense that it 787 must observe and enforce the policies defined for the blockchain 788 domain. Resources that make-up a blockchain systems are owned and 789 operated by entities (e.g. legal persons or organizations), and these 790 entities typically operate within regulatory jurisdictions [FATF]. 791 It is the responsibility of these entities to translate regulatory 792 policies into functions on blockchain systems that comply to the 793 relevant regulatory policies. 795 At the application layer, asset transfers must take into 796 consideration the legal status of assets and incorporate relevant 797 asset-related policies into their business logic. These policies 798 must permeate down to the nodes that implement the functions of asset 799 transaction processing. 801 The smart contract abstraction, based on replicated shared code/state 802 on the ledger [Herl19], must additionally incorporate the notion of 803 policy into the abstraction. 805 11. References 807 11.1. Normative References 809 [FATF] FATF, "International Standards on Combating Money 810 Laundering and the Financing of Terrorism and 811 Proliferation - FATF Revision of Recommendation 15", 812 October 2018, . 816 [ISO] ISO, "Blockchain and distributed ledger technologies- 817 Vocabulary (ISO:22739:2020)", July 2020, 818 . 820 [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST 821 Blockchain Technology Overview (NISTR-8202)", October 822 2018, . 824 [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset 825 Protocol, October 2020, IETF, draft-hargreaves-odap-00.", 826 October 2020, 827 . 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, 831 DOI 10.17487/RFC2119, March 1997, 832 . 834 11.2. Informative References 836 [ABCH20] Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and 837 T. Hardjono, "Proposal for a Comprehensive Crypto Asset 838 Taxonomy", May 2020, . 840 [BVGC20] Belchior, R., Vasconcelos, A., Guerreiro, S., and M. 841 Correia, "A Survey on Blockchain Interoperability: Past, 842 Present, and Future Trends", May 2020, 843 . 845 [Clar88] Clark, D., "The Design Philosophy of the DARPA Internet 846 Protocols, ACM Computer Communication Review, Proc SIGCOMM 847 88, vol. 18, no. 4, pp. 106-114", August 1988. 849 [Gray81] Gray, J., "The Transaction Concept: Virtues and 850 Limitations, in VLDB Proceedings of the 7th International 851 Conference, Cannes, France, September 1981, pp. 144-154", 852 September 1981. 854 [Herl19] Herlihy, M., "Blockchains From a Distributed Computing 855 Perspective, Communications of the ACM, vol. 62, no. 2, 856 pp. 78-85", February 2019, 857 . 859 [HLP19] Hardjono, T., Lipton, A., and A. Pentland, "Towards and 860 Interoperability Architecture for Blockchain Autonomous 861 Systems, IEEE Transactions on Engineering Management", 862 June 2019, . 864 [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted 865 Computing Base for Blockchain Infrastructure Security, 866 Frontiers Journal, Special Issue on Blockchain Technology, 867 Vol. 2, No. 24", December 2019, 868 . 870 [IDevID] Richardson, M. and J. Yang, "A Taxonomy of operational 871 security of manufacturer installed keys and anchors. IETF 872 draft-richardson-t2trg-idevid-considerations-01", August 873 2020, . 876 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 877 in System Design, ACM Transactions on Computer Systems, 878 vol. 2, no. 4, pp. 277-288", November 1984. 880 Authors' Addresses 882 Thomas Hardjono 883 MIT 885 Email: hardjono@mit.edu 887 Martin Hargreaves 888 Quant Network 890 Email: martin.hargreaves@quant.network 891 Ned Smith 892 Intel 894 Email: ned.smith@intel.com