Internet Engineering Task Force T. Hardjono Internet-Draft MIT Intended status: Informational M. Hargreaves Expires: May 11, 2022 Quant Network N. Smith Intel V. Ramakrishna IBM November 7, 2021 Interoperability Architecture for DLT Gateways draft-hardjono-blockchain-interop-arch-03 Abstract With the increasing interest in the potential use of blockchains and decentralized ledger technology (DLT) networksorks for virtual asset management, there is a need for these networks to have interoperability to support applications and services built atop these networks. An interoperability architecture for DLT networks is therefore needed in order to permit the secure flow of digital assets different DLT networks, satisfying the properties of transfer atomicity, consistency and durability. The architecture must recognize that there are different DLT networks and that the interior constructs in these networks maybe incompatible with one another. This document proposes an interoperability architecture based on DLT Gateways, which are points of interconnection between networks. Among others, the gateways implement one or more protocols for the transfer (or exchange) digital assets between DLT networks. A gateway belonging to a DLT network peers with another gateway belonging to a different DLT network to perform the asset transfer between the two networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Hardjono, et al. Expires May 11, 2022 [Page 1] Internet-Draft DLT Gateways November 2021 This Internet-Draft will expire on May 11, 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions and Principles . . . . . . . . . . . . . . . . . 6 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6 3.2. Operational Assumptions . . . . . . . . . . . . . . . . . 7 4. Interoperability Modes . . . . . . . . . . . . . . . . . . . 7 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Goal of Architecture . . . . . . . . . . . . . . . . . . 9 5.2. Overview of Asset Transfer . . . . . . . . . . . . . . . 10 5.3. Desirable Properties of Asset Transfer . . . . . . . . . 10 5.4. Event log-data, crash recovery and backup gateways . . . 11 5.5. Overview of the Phases in Asset Transfer . . . . . . . . 12 6. Pre-transfer Verification of Asset and Identities (Phase 1) . 13 7. Evidence of asset locking or escrow (Phase 2) . . . . . . . . 15 8. Transfer Commitment (Phase 3) . . . . . . . . . . . . . . . . 17 9. Related Open Issues . . . . . . . . . . . . . . . . . . . . . 19 9.1. Global identification of blockchain systems and public- keys . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Discovery of gateways in DLT Networks . . . . . . . . . . 20 9.3. Remote gateway discovery . . . . . . . . . . . . . . . . 20 9.4. Commitment protocols and forms of commitment evidence . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Policy Considerations . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Hardjono, et al. Expires May 11, 2022 [Page 2] Internet-Draft DLT Gateways November 2021 1. Introduction Currently there is little technical interoperability between decentralized ledger technology (DLT) networks. This results in the difficulty in transferring or exchanging virtual (digital) assets from one DLT network to another directly. The existing solutions involve a third party that mediates the transfer. This mediating third party is typically an asset-exchange entity (i.e. crypto-exchange) operating in a centralized hub-spoke fashion. This reliance on a third party results not only in delays in transfers, but also in the need for asset owner to have a business relationship (e.g. open accounts) at the mediating third party. Many of these solutions centralize control at the hands of the mediating party, thereby diminishing the autonomy of blockchains and DLT networks, and limits their scalability. This document proposes an interoperability architecture based on DLT Gateways, which are points of interconnection between networks. There are several services that may be offered by a DLT gateway, one of which being the direct transfer of a digital asset from one DLT network to another via pairs of gateways without a mediating third party. A given DLT network may have one or more gateways to perform a unidirectional direct transfer of digital assets to another DLT network possessing one or more compatible gateway. Similar to the notion of border gateways in interdomain routing (e.g. running the BGPv4 protocol), a DLT gateway belonging to an origin DLT network is said to peer with another gateway is a destination DLT network. Both gateways must implement an asset transfer protocol that must satisfy certain security, privacy and atomicity requirements. The purpose of this architecture document is to provide technical framework within which to define the required properties of a DLT gateway that supports an atomic asset transfer protocol, such as ODAP [ODAP]. These properties include the security, reliability and data privacy of digital asset transfers between pairs of gateways belonging to differing DLT networks. 2. Terminology There following are some terminology used in the current document. We borrow terminology from NIST and ISO as much as possible, introducing new terms only when needed: o Blockchain system: Blockchains are distributed digital ledgers of cryptographically signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after validation and undergoing a Hardjono, et al. Expires May 11, 2022 [Page 3] Internet-Draft DLT Gateways November 2021 consensus decision. As new blocks are added, older blocks become more difficult to modify (creating tamper resistance). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules [NIST]. o Distributed ledger technology (DLT) system: Technology that enables the operation and use of distributed ledgers, where the ledger is shared (replicated) across a set of DLT nodes and synchronized between the DLT nodes using a consensus mechanism [ISO]. o DLT Network: A generic term for blockchain systems. o Resource Domain: Resource Domain: The collection of resources and entities participating within a blockchain or DLT network. The domain denotes an boundary for permissible or authorized actions on resources. o Interior Resources: The various interior protocols, data structures and cryptographic constructs that are a core part of a blockchain or DLT network. Examples of interior resources include the ledger (blocks of confirmed transaction data), public keys on the ledger, consensus protocol, incentive mechanisms, transaction propagation networks, etc. o Exterior Resources: The various resources that are outside a blockchain or DLT network, and are not part of the operations of the network. Examples include data located at third parties such as asset registries, ledgers of other DLT network, PKI infrastructures, etc. o Nodes: The nodes of the blockchain or DLT system which form the peer-to-peer network, which collectively maintain the shared ledger in the system by following a consensus algorithm. o DLT Gateway: a DLT gateway is the collection of services, controlled by one legal entity, which connects to a minimum of one DLT network to provide read and write access to the ledger of that DLT network. A DLT gateway implements an atomic digital asset transfer protocol, such as ODAP [ODAP], via a DLT-neutral data formats and local storage logs. A gateway does not implement an interior consensus protocol. o DLT address: This is the public-key of an entity as known within a DLT network or blockchain system, employed to transact on the DLT network and recorded on the ledger of the DLT network. Also referred to as the transaction public key. Hardjono, et al. Expires May 11, 2022 [Page 4] Internet-Draft DLT Gateways November 2021 o Entity public-key pair: This the private-public key pairs of an entity used for interactions outside the DLT network (e.g. TLS 1.3). The term is used to distinguish this public-key from the blockchain address. o Asset transfer protocol: The gateway-to-gateway technical protocol used by two gateways to perform a unidirectional transfer of a virtual (digital_ asset. o Asset profile: The prospectus of a regulated asset that includes information and resources describing the virtual asset. This includes, among others, the asset name/code, issuing authority, denomination, jurisdiction, and the URLs and mechanisms to validate the information. The asset profile is independent from the specific instantiation of the asset (on a DLT network or otherwise) and independent from its instance-ownership information. o Virtual Asset: A virtual asset is a digital representation of value that can be digitally traded, or transferred as defined by the FATF [FATF]. We use the term interchangeably with ?digital asset?. o Virtual Asset Service Provider (VASP): Legal entity handling virtual assets as defined by the FATF [FATF]. o Originator: Person or organization seeking the transfer of virtual asset to a beneficiary o Beneficiary: Person or organization receiving the transferred virtual asset from an originator. o Travel Rule information: Data regarding the VASPs, originators and beneficiaries involved in an asset transfer, as defined by the FATF [FATF] and as required by the jurisdiction of operations of the VASPs. o Gateway device identity: The identity of the device implementing the gateway functions. The term is used in the sense of IDevID (IEEE 802.1AR) or EK/AIK (in TPM1.2 and TPM2.0) [IDevID]. o Gateway owner: The VASP who legally owns and operates a gateway within a DLT network. o Asset locking or escrow: The conditional mechanism used within a DLT network to make an asset temporarily unavailable for use by its owner. The condition of the asset release can be based on a duration of time (e.g. hash time locks) or other parameters. Hardjono, et al. Expires May 11, 2022 [Page 5] Internet-Draft DLT Gateways November 2021 o Gateway crash recovery: The local process by which a crashed gateway (i.e. device or system fault) is returned back into a consistent and operational state, ready to resume the asset transfer protocol with the peer gateway prior to the crash event. Further terminology definitions can be found in [NIST] and [ISO]. The term 'blockchain' and 'distributed ledger technology' (DLT) are used interchangeably in this document. 3. Assumptions and Principles The following assumptions and principles underlie the design of the current gateway architecture, and correspond to the design principles of the Internet architecture. 3.1. Design Principles o Opaque DLT resources: The interior resources of each DLT network is assumed to be opaque to (hidden from) external entities. Any resources to be made accessible to an external entity must be made explicitly accessible by a gateway with proper authorization. o Externalization of value: The gateway protocol is agnostic (oblivious) to the economic or monetary value of the virtual asset being transferred. The opaque resources principle permits the interoperability architecture to be applied in cases where one (or both) DLT networks are permissioned (private). It is the analog of the autonomous systems principle in IP networking [Clar88], where interior routes in local subnets are not visible to other external networks. The value-externalization principle permits asset transfer protocols to be designed for efficiency, security and reliability - independent of the changes in the perceived economic value of the virtual asset. It is the analog of the end-to-end principle in the Internet architecture [SRC84], where contextual information (economic value) is placed at the endpoints of the transaction. In the case of a transfer of virtual assets, the originator and beneficiary at the respective DLT networks are assumed to have a common agreement regarding the economic value of the asset. This context of the economic meaning of the value of the asset is assumed to exists at the end-points, namely at the originator and beneficiary. Hardjono, et al. Expires May 11, 2022 [Page 6] Internet-Draft DLT Gateways November 2021 3.2. Operational Assumptions The following conditions are assumed to have occurred, leading to the invocation of the asset transfer protocol between two gateways: o Application layer transfer request: The transfer request from an originator in the origin DLT network is assumed to have occurred prior to the execution of the asset transfer protocol. o Identification of originator and beneficiary: The originator and beneficiary are assumed to have been identified and that consent has been obtained from both parties regarding the asset transfer. o Identification of origin and destination DLT networks: The origin and destination DLT networks is assumed to have been identified. o Selection of gateway: The two gateway at the origin and destination DLT networks respectively is assumed to have been identified and selected. o Identification of gateway-owners (VASP): The VASP operating the gateway are assumed to have been identified and their status verified [FATF]. 4. Interoperability Modes Before delving into the architecture, it would be instructive to survey the different modes (or categories) of operations that necessitate interoperability between two blockchain/DLT network, virtual asset transfer being one such category. We can reason about this in terms of the interdependencies between business processes in two independent systems. In one category, a ledger state update in one system depends on an update in the other. In other words, a write operation must be performed on both ledgers to maintain integrity of the collective system; if either ledger lies in a blockchain system or DLT network, a new block is also added. From this, one can infer that both writes, or ledger state updates, must occur atomically (either both happen or neither does) across both systems despite their independence and lack of a central coordinator. The category of atomic writes can further be classified into asset transfers and asset exchanges. In the former, a virtual asset is expunged in one system while atomically being recreated in the other; the owner and recipient need only have accounts in their respective DLT networks. In the latter, two virtual assets are exchanged in two distinct networks atomically; they simply switch ownership without Hardjono, et al. Expires May 11, 2022 [Page 7] Internet-Draft DLT Gateways November 2021 their profile records leaving their respective systems' ledgers. In this scenario, both owners must have accounts in both networks. Moving back up the categorization hierarchy, we can identify a different category in which a ledger state update in one system depends on already recorded state in the ledger of another. In other words, a write operation must be performed in one ledger after reading state from another. The use case under this category can be termed data transfer or data sharing, where the advancement of a business workflow in one system depends on the advancement of a different workflow in another without requiring an atomic operation across the two systems. Here, it is useful to distinguish data from asset; the former can be copied in and across systems without losing its integrity whereas the latter must have an unambiguous ownership record at all times. Cross DLT-System Dependency | | +-----------------------------------+ | | | | +--------------------+ +--------------------+ | Bidirectional | | Unidirectional | | (Write <--> Write) | | (Read --> Write) | +--------------------+ +--------------------+ | | | | +------------------+ | | | | | | | +----------------+ +----------------+ +-----------------+ | Asset Transfer | | Asset Exchange | | Data Transfer | +----------------+ +----------------+ +-----------------+ Figure 1 Though the rest of this document focuses on a gateway architecture to facilitate virtual asset transfers, the same architecture can also be used for asset exchanges and data transfers. Interested readers can find out more about cross DLT-system asset exchanges by referring to literature on Hashed Time Lock Contracts [HTLC21], on cross network data transfers [Abebe19][Abebe21], and on ledger state views and addresses [DLVIEW]. Hardjono, et al. Expires May 11, 2022 [Page 8] Internet-Draft DLT Gateways November 2021 5. Architecture 5.1. Goal of Architecture The goal of the interoperability architecture is to permit two (2) Gateways belonging to distinct DLT networks to conduct a virtual asset transfer between them, in a secure and non-repudiable manner while ensuring the asset does not exist simultaneously on both networks (double-spend problem). The virtual asset as understood by the two gateway is a digital representation of value, expressed in an standard digital format in a way meaningful to the gateway syntactically and semantically. The syntactic representation of the virtual asset between the two gateways need not bear any resemblance to the syntactic asset representation within their respective DLT networks. The architecture recognizes that there are different DLT networks currently in operation and evolving, and that in many cases the interior technical constructs in these DLT networks maybe incompatible with one another. The architecture therefore assumes that certain types of computer systems (i.e. gateway) will be equipped with an asset transfer protocol and with other relevant resources that permits greater interoperability across these DLT networks. The resources within a DLT network (e.g. ledgers, public-keys, consensus protocols, etc.) are assumed to be opaque to external entities in order to permit a resilient and scalable protocol design that is not dependent on the interior constructs of particular blockchain system or DLT network. This ensures that the virtual asset transfer protocol between gateways is not conditioned or dependent on these local technical constructs. The role of a gateway therefore is also to mask (hide) the complexity of the interior constructs of the DLT network that it represents. Overall this approach ensures that a given DLT network operates as a true autonomous system. The current architecture focuses on unidirectional asset transfers, although the building blocks in this architecture can be used to support protocols for bidirectional transfers (conditional two unidirectional transfers), atomic asset exchanges and data transfers. For simplicity the current architecture employs two (2) gateways in the respective DLT networks, but collective multi-gateway transfers (i.e. multiple gateways at each side) [HS2019] may be developed based Hardjono, et al. Expires May 11, 2022 [Page 9] Internet-Draft DLT Gateways November 2021 on the building blocks and constructs identified in the current architecture. 5.2. Overview of Asset Transfer An asset transfer between two DLT networks is carried out by two (2) gateway in a direct interaction (unmediated), where the gateway represents the two respective DLT networks. A successful transfer results in the asset being extinguished (deleted) or marked on the origin ledger by the origin-gateway, and for the asset to be introduced by the destination-gateway into the destination ledger. The mechanism to extinguish or introduce an asset from/into a ledger is dependent on the specific blockchain or DLT network. The task of the respective gateway is to implement the relevant mechanism to modify the ledger of their corresponding DLT networks in such a way that together the two DLT networks maintain consistency from the asset perspective, while observing the design principles of the architecture. An asset transfer protocol that can satisfy the properties of atomicity and consistency in the case of two private DLT networks should also satisfy the same properties in the case when one or both are public. 5.3. Desirable Properties of Asset Transfer The desirable features of asset transfers between two gateway include, but not limited, to the following: o Atomicity: Transfer must either commit or entirely fail (failure means no change to asset ownership). o Consistency: Transfer (commit or fail) always leaves the ledgers of both DLT networks to be in a consistent state (asset located in the ledger of one DLT network only). o Isolation: While transfer occurring, asset ownership cannot be modified (no double-spend). o Durability: Once a transfer has been committed, must remain so regardless of gateway crashes. o Verifiable by authorized third parties: With proper authorization to access relevant interior resources, third party entities must be able at any time to perform audit-validation of the two Hardjono, et al. Expires May 11, 2022 [Page 10] Internet-Draft DLT Gateways November 2021 respective ledgers for asset transfers across the corresponding DLT networks. o Containment of side-effects: Any effects due to errors or security/integrity breaches in a DLT network during an asset transfer must be contained within that network. An implementation of the asset transfer protocol should satisfy these properties, independent of whether the implementation employs stateful messaging or stateless messaging between the two gateways. 5.4. Event log-data, crash recovery and backup gateways Implementations of gateway should maintain event logs and checkpoints for the purpose of gateway crash recovery. The log-data generated by a gateway should be considered as an interior resource accessible to other authorized gateways within the same DLT network. Mechanisms used to select or elect a gateway in a DLT network for a given asset transfer could be extended to include the selection of a backup gateways. The primary gateway and the backup gateway may or may not belong to the same owner (VASP). Some DLT networks may utilize the ledger itself as means to retain the log-data, allowing other nodes in the DLT network to have visibility and access to the gateway log-data. Other DLT networks may employ off-chain storage that is accessible to all gateway in the same authorization domain. In such cases, to provide event- sequencing integrity the gateway may store a hash of the log- data on the ledger of the DLT network prior to writing the log-data to the off-chain storage. The mechanism used to provide gateway crash-recovery is dependent on the DLT network and the gateway implementation. For interoperability purposes the information contained in the log and the format of the log-data should be standardized, permitting vendors of gateway products to reduce development costs over time. Similarly, in order to ensure a high degree of interoperability across crash-recovery protocol implementations [BCH21], a standardized interface (e.g. REST APIs) should be defined for read/ write access to the log- storage. The interface should hide the details of the log-storage from the gateway itself, and it should be independent of the gateway recovery strategy (e.g. self-healing, primary-backup, etc.). The resumption of an interrupted transfer (e.g. due to gateway crash, network failure, etc.) should take into consideration the aspects of secure channel establishment and the aspects of the transfer protocol resumption. In some cases, a new secure channel (e.g. TLS session) Hardjono, et al. Expires May 11, 2022 [Page 11] Internet-Draft DLT Gateways November 2021 must be established between the two gateways, within which the asset transfer protocol could be continued from the last checkpoint prior to the interruption. However, in other cases both the secure channel and the transfer protocol may need to be started completely afresh (no resumption). The log-data collected by a gateway acts also as a checkpoint mechanism to assist the recovered (or backup) gateway in continuing the transfer. The point at which to re-start the transfer protocol flow is dependent on the implementation of the gateway recovery strategy. Some owners (VASPs) of gateways may choose to start afresh the transfer of the asset, and not to resume partially completed transfers (e.g. for easier legal audit purposes). 5.5. Overview of the Phases in Asset Transfer The interaction between two gateways in an asset transfer is summarized in Figure 2, where the origin DLT network is DLN1 and the destination network is DLN2. The gateways are denoted as G1 and G2 respectively. Originator Beneficiary | | +-------------+ +-------------+ | Client | | Client | | Application | | Application | | (App1) | | (App2) | +-------------+ +-------------+ | | | (Phases) | V V +-------------+ |<-----(1)----->| +-------------+ | DLT Network | +----+ +----+ | DLT Network | | DLN1 | |Gate| |Gate| | DLN2 | | |--|way |<-----(2)----->|way |--| | | +---------+ | | G1 | | G2 | | +---------+ | | |Ledger L1| | +----+ +----+ | |Ledger L2| | | +---------+ | |<-----(3)----->| | +---------+ | +-------------+ +-------------+ Figure 2 The phases are summarized as follows. Hardjono, et al. Expires May 11, 2022 [Page 12] Internet-Draft DLT Gateways November 2021 o Phase 0: Initiation of transfer at the application layer. The two applications utilized by the originator and beneficiary is assumed to interact as part of the asset transfer. In this phase, the applications App1 and App2 may establish some context information (e.g. Session-ID) that will be made available to their respective gateways G1 and G2. The legal verification of the identities of the Originator and Beneficiary may occur in this phase [FATF]. This phase is outside the scope of the current architecture. o Phase 1: Pre-transfer Verification of Asset and Identities. In this phase the gateways G1 and G2 must mutually identify themselves and authenticate that both possess gateway- capabilities. Gateway G1 must communicate to G2 the asset-profile of the asset to be transferred, while G2 must validate that it has the ability to support this type of asset in the ledger of its DLT network. o Phase 2: Evidence of asset locking or escrow. In this phase, gateway G1 must provide gateway G2 with sufficient evidence that the asset on DLN1 is in a locked state (or escrowed) under the control of G1 on ledger L1, and safe from double-spend by its current owner (the originator). o Phase 3: Transfer commitment. In this phase gateways G1 and G2 commit to the unidirectional asset transfer. These phases will be further discussed below. 6. Pre-transfer Verification of Asset and Identities (Phase 1) The primary purpose of the first phase is to verify the various information relating to the asset to be transferred, the correct identities of the originator and beneficiary (as provided by the respective applications), the identity and legal status of the entities (VASPs) who own and operate the gateways, the type of the DLT network, and network parameters, and the device-identities of the gateways. Hardjono, et al. Expires May 11, 2022 [Page 13] Internet-Draft DLT Gateways November 2021 Orig L1 G1 G2 L2 Benef | | | | | | |---request------->| | | | | | | | | | ..|.....|............|....................|............|.....|.. | | | Phase 1 | | | | | | | | | | | (1.1)|<-----VASP id------>| | | | | | | | | | | | | | | | | (1.2)|<--Asset Profile--->| | | | | | | | | | | | | | | | | (1.3)|<--Orig/Benef id--->| | | | | | | | | ..|.....|............|....................|............|.....|.. | | | | | | Figure 3 This phase starts with the assumption that in DLN1 the gateway to process the asset transfer to DLN2 has been selected (namely gateway G1). It also assumes that the destination DLN2 has been identified where the beneficiary address is located, and that gateway G2 in DLN2 has been identified that will peer with G1 to perform the transfer. There are several steps that may occur in Phase 1: o Secure channel establishment between G1 and G2: This includes the mutual verification of the gateway device identities and the exchange of the relevant parameters for secure channel establishment. In cases where device attestation [RATS] is required, the mutual attestation protocol must occur between G1 and G2 prior to proceeding to the next phase. o Mutual device attestations: In cases where device attestation [RATS] is required, each gateway must yield attestation evidence to the other regarding its configuration. A gateway may take on the role as a attestation verifier, or it may rely on an external verifier to appraise the received evidence. o Validation of the gateway ownership: There must be a means for gateway G1 and G2 to verify their respective ownerships (i.e. VASP1 owning G1 and VASP2 owning G2 respectively). Examples of ownership verification mechanism include the chaining of the gateway-device X.509 certificate up to the VASP entity certificate, directories of gateways and VASPs, and others. Hardjono, et al. Expires May 11, 2022 [Page 14] Internet-Draft DLT Gateways November 2021 o Validation of VASP status: In some jurisdictions limitations may be placed for regulated VASPs to transact only with other similarly regulated VASPs. Examples of mechanisms used to validate a VASP legal status include VASP directories, Extended Validation (EV) X.509 certificates for VASPs, and others. o Identification and validation of asset profile: Both gateways must agree on the type of asset being transferred based on the profile of the asset. Gateway G1 must communicate the asset-profile identification to gateway G2, who in turn must validate both the legal status of the asset as well as the technical capability of DLN2 to digitally represent the asset type within its ledger L2. The policies governing DLT network DLN2 with regards to permissible incoming assets must be enforced by G2. o Exchange of Travel Rule information and validation: In jurisdictions where the Travel Rule policies regarding originator and beneficiary information is enforced [FATF], the owners of gateways G1 and G2 must comply to the Travel Rule. Mechanisms must be used to permit gateways G1 and G2 to make available originator/beneficiary information to one another in such away that the Travel Rule information can be logged as part of the asset transfer history. o Negotiation of asset transfer protocol parameters: Gateway G1 and G2 must agree on the parameters to be employed within the asset transfer protocol. Examples include endpoints definitions for resources, type of commitment flows (e.g. 2PC or 3PC), lock-time durations, and others [ODAP]. 7. Evidence of asset locking or escrow (Phase 2) The asset transfer protocol can commence when both gateways G1 and G2 have completed the verifications in Phase 1. The steps of Phase 2 are summarized in Figure 4, and broadly consists of the following: o Commencement (2.1): Gateway G1 indicates the start of the asset transfer protocol by sending a transfer-commence message to gateway G2. Among others, the message must include a cryptographic hash of the information agreed-upon in Phase 1 (e.g. asset profile, gateway identities, originator/beneficiary public keys, etc.). o Acknowledgement (2.2): The gateway G2 must send an explicit acknowledgement of the receipt of the commence message, which Hardjono, et al. Expires May 11, 2022 [Page 15] Internet-Draft DLT Gateways November 2021 should include a hash of commencement message (2.1) and other relevant session parameters. o G1 lock/escrow asset (2.3): Gateway G1 proceeds to lock or escrow the asset belonging to the originator on ledger L1. This prevents other transactions from changing the state of the asset in L1 until such time the lock by G1 is finalized or released. A time- lock or escrow may also be employed. The mode of the escrow may depend on the fundamental ledger architecture of the respective DLN1 and DLN2 in question (e.g. account-based, UTXO, or other). o G2 logs incoming asset (2.4): Gateway G2 correspondingly writes a non-committing log (passive transaction) on ledger L2 indicating an imminent arrival of the asset to L2. This may act as a notification for the beneficiary regarding the asset transfer. o Lock Evidence (2.5): Gateway G1 sends a digitally signed evidence regarding the lock (escrow) performed by G1 on the asset on ledger L1. The signature by G1 is performed using its entity public-key pair. This signifies that G1 (i.e. its owner VASP) is legally standing behind its assertion regarding the lock/escrow on the asset performed by G1. o Evidence receipt (2.6): If gateway G2 accepts the evidence, G2 then responds with a digitally signed receipt message which includes a hash of the previous lock-evidence message. Otherwise, if G2 declines the evidence then G2 can ignore the transfer and let it time-out (i.e. transfer failed). The signature by G2 is performed using its entity public-key pair. Hardjono, et al. Expires May 11, 2022 [Page 16] Internet-Draft DLT Gateways November 2021 Orig L1 G1 G2 L2 Benef | | | (Phase 1) | | | | | | | | | ..|.....|............|....................|............|.....|.. | | | Phase 2 | | | | | | | | | | | (2.1)|-----Commence------>| | | | | | | | | | | |<-------ACK---------|(2.2) | | | | | | | | | | | | | | | |<---Lock----|(2.3) | | | | | | (2.4)|----Log---->| | | | | | | | | | | | | | | | (2.5)|---Lock Evidence--->| | | | | | | | | | | |<-----Receipt-------|(2.6) | | | | | | | | ..|.....|............|....................|............|.....|.. | | | | | | Figure 4 The precise form of the evidence in step 2.5 is dependent on the type of ledger technology in DLN1, and must be previously agreed upon between G1 and G2 in Phase 1. The purpose of this evidence is for dispute resolution between G1 and G2 (i.e. the VASP entities who own and operate G1 and G2 respectively) in the case that double-spend is later detected. The gateway G2 must return a digitally signed receipt to G1 of this evidence in order to cover G1 (exculpatory proof) in the case of later denial by G2. 8. Transfer Commitment (Phase 3) In Phase 3 the gateways G1 and G2 finalizes to the asset transfer by performing a commitment protocol (e.g. 2PC or 3PC) as a process (sub- protocol) embedded within the overall asset transfer protocol. Upon receiving the evidence-receipt message in the previous phase, G1 begins the commitment (see Figure 5): Hardjono, et al. Expires May 11, 2022 [Page 17] Internet-Draft DLT Gateways November 2021 o Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for the commitment of the transfer. This message must include a hash of the previous messages (message 2.5 and 2.6). o Ack-prepare (3.2): Gateway G2 acknowledges the commit-prepare message. o Lock-final (3.3): Gateway G1 issues a lock-finalization transaction or escrow finalization on ledger L1 that signals the permanent extinguishment of the asset from DLN1. This transaction must include a hash reference to the lock transaction on L1 previously in step (2.3). This indicates that the asset is no longer associated with the public-key of its previous owner (originator) and that the asset instance is no longer recognized on the ledger L1. o Commit-final (3.4): Gateway G1 indicates to G2 that G1 has performed a local lock/escrow finalization on L1. This message must be digitally signed by G1 and should include the block number and transaction number (of the confirmed block) on ledger L1. o Asset-create (3.5): Gateway G2 issues a transaction on ledger L2 to create (re-generate) the asset, associated with the public-key of the beneficiary. This transaction must include a hash of the previous message (3.4) and hash reference to the log-incoming transaction on L2 previously in step (2.4). These hash references connects the newly re-generated asset with the overall transfer event originating from gateway G1. o Ack-final (3.6): Gateway G2 indicates to G1 that G2 has performed an asset-regeneration transaction on L2. This message must be digitally signed by G2 and should include the block number and transaction number (of the confirmed block) on ledger L2. o Location-record (3.7): Gateway G1 has the option to record the block number and transaction number (as reported by G2 in the previous step) to ledger L1. This transaction should include a hash reference to the confirmed lock-finalization transaction on L1 from step 3.3. This information may aid in future search, audit and accountability purposes from a legal perspective. o Transfer complete (3.8): Gateway G1 must explicitly close the asset transfer session with gateway G2. This allows both sides to close down the secure channel established in Phase 1. Hardjono, et al. Expires May 11, 2022 [Page 18] Internet-Draft DLT Gateways November 2021 Orig L1 G1 G2 L2 Benef | | | (Phase 2) | | | | | | | | | ..|.....|............|....................|............|.....|.. | | | Phase 3 | | | | | | | | | | | (3.1)|--Commit Prepare--->| | | | | | | | | | | |<-----ACK-Prep------|(3.2) | | | | | | | | | | | | | | | |<--Final----|(3.3) | | | | | | | | | | | (3.4)|----Commit Final--->| | | | | | | | | | | | (3.5)|---Create-->| | | | | | | | | | |<-----ACK-Final-----|(3.6) | | | | | | | | | | | | | | | |<--Record---|(3.7) | | | | | | | | | | | (3.8)|---Complete/End---->| | | | | | | | | ..|.....|............|....................|............|.....|.. | | | | | | Figure 5 9. Related Open Issues There are a number of open issues that are related to the asset transfer protocol between gateways. Some of the issues are due to the fact that blockchain technology is relatively new, and that technical constructs designed for interoperability have yet to be addressed. Some of the issues are due to the nascency of the virtual asset industry and lack of conventions, and therefore require industry collaboration to determine the standard conventions. 9.1. Global identification of blockchain systems and public-keys There is currently no standard nomenclature to identify a DLT network in a globally unique manner. The analog to this is the AS-numbers associated with IP routing autonomous systems. Hardjono, et al. Expires May 11, 2022 [Page 19] Internet-Draft DLT Gateways November 2021 Furthermore, an address (public-key) may not be unique to one DLT network. An entity (e.g. user) may in fact employ the same public- key simultaneously at multiple distinct DLT networks. Thus, there is no convention today with regards to the application of a key within a given DLT network (comparable to the principal/ domain convention in Internet host naming). However, in order to perform an asset transfer from one DLT network to another, there needs to be mechanism that resolves the beneficiary identifier (as known to the originator) to the correct public-key and DLT network as intended by the originator. 9.2. Discovery of gateways in DLT Networks A given DLT network must possess the capability to select or designate gateway that will perform an asset transfer. A number of DLT networks already employ consensus mechanisms that elect a gateway to perform the transaction processing (e.g. proof of stake in Ethereum). The same consensus mechanisms may be used to elect the gateway (e.g. out of a pool of available gateways in the DLT network). 9.3. Remote gateway discovery Related to the ability to discover other DLT networks globally is the ability to discover the remote gateways for these other DLT networks. A discovery mechanism for external entities (e.g. for gateway G1) to look for gateways (e.g. remote gateway G2) is required in order for gateways to quickly and efficiently peer without human intervention. The discovery mechanism may employ the available information at gateway G1, such as the originator/beneficiary public keys, the VASPs (owners of the gateways) and other parameters. Other approaches may also be employed, such as incorporating the gateway identities within a VASP's configuration file (e.g. at a well-known location), and within a global directory of regulated VASPs. Approaches similar to the DNS infrastructure may provide an alternative architecture for solving this problem. 9.4. Commitment protocols and forms of commitment evidence Within Phase 2, the gateways must implement one (or more) transactional commitment protocols that permit the coordination between two gateways, and the final commitment of the asset transfer. Hardjono, et al. Expires May 11, 2022 [Page 20] Internet-Draft DLT Gateways November 2021 The choice of the commitment protocol (type/version) and the corresponding commitment evidence must be negotiated between the gateways during Phase 1. For example, in Phase 2 and Phase 3 discussed above the gateways G1 and G2 may implement the classic 2 Phase Commit (2PC) protocol [Gray81] as a means to ensure efficient and non-disputable commitments to the asset transfer. Historically, transactional commitment protocols employ locking mechanisms to prevent update conflicts on the data item in question. When used within the context of virtual asset transfers across DLT networks, the fact that an asset has been locked by G1 (as the 2PC coordinator) must be communicated to G2 (as the 2PC participant) in an indisputable manner. The exact form of this evidence of asset-locking must be standardized (for the given transactional commitment protocol) to eliminate any ambiguity. 10. Security Considerations As a DLT network hold an increasing number of virtual assets, it may become attractive to attackers seeking to compromise the cryptographic keys of the entities, services and its end-users. Gateways are of particular interest to attackers because they enable the transferal of virtual assets to external DLT networks, which may or may not be regulated. As such, hardening technologies and tamper- resistant crypto-processors (e.g. TPM, SGX) should be used for implementations of gateways [HS19]. 11. Policy Considerations Virtual asset transfers must be policy-driven in the sense that it must observe and enforce the policies defined for the DLT network. Resources that make-up a DLT network are owned and operated by entities (e.g. legal persons or organizations), and these entities typically operate within regulatory jurisdictions [FATF]. It is the responsibility of these entities to translate regulatory policies into functions on DLT networks that comply to the relevant regulatory policies. At the application layer, asset transfers must take into consideration the legal status of assets and incorporate relevant asset-related policies into their business logic. These policies must permeate down to the gateways that implement the functions of asset transaction processing. Hardjono, et al. Expires May 11, 2022 [Page 21] Internet-Draft DLT Gateways November 2021 The smart contract abstraction, based on replicated shared code/state on the ledger [Herl19], must additionally incorporate the notion of policy into the abstraction. 12. References 12.1. Normative References [BCH21] Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway Crash Recovery Mechanism, IETF, draft-belchior-gateway- recovery-01.", March 2021, . [DLVIEW] Ramakrishna, V., Pandit, V., Nishad, S., Narayanam, K., and D. Vinayagamurthy , "Views and View Addresses for Blockchain/DLT Interoperability, IETF Draft", November 2021. [FATF] FATF, "International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation - FATF Revision of Recommendation 15 (Updated June 2021)", October 2018, . [ISO] ISO, "Blockchain and distributed ledger technologies- Vocabulary (ISO:22739:2020)", July 2020, . [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST Blockchain Technology Overview (NISTR-8202)", October 2018, . [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset Protocol, IETF, draft-hargreaves-odap-01.", November 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 12.2. Informative References [ABCH20] Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and T. Hardjono, "Proposal for a Comprehensive Crypto Asset Taxonomy", May 2020, . Hardjono, et al. Expires May 11, 2022 [Page 22] Internet-Draft DLT Gateways November 2021 [Abebe19] Abebe, E., Behl, D., Govindarajan, C., Hu, Y., Karunamoorthy, D., Novotny, P., Pandit, V., Ramakrishna, V., and C. Vecchiola, "Enabling Enterprise Blockchain Interoperability with Trusted Data Transfer (Middleware 2019, Industry Track)", December 2019, . [Abebe21] Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit, V., Ramakrishna, V., and J. Yu, "Verifiable Observation of Permissioned Ledgers (ICBC2021)", May 2021, . [BVGC20] Belchior, R., Vasconcelos, A., Guerreiro, S., and M. Correia, "A Survey on Blockchain Interoperability: Past, Present, and Future Trends", May 2020, . [Clar88] Clark, D., "The Design Philosophy of the DARPA Internet Protocols, ACM Computer Communication Review, Proc SIGCOMM 88, vol. 18, no. 4, pp. 106-114", August 1988. [Gray81] Gray, J., "The Transaction Concept: Virtues and Limitations, in VLDB Proceedings of the 7th International Conference, Cannes, France, September 1981, pp. 144-154", September 1981. [Herl19] Herlihy, M., "Blockchains From a Distributed Computing Perspective, Communications of the ACM, vol. 62, no. 2, pp. 78-85", February 2019, . [HLP19] Hardjono, T., Lipton, A., and A. Pentland, "Towards and Interoperability Architecture for Blockchain Autonomous Systems, IEEE Transactions on Engineering Management", June 2019, . [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted Computing Base for Blockchain Infrastructure Security, Frontiers Journal, Special Issue on Blockchain Technology, Vol. 2, No. 24", December 2019, . [IDevID] Richardson, M. and J. Yang, "A Taxonomy of operational security of manufacturer installed keys and anchors. IETF draft-richardson-t2trg-idevid-considerations-01", August 2020, . Hardjono, et al. Expires May 11, 2022 [Page 23] Internet-Draft DLT Gateways November 2021 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design, ACM Transactions on Computer Systems, vol. 2, no. 4, pp. 277-288", November 1984. Authors' Addresses Thomas Hardjono MIT Email: hardjono@mit.edu Martin Hargreaves Quant Network Email: martin.hargreaves@quant.network Ned Smith Intel Email: ned.smith@intel.com Venkatraman Ramakrishna IBM Email: vramakr2@in.ibm.com Hardjono, et al. Expires May 11, 2022 [Page 24]