Interoperable blockchain system design concept

This paper introduces and reviews a paper Towards a Design Philosophy for Interoperable blockchain Systems. Interested readers can use the hyperlink to view the paper.

Once upon a time the Internet and the Internet allowed carefully managed clusters of computers to communicate with each other. Later, the “I” was capitalized, infusing the Internet with a design principle that devices from all over the world should interoperate. Like many people, I often think about the similarities between networks and blockchains, as well as between the Internet and what we call ‘the Blockchain’ (capital ‘B’). In today’s selected paper, Hardjono et al. delve deeper into this issue, reviewing their experience with Internet design concepts and exploring how to create a blockchain infrastructure that supports interoperability. Some of these lessons have been included in the MIT Tradecoin project.

We believe that if blockchain technology is to become a fundamental part of the future distributed network of global commerce and value, then its architecture must also meet the same fundamental goals as the Internet architecture.

Internet Design Concept

This part of this article is taken from The abstract of SIGCOMM 1988 “The Design Philosophy of The DARPA Internet Protocols”. DARPA envisioned three basic goals for the Internet at the time:

1. Survivability: Internet communication must be able to continue even if a single network or gateway is lost.

2. Ability to support multiple types of communication services (different rates, delays, and reliability requirements)

3. Ability to access and integrate many different networks

In addition, the end-to-end principle is the core principle for determining the assignment of functional responsibilities, which solves the problem of “whether the responsibility should be borne by the network or the application of the network endpoint”. A classic example is end-to-end encryption, which distributes responsibility to network endpoints due to the need for multi-party communication.

The Internet is organized as a collection of autonomous systems (routing domains) connected by peer-to-peer protocols. Autonomous Systems (ASs) are owned and operated by legal entities. All routers and related devices have unique identifiers in the same domain name. Domain names interoperate through gateways (for example, BGP).

Blockchain design concept

We think the issue of survivability is as important as the issue of privacy and security. Therefore, interoperability between blockchain systems will be a core requirement (both at the machine level and at the value level) if blockchain systems and technologies are to become a critical infrastructure for the future global economy.

.

The authors define an interoperable blockchain architecture with the following characteristics:

• It consists of distinguishable blockchain systems, each representing a distributed data ledger

• Transactions can be executed across multiple blockchain systems

• Data recorded in a blockchain can be accessed and validated in a semantically compatible manner by another possible external transaction

Persistence is defined at The application level of transactions: transactions can be completed even if some part of The Blockchain network is damaged.

Application-level transactions can consist of multiple ledger level transactions (subtransactions) and may involve multiple different blockchain systems (for example, asset transfer subtransactions, payment subtransactions, and tax subtransactions).

(Are we reinventing XA?) (Proofread: XA probably stands for X/Open XA, a distributed transaction specification.)

Validation of sub-transactions on an extended blockchain system is opaque to user applications, just as packets over multiple routing domains are opaque to communications applications.

In the Event of Failure, many questions are raised about the concept of persistence and blockchain substitution, for example, to what extent an application needs to know about the functionality and design of a single blockchain system, and how responsibility for maintaining reliability should be allocated (e.g., resend transactions). What should be done when a smart contract cannot be invoked or completed because the blockchain system on which it is based cannot be accessed? Can smart contracts be transferred between blockchains? Should The information on The Blockchain on which The contract is currently located be opaque to The application (i.e., give each Blockchain an “IP” address that is valid across The entire Blockchain network -The Blockchain-)? How do we know when inter-chain migration of contracts will be triggered?

The goal of the Internet is to support many types of services with different needs; In blockchain networks, this goal can be reinterpreted to support a variety of blockchain systems with different consensus algorithm, throughput, and latency characteristics. (We may also add security and privacy features).

When it comes to needing access to many different blockchain systems, we want to be able to support cross-chain transactions operated (or initiated) by different entities. On the Internet,

The concept of value is a layer above blockchain transactions (just as the Internet separates the mechanical transmission of packets from the value of the information contained in them). For the need to transfer value across chains (

InterLedger Protocol

Tradecoin

MIT Tradecoin

The project has many goals, one of which is to develop a blueprint model of an interoperable blockchain system that can be applied to multiple usage scenarios.

Essentially, there are two different levels of interoperability: the mechanical level of interoperability and the value level of interoperability (including structures considered valuable in the human world).

Statutory trust (

Legal trust is a bridge connecting the mechanical layer and the value layer. That is, technical trusts and statutory trusts enable real-world participants to quantify and manage transaction risks occurring at the mechanical level, thereby supporting business trusts (at the value level). Realizing the technical standardization of technology trust Promotes the standardization of legal contracts (i.e. legal trust frameworks), thus reducing the overall business cost of operating autonomous systems.

(Not only that, it also provides the trust businesses need to trade value on the blockchain.)

The Tradecoin project treats individual blockchain systems as fully autonomous and connects them through gateways. Gateways ensure value stability, accessibility and transaction intermediation for cross-domain transactions.

To support reachability, a gateway needs to be able to resolve identifiers and provide NAT-like functionality to translate internal and external identifiers. Regarding transaction intermediaries, in the design of Tradecoin, gateways seem to act as transactions

Since blockchain BC1 and BC2 require authorized access, ledger information cannot be seen from one side of the blockchain and the gateway for each blockchain must “guarantee” that transactions have been confirmed on their respective ledgers. That is, the gateway must publish legally binding signature assertions and be responsible for error reporting (intentionally or unintentionally). The signature is issued by a single gateway, or collectively signed by all gateways in the blockchain system.

In order for the above process to work, there are five desirable characteristics:

1. Applications that initiate and receive transactions must be able to independently verify that the transaction has been confirmed on their respective blockchains.

2. Regardless of the gateway selection mechanism chosen, gateway signatures must be bound.

3. There need to be multiple reliable “paths” (gateways) between any two blockchain systems.

4. Identifiers must have a global interpretation mechanism so that they can always be interpreted to the correct authorized blockchain system.

5. Gateways must be recognizable (that is, not anonymous) within or between domain names.

   “Gateways must be able to authenticate each other in their
   identity
   ,
   Legal ownership
   ,
   Or that they uniquely represent the ‘home’ blockchain autonomous system
   .”

Gateways are connected by a peer-to-peer protocol:

With regard to blockchain system interoperability, concepts similar to peer-to-peer protocols must be specified:


(I) define the semantic compatibility required for cross-domain transactions between the two blockchains;


(ii) Identify specific cross-domain protocols required;


(iii) Determine the entrustment and technology trust mechanism to be used;


(iv) Define peer service legal agreements (e.g., service levels, transaction fees, penalties, liabilities, warranties). It is worth noting that in the Tradecoin interoperability model, the gateway of the blockchain system represents the base-point of the blockchain at flag.

In the absence of a clearly defined legal entity associated with the blockchain, the above requirement (IV) seems problematic.

The original link: https://blog.acolyer.org/2018/05/30/towards-a-design-philosophy-for-interoperable-blockchain-systems/ author: adriancolyer Stormpang & sword articles: the etheric fang lovers (https://ethfans.org/posts/towards-a- design - point - for - interoperable - blockchain - systems)Copy the code