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].
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].
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]:
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.
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.
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:
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.
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.
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.
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:
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:
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:
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:
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.
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:
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].
There are several design principles for blockchain gateway-to-gateway interoperability, with two key principles being the following [34]:
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]).
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.
There are a number of functional requirements for cross-chain transfers of virtual assets between two blockchain systems or domains [34]:
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].
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:
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.
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:
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.
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:
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:
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.
