Blockchain Gateways, Bridges and Delegated Hash-Locks
BBlockchain Gateways, Bridges and Delegated Hash-Locks
THOMAS HARDJONO,
MIT Connection ScienceIn the current work we discuss the notion of gateways as a means for interoperability across different blockchainsystems. We discuss two key principles for the design of gateway nodes and scalable gateway protocols, namely(i) the opaque ledgers principle as the analogue of the autonomous systems principle in IP datagram routing, and(ii) the externalization of value principle as the analogue of the end-to-end principle in the Internet architecture.We illustrate the need for a standard gateway protocol by describing a unidirectional asset movement proto-col between two peer gateways, under the strict condition of both blockchains being private/permissionedwith their ledgers inaccessible to external entities. Several aspects of gateways and the gateway protocolis discussed, including gateway identities, gateway certificates and certificate hierarchies, passive lockingtransactions by gateways, and the potential use of delegated hash-locks to expand the functionality of gateways.February 11, 2021Additional Key Words and Phrases: Blockchains, gateways, virtual assets, atomic swaps, delegation.ContentsAbstract 1Contents 11 Introduction 22 Gateways for Interoperability, Autonomy and Asset Mobility 23 Blockchain Gateway Architecture 33.1 Gateway Definition, Roles and Functions 43.2 The Three Parts of the Cross-Chain Asset Movement Problem 63.3 Design Principles 63.4 Gateway Protocols: Desirable Atomicity Properties 73.5 Gateway Protocols: Desirable Security Properties 84 An Atomic Unidirectional Gateway Protocol 84.1 Phase 1: Identity Verification, Asset Validation and Parameters Exchange 94.2 Phase 2: Evidence of asset locking or escrow 104.3 Phase 3: Final commitment of asset movement 115 Discussion 125.1 Extinguishment and Regeneration of Assets: Locks & Escrows 125.2 Gateway Identities, Signing Keys and Certificates 145.3 A Certificate Hierarchy for VASPs and Gateways 155.4 Gateway Crash Recovery 175.5 Gateway Discoverability 176 Looking Further Afield 186.1 Third Party Witness Blockchains 186.2 Bridges for Private Blockchain Networks 196.3 Gateways and Delegated Hash-Locks 217 Conclusions 22References 23
Author’s address: Thomas Hardjono, MIT Connection Science, 77 Massachusetts Avenue, Cambridge, MA 02139, [email protected]. a r X i v : . [ c s . CR ] F e b Thomas Hardjono
Interoperability across blockchain systems represents one of the open challenges today for thebroad adoption of blockchain technology and distributed ledger technology (DLT) generally. Thepromise of the decentralization of control as offered by the vision of blockchains cannot be attainedif different blockchain systems – employing different internal ledger architectures, consensusparadigms and differing processing incentives – cannot interoperate at the scale of the Internet. Inthe current work we explore further the notion of blockchain gateways as a means to interconnectdistinct and incompatible blockchain networks [1].In Section 2 we motivate the need for gateways from the perspective of the autonomy ofblockchain networks and the need to address the problem of cross-border virtual asset move-ments [2]. Section 3 proposes two key principles for the design of gateway nodes and scalablegateway protocols. In Section 4 we illustrate with a gateway protocol that performs a unidirectionalmovement of a virtual asset representation from one blockchain to another. The various aspectsand open challenges to the proper design of blockchain gateways are then discussed in Section 5.We also explore additional possible functions that a gateway may implement in Section 6, includingthe use of a delegated hash-lock to a remote third party blockchain to assist in the movement of afungible virtual asset and of the value that may be associated with the asset.We seek to make this paper readable to a broad audience, and thus have avoided using detailedtechnical constructs belonging specific blockchains. The reader is assumed to have some basicknowledge regarding blockchains, shared ledgers, consensus algorithms and public-key technology.We use the term “blockchain” and “DLT” interchangeably for convenience.
Currently blockchains and DLT systems are exhibiting similar patterns of growing pains as that ofLAN technologies in the 1980s. There is today a proliferation in the number of blockchain projectsaround the world (e.g. over three dozen systems as surveyed by [3]). Although on the surface thisapparent proliferation of blockchain projects may seem to be a new phenomenon, in reality thisis part of the natural cycle in the development of emerging technologies. A similar developmentcycle was also experienced in the early days of Local Area Networks (LAN) technologies and therouting protocols for data within these LANs. Examples of Enterprise LAN technologies from thatperiod of development include IBM SNA, DECnet, Ethernet, etc.One milestone moment in the history of the nascent Internet was the definition of the IP datagramstructure [4] with the support of DARPA and their goals for the survivable network [5, 6]. Thearchitecture of the Internet viewed each network as an autonomous system (AS), where each ASwould operate its own interior routing protocol. A given autonomous system may even containmultiple LANs, where each LAN could implement different physical layer (PHY level) protocols (e.g.token-ring in SNA, CSMA/CD in DECnet, etc). This approach permitted each autonomous systemto develop and deploy its own technological choice to satisfy the goal of delivering the standard IPdatagram, from the point where the IP datagram enters the autonomous system to the point whereit departs from it. Each autonomous system was free to operate the interior (intra-domain) routingprotocol of its choice (e.g. RIP, IS-IS, OSPF, etc,) [7]. In order to interconnect autonomous systemsto provide end-to-end reliable services to the user, special routers called border gateway routerswere deployed between peered autonomous systems. The main function of a border router in agiven autonomous system is to advertise available routes to its peered border router at an adjacentautonomous system. Protocols such as the Border Gateway Protocol (BGPv4) [8] were developedfor this purpose. lockchain Gateways, Bridges and Delegated Hash-Locks 3
In order for blockchain-based services to scale globally, blockchain networks must be able tointeroperate with one another following a standardized protocol and interfaces (APIs). We believethat a blockchain gateway is needed for blockchain networks to interoperate in a manner similarto border gateway routers in IP networks. Furthermore, just as border gateway routers use theBGPv4 protocol to interact with one another in a peered fashion, we believe that a blockchaingateway protocol will be needed to permit the movement of virtual assets and related informationacross blockchain networks in a secure and privacy-preserving manner. We motivate the need forblockchain gateways and blockchain gateway protocols in the following summary: • Enables blockchain interoperability : Blockchain gateways provide an interface for the inter-operability between blockchain/DLT systems that operate distinct consensus protocols andledger data structures. A gateway fronts its blockchain/DLT system, and exposes a standardinterface (APIs) to an external peer (opposite) gateway. Facing outwards, a gateway imple-ments a gateway-to-gateway protocol with the peer gateway. Facing inwards, a gatewayimplements the relevant interior resources (e.g. consensus protocol, ledger management, keymanagement, etc.) relevant to participate in its blockchain/DLT system. Gateways permitsprivate blockchain/DLT systems to interact with public blockchain/DLT systems. • Ensures blockchain network autonomy : The use of gateways as the interface point betweenblockchain networks permits each blockchain network to evolve, where new innovations andnew technologies can be deployed interiorly within a blockchain network without affectingother external blockchains. In this way, a blockchain network truly behaves as an autonomousnetwork in the same vein as the original vision of the IP Internet. • Enables virtual asset mobility : There is a growing need for virtual assets to be moveableacross blockchain networks, a need that will only increase with growth of CBDC tokenizedcurrencies [9]. The use of blockchains permit innovative asset movement protocols to be devel-oped that can be implemented by gateways across standardized APIs. Such asset movementprotocols can be designed for specific asset types and be operated by gateways according tothe different regulatory jurisdictions in the world. • Enforcement point for AML/KYC regulations and international taxation : Gateways as the“landing points” for virtual asset entering into (departing from) blockchain networks becomesan enforcement point for AML/KYC regulations [2]. Furthermore, for cross-border movementof assets the gateways also become “checkpoints” where international taxation concerns canbe addressed and implemented. • Enables integration with legacy systems : The use of a standardized gateway-protocol betweenpeers of gateways permits one of the blockchains to be substituted for a legacy system(e.g. financial database systems) without impact to the remote peer. That is, a standardizedgateway protocol can be use to hide the fact behind the gateway lies a legacy system. Thegateway hides the complexity of the interiors of the system that it fronts – be it legacy datasystems or new blockchain/DLT systems.
In this section we discuss the concept of gateways in the context of asset movement acrossblockchain networks. Our view is motivated by the fact that: (i) there are today and will increasinglybe multiple autonomous blockchain networks in the future; (ii) that many of these blockchainswill be private with ledgers that are read/write permissioned; and that (iii) interoperability amongthese blockchains (public and private) will be a core necessity that will determine the viability
Thomas Hardjono
Fig. 1. The problem of dependence on centralized exchanges for asset movement of blockchain and DLT technology as a means to retain and exchange digital representations ofeconomic value.The design of a gateway architecture has many challenges, three among which are: (i) entityidentities – namely the correct validation of the digital identities of entities in the blockchainecosystem; (ii) atomic asset movement – namely the secure, atomic and efficient movement ofthe digital representation of virtual assets from one blockchain to another; and (iii) reliability ofgateways and the mechanisms to recover securely from crashes. A blockchain gateway is a computer system in a blockchain network for the purpose of assistingin the movement of virtual assets into (out of) the blockchain network [1, 10]. Being a node in itsblockchain network, a gateway has read/write access to the shared ledger of the blockchain andmay participate in the consensus mechanism of the blockchain. A gateway is dual-faced in thatit is said to be facing interiorly when interacting with its blockchain, and facing exteriorly wheninteracting with a remote peer gateway belonging to a different blockchain network. Two (2) peergateways jointly execute a gateway protocol that implement the relevant steps for moving a virtualasset with the mediation of the gateways from one blockchain to another.By definition a gateway belongs to one blockchain network only, and when facing interiorly(inward) it must be identifiable and authenticable to entities in that blockchain network. For interiorinteractions, a gateway has at least one blockchain transaction signing public/private key-pair.When facing exteriorly, a gateway must have a gateway identity public/private key-pair that itemploys when interacting with remote peer gateways. This key-pair permits the gateway to beidentifiable and authenticable by peer gateways (see Section 5.2 below for a discussion on gatewayidentity keys).The legal owner and operator of a node is referred to as a Virtual Asset Service Provider (VASP)in the sense of the FATF definition [2]. The VASP owner of a gateway employs a
VASP identity public/private key-pair. Some form of cryptographic binding is assumed to exists between thegateway identity public-key and the VASP identity public-key.At a high level, among others there are three (3) roles and functions of peer gateways (Figure 2): • Protocol and state information translation : A blockchain gateway performs the translation ofledger-based state information from one blockchain to another. The state information in a lockchain Gateways, Bridges and Delegated Hash-Locks 5
Fig. 2. Three (3) segments of the cross-chain asset movement problem ledger pertains to the ownership of a virtual asset, which typically is associated with (boundto) a public-key (address) of the current owner.A ledger within an origin blockchain may employ a different data structure (to represent vir-tual assets) that is different from the ledger data structure used in the destination blockchain.As such, the gateway in an origin blockchain may need to deliver the information in astandardized format to the gateway in an destination blockchain in order to permit interoper-ability. Looking at Figure 2, gateway G1 in blockchain B1 may translate the information fromits ledger L1, while gateway G2 in blockchain B2 performs the same task for its ledger L2.The gateway protocol employed between gateway G1 and G2 should define a standardizedformat that can convey acurrately the information from ledger L1 to L2. • Ledger consistency maintenance during asset movement : Individually, a gateway maintainsthe consistency of the ledger in its blockchain system in connection to the movement ofvirtual assets into (out of) the blockchain system. Together, two peer gateways must jointlymaintain consistency of state information across their ledgers respectively.In the context of virtual asset movement assisted by G1 and G2, consistency across ledgers
L1and L2 refers to the prevention by G1 and G2 of the double-existence of the asset (leading todouble spending) in blockchains B1 and B2 respectively. • Regulatory Policy Enforcement Point : A gateway takes on the role of a Policy EnforcementPoint (PEP) [11, 12] for enforcing rules (policies) that implement regulations related to assettypes and legal jurisdictions.The movement of a virtual asset between blockchains may in fact cross regulatory andgovernance boundaries, and as such information regarding the legal status of the asset andthe involved entities may reside outside the ledger of the blockchain. The function of agateway is also to obtain validated information from eternal sources regarding the asset andentities.
Thomas Hardjono
In the current work we subdivide the problem of a gateway protocol for cross-blockchain assetmovement into three (3) parts or sub-problems, where the three steps must execute to completionin atomic fashion (see Figure 2):(1)
Extinguishment of the asset at the origin blockchain : Information must be recorded on theorigin ledger L1 to denote the fact that the asset associated with its last owner (originatoraddress) no longer exists (i.e. no longer accessible) in the origin blockchain. This is shown asStep-1 in Figure 2.(2)
Blockchain-to-blockchain transfer commitment : The gateways that mediate (i.e. delegatedto perform) the asset movement must exchange signed messages that legally commit toperforming the relevant steps of the asset-movement. This is shown as Step-2 in Figure 2.(3)
Regeneration of the asset at the destination blockchain : Information must be recorded onthe destination ledger L2 that an asset instance has been introduced into the ledger and isassociated with an owner (beneficiary address) in that blockchain. This is shown as Step-3 inFigure 2.Since the ledger of a blockchains operates on an append-only basis [13, 14], this means that unliketraditional databases there is no way to “delete” information that has been recorded (confirmed) onthe ledger. This means that in reality the task of “extinguishment” and “regeneration” of a virtualasset must be implemented using the same append-only mechanism used by the blockchain. Inother words, the same transaction processing paradigm used in blockchain technologies should beused to manifest the notions of extinguishment and regeneration of assets. We discuss further thepossible mechanisms to “mark” ledgers for asset extinguishment and regeneration in Section 5.1.It is important to note that a cross-blockchain asset movement is not necessarily equivalent toa local movement (same blockchain). It is insufficient to simply record on the ledger L1 that theasset’s ownership was transferred to a given address (public key), in this case to the address of thegateway G1. This is due to the possibility that the destination blockchain B2 may reside within adifferent regulatory and governance jurisdiction. Thus, the transaction initiated by the originatoron blockchain B1 must include both the address of the beneficiary and the blockchain identifierwhere the beneficiary address is located. This combined information – including the public-keys ofG1 and G2 – must be recorded on both ledgers L1 and L2, including when both blockchains B1 andB2 are private/permissioned. This recording on ledgers L1 and L2 must be such that there is littleroom for disputes (e.g. among the originator, beneficiary, owner of G1 and owner of G2) and thatpost-event audits can be performed on both sides.
The interoperability of blockchain systems affects the scalability of the services built atop theblockchains. In order to develop scalable gateway protocols, there are a number of design principlesunderlie the interoperability architecture of gateways [10]:
Opaque ledgers principle : The interior ledger and other resources of each blockchainsystem must be assumed to be opaque to (hidden from) external entities. Any resourcesto be made accessible to an external entity must be made explicitly accessible by itsgateway with proper authorization.This principle is the analogue of the autonomous systems principle in IP networking [5], whereinterior routes in local subnets are not visible to other external autonomous systems. Observance of lockchain Gateways, Bridges and Delegated Hash-Locks 7 this principle leads to a design of gateway-to-gateway protocols that do not rely on (be dependenton) interior constructs that are unique to specific blockchain systems.
Externalization of value principle : The gateway-to-gateway protocol that imple-ments the cross-blockchain asset movement must be agnostic to (oblivious to) theeconomic or monetary value of the virtual asset being moved.This principle is the analogue of the end-to-end principle in the Internet architecture [15], wherecontextual information of the communicating parties is placed at the endpoints of the communi-cations instance. The Internet’s interior routing fabric is oblivious as to which application eachdatagram belongs to. This principle permits gateway protocols to be designed for efficiency, speedand reliability – independent of the changes in the perceived economic value of the virtual asset. Inthe case of virtual asset movements, the originator and beneficiary at the respective blockchainsystems are assumed to have a common agreement regarding the economic value of the asset.The resources within a blockchain system (e.g. ledgers, keys, consensus protocols, smart contracts,etc.) are assumed to be opaque to external entities in order to permit a resilient and scalable protocoldesign that is not dependent on the interior constructs of particular blockchain systems. This ensuresthat the virtual asset movement protocol between gateways is not conditioned upon or dependent onthese interior technical constructs. A gateway interacts in two directions, namely facing outboundor exteriorly to other peer gateways and facing inbound to its blockchain system. The role of agateway therefore is also to mask (hide) the complexity of the interior constructs of the blockchainsystem that it represents. Overall this approach ensures that a given blockchain system operates asa true autonomous system.The point of the opaque ledgers/resources principle is to enable the design of a cross-blockchainasset movement protocol under the strictest condition – namely that both blockchains are private andtheir ledgers, keys, data structures and smart-contracts (i.e their interior resources) are inaccessibleto each other – so that the same protocol can be used in less strict situations also. Thus, theinteraction between the two private blockchains are possible only through their respective gatewaysand the interfaces (i.e. standardized APIs) which the gateways implement. The thinking is that ifan asset movement protocol (i.e. gateway protocol) can operate securely and efficiently betweentwo private blockchain systems (with no visibility into each other’s ledgers/resources), then theprotocol will also operate when one or both blockchains are public/permissionless.
From the state (ledger) consistency perspective, there are a number of desirable properties withregards to a gateway protocol [16]: • Atomicity : An asset movement must either commit or entirely fail (where failure means thereare no changes to asset ownership in the origin blockchain). • Consistency : An asset movement (commit or fail) must always leave both blockchain systemsin a consistent state, where the asset in question is located in one blockchain only. A protocolfailure must not result in a “double-existence” of the asset (leading to double-spend in thetwo blockchain systems respectively). • Isolation : While the asset movement is occurring, the asset ownership cannot be modified.That is, some kind of temporary disablement of the asset at the origin blockchain must beused (e.g. locking on the ledger, escrow to a gateway, etc). This is to prevent the owner (who
Thomas Hardjono requested the cross-chain asset movement) from double-spending the asset locally while thegateway protocol is executing. • Durability : Once an asset movement has been committed on both the origin blockchain anddestination blockchain, this commitment must remain true regardless of subsequent gatewaycrashes.These properties must hold true regardless of whether one or both of the blockchain systems areprivate (permissioned) or public (permissionless).
From a security and non-repudiation perspective, there are a number of requirements for a gateway-protocol: • Identification and authentication : Gateways must be able to mutually identify and authenticateeach other using the relevant gateway identity keys, trust anchors and other entity identifierschemes. This means that the gateway identity key-pair used to interact externally with otherpeer gateways must be different from the transaction signing key-pair that it uses internallyfor its ledger. • Secure channel for confidentiality and privacy : All communications between gateways must bebe performed over a secure channel, using standard secure channel establishment protocols(e.g. IPsec [17–19], SSL/TLS [20, 21]). • Non-repudiation of asset movement : Relevant parts of the messages exchanged betweengateways must be digitally signed using the gateway identity key-pair in such a way thatthe entire protocol exchange yields non-repudiable evidence regarding the movement ofthe asset. Gateways must keep a forensic log of these messages in such a manner that thecomplete flows are reconstructable in the case of a future legal dispute or a future inquiry byrelevant regulatory authorities. • Crash recovery into secure state : The crash of one gateway (or both) during the movementof an asset must not result in loss or leakage of information pertaining to asset or entityinformation (e.g. originator and beneficiary identities). The gateway recovery mechanismmust always place a gateway into a safe state.We discuss gateway identities and keys in Section 5.2.
There is today considerable research interest in the area of “atomic swaps” within public (per-missionless) blockchains (e.g. see [22–26]). However, there is scant effort today to address thestandardization of the various infrastructure building blocks – messages, data formats and flows –to support the interoperability across blockchains that permit “swaps” to occur.In this section we discuss a rudimentary gateway protocol to support the unidirectional movementof a virtual asset from an origin blockchain to a destination blockchain with the assistance of gatewaynodes at the respective endpoints. We focus on the unidirectional movement as a building block,with the understanding that it should be usable to achieve bi-directional conditional swaps whilesatisfying the general atomicity requirements (Section 3.4) and security requirements (Section 3.5).As a common building block, the gateway protocol must be operable in the case that one or bothblockchains are private (permissioned) systems. For the commitment establishment between the lockchain Gateways, Bridges and Delegated Hash-Locks 9
Fig. 3. Overview of the phases of the gateway asset movement protocol (after [10, 16]) two gateways, we use the classic 2-Phase Commit paradigm (2PC or 3PC) [27–29], which is awell-understood and widely deployed paradigm (e.g. in distributed database systems).At a high level, the gateway protocol is used to move a digital representation of an asset fromone blockchain system to another, with the goal of maintaining consistency across the ledgers ofthe respective blockchains. A gateway node must therefore interact in two directions: (a) facinginteriorly the gateway must perform the relevant tasks in ensuring the consistency of state in itsledger, and (b) facing exteriorly the gateway must interact with a peer remote gateway to obtainagreement regarding the movement of the virtual asset.In the following, we divide the gateway protocol into three (3) general phases [10, 16] and discussthe tasks that need to occur with in each phase. The first phase is triggered by the originator (Alice)in blockchain B1 seeking to move assets to the beneficiary (Bob) in B2 (see Figure 3). Each gatewayis assumed to keep a persistent log of all the messages it receives or transmits to its peer gateway.This is to permit the gateway to recover from crashes, and to use the information in the log tore-commence the gateway protocol.
The primary purpose of the first phase is to verify the various information relating to the asset to bemoved, the identities of the originator and beneficiary, the identity and legal status of the entities(VASPs) who own and operate the gateways, the identities of the gateways and the exchange ofsession parameters needed to establish the secure channel between G1 and G2.This phase starts with the assumption that the gateway G1 has been selected (elected) inblockchain B1 and that gateway G2 in blockchain B2 has been identified. The following are asummary of the various checks that need to be performed in this phase: • Secure channel establishment between G1 and G2 : This includes the mutual verification of thegateway device identities and the exchange of the relevant parameters for secure channelestablishment. In cases where device attestation [30–32] is required, the mutual attestationprotocol must occur between G1 and G2 prior to proceeding to the next phase. • Validation of the gateway ownership : There must be a means for gateway G1 and G2 to verifytheir respective ownerships (i.e. VASP1 owning G1 and VASP2 owning G2 respectively).Examples of ownership verification mechanism include the chaining of the gateway-deviceX.509 certificate up to the VASP entity certificate, directories of gateways and VASPs, andother approaches. • Validation of owner legal status : There must be a means for gateway G1 and G2 to verifythe legal status of the VASP who owns the gateway. In some jurisdictions limitations maybe placed for regulated VASPs to transact only with other similarly regulated VASPs [33].Examples of mechanisms used to validate a VASP legal status include LEI numbers [34], VASPdirectories [35], Extended Validation (EV) X.509 certificates for VASPs [36, 37], and others. • Identification and validation of correct profile of asset : There must be a means for gateway G1and G2 to identity and reference the definition of the virtual asset to be moved. We use theterm asset profile [38] to refer to this definition. Some jurisdictions may limit the movementof certain types of virtual assets, and thus it is imperative that both G1 and G2 be referringto the same asset definition. • Exchange of Travel Rule information : In jurisdictions where the Travel Rule policies regardingoriginator and beneficiary information is enforced, the gateways G1 and G2 must exchangethis information [2]. • Negotiation of asset movement protocol parameters : Gateway G1 and G2 must agree on theparameters to be employed within the asset movement protocol. Examples include endpointsdefinitions for resources, type of commitment flows (e.g. 2PC or 3PC), lock-time durations ineach ledger, and others [39]. An important parameter is the average expected confirmationtimes of transactions within each respective blockchain network (e.g. the times 𝑡 in ledgerL1, 𝑡 in ledger L2, and 𝑡 for the gateway protocol, as illustrated in Figure 2). In this phase, gateway G1 must provide gateway G2 with sufficient evidence that the asset onblockchain B1 is in a locked state (or escrowed) under the control of G1 on ledger L1, and safe fromdouble-spend on the part of its current owner (the originator). The purpose of this evidence is fordispute resolution between G1 and G2 (i.e. entities who own and operate G1 and G2 respectively)in the case that double-spend is later detected. Additionally, this phase is used is prepare bothgateways for the third phase where the actual commitment occurs.There are several general steps which occur in this phase (see Figure 3): • Asset locking in the origin blockchain : The asset in question must be locked (or escrowed) tothe gateway G1 and be under the exclusive control of the G1 within blockchain B1. This isshown as Step 2 in Figure 3.The mechanism to lock the asset is dependent on the specific architecture of the blockchain.For example, a lock can be created using a passive transaction where the gateway G1 issuesa transaction on the ledger that signals to the other nodes (e.g. mining or forging nodes) todelay other pending transactions on the same asset until the duration of the lock in finished. lockchain Gateways, Bridges and Delegated Hash-Locks 11
We discuss this further in Section 5.1. Other examples of mechanisms include a direct escrowfrom the originator (Alice) to the gateway G1 (i.e. to the public-key of the G1 on blockchainB1). • Delivery of signed lock-evidence : The gateway G1 – which has the authoritative lock on theasset on in blockchain B1 – must deliver a signed evidence to gateway G2 that the asset hasbeen locked to G1. The evidence must be signed using the gateway-identity key pair whichis known to the destination gateway G2 and possibly to other entities globally. This is shownas Step 3 in Figure 3.The form of the evidence depends on the lock mechanism used in the origin blockchain butshould include: (i) the transaction/block number on ledger L1 where the lock (escrow) hasbeen confirmed; (ii) the hash of the header of the block (assuming a Merkle Tree hash isincluded in the header); (iii) the hash of the public-keys of the originator and beneficiary; (iv)the hash of the blockchain public-key of the gateway G1; (v) a timestamp; and others.The gateway G2 at the destination blockchain has the option to passively record the receivedevidence on its local ledger L2 (shown as Step 4 in Figure 3). • Acknowledgement of received evidence : The gateway G2 must then return a signed messageacknowledging the receipt of the evidence in the previous step (Step 5 in Figure 3). Thepurpose of this acknowledgement is to provide exculpatory evidence (cover) for gatewayG1 in the case that G2 is dishonest. As such, the message carry a hash of the previous lock-evidence message (in Step 3) and it must be signed using the gateway-identity key pair ofG2.
The goal of the third phase is to establish transactional commitment between gateway G1 and G2that they will each perform the relevant tasks necessary to complete the unidirectional movementof the asset from blockchain B1 to blockchain B2. The term commitment here is used in the sense ofthe classic 2PC model [27, 28] where both sides perform actions that are durable – following fromthe atomicity properties (Section 3.4). In the case of append-only ledgers, the results of the 2PC(3PC) commitment would be recorded by G1 and G2 in their respective local ledgers L1 and L2.There are several steps which occur in this phase (see Figure 3): • Commit preparation and acknowledgement : Following the 2PC (3PC) model, gateway G1 actsas the coordinator in the 2PC commitment context. This means that G1 has the task to ensurethat the other gateway(s), namely G2 in this case, is ready on its part to perform the commiton its ledger L2. This is represented as Step 6 and Step 7 in Figure 3. • Finalization of lock or escrow in ledger L1 : Since the asset movement originated from blockchainB1 – with gateway G1 being the commitment coordinator – the finalization of the lock (escrow)must occur first on ledger L1. This means that in Step 8 gateway G1 must record on ledgerL1 that the asset has been moved to the address (public key) of the beneficiary located onledger L2 in blockchain B2 with the assistance of gateway G2. We discuss further passivetransactions and escrows in Section 5. • Delivery of evidence of final lock/escrow : Once the lock (escrow) finalization has been recorded(confirmed) on ledger L1, the gateway G1 must deliver evidence of this confirmed lock/escrowon L1 to the gateway G2.Because of the opaque ledgers assumption (see Section 3.3), gateway G2 has no visibility intoledger L1 and therefore must solely trust the signed assertion by gateway G1 that the lock (escrow) finalization has been confirmed on L1. The signed assertion delivered in Step 9from G1 to G2 must include the entire information (data) confirmed on ledger L1 from theprevious Step 8 – even though gateway G2 has no way to validate the truthfulness of theinformation. The purpose of this is to provide exculpatory legal evidence for gateway G2(and its owner/operator VASP2) in the case that gateway G1 cheats and that a duplication(double-spending) of the asset has occurred. • Finalization of asset regeneration in ledger L2 : Based on the signed assertion from G1 deliveredin Step 9, the gateway G2 performs a similar finalization of the asset regeneration on ledger L2in blockchain B2. The information recorded on L2 must include the signed information/data(or hashes of) received by G2, as a means to protect G2 (i.e. as exculpatory proof) against adishonest G1 or a dishonest beneficiary. This is shown as Step 10 in Figure 3.Depending the data structure (i.e. block structure) of the ledger L2, gateway G2 may haveto map the data from the signed assertion to the format used on L2. If the block size on L2cannot accommodate the full assertion data from G1 (from the previous step), then a hash ofthe assertion should be used instead – with the full signed assertion being stored off-chain inprotected storage. • Report asset regeneration commitment (acknowledge-final) : Once the asset regeneration transac-tion is confirmed on ledger L2, the gateway G2 may optionally report the new block/transactiondetails (on L2) to gateway G1. This is shown as Step 11 in Figure 3.This step is not strictly part of the 2PC model, but in the context of asset movements across pri-vate (permissioned) blockchains it provides a means for future tracing of the asset movementsfrom the legal perspective (e.g. legal audit). • Local recording of new asset location : Assuming gateway G2 provides a report to G1 of thenew location of the asset (i.e. new block/transaction details on L2), the gateway G1 mayrecord this data on ledger L1.
The movement of virtual assets between blockchain networks is a complex problem because itstraddles (cuts across) three (3) “planes” (or domains) that together provide an interpretation ofeconomic value of the virtual assets according to the prevailing socio-economic conventions andlegal/governance rules (regulations) in a given area of the world. We refer to these three planes as:(i) the mechanical (technical protocols) plane, (ii) the value plane (i.e. economic or financial values)(iii) the legal and governance jurisdictions plane (see Figure 4).In the following we discuss various aspects and challenges related to the gateway architectureand gateway-protocol described above.
As mentioned previously in Section 3.2, at the mechanical plane (protocol layer) the proposedgateway architecture implements the notion of asset extinguishment and regeneration. Thus, atthe protocol layer we define the following:A unidirectional cross-blockchain movement of virtual assets consists of the extin-guishment of the asset representation in the ledger of the origin blockchain and for the regeneration of the asset representation within the ledger of the destination blockchain,conducted as an atomic operation. lockchain Gateways, Bridges and Delegated Hash-Locks 13
Fig. 4. Asset Movement at the Mechanical, Value and Legal Jurisdictions Planes
There several technical means to realize the notion of “extinguishment” and “regeneration” ofvirtual assets on distributed ledgers, with the meditation of gateway nodes. These two operationsmust be performed atomically, leading to consistency of data across both ledgers.The atomicity-related requirements (Section 3.4) necessitate the use of temporary “locks” on theasset in question on the origin blockchain to temporarily disable it and prevent double-spending.This introduces the question of how “locks” can be employed on ledgers which by definition areappend-only data structures [13, 14]. The ledger recording of a temporary lock must be communi-cated by gateway G1 in the origin blockchain to gateway G2 at the destination blockchain as aform of evidence that the atomic movement of the asset has commenced.Two possible mechanisms for temporary locks or disablement of asset are as follows: • Conditional escrow transaction : An escrow transaction on an asset on a blockchain alters theownership of the asset from its current owner to a trusted third party based on some condition.An escrow can be timed in that a duration of time 𝑡 𝑒𝑠𝑐 is allocated within which the conditionmust be fulfilled. In the context of cross-blockchain asset movement, the condition is relatedto the atomic commitment mediated by gateway G1 and G2 through their execution of thegateway-protocol. If the gateway protocol finishes to completion within the set duration oftime 𝑡 𝑒𝑠𝑐 , then the escrow is finalized and the asset reverts ownership. If the gateway protocolfails to conclude within time 𝑡 𝑒𝑠𝑐 , then the asset reverts back to the originator.The precise method to implement escrows is dependent on the protocols employed by theblockchain (e.g. combinations of hash-locks, time-locks, multisig, smart contracts, etc) andthe asset representation on the ledger (e.g. fungible, non-fungible). However, regardless ofthe precise mechanism, the escrow must be confirmed on the ledger and therefore be visible tothe all the entities having access to the ledger. • Passive blocking & disablement transaction : A passive blocking transaction (directed at an asset)is a type of transaction that refers to the asset on the ledger for the purpose of temporarilyblocking or deferring other actions on the same asset by other nodes/trasactions. The passiveblocking transaction contains a time duration 𝑡 𝑏𝑙𝑜𝑐𝑘 that counts once the transaction has beenconfirmed on the ledger. It does not change the ownership of the asset (i.e. the public-keymost recently associated with the asset). A passive blocking transaction can either time-out (i.e. blocking no longer valid) or it can bemade permanent by a matching passive disablement transaction that makes the effect of theblocking transaction to be permanent. Once the disablement transaction is confirmed on theledger, the asset in question is no longer considered to be active on the blockchain.Both types of mechanisms provide a means to temporarily “lock” an asset with the subsequentoption to make the lock effect permanent on the ledger (i.e. extinguish the asset by making ithenceforth inaccessible). Furthermore, in both approaches there is evidence of these actions recorded(appended) permanently on the ledger. As an illustration, the Phase-2 of the gateway protocol(Section 4.2 and Figure 3) employs a pair of “locks” on ledger L1. In Step 2 the gateway G1 issuesa temporary asset disablement, which is subsequently finalized in Step 8 of Figure 3. If Step 2 isnever closed by a matching Step 8 (e.g. due to gateway crashes), then the lock effect will time-outand will be ignored by other nodes.Symmetrically to the disablement of an asset at the origin blockchain, the same asset must beintroduced into the destination blockchain in two basic steps, namely the notification step and the finalization step performed by the gateway G2. The notification step “announces the impendingarrival” of an asset to be assigned to the beneficiary’s address (public-key) on the ledger L2 of thedestination blockchain. This notification transaction is passive in that it acts as a log entry to berecored on the ledger L2. It does not assign ownership of the asset to the beneficiary. Ideally, thepassive notification transaction issued by G2 should include the the lock/disablement informationdelivered by gateway G1 to G2, the relevant timestamps, and the address (public key) of thebeneficiary.In order for the asset to be fully regenerated in blockchain B2, a finalization transaction mustbe issued by G2 that formally records on ledger L2 the ownership assignment of the asset to thebeneficiary’s public-key. The finalization transaction must include relevant information, includinga hash of the previous notification transaction confirmed on ledger L2, as a means to refer to thespecific asset movement in question. Continuing the above illustration, the passive notificationtransaction is shown as Step 4 within the gateway protocol (Section 4.2 and Figure 3). The finalizationtransaction is shown as Step 10 within the gateway protocol (Section 4.3 and Figure 3). If Step 4is never closed by a matching Step 10 (e.g. because gateway crashes), then the announcementtransaction will time-out and be thereafter ignored.
In jointly executing the gateway protocol (Section 4), the gateways G1 and G2 must perform anumber of digital signatures on the messages in the protocol. These digital signatures signify thepromise or commitment on the part of the owners of the gateways to perform the asset movementfollowing the prescribed protocol. The signatures becomes crucial in the case of disputes occurringbetween the owners of the gateways (and possibly involving the originator and beneficiary). Assuch, mechanisms are needed to cryptographically bind the public-key of a gateway to the identityof its owner (a VASP) in such a way that the digital signatures [40] performed by a gateway becomeslegally binding to its owner. Figure 4 provides a high level illustration of the entity identities, whichwe have expanded upon in Figure 5.We define at least four (4) types of public-private key pairs associated with a gateway and itsowner (Figure 5): • VASP identity key-pair : This public-private key pair is used by the VASP in interacting (off-chain) with other entities in the capacity of the VASP as a legal entity. This is illustrated inFigure 5(a). The VASP should employ a different key-pair when signing transactions on a lockchain Gateways, Bridges and Delegated Hash-Locks 15
Fig. 5. Gateway identity and VASP identity key-pairs & certificates blockchain system. The VASP identity public-key may be represented inside an ExtendedValidation (EV) X.509 certificate (see [36, 37] for a discussion of EV-Certificates for VASPs). • Gateway identity key-pair : This public-private key pair is used by a gateway when interactingwith peer remote gateways (i.e. facing outbound). Among others, it is used to set-up thesecure channel with the peer gateway and to sign the various protocol messages exchangedbetween the two gateways. This is shown in Figure 5(b).Ideally, the gateway identity public-key should be represented within the standard X.509certificate, with additional fields containing either the hash of the VASP identity public-key(or hash of VASP identity certificate), or the serial-number VASP identity certificate. Thegateway X.509 certificate should be issued under the VASP X.509 identify certificate. Thiscertificate linking or chaining signifies the ownership of the gateway by the VASP. • Gateway transaction signing key-pair : This public-private key pair is used by the gateway tosign transactions on its interior ledger in the gateway’s capacity as a node in the blockchainnetwork. Depending on the requirements of the blockchain, the public-key may be representedwithin an X.509 certificate that is bound to the VASP identity certificate. This is shown inFigure 5(c). • Gateway device attestations key-pair : This public-private key pair is a device-level key pairused by the gateway to sign attestations evidence [41] pertaining to the hardware/softwarestack [42] underlying the gateway implementation (see [31] for a discussion of node attes-tations within blockchain networks). Ideally the key pair should be bound to the hardwareof the gateway in such a way that it is difficult (un-economical) for attackers to physicallyremove, export or replace the private key. Solutions for hardware-bound keys have beendeveloped by several industry organizations [43–46]. This is shown in Figure 5(d).
When a gateway opens a connection with a peer remote gateway in another blockchain system,one immediate requirement of the respective gateways is the verification of the legal ownership ofthe gateway device (i.e. which VASP owns the gateway) and the validation of the legal status of the
Fig. 6. Example of a certificate hierarchy for VASP identities and their gateways
VASP (see Section 4.1). We use the generic term “VASP” for the owner and operator of gatewaysfollowing the FATF definition [2, 47].One possible solution is for gateways to employ X.509 digital certificates [48, 49] and for thecertificates to be exchanged as part of the TLS handshake [20, 50]. This approach of exchangingX.509 certificates is a common practice in the Internet online commerce industry since the mid-2000’s. The CA/Browser (CAB) Forum has additionally defined
Extended Validation (EV) fields,which contains the business-related information of the subject (i.e. business entity) [51]. A similarEV-certificates approach is being adopted currently for VASPs, where the VASP business information(e.g. business registration, legal address, LEI number, etc.) is added as the EV fields in their X.509certificates [36, 37].In the case of gateway identity public keys, we believe a certificate hierarchy is required that canassociate or bind a gateway X.509 identity certificate to the owner’s X.509 EV-identity certificate,and which permits any entity to quickly perform “chain validation” (up the certificate chain) of thesecertificates. Such a device/operator combined certificate hierarchy is not new, and has been deployedby the Cable Modem industry for over two decades now under the industry consortium called CableLaboratories (Cable Labs) [52, 53]. This solution was developed to permit DOCSIS1.2 [54] (or higher)cable modem devices to perform mutual authentication with its head-end device (cable modemtermination service or CMTS) that is owned by the regional cable provider/operator company. Asimilar approach for WiFi and Wireless-LAN devices is described in [55, 56].Figure 6 provides an illustration for a potential certificate hierarchy, that is rooted in an industryconsortium. One purpose of the certificate hierarchy is to permit recipients of any VASP-relatedcertificate (issued under the hierarchy) to be able to quickly validate the certificate, with theassurance that the VASP legal status has been verified by the consortium [37]. Another purposeis to permit VASP the freedom to issue some relevant certificates, such as the gateway identitycertificates (for their gateways) and customer signing key certificates (for their customers whosekeys are hosted by the VASP).A deeper discussion of VASP certificates and gateway certificates is outside the scope of thecurrent work, and will be treated in future work. lockchain Gateways, Bridges and Delegated Hash-Locks 17
An important issue with the use of gateways is that of the potential unavailability of a gateway,due to crashes or other availability issues. In order to anticipate gateway crashes, a crash recoveryscheme or strategy should be part of the design of gateways. This design should also be informedby the blockchain architecture for which the gateway is designed (i.e. inward facing). The overallgoal of a crash recovery scheme is to maintain the desirable atomicity properties (Section 3.4) andsecurity properties (Section 3.5). As mentioned previously, a gateway must retain a persistent logof all the messages that it received from (and sent to) its peer gateway in the execution of the assetmovement protocol (e.g. ODAP protocol [39]).There are several aspects related to crash recovery that needs to be taken into consideration: • Recovery gateway selection : There needs to be a mechanism to determine the recovery gate-way that will re-engage the remote peer gateway to complete the gateway protocol (assetmovement) session. There are several approaches or strategies that can be adopted. Oneapproach could be self-healing , meaning that the same gateway device recovers (e.g. reboots)and picks-up the session from the last possible check-point in the log. Another approachcould be the use of primary backup gateway that detect the crash of the primary gatewayand takes-over the re-starting of the gateway protocol [57]. An alternative strategy could beelection of the recovery gateway, such as through the use of the consensus algorithm itself. • Reliable storage of event logs and access to logs : There needs to be storage facility to storelogs of the messages received from (sent to) a peer gateway, such that the entire sequencecan be reconstructed up to the point where the crash occurred. There are several possibleapproaches with regards to the storage of logs by a gateway in a blockchain network. Thisincludes (i) placing the log data on the main ledger (i.e. transactions ledger), (ii) storing thelog data off-chain, with each entry hashed to the main ledger (for data integrity purposes),(iii) establishing a special “metadata” ledger within the blockchain network solely for thepurpose of recording the log data, and other approaches.A key requirement is that the log entries be accessible (i.e. readable) to the recovery-gateway. Astandardized API to write to (read from) the log should be defined, where the implementationof the log mechanism (behind the API) can be a local construct [58]. • Secure channel re-establishment : A recovery gateway must establish a secure channel withits peer remote gateway in order to complete the the gateway protocol (asset movement)session. If the recovery gateway is the same device as the original primary gateway (i.e.self-healing node), then depending on the secure channel protocol (e.g. TLS, IPsec, etc.) andits configuration the recovery gateway may be able to resume the secure channel (i.e. TLSsession resumption). However, if the recovery gateway is different device from the originalgateway, then a new secure channel must be created with the remote peer gateway.
The ability for a gateway G1 (fronting blockchain B1) to discover its peer gateway G2 (frontingblockchain B2) is closely related to the current fundamental challenge of VASP discovery in thevirtual assets industry [37].More broadly, the issue of originator and beneficiary discoverability is relevant from the TravelRule compliance perspective [59] because an Originator-VASP must obtain and validate the personaldata of the beneficiary and the legal status of the Beneficiary-VASP prior to transmitting assetsto the beneficiary. Compliance to the funds Travel Rule has been the norm for the banking sector and correspondent banking since the Bank Secrecy Act of 1996 (BSA - 31 USC 5311-5330). Notonly do VASPs – such as crypto-exchanges – need to comply to the Travel Rule, they also havethe additional burden related to proving control over private-keys [60], which are the means tocontrol virtual assets on a blockchain network. Thus, the discoverability of VASPs and their legalstatus permits the question of the legal ownership of gateway nodes (and control over gateways)to be answered more succinctly at all three planes of the asset movement paradigm summarizedpreviously in Figure 4.The following is a short list of some of the challenges and requirements related to the problemof the discoverability of gateways at a global scale. For gateway G1 to discover the correct gatewayG2 (and its protocol endpoints), we assume that the decision to perform the asset movement (fromthe originator in B1 to the beneficiary in B2) has been taken at the value plane. • Persistent global identifier for gateway devices : In order for one gateway to discover another,each gateway device must have (be assigned) a persistent identifier that is globally unique andwhich survives crashes and re-starts. The gateway identifier must be independent from thenetwork addressing mechanism (i.e. IP address) of the gateway device, because network-layeraddresses may change. It must also be independent from the identity public/private key-pairsbecause these keys maybe replaced over time (e.g. aging keys being archived). The gatewayidentifier could be initially cryptographically derived from its keys (e.g. see [61]), but itsusage must not be dependent on the existence of the keys. The persistency of the identifieris needed also from a regulatory audit perspective, where past logs may refer to a gatewayidentifier and the gateway owner even though the gateway may no longer be operational(e.g. dead hardware).There are several persistent-identifier assignment paradigms that can be adopted, such asthe DOI [62], KERI [63], and hardware-derived identifiers (e.g. derived from EK public-key ofTPM hardware [43, 64], derived from hardware key “latches” [65, 66], etc.). • Binding between gateway identifier and network-layer address : There needs to be a mechanismto bind the persistent gateway identifier with network-layer address of the gateway (i.e. IPaddress).Example mechanism include using DNS/DNSSEC records [67–69], Handle system records [70–72], DID data structures [73], X.509 certificates, and others. Approaches such as the VASPDirectory proposal of [37] can be augmented to include the identifiers of gateways owned byeach VASP in the ecosystem. • Resolver services : Corresponding to the binding between the gateway identifier and network-layer address, there needs to be matching resolver services that can “map” from a gatewayidentifier to its current IP address. Examples of resolver services include DNS/DNSSEC [67–69], Handle system [72], and others.
In this section, we discuss a number of topics relating to gateways, potential variations of thegateway architecture, and the use of external constructs – such as a witness blockchains – toprovide greater flexibility to the basic gateway model defined in Section 3.
There has been several authors who have pointed out the benefit of a public witness blockchain thatacts purely as an append-only blockchain that can carry any data of fixed length and which can lockchain Gateways, Bridges and Delegated Hash-Locks 19 be “written to” by anyone (e.g.see [23, 74, 75]. Indeed, this idea harks back to the purpose of therudimentary hash-chain model by Haber and Stornetta in 1991 [13, 14], which included the periodicprinting in a local newspaper of the roots of hash-tree (e.g. hexadecimal strings). Thus, the mainpurpose of such a witness blockchain is to act as a decentralized notarization service, where pairsof
We define a blockchain bridge as a partial gateway in a private blockchain network that is authorizedto expose (export) a number of data elements from its interior ledger under the authorization of auser (e.g. originator) in the context of a cross-chain asset movement initiated by the user. Thus, abride node provides an information conduit function only, and not a transactional function in thesense of a full gateway. Unlike a full gateway, a bridge node can only read from (not write to) itsinterior ledger.In the context of a cross-blockchain asset movement, a bridge node may be utilized by anoriginator (Alice) to provide evidence to an external entity (e.g. beneficiary Bob) regarding theoriginator’s ownership of a given asset, without giving the beneficiary access to the private ledger.Such evidence may be needed before the first phase of the gateway protocol (Section 4.1) commences.Since the originator (e.g. user) maybe prohibited by the governance of the private blockchain (e.g.consortium) to share ledger data with external entities, the bridge construct is one way to implementthe authorized sharing of redacted transaction data from the ledger with a specified external entity(such as the beneficiary). The location of the exported ledger-data should be pre-approved by thegovernance of the private blockchain, and could include a public witness blockchain (Section 6.1).Several mechanism can be used to elect the bridge node, including a consensus protocol instance.
Fig. 7. The notion of a public witness blockchain
Using the example of the preparation for a cross-blockchain asset movement from Alice (origina-tor) to Bob (beneficiary), the following are some tasks of a bridge node: • Redaction of transaction data : The bridge node must remove certain fields of informationthat may disclose information regarding other interior entities unrelated to the currentcross-blockchain asset movement.For example, if the past transaction history on the ledger L1 indicates that the last localasset movement was from Charlie’s public-key to Alice’s public-key (signifying that Alice isnow the current holder of the asset), then the bridge node must redact (remove) Charlie’spublic-key from the information it will export. This is because Charlie’s public-key has nobearing to the current the cross-blockchain asset movement from Alice in blockchain B1 toBob in blockchain B2.In the case that the local ledger L1 in blockchain B1 is protected using data encryptiontechniques (e.g. Zero-Knowledge Proof schemes [78], or encrypted private channels [79])then the bridge node must first decipher the relevant block/transaction before redacting it(assuming it has the capability and keys to decrypt these). • Encryption of exported data : In order to protect the privacy of the information being exported(e.g. the fact of Alice in blockchain B1 being the current asset owner), the bridge node canapply encryption to the data prior to exporting to a public witness blockchain.For example, the exported data could be encrypted to the beneficiary’s public-key on thewitness blockchain, permitting only the beneficiary to view the data. • Retain authorization tokens : The owner of a bridge node (i.e. VASP) must be protected againstfuture disputes from a dishonest originator (e.g. Alice repudiates the authorization to exporther ledger-data). Thus, the bridge node must also retain and archive the authorization-token(e.g. OAuth2.0 tokens [80, 81]) used by the originator to authorize the bridge node. lockchain Gateways, Bridges and Delegated Hash-Locks 21
Fig. 8. Overview of a delegated remote hash-lock by a gateway
The topic of user authorization and consent for a bridge node to export ledger data is beyond thescope of the current work, and will be treated in future work.
One potential function that can be implemented by a gateway is accessing a
Hash Time LockContracts (HTLC) – commonly referred to as “hash-lock” [26] smart contracts – at a third-partyremote blockchain (denoted as B4 in Figure 8) to which the gateway has access. This approach maybeuseful for cases involving fungible assets in which the cross-blockchain movement involves theexchange of value to a common denomination (e.g. fiat-backed stablecoin) occurring simultaneouslyat remote blockchain B4. A hash-lock [26] is defined as ℎ = 𝐻 ( 𝑠 ) where 𝐻 is a strong cryptographichash function and 𝑠 is the secret to unlock it within the duration time 𝑡 ℎ . A hash-lock can beimplemented using a smart contract on a blockchain system which enforces the timeout 𝑡 ℎ .The process of adding a remote hash-lock to the gateway protocol is summarized in Figure 8,where a hash-lock smart contract HL4 is assumed to be located at a “remote” blockchain B4. Thehash-lock construct is assumed to be located at B4 because under the opaque ledgers principle(Section 3.3) the blockchains B1 and B2 are inaccessible to external parties. Thus, even if B1 hadsmart-contract capabilities to implement a hash-lock, it will only be readable (i.e. can be invoked)by entities in B1 only (and vice versa for blockchain B2). We refer to such remote hash-locks as“delegated” hash-locks because it is in essence a delegated authorization from the originator (Alice)to the owner of gateway G1 (namely the VASP entity V1) to have G1 invoke the smart contracthash-lock on B4. The blockchain B4 with ledger L4 is assumed to be read/write accessible to G1and G2, which operate under the control of VASP entities V1 and V2 respectively.Delegated hash-locks may play an important role is assisting in the movement of fungible assetfrom one private blockchain to another private blockchain. In the example of Figure 8, blockchainB4 may implement a stablecoin (or CBDC) denomination that is acceptable to the VASP V1 (ownerof gateway G1) and to VASP V2 (owner of gateway G2). The joint-execution by G1 and G2 of The Merriam-Webster dictionary defines fungible as being something (such as money or a commodity) of such a naturethat one part or quantity may be replaced by another equal part or quantity in paying a debt or settling an account. the gateway protocol at the mechanical plane – that moves the fungible asset representation fromblockchains B1 to B2 – must accompanied in parallel with the transfer of value at the value plane.Thus, looking at Figure 8, there is in fact two parallel flows occurring (one flow in the mechanicalplane and one flow at the value plane). The role of the gateway is thus to inter-link or “unite” thesetwo flows so that consistency is achieved at both planes. These two unidirectional flows mustbe synchronized in order to achieve consistency in both ledger without any loss of value (otherthan perhaps some transaction fees). The need for a stable and common value denomination istherefore crucial not only in our current case of a unidirectional asset movement, but it is also coreto the concept of bidirectional atomic swaps and deals [74] where the mediating denominationmust remain unchanged (non-fluctuating) during the entire swap [82]. This is one reason why theBitcoin cryptocurrency [83–85] cannot be a mediating denomination for atomic swaps . A similarlimitation appears to be true also for ethers [86, 87] in the Ethereum platform [88].The basic idea is for G1 to use the hash-lock HL4 as means to ensure that gateway G2 (i.e.VASP V2) obtains payment in the form of stablecoins in B4 prior to gateway G2 regenerating theasset representation at blockchain B2. Using hash-lock HL4, the gateway G1 locks 𝑋 number ofstablecoins to the address of G2 within blockchain B4. This is shown as Step (a) in Figure 8. Theamount 𝑋 is the equivalent value of Alice’s fungible asset in B1 being moved to Bob at blockchainB2. If gateway G2 fails to regenerate the asset representation at B2 (as visible to Bob) before thetime 𝑡 ℎ expires, the stablecoins in B4 reverts back to G1 (i.e. VASP V1).During the joint execution of the gateway protocol (see Figure 3), the gateway G1 must indicate togateway G2 that the stablecoins have been put-aside (hash-locked) for G2 at the remote blockchainB4. This message can be included in Step 3 (escrow evidence) of Phase 2 of Figure 3, which willmotivate G2 to complete the execution of the gateway protocol. Since G2 has access to ledger L4 atblockchain B4, it can see (read) the complete smart contract HL4 and the fact that an instance ofHL4 has been invoked by G1 with the stablecoins addressed to G2 (to be released upon input of thesecret 𝑠 ).Towards the end of Phase 3 of the gateway protocol execution, the gateway G1 delivers the secret 𝑠 to gateway G2 to permit gateway G2 (VASP V2) to receive the stablecoins at blockchain B4. Thisis shown as Step (b) and Step (c) in Figure 8. Upon receiving the stablecoins at B4 the gateway G2issue (regenerates) the virtual asset on ledger L2, assigned to Bob’s public-key at B2. This release ofthe secret 𝑠 can be incorporated into the gateway protocol, such as within Step 9 (commit final) ofFigure 3. This permits gateway G2 to regenerate the asset in ledger L2 in Step 10 of Figure 3.It is important to note that there is always the chance that VASP V2 (gateway G2) is dishonestand purposely fails to regenerate the virtual asset in ledger L2 at blockchain B2, despite havingreceived payment of 𝑋 units of stablecoins via the hash-lock at the remote blockchain B4. In such acase, gateway G1 can dispute this dishonest behavior by using the fact that (a) the gateway G2 hadissued the signed prepare-commit message in Step 7 of Phase 2 of Figure 3, and (b) the evidence onledger L4 in blockchain B4 that gateway G2 has received a payment of 𝑋 number of stablecoins. If blockchain technology is to be a foundational infrastructure for the future global virtual assetsindustry, then the currently nascent industry needs to begin addressing the challenges aroundblockchain interoperability. In the current we have discussed the need for blockchain gatewaysas a means to achieve interoperability across different blockchain networks, and to support thecross-blockchain mobility of virtual assets. Putting it in another way, “Bitcoin has no value, and hence it can have any price” [82]. lockchain Gateways, Bridges and Delegated Hash-Locks 23
One key component for interoperability is the well-designed architecture for gateway nodes thatinterconnect the various blockchain networks, based on standardized APIs and gateway protocols.We discuss some of the design principles for gateways, notably under the strict condition wherethe origin blockchain and the destination blockchain are both private/permissioned.Another key ingredient is a standard gateway-to-gateway protocol that implements the move-ment of virtual assets from one blockchain to another satisfying the classic ACID properties(atomicity, consistency, isolation and durability). We discuss an example of a gateway protocolfor the unidirectional movement of assets, following the classic 2-Phase Commit paradigm. Theunidirectional protocol can be used as a building-block to achieve “atomic swaps” across two privateblockchain systems.Finally, we discuss several aspects of gateway deployments, including gateway identities andcertificates, gateway crash recovery, and the problem of the discoverability of gateways at a globalscale.
REFERENCES [1] T. Hardjono, A. Lipton, and A. Pentland, “Towards an Interoperability Architecture Blockchain AutonomousSystems,”
IEEE Transactions on Engineering Management
IEEE Transactions on Communications ,vol. 22, pp. 637–648, 1974.[5] D. Clark, “The Design Philosophy of the DARPA Internet Protocols,”
ACM Computer Communication Review – ProcSIGCOMM 88 , vol. 18, no. 4, pp. 106–114, August 1988.[6] D. D. Clark,
Designing an Internet . MIT Press, 2018.[7] R. Perlman,
Interconnections: Bridges, Routers, Switches, and Internetworking Protocols . Addison-Wesley, 1999.[8] K. Lougheed and Y. Rekhter, “Border Gateway Protocol (BGP),” June 1989, IETF Standard RFC1105. [Online]. Available:http://tools.ietf.org/rfc/rfc1105.txt[9] R. Auer, G. Cornelli, and J. Frost, “Rise of the Central Bank Digital Currencies: Drivers, Approaches andTechnologies,” Bank for International Settlements, BIS Working Papers - No 880, August 2020. [Online]. Available:https://ssrn.com/abstract=3711458[10] T. Hardjono, A. Lipton, and A. Pentland, “Interoperability of Distributed Systems,” April 2020, to appear in
Building theNew Economy (MIT Press 2021).[11] R. Yavatkar, D. Pendarakis, and R. Guerin, “A Framework for Policy-based Admission Control,” January 2000,IETF Standard RFC2753. [Online]. Available: https://tools.ietf.org/rfc/rfc2753.txt[12] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero Trust Architecture,” National Institute of Standards andTechnology, NIST Special Publication 800-207, August 2020. [Online]. Available: https://doi.org/10.6028/NIST.SP.800-207[13] S. Haber and W. Stornetta, “How to Time-Stamp a Digital Document,” in
Advances in Cryptology - CRYPTO’90 (LNCS537) , 1991, pp. 437–455.[14] 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.[15] 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.[16] T. Hardjono, M. Hargreaves, and N. Smith, “An Interoperability Architecture for Blockchain Gateways,” IETF,Internet-Draft draft-hardjono-blockchain-interop-arch-01, October 2020. [Online]. Available: https://datatracker.ietf.org/doc/draft-hardjono-blockchain-interop-arch/[17] 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[18] D. Harkins and D. Carrel, “The Internet Key Exchange (IKE),” November 1998, IETF Standard RFC2409. [Online].Available: http://tools.ietf.org/rfc/rfc2409.txt [19] D. Maughan, M. Schertler, M. Schneider, and J. Turner, “Internet Security Association and Key Management Protocol(ISAKMP),” November 1998, IETF Standard RFC2408. [Online]. Available: https://tools.ietf.org/rfc/rfc2408.txt[20] D. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” August 2018, IETF Standard RFC8446. [Online].Available: https://tools.ietf.org/html/rfc8446[21] K. A. McKay and D. A. Cooper, “Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS)Implementations,” National Institute of Standards and Technology, NIST Special Publication 800-52 Revision 2, August2019. [Online]. Available: https://doi.org/10.6028/NIST.SP.800-52r2[22] P. Ezhilchelvan, A. Aldweesh, and A. van Moorsel, “Non-blocking two phase commit using blockchain,” in
Proceedingsof 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[23] V. Zakhary, D. Agrawal, and A. E. Abbadi, “Atomic Commitment Across Blockchains,” June 2019. [Online]. Available:https://arxiv.org/pdf/1905.02847.pdf[24] M. Herlihy, “Atomic Cross-chain Swaps,” in
Proceedings of the ACM Symposium on Principles of Distributed ComputingPODC’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[25] A. Zamyatin, D. Harz, J. Lind, P. Panayiotou, A. Gervais, and W. Knottenbelt, “XCLAIM: Trustless, Interoperable,Cryptocurrency-Backed Assets,” in . IEEE, May 2019, pp. 193–210.[Online]. Available: https://doi.org/10.1109/SP.2019.00085[26] T. Nolan, “Alt chains and atomic transfers,” May 2013. [Online]. Available: https://bitcointalk.org/index.php?topic=193281.msg2224949
Very Large Data Bases – Proceedings of the 7thInternational Conference , Cannes, France, September 1981, pp. 144–154.[28] 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.[29] M. T. Ozsu and P. Valduriez,
Principles of Distributed Database Systems (4th Ed.) . Springer, Switzerland, 2020.[30] T. Hardjono and N. Smith, “Decentralized Trusted Computing Base for Blockchain Infrastructure Security,”
Frontiers Journal - Special Issue on Finance, Money & Blockchains
Coindesk
ESORICS 2020Interdisciplinary Workshop on Trust, Identity, Privacy and Security in the Digital Economy , ser. Lecture Notes inComputer Science, I. Boureanu, C. C. Dragan, and M. Manulis, Eds., vol. 12580. Springer, 2020, pp. 74–91. [Online].Available: https://arxiv.org/abs/2008.05048[37] D. Jevans, T. Hardjono, J. Vink, F. Steegmans, J. Jefferies, and A. Malhotra, “Travel Rule InformationSharing Architecture for Virtual Asset Service Providers,” TRISA, Version 7, June 2020. [Online]. Available:https://trisa.io/wp-content/uploads/2020/06/TRISAEnablingFATFTravelRuleWhitePaperV7.pdf[38] A. Sardon, T. Hardjono, and B. Schuppli, “Asset Profile Definitions for DLT Interoperability,” IETF, Internet-Draft draft-sardon-blockchain-interop-asset-profile-00, December 2021. [Online]. Available: https://datatracker.ietf.org/doc/draft-sardon-blockchain-interop-asset-profile/[39] M. Hargreaves and T. Hardjono, “Open Digital Asset Protocol,” IETF, Internet-Draft draft-hargreaves-odap-01,November 2020. [Online]. Available: https://datatracker.ietf.org/doc/draft-hargreaves-odap/[40] US Congress, “Electronic signatures in global and national commerce act,” June 2000.[41] N. Smith (ed), “TCG Attestation Framework,” Trusted Computing Group, TCG Draft Specification – Version 1.0,November 2020. lockchain Gateways, Bridges and Delegated Hash-Locks 25
Security In Wireless LANS And MANS
Journal of FinTech , vol. 1, no. 1, 2020, available at https://arxiv.org/pdf/1909.08607.[Online]. Available: https://doi.org/10.1142/S2705109920500017[61] T. Aura, “Cryptographically generated addresses (cga),” March 2005, RFC3972. [Online]. Available: http://tools.ietf.org/rfc/rfc3972.txt[62] R. Kahn and R. Wilensky, “A framework for distributed digital object services,”
D-Lib Magazine [66] TCG, “Hardware Requirements for a Device Identifier Composition Engine,” Trusted Computing Group, TCGPublished Specifications - Family 2.0, March 2018. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf[67] J. Schlyter and W. Griffin, “Using dns to securely publish secure shell (ssh) key fingerprints,” January 2006, RFC4255.[Online]. Available: http://tools.ietf.org/rfc/rfc4255.txt[68] M. Delany, “Domain-based email authentication using public keys advertised in the dns (domainkeys),” May 2007,RFC4870. [Online]. Available: http://tools.ietf.org/rfc/rfc4870.txt[69] D. Crocker, T. Hansen, and M. Kucherawy, “Domainkeys identified mail (dkim) signatures,” September 2011, RFC6376.[Online]. Available: http://tools.ietf.org/rfc/rfc6376.txt[70] S. Sun, L. Lannom, and B. Boesch, “Handle System Overview,” November 2003, RFC3650. [Online]. Available:http://tools.ietf.org/rfc/rfc3650.txt[71] S. Sun, S. Reilly, and L. Lannom, “Handle System Namespace and Service Definition,” November 2003, RFC3651.[Online]. Available: http://tools.ietf.org/rfc/rfc3651.txt[72] S. Sun, S. Reilly, L. Lannom, and J. Petrone, “Handle system protocol (ver 2.1) specification,” November 2003, RFC3652.[Online]. Available: http://tools.ietf.org/rfc/rfc3652.txt[73] D. Reed and M. Sporny, “Decentralized Identifiers (DIDs) v0.11,” W3C, Draft Community Group Report 09 July 2018,July 2018, https://w3c-ccg.github.io/did-spec/.[74] 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[75] A. Lipton, T. Hardjono, and A. Pentland, “Digital Trade Coin (DTC): Towards a more stable digital currency,”
Journalof the Royal Society Open Science (RSOS)
Proceedings of the European Symposium on Research in Computer Security (ESORICS2018) .Springer, 2018, pp. 111–131.[80] T. Hardjono, E. Maler, M. Machulak, and D. Catalano, “User-Managed Access (UMA) Profile of OAuth2.0 – SpecificationVersion 1.0,” Kantara Initiative, Kantara Published Specification, April 2015, https://docs.kantarainitiative.org/uma/rec-uma-core.html.[81] T. Hardjono and E. Maler, “Blockchain and Smart Contracts Report,” Kantara Initiative, Report, June 2017,https://kantarainitiative.org/confluence/display/BSC/Home.[82] A. Lipton and A. Treccani,
Blockchain and Distributed Ledgers: Mathematics, Technology and Economics . WorldScientific Publishing, Singapore, 2021.[83] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf[84] J. M. Griffin and A. Shams, “Is Bitcoin Really Un-Tethered?”
SSRN , November 2019. [Online]. Available:http://dx.doi.org/10.2139/ssrn.3195066[85] O. Godbole, “Bitcoin Transaction Fees Rise to 28-Month High as Hashrate Drops Amid Price Rally,”
Coindesk
Cointelegraph ,September 2020. [Online]. Available: https://cointelegraph.com/news/using-a-defi-protocol-now-costs-more-than-50-as-ethereum-fees-skyrocket[87] Z. Voell and W. Foxley, “Decentralized Finance Frenzy Drives Ethereum Transaction Fees to All-Time Highs,”