UCC: Universal and Committee-based Cross-chain Framework

Abstract

One most potential solution to enhance the interoperability of various kinds of blockchains is to utilize the cross-chain mechanism. This mechanism, however, still faces some challenges. One is to find a universal cross-chain solution, independent of the underlying heterogeneous blockchains. The other is the lack of formal security definitions. To address these challenges, we propose UCC, a universal cross-chain framework using the cross-chain committees. We provide the formal security definition of the cross-chain framework and prove that UCC is secure when each well-defined module meets its security requirement. To demonstrate the feasibility of UCC, we implement it with efficient components and make the experimental evaluation. The result shows that UCC achieves a secure cross-chain with a low cost in comparison to the underlying chains.

This work is supported by the National Natural Science Foundation of China (No. 61872142), the Key (Keygrant) Project of Chinese Ministry of Education (No. 2020KJ010201), the Key Research and Development Plan of Shandong Province (No. 2021CXGC010105).

Appendices

A Related definition

Definition 2

(Secure Committee Construction) For one run a secure committee construction protocol, the following properties need to be satisfied,

• Termination If at least $f+1$ honest nodes activate the protocol, and all messages among honest nodes arrive, then each honest node outputs a committee $\textsf{cccom}$ within a pre-defined time.

• Agreement Any two honest nodes output the same $\textsf{cccom}$.

• Validity If any honest node outputs $\textsf{cccom}$, then the probability that (1) $|\textsf{cccom}|=n$, (2) the probability of each candidate node $P_i\in \textsf{cccom}$ is the same, (3) $\textsf{cccom}$ contains at most f Byzantine nodes, is at least $1-\epsilon$.

• Unpredictability Before an honest node innovates the election, the probability that the adversary predicts the result is at most $1/{\left( {\begin{array}{c}N\\ n\end{array}}\right) }$.

B Security Analysis of the Instantiation

In this part, we will analyze the security of each module in Sect. 7.1. We assume the adversary ratio is 1/3. That is, $F<N/3$.

Committee Member Selection Module. We will prove that when $F<N/3$, the probability that $f<n/2$ does not hold is negligible. The proof is inspired by Rapidchain [2]. Suppose there are X Byzantine nodes in the committee, then $Pr[X\ge \lfloor n/2\rfloor ]=\Sigma _{x=\lfloor n/2\rfloor }^{n}{\frac{\left( {\begin{array}{c}F\\ x\end{array}}\right) \left( {\begin{array}{c}N-F\\ n-x\end{array}}\right) }{\left( {\begin{array}{c}N\\ n\end{array}}\right) }}$. When N and n are large enough, we can estimate the probability with a binomial distribution $Pr[X\ge \lfloor n/2\rfloor ]=\Sigma _{x=0}^{f}{\left( {\begin{array}{c}n\\ x\end{array}}\right) (\frac{f}{n})^x(1-\frac{f}{n})^x}$. The value of this expression decreases exponentially when N and n increases. Thus, the security of this module is proved.

Committee Consensus Module. The intra-committee consensus protocol in Rapidchain achieves both safety and liveness if $f<n/2$ [2]. Here safety guarantees that all the honest nodes will obtain the correct value, and liveness guarantees that it can be completed within a bounded time.

Inter-chain Message Passing Module. The IDA gossip protocol in Rapidchain guarantees that the probability that all the honest nodes receive the correct message is at least 0.9 if the parameters are properly adjusted, and the time is bounded to a certain value $\delta _\text {IDA}$. In our model, we perform IDA gossip k times. Therefore, the probability that there exist some honest nodes that do not receive the correct message is at most $0.1^k$, a negligible value, with a bounded time.

C Communication Complexity Analysis

• When $\textsf{cccom}_\text {A}$ receives the transaction and make a consensus since every honest user can obtain the information from chain A and calculate the hash value according to a known rule, they are able to send only the hash value, which is a fixed small value that can be ignored.

• When the transaction is passed from $\textsf{cccom}_\text {A}$ to $\textsf{cccom}_\text {B}$, we assume that the message format is as follows. It has an 8-byte transaction id, 35-byte target address, 2-byte chain id, and 8-byte transaction amount. Thus, the size of one transaction is 53 bytes. Besides, we should add a 20n-byte signature length. Thus, the total size is $53u+20n$ bytes.

• When $\textsf{cccom}_\text {B}$ receives the transaction and makes a consensus, the signature is not included. Thus, the size is 53u bytes.

• When $\textsf{cccom}_\text {B}$ sends the message back to $\textsf{cccom}_\text {A}$, each transaction can be represented by 8-byte id. Thus, the total size is $8u+20n$ bytes.

• Similarly, when $\textsf{cccom}_\text {A}$ makes a consensus for $\textsf{cccom}_\text {B}$’s response, the message size is 8u bytes.