< draft-hardjono-blockchain-interop-arch-01.txt   draft-hardjono-blockchain-interop-arch-02.txt >
Internet Engineering Task Force T. Hardjono Internet Engineering Task Force T. Hardjono
Internet-Draft MIT Internet-Draft MIT
Intended status: Informational M. Hargreaves Intended status: Informational M. Hargreaves
Expires: April 30, 2021 Quant Network Expires: October 23, 2021 Quant Network
N. Smith N. Smith
Intel Intel
October 27, 2020 April 21, 2021
An Interoperability Architecture for Blockchain Gateways An Interoperability Architecture for Blockchain/DLT Gateways
draft-hardjono-blockchain-interop-arch-01 draft-hardjono-blockchain-interop-arch-02
Abstract Abstract
With the increasing interest in the potential use of blockchain With the increasing interest in the potential use of blockchain
systems for virtual assets, there is a need for these assets to have systems for virtual assets, there is a need for these assets to have
mobility across blockchain systems. An interoperability architecture mobility across blockchain systems. An interoperability architecture
for blockchain systems is needed in order to permit the secure flow for blockchain systems is needed in order to permit the secure flow
of virtual assets between blockchain systems, satisfying the of virtual assets between blockchain systems, satisfying the
properties of transfer atomicity, consistency and durability. The properties of transfer atomicity, consistency and durability. The
architecture must recognize that there are different blockchain architecture must recognize that there are different blockchain
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2021. This Internet-Draft will expire on October 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Assumptions and Principles . . . . . . . . . . . . . . . . . 5 3. Assumptions and Principles . . . . . . . . . . . . . . . . . 6
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6
3.2. Operational Assumptions . . . . . . . . . . . . . . . . . 6 3.2. Operational Assumptions . . . . . . . . . . . . . . . . . 7
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Goal of Architecture . . . . . . . . . . . . . . . . . . 6 4.1. Goal of Architecture . . . . . . . . . . . . . . . . . . 7
4.2. Overview of Asset Transfer . . . . . . . . . . . . . . . 7 4.2. Overview of Asset Transfer . . . . . . . . . . . . . . . 8
4.3. Desirable Properties of Asset Transfer . . . . . . . . . 8 4.3. Desirable Properties of Asset Transfer . . . . . . . . . 9
4.4. Event log-data, crash recovery and backup gateways . . . 8 4.4. Event log-data, crash recovery and backup gateways . . . 9
4.5. Overview of the Phases in Asset Transfer . . . . . . . . 9 4.5. Overview of the Phases in Asset Transfer . . . . . . . . 10
5. Pre-transfer Verification of Asset and Identities (Phase 1) . 10 5. Pre-transfer Verification of Asset and Identities (Phase 1) . 11
6. Evidence of asset locking or escrow (Phase 2) . . . . . . . . 12 6. Evidence of asset locking or escrow (Phase 2) . . . . . . . . 13
7. Transfer Commitment (Phase 3) . . . . . . . . . . . . . . . . 14 7. Transfer Commitment (Phase 3) . . . . . . . . . . . . . . . . 15
8. Related Open Issues . . . . . . . . . . . . . . . . . . . . . 16 8. Related Open Issues . . . . . . . . . . . . . . . . . . . . . 17
8.1. Global identification of blockchain systems and public- 8.1. Global identification of blockchain systems and public-
keys . . . . . . . . . . . . . . . . . . . . . . . . . . 16 keys . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Selection of gateways nodes within a blockchain system . 16 8.2. Discovery of gateways nodes within a blockchain system . 18
8.3. Commitment protocols and forms of commitment evidence . . 16 8.3. Remote gateway discovery . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.4. Commitment protocols and forms of commitment evidence . . 19
10. Policy Considerations . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Policy Considerations . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Currently there is little technical interoperability between Currently there is little technical interoperability between
blockchain systems. This results in the difficulty in transferring blockchain systems. This results in the difficulty in transferring
or migrating virtual assets associated with a public-key (address) in or migrating virtual assets associated with a public-key (address)
one blockchain system to another blockchain system. from one blockchain or DLT system to another directly.
The existing solutions involve a third party that mediates the The existing solutions involve a third party that mediates the
transfer. This mediating third party is typically an asset-exchange transfer. This mediating third party is typically an asset-exchange
entity (i.e. crypto-exchange) operating in a centralized hub-spoke entity (i.e. crypto-exchange) operating in a centralized hub-spoke
fashion. This reliance on a third party results not only delays in fashion. This reliance on a third party results not only delays in
transfers, but also in the need for key-holders to open accounts at transfers, but also in the need for asset owner to have a business
the third party entity. It diminishes the autonomy of a blockchain relationship (e.g. open accounts) at the mediating third party. Many
system and limits its scalability. of these solutions centralize control at the hands of the mediating
party, thereby diminishing the autonomy of blockchains and DLT
systems, and limits their scalability.
This document describes an architecture for blockchain gateways that This This document describes an architecture for gateways for
perform the unidirectional transfer of virtual assets between two blockchains and DLT systems that permit a direct transfer of assets
autonomous blockchain systems which employ the gateways. without a mediating third party. A given blockchain or DLT system
may have one or more gateway nodes to perform a unidirectional direct
transfer of virtual assets to blockchain or DLT system possessing one
or more compatible gateway nodes. Similar to the notion of border
gateways in interdomain routing (e.g. running the BGPv4 protocol), a
blockchain gateway belonging to an origin blockchain or DLT system is
said to peer with another gateway is a destination blockchain or DLT
system. 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 The purpose of this architecture document is to provide technical
framework within which to discuss the various aspects of a transfer framework within which to discuss the various aspects of a transfer
between two gateways, including security aspects and transfer between two gateways, including security aspects and transfer
commitment aspects. atomicity aspects.
2. Terminology 2. Terminology
There following are some terminology used in the current document: There following are some terminology used in the current document:
o Blockchain Domain: The collection of resources and entities o Blockchain system: Blockchains are distributed digital ledgers of
participating within a blockchain system. 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
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 Resource Domain: Resource Domain: The collection of resources and
entities participating within a blockchain or DLT system. The
domain denotes an boundary for permissible or authorized actions
on resources.
o Interior Resources: The various interior protocols, data o Interior Resources: The various interior protocols, data
structures and cryptographic constructs that are a core part of a structures and cryptographic constructs that are a core part of a
blockchain system. Examples of interior resources include the blockchain or DLT system. Examples of interior resources include
ledger (blocks of confirmed transaction data), public keys on the the ledger (blocks of confirmed transaction data), public keys on
ledger, consensus protocol, incentive mechanisms, transaction the ledger, consensus protocol, incentive mechanisms, transaction
propagation networks, etc. propagation networks, etc.
o Exterior Resources: The various resources that are outside a o Exterior Resources: The various resources that are outside a
blockchain system, and are not part of the operations of a blockchain or DLT system, and are not part of the operations of
blockchain. Examples include data located at third parties such the system. Examples include data located at third parties such
as asset registries, ledgers of other blockchains, PKI as asset registries, ledgers of other blockchain/DLT systems, PKI
infrastructures, etc. infrastructures, etc.
o Blockchain nodes: The nodes of the blockchain system which form o Nodes: The nodes of the blockchain or DLT system which form the
the peer-to-peer network, which collectively maintain the shared peer-to-peer network, which collectively maintain the shared
ledger in the blockchain by following a consensus algorithm. ledger in the system by following a consensus algorithm.
o Gateway nodes: The nodes of the blockchain system that are o Gateway nodes: The nodes of the blockchain or DLT system that are
functionally capable of acting as a gateway in an asset transfer. functionally capable of acting as a gateway in an asset transfer.
Gateway nodes implement the gateway-to-gateway asset transfer A gateway node implements the gateway-to-gateway asset transfer
protocol. Being a node on the blockchain system, a gateway has protocol. Being a node on the blockchain/DLT system, a gateway
read/write access to the interior resources (e.g. ledger) of the has read/write access to the interior resources (e.g. ledger) of
blockchain. It participates in the consensus mechanism deployed the blockchain. It participates in the consensus mechanism
for the blockchain system. Depending on the blockchain system deployed for the system. Depending on the blockchain/DLT system
implementation, some or all of the nodes may be gateway-capable. implementation, some or all of the nodes may be gateway-capable.
o Blockchain address: This is the public-key of an entity as known o Blockchain address: This is the public-key of an entity as known
within a blockchain system, employed to transact on the blockchain within a blockchain system, employed to transact on the blockchain
network and recorded on the ledger of the blockchain. Also network and recorded on the ledger of the blockchain. Also
referred to as the transaction signing public-key pair. referred to as the transaction public key.
o Entity public-key pair: This the private-public key pairs of an o Entity public-key pair: This the private-public key pairs of an
entity used for interactions outside the blockchain system (e.g. entity used for interactions outside the blockchain or DLT system
TL1.3). The term is used to distinguish this public-key from the (e.g. TL1.3). The term is used to distinguish this public-key
blockchain address. from the blockchain address.
o Asset transfer protocol: The gateway-to-gateway technical protocol o Asset transfer protocol: The gateway-to-gateway technical protocol
used by two gateway nodes to perform a unidirectional transfer of used by two gateway nodes to perform a unidirectional transfer of
a virtual asset. a virtual asset.
o Asset profile: The prospectus of a regulated asset that includes o Asset profile: The prospectus of a regulated asset that includes
information and resources describing the virtual asset. This information and resources describing the virtual asset. This
includes the asset name/code, issuing authority, denomination, includes, among others, the asset name/code, issuing authority,
jurisdiction, and the URLs and mechanisms to validate the denomination, jurisdiction, and the URLs and mechanisms to
information. The asset profile is independent from the specific validate the information. The asset profile is independent from
instantiation of the asset (on a blockchain or otherwise) and the specific instantiation of the asset (on a blockchain or
independent from its instance-ownership information. otherwise) and independent from its instance-ownership
information.
o Virtual Asset: A virtual asset is a digital representation of o Virtual Asset: A virtual asset is a digital representation of
value that can be digitally traded, or transferred as defined by value that can be digitally traded, or transferred as defined by
the FATF [FATF]. the FATF [FATF].
o Virtual Asset Service Provider (VASP): Legal entity handling o Virtual Asset Service Provider (VASP): Legal entity handling
virtual assets as defined by the FATF [FATF]. virtual assets as defined by the FATF [FATF].
o Originator: Person or organization seeking the transfer of virtual o Originator: Person or organization seeking the transfer of virtual
asset to a beneficiary asset to a beneficiary
skipping to change at page 5, line 19 skipping to change at page 5, line 50
o Gateway owner: The VASP who legally owns and operates a gateway o Gateway owner: The VASP who legally owns and operates a gateway
node within a blockchain system. node within a blockchain system.
o Passive transaction: A transaction aimed at recording some state o Passive transaction: A transaction aimed at recording some state
metadata information on the ledger that does not affect assets metadata information on the ledger that does not affect assets
recorded on the ledger. A passive transaction can be self- recorded on the ledger. A passive transaction can be self-
addressed (or has null as destination address) and can be used to addressed (or has null as destination address) and can be used to
signal implicitly to other nodes regarding an state-change of the signal implicitly to other nodes regarding an state-change of the
metadata pertaining to an entity or an asset on the ledger. metadata pertaining to an entity or an asset on the ledger.
o Asset locking or escrow: The conditional mechanism used within a
blockchain or DLT system 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.
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]. Further terminology definitions can be found in [NIST] and [ISO].
The term 'blockchain' and 'distributed ledger technology' (DLT) are The term 'blockchain' and 'distributed ledger technology' (DLT) are
used interchangeably in this document. used interchangeably in this document.
3. Assumptions and Principles 3. Assumptions and Principles
The following assumptions and principles underlie the design of the The following assumptions and principles underlie the design of the
current interoperability architecture, and correspond to the design current interoperability architecture, and correspond to the design
principles of the Internet architecture. principles of the Internet architecture.
skipping to change at page 6, line 7 skipping to change at page 6, line 49
autonomous systems. autonomous systems.
The value-externalization principle permits asset transfer protocols The value-externalization principle permits asset transfer protocols
to be designed for efficiency, speed and reliability - independent of to be designed for efficiency, speed and reliability - independent of
the changes in the perceived economic value of the virtual asset. It the changes in the perceived economic value of the virtual asset. It
is the analog of the end-to-end principle in the Internet is the analog of the end-to-end principle in the Internet
architecture [SRC84], where contextual information (economic value) architecture [SRC84], where contextual information (economic value)
is placed at the endpoints of the transaction. In the case of a is placed at the endpoints of the transaction. In the case of a
transfer of virtual assets, the originator and beneficiary at the transfer of virtual assets, the originator and beneficiary at the
respective blockchain systems are assumed to have a common agreement respective blockchain systems are assumed to have a common agreement
regarding the economic value of the asset. 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.
3.2. Operational Assumptions 3.2. Operational Assumptions
The following conditions are assumed to have occurred, leading to the The following conditions are assumed to have occurred, leading to the
invocation of the asset transfer protocol between two gateway nodes: invocation of the asset transfer protocol between two gateway nodes:
o Application layer transfer request: The transfer request from an o Application layer transfer request: The transfer request from an
originator in the origin blockchain is assumed to have occurred originator in the origin blockchain is assumed to have occurred
prior to the execution of the asset transfer protocol. prior to the execution of the asset transfer protocol.
o Identification of originator and beneficiary: The originator and o Identification of originator and beneficiary: The originator and
beneficiary are assumed to have been identified and that consent beneficiary are assumed to have been identified and that consent
has been obtained from both parties regarding the asset transfer. has been obtained from both parties regarding the asset transfer.
o Identification of origin and destination blockchain: The origin o Identification of origin and destination blockchain: The origin
and destination blockchain systems is assumed to have been and destination blockchain systems is assumed to have been
identified. identified.
o Selection of gateway nodes: The two gateway nodes at the origin o Selection of gateway nodes: The two gateway nodes at the origin
and destination blockchain systems respectively is assumed to have and destination blockchain systems respectively is assumed to have
been selected. been identified and selected.
o Identification of gateway-node owners (VASP): The VASP operating o Identification of gateway-node owners (VASP): The VASP operating
the gateway nodes are assumed to have been identified and their the gateway nodes are assumed to have been identified and their
legal status verified. legal status verified [FATF].
4. Architecture 4. Architecture
4.1. Goal of Architecture 4.1. Goal of Architecture
The goal of the interoperability architecture is to permit two (2) The goal of the interoperability architecture is to permit two (2)
gateway nodes belonging to distinct blockchain systems to conduct a gateway nodes belonging to distinct blockchain systems to conduct a
virtual asset transfer between them, in a secure and non-repudiable virtual asset transfer between them, in a secure and non-repudiable
manner while ensuring the asset does not exist simultaneously on both manner while ensuring the asset does not exist simultaneously on both
blockchains (double-spend problem). blockchains (double-spend problem).
The virtual asset as understood by the two gateway nodes is a digital The virtual asset as understood by the two gateway nodes is a digital
representation of value, expressed in an standard digital format in a representation of value, expressed in an standard digital format in a
way meaningful to the gateway nodes syntactically and semantically. way meaningful to the gateway nodes syntactically and semantically.
The syntactic representation of the virtual asset between the two The syntactic representation of the virtual asset between the two
gateways need not bear any resemblance to the syntactic asset gateways need not bear any resemblance to the syntactic asset
representation within their respective blockchain systems. representation within their respective blockchain systems.
The architecture recognizes that there different blockchain systems The architecture recognizes that there are different blockchain
currently in operation and evolving, and that in many cases the systems currently in operation and evolving, and that in many cases
interior technical constructs in these blockchains maybe incompatible the interior technical constructs in these blockchains maybe
with one another. incompatible with one another.
The architecture therefore assumes that certain types of nodes The architecture therefore assumes that certain types of nodes
(gateway nodes) will be equipped with an asset transfer protocol and (gateway nodes) will be equipped with an asset transfer protocol and
other relevant resources that permits greater interoperability across with other relevant resources that permits greater interoperability
these incompatible blockchain systems. across these incompatible blockchain systems.
The resources within a blockchain system (e.g. ledgers, public-keys, The resources within a blockchain system (e.g. ledgers, public-keys,
consensus protocols, etc.) are assumed to be opaque to external consensus protocols, etc.) are assumed to be opaque to external
entities in order to permit a resilient and scalable protocol design entities in order to permit a resilient and scalable protocol design
that is not dependent on the interior constructs of particular that is not dependent on the interior constructs of particular
blockchain systems. This ensures that the virtual asset transfer blockchain systems. This ensures that the virtual asset transfer
protocol between gateways is not conditioned or dependent on these protocol between gateways is not conditioned or dependent on these
local technical constructs. The role of a gateway therefore is also local technical constructs. The role of a gateway therefore is also
to mask (hide) the complexity of the interior constructs of the to mask (hide) the complexity of the interior constructs of the
blockchain system that it represents. Overall this approach ensures blockchain system that it represents. Overall this approach ensures
skipping to change at page 8, line 9 skipping to change at page 9, line 4
The mechanism to extinguish or introduce an asset from/into a ledger The mechanism to extinguish or introduce an asset from/into a ledger
is dependent on the specific blockchain system. The task of the is dependent on the specific blockchain system. The task of the
respective gateway is to implement the relevant mechanism to modify respective gateway is to implement the relevant mechanism to modify
the ledger of their corresponding blockchain system in such a way the ledger of their corresponding blockchain system in such a way
that together the two blockchains maintain consistency from the asset that together the two blockchains maintain consistency from the asset
perspective, while observing the design principles of the perspective, while observing the design principles of the
architecture. architecture.
An asset transfer protocol that can satisfy the properties of An asset transfer protocol that can satisfy the properties of
atomicity and consistency in the case of two private blockchain atomicity and consistency in the case of two private blockchain
systems, should also do in the case when one or both are public systems, should also satisfy the same properties in the case when one
blockchain systems. or both are public blockchain systems.
4.3. Desirable Properties of Asset Transfer 4.3. Desirable Properties of Asset Transfer
The desirable features of asset transfers between two gateway nodes The desirable features of asset transfers between two gateway nodes
include, but not limited, to the following: include, but not limited, to the following:
o Atomicity: Transfer must either commit or entirely fail (failure o Atomicity: Transfer must either commit or entirely fail (failure
means no change to asset ownership). means no change to asset ownership).
o Consistency: Transfer (commit or fail) always leaves both o Consistency: Transfer (commit or fail) always leaves both
blockchains in a consistent state (asset located in one blockchain blockchains in a consistent state (asset located in the ledger of
only). one blockchain only).
o Isolation: While transfer occurring, asset ownership cannot be o Isolation: While transfer occurring, asset ownership cannot be
modified (no double-spend). modified (no double-spend).
o Durability: Once a transfer has been committed, must remain so o Durability: Once a transfer has been committed, must remain so
regardless of gateway crashes. regardless of gateway crashes.
o Verifiable by authorized third parties: With proper authorization o Verifiable by authorized third parties: With proper authorization
to access relevant interior resources, third party entities must to access relevant interior resources, third party entities must
be able at any time to perform audit-validation of the two be able at any time to perform audit-validation of the two
skipping to change at page 9, line 4 skipping to change at page 9, line 46
properties, independent of whether the implementation employs properties, independent of whether the implementation employs
stateful messaging or stateless messaging between the two gateways. stateful messaging or stateless messaging between the two gateways.
4.4. Event log-data, crash recovery and backup gateways 4.4. Event log-data, crash recovery and backup gateways
Implementations of gateway nodes should maintain event logs and Implementations of gateway nodes should maintain event logs and
checkpoints for the purpose of gateway crash recovery. The log-data checkpoints for the purpose of gateway crash recovery. The log-data
generated by a gateway should be considered as an interior resource generated by a gateway should be considered as an interior resource
accessible to other authorized gateway nodes within the same accessible to other authorized gateway nodes within the same
blockchain system blockchain system
Mechanisms used to select or elect a gateway node in a blockchain Mechanisms used to select or elect a gateway node in a blockchain
system for a given asset transfer could be extended to include the system for a given asset transfer could be extended to include the
selection of a backup gateway node. The primary gateway and the selection of a backup gateway node. The primary gateway and the
backup gateway may or may not belong to the same owner (VASP). backup gateway may or may not belong to the same owner (VASP).
Some blockchain systems may utilize the ledger itself as means to Some blockchain systems may utilize the ledger itself as means to
retain the log-data, allowing other nodes in the blockchain to have retain the log-data, allowing other nodes in the blockchain to have
visibility and access to the gateway log-data. In these cases, the visibility and access to the gateway log-data. Other blockchain
gateway node may employ its transaction-signing key pair to issue a systems may employ off-chain storage that is accessible to all
passive transaction (e.g. self-addressed, no asset) on the ledger, gateway nodes in the blockchain domain. In such cases, to provide
incorporating details of the transfer event. event-sequencing integrity the gateway may store a hash of the log-
data on the ledger of the blockchain (passive transaction) prior to
Other blockchain systems may employ off-chain storage that is writing the log-data to the off-chain storage.
accessible to all gateway nodes in the blockchain domain. In such
cases, to provide event-sequencing integrity the gateway may store a
hash of the log-data on the ledger of the blockchain (passive
transaction) prior to writing the log-data to the off-chain storage.
The mechanism used to provide gateway crash-recovery is dependent on The mechanism used to provide gateway crash-recovery is dependent on
the blockchain system and the gateway implementation. For the blockchain system and the gateway implementation. For
interoperability purposes the information contained in the log and interoperability purposes the information contained in the log and
the format of the log-data should be standardized, permitting vendors the format of the log-data should be standardized, permitting vendors
of gateway products to reduce development costs over time. 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 node recovery strategy (e.g. self-healing,
primary-backup node, etc.).
The resumption of an interrupted transfer (e.g. due to gateway crash, The resumption of an interrupted transfer (e.g. due to gateway crash,
network failure, etc.) should take into consideration the aspects of network failure, etc.) should take into consideration the aspects of
secure channel establishment and the aspects of the transfer protocol secure channel establishment and the aspects of the transfer protocol
resumption. In some cases, a new secure channel (e.g. TLS session) resumption. In some cases, a new secure channel (e.g. TLS session)
must be established with the backup gateway node, within which the must be established netween the two gateways nodes, within which the
asset transfer protocol could be continued from the last checkpoint asset transfer protocol could be continued from the last checkpoint
prior to the interruption. However, in other cases both the secure prior to the interruption. However, in other cases both the secure
channel and the transfer protocol must be started completely afresh channel and the transfer protocol may need to be started completely
(no resumption). afresh (no resumption).
The log-data collected by a gateway node acts also as a checkpoint The log-data collected by a gateway node acts also as a checkpoint
mechanism to assist the backup gateway node in continuing the mechanism to assist the recovered (or backup) gateway node in
transfer. The point at which to re-start the transfer protocol flow continuing the transfer. The point at which to re-start the transfer
is dependent on the implementation of the gateway. Some owners protocol flow is dependent on the implementation of the gateway
(VASPs) of gateway nodes may choose to start afresh the transfer of recovery strategy. Some owners (VASPs) of gateway nodes may choose
the asset, and not to resume partially completed transfers. to start afresh the transfer of the asset, and not to resume
partially completed transfers (e.g. for easier legal audit purposes).
4.5. Overview of the Phases in Asset Transfer 4.5. Overview of the Phases in Asset Transfer
The interaction between two gateways in an asset transfer is The interaction between two gateways in an asset transfer is
summarized in Figure 1, where the origin blockchain is B1 and the summarized in Figure 1, where the origin blockchain is B1 and the
destination blockchain is B2. The gateways are denoted as G1 and G2 destination blockchain is B2. The gateways are denoted as G1 and G2
respectively. respectively.
Originator Originator
| |
skipping to change at page 10, line 38 skipping to change at page 11, line 38
this phase the gateways G1 and G2 must mutually identify this phase the gateways G1 and G2 must mutually identify
themselves and authenticate that both possess gateway- themselves and authenticate that both possess gateway-
capabilities. Gateway G1 must communicate to G2 the asset-profile capabilities. Gateway G1 must communicate to G2 the asset-profile
of the asset to be transferred, and that consent have been of the asset to be transferred, and that consent have been
obtained from the beneficiary regarding accepting the transfer. obtained from the beneficiary regarding accepting the transfer.
o Phase 2: Evidence of asset locking or escrow. In this phase, o Phase 2: Evidence of asset locking or escrow. In this phase,
gateway G1 must provide gateway G2 with sufficient evidence that gateway G1 must provide gateway G2 with sufficient evidence that
the asset on blockchain B1 is in a locked state (or escrowed) the asset on blockchain B1 is in a locked state (or escrowed)
under the control of G1 on ledger L1, and safe from double-spend under the control of G1 on ledger L1, and safe from double-spend
on the part of its current owner (the originator). by its current owner (the originator).
o Phase 3: Transfer commitment. In this phase gateways G1 and G2 o Phase 3: Transfer commitment. In this phase gateways G1 and G2
commits to the transaction commit to the unidirectional asset transfer.
These phases will be further discussed below. These phases will be further discussed below.
5. Pre-transfer Verification of Asset and Identities (Phase 1) 5. Pre-transfer Verification of Asset and Identities (Phase 1)
The primary purpose of the first phase is to verify the various The primary purpose of the first phase is to verify the various
information relating to the asset to be transferred, the identities information relating to the asset to be transferred, the identities
of the originator and beneficiary, the identity and legal status of of the originator and beneficiary, the identity and legal status of
the entities (VASPs) who own and operate the gateways, and the the entities (VASPs) who own and operate the gateways, the blockchain
device-identities of the gateways. or DLT system type and network parameters, and the device-identities
of the gateways.
This phase starts with the assumption that in blockchain B1 the
gateway to process the asset transfer to B2 has been selected (namely
gateway G1). It also assumes that the destination blockchain B2 has
been identified where the beneficiary address is located, and that
gateway G2 in blockchain B2 has been identified that will peer with
G1 to perform the transfer.
Orig L1 G1 G2 L2 Benef Orig L1 G1 G2 L2 Benef
| | | | | | | | | | | |
|---request------->| | | | |---request------->| | | |
| | | | | | | | | | | |
..|.....|............|....................|............|.....|.. ..|.....|............|....................|............|.....|..
| | | Phase 1 | | | | | | Phase 1 | | |
| | | | | | | | | | | |
| | (1.1)|<-----VASP id------>| | | | | (1.1)|<-----VASP id------>| | |
| | | | | | | | | | | |
skipping to change at page 11, line 32 skipping to change at page 12, line 27
| | (1.2)|<--Asset Profile--->| | | | | (1.2)|<--Asset Profile--->| | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | (1.3)|<--Orig/Benef id--->| | | | | (1.3)|<--Orig/Benef id--->| | |
| | | | | | | | | | | |
..|.....|............|....................|............|.....|.. ..|.....|............|....................|............|.....|..
| | | | | | | | | | | |
Figure 2 Figure 2
This phase starts with the assumption that in blockchain B1 the
gateway to process the asset transfer to B2 has been selected (namely
gateway G1). It also assumes that the destination blockchain B2 has
been identified where the beneficiary address is located, and that
gateway G2 in blockchain B2 has been identified that will peer with
G1 to perform the transfer.
There are several steps that may occur in Phase 1 (see Figure 2): There are several steps that may occur in Phase 1 (see Figure 2):
o Secure channel establishment between G1 and G2: This includes the o Secure channel establishment between G1 and G2: This includes the
mutual verification of the gateway device identities and the mutual verification of the gateway device identities and the
exchange of the relevant parameters for secure channel exchange of the relevant parameters for secure channel
establishment. In cases where device attestation [RATS] is establishment. In cases where device attestation [RATS] is
required, the mutual attestation protocol must occur between G1 required, the mutual attestation protocol must occur between G1
and G2 prior to proceeding to the next phase. 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 o Validation of the gateway ownership: There must be a means for
gateway G1 and G2 to verify their respective ownerships (i.e. gateway G1 and G2 to verify their respective ownerships (i.e.
VASP1 owning G1 and VASP2 owning G2 respectively). Examples of VASP1 owning G1 and VASP2 owning G2 respectively). Examples of
ownership verification mechanism include the chaining of the ownership verification mechanism include the chaining of the
gateway-device X.509 certificate up to the VASP entity gateway-device X.509 certificate up to the VASP entity
certificate, directories of gateways and VASPs, and others. certificate, directories of gateways and VASPs, and others.
o Validation of VASP status: In some jurisdictions limitations may o Validation of VASP status: In some jurisdictions limitations may
be placed for regulated VASPs to transact only with other be placed for regulated VASPs to transact only with other
similarly regulated VASPs. Examples of mechanisms used to similarly regulated VASPs. Examples of mechanisms used to
validate a VASP legal status include VASP directories, Extended validate a VASP legal status include VASP directories, Extended
Validation (EV) X.509 certificates for VASPs, and others. Validation (EV) X.509 certificates for VASPs, and others.
o Delivery and validation of asset profile: Gateway G1 must deliver o Identification and validation of asset profile: Both gateways must
to G2 the asset-profile for the virtual asset to be transferred. agree on the type of asset being transferred based on the profile
Gateway G2 must validate the authenticity of the statements of the asset. Gateway G1 must communicate the asset-profile
(claims) found in the asset profile. The policies governing identification to gateway G2, who in turn must validate both the
blockchain B2 with regards to permissible incoming assets must be legal status of the asset as well as the technical capability of
enforced by G2. the blockchain B2 to digitally represent the asset type within its
ledger L2. The policies governing blockchain B2 with regards to
permissible incoming assets must be enforced by G2.
o Exchange of Travel Rule information: In jurisdictions where the o Exchange of Travel Rule information and validation: In
Travel Rule policies regarding originator and beneficiary jurisdictions where the Travel Rule policies regarding originator
information is enforced, the gateways G1 and G2 must exchange this and beneficiary information is enforced [FATF], the owners of
information [FATF]. 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 o Negotiation of asset transfer protocol parameters: Gateway G1 o Negotiation of asset transfer protocol parameters: Gateway G1 and
and G2 must agree on the parameters to be employed within the G2 must agree on the parameters to be employed within the asset
asset transfer protocol. Examples include endpoints definitions transfer protocol. Examples include endpoints definitions for
for resources, type of commitment flows (e.g. 2PC or 3PC), lock- resources, type of commitment flows (e.g. 2PC or 3PC), lock-time
time durations, and others [ODAP]. durations, and others [ODAP].
6. Evidence of asset locking or escrow (Phase 2) 6. Evidence of asset locking or escrow (Phase 2)
The asset transfer protocol can commence when both gateways G1 and G2 The asset transfer protocol can commence when both gateways G1 and G2
have completed the verifications in Phase 1. have completed the verifications in Phase 1.
The steps of Phase 2 is shown in Figure 3, and broadly consists of The steps of Phase 2 are summarized in Figure 3, and broadly consists
the following: of the following:
o Commencement (2.1): Gateway G1 indicates the start of the asset o Commencement (2.1): Gateway G1 indicates the start of the asset
transfer protocol by sending a transfer-commence message to transfer protocol by sending a transfer-commence message to
gateway G2. Among others, the message must include a gateway G2. Among others, the message must include a
cryptographic hash of the information agreed-upon in Phase 1 (e.g. cryptographic hash of the information agreed-upon in Phase 1 (e.g.
asset profile, gateway identities, originator/beneficiary public asset profile, gateway identities, originator/beneficiary public
keys). keys, etc.).
o Acknowledgement (2.2): The gateway G2 must send an explicit o Acknowledgement (2.2): The gateway G2 must send an explicit
acknowledgement of the commence message, which should include a acknowledgement of the receipt of the commence message, which
hash of commencement message and other relevant session should include a hash of commencement message (2.1) and other
parameters. relevant session parameters.
o G1 lock/escrow asset (2.3): Gateway G1 proceeds to lock or escrow o G1 lock/escrow asset (2.3): Gateway G1 proceeds to lock or escrow
the asset belonging to the originator on ledger L1. The lock may the asset belonging to the originator on ledger L1. The lock may
take the form of passive transaction that signals to other nodes take the form of passive transaction that signals to other nodes
that the asset is temporarily inaccessible. This signals to other that the asset is temporarily inaccessible. This signals to other
nodes in the blockchain system to ignore other transactions nodes in the blockchain system to ignore other transactions
pertaining to the asset until such time the lock by G1 is pertaining to the asset until such time the lock by G1 is
finalized or released. 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 blockchains B1 and B2 in
question (e.g. account-based, UTXO, or other).
o G2 log incoming (2.4): Gateway G2 correspondingly writes a log o G2 log incoming asset (2.4): Gateway G2 correspondingly writes a
(passive transaction) on ledger L2 indicating an imminent arrival non-committing log (passive transaction) on ledger L2 indicating
of the asset to L2. This may act as a notification for the an imminent arrival of the asset to L2. This may act as a
beneficiary regarding the asset transfer. notification for the beneficiary regarding the asset transfer.
o Lock Evidence (2.5): Gateway G1 sends a digitally signed evidence o Lock Evidence (2.5): Gateway G1 sends a digitally signed evidence
regarding the lock (escrow) performed by G1 on the asset on ledger regarding the lock (escrow) performed by G1 on the asset on ledger
L1. The signature by G1 is performed using its entity public-key L1. The signature by G1 is performed using its entity public-key
pair. pair. This signifies that G1 (i.e. its owner VASP) is standing
behind the assertion regarding the lock/escrow on the asset
performed by G1.
o Evidence receipt (2.6): If gateway G2 accepts the evidence, G2 o Evidence receipt (2.6): If gateway G2 accepts the evidence, G2
then responds with a digitally signed receipt message which then responds with a digitally signed receipt message which
includes a hash of the previous lock-evidence message. Otherwise, includes a hash of the previous lock-evidence message. Otherwise,
if G2 declines the evidence then G2 can ignore the transfer and if G2 declines the evidence then G2 can ignore the transfer and
let it time-out (i.e. transfer failed). let it time-out (i.e. transfer failed). The signature by G2 is
performed using its entity public-key pair.
Orig L1 G1 G2 L2 Benef Orig L1 G1 G2 L2 Benef
| | | (Phase 1) | | | | | | (Phase 1) | | |
| | | | | | | | | | | |
..|.....|............|....................|............|.....|.. ..|.....|............|....................|............|.....|..
| | | Phase 2 | | | | | | Phase 2 | | |
| | | | | | | | | | | |
| | (2.1)|-----Commence------>| | | | | (2.1)|-----Commence------>| | |
| | | | | | | | | | | |
| | |<-------ACK---------|(2.2) | | | | |<-------ACK---------|(2.2) | |
skipping to change at page 14, line 6 skipping to change at page 15, line 34
..|.....|............|....................|............|.....|.. ..|.....|............|....................|............|.....|..
| | | | | | | | | | | |
Figure 3 Figure 3
The precise form of the evidence in step 2.5 is dependent on the The precise form of the evidence in step 2.5 is dependent on the
blockchain system in B1, and must be previously agreed upon between blockchain system in B1, and must be previously agreed upon between
G1 and G2 in Phase 1. G1 and G2 in Phase 1.
The purpose of this evidence is for dispute resolution between G1 and The purpose of this evidence is for dispute resolution between G1 and
G2 (i.e. entities who own and operate G1 and G2 respectively) in the G2 (i.e. the VASP entities who own and operate G1 and G2
case that double-spend is later detected. respectively) in the case that double-spend is later detected.
The gateway G2 must return a digitally signed receipt to G1 of this 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 evidence in order to cover G1 (exculpatory proof) in the case of
later denial by G2. later denial by G2.
7. Transfer Commitment (Phase 3) 7. Transfer Commitment (Phase 3)
In Phase 3 the gateways G1 and G2 finalizes to the asset transfer by 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- performing a commitment protocol (e.g. 2PC or 3PC) as a process (sub-
protocol) embedded within the overall asset transfer protocol. protocol) embedded within the overall asset transfer protocol.
skipping to change at page 14, line 30 skipping to change at page 16, line 13
begins the commitment (see Figure 4): begins the commitment (see Figure 4):
o Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for o Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for
the commitment of the transfer. This message must include a hash the commitment of the transfer. This message must include a hash
of the previous messages (message 2.5 and 2.6). of the previous messages (message 2.5 and 2.6).
o Ack-prepare (3.2): Gateway G2 acknowledges the commit-prepare o Ack-prepare (3.2): Gateway G2 acknowledges the commit-prepare
message. message.
o Lock-final (3.3): Gateway G1 issues a lock-finalization o Lock-final (3.3): Gateway G1 issues a lock-finalization
transaction (passive) on ledger L1 that signals the permanent transaction (passive transaction) or escrow finalization on ledger
extinguishment of the asset. This transaction must include a hash L1 that signals the permanent extinguishment of the asset
reference to the lock transaction on L1 previously in step (2.3). blockchain B1. This transaction must include a hash reference to
This indicates that the asset is no longer associated with the the lock transaction on L1 previously in step (2.3). This
public-key of its previous owner (originator) and that the asset indicates that the asset is no longer associated with the public-
instance is no longer recognized on the ledger L1. 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 o Commit-final (3.4): Gateway G1 indicates to G2 that G1 has
performed a local lock-finalization on L1. This message must be performed a local lock/escrow finalization on L1. This message
digitally signed by G1 and should include the block number and must be digitally signed by G1 and should include the block number
transaction number (of the confirmed block) on ledger L1. and transaction number (of the confirmed block) on ledger L1.
o Asset-create (3.5): Gateway issues a transaction on ledger L2 to o Asset-create (3.5): Gateway G2 issues a transaction on ledger L2
create the asset, associated with the public-key of the to create (re-generate) the asset, associated with the public-key
beneficiary. This transaction must include a hash of the previous of the beneficiary. This transaction must include a hash of the
message (3.4) and hash reference to the log-incoming transaction previous message (3.4) and hash reference to the log-incoming
on L2 previously in step (2.4). These hash references connects transaction on L2 previously in step (2.4). These hash references
the newly created asset with the overall transfer event connects the newly re-generated asset with the overall transfer
originating from gateway G1. event originating from gateway G1.
o Ack-final (3.6): Gateway G2 indicates to G1 that G2 has performed o Ack-final (3.6): Gateway G2 indicates to G1 that G2 has performed
an asset-creation transaction on L2. This message must be an asset-regeneration transaction on L2. This message must be
digitally signed by G2 and should include the block number and digitally signed by G2 and should include the block number and
transaction number (of the confirmed block) on ledger L2. transaction number (of the confirmed block) on ledger L2.
o Location-record (3.7): Gateway G1 has the option to record the o Location-record (3.7): Gateway G1 has the option to record the
block number and transaction number (as reported by G2 in the block number and transaction number (as reported by G2 in the
previous step) to ledger L1, using a passive transaction. This previous step) to ledger L1, using a passive transaction. This
transaction should include a hash reference to the confirmed lock- transaction should include a hash reference to the confirmed lock-
finalization transaction on L1 from step 3.3. This information finalization transaction on L1 from step 3.3. This information
may aid in future search, audit and accountability purposes from a may aid in future search, audit and accountability purposes from a
legal perspective. legal perspective.
skipping to change at page 16, line 13 skipping to change at page 17, line 42
Figure 4 Figure 4
8. Related Open Issues 8. Related Open Issues
There are a number of open issues that are related to the asset There are a number of open issues that are related to the asset
transfer protocol between gateway nodes. Some of the issues are due transfer protocol between gateway nodes. Some of the issues are due
to the fact that blockchain technology is relatively new, and that to the fact that blockchain technology is relatively new, and that
technical constructs designed for interoperability have yet to be technical constructs designed for interoperability have yet to be
addressed. Some of the issues are due to the nascency of the virtual addressed. Some of the issues are due to the nascency of the virtual
asset industry and lack of conventions, and therefore require asset industry and lack of conventions, and therefore require
industry collaboration to determine these. industry collaboration to determine the standard conventions.
8.1. Global identification of blockchain systems and public-keys 8.1. Global identification of blockchain systems and public-keys
There is currently no standard nomenclature to identify blockchain There is currently no standard nomenclature to identify blockchain
systems in a globally unique manner. The analog to this is the AS- systems in a globally unique manner. The analog to this is the AS-
numbers associated with IP routing autonomous systems. numbers associated with IP routing autonomous systems.
Furthermore, an address (public-key) may not be unique to one Furthermore, an address (public-key) may not be unique to one
blockchain system. An entity (e.g. user) may in fact employ the same blockchain system. An entity (e.g. user) may in fact employ the same
public-key at multiple distinct blockchain systems simultaneously. public-key at multiple distinct blockchain systems simultaneously.
Thus, there is no convention today with regards to the application of
a key within a given blockchain system (comparable to the principal/
domain convention in Internet host naming).
However, in order to perform an asset transfer from one blockchain However, in order to perform an asset transfer from one blockchain
system to another, there needs to be mechanism that resolves the system to another, there needs to be mechanism that resolves the
beneficiary identifier (as known to the originator) to the correct beneficiary identifier (as known to the originator) to the correct
public-key and blockchain system as intended by the originator. public-key and blockchain system as intended by the originator.
8.2. Selection of gateways nodes within a blockchain system 8.2. Discovery of gateways nodes within a blockchain system
A given blockchain system must possess the capability to select or A given blockchain system must possess the capability to select or
designate gateway nodes that will perform an asset transfer across designate gateway nodes that will perform an asset transfer across
blockchain systems. blockchain systems.
A number of blockchain systems already employ consensus mechanisms A number of blockchain systems already employ consensus mechanisms
that elect a node to perform the transaction processing (e.g. proof that elect a node to perform the transaction processing (e.g. proof
of stake in Ethereum). The same consensus mechanisms may be used to of stake in Ethereum). The same consensus mechanisms may be used to
elect the gateway node. elect the gateway node.
However, there are some blockchain systems that do not elect a single However, there are some blockchain systems that do not elect a single
node and which employ a race-to-process strategy (e.g. proof of work node and which employ a race-to-process strategy (e.g. proof of work
in Bitcoin). Since the winner of the proof of work can be any node in Bitcoin). Since the winner of the proof of work can be any node
in the blockchain system, this implies that all the nodes in these in the blockchain system, this implies that all the nodes in these
types of blockchains must be gateway-capable. types of blockchains must be gateway-capable.
8.3. Commitment protocols and forms of commitment evidence 8.3. Remote gateway discovery
Related to the ability to discover other blockchain/DLT systems
globally is the ability to discover the remote gateways for these
other blockchain/DLT systems. A discovery mechanism for external
entities (e.g. for gateway G1) to look for gateway-capable nodes
(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.
8.4. Commitment protocols and forms of commitment evidence
Within Phase 2, the gateway nodes must implement one (or more) Within Phase 2, the gateway nodes must implement one (or more)
transactional commitment protocols that permit the coordination transactional commitment protocols that permit the coordination
between two gateways, and the final commitment of the asset transfer. between two gateways, and the final commitment of the asset transfer.
The choice of the commitment protocol (type/version) and the The choice of the commitment protocol (type/version) and the
corresponding commitment evidence must be negotiated between the corresponding commitment evidence must be negotiated between the
gateways during Phase 1. gateways during Phase 1.
For example, in Phase 2 and Phase 3 discussed above the gateways G1 For example, in Phase 2 and Phase 3 discussed above the gateways G1
skipping to change at page 18, line 15 skipping to change at page 20, line 21
transaction processing. transaction processing.
The smart contract abstraction, based on replicated shared code/state The smart contract abstraction, based on replicated shared code/state
on the ledger [Herl19], must additionally incorporate the notion of on the ledger [Herl19], must additionally incorporate the notion of
policy into the abstraction. policy into the abstraction.
11. References 11. References
11.1. Normative References 11.1. Normative References
[BCH21] Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway
Crash Recovery Mechanism, IETF, draft-belchior-gateway-
recovery-01.", March 2021,
<https://datatracker.ietf.org/doc/draft-belchior-gateway-
recovery/>.
[FATF] FATF, "International Standards on Combating Money [FATF] FATF, "International Standards on Combating Money
Laundering and the Financing of Terrorism and Laundering and the Financing of Terrorism and
Proliferation - FATF Revision of Recommendation 15", Proliferation - FATF Revision of Recommendation 15",
October 2018, <http://www.fatf- October 2018, <http://www.fatf-
gafi.org/publications/fatfrecommendations/documents/fatf- gafi.org/publications/fatfrecommendations/documents/fatf-
recommendations.html>. recommendations.html>.
[ISO] ISO, "Blockchain and distributed ledger technologies- [ISO] ISO, "Blockchain and distributed ledger technologies-
Vocabulary (ISO:22739:2020)", July 2020, Vocabulary (ISO:22739:2020)", July 2020,
<https://www.iso.org>. <https://www.iso.org>.
[NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
Blockchain Technology Overview (NISTR-8202)", October Blockchain Technology Overview (NISTR-8202)", October
2018, <https://doi.org/10.6028/NIST.IR.8202>. 2018, <https://doi.org/10.6028/NIST.IR.8202>.
[ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset
Protocol, October 2020, IETF, draft-hargreaves-odap-00.", Protocol, IETF, draft-hargreaves-odap-01.", November 2020,
October 2020,
<https://datatracker.ietf.org/doc/draft-hargreaves-odap/>. <https://datatracker.ietf.org/doc/draft-hargreaves-odap/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 11.2. Informative References
[ABCH20] Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and [ABCH20] Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and
 End of changes. 60 change blocks. 
157 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/