Internet Engineering Task Force                              T. Hardjono
Internet-Draft                                                       MIT
Intended status: Informational                             M. Hargreaves
Expires: May 11, 2022                                      Quant Network
                                                                N. Smith
                                                          V. Ramakrishna
                                                        November 7, 2021

             Interoperability Architecture for DLT Gateways


   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

   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
   ( 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

   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

   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

   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

   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

   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

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

   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

            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

   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

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

   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

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

   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

   [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, <http://www.fatf-

   [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, <https://doi:10.1109/TEM.2019.2920154>.

   [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


   Martin Hargreaves
   Quant Network


   Ned Smith


   Venkatraman Ramakrishna


Hardjono, et al.          Expires May 11, 2022                 [Page 24]