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