Introduction

One of the key issues facing the nascent area of blockchain and distributed ledger technology (DLT) is the lack of interoperability across various blockchain networks [1]. The original blockchain idea of Haber and Stornetta [2, 3] is now a fundamental construct within most blockchain systems, starting with the Bitcoin system which first adopted the idea and deployed it in a digital currency context. Given the history of the development of the Internet and of computer networks in general (e.g. LANs, WANs), it is unlikely that the world will settle on one global blockchain system operating universally. The emerging picture will most likely consist of “islands” of blockchain systems, which– like autonomous systems that make-up the Internet – must be “stitched” together in some fashion to make a coherent unity.

One of the main features of a blockchain network that distinguishes it from an Internet routing domain is the perceived value of the signed information contained in the records of the shared ledger of the blockchain. In the case of a routing domain, the goal of the routing protocols and the network elements (e.g. routers) is to route the data packet through the domain in as minimal time as possible. Data packets or PDUs (protocol data units) are therefore seen as being ephemeral and carries no value in themselves. Indeed, in some routing protocols may even duplicate some data packets and pass them through different routes in order to speed-up the delivery of the application-layer message in its totality.

In the world of blockchain technology, many of the leading developers of blockchain protocols and networks seek to be the sole “platform” where transactions occur. We believe this outlook is too short-term and even naive, given the history of the purpose of the Internet development. Many leading voices in the blockchain world often fail to understand the fundamental goals of the Internet architecture as promoted and led by the Defense Advanced Research Projects Agency (DARPA), and thus fail to fully appreciate how these goals have shaped the Internet to achieve its success as we see it today. There was a pressing need in the Cold War period of the 1960s and 1970s to develop a new communications network architecture that did not previously exist, one that would allow communications to survive in the face of attacks. In Section 2 we review and discuss these goals.

The goal of the current work is to bring to the forefront the notion of interoperability, survivability and manageability for blockchain systems, using lessons learned from the three decades of the development of the Internet. Our overall goal is to develop a design philosophy for an interoperable blockchain architecture, and to identify some design principles that promote interoperability [4].

The Design Philosophy of the Internet

In considering the future direction for blockchain systems generally, it is useful to recall and understand goals of the Internet architecture as defined in the early 1970s as a project funded by DARPA. The definition of the Internet as view in the late 1980s is the following: it is “a packet switched communications facility in which a number of distinguishable networks are connected together using packet switched communications processors called gateways which implement a store and forward packet-forwarding algorithm” [5, 6].

Fundamental Goals

It is important to remember that the design of the ARPANET and the Internet favored military values (e.g. survivability, flexibility, and high performance) over commercial goals (e.g. low cost, simplicity, or consumer appeal) [7], which in turn has affected how the Internet has evolved and has been used. This emphasis was understandable given the Cold War backdrop to the packet-switching discourse throughout the 1960s and 1970s. The Advanced Research Projects Agency Network (ARPANET) was an early packet-switching network. It was the first network to implement the TCP/IP protocol suite.

The DARPA view at the time was that there are seven (7) goals of the Internet architecture, with the first three being fundamental to the design, and the remaining four being second level goals. The following are the fundamental goals of the Internet in the order of importance [5, 6]:

Survivability: Internet communications must continue despite loss of networks or gateways.

This is the most important goal of the Internet, especially if it was to be the blueprint for military packet switched communications facilities. This meant that if two entities are communicating over the Internet, and some failure causes the Internet to be temporarily disrupted and reconfigured to reconstitute the service, then the entities communicating should be able to continue without having to reestablish or reset the high level state of their conversation. Therefore, to achieve this goal, the state information which describes the on-going conversation must be protected. But more importantly, in practice this explicitly meant that it is acceptable to lose the state information associated with an entity if, at the same time, the entity itself is lost. This notion of state of conversation is related to the end-to-end principle discussed below.
Variety of service types: The Internet must support multiple types of communications service.

What was meant by “multiple types” is that at the transport level the Internet architecture should support different types of services distinguished by differing requirements for speed, latency and reliability. Indeed it was this goal that resulted in the separation into two layers of the TCP layer and IP layer, and the use of bytes (not packets) at the TCP layer for flow control and acknowledgement.
Variety of networks: The Internet must accommodate a variety of networks.

The Internet architecture must be able to incorporate and utilize a wide variety of network technologies, including military and commercial facilities.

The remaining four goals of the Internet architecture are: (4) distributed management of resources, (5) cost effectiveness, (6) ease of attaching hosts, and (7) accountability in resource usage. Over the ensuing three decades these second level goals have been addressed in different ways. For example, accountability in resource usage evolved from the use of rudimentary management information bases (MIB) into the current sophisticated traffic management protocols and tools. Cost effectiveness was always an important aspect of the business model for consumer ISPs and corporate networks.

The End-to-End Principle

One of the critical debates throughout the development of the Internet architecture in the 1980s was in regards to the placement of functions that dealt with reliability of message delivery (e.g. duplicate message detection, message sequencing, guaranteed message delivery, encryption). In essence the argument revolved around the amount of effort put into reliability measures within the data communication system, and was seen as an engineering trade-off based on performance. That is, how much low-level function (for reliability) needed to be implemented by the networks versus implementation by the applications at the endpoints.

The line of reasoning against low-level function implementation in the network became known as the end-to-end argument or principle. The basic argument is as follows: a lower level subsystem that supports a distributed application may be wasting its effort in providing a function that must be implemented at the application level anyway [8]. Thus, for example, for duplicate message suppression the task must be accomplished by the application itself seeing that the application is most knowledgeable as to how to detect its own duplicate messages.

Another case in point relates to data encryption. If encryption/decryption was to be performed by the network, then the network and its data transmission systems must be trusted to securely manage the required encryption keys. Also, when data enters the network (to be encrypted there) the data will be in plaintext and therefore susceptible to theft and attacks. Finally, the recipient application of the encrypted messaged will still need to verify the source-authenticity of the message. The application will still need to perform key management. As such, the best place to perform data encryption/decryption is the application endpoints – there is no need for the communication subsystem to provide for automatic encryption of all traffic. That is, encryption is an end-to-end function.

The end-to-end principle was a fundamental design principle of the security architecture of the Internet. Among others, it influenced the direction of the subsequent security features of the Internet, including the development of the IP-security sublayer [9] and its attendant key management function [10]. Today the entire Virtual Private Network (VPN) subsegment of the networking industry started based on this end-to-end principle. (The global VPN market alone is forecasted to reach 70 billion dollars in the next few years). The current day-to-day usage of the Secure Sockets Layer (TLS) [11] to protect HTTP web-traffic (i.e. browsers) is also built on the premise that client-server data encryption is an end-to-end function performed by the browser (client) and by the HTTP server.

The Autonomous Systems Paradigm

Another key concept in the development of the Internet is that of autonomous systems (AS) (or routing domains) as a connectivity unit that provide scale-up capabilities. More specifically, the classic definition of an AS is a connected group of one or more networks (distinguishable via IP prefixes) run by one or more network-operators which has a single and clearly defined routing policy [12]. The notion of autonomous systems provides a way to hierarchically aggregate routing information, such that the distribution of routing information itself becomes a manageable task. This division into domains provides independence for each domain owner/operator to employ the routing mechanisms of its choice. IP packet routing inside an autonomous system is therefore referred to as intra-domain routing, while routing between (across) autonomous systems is referred to as inter-domain routing. The common goal of many providers of routing services (consumer ISPs, backbone ISPs and participating corporations) is that of supporting different types of services (in the sense of speed, latency and reliability).

In the case of intra-domain routing the aim is to share best-route information among routers using an intra-domain routing protocol (e.g. distance vector such as RIP [13], or link-state such as OSPF [14]). The routing protocol of choice must address numerous issues, including possible loops and imbalances in traffic distribution. Today routers are typically owned and operated by the legal owner of the autonomous system (e.g. ISP or corporation). These owners then enter into peering agreements with each other in order to achieve end-to-end reachability of destinations across multiple hops or domains. The primary revenue model in the ISP industry revolves around different tiers of services appropriate to different groups of customers.

There are several important points regarding autonomous systems paradigm and the positive impact this paradigm has had on the development of the Internet for the past four decades:

Autonomous systems paradigm leads to scale:
The autonomous system paradigm, the connectionless routing model and the distributed network topology of the Internet allows each unit (the AS) to solve performance issues locally. This in turn promotes service scale in the sense of throughput (end-to-end) and reach (the large numbers of connected endpoints). As such, it is important to see the global Internet today a connected set of “islands” of autonomous system, stitched together through peering agreements.

Figure 1: Autonomous Systems as a set of networks and gateways (after [6])

Domain-level control with distributed topology:
Each autonomous system typically possesses multiple routers operating the same intra-domain routing protocol. The availability of multiple routers implies availability of multiple routing paths through the domain. Despite this distributed network topology, these routers are centrally controlled (e.g. by the network administrator of the domain). The autonomous system as a control-unit provides manageability, visibility and peering capabilities centrally administered by the owner of the domain.
Each entity is uniquely identifiable in its domain:
All routers (and other devices, such as bridges and switches) in an autonomous system are uniquely identifiable and visible to the network operator. This is a precondition of routing. The identifiability and visibility of devices in a domain is usually limited to that domain. Entities outside the domain may not even be aware of the existence individual routers in the domain.
Autonomous system reachability: Autonomous systems interact with each other through special kinds of routers – called Gateways – that are designed and configured for cross domain packet routing. These operate specific kinds of protocols (such as an exterior Border Gateway Protocol [15]), which provides transfer of packets across domains. For various reasons (including privacy and security) these exterior-facing gateway protocols typically advertise only reachability status information regarding routers and hosts in the domain, but do not publish internal routing conditions.
Autonomous systems are owned and operated by legal entities:
All routing autonomous systems (routing domains) today are owned, operated and controlled by known entities. Internet Service Providers (ISPs) provide their Autonomous System Numbers (ASNs) and routing prefixes to Internet Routing Registries (IRRs). IRRs can be used by ISPs to develop routing plans. An example of an IRR is the American Registry for Internet Numbers (ARIN) [16], which is one of several IRRs around the world.

In the next section we re-map the fundamental goals of the Internet architecture in the context blockchain systems, with the goal of identifying some fundamental requirements for blockchain interoperability.

A Design Philosophy for Blockchains

During the 1970s and 1980s several local area network (LAN) systems were in development and were marketed for Enterprises (e.g. IBM SNA [17], DECnet [18]). However, these LANs were distinct enough in their technological approaches (e.g. PHY layer protocols) that they did not interoperate with each other [7]. Today we are seeing a very similar situation, in which multiple blockchain designs are being proposed (e.g. Bitcoin [19], Ethereum [20] Hyperldeger [21], CORDA [22], each having different technological designs and approaches. Most share some common terminology (e.g. “transaction”, “mining node”, etc.), but there is little or no interoperability among these systems.

Following from the first fundamental goal of the Internet architecture, the lesson learned there was that interoperability is key to survivability. Thus, interoperability is core to the entire value-proposition of blockchain technology. Interoperability across blockchain systems must be a requirement – both at the mechanical level and the value level – if blockchain systems and technologies are to become the fundamental infrastructure of the future global commerce [23, 24].

The current work focuses primarily on the interoperability across blockchain systems at the mechanical level, as the basis to achieve a measurable degree of technical-trust across these systems. In turn, technical-trust is needed by the upper level functions to achieve interoperability at the value level, so that legal-frameworks can be created that are able quantify risks based on the technological choices used to implement technical-trust. Poorly designed blockchain systems should present a higher risk for commerce, and vice versa. Finally, business-trust can be built upon these legal-frameworks to allow business transactions to occur seamlessly across multiple blockchain systems globally.

In this section we identify and discuss some of the challenges to blockchain interoperability, using the Internet architecture as a guide and using the fundamental goals as the basis for developing a design philosophy for interoperable blockchains.

In order to clarify the meaning on “interoperability” in the context blockchain systems, we offer the following definition of an “interoperable blockchain architecture” using the NIST definition of “blockchain” (p.50 of [25]):

An interoperable blockchain architecture is a composition of distinguishable blockchain systems, each representing a unique distributed data ledger, where atomic transaction execution may span multiple heterogeneous blockchain systems, and where data recorded in one blockchain is reachable, verifiable and referenceable by another possibly foreign transaction in a semantically compatible manner.

In the following we re-cast the aspects of survivability, variety of service types and variety of systems in the context of blockchain systems.

Survivability

As mentioned previously, interoperability is key to survivability. In the Internet architecture, survivability as viewed by DARPA [5, 6] meant that communications must continue despite loss of networks and gateways. In practical engineering terms, this meant the use of the packet-switching model as a realization of the connectionless routing paradigm.

In the context of blockchain systems generally, survivability should also mean continued operations in the face of various kinds of attacks. The possible types of attacks to a blockchain system has been discussed elsewhere, and consists of a broad spectrum. These range from classic network-level attacks (e.g. network partitions, denial of services, DDOS, etc.) to more sophisticated attacks targeting the particular constructs (e.g. consensus implementation [26, 27, 28]), to targeting specific implementations of mining nodes (e.g. code vulnerabilities; viruses). Similar to applications on the Internet, we can also view survivability more specifically from the perspective of the application (and its user) that is transacting on the blockchain. A user’s transaction should proceed as far as possible despite the blockchain being under attack.

For blockchain systems we propose to re-interpret the term “survivability” to mean the completion (confirmation) of an application-level transaction independent of blockchain systems involved in achieving the completion of the transaction. Furthermore, the transaction may be composed of sub-transactions, in the same sense of a message on the Internet may consists of multiple IP datagrams. Thus, in the blockchain case an application-level transaction may consists of multiple ledger-level transactions (sub-transaction) where each could be intended for (and be confirmed at) different blockchain systems (e.g. sub-transaction for asset transfer in blockchain A, simultaneously with sub-transaction for payments and sub-transaction for taxes in blockchain B).

Here, the notion of packets routing through multiple domains being opaque to the user’s communications application (e.g. email applications, browsers) is now re-cast to the notion of sub-transactions confirmed on a spread of blockchain systems generally being opaque to the user application. Thus, the challenge of reliability and “best effort delivery” becomes the challenge of ensuring that an application-level transaction is completed within reasonable time, possibly with the application itself being oblivious to the actual blockchains where different ledger-level sub-transactions are finally confirmed.

To illustrate the challenges of survivability as interpreted in this manner, we start with the simplest case in which an application sends a “data” transaction (signed hash value) to a blockchain for the purpose of recording it on the ledger of the blockchain (Figure 2). We ignore for the moment the dichotomy of permissionless and permissioned blockchains and ignore the specific logic syntax of the blockchain. Here the application does not care which blockchain records the data as long as once the transaction is confirmed, later the application (and other entities) can find the transaction/block and verify the data has been recorded immutably. Figure 2 illustrates the scenario. The application transmits data-bytes (hash) to a blockchain system No. 1, and waits for confirmation to become available on the blockchain. After waiting for some predetermined time unsuccessfully (i.e. timeout), the application transmits the same data-bytes to a different blockchain system No. 2. The application continues this process until it is able to obtain the desired confirmation.

Figure 2: Example of the reliability of a simple transaction

Although the example in Figure 2 may appear overly simplistic, inefficient, and has the undesirable side-effect of confirmations on multiple blockchains, it highlights a number of questions similar to those posed in the early days of the Internet architecture development:

Application degree of awareness: To what degree must an application be aware of the internal constructs of a blockchain system in order to interact with it and make use of the blockchain? Most (all of) wallet applications today must maintain configuration information regarding which blockchain system to which a key applies.

As a point of comparison, an email client application today is not aware of constructs of packets, MPDUs, routing and so on. It interacts with mail-server according to a high-level protocol (e.g. POP3, IMAP, SMTP) and a well-defined API. The email client needs only to know the destination email address.
Distinguishability and addressability of blockchain systems: For an interoperable blockchain architecture, each blockchain autonomous system must be distinguishable from a naming perspective as well as from an addressing/routing perspective. This introduces some new challenges, such as the situation where a node is permitted to participate in several blockchain systems simultaneously. From a key management perspective, there is also the question regarding multiple uses of the same public key pair across several distinct blockchain systems.
Placement of reliability functions: What is the correct notion of “reliability” in the context of interoperable blockchain systems and where should the function of reliability be placed?
That is, should the function of re-transmitting the same data-bytes (transaction) be part of the application, part of the blockchain system or part of a yet to be defined “middle layer”?
As a comparison, within the TCP/IP stack the TCP protocol has a number of flow control features that “hides” reliability issues from the higher level applications.
Semantic interoperability: If in the future there will emerge blockchain autonomous systems with differing applications (e.g. registry of assets, currency trading, etc.), what mechanisms are needed to convey to an external system the functional goal of a blockchain and its application-specific semantics?
As a comparison, the HTTP protocol and RPC inter-process communications both run on the TCP/IP layer. However, these represent different resource access paradigms for different types of applications.
Objective benchmarks for speed and performance: How do external entities obtain information about the current performance/throughput of a blockchain system and what measure can be used to compare across systems.

Variety of service types

The second goal of the Internet architecture was the support for different types of services, distinguished by different speeds, latency and reliability. The bi-directional reliable data delivery model was suitable for a variety of “applications” on the Internet but each application required different speeds and bandwidth consumptions (e.g. remote login; file transfer, etc.). This understanding led to the realization early in the design of the Internet that more than one transport service would be needed and that the architecture must support simultaneously transports wishing to tailor reliability, delay or bandwidth usage. This resulted in the separation of TCP (that provided reliable sequenced data stream) from the IP protocol that provided “best effort” delivery using the common building block of the datagram. The User Datagram Protocol (UDP) [29] was created to address the need for certain applications that wished to trade reliability for direct access to the datagram construct.

For blockchain systems we propose to re-interpret the notion of service types from the perspective of the different needs of various applications. We distinguish three (3) basic types of service:

Immediate direct confirmation: This refers to applications which require the fastest confirmation from a specific destination blockchain system. The confirmation of the transaction must occur at the destination blockchain. As such, speed and latency are the primary concerns for these types of applications. This is summarized in Figure 3(a). This situation is an analog of the classic TCP-based login service, in which the user performs login to a specific computer system and needs confirmation in as minimal delay as possible (e.g. milliseconds, seconds).
Digital currency applications (e.g. currency trading system) are a typical example of cases needing direct and immediate confirmation with low latency.

Figure 3: Service types based on different confirmation models

Delayed mediated confirmation: This refers to applications which are satisfied with a “temporary” confirmation produced by a mediating blockchain system, which will then seek to “move” the transaction to its intended destination blockchain system. This is summarized in Figure 3(b).
The application will obtain two confirmations: the first would be a temporary confirmation from the mediating blockchain system, while the final confirmation will occur at the destination blockchain system at a later time. As such, there are two latency values corresponding to the two confirmations. The understanding here is that the application deems the first latency to be acceptable from a practical perspective, and that the second latency can be of a longer period of time (e.g. minutes). This is akin to the store-and-forward method used by classic electronic mail systems.
An example of this type of application are non-critical notarization applications which seek to record static (unchanging) data (e.g. birth date on a birth certificate) and which do not require low latency confirmations.
Multi-party mediated confirmation: This scenario is a multi-party variation of the single party mediated case mentioned above. Here, two (or more) applications are seeking to complete a common transaction at an agreed destination blockchain system, with the aid of settlement logic that executes at destination blockchain system. Each of the applications are willing to accept a “temporary” confirmation produced by a mediating blockchain system, with the understanding that they will obtain a final confirmation from the destination blockchain system. This is summarized in Figure 3(c).
This situation is akin to TCP-based messaging or chat servers (e.g. XMPP), in which two (or more) parties converge on a common server even though they each may have their own local servers.

Variety of blockchain systems

The third fundamental goal of the Internet architecture was to support a variety of networks, which included networks employing different transmission technologies at the physical layer (e.g. X.25, SNA, etc.), local networks and long-haul networks, and networks operated/owned by different legal entities. The minimum assumption of the Internet architecture – which is core to the success of the Internet as an interoperable system of networks – was that each network must be able to transport a datagram as the lowest unit common denominator. Furthermore, this was to be performed “best effort” – namely with reasonable reliability, but not perfect reliability.

For blockchain systems we propose a reinterpretation of the minimal assumption as consisting of:

a common standardized transaction format and syntax that will be understood by all blockchain systems regardless of their respective technological implementation, and
a common standardized minimal operations set that will be implemented all blockchain systems regardless of their technological choices.

The notion of a common transaction format is akin to the definition of the minimal IP datagram, which was first published in the 1974 milestone paper by Vint Cerf and Bob Kahn [6]. The operation involved in the datagram case is simple and is implicit in the datagram construct itself, namely that a set of bytes needs to be transmitted from one IP address to another. The situation is somewhat more complex in blockchain systems. Aside from the current common fields found in transactions in current systems (e.g. sender/receiver public keys, timestamp, pointers) there is the question of semantic meaning of the operations intended by the op-code symbols. Some mathematical operations are clear (e.g. op-codes for addition, multiplication, hash function), but others may introduce some degree of ambiguity across systems.

Similar to the variety of technologies implementing LANs and local routing in the 1980s and 1990s, today there are several technological aspect that differentiate one blockchain system from another:

Governance model: The term “governance” in the context of blockchain systems typically is used to refer to the combination of (i) the human-driven policies for the community of participants, (ii) the rules of operations that are encoded within the blockchain software and hardware fabric itself, and (iii) the intended application of the blockchain, which is often
expressed as the “smart contracts” (stored-procedures available on nodes) that are application-specific.
Speed of confirmation: The speed (or “throughput”) of a blockchain system refers to the confirmation speed, based on the population size of the participating nodes and other factors.
Strength of consensus: An important consideration is the size of the population of nodes (i.e. entities contributing to the consensus) at any given moment and whether this information is obtainable. Obtaining this information may be challenging in systems where nodes are either anonymous, or perhaps unobtainable by external entities in the case of permissioned systems.
Degrees of permissionability: Currently the permissionless/permissioned distinction refers to the degree to which users can participate in the system [25]. Interoperability across permissioned blockchains poses additional questions with regards to how data recorded on the ledger can be referenced (referred to or “pointed to”) by transactions in a foreign domain (i.e. another blockchain system).
Degrees of anonymity: There are at least two (2) degrees of anonymity that is relevant to blockchain systems. The first pertains to the anonymity of end-users (i.e. identity-anonymity [30, 31, 32]) and the second is the anonymity of the nodes participating in processing transactions (e.g. nodes participating in a given consensus instance). Combinations are possible, such as where a permissioned system may require all consensus nodes to be strongly authenticated and
identified, but allows for end-users to remain permissionless (and even unidentified/unauthenticated).
Cybersecurity and assurance levels of nodes: The robustness of a blockchain system consisting of a peer-to-peer network of nodes is largely affected by the security of the nodes that make-up the network. If nodes are easily compromised directly (e.g. hacks) or via indirect means (e.g. dormant viruses), the utility of the blockchain system degrades considerably [28].

Design Principles for Blockchain Gateways

As mentioned previously, similar to the Internet architecture consisting of a network of autonomous systems, the future blockchain technology may evolve to becoming a network of interconnected blockchain systems – each with differing internal consensus protocols, incentives mechanisms, permissions and security-related constraints. Key to this interconnectivity is the notion of blockchain gateways. In this section we discuss the potential use of blockchain gateways to provide interoperability and interconnectivity across different blockchain systems and service types.

Blockchain Domains: Intra-Domain and Inter-Domain Nodes

Similar to a routing autonomous system being composed of one or more (possibly nested) routing domains, we propose viewing the nodes of a blockchain domain as being interior nodes and gateway nodes.

Thus, just as routers in a routing-domain operate one or more routing protocols to achieve best routes through that domain, nodes in a blockchain domain to contribute to maintaining a shared ledger by running one or more ledger management protocols (e.g. consensus algorithms, membership management) to achieve stability and fast convergence (i.e. confirmation throughput) of the ledger in that domain:

Interior nodes: These are nodes and other entities whose main task is maintaining ledger information and conducting transactions within one blockchain domain.
For certain blockchain configurations (e.g. private or permissioned) the interior nodes are prohibited from engaging external entities without authorization.

Figure 4: Overview of gateway-to-gateway transfer of virtual assets

Gateway nodes: These are nodes and other entities whose main task is dealing with cross-domain transactions involving different blockchain autonomous systems.

Figure 4 provides a high level illustration of gateway nodes G within two blockchain domains (interior nodes are not shown). Although Figure 4 shows a small number of nodes G to be designated as inter-domain gateway nodes, ideally all nodes in a given blockchain autonomous system should have the capability (i.e. correct software, hardware, trusted computing base) to become a gateway node. This allows dynamic groups (subsets) of the population of nodes to become gateway groups that act collectively on behalf of the blockchain system as a whole [33].

Design Principles

There are several design principles for blockchain gateway-to-gateway interoperability, with two key principles being the following [34]:

Opaque blockchain resources: The interior resources of each blockchain system must be assumed to be opaque to (hidden from) external entities.
In the context of two gateway nodes performing an asset transfer from one blockchain system to another, any resources to be made accessible to one gateway must be made explicitly accessible by the other gateway node with proper authorization (and vice versa).
The opaque resources principle permits the interoperability architecture to be applied in cases where one (or both) blockchain systems are permissioned (private). It is the analog of the
autonomous systems principle in IP networking [5], where interior routes in local subnets are not visible to other external autonomous systems.
Externalization of value: A gateway-to-gateway protocol must be agnostic (oblivious) to the economic or monetary value of the virtual asset being transferred.
The value-externalization principle permits asset transfer protocols to be designed for efficiency, speed 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 [8], where contextual information (economic value) is placed at the endpoints of the transaction. In the case of virtual asset transfers, the originator and beneficiary at the respective ends are assumed to have a common agreement regarding the economic value of the asset.

A key aspect of the autonomous system principle in the Internet architecture is that routing-data (e.g. interior route advertisements) belonging to an ISP is opaque (invisible) to other ISPs and external entities. This provides the freedom for an ISP to innovate within the confines of its own network (e.g. using new routing protocols and routers), while not impacting other ISPs. The ISP-to-ISP interaction occurs through the deployment of an exterior inter-domain routing protocol (e.g. BGPv4) that acts as a standardized interface between networks. The role of a gateway node therefore is also to mask (hide) the complexity of the interior constructs of the blockchain system that it represents. Overall this approach ensures that a given blockchain system operates as a true autonomous system.

Note that the opaque ledgers assumption has implications on smart contract cross-chain conditionals, such as cross-chain hash-locks [35] and time-locks – which assume that the ledgers on both sides of the cross-chain transfer are readable/writeable (e.g. see [36, 37, 38, 39]).

A Gateway Interoperability Architecture

The goal of a gateway interoperability architecture is to permit two (2) gateway nodes belonging to distinct blockchain systems 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 blockchains (double-spend problem).

The architecture must recognize that there different blockchain systems currently in operation and evolving, and that in many cases the interior technical constructs in these blockchains maybe incompatible with one another. The resources within a blockchain system (e.g. ledgers, public-keys, consensus protocols, etc.) must be 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 systems. This ensures that the virtual asset transfer protocol between gateways is not conditioned or dependent on these interior technical constructs.

Functional Requirements

There are a number of functional requirements for cross-chain transfers of virtual assets between two blockchain systems or domains [34]:

Asset validation before transfer: There must be some means for the recipient entity (in the destination blockchain) to validate the asset type and legal status prior to engaging with the transfer.
Commitment atomicity: Asset transfers across blockchain systems must employ an atomic commitment scheme that prevents (detect) the same asset being present simultaneously on both blockchains (e.g. using 2-Phase Commit Protocol (2PC) [40, 41]).
There are several efforts today to reuse the atomic commitment protocols from the field of distributed databases and concurrency control (e.g. see [37]). The overall aim of many of these schemes is to interpret (re-cast) the ACID properties (atomicity, consistency, isolation, durability) [42] of these protocols to the context of asset transfers, at least for unidirectional transfers (database transactions are typically unidirectional). Additional properties (e.g. safety, liveliness) have also been suggested (e.g. cross-chain deals [43]).
Transfer non-repudiability: There must be sufficient evidence regarding the finality and settlement at both blockchain systems to obviate disputes.
Evidence of settlement can consist of the combinations of confirmed transactions on the blocks on both ledgers, local signed-logs by the nodes handling the cross-chain transfer, logs from the commitment layer, and so on.
Policy federation as part of peering agreements: Blockchain systems need compatible policies along several axes, including: (i) the type of regulated asset being transferred; (ii) the legal jurisdiction of operations of the entities (VASPs) owning the nodes; (iii) the type of operations permitted (e.g. unidirectional unconditional transfers only, conditional transfer, etc.), (iv) the agreed commitment protocol and non-repudiation protocol to be used (or negotiated from a common standard list), and (v) the configuration of the nodes handling the transfers on both sides based on the node-device attestation evidence (see [44, 45] for a discussion on node device identities and node attestations).

Identifiers for Blockchain Domains and VASP Numbers

Each autonomous systems (AS) in the Internet is allocated a globally unique AS-number. For example, in the United States this task is managed by the American Registry for Internet Numbers (ARIN) [16]. For the EU the organization is RIPE, for Africa it is AFRINIC, for Asia-Pacific it is APNIC and so on [46].

Today the VASP and virtual asset industry globally has yet to agree on a common VASP numbering scheme and customer identification scheme. The notion of a unique VASP number has been proposed in [47, 48], while other mechanisms have been contemplated, such as using the VASP’s Legal Entity Identifier (LEI) [49] within the VASP KYC-Certificate [50].

Asset Locking during Cross-Domain Transfers

A requirements for cross-domain asset transfers between two blockchain domains is preventing double-spend of the asset (inadvertently or otherwise) on the part of the customer (originator) who owns it. In this case, a double-spend would consist of a customer initiating a cross-domain transfer of their asset while at the same using the same asset in a different transaction (e.g. locally in the same blockchain domain).

One approach to solve this dilemma is for the gateway node to temporarily lock the asset while the transfer process is underway. The notion of “locking” is borrowed from the classic field of database transaction and concurrency-control [51, 40, 41]. In transactional database systems, locking techniques are used to “mark” a data item (e.g. database row) as undergoing an update by one process. Other processes are unable to access (write to) the data item until the lock is released.

Given the diversity of blockchain transaction processing models (e.g. UTXO in Bitcoin; external-owned accounts and smart contract accounts in Ethereum; etc.) we believe that (i) the ledger is the only reliable shared-state and synchronization method for all the nodes in a blockchain network [52, 53], and therefore that (ii) the lock-state information for cross-domain transfers must be recorded on the ledger so that the lock-state is visible to all nodes in the same blockchain domain. From an audit and security perspective, the recording of lock/unlock information on the ledger provides the benefit of historical traceability of cross-domain events in the case of disputes.

The specific lock/unlock mechanism is dependent on the cross-domain atomic commitment protocol used by gateway nodes. However, in general they must perform the following tasks:

Asset locked transaction: This transaction marks an asset associated with a customer public-key as being in a locked-state and therefore will not be processed by other nodes. A time duration may be set in the transaction header denoting the duration of validity of the lock, after which the lock automatically expires and the asset considered unlocked.
Asset unlock transaction: This is an explicit unlock transaction that marks the asset as being “free” (unlocked state) on the ledger. An asset-unlock transaction must match an existing asset-lock transaction on the same ledger, and it is typically issued by the same gateway node that issued the lock. The purpose of an explicit unlock is to terminate a lock before the expiration of its timer. This feature is useful for cases such as an aborted cross-domain transaction (e.g. abort request from customer).
Asset lock-committed transaction: This transaction marks a virtual asset as being henceforth permanently unavailable due to the asset exiting (transferred out of) the origin blockchain. Typically, this transaction must refer to (include a hash of) a previous asset-locked transaction confirmed on the ledger. It may include an identifier that points to the new home (destination blockchain) of the virtual asset [4, 33].

Figure 5: Summary of flows in a cross-domain transfer

Although the specific locking mechanism is beyond the current work, in general lock/unlock transactions must include at least the following parameters: the identifier of the asset being locked, the address (public key) of the current holder (customer), identity of the gateway node issuing the lock, the timestamp value (or timer), and the hash of the confirmed transaction on the ledger where the asset was last used. Similarly, an asset unlock transaction must include a hash of the earlier confirmed asset locked transaction.

Example of Flows in a Cross-Domain Transfer

An example of the flows that occur in a cross-domain transfer between two blockchain domains in shown in Figure 5. The gateway nodes are shown as G1 in domain BD1, and G2 in domain BD2 respectively. Alice is the originator (customer C1), while Bob is the beneficiary (customer C2). Gateway G1 is assumed to be legally owned by a VASP, making it the Originator-VASP. Similarly, gateway G2 is assumed to be legally owned and operated by a Beneficiary-VASP [54].

The transfer consists of four (4) general phases, including the commitment protocol embedded in the flows:

Phase 1: Initiation of transaction and policy validation. There are a number of pre-transfer tasks that need to occur in this phase:

The processing node (gateway G1) must locate the correct destination domain BD2 where the beneficiary (Bob) is thought to reside.
Gateway G1 must validate that gateway G2 is owned by a registered VASP, and vice versa (see [50, 45] for a discussion of VASP status validation).
Gateway G1 must request gateway G2 to seek consent from the beneficiary (Bob) to receive the asset to be transferred. This protects the beneficiary and the owner of G2 by giving them exculpatory evidence. An explicit consent from a beneficiary is a requirement in some jurisdictions (e.g. see FINMA [55]).
Gateway G2 must validate that the virtual asset to be transferred from G1 is compatible with the core operating policies of the blockchain domain BD2.
If all is well, gateway G2 transmits an acknowledgment to G1 that the transfer can proceed.

Phase 2: Local locking of asset. In this phase the gateway G1 issues a local asset-locked transaction on ledger L1 to the asset in question. This prevents double-spending on the part of the originator.

Optionally, gateway G2 may indicate an incoming asset by issuing a candidate-lock on its ledger L2. The candidate-lock is not binding, but serves as an audit trail in case of later disputes.

Phase 3: Preparation to commit. In this phase gateway G1 acting as the coordinator (in the context of the embedded 2PC protocol [40, 41]) signals readiness to commit to gateway G2.

Phase 4: Finalization of commit. In this phase the gateway G1 as coordinator signals to gateway G2 to perform the global commitment on ledger L2. Gateway G1 then issues an asset lock-committed transaction on ledger L1 to close its previous asset-locked transaction in Phase 2.

Gateway G2 records the new asset on its local ledger L2, assigning it to the public-key of the beneficiary Bob. If G2 employed a candidate-lock transaction on L2 previously in Phase 2, then G2 can also close that transaction with its own asset-locked transaction on ledger L2.

The astute reader may recognize that Phase 2 to Phase 4 constitutes a variant of the 2PC commitment protocol, often referred to as 3PC (i.e. three phase commit). In distributed databases this occurs through the use of a commit-prepare message followed by a global-commit message sent from the coordinator (node G1) to all recipient (in this case, node G2). The reader is directed to [51] for further discussion on the topic of reliability of commitment protocols.

Inter-Domain Trust Establishment: Node Attestations

Another potential use of gateways in the context of blockchain interoperability is to support the establishment of trust (i.e. technical-trust) across blockchain autonomous systems. We believe there is a promising role for trusted hardware to implement many of the function of the gateways. As mentioned previously, ideally all nodes in a given blockchain autonomous system should possess the relevant trusted hardware and software to allow them to take-on the role of gateways as required. Trusted hardware in nodes provide the basis for nodes to perform attestation [44] of each other as part of Phase 1 of the asset transfer. Similarly, trusted hardware can be used to secure keys in end-user wallets, and provide a means for the wallet to attest to its current configuration. This may be useful from an asset insurance perspective [56].

Examples of trusted hardware include the TPM [57] with its various roots of trust for measurement, storage and reporting. The first successful version was TPM v1.2 that supported a “one-size-fits-all” approach that primarily targeted the PC market. A second generation TPM v2.0 expanded trusted computing features to better support vertical markets. TPMv2.0 introduced platform specific profiles that define mandatory, optional and excluded functionality for PC Client, Mobile and Automotive-Thin platform categories. Platform-specific profiles allow TPM vendors flexibility in implementing TPM features that accommodates a specific market. Additionally, TPMv2.0 supports three key hierarchies, for storage, platform and endorsement. Each hierarchy can support multiple keys and cryptographic algorithms. We believe that TPM v2.0 profiles for trusted gateways could be developed for the blockchain infrastructure market.

Another example of trusted hardware is the Software Guard Extensions (SGX) from Intel Corporation [58]. The SGX offers another perspective on trusted computing base where a trusted environment exists within a user process called an Enclave. The SGX TCB consists of hardware isolated memory pages, CPU instructions for creating, extending, initializing, entering, exiting and attesting the enclave and privileged CPU modes for controlling access to enclave memory. A second generation SGX (see [59]) added support for dynamic memory management where enclave runtimes could dynamically increase or decrease the number of enclave pages.

There are multiple steps to establish measurable technical-trust that can be input into legal frameworks in the context of peering. Some of these are as follows:

Mutual verification of gateway device-identities: Prior to interacting, two gateways belonging to separate blockchain autonomous system must mutually verify their device identities (e.g. AIK-certificates in TPM) [60].
Mutual attestation of gateway device status: As part of trust establishment each gateway may be required to attest to its hardware and software stack [44], as well as the current state of some of its hardware registers (e.g. Quote protocol [57, 58]).
Mutual session key establishment: For use-cases involving session keys, the gateways have the additional task of negotiating the keying parameters, and establish the relevant session keys.
Mutual reporting of transaction settlement: In use-cases involving one (or both) private blockchains, an additional requirement could be the signing of assertions using a gateway’s device-keys.

Peering-Points for Peering Business Agreements

Gateways in the context of blockchain interoperability can be used to serve as the peering-points identified within peering agreements or contracts. Historically, in the case of the various ISPs that constitute the Internet the peering agreements are legally binding contracts that define the various interconnection aspects (e.g. traffic bandwidth, protocols, etc.) as well as fees (“settlements”) and possible penalties. For the interoperability of autonomous blockchain systems, a notion similar to peering agreements must be developed that possess features specifically for blockchain technology and the governance model used by the systems.

Peering agreements for blockchain systems should include, among others, the following:

Identification of gateways chosen as peering points: A blockchain peering agreement should require the clear identification of gateways which are permitted to peer with other gateways. This agreement may specify the device certificates, hardware and software manifest (e.g. hash of manifest), root certificates, device status attestations, and so on.
Specify the minimal trust establishment mechanisms and parameters: A peering agreement should specify the trust negotiation and establishment protocols, the respective known parameters (e.g. size of key parameters), the key management protocols, standards compliance required, minimal assurance level required, and others.
Specify warranties and liabilities: Similar to peering agreements for ISPs and certificate practices statement for Certificate Authorities (CA), blockchain peering agreements should clearly identify the liabilities of parties (e.g. in monetary terms) in negative or catastrophic scenarios (e.g. gateway is compromised).

Conclusions

The fundamental goals underlying the Internet architecture has played a key role in determining the interoperability of the various networks and service types, which together compose the Internet as we know it today. Interoperability is key to survivability. A number of design principles emerged from the evolution of internet routing in the 1970s and 1980s, which ensured the scalable operation of the Internet over the last three decades.

We believe that a similar design philosophy is needed for interoperable blockchain systems. The recognition that a blockchain system is an autonomous system is an important starting point that allows notions such as reachability, referencing of transaction data in ledgers, scalability and other aspects to be understood more meaningfully – beyond the current notion of throughput (“scale”), which is often the sole measure of performance used with regards to many blockchain systems today.

Furthermore, interoperability forces a deeper re-thinking into how permissioned and permissionless blockchain systems can interoperate without a third party (such as an exchange). A key aspect is the semantic interoperability at the value level and at the mechanical level. Interoperability at the mechanical level is necessary for interoperability at the value level but does not guarantee it. The mechanical level plays a crucial role in providing technological solutions that can help humans in quantifying risk through the use of a more measurable notion of technical-trust. Human agreements (i.e. legal contracts) must be used at the value level to provide semantically compatible meanings to the constructs (e.g. coins, tokens) that circulate in the blockchain system.

References

J. Martin, “Vitalik Proposes Solution to Embarrassing Lack of Bitcoin–Ethereum Bridge,” Cointelegraph, March 2020. [Online]. Available: https://cointelegraph.com/ news/vitalik-proposes-solution-to-embarrassing-lack-of-bitcoinethereum-bridge
S. Haber and W. Stornetta, “How to Time-Stamp a Digital Document,” in Advances in Cryptology - CRYPTO’90 (LNCS 537), 1991, pp. 437–455.
D. Bayer, S. Haber, and W. Stornetta, “Improving the efficiency and reliability of digital time-stamping,” in Sequences II: Methods in Communication, Security and Computer Science,
R. Capocelli, A. DeSantis, and U. Vaccaro, Eds. Springer, 1993, pp. 329–334.
T. Hardjono, A. Lipton, and A. Pentland, “Towards an Interoperability Architecture Blockchain Autonomous Systems,” IEEE Transactions on Engineering Management, pp. 1–12, 2019, doi:10.1109/TEM.2019.2920154. [Online]. Available: https://arxiv.org/abs/1805.05934
D. Clark, “The Design Philosophy of the DARPA Internet Protocols,” ACM Computer Communication Review – Proc SIGCOMM 88, vol. 18, no. 4, pp. 106–114, August 1988.
V. G. Cerf and R. E. Khan, “A Protocol for Packet Network Intercommunication,” IEEE Transactions on Communications, vol. 22, pp. 637–648, 1974.
J. Abbate, Inventing the Internet. MIT Press, 1999.
J. Saltzer, D. Reed, and D. Clark, “End-to-End Arguments in System Design,” ACM Transactions on Computer Systems, vol. 2, no. 4, pp. 277–288, November 1984.
S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998,
IETF Standard RFC2401. [Online]. Available: http://tools.ietf.org/rfc/rfc2401.txt
D. Harkins and D. Carrel, “The Internet Key Exchange (IKE),” November 1998,
IETF Standard RFC2409. [Online]. Available: http://tools.ietf.org/rfc/rfc2409.txt
T. Dierks and C. Allen, “The TLS Protocol Version 1.0,” January 1999,
IETF Standard RFC2246. [Online]. Available: http://tools.ietf.org/rfc/rfc2246.txt
J. Hawkinson and T. Bates, “Guidelines for Creation, Selection, and Registration of an Autonomous System (AS),” March 1996, IETF Standard RFC1930. [Online]. Available: http://tools.ietf.org/rfc/rfc1930.txt
G. Malkin, “RIP Version 2,” November 1998, IETF Standard RFC2453. [Online]. Available: http://tools.ietf.org/rfc/rfc2453.txt
J. Moy, “OSPF Version 2,” April 1998, IETF Standard RFC2328. [Online]. Available: http://tools.ietf.org/rfc/rfc2328.txt
K. Lougheed and Y. Rekhter, “Border Gateway Protocol (BGP),” June 1989, IETF Standard RFC1105. [Online]. Available: http://tools.ietf.org/rfc/rfc1105.txt
ARIN, “American Registry for Internet Numbers – Autonomous System Numbers (asn.txt),” 2018. [Online]. Available: https://www.arin.net
J. H. McFadyen, “Systems Network Architecture: An Overview,” IBM Systems Journal, vol. 15, no. 1, pp. 4–23, 1976.
S. Wecker, “DNA: The Digital Network Architecture,” IEEE Transactions on Communications, vol. 28, no. 4, pp. 510–526, 1980.
S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf
V. Buterin, “Ethereum: A Next-Generation Cryptocurrency and Decentralized Application Platform,” Bitcoin Magazine, Report, January 2014, https://bitcoinmagazine.com/articles/ethereum-next-generation-cryptocurrency-decentralized-application-platform-
E. Androulaki Et al., “Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains,” in Proceedings of the Thirteenth EuroSys Conference (Eurosys’18). ACM, 2018, pp. 30:1–30:15.
R3CEV, “R3,” 2018, https://www.r3.com.
A. Lipton and A. Pentland, “Breaking the Bank,” Scientific American, vol. 318, no. 1, pp. 26–31, 2018.
A. Lipton, T. Hardjono, and A. Pentland, “Digital Trade Coin (DTC): Towards a more stable digital currency,” Journal of the Royal Society Open Science (RSOS), August 2018, available at https://doi.org/10.1098/rsos.180155.
D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain Technology Overview,” NIST Draft NISTIR 8202, January 2018, available on https://csrc.nist.gov,.
I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is vulnerable,” in Financial Cryptography and Data Security - 18th International Conference, FC 2014, March 2014, pp. 436–454.
A. Gervais, G. O. Karame, V. Capkun, and S. Capkun, “Is bitcoin a decentralized currency?”
IEEE Security & Privacy, vol. 12, no. 3, pp. 54–60, 2014.
B. Schneier, “There’s no good reason to trust blockchain technology,” Wired Magazine, February 2019, https://www.wired.com/story/theres-no-good-reason-to-trust-blockchain-technology/.
J. Postel, “User Datagram Protocol,” August 1980, IETF Standard RFC0768. [Online].
Available: http://tools.ietf.org/rfc/rfc0768.txt
D. L. Chaum, “Untraceable electronic mail, return addresses, and digital pseudonyms,”
Communications of the ACM, vol. 24, no. 2, pp. 84–88, February 1981.
J. Camenisch and E. Van Herreweghen, “Design and implementation of the Idemix anonymous credential system,” in Proceedings of the 9th ACM conference on Computer and communications security. ACM, 2002, pp. 21–30.
T. Hardjono and N. Smith, “Cloud-Based Commissioning of Constrained Devices Using Permissioned Blockchains,” in Proceedings of the Second ACM International Workshop on IoT Privacy, Trust, and Security (IoTPTS 2016). ACM, 2016, pp. 29–36.
——, “Decentralized Trusted Computing Base for Blockchain Infrastructure Security,” Frontiers Journal - Special Issue on Finance, Money & Blockchains, vol. 2, December 2019. [Online]. Available: https://doi.org/10.3389/fbloc.2019.00024
T. Hardjono, A. Lipton, and A. Pentland, “Towards a Contract Service Provider Model for Virtual Assets and VASPs,” September 2020. [Online]. Available: https://arxiv.org/abs/2009.07413
T. Nolan, “Alt chains and atomic transfers,” May 2013. [Online]. Available: https:
//bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
P. Ezhilchelvan, A. Aldweesh, and A. van Moorsel, “Non-blocking two phase commit using blockchain,” in Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems (CryBlock?18). New York, NY, USA: Association for Computing Machinery, 2018, p. 36?41. [Online]. Available: https://doi.org/10.1145/3211933.3211940
V. Zakhary, D. Agrawal, and A. E. Abbadi, “Atomic Commitment Across Blockchains,” June 2019. [Online]. Available: https://arxiv.org/pdf/1905.02847.pdf
M. Herlihy, “Atomic Cross-chain Swaps,” in Proceedings of the ACM Symposium on Principles of Distributed Computing PODC’18. New York, NY, USA: Association for Computing Machinery, July 2018, pp. 245–254. [Online]. Available: https://dl.acm.org/doi/pdf/10.1145/ 3212734.3212736
E. Heilman, S. Lipmann, and S. Goldberg, “The Arwen Trading Protocols (Full-Version).” [Online]. Available: https://eprint.iacr.org/2020/024.pdf
I. L. Traiger, J. Gray, C. A. Galtieri, and B. G. Lindsay, “Transactions and Consistency in Distributed Database Systems,” IBM Research Report, vol. RJ2555, 1979.
J. Gray, “The Transaction Concept: Virtues and Limitations,” in Very Large Data Bases
– Proceedings of the 7th International Conference, Cannes, France, September 1981, pp. 144–154.
T. Haerder and A. Reuter, “Principles of Transaction-Oriented Database Recovery,” ACM Computing Surveys, vol. 15, no. 4, p. 287?317, December 1983. [Online]. Available: https://doi.org/10.1145/289.291
M. Herlihy, B. Liskov, and L. Shrira, “Cross-chain Deals and Adversarial Commerce,”
Proceedings of VLDB, vol. 13, no. 2, October 2019. [Online]. Available: https:
//doi.org/10.14778/3364324.3364326
T. Hardjono and N. Smith, “An Attestation Architecture for Blockchain Networks,” May 2020, available at https://arxiv.org/abs/2005.04293.
T. Hardjono, “Trust Infrastructures for Virtual Asset Service Providers,” August 2020, available at https://arxiv.org/abs/2008.05048.
Wikipedia, “Regional Internet Registry,” 2020. [Online]. Available: https://en.wikipedia.org/ wiki/Regional Internet registry
D. Riegelnig, “OpenVASP: An Open Protocol to Implement FATF’s Travel Rule for Virtual Assets,” November 2019. [Online]. Available: https://www.openvasp.org/wp-content/uploads/ 2019/11/OpenVasp\ Whitepaper.pdf
InterVASP, “InterVASP Messaging Standards IVMS101,” Joint Working Group on interVASP Messaging Standards, Working Draft – Issue 1 – Draft G, March 2020.
GLEIF, “LEI in KYC: A New Future for Legal Entity Identification,” Global Legal Entity Identifier Foundation (GLEIF), GLEIF Research Report ? A New Future for Legal Entity Identification, May 2018. [Online]. Available: https://www.gleif.org/en/lei-solutions/ lei-in-kyc-a-new-future-for-legal-entity-identification
D. Jevans, T. Hardjono, J. Vink, F. Steegmans, J. Jefferies, and A. Malhotra, “Travel Rule Information Sharing Architecture for Virtual Asset Service Providers,” TRISA, Version 7, June 2020. [Online]. Available: https://trisa.io/wp-content/uploads/2020/06/ TRISAEnablingFATFTravelRuleWhitePaperV7.pdf
P. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems. New York: Addison-Wesley, 1987.
T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding Concurrency to Smart Contracts,” in Proceedings of the ACM Symposium on Principles of Distributed Computing PODC’17. New York, NY, USA: Association for Computing Machinery, 2017, pp. 303–312. [Online]. Available: https://doi.org/10.1145/3087801.3087835
M. Herlihy, “Blockchains From a Distributed Computing Perspective,” Communications of the ACM, vol. 62, no. 2, pp. 78–85, February 2019. [Online]. Available: https:
//doi.org/10.1145/3209623
FATF, “International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation,” Financial Action Task Force (FATF), FATF Revision of Recommendation 15, October 2018, available at: http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html.
FINMA, “FINMA Guidance: Payments on the blockchain,” Swiss Financial Market Supervisory Authority (FINMA), FINMA Guidance Report, August 2019. [Online]. Available: https://www.finma.ch/en/∼/media/finma/dokumente/dokumentencenter/myfinma/ 4dokumentation/finma-aufsichtsmitteilungen/20190826-finma-aufsichtsmitteilung-02-2019. pdf
T. Hardjono, A. Lipton, and A. Pentland, “Wallet Attestations for Virtual Asset Service Providers and Crypto-Assets Insurance,” June 2020. [Online]. Available: https:
//arxiv.org/pdf/2005.14689.pdf
Trusted Computing Group, “TPM Main – Specification Version 1.2,” Trusted Computing Group, TCG Published Specification, October 2003, available at http://www.trustedcomputinggroup.org/ resources/ tpm main specification.
F. Mckeen, I. Alexandrovich, A. Berenzon, C. Rozas, H. Shafi, V. Shanbhogue, and
U. Savagaonkar, “Innovative Instructions and Software Model for Isolated Execution,” in Proc. Second Workshop on Hardware and Architectural Support for Security and Privacy HASP2013, Tel-Aviv, June 2013, https://sites.google.com/site/haspworkshop2013/workshop-program.
F. McKeen, I. Alexandrovich, I. Anati, D. Caspi, S. Johnson, R. Leslie-Hurd, and C. Rozas, “Intel Software Guard Extensions (Intel SGX) Support for Dynamic Memory Management Inside an Enclave,” in Proc. Workshop on Hardware and Architectural Support for Security and Privacy (HASP) 2016, Seoul, June 2016, http://caslab.csl.yale.edu/workshops/hasp2016/program.html.
T. Hardjono and G. Kazmierczak, “Overview of the TPM Key Management Standard,” May 2008. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/ Kazmierczak20Greg20-20TPM Key Management KMS2008 v003.pdf

12. Interoperability of Distributed Systems