DOI QR코드

DOI QR Code

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

  • Liang, Xinyu (School of Cyber Science and Engineering, Wuhan University) ;
  • Chen, Jing (School of Cyber Science and Engineering, Wuhan University) ;
  • Du, Ruiying (School of Cyber Science and Engineering, Wuhan University) ;
  • Zhao, Tianrui (School of Cyber Science and Engineering, Wuhan University)
  • Received : 2021.12.23
  • Accepted : 2022.07.08
  • Published : 2022.08.31

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.

Keywords

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.

E1KOBZ_2022_v16n8_2507_f0001.png 이미지

Fig. 1. Merkle proof. For the given data 𝐷7 and the Merkle tree root hash 𝐻15 (marked by brown), 𝐷7 can be proved to be included in the Merkle tree if 𝐻15 = 𝐻 (𝐻7 || 𝐻(𝐻10 || 𝐻(𝐻(𝐷7) || 𝐻12))). The value 𝐻12, 𝐻10, and 𝐻7 (marked by dark blue) are the Merkle proof 𝛱𝐷7𝒯 to 𝐷7. 𝛱𝐷7𝒯 are the siblings of 𝐻11, 𝐻13, and 𝐻14 (marked by light blue), which are in the Merkle tree path linking 𝐷7 to 𝐻15.

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 ⌈log2(𝑛)⌉. 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 𝐵1 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 𝜖.

E1KOBZ_2022_v16n8_2507_f0002.png 이미지

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 𝐵1. The blocks in the path form the block chain 𝐶12′, which is marked by red. For all of the block chains in this figure, 𝐶14 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 𝐵5. 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).

E1KOBZ_2022_v16n8_2507_f0003.png 이미지

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

E1KOBZ_2022_v16n8_2507_t0001.png 이미지

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)

E1KOBZ_2022_v16n8_2507_f0004.png 이미지

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 𝐵1𝑅 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(Dj), 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).

E1KOBZ_2022_v16n8_2507_f0005.png 이미지

Fig. 5. Merkle Mountain Range. The blocks from 𝐵1 to 𝐵11 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 𝐻15, 𝐻18, and 𝐻19 are three Merkle trees, and the hash 𝐻𝑟 = 𝐻(𝐻15 || 𝐻18 || 𝐻19) is the root of the MMR. When new blocks 𝐵12 and 𝐵13 (marked by dotted line) are added into the block chain, the new hashes 𝐻20, 𝐻21, 𝐻22, 𝐻23, and 𝐻𝑟″ are generated based on 𝐻15, 𝐻18, and 𝐻19, and 𝐻𝑟″ is the root of the new MMR.

For a chosen ℛ block chain 𝐶𝑗𝑅 with the largest length, the hashes of the blocks in 𝐶𝑗𝑅 from 𝐵1𝑅 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.

E1KOBZ_2022_v16n8_2507_f0006.png 이미지

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 𝑇3𝑅 by the three-stage Merkle proof (marked by dark blue). First, the validity of 𝜋𝑖,11𝑅 is proved, when the Merkle tree root in 𝐵ℎ𝑖𝑆 equals 𝐻(𝐻3𝑆 || 𝐻 (𝐻4𝑆 || 𝐻(𝜋𝑖,11𝑅))). Second, the validity of 𝐵ℎ7𝑅 is proved, when the MMR root in 𝜋𝑖,11𝑅 equals 𝐻(𝐻 (𝐻7 || 𝐻(𝐻10 || 𝐻(𝐻(𝐵ℎ7𝑅) || 𝐻12))) || 𝐻18 || 𝐻19). Third, the validity of 𝑇3𝑅 is proved, when the Merkle tree root in 𝐵ℎ7𝑅 equals 𝐻(𝐻3𝑅 || 𝐻(𝐻(𝑇3𝑅) || 𝐻5𝑅)).

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.

E1KOBZ_2022_v16n8_2507_f0007.png 이미지

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

E1KOBZ_2022_v16n8_2507_t0002.png 이미지

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.

E1KOBZ_2022_v16n8_2507_f0008.png 이미지

Fig. 8. Size of proves

Table 3. Bandwidth overhead

E1KOBZ_2022_v16n8_2507_t0003.png 이미지

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.

References

  1. A. Kiayias, A. Russell, B. David, and R. Oliynykov, "Ouroboros: A provably secure proof-of-stake blockchain protocol," in Proc. of Annual International Cryptology Conference, Springer, pp. 357-388, 2017.
  2. E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, "Zerocash: Decentralized anonymous payments from bitcoin," in Proc. of 2014 IEEE Symposium on Security and Privacy, IEEE, pp. 459-474, 2014.
  3. J. Poon and T. Dryja, "The bitcoin lightning network: Scalable off-chain instant payments," 2016.
  4. L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, "A secure sharding protocol for open blockchains," in Proc. of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 17-30, 2016.
  5. S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," Decentralized Business Review, p. 21260, 2008.
  6. V. Buterin et al., "A next-generation smart contract and decentralized application platform," white paper, vol. 3, no. 37, 2014.
  7. S. Jiang, J. Cao, J. A. McCann, Y. Yang, Y. Liu, X. Wang, Y. Deng, "Privacy-Preserving and Efficient Multi-Keyword Search over Encrypted Data on Blockchain," in Proc. of IEEE International Conference on Blockchain, IEEE, pp. 405-410, 2019.
  8. Z. Liu, Y. Xiang, J. Shi, P. Gao, H. Wang, X. Xiao, B. Wen, and Y.-C. Hu, "Hyperservice: Interoperability and programmability across heterogeneous blockchains," in Proc. of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pp. 549-566, 2019.
  9. V. Buterin, "Chain interoperability," R3 Research Paper, 2016.
  10. W. Warren, A. Bandeali, "0x: An open protocol for decentralized exchange on the ethereum blockchain," 2017.
  11. C. Decker and R. Wattenhofer, "A fast and scalable payment network with bitcoin duplex micropayment channels," in Proc. of Symposium on Self-Stabilizing Systems, Springer, pp. 3-18, 2015.
  12. M. Herlihy, "Atomic cross-chain swaps," in Proc. of the 2018 ACM symposium on principles of distributed computing, pp. 245-254, 2018.
  13. "Btc relay," Ethereum project, 2015. [Online]. Available: https://github.com/ethereum/btcrelay
  14. A. Zamyatin, D. Harz, J. Lind, P. Panayiotou, A. Gervais, and W. Knottenbelt, "Xclaim: Trustless, interoperable, cryptocurrency-backed assets," in Proc. of 2019 IEEE Symposium on Security and Privacy (SP), IEEE, pp. 193-210, 2019.
  15. S. Jiang, J. Cao, H. Wu, Y. Yang, M. Ma, J. He, "BlocHIE: A BLOCkchain-Based Platform for Healthcare Information Exchange," in Proc. of International Conference on Smart Computing, IEEE, pp. 49-56, 2018.
  16. M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. A. Maglaras, H. Janicke, "Blockchain Technologies for the Internet of Things: Research Issues and Challenges," IEEE Internet of Things Journal, vol. 6, pp. 2188-2204, 2019. https://doi.org/10.1109/jiot.2018.2882794
  17. M. A. Ferrag, L. Shu, "The Performance Evaluation of Blockchain-Based Security and Privacy Systems for the Internet of Things: A Tutorial," IEEE Internet of Things Journal, vol. 8, pp. 17236-17260, 2021. https://doi.org/10.1109/JIOT.2021.3078072
  18. S. Jiang, J. Cao, H. Wu, Y. Yang, "Fairness-Based Packing of Industrial IoT Data in Permissioned Blockchains," IEEE Transactions on Industrial Informatics, vol. 17, no. 11, pp. 7639-7649, 2021. https://doi.org/10.1109/TII.2020.3046129
  19. C. Decker and R. Wattenhofer, "Information propagation in the bitcoin network," in Proc. of IEEE P2P 2013 Proceedings, IEEE, pp. 1-10, 2013.
  20. N. Papadis, S. Borst, A. Walid, M. Grissa, and L. Tassiulas, "Stochastic models and wide-area network measurements for blockchain design and analysis," in Proc. of IEEE INFOCOM 2018-IEEE Conference on Computer Communications, IEEE, pp. 2546-2554, 2018.
  21. L. Kiffer, R. Rajaraman, and A. Shelat, "A better method to analyze blockchain consistency," in Proc. of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 729-744, 2018.
  22. I. Eyal and E. G. Sirer, "Majority is not enough: Bitcoin mining is vulnerable," in Proc. of International conference on financial cryptography and data security, Springer, pp. 436-454, 2014.
  23. J. Bonneau, "Why buy when you can rent?," in Proc. of International Conference on Financial Cryptography and Data Security, Springer, pp. 19-26, 2016.
  24. J. Garay, A. Kiayias, and N. Leonardos, "The bitcoin backbone protocol: Analysis and applications," in Proc. of Annual international conference on the theory and applications of cryptographic techniques, Springer, pp. 281-310, 2015.
  25. L. Wang and Y. Liu, "Exploring miner evolution in bitcoin network," in Proc. of International Conference on Passive and Active Network Measurement, Springer, pp. 290-302, 2015.
  26. P. Todd, "Merkle mountain range," Github, 2018. [Online]. Available: https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountainrange.md
  27. G. Wood et al., "Ethereum: A secure decentralised generalized transaction ledger," Ethereum project yellow paper, vol. 151, no. 2014, pp. 1-32, 2014.
  28. "Bitcoin development," Github, 2021. [Online]. Available: https://github.com/bitcoin/bitcoin