Surveillant: a supervision mechanism between blockchains for efficient cross-chain verification

Abstract

Blockchain interoperability, which refers in particular to the ability to access information across blockchain systems, plays the key role for different blockchains to communicate with each other, and further supports the superstructure built on top of the cross-chain mechanism. Nowadays, blockchain interoperability technology is still in its infancy. The existing cross-chain scheme such as BTCRelay requires that the smart contract in a blockchain to download and maintain block headers of the other blockchain, which is costly in maintenance and inefficient to use. In this paper, we propose a supervision mechanism between blockchains, called Surveillant. Specially, the new entities called dual-functional nodes are introduced to commit the real-time information from the blockchain under supervision to the supervising blockchain, which enables users to have efficient cross-chain verification. Furthermore, we introduce Merkle mountain range for blocks aggregation to deal with the large-scale committing data. We propose the design of long orphan branch counter to trace the bifurcations in the blockchain under supervision. The existing incentive mechanism is improved to encourage the behaviors of dual-functional nodes. In Surveillant, the analysis and experimental results demonstrate that users are able to have efficient cross-chain verification with low maintenance overhead.

1. Introduction

In recent years, we have witnessed the rapid development of blockchain technology. Researchers have made considerable effort to improve the performance of blockchain, such as more efficient consensus protocols [1], better privacy protection [2], improving throughput by state channels [3] and sharding protocols [4]. Based on the works above, Blockchain has been widely used in various fields, such as the payment platform [5], smart contract [6], privacy preserving [7], etc.

Although the number and variety of blockchain applications are increasing, these applications remain mutually isolated, in which each blockchain only operates within its own ecosystem. Subsequently, a new demand of achieving blockchain interoperability [8] has naturally emerged. It requires to establish a secure and practical cross-chain mechanism to transfer information across blockchains. By this mechanism, different blockchain systems begin to communicate with one another to form a blockchain web, which is invaluable for next generation blockchain technology [9].

Illustrated by Vitalik Buterin [9], the existing research on blockchain interoperability can be classified into three categories, which are notary scheme, hash-locking, and chain relay. First, in the notary schemes [10], the information is transferred between blockchains by a trusted third party, which has potential security vulnerability. Second, the hash-locking [11] is adopted to ensure the atomicity [12] of the operations on different blockchains. However, in this scheme, the information transferred between blockchains is very limited, which cannot support complex cross-chain operations. Third, in the chain relay schemes [13] [14], the smart contract in the first blockchain will receive and maintain the SPV proof of the second blockchain delivered by a group of relayers. It enables programmatic public cross-chain verification, which has the advantages in security and functionality compared with the notary scheme and hash-locking.

However, the existing chain relay schemes still suffer from several drawbacks as follows. First, as the chain relay schemes require to maintain the SPV proof of the other blockchain, it is comparable to that the smart contract additionally maintain a light client of the other blockchain, which is costly in maintenance and inefficient to use. Second, as a blockchain includes thousands or millions of blocks, how to commit the large-scale blocks across blockchains becomes a problem. Moreover, because blockchain has a dynamic changing data structure, a block having been included in the blockchain before has the possibility to be orphaned in a future time, which brings the problem such as double-spending. It requires an efficient retrieval mechanism for a blockchain to supervise the orphan branches in the other blockchain, which ensures that the bifurcation in the other blockchain can be detected in time.

In this paper, to overcome the above issues, we propose a supervision mechanism between blockchains, called Surveillant, which includes three protocols: listen, record, and query. In protocol: listen, we introduce new entity called dual-functional node D^𝑆. D^𝑆 listens for the latest state of the blockchain ℛ under supervision, and maintains its real-time data. In protocol: record, D^𝑆 generates new block for the supervising blockchain 𝒮. A commitment of the real-time data of ℛ will be recorded into the 𝒮 block. By the recording process, 𝒮 and ℛ achieve blockchains synchronization, which is further illustrated in Section 6. In protocol: query, a user using an 𝒮 client U^𝑆 is able to have cross-chain verification to ℛ by using the synchronization between 𝒮 and ℛ. The cross-chain verification can be as nearly efficient as the verification to the local transactions in 𝒮.

In summary, we make the following contributions:

1. We propose a supervision mechanism between blockchains. In this mechanism, new entities called dual-functional nodes are introduced to listen for the blockchain under supervision, and record the real-time commitment of it into the supervising blockchain, achieving a blockchain synchronization. Through this design, a user is able to have cross-chain verification effectively.

2. To process the large-scale blocks in the blockchain under supervision, we introduce Merkle mountain range for blocks aggregation to cut down the storage overhead. To trace the bifurcations in the blockchain under supervision, we propose the design of LOBCounter for efficient orphan branch retrieval. Moreover, the existing incentive mechanism is improved to encourage the behaviors of dual-functional nodes.

3. We analyze the security, time delay, and overhead of Surveillant in theory. Moreover, we implement a proof-of-concept prototype and evaluate the performance of Surveillant in practice.

This paper is organized as follows. In Section 2, we have a discussion about the existing schemes for blockchain interoperability. In Section 3, we review the preliminary knowledge related to our following design. We have a description about the system model, threat model, and design goals in Section 4. We have a design to the framework of Surveillant in Section 5, describe the details of blockchain synchronization in Section 6, and further analyze its security and performance of in Section 7. In Section 8, we describe the simulation experiment of Surveillant, and evaluate the result by comparing it with other schemes. Finally, we conclude in Section 9.

2. Related Work

The existing schemes for blockchain interoperability can be classified into three categories, which are notary scheme, hash-locking scheme, and chain relay scheme. In the notary scheme [10], the blockchain information is transferred by a trusted notary group, which has potential security vulnerability.

In the hash-locking scheme [11], the operations in two blockchains are sealed by the same hash lock in advance. The operations can be triggered in the same time by revealing the preimage of the hash lock, or none of the operations can be executed, which ensures the atomicity. By virtue of this property, the hash-locking scheme has been adopted in atomic cross-chain swap [12]. However, the drawback of the scheme is that the information carried by the preimage is very limited. It results that the hash-locking scheme cannot support the complex cross-chain operations which require to transfer concrete state information of a blockchain.

In the chain relay scheme such as the Ethereum project BTCRelay [13], a group of relayers, which act as the intermediaries, deliver every block header of Bitcoin to the smart contract of Ethereum. Hence, the smart contract provides the functionality comparable to a Bitcoin light client. First, based on the smart contract, the users of Ethereum are able to verify the transactions in Bitcoin, which achieves a cross-chain transaction verification. Second, because the block headers in the smart contract include the complete proof-of-work of Bitcoin, the validity of the block headers can be proved by the proof-of-work itself, which removes the dependence to trust the intermediary. For these advantages, chain relay scheme has broader application space.

In the following work, XCLAIM [14] achieves trustless cross-chain exchanges by using chain relay scheme. The cross-chain protocols in XCLAIM require a publicly verifiable audit log of user actions on both blockchains, in which the chain relay scheme plays an essential role in cross-chain verification. However, as the smart contract still has to maintain every block header of the other blockchain, the overhead of XCLAIM remains too large.

Nowadays, with the popularization of blockchain technology, the application scenario of blockchain is no longer limited to cryptocurrency, but tends to be diversified and self-organized. For example, BlocHIE [15] establishes a platform for healthcare information exchange by using two loosely-coupled blockchain. Ferrag [16] provides an overview of different application domains of blockchain technologies in internet of things, and further evaluates their security and privacy in [17]. Jiang [18] proposes a fair transaction packing algorithm for permissioned blockchain-empowered industrial IoT systems. As the different blockchain applications are built independently, one blockchain cannot guarantee the security of the other blockchain. Consequently, a corruption in a blockchain is able to influence the other blockchain if a cross-chain linking exists between them. Therefore, it is necessary for a blockchain to establish a supervision mechanism to monitor the state of the other blockchain that has a cross-chain linking with it, which prevents the exotic corruption.

3. Preliminary

3.1 Merkle Proof

In Bitcoin, the transactions in a block are aggregated by Merkle tree, and the Merkle tree root as a commitment to the transactions is recorded into the block header. In the condition when the validity of the block header has been confirmed, a given transaction in the block can be further verified by a Merkle proof (also known as SPV proof) (see Fig. 1) linking the transaction with the Merkle tree root in the header.

Fig. 1. Merkle proof. For the given data 𝐷₇ and the Merkle tree root hash 𝐻₁₅ (marked by brown), 𝐷₇ can be proved to be included in the Merkle tree if 𝐻₁₅ = 𝐻 (𝐻₇ || 𝐻(𝐻₁₀ || 𝐻(𝐻(𝐷₇) || 𝐻₁₂))). The value 𝐻₁₂, 𝐻₁₀, and 𝐻₇ (marked by dark blue) are the Merkle proof 𝛱_𝐷7^𝒯 to 𝐷₇. 𝛱_𝐷7^𝒯 are the siblings of 𝐻₁₁, 𝐻₁₃, and 𝐻₁₄ (marked by light blue), which are in the Merkle tree path linking 𝐷₇ to 𝐻₁₅.

Definition 1 (Merkle Proof). In a Merkle tree 𝒯, a Merkle proof 𝛱_𝐷𝑖^𝒯 to data 𝐷_𝑖 is the siblings of the nodes in the Merkle tree path from 𝐻(𝐷_𝑖) to 𝒯 root. The length of 𝛱_𝐷𝑖^𝒯 is at most the height of 𝒯, which equals ⌈log₂(𝑛)⌉. For the given root of 𝒯 and the 𝛱_𝐷𝑖^𝒯 of 𝐷_𝑖, the 𝐷_𝑖 is proved to be included in 𝒯 when each parent node following the Merkle tree path is recursively hashed from its two children, and the final hash equals the value of 𝒯 root.

3.2 Longest Chain Rule

Because of the network latency or intentional attack (see Section 3.3), different bookkeepers have disagreements to the current blockchain state. To deal with this problem, every honest bookkeeper adapts and mines on the longest chain, and the shorter block chains stop to grow, in which we say that the block chains are orphaned. The longest chain rule ensures that the bookkeepers distributed in the network tends to work on the longest chain maintained by the honest majority.

Definition 2 (Block chain). For any given block 𝐵_𝑗, there is only path to traverse from 𝐵_𝑗 to the genesis block 𝐵₁ in which the traversal follows the hash pointers of the blocks in the path. We define that the blocks in the path form a block chain 𝐶_𝑗. The block chain height of 𝐶_𝑗 equals 𝑗.

3.3 Orphan Block Phenomenon

Orphan block, sometimes referred to as stale block, are the block directly or indirectly pointing to a block in the longest chain, but not included in the longest chain. When several continuous orphan blocks hanging outside the longest chain, we call them an orphan branch (see Fig. 2). An orphan branch has two attributes, which are length and bifurcation point. A long orphan branch has the length exceeding the security threshold 𝜖.

Fig. 2. Block chains and orphan branches. For any given block such as 𝐵_12′, there is only path to traverse from 𝐵_12′ to the genesis block 𝐵₁. The blocks in the path form the block chain 𝐶_12′, which is marked by red. For all of the block chains in this figure, 𝐶₁₄ is known as the longest chain (For convenience, we draw only 14 blocks in the longest chain). Moreover, 𝐵_4′ is an orphan block. The orphan blocks “← 𝐵_6′ ← 𝐵_7′ ← 𝐵_8′” form an orphan branch, whose length is 3, and bifurcation point is 𝐵₅. As the honest majority of bookkeepers will adapt and mine on the longest chain, the block chain 𝐶_12′ is tending to be orphaned, in which it includes the orphan branch “← 𝐵_10′ ← 𝐵_11′ ← 𝐵_12′” at its tail end.

• The length of an orphan branch equals the number of the orphan blocks included in the branch.

• The bifurcation point is the block in the longest chain which the orphan branch points to.

The causes of orphan block can be classified into two categories, which are network latency and intentional attack.

Network Latency. Since the network latency, the transmission of a newly generated block between nodes takes time. For this reason, there is a possibility that a group of miners having not received the newly generated block still mine on the old block chain. Consequently, a bifurcation occurs to produce two branches, and one branch will be orphaned eventually. Illustrated by Christian [19], the scale of the nodes that have received the new block has high possibility to reach majority within a certain time latency. By properly setting the block generation rate [20], the orphan blocks caused by network latency will be kept in a small scale.

Lucianna [21] further indicates that the probability of a block to be orphaned drops exponentially with its confirmation increasing. We usually assert that a block is stable when its confirmation has exceeded the threshold 𝜖. In Bitcoin for example, 𝜖 usually defaults to 6 blocks.

Intentional Attack. Compared with the orphan blocks caused by network latency, the orphan blocks caused by intentional attacks are more harmful, such as selfish mining [22], bribery attack [23], and majority attack. In the selfish mining for example, a malicious mining pool intentionally keeps its mined blocks private, bifurcating the blockchain to create a secret branch. The secret branch is judiciously revealed when it takes chance to have more blocks than the public branch mining by the honest miners. Following the longest chain rule, the honest miners turn to mine on the revealed secret branch, leaving the public branch orphaned. Furthermore, the bifurcation may lead to a serial of problems, such as double-spending.

3.4 Full Node and Light Client

Full Node. A “full node” exists by default in a blockchain. The full node is responsible for verifying, storing and relaying the blocks and transactions on the network. Because of the trustless network environment and the nature of a blockchain, each full node needs to download and verify every single block, and therefore every single transaction in each block. Besides, the full node works full-time to keep tracking the state change of blockchain. Based on the functions of full node, organizations and individuals, such as miners, block explorers, and exchanges, run full nodes for their business.

Light Client. A light client, sometimes referred to as light node, is an end-user software that connects to full nodes to interact with the blockchain. Unlike the full node, light client does not need to work full-time or maintain the complete information of the blockchain. In a high level of security, a light client needs to download and verify every block header of the blockchain. To verify a certain transaction in a block, the light client will further download the Merkle proof linking the transaction to the header of the block. The overall verification process is achieved cryptographically, in which the light client does not need to trust the full node for every request.

4. Problem Statement

4.1 System Model

In Surveillant, one blockchain is able to have supervision to several blockchains in the same time. For convenience, in the following content, we discuss the only the supervision between two blockchains, which are the supervising blockchain 𝒮 and the blockchain ℛ under supervision. The blockchain ℛ is required to be public chain, in which the blockchain data of ℛ can be received by the nodes of 𝒮. If the ℛ data keeps secret like the private chain, the supervision cannot be proceeded.

First, 𝒮 has well security and stability guarantee such as Bitcoin and Ethereum. In 𝒮, the scale of nodes is large enough, which creates a relatively safe environment to resist an adversary to corrupt the majority of the nodes. For specific performance, the probability of a bifurcation of depth 𝑛 drops exponentially with 𝑛 increasing, and all transactions published by honest nodes will eventually end up at the depth more than 𝑘 blocks in the blockchain, which satisfies the property of persistence and liveness [24].

However, on the other side, the blockchain ℛ is not as well-equipped as 𝒮. The blockchains like ℛ are usually applied in various Altcoins or the other scenarios such as the applications in medical data access [15], and IoT [16]. In some of these situations, the scale of the participants in the blockchain is relatively limited, and the blockchain is lack of operation and maintenance. Therefore, we assume that blockchain ℛ is vulnerable to intentional attack, and orphan block is much easier to be created (see Section 3.3).

The blockchain system of 𝒮 includes two types of entities, which are dual-functional node D^𝑆 and client U^𝑆 (see Fig. 3).

Fig. 3. Framework of Surveillant

Dual-functional node D^𝑆. D^𝑆 is the entity that generates blocks for 𝒮, which provides the function comparable to the so-called bookkeeper [25]. Specifically, the group of D^𝑆 interconnect with one another through the peer-to-peer network; D^𝑆 receives and verifies the new blocks and pending transactions of 𝒮; D^𝑆 maintains the full blockchain data of 𝒮; D^𝑆 generates new blocks for 𝒮.

In the same time, every D^𝑆 listens for the full blockchain data of ℛ, which provides the function comparable to a listener to ℛ. Specifically, D^𝑆 establishes connections with the nodes who do not participate in 𝒮, but generate, transfer, and maintain the blockchain data of ℛ; D^𝑆 receives and verifies the new blocks of ℛ; D^𝑆 maintains the full blockchain data of ℛ. It is worth noted that D^𝑆 belongs to the entity of 𝒮 instead of the entity of ℛ, though D^𝑆 receives the information from ℛ. In this situation, D^𝑆 does not receive the pending transactions of ℛ, or generate new blocks for ℛ. Consequently, D^𝑆 does not contribute to the blockchain growth of ℛ.

Comprehensively considering the above dual functions of D^𝑆, D^𝑆 is able to listen for the information of ℛ, and record the ℛ information into 𝒮, which achieves a commitment of ℛ.

From the perspective of traditional blockchain, D^𝑆 can be treated as the conventional bookkeeper with the listening function added, which brings extra workload to the bookkeeper. For this problem, we propose the commitment reward for the extra workload. By this design, the improved incentive mechanism is able to encourage D^𝑆 to do both the works of listening and block generating, by which the information of ℛ will be committed to 𝒮 in real time.

Clients U^𝑆. U^𝑆 is the end-user software of 𝒮, in which U^𝑆 is usually the light client. The main task of U^𝑆 is to query the information in 𝒮. First, U^𝑆 will download every block header of 𝒮 from D^𝑆. To verify a specific transaction in 𝒮, the U^𝑆 needs to additionally download the Merkle proof of the transaction from D^𝑆, which is the same with the traditional SPV. To cross-chain verify a transaction in ℛ, the U^𝑆 needs to download a three-stage Merkle proof of the transaction. The three-stage Merkle proof includes the Merkle proves in 𝒮, ℛ and the Merkle mountain range between them (see Section 6 for more details). As D^𝑆 maintains both the full blockchain data of 𝒮 and ℛ, D^𝑆 is able to provide the three-stage Merkle proof. In this process, U^𝑆 does not need to access the entities other than D^𝑆.

4.2 Threat Model

We suppose an adversary is powerful enough to corrupt the blockchain ℛ. For example, in the blockchain based on Nakamoto consensus protocol, the adversary is able to control more than 1/3 [22] of the hash power of ℛ. Therefore, ℛ is vulnerable to the damages such as selfish mining, bribery attack, and majority attack. Consequently, the adversary is able to bifurcate the blockchain ℛ to orphan a branch and the length of the orphan branch has high possibility to exceed a threshold 𝜖, which brings the problem such as double-spending. On the other side, in 𝒮, we assume that the corrupted entities of 𝒮 is bounded by the security threshold, such as the corrupted hash power is bounded by 1/3 in the blockchain based on Nakamoto consensus protocol. It ensures the security including the persistence and liveness of 𝒮.

Furthermore, we assume Surveillant satisfies the following security assumptions. First, we assume the cryptographic primitives of both 𝒮 and ℛ are secure. Second, we assume that the block generation rates of 𝒮 and ℛ are upper-bounded [20], which can be achieved by periodically adjusting the difficulty targets of the two blockchains (in PoW protocol). It ensures that an adversary cannot create unlimited blocks arbitrarily. Third, we assume the blocks of 𝒮 and ℛ are broadcast in the peer-to-peer network following the information propagation model [19] [24], in which the honest majority of D^𝑆 will reach consensus to the newly generated block of 𝒮 and ℛ within the time delay 𝛥^𝑆 and 𝛥^𝑅. Fourth, we assume that a user using a client U^𝑆 is connected to at least one honest dual-functional node D^𝑆, which means U^𝑆 is not vulnerable to eclipse attack. Defending against such attacks is beyond the scope of our paper.

4.3 Design Goals

• Reliable information transfer. By introducing dual-functional nodes with improved incentive mechanism, the commitment to newly generated block of ℛ will be recorded into 𝒮 in real time, and the cross-chain commitment recording resists against denial-of-service attack.

• Efficient cross-chain verification. The operation that a user of 𝒮 has a cross-chain verification to ℛ is as nearly efficient as verifying the local information in 𝒮.

• Low storage overhead. A user of 𝒮 has cross-chain verification without maintaining the data of ℛ. Subsequently, the user’s extra storage overhead brought by the cross-chain requirement is negligible.

4.4 Notations

To facilitate the understanding, we summarize the main notations in this paper in Table 1.

Table 1. Notations

5. Surveillant Framework

5.1 Overview

In this section, we present Surveillant: an efficient supervision mechanism between blockchains. For Surveillant in general, the dual-functional node D^𝑆 listens for the blockchain information of ℛ, generates commitment to the information, and records the commitment into 𝒮. Subsequently, the clients U^𝑆 is able to have efficient and low-cost cross-chain verification to the information through the commitment recorded in 𝒮.

The basic scheme of Surveillant includes three protocols: listen, record, and query. (see Fig. 4)

Fig. 4. Architecture of Surveillant

5.2 Protocol: Listen

D^𝑆 receives and maintains the full blockchain data of ℛ. Subsequently, D^𝑆 has verification to the blocks received and inspect any orphan branches occurred in ℛ.

Block verification. D^𝑆 has verification to the correctness of each new 𝐵_𝑗^𝑅 received. First, the block header of 𝐵_𝑗^𝑅 is verified based on the consensus protocol which blockchain ℛ is using. For PoW consensus protocol, D^𝑆 is required to know the difficulty policy of ℛ, and verify the correctness of proof-of-work in 𝐵_𝑗^𝑅. For PoS consensus protocol, such as Ouroboros [1], D^𝑆 is required to know the leader selecting epochs, and verify the correctness of leader signature in 𝐵_𝑗^𝑅 . Second, the transactions in 𝐵_𝑗^𝑅 is verified, in which the inclusion of a transaction in 𝐵_𝑗^𝑅 is required to be proved by a Merkle proof linking the transaction to the root in 𝐵_𝑗^𝑅 header.

Orphan branch inspection. Discussed in Section 3.3, orphan blocks are the blocks not included in the longest chain, and several continuous orphan blocks form an orphan branch. If the length of an orphan branch has exceeded a threshold 𝜖, the branch is judged as a long orphan branch, which brings the problem such as double-spending. In this situation, D^𝑆 will verify the long orphan branch generated in ℛ, and record its information into 𝒮.

5.3 Protocol: Record

In this process, a commitment of ℛ will be recorded into each 𝒮 block. The recording process includes two steps, which are commitment recording and commitment verification.

Commitment recording. First, at the moment when an 𝒮 block 𝐵_𝑖^𝑆 is being generated by a D^𝑆, the ℛ block chain 𝐶_𝑗^𝑅 with the largest length among the current ℛ chains maintained by the D^𝑆 itself is committed by using the data structure of Merkle mountain range [26]. Then the commitment 𝜋_𝑖j^𝑅 is recorded into the Merkle tree of 𝐵_𝑖^𝑆.

Second, for the ℛ chain 𝐶_𝑗′^𝑅 committed by 𝜋_{(𝑖−1)𝑗′}^𝑅 (𝑗′ < 𝑗) in 𝐵_𝑖−1^𝑆, if the blocks at the tail end of 𝐶_𝑗′^𝑅 are not included in 𝐶_𝑗^𝑅, these blocks are orphaned to form an orphan branch. In this situation, if the length of the orphan branch exceeds the threshold 𝜖, we have the assignments in which LOBCounter_𝑖 ← LOBCounter_𝑖−1 + 1, and BCHeight_𝑖 ← 𝑗.

LOBCounter_𝑖 is a field added in the block header of 𝐵_𝑖^𝑆. It counts the long orphan branches (LOB) that occurred in the history of ℛ. BCHeight_𝑖 is also a field in 𝐵_𝑖^𝑆 header. It records the height of each committed ℛ block chain. The two fields enable an efficient orphan branch retrieval, which is discussed in the following content.

Commitment verification. Next, the generated 𝐵_𝑖^𝑆 is broadcast to the other D^𝑆 to reach consensus. First, a D^𝑆 having received 𝐵_𝑖^𝑆 will verify that the 𝜋_𝑖j^𝑅 in 𝐵_𝑖^𝑆 must commit to one of the ℛ block chains maintained by the D^𝑆 itself, in which the ℛ block chains are received by the D^𝑆 during the listening process. Second, BCHeight_𝑖 must equal the height of 𝐶_𝑗^𝑅, and LOBCounter_𝑖 must be accumulated by one if a long orphan branch is created.

Subsequently, the 𝒮 block having correct format and block content will be included into blockchain 𝒮. As each 𝒮 block records an ℛ commitment, 𝒮 and ℛ are synchronized, which enables efficient cross-chain verification.

5.4 Protocol: Query

By using the synchronization between 𝒮 and ℛ, a user using an 𝒮 client U^𝑆 is able to have cross-chain verification to ℛ.

First, based on a recent stable 𝒮 block 𝐵^𝑆 recording the commitment 𝜋^𝑅, the user cross-chain verifies a transaction 𝑇^𝑅 in an ℛ block 𝐵^𝑅 by downloading a three-stage Merkle proof, which is the connection of the Merkle proof of 𝜋^𝑅 in the Merkle tree of 𝐵^𝑆, the Merkle proof of 𝐵^𝑅 in the Merkle mountain range of 𝜋^𝑅, and the Merkle proof of 𝑇^𝑅 in the Merkle tree of 𝐵^𝑅. By this design, the transaction in ℛ can be cross-chain verified efficiently without maintaining the data in ℛ.

Second, by checking where LOBCounter is accumulated in 𝒮, the user is able to retrieve any long orphan branches occurred in the history of ℛ. Moreover, BCHeight helps locating the position of the branches. This retrieval can be achieved by only downloading the block headers of 𝒮.

6. Blockchains Synchronization

6.1 Motivation

Discussed in Section 3.1, blockchain is a distributed digital ledger of cryptographically signed transactions that are grouped into blocks. Each block header records a hash pointer pointing to the header of the last block, and the transactions is grouped by the Merkle tree in a block, in which the hash pointer and Merkle tree constitute the cryptographical links among each part of the blockchain data structure. Therefore, a user using a blockchain light client is able to have cryptography-based verification to any blocks and transactions in the blockchain. The advantage of cryptography-based verification is that it is efficient in operation, and it does not need to trust the intermediaries.

However, as different blockchains are mutually independent in data structure, there are no cryptographical links between them. This limitation results that we cannot use the same cryptography-based verification method to achieve cross-chain verification, in which the cross-chain verification refers that a user using a client of blockchain 𝒮 wants to verify the information in blockchain ℛ. For the other methods, some existing schemes have cross-chain verification with the help of trusted third parties, or each user using a client of 𝒮 additionally maintains the data of ℛ to verify both of the blockchains in the same time. However, the existing methods are insecure or costly.

In respect of the issues above, if we establish the cryptographical links between the two blockchains by embedding a real-time blockchain commitment of ℛ into every block of 𝒮, the application of cryptography-based verification method to cross-chain verification will become feasible. This conception will have two advantages. First, a user using a client of 𝒮 will be able to have cross-chain verification to a transaction in ℛ through the blockchain commitment 𝜋^𝑅 embedded in 𝒮, which is as nearly efficient as the verification to a transaction in 𝒮. Second, the user does not need to additionally maintain the data of ℛ, avoiding the high usage costs.

6.2 Overview

Starting from the idea mentioned above, we achieve synchronization between 𝒮 and ℛ by blockchain commitment, enabling efficient cross-chain verification.

First, the ℛ block chain 𝐶_𝑗^𝑅 is committed by using Merkle mountain range (MMR), which is a variant of Merkle tree. In 𝐶_𝑗^𝑅, the blocks from 𝐵₁^𝑅 to 𝐵_𝑗^𝑅 is grouped by MMR, and the root of the MMR is the commitment 𝜋_𝑖j^𝑅 to 𝐶_𝑗^𝑅. By virtue of MMR, the size of 𝜋_𝑖j^𝑅 can be as small as the size of a common transaction.

At the moment when a new 𝒮 block 𝐵_𝑖^𝑆 is generated by a D^𝑆, the 𝜋_𝑖j^𝑅 is recorded into 𝐵_𝑖^𝑆. Subsequently, with 𝑖 and 𝑗 increasing, the successively generated 𝐵_𝑖^𝑆 record the 𝜋_𝑖^𝑅𝑗 committing to 𝐶_𝑗^𝑅 with increasing length, describing the state update of ℛ. By recording the blockchain commitment, 𝒮 and ℛ are synchronized.

To encourage the blockchain commitment, we design an incentive mechanism. In this design, the D^𝑆 committing the 𝐶_𝑗^𝑅 with larger length will earn more commitment reward. In order to maximize revenue, the honest majority will be initiative to listen to the most real-time information of ℛ, and commit the information to 𝒮, achieving active blockchain commitment.

Through the synchronization between 𝒮 and ℛ, a user using an 𝒮 client U^𝑆 is able to have cross-chain verification to ℛ. The cross-chain verification does not need to rely the trusted third parties, and the cost to have a cross-chain verification has been nearly close to the cost to have a verification to the local information in 𝒮. Therefore, the user is able to have on-demand cross-chain verification, breaking through the limitation of trust and cost.

6.3 Blockchain Commitment

Because the data in a blockchain occupies a lot of storage space, for example the Bitcoin blockchain takes up about 340 GB. It is completely impractical to directly commit the untreated ℛ data into 𝒮 block. A preprocessing method is to take the hash of every ℛ block. However, the size of the block hashes is still too large to commit. For example, all block hashes of Bitcoin blockchain takes up about 21 MB.

Merkle mountain range. To solve the above problem, we first introduce the data structure of MMR. Considering both the definition of MMR, each 𝒯_𝑘 in MMR is actually a Merkle tree. Subsequently, the data 𝐷_𝑗 can be proved to be included in MMR by a Merkle proof (see Definition 1), and the complexity of the Merkle proof is 𝑂(log𝑛).

Definition 3 (Merkle Mountain Range). Merkle mountain range is formed by a sequence of perfect binary trees 𝒯_𝑘 with strictly decreasing heights ℎ_𝑘. In a 𝒯_𝑘, each leaf of 𝒯_𝑘 includes a data hash H(D_j), and each non-leaf node includes a hash 𝐻(LeftChild∥RightChild). The number of all leaves in MMR equals ∑2^ℎ_𝑘. The hash of the 𝒯_𝑘 roots is the root of MMR. The hash function used in MMR is collision resistant.

Compared with Merkle tree, MMR has the advantage of extendibility. When new data hashes are added as new leaves are appended in MMR, we do not have to recalculate all the hashes in MMR, but generate the new 𝒯_𝑘″ roots (𝑘 < 𝑘″) based on the old 𝒯_𝑘 roots along with the new leaves.

Commitment to ℛ. To make a smaller ℛ commitment to be recorded into 𝒮 block, we further aggregate the hashes of the ℛ blocks by using MMR (see Fig. 5).

Fig. 5. Merkle Mountain Range. The blocks from 𝐵₁ to 𝐵₁₁ in a block chain are aggregated by the MMR (marked by full line). For convenience, we draw only 11 blocks here. The binary trees with the roots 𝐻₁₅, 𝐻₁₈, and 𝐻₁₉ are three Merkle trees, and the hash 𝐻_𝑟 = 𝐻(𝐻₁₅ || 𝐻₁₈ || 𝐻₁₉) is the root of the MMR. When new blocks 𝐵₁₂ and 𝐵₁₃ (marked by dotted line) are added into the block chain, the new hashes 𝐻₂₀, 𝐻₂₁, 𝐻₂₂, 𝐻₂₃, and 𝐻_𝑟″ are generated based on 𝐻₁₅, 𝐻₁₈, and 𝐻₁₉, and 𝐻_𝑟″ is the root of the new MMR.

For a chosen ℛ block chain 𝐶_𝑗^𝑅 with the largest length, the hashes of the blocks in 𝐶_𝑗^𝑅 from 𝐵₁^𝑅 to 𝐵_𝑗^𝑅 are sequentially included into the leaves of a MMR, and the MMR root is included in the commitment 𝜋_𝑖j^𝑅, in which 𝜋_𝑖j^𝑅 has the size comparable to the size of a common transaction. Now 𝜋_𝑖j^𝑅 is small enough to be recorded into 𝐵_𝑖^𝑆.

6.4 Synchronization via Blockchain Commitment

Discussed in Section 5, at the moment when a new block 𝐵_𝑖^𝑆 is assembled by a dual-functional node D^𝑆, the 𝜋_𝑖j^𝑅 committed by the D^𝑆 is recorded into 𝐵_𝑖^𝑆. After finding a nonce to make the 𝐵_𝑖^𝑆 satisfy the difficulty, the D^𝑆 broadcasts the 𝐵_𝑖^𝑆 to other D^𝑆 to reach consensus.

Commitment verification. In the process of consensus, an honest D^𝑆 having received the 𝐵_𝑖^𝑆 is required to have verification to the 𝜋_𝑖j^𝑅 in it. A valid 𝜋_𝑖j^𝑅 satisfies the following two conditions:

• Congruity: 𝜋_𝑖j^𝑅 commits to an ℛ block chain maintained by the honest D^𝑆 itself.

• Monotonicity: the length of 𝐶_𝑗^𝑅 is greater than or equal to the length of 𝐶_𝑗′^𝑅 committed by the 𝜋_{(𝑖−1)𝑗′}^𝑅 in 𝐵_𝑖−1^𝑆.

For the congruity, if 𝜋_𝑖j^𝑅 does not commit to any block chains maintained by the honest D^𝑆, the D^𝑆 affirms that the 𝜋_𝑖j^𝑅 is not true, and the 𝜋_𝑖j^𝑅 will not generated new 𝒮 block following 𝐵_𝑖^𝑆. It is worth noted if a block chain 𝐶_𝑗^𝑅 committed by 𝜋_𝑖j^𝑅 is orphaned in a future time, the 𝜋_𝑖j^𝑅 is still true. Because the 𝜋_𝑖j^𝑅 reflects the state of ℛ in a certain time period. This commitment enables us to locate the long orphan branches occurred in ℛ.

For the monotonicity, as the blockchain ℛ increases with new block extended, the D^𝑆 should follow the increment to commit the ℛ block chain with increasing length. Otherwise, the behavior committing the out-of-date block chains with decreasing length violate our intention to deliver the real-time information from ℛ to 𝒮.

Synchronization between 𝒮 and ℛ. The 𝐵_𝑖^𝑆 satisfying the condition of congruity and monotonicity will reach consensus among the honest majority, and be included into 𝒮. As a result, the blockchain 𝒮 and ℛ are synchronized to form an integrated three-layer data structure (see Fig. 6): the first layer is 𝒮, whose block records 𝜋_𝑖j^𝑅 ; the second layer is 𝜋_𝑖j^𝑅, which commits to ℛ by using MMR; the third layer is ℛ, which records its own transactions. The synchronization between 𝒮 and ℛ enables the cross-chain transaction through a three-stage Merkle proof, which is discussed in Section 6.6.

Fig. 6. Synchronization between 𝒮 and ℛ. 𝒮 and ℛ are synchronized to form a three-layer data structure, which includes the blockchain 𝒮, MMR, and blockchain ℛ. For convenience, we draw only the block headers of 𝒮 and ℛ with necessary block contents. Based on a stable 𝒮 block such as 𝐵_𝑖^𝑆 with the block header 𝐵ℎ_𝑖^𝑆, a user cross-chain verifies a given transaction such as 𝑇₃^𝑅 by the three-stage Merkle proof (marked by dark blue). First, the validity of 𝜋_𝑖,11^𝑅 is proved, when the Merkle tree root in 𝐵ℎ_𝑖^𝑆 equals 𝐻(𝐻₃^𝑆 || 𝐻 (𝐻₄^𝑆 || 𝐻(𝜋_𝑖,11^𝑅))). Second, the validity of 𝐵ℎ₇^𝑅 is proved, when the MMR root in 𝜋_𝑖,11^𝑅 equals 𝐻(𝐻 (𝐻₇ || 𝐻(𝐻₁₀ || 𝐻(𝐻(𝐵ℎ₇^𝑅) || 𝐻₁₂))) || 𝐻₁₈ || 𝐻₁₉). Third, the validity of 𝑇₃^𝑅 is proved, when the Merkle tree root in 𝐵ℎ₇^𝑅 equals 𝐻(𝐻₃^𝑅 || 𝐻(𝐻(𝑇₃^𝑅) || 𝐻₅^𝑅)).

Treatment to orphan branch. Because of the network latency or intentional attack (discussed in Section 3.3), the ℛ block chain 𝐶_𝑗^𝑅 committed by 𝜋_𝑖j^𝑅 has the possibility to be orphaned in a future time. Specifically, the honest miners of ℛ adapt and mine on another ℛ block chain with the largest length, and 𝐶_𝑗^𝑅 stops to increase leaving an orphan branch at the tail end of 𝐶_𝑗^𝑅.

In this situation, the honest majority of D^𝑆 will detect this orphaning event, and preserve 𝐶_𝑗^𝑅 along with its orphan branch. The 𝜋_𝑖j^𝑅 committing to 𝐶_𝑗^𝑅 still satisfies the condition of congruity, although 𝐶_𝑗^𝑅 has been orphaned. The commitment to orphan branch is not trivial, as it reflects the state of ℛ in different time period.

More importantly, when the length of an orphan branch has exceeded a threshold 𝜖, the probability that the long orphan branch is caused by network latency drops to nearly zero, which means that the long orphan branch is very likely to be caused by intentional attack. Hence, the commitment to long orphan branch reflects the malicious behaviors in ℛ. Moreover, the LOBCounter_𝑖 counting the long orphan branches will provide marks for users to locate the drastic structure changes caused by intentional attacks.

6.5 Incentive for Blockchain Commitment

The work to commit the ℛ block chain brings additional workload without retribution. Although the condition of monotonicity has regulated that a D^𝑆 is not allowed to commit the out-of-date ℛ block chains with decreasing length, the commitment to the up-to-date ℛ block chains with larger length is not encouraged by the regulation. It results that the D^𝑆 will be passive to do the commitment, and the latest information in ℛ cannot be committed in real time.

To achieve active blockchain commitment, we propose the “commitment reward” to incentive the commitment, which is inspired by the incentive mechanism in Bitcoin. In Bitcoin, there are two types of rewards, which are the block reward and transaction fee. For the block reward, a bookkeeper who generates a new block will receive 6.25 Bitcoin, in which 6.25 Bitcoins is created out of nothing by a coin-creation transaction in the new block. For the transaction fee, a user who publishes a transaction will attach a transaction fee on it, rewarding a bookkeeper to timely record the transaction into the new block.

Commitment reward. As the third type of reward, the commitment reward is created out of nothing by a coin-creation transaction 𝑇_𝑐^𝑆, which has the same creation process as the block reward in Bitcoin. The 𝑇_𝑐^𝑆 is recorded into 𝐵_𝑖^𝑆 along with the other transactions in 𝐵_𝑖^𝑆, and the reward is sent to a recipient address chosen by the D^𝑆 who generates the 𝐵_𝑖^𝑆.

The value of commitment reward monotonically increases with the proof-of-work in the fresh blocks committed by 𝜋_𝑖j^𝑅. To get more commitment reward, a D^𝑆 should actively obtain the new fresh blocks mined in the longest chain of ℛ, and timely commit the fresh blocks before other D^𝑆 do. Subsequently, D^𝑆 is incentivized to commit the real-time information of ℛ to 𝒮.

Definition 4 (Fresh block). Fresh blocks are the newly generated ℛ blocks which are committed by 𝜋_𝑖j^𝑅, but were not committed by any 𝜋_𝑖'j'^𝑅 before 𝜋_𝑖j^𝑅 (𝑖′ < 𝑖,𝑗′ ≤ 𝑗).

Backoff against network latency. However, the behavior that D^𝑆 try to commit the latest ℛ block brings additional problem in the consensus process of 𝐵_𝑖^𝑆. Because of the network latency, the transmission of the ℛ block takes time, in which we assume that the honest majority of D^𝑆 will reach consensus to the newly generated block of 𝒮 and ℛ within the maximum time delay 𝛥^𝑆 and 𝛥^𝑅. There is a phenomenon that the 𝐵_𝑖^𝑆 with 𝜋_𝑖j^𝑅 committing to the 𝐵_𝑗^𝑅 has been spread throughout the network, but 𝐵_𝑗^𝑅 has not been received by the honest majority of D^𝑆. This phenomenon is more common when the 𝒮 block propagation speed is higher than the propagation speed of ℛ block, or in another word 𝛥^𝑆 < 𝛥^𝑅.

Consequently, there can be a time interspace in which the 𝜋_𝑖j^𝑅 in 𝐵_𝑖^𝑆 is not congruent with any ℛ block chains maintained by the honest majority, as most of the honest D^𝑆 have not received 𝐵_𝑗^𝑅. The honest D^𝑆 will affirm that 𝜋_𝑖j^𝑅 does not satisfy the condition of congruity, and chooses not to generate new 𝒮 block following 𝐵_𝑖^𝑆. This affirmation keeps until 𝐵_𝑗^𝑅 has reached consensus. In this time interspace, 𝐵_𝑖^𝑆 takes the risk to be orphaned.

To lower the risk, A D^𝑆 who generates the 𝒮 block will have backoff against network latency. The D^𝑆 does not directly commit to the latest ℛ block after first receiving it. Instead, the D^𝑆 waits for a certain time, and let the ℛ block reach consensus among the majority of D^𝑆.

Then the D^𝑆 commits the latest ℛ block.

6.6 Cross-chain Verification via Synchronization

As the blockchains 𝒮 and ℛ have been synchronized via the blockchain commitment, a user using an 𝒮 client U^𝑆 is able to have cross-chain verification via the synchronization. The cross-chain verification includes two aspects, which are cross-chain transaction verification and long orphan branch supervision.

Cross-chain transaction verification. First, the user chooses a recent stable 𝐵_𝑖^𝑆 with large enough confirmation. A valid 𝐵_𝑖^𝑆 header satisfies that every 𝐵_𝑖′^𝑆 prior to 𝐵_𝑖^𝑆 (𝑖′ < 𝑖) is correctly pointed by the hash pointer in 𝐵_𝑖′+1^𝑆, which ensures no manipulation occurs. Based on the 𝐵_𝑖^𝑆 header, the user further verifies a transaction 𝑇^𝑅 in ℛ through a three-stage Merkle proof across 𝒮 and ℛ (see Fig. 6).

• The first stage Merkle proof is the hash path linking the 𝐵_𝑖^𝑆 header to the 𝜋_𝑖j^𝑅 in 𝐵_𝑖^𝑆. The Merkle proof in this stage is situated in the Merkle tree in 𝐵_𝑖^𝑆, as the 𝜋_𝑖j^𝑅 is recorded along with other transactions in 𝐵_𝑖^𝑆.

• The second stage Merkle proof is the hash path linking the 𝜋_𝑖j^𝑅 to the header of the ℛ block 𝐵_𝑗^𝑅. The Merkle proof in this stage is situated in the MMR.

• The third stage Merkle proof is the hash path linking the 𝐵_𝑗^𝑅 header to the target transaction 𝑇^𝑅 in 𝐵_𝑗^𝑅. The Merkle proof in this stage is situated in the Merkle tree in 𝐵_𝑗^𝑅.

The 𝑇^𝑅 is verified by doing hash calculations backward along the three-stage Merkle proof, which is from 𝑇^𝑅 to 𝐵_𝑗^𝑅 header, to 𝜋_𝑖^𝑅, and to 𝐵_𝑖^𝑆 header. The 𝑇^𝑅 is valid when the result of the hash calculations matches the Merkle root in 𝐵_𝑖^𝑆 header.

Long orphan branch supervision. In the second aspect, the user using the U^𝑆 has supervision to the long orphan branches in ℛ by checking the LOBCounter_𝑖 in 𝐵_𝑖^𝑆. An accumulation of LOBCounter_𝑖 indicates that a long orphan branch whose length has exceeded the threshold 𝜖 is created in ℛ, which reflects that an intentional attack occurs in ℛ with large possibility. Subsequently, based on all the 𝐵_𝑖^𝑆 with the LOBCounter_𝑖 accumulated, a user is able to locate the long orphan branches occurred in ℛ to trace the malicious behaviors in the history of ℛ.

Simplified re-verification. A combination of the cross-chain transaction verification and long orphan branch supervision can further simplify the re-verification to the transactions in ℛ.

There is a common scenario that a business proceeded in 𝒮 is related to a 𝑇^𝑅 in ℛ, and the prerequisite of every operation in the business is that the 𝑇^𝑅 must stably exist in ℛ. However, as each block in ℛ has the possibility to be orphaned in a future time, the 𝑇^𝑅 recorded in an ℛ block may be removed later. Therefore, to guarantee the validity of every operation in the business, the business participants have to re-verify the 𝑇^𝑅 every time in each operation, ensuring that the 𝑇^𝑅 exists in ℛ

We assume that a business participant first verifies the 𝑇^𝑅 based on the header of 𝐵_𝑖^𝑆, and the current latest stable block of 𝒮 is 𝐵_𝑖″^𝑆 (𝑖 < 𝑖″). By virtue of the long orphan branch supervision, the multiple re-verifications to the 𝑇^𝑅 can be omitted if 𝑇^𝑅 satisfies the following two conditions.

• First, the value BCHeight_𝑖″−1 − BCHeight_𝑖 has exceeded threshold 𝜖.

• Second, the LOBCounter_𝑖″ in 𝐵_𝑖″^𝑆 does not accumulated compared with the LOBCounter_𝑖 in 𝐵_𝑖^𝑆.

The two condition means that the confirmation of 𝐵_𝑗^𝑅 recording the 𝑇^𝑅 is at least larger than 𝜖, and no orphan branch with large enough length occurred to remove 𝐵_𝑗^𝑅. Therefore, the 𝑇^𝑅 has been showed to exist in ℛ, and the re-verification to the 𝑇^𝑅 is not necessary.

7. Analysis

7.1 Security Analysis

Illegal blockchain commitment. While generating the commitment to ℛ, a dishonest D^𝑆 may tamper the block hash of ℛ, create fabricated hash pretending to be the hash of the new ℛ block, or just arbitrarily commit a random value to create a false commitment. It results that none of the ℛ block chains correspond with the commitment, which violates the condition of congruity. Second, a dishonest D^𝑆 may record an out-of-date commitment 𝜋_𝑖j^𝑅 committing to an ℛ block chain with smaller length compared with the ℛ block chain committed by 𝜋_{(𝑖−1)𝑗″}^𝑅(𝑗 < 𝑗″), which violates the condition of monotonicity. We assume that the honest majority of D^𝑆 will reach consensus to an ℛ block within the time delay 𝛥^𝑅. Subsequently, the honest majority are able to verify the false and out-of-date commitment based on the received information of ℛ, and the 𝒮 block recording the illegal commitment will not be included into ℛ.

Counterfeit three-stage Merkle proof. First, we review the security of Merkle proof. For a given Merkle tree 𝒯, 𝒯 is constructed by collision-resistant hash function. The root of 𝒯 is 𝑟^𝒯, every node in 𝒯 has a path to 𝑟^𝒯, and every Merkle proof must end with 𝑟^𝒯. Assume a PPT adversary is able to forge a Merkle proof 𝛱_𝐷^𝒯 for a 𝐷 not in 𝒯. It is required that the adversary establishes a new path linking 𝐷 with a node 𝐻(𝑥 || 𝑦) in 𝒯 which has an initial path to 𝑟^𝒯, and finds an 𝑥′ (or 𝑦′) to satisfy 𝐻(𝑥′ || 𝑦) = 𝐻(𝑥 || 𝑦) and 𝑥′ || 𝑦 ≠ 𝑥 || 𝑦 (or 𝐻(𝑥 || 𝑦′) = 𝐻(𝑥 || 𝑦) and 𝑥 || 𝑦′ ≠ 𝑥 || 𝑦), in which a collision occurs.

Furthermore, the three-stage Merkle proof is constituted by three Merkle proofs with coherent path in three Merkle trees. The path links the transaction 𝑇^𝑅 to the block header of 𝒮, traversing across ℛ block, MMR, and 𝒮 block. Given a stable 𝒮 block header which has been confirmed valid, an adversary forging a three-stage Merkle proof for a transaction 𝑇 not in ℛ is required to establishes a new path linking 𝑇 to a node in any one of the three Merkle trees. However, it is hard to find a collision in any node.

Denial-of-service attack. An adversary may try to control the D^𝑆 to suspend or delay the commitment to ℛ. However, the decentralized design of Surveillant makes the denial-of-service attack difficult. To permanently exclude the 𝒮 block recording the commitment, the adversary has to have a majority attack. It creates the adversary’s 𝒮 chain without recording the ℛ commitment, and the chain has overwhelming advantage in length to exclude the other block chains generated by the honest majority. To delay the commitment to real-time information of ℛ, the adversary has to have bifurcation in 𝒮 to orphan the 𝒮 blocks with large enough confirmation. However, the condition for the above attacks is that the corrupted hash power in D^𝑆 should have exceeded the security threshold, which violates our initial assumption.

7.2 Time Consumption of Blockchain Commitment

The time consumption is calculated from the generation of 𝐵_𝑗^𝑅 to the moment when 𝜋_𝑖j^𝑅 committing to 𝐶_𝑗^𝑅 is recorded into the newly generated 𝐵_𝑖^𝑆. First, we assume that 𝐵_𝑗^𝑅 is broadcast in network following the block propagation model 𝑃(𝑡) [19], in which the proportion of the honest majority that have received the 𝐵_𝑗^𝑅 increases with time 𝑡 following the model 𝑃(𝑡). In the condition without backoff, the D^𝑆 having received 𝐵_𝑗^𝑅 begin to generate 𝐵_𝑖^𝑆 immediately. The total hash rate of all D^𝑆 is ℎ, \(\begin{aligned}\bar{H}\end{aligned}\) is the average number of hashes required to generate an 𝒮 block, and 𝛥t is the time it takes. Their relationship satisfies the following equation. Considering the backoff time 𝛥𝑡_𝑏 taken by D^𝑆, the average time consumption of blockchain commitment equals 𝛥t + 𝛥𝑡_𝑏.

\(\begin{aligned}h \int_{0}^{\Delta t} P(t), d t=\bar{H}\end{aligned}\)

7.3 Storage and Bandwidth Overhead

In addition to the function to receive, maintain and generate the blocks of ℛ, D^𝑆 is required to receive and maintain the full blockchain data of ℛ, which brings additional overhead to storage and bandwidth. However, compared with the mining process in 𝒮 that consumes most of the resource of D^𝑆, the additional overhead appears to be insignificant.

On the other hand, a user using a light client U^𝑆 downloads the three-stage Merkle proof to have cross-chain verification to a transaction in ℛ. Because the complexity of Merkle proof increases logarithmically, and the user does not need to download or maintain the data on ℛ. The cross-chain verification to a transaction in ℛ can be as nearly efficient as the verification to a local transaction in 𝒮.

8. Implementation and Evaluation

8.1 Implementation

We implement a simulation experiment for Surveillant. The main processes of Surveillant are written in Python (version 3.8.3) Javascript(node.js), and HTML. The blockchain ℛ is deployed on Intel Xeon E5-2680 v4 CPU @2.4GHz, 32GB DDR, and Ubuntu 18.04 64bit operating system. 100,000 dual-functional nodes of 𝒮 are deployed on Intel Xeon E5-2680 v4 CPU @2.4GHz, 32GB DDR, and Ubuntu 18.10 64bit operating system. The clients of 𝒮 are deployed on Intel Core i7-7500U @2.70GHz, and Windows 10.0.19042 64bit operation system.

8.2 Result Analysis

First, for blockchain ℛ and 𝒮, we investigate how long it takes for an ℛ block to be committed to 𝒮. On the side of ℛ, the propagation of ℛ block is improvable, as the application of delegations or gossip protocol will accelerate the speed. The block propagation time is defined as the time required for a newly generated ℛ block to reach consensus among the honest majority. On the side of 𝒮, the block generation rate is adjustable following different difficulty policies or consensus epoch setting. The time it takes for committing is calculated from the moment when an ℛ block is generated to the moment when an 𝒮 block which records the commitment committing to the ℛ block is generated. Measurements are given as the average over 1000 test runs, and the results are presented in Fig. 7. From the results, we can find that the time consumption of blockchain commitment is mainly affected by block generation rate (BGenRate). The block propagation time has slight influence on the time consumption, as the block propagation time is relatively smaller compared with the block generating time.

Fig. 7. Time consumption of blockchain commitment

Second, we have a comparison about the user’s storage overhead in Chain relay, XCLAIM, and Surveillant. The characteristics of blockchain 𝒮 and ℛ are configured referring to the specifications of Ethereum [27] and Bitcoin [28]. The trusted checkpoint is built into the code of the 𝒮 client as Ethereum design, by which a user using a light client of 𝒮 only need to download the latest headers of 𝒮. We measured the size of total data stored by the user, as shown in Table 2. Compared with Chain relay and XCLAIM that maintain both the block headers of 𝒮 and ℛ, the client of Surveillant is smaller than the clients of the other two schemes, as Surveillant does not need to store the block headers of ℛ.

Table 2. Storage overhead

Third, we compare the bandwidth overhead of Chain relay, XCLAIM, and Surveillant. It is measured by the the average data size which a user needs to download for a cross-chain transaction verification. In 𝒮 and ℛ, the size of a block is limited to 2 MB, and the hash function applied is SHA-256. Measurements are given as the average over 1000 test runs, and the results are presented in Table 3. In Surveillant, because the user does not download the block headers of ℛ, but has cross-chain transaction verification through the three-stage Merkle proof (TSMP), the amount of data downloads is significantly reduced. Furthermore, we compare the size of TSMP with the size of ordinary Merkle proof to verify a local transaction in 𝒮, as shown in Fig. 8. As the height of Merkle mountain range increases logarithmically with the number of the blocks included in it, the TSMP size is kept at about 1.5KB, which is as negligible as the size of ordinary Merkle proof. Comprehensively, the results in Table 3 and Fig. 8 show that the cross-chain transaction verification in Surveillant is as nearly efficient as the verification to a local transaction.

Fig. 8. Size of proves

Table 3. Bandwidth overhead

8. Conclusion

To achieve blockchain interoperability, we propose a supervision mechanism between blockchains (Surveillant) in this paper. It introduces the dual-functional nodes to commit the real-time information from ℛ to 𝒮, which enables users to have efficient cross-chain verification. Specially, we introduce Merkle mountain range for blocks aggregation to deal with the large-scale data in ℛ. We propose the design of LOBCounter, which enables the users of 𝒮 to retrieve the long orphan branch occurred in ℛ. The incentive mechanism is improved to encourage the behaviors of dual-functional nodes. The security proof and experimental results show that Surveillant is suitable in practice.