SMPTC3: Secure Multi-Party Protocol Based Trusted Cross-Chain Contracts

Abstract

We propose an innovative approach called SMPTC³, designed specifically to enhance security and privacy in cross-chain transaction verification. This approach addresses multi-chain, multi-participant information exchange and large-scale cross-chain transfers, resisting various types of malicious attacks. We leverage the verifiability of cross-chain transactions based on smart contracts and innovatively transform transaction information into confidential sets, organizing them into quadratic secret polynomials. By utilizing secret sharing and random distribution techniques, we construct a secure multiparty computation method, tailored for cross-chain transactions. To enhance the efficiency of cross-chain transactions, we introduce cross-chain batch processing technology, grouping inter-chain transactions into cross-chain transaction sets. Unlike traditional distributed notary technologies, SMPTC³ designates honest participants as a cross-chain notary group, reducing the time required for redundant signature confirmations and significantly lowering the possibility of malicious notaries. Theoretical analysis and empirical experiments demonstrate that SMPTC³ is highly efficient in addressing cross-chain transaction security issues.

1. Introduction

Since Satoshi Nakamoto proposed the concept of blockchain [1], blockchain technology has realized a decentralized shared general ledger, which can be understood as a large-scale and decentralized distributed database, which is traceable, verifiable and not easily tampered with [2].

Blockchain has developed very quickly, and a large number of blockchain projects and their unique chain structures and tokens have been recently created, such as bitcoin blockchain [1] based on proof-of-work, Ethereum blockchain [3] transitioning from proof-of-work to proof-of-stake, the use of proof-of-stake [4,5,6], the use of proof-of-authority [7,8], and web3′s hot consortium blockchains, such as Hyperledger Fabric, Corda, and Quorum, which use consensus protocols such as PBFT [9,10] and Raft [11]. These chains do not communicate with each other in structure, which leads to great obstacles in the application and development of blockchain technology. Token and application data on the chain may form the data-islanding effect of blockchain, so different blockchains need a unified method to transfer data and assets. Therefore, researchers put forward the concept of “cross-chain”, which breaks the islanding effect among different blockchain projects and realizes interoperability between chains.

The current mainstream projects of cross-chain technology include Cosmos [12], Polkadot [13], Lightning Network [14], Fusion [15], Interledger [16], etc. Their purpose is to realize asset exchange, information interaction, and application collaboration between different blockchain platforms, reduce the difficulty of blockchain users, and reduce the cross-chain transmission process.

Table 1. Comparison of cross-chain projects.

Cross-Chain Project	Consensus	Cross-Chain Technology	Security	Transaction Speed
Cosmos	Tendermint BFT	IBC Protocol and Relays	Medium	Very High
Polkadot	Asynchronous BFT	Relays	Medium	Medium
Lighting Network	Following transactions chain	Channels	Medium	High
Fusion	PoW	DCRM	Medium	Medium
Interledger	Following transactions chain	Multi-Notary	Low	Medium

shows the key attributes of some cross-chain projects.

The Problem: At present, cross-chain still relies on third-party centralized nodes and relays. Even though Cosmos, Polkadot and cross-chain bridges [17,18] are proposed, which solve the inter-chain consensus protocol and some security problems, there is still the possibility of bridging chains being used for malicious purposes. In 2019, Cosmos was found to have a re-entrustment loophole, which could immediately redeem guarantee tokens by replacing the validator of a parallel chain, resulting in the early redemption of 7250 Atom tokens with a value of about 43,500 US dollars; this event destroyed the fairness of the transaction. The Grandpa Consensus (GHOST-based Recursive Ancestor Deriving Prefix Agreement) Protocol used by Polkadot cannot tolerate Dos attacks, and there is the possibility that Nominators will be used for malicious purposes together [13]. In 2022, Lightning Network had a malicious channel attack problem, and after the uplink timed out, malicious traders could still send bitcoin under the chain, resulting in theft.

Cross-chain bridge solutions focus on two-blockchain interoperability, which does not suit the complex cross-chain requirements in multi-chain ecosystems. As depicted in Figure 1 [17,18], suppose a user $U$, driven by investment motives, intends to exchange their assets $t_1$ held on blockchain $C_1$ for equivalent assets $t_3$ on another blockchain $C_3$. However, given that both $t_1$ and $t_2$ are not stable currencies (potentially speculative coins), it requires converting $t_1$ through cross-chain bridge $B_1$ to obtain $t_2$ on blockchain $C_2$ (e.g., Ethereum′s ETH), then subsequently through $B_2$, converting $t_2$ to $t_3$ via cross-chain transfer. It is evident in this operational flow that $U$ engages in two separate cross-chain transactions, resulting in a cumbersome process, and the multiple transactions incur additional operational costs.

To address the issues of excessively long waiting times and high cross-chain transaction fees caused by multiple cross-chain operations in multi-party cross-chain scenarios, as well as to enhance the security and privacy of cross-chain operations and prevent other participating nodes or third-party verification nodes from stealing secret information during the cross-chain process, we propose the following solution.

Our approach: we can derive the following research objectives:

• Reduce transaction time in multi-party, multi-cross-chain scenarios.
• Lower the high fees associated with multi-party, multi-cross-chain scenarios.
• Enhance the security and attack resistance of the cross-chain process.
• Prevent third-party verification nodes or other participating nodes from stealing information, thereby improving the privacy of cross-chain operations.

In blockchain cross-chain scenarios, involving collaboration among multiple parties may require computations involving sensitive information. Secret sharing can be employed to securely execute computations among multiple parties, ensuring that no private information from any party is disclosed. We propose SMPTC³ (secure multi-party protocol-based trusted cross-chain contracts) to implement a secure cross-chain interaction protocol, which is mainly aimed at a token transfer of a large amount and the cross-chain transmission of important private data. SMPTC³ does not need to trust any central committee or third-party node. It uses and improves the SMC [19,20,21,22,23] (secure multi-party computation) proposed by Yao to establish the trust between the participating chains, and defines the participating nodes as semi-honest adversaries to prevent the participating chain from being used for malicious purposes. Meanwhile, participants can prove their identities without providing too much private data to ensure the privacy of cross-chain transactions. SMPTC³ embeds the improved SMC into the smart contract, and the cross-chain initiator C1 initiates the smart contract (SC) of the relay chain, and SC verifies whether the identities of C1 and other participants in the chain are true and reliable.

The SMPTC³ deploys a group of contracts, each situated on various participating chains, referred to as validator contracts. These validator contracts can invoke the validator contracts of other participating chains for cross-chain validation. They can also invoke sender and receiver contracts deployed across different chains to perform application-specific tasks. Depending on the application scenario, validator contracts may also require participating nodes to provide transaction information and Merkle proofs of smart contract states to ensure the atomicity of asset exchanges and the correctness of smart contracts. Figure 2 illustrates a hypothetical scenario of multi-chain asset exchange facilitated by SMPTC³. Initially, user U1 requests the validator contract to initiate a cross-chain transaction (step 1). To transfer the asset, the validator contract invokes SClock and notifies participating users to lock their respective assets (steps 2 and 3). Subsequently, the validator contract verifies the correctness and atomicity of the cross-chain transaction (steps 5 and 6). Upon successful validation, it invokes SCmint to issue assets. To ensure transaction atomicity, SCmint can issue new assets only when users have locked assets on the chain. This necessitates SCmint to read the state of SClock (balance of U, step 4) from the relevant blockchain, which is not directly accessible in cross-chain transactions. This is achieved through validator contracts facilitating the transmission of block headers, transaction information, and correctness proofs between chains (step 5 and 6). SCmint can verify the correctness of user balances through the validator contract (step 7) and, upon successful verification, issue new assets to each user (step 8).

Apart from the aforementioned multi-chain asset transfer, SMPTC³ can also support applications such as multi-chain message interaction and multi-chain voting.

This design offers four benefits.

• For a token transfer of a large amount and the transmission of important private data in a cross-chain, there is no need to verify its offline identity repeatedly, and its reliability is ensured through strict identity verification on the chain;
• In multi-chain ecology, confidential information sharing or anonymous voting can be carried out for mutual distrust among members;
• Prevent various types of attacks and avoid possible losses caused by loopholes in the consensus protocol in the participating chain;
• Due to the reliability of SMPTC³, there is no need for any additional security requirements beyond the security logic of underlying blockchains, especially the third-party centralized nodes or the security committees in the relay chain.

Technical challenges: Although there are many theoretical works of research [23,24] on secure multi-party computation at present, SMC is rarely used for blockchain cross-chain. Secondly, the two-party secure computation model is mostly used in the privacy protection methods on the chain, and whether the multi-party can resist collusion attack is an important problem for protocol security. Thirdly, the execution efficiency of complex computation tasks on ciphertext is very low and the communication cost is high. The question of how to simplify the computation and communication cost in the cross-chain process has become a research challenge. Finally, when using SMC and blockchain, it should be noted that the participating nodes of the two technologies may overlap. Therefore, in practical application, it is necessary to consider that these overlapping situations can meet the security assumptions of the two technologies at the same time.

It is obviously infeasible to directly extend the inter-chain communication of a secure two-party secure computation to multi-party, so we propose a novel scheme based on the original research results [19,20,25,26,27]; the presently available schemes include the garbled circuit method [20,28,29], secret sharing method [30,31,32] and homomorphic encryption method [27,33,34]. We transform the private information of each participant into a secret set, and use the secret set for SMC. We find that in a cross-chain, the set elements are regularly verifiable (traceability and immutability of the blockchain), so the secure set is encoded into a special array, and the homomorphic encryption method is combined to solve the problem of SMC, to reduce the high computing cost and communication cost of a traditional SMC. Then, we use smart contract in EVM or chaincode in a privacy channel by Fabric to ensure the information security of the computing process. Therefore, a secure cross-chain protocol with lower computation and communication cost is realized.

Our contribution: in this paper, we make the following contributions:

• In order to resist malicious attacks such as Sybil and Dos, we improve the homomorphic encryption method (P-ElGamal) and threshold signature method, and combine these with the improved secure multi-party computation method (SMPTC³). The improved combination method can resist a variety of attacks to which the original blockchain was susceptible.
• We propose an improved multi-party security computation method (SMPTC³) for blockchain. Compared with the original method, it significantly reduces the computational complexity and communication complexity, so the SMPTC³ in this paper is efficient, and SMPTC³ can be applied to a variety of environments except blockchain.
• Based on SMPTC³, we convert the private data of multiple participants in different chains into secure sets. This method has great application value in cross-chain interaction, and can also provide a new secure transmission scheme for other cross-chain methods.
• SMPTC³ uses secure multi-party computation to solve collusion attacks and avoid relying on third-party central nodes or security committees for authentication. SMPTC³ is a novel cross-chain interaction protocol.
• Based on the Fabric, Ethernet and Cosmos systems, we implement the multi-party participation model of SMPTC³ and verify it. The experiments show that this protocol has high performance.

Section 2 introduces the background knowledge required for this paper. Section 3 is the core of this paper, including how to construct confidential sets and the two-round communication and computation process of SMPTC³. Section 4 describes the usage scenarios of SMPTC³. Section 5 extends SMPTC³ to two-party secure computation, which is one of the key challenges in multi-party secure computation. Section 6 presents the experiments demonstrating the security and efficiency of SMPTC³. Section 7 summarizes the work and advantages of SMPTC³. Section 8 briefly describes future research work.

2. Background

In this section we cover the background on blockchains, secure multi-party computation, and homomorphic encryption.

2.1. Blockchains

Blockchain [35,36,37] is a distributed shared ledger based on various technologies, essentially a distributed database with multi-participation and joint maintenance. Compared with centralized database management system, the blockchain system adopts a decentralized or weakly centralized data management mode [38], There is no central node; all participating nodes can store data. The persistence of transactions is realized by the increasing data chain and decentralized consensus mechanism jointly maintained by participating nodes, which ensures the credibility of data based on verification, improves the query efficiency of participants and the data security of the system, and reduces the maintenance cost of the original database maintainer [39].

2.1.1. Cross-Chain

Cross-chain [2,40] can be understood as chain-to-chain communication protocols. Current cross-chain technologies include the following methods: notary schemes, sidechains/relays, distributed private key control, hash-locking, and tight coupling. Because cross-chain involves building trust between chains, there may be some problems, such as private data leakage in a public chain, Sybil attacks in a consortium chain, and malicious intentions from third-party nodes. In the process of the cross-chain, there may be more security problems due to the different consensus protocols of participating chains. The common solution is to use a relay chain (cross-chain bridge [18,41]) to solve the problems of different consensus protocols, data leakage and third-party malicious intentions. However, at present, the relay chains are becoming centralized, and there is the possibility that the relay chains may be used for malicious purposes (

Table 2. Cross-chain bridges security problem.

Date	Victimization Agreement	Type of Attack	Operation Position
2021.07	Chainswap	Check for defects	After signing/cross-chain
2021.08	Poly Network	Hash collusion/check defect	signature
2022.01	Qubit Bridge	Incorrect setup/check defect	Before cross-chain
2022.01	Multichain	Interface compatibility issues	Before cross-chain
2022.02	Meter Bridge	Inspection defects	Before cross-chain
2022.02	Wormhole	Interface verification problem	signature
2022.03	Li Finance	Inspection defects	Before cross-chain
2022.03	Ronin Network	Validator control	signature

shows some cross-chain bridges’ security problems). Therefore, solving the trust problem between chains has become one of the key objectives of the research.

2.1.2. Smart Contracts

Smart contracts are event-driven, stateful computer programs deployed on shared distributed databases. The implementation of a smart contract is not based on the trust of centralized third party, and its security is based on cryptography. Smart contracts based on blockchain support the creation of distrusted protocols. This means that the contract participants do not need to know or trust each other, but only make commitments through blockchain, which is consistent with secure multi-party computation. For example, the Ethereum smart contract consists of a contract code and two public keys. The first public key is provided by the contract creator, and the other public key is the contract itself, which serves as a unique numeric identifier for each smart contract. All smart contract deployments are conducted through blockchain transactions, which will only be activated when external accounts (EOAs) or other smart contracts invoke. Ethereum smart contract has the characteristics of certainty, non-tampering and distrust. Regarding the trust problem in cross-chain process, it is one of the important means to express secure multi-party computing in the form of a smart contract.

2.2. Secure Multi-Party Computation

2.2.1. Mathematical Definition

Assuming there are $n$ participants $p_1, p_2, \dots , p_n$, each party has a private input data $x_i$, all participants calculate a function $f (x_1, x_2, \dots , x_n)$ together, and at the end of the calculation, each participant $p_i$ can only obtain the output of private input data $x_i$, but can not obtain the input information and output information of other participants [42]. In secure multi-party computing, the semi-honest model and malicious adversary model are usually used.

2.2.2. Honest Participants

Honest participants [19,20] mean that, ideally, this kind of participant calculates strictly according to the requirements of the protocol, does not collect data privately, and does not have any malicious behaviors (attacking the protocol, refusing to participate in the protocol, stopping the protocol halfway, entering false data). This type of participant is ideal, but when designing a security model, it is generally assumed that there are no absolutely honest participants.

2.2.3. Semi-Honest Model

Semi-honest model is also called passive model [19,20,34] or honest-but-curious model. All participants in this kind of model are semi-honest, which refers to participants who calculate according to the requirements of the protocol during the calculation process, but these participants will record all the information collected during the protocol process and calculate the input information (private information) of other participants according to the collected information. Semi-honest participants do not actively attack protocols, but collect and record possible private information.

2.2.4. Malicious Adversary Model

In the malicious adversary model [19,20,43], some participants, as attackers, may use illegal input or malicious tampering input to calculate the private information of other participants, and may also refuse to participate in the protocol or stop the protocol halfway. A secure multi-party computation protocol based on malicious adversary model can meet the security requirements of semi-honest model.

2.3. Homomorphic Encryption

Because secure multi-party computation needs to ensure the privacy of data of each participant, it needs an encryption method with good homomorphism. ElGamal [27] has good multiplication homomorphism, as follows:

2.3.1. Key Generation

Given the security parameter $k$, the key generation algorithm generates a large prime number $p$ with $k$ bits and a generator $g$ of $Z_p^{*}$, and randomly selects $x$ as the secret key, and the corresponding public key is $h=g^x\mathrm{mod} p$.

2.3.2. Encryption

To encrypt the message $M(M\in Z_p^{*})$, select the random number $r$, and the ciphertext is $E_{pk}\left(M\right)=\left(c_1,c_2\right)=(g^r\mathrm{mod} p,{Mh}^r\mathrm{mod} p)$.

2.3.3. Decryption

For ciphertext $E_{pk}\left(M\right)=\left(c_1,c_2\right)$, decrypt it to $M=c_2{·c}_1^{-x}\mathrm{mod} p$.

2.3.4. Homomorphic Property

Encryption system has multiplicative homomorphism:

$$\begin{array}{ll}{E}_{pk}\left(M_1\right){\times E}_{pk}\left(M_2\right)& =\left(g^{r_1},M_1{h}^{r_1}\right)\times \left(g^{r_2},M_2{h}^{r_2}\right)\\ & =\left(g^{r_1+r_2},M_1{\times M}_2{h}^{r_1+r_2}\right)\\ & =E_{pk}\left(M_1\times M_2\right)\end{array}$$

The data encrypted by ElGamal $E_{pk}\left(M\right)$ cannot obtain the original data $M$ after decryption, so it is not completely decrypted, which can ensure that malicious nodes (semi-honest participants and malicious participants) in the chain cannot obtain the private data of other participants, which is one of the important objectives in this paper.

3. Confidential Set and Secure Multi-Party Computation for Cross-Chain

Firstly, the proposed solution in this paper does not require on-chain participants to encrypt transaction information in their sets using cryptographic algorithms. Since cryptographic algorithms consume significant computational power and communication costs, they are not suitable for cross-chain interactions. Therefore, the solution presented in this paper no longer employs cryptographic algorithms. Instead, it leverages mathematical methods for confidential computation, where participants communicate with each other only twice, establishing inter-chain trust locally. An essential feature of this solution is the elimination of the need to obtain and store public keys of other participants, preventing malicious activities by centralized transaction nodes or relay chains. This approach significantly reduces both computational and communication overhead.

3.1. Constructing Transaction Set

Assuming there are n participants on different chains, denoted as $p1, p2, \dots , pn \left(n \ge 3\right)$, collectively participating in a cross-chain transaction T, they collectively sign the transaction elements, including transaction signatures, sender identities, locked assets, transaction order, etc., denoted as $e_1, e_2, e_3, \dots ,e_m$. These elements are hashed and packaged into sets as follows:

$$X_1=\left\{x_{11},x_{12},\dots ,x_{1m}\right\}\dots { X}_n={\{x}_{n1},x_{n2},\dots ,x_{nm}\}$$

In order to ensure the confidentiality of the set information, each participant converts their set into polynomial form. They construct a quadratic secret polynomial by taking each element (hash value) of their set as a root parameter for the polynomial. The quadratic secret polynomials constructed by participants $p1, p2, \dots , pn$ can be represented as:

$$\begin{array}{l}{f}_1\left(x\right)={{(x-x}_{11})}^2{{(x-x}_{12})}^2\dots {{(x-x}_{1m})}^2\\ \hspace{1em}\dots \\ f_n\left(x\right)={{(x-x}_{n1})}^2{{(x-x}_{n2})}^2\dots {{(x-x}_{nm})}^2\end{array}$$

(1)

When $x=e$, $f_i\left(e\right)=0$ iff $e\in X_i$.

3.2. First Round of Participant Communication

The quadratic secret polynomials for participant $p_i, i\in \left[1,n\right]$ can be organized as follows:

$$\begin{array}{c}{f}_i\left(x\right)={\displaystyle \sum _{p=0}^{2m}}{e}_{ip}{x}^p\end{array}$$

(2)

The secret polynomials are then randomly divided into non-zero $t, 2\le t\le n$ shares, such that:

$$\begin{array}{c}{f}_i\left(x\right)=f_{i1}\left(x\right)+\cdots +f_{it}\left(x\right)\end{array}$$

(3)

Even if an adversary S on a certain chain obtains $t-1$ shares of the secret polynomial $p_i$, $1<j<t$:

$$\begin{array}{c}{f}_{i1}\left(x\right)+\cdots +f_{i\left(j-1\right)}\left(x\right)+f_{i\left(j+1\right)}\left(x\right)+\cdots +f_{it}\left(x\right)\end{array}$$

(4)

From Formula (3), it can be seen that $S$ cannot obtain the complete secret polynomial. It is crucial to note that each share of the polynomial is non-zero and random, making Equation (4) an indeterminate equation. Therefore, it is impossible to construct the complete quadratic secret polynomial $f_i\left(x\right)$. Even if $S$ possesses the ability to reverse hash or use rainbow tables, they cannot obtain any element of the secret set $p_i$.

Due to the possibility of collusion attacks such as Sybil attacks and conspiracy attacks in a multi-chain environment, to enhance security, we introduce random sending and random number strategies.

Random Sending Strategy: As the sender, participant $p_i$ randomly sends $t$ shares of the polynomial to $t$ recipients among the $n$ participants $2\le t\le n$, and t may include the sender $p_i$ itself. Thus, $t$ is not fixed, and the recipients are not certain whether other recipients have received the shares from the sender. This approach can also be used for cross-chain methods with relay chains and notary groups. In such cases, $t$ shares of the polynomial are randomly sent to $t$ relay chain nodes, forming a notary group, which then verifies and publicly discloses on the relay chain. The random sending strategy implies that even in a multi-chain environment, a witch attack or collusion attack cannot obtain the complete quadratic secret polynomial. Moreover, common consensus protocols have tolerances of 49% or 33%, while this scheme has a tolerance of 0%. Therefore, the tolerance of this scheme is lower than that of the consensus protocols used by each chain, eliminating the need for security guarantees at the underlying blockchain level.

Random Number Strategy: To further enhance the security of this scheme, we introduce a random number strategy. Specifically, each share of the polynomial is assigned a random number $r_{ij}, r_{ij}\ne 0, i\in \left[1,n\right], j\in \left[1,t\right]$. To reduce the difficulty of verification and computational overhead in smart contracts, it is necessary to ensure:

$$\begin{array}{c}{\displaystyle \sum _{i=1}^n}{\displaystyle \sum _{j=1}^t}{r}_{ij}=0\end{array}$$

(5)

From Formulas (3)–(5), it can be observed that with the introduction of the random number strategy, if $S$ obtains an incomplete secret polynomial, the sum of some random numbers must be non-zero. This will significantly increase the decryption cost, greatly enhancing the security of the secret polynomial.

The first-round communication example among participant nodes is illustrated in Figure 3, involving six participant nodes labeled as A, B, C, D, E, F. In this initial communication round, each node divides its quadratic secret polynomial into three parts:

$$\begin{array}{c}{f}_A=f_{A1}+\cdots +f_{A3}\\ \dots \\ f_D=f_{D1}+\cdots +f_{D3}\\ \dots \end{array}$$

Then, each node randomly sends them to the cross-chain participant nodes.

The participants randomly distribute their respective secret polynomial fragments. As evident from nodes C, D, and F in the diagram, it is possible for a participant to distribute a fragment randomly to themselves. Meanwhile, as node B indicates, due to the random transmission strategy, a participant node might not receive any secret polynomial fragments.

3.3. Second Round of Participant Communication

After the first communication round, each participant $p_i$ adds up all the partial polynomials they possess to form a new secret polynomial $h_i\left(x\right)$. Due to the random sending strategy, $h_i\left(x\right)$ may be zero. After forming $h_i\left(x\right)$, the second communication protocol is initiated. Participant $p_i$ sends the $h_i\left(x\right)$ they own to every participant node involved in the cross-chain transaction. Upon receiving $h_1\left(x\right),h_2\left(x\right),\dots ,h_n\left(x\right)$, participant $p_i$ adds them up to create a new secret polynomial $F\left(x\right)$.

$$\begin{array}{c}F\left(x\right){=h}_1\left(x\right)+\cdots +h_n\left(x\right)\end{array}$$

(6)

From Formulas (3), (5) and (6), the following computation process can be derived, resulting in Formula (7).

$$\begin{array}{ll}F\left(x\right)& ={\displaystyle \sum _{i=1}^n}{g}_i\left(x\right)\\ & ={(f}_{11}\left(x\right)+r_{11})+\cdots +{(f}_{nt}\left(x\right)+r_{nt})\\ & ={\displaystyle \sum _{i=1}^n}{f}_i\left(x\right)+{\displaystyle \sum _{i=1}^n}{\displaystyle \sum _{j=1}^t}{r}_{ij}\\ & =f_1\left(x\right)+\cdots +f_n\left(x\right)\end{array}$$

(7)

We provided the construction process of the secret polynomial in Protocol 1.

Protocol 1: Constructing the Secret Polynomial $F\left(x\right)$

Input: Transaction Elements $e_1, e_2, e_3, \dots ,e_m$ from each Participant $p_i$ Output: Secret Polynomial $F\left(x\right)$   1. Each participant $p_i$ hashes and compiles their transaction elements $e_1, e_2, e_3, \dots ,e_m$ into a secret set $X_i$.   2. $p_i$ constructs quadratic secret polynomials $f_i\left(x\right)$ based on the elements in the secret set $X_i$.   3. $p_i$ randomly divides $f_i\left(x\right)$ into $t$ parts. For each participant $p_i$ and each polynomial fragment $f_{ij}\left(x\right)$, generate a random number $r_{ij}$ such that $r_{ij}\ne 0$. These random numbers enhance security and ensure that $f_{ij}=\left(f_{i1}\left(x\right)+r_{i1}\right)+\cdots +\left(f_{it}\right(x)+r_{it})$.   4. $p_i$ randomly sends the t polynomial fragments to $t$ participating nodes.   5. Participants $p1, p2, \dots , pn$ collectively add up all the polynomial fragments to obtain $h_1\left(x\right),\dots ,h_n\left(x\right)$, then broadcast it to all cross-chain participants.   6. Each node adds up all received polynomials $h_1\left(x\right),\dots ,h_n\left(x\right)$ to construct $F\left(x\right)$.

After the first round of communication, each participant consolidates all the secret polynomial fragments they own into a new secret polynomial, denoted as:

$$\begin{array}{ll}{h}_A& =f_{B1}+f_{C2}+f_{D3}+f_{E2}\\ h_B& =\varnothing \\ & \dots \\ h_F& =f_{A3}+f_{B2}+f_{D1}+f_{E3}+f_{F3}\end{array}$$

After the consolidation, each participant broadcasts the secret polynomial they possess to the participant network, ensuring that eventually, each participant has the complete secret polynomial F. Specifically, as in the case of node B shown in Figure 3, $h_B$ is zero, and, for the integrity and security of the protocol, B also needs to broadcast $h_B$ to the network.

3.4. Secure Comparison

When the element $e_i$ represents the transaction verification information collectively possessed by all participants, $f_i\left(x\right)$ can be transformed into the following form:

$$\begin{array}{c}{f}_i\left(x\right)={\left(x-e_i\right)}^{2}S\left(x\right)\end{array}$$

(8)

where $S\left(x\right)$ is a $(2m-2)$-degree polynomial obtained by dividing $f\left(x\right)$ by ${\left(x-e_i\right)}^2$. Substituting $e_i$ into Equation (8), we obtain $f_i\left(x\right)=0$, implying $F\left(x\right)=0$. If a transaction element $e^{*}$ is not a shared element, then ${(x-e^{*})}^2>0$, and it follows that $f_i\left(x\right)>0$, which implies $F\left(x\right)\ne 0$.

Each participant can substitute their transaction elements $e_1, e_2, e_3, \dots ,e_m$ into Equation (7). If $F\left(e_i\right)=0$, then $e_i$ represents the transaction information collectively owned by all participants. The smart contract can then make decisions based on predefined elements for comparison.

If the transaction elements possessed by each participant are accurately compared, operations such as cross-chain transfers are executed.

In Protocol 2, a secure multiparty computation scheme for transaction elements is provided.

Protocol 2: Secure Comparison Protocol

Input: $F\left(x\right)$, $e_i$ Output: Verification Result 1: Procedure CompareElements ($F\left(x\right)$, $e_i$) 2:  For i = 1 to m 3:   If F($e_i$)! = 0 Then 4:    return False//Verification failed, indicating data tampering, terminate the cross-chain contract 5:   Else Continue 6:   End if 7:  End 8:  Send transactions to Pools // Execute cross-chain transfer

4. Application Use Cases

A building block of cross-chain applications is ability to verify whether specific transactions exist on another blockchain and transactions’ atomicity. The existence of a transaction can be verified by the receiver contract on the destination chain, acquired from a user, third-party service, or validator contract (in this paper). This transaction $trx$ on source blockchain at block d can be obtained with the Merkle proof. Subsequently, the receiver contract invokes the updater contract to check if the Merkle proof of d from the source blockchain matches the one provided by the validator contract. The atomicity of multi-chain cross-chain transactions relies on a group of receiver contracts across all participating chains. This group of receiver contracts must collectively confirm the Merkle proof before proceeding, aiming for strong consistency and atomicity.

We present two application examples supported by SMPTC³, representing integral parts of Web 3.0.

4.1. Multi-Chain Asset Transfer

In Web 3.0, the investment demands of individual users expand, often involving the transfer and exchange of cross-chain assets. Unlike miner node transfers of assets to high-yield mainstream blockchain networks, regular cross-chain bridges suffice for these scenarios. However, for individual users investing in potential coins or NFTs, regular cross-chain bridges entail complex multiple cross-chain transfers and high fees. Leveraging SMPTC³, users can employ a unified validator contract and pre-deployed locking contracts ${SC}_{lock}$ and minting contract ${SC}_{mint}$ across multiple chains. The specific protocol involves the deployment of ${SC}_v$, ${SC}_{lock}$, and ${SC}_{mint}$ in a multi-chain ecosystem. User $U_1$ aims to swap their investment asset NFT $t_1$ for an equivalent value in potential coin $t_3$. User $U_2$ is willing to purchase $t_1$ with an equivalent stable coin $t_2$, while User $U_3$ has completed their investment and desires to exchange $t_3$ for stable coin $t_2$. The detailed process is outlined in Figure 2.

4.2. Multi-Chain Information Interaction

Cross-chain message passing and data sharing involve sharing off-chain data across different blockchains, but simple bilateral cross-chain information exchange cannot satisfy the current complexities of the blockchain ecosystem. Multi-chain information interaction satisfies this need. Message passing can be achieved by embedding messages into transactions. As shown in Figure 4, to pass messages $m_1, m_2$ from blockchain $C_1, C_2 \mathrm{to} C_3$, a multi-chain transaction can be initiated, divided into two parts ${trx}_1$ and ${trx}_2$. Users can embed messages $m_1$ and $m_2$ into ${trx}_1$ and ${trx}_2$, respectively, sending them to $C_3$ for verification and execution.

5. Trusted Cross-Chain Protocol for Two Participants

In this section, we aim to extend SMPTC³ to accommodate two participants and demonstrate through an example and security analysis that this approach is ineffective. Subsequently, we introduce a two-participant cross-chain verification method based on discrete logarithms.

5.1. Direct Extension of TMPC3 to Two Participants

In SMPTC³, the fundamental security assumption is $n\ge 3$, signifying multiple participants collectively executing cross-chain verification tasks. It allows participants to conceal data within secret polynomials and share them among other participants while ensuring the secrecy of data. However, a majority of cross-chain interaction scenarios are concentrated on two participants across two chains, i.e., $n=2$, from Section 3.1, resulting in t = 2, which can be derived from Equation (3):

$$\begin{array}{l}{f}_A=f_{A1}\left(x\right)+f_{A2}\left(x\right)\\ f_B=f_{B1}\left(x\right)+f_{B2}\left(x\right)\end{array}$$

The execution of the first round of communication leads to the transformation of Figure 3 into Figure 5:

$$\begin{array}{c}\begin{array}{c}{h}_A{+h}_B-f_B=f_A\end{array}\end{array}$$

(9)

From Equation (9), it can be observed that B can directly compute the complete quadratic secret polynomial of A. This makes the secret information of A highly susceptible to direct deduction, rendering the direct extension of SMPTC³ to two-party computation ineffective.

5.2. Two-Participant Cross-Chain Verification Method Based on Discrete Logarithms

In practical cross-chain scenarios involving two participants, the data source is determinate. Therefore, relying on random transmission based on quadratic secret polynomials becomes ineffective. Hence, leveraging discrete logarithms [38], we have designed a verification method (2PC3) tailored for two-participant cross-chain scenarios.

As shown in Figure 6:

Two participants, A and B, first collectively agree on a large prime number $p$. Subsequently, each generates a large random number, $r_a$ and $r_b$, respectively. Then, based on their respective sets $X_A=\{x_{11},x_{12},\dots ,x_{1m}\}$ and $X_B=\{x_{21},x_{22},\dots ,x_{2m}\}$, they create $Y_A$ and $Y_B$ through the first round of discrete logarithm encryption and exchange these (steps 1 and 2). Following this, A and B individually perform the second round of discrete logarithm encryption to obtain ${Y_B}^{\prime }$ and ${Y_A}^{\prime }$ (step 3) and send these results to the verification contract (step 4). Upon successful comparison by the verification contract, a verification success message is sent to A and B (step 5).

The first round of discrete logarithm encryption is represented as:

$$\begin{array}{ll}{y}_{Ai}={x_{1i}}^{r_a}modp, x_{1i}\in X_A,& \\ y_{Bi}={x_{2i}}^{r_b}modp, x_{2i}\in X_B,& i\in \left[1,m\right]\end{array}$$

(10)

The second round of discrete logarithm encryption is represented as:

$$\begin{array}{ll}{y_{Bi}}^{\prime }={y_{Bi}}^{r_a} modp, y_{Bi}\in Y_B,& \\ {y_{Ai}}^{\prime }={y_{Ai}}^{r_b} modp, y_{Ai}\in Y_A,& i\in \left[1,m\right]\end{array}$$

(11)

Derived from Equations (9) and (10):

$$\begin{array}{l}{y_{Ai}}^{\prime }={x_{1i}}^{r_a+r_b} modp\\ {y_{Bi}}^{\prime }={x_{2i}}^{r_a+r_b} modp\end{array}$$

(12)

From Equation (11), if $X_A=X_B$, then ${Y_A}^{\prime }={Y_B}^{\prime }$, where the exponents $r_a$ and $r_b$ along with the large prime number p are randomly generated. Hence, the encryption verification method used in this paper ensures semantic security. Due to the complexity of the discrete logarithm problem, deducing xi is almost impossible. Even in the presence of curious nodes on the chain or among participants, access to confidential information is unattainable.

Protocol 3: 2PC3 Protocol

Input: Transaction Elements Set $X_A$ and $X_B$ from Participants $p_A$ and $p_B$ Output: Verification Result 1: Participants $p_A$ and $p_B$ jointly generate a large prime number $p$. 2: $p_A$ and $p_B$ each generate a large random number $r_a$ and $r_b$. 3: $p_A$ and $p_B,$ respectively, perform the first round of discrete logarithm encryption on elements $x_{Ai}$ from set $X_A$ and $x_{Bi}$ from set $X_B$, denoted as $y_{Ai}={x_{1i}}^{r_a}modp,{ y}_{Bi}={x_{2i}}^{r_b}modp$, where $i\in \left[1,m\right]$, then forming confidential sets $Y_A$ and $Y_B$. 4: $p_A$ and $p_B$ mutually exchange $Y_A$ and $Y_B$. 5: $p_A$ and $p_B,$ respectively, perform the second round of discrete logarithm encryption on $Y_B$ and $Y_A$, denoted as ${{{y_{Bi}}^{\prime }={{ y}_{Bi}}^{r_a}modp,y}_{Ai}}^{\prime }={y_{Ai}}^{r_b}modp$, forming sets ${Y_B}^{\prime }$ and ${Y_A}^{\prime }$. 6: $p_A$ and $p_B$ send ${Y_B}^{\prime }$ and ${Y_A}^{\prime }$ to the validator contract. After verification by the validator contract, the verification result is sent to the participants.

6. Implementation and Evaluation

The experiments for SMPTC3 are based on Fabric and the Ethereum test version Rinkeby (Geth) systems. The cross-chain contracts are implemented using Go and Solidity 3 multi-party cross-chain algorithm and the two-party cross-chain algorithm. Depending on the number of participants, the contract will automatically select the corresponding cross-chain solution (2PC or MPC). Based on the characteristics of blockchain cross-chain transactions (cross-chain information transmission also falls under cross-chain transactions), we use methods such as hashing and feature extraction to compute the transaction features, forming a verifiable high-privacy secret set. Then, based on the concept of multi-party secure computation (MPC) and combined with the communication characteristics of blockchain, we achieve communication and secure computation.

6.1. Experiment Setup

We conducted experimental tests using an Intel(R) Xeon(R) Gold 6354 CPU @ 3.00 GHz and 504 GB RAM. In accordance with requirements and industry standards, we report the average execution time and fees. The reported results are derived from the average of ten executions.

6.2. Security Test

We divided the participant nodes into four types: honest nodes, semi-honest adversaries, malicious adversaries, and downtime nodes. Based on these classifications, we set up four test scenarios: all honest nodes, an unspecified number of semi-honest adversaries, mostly honest nodes with one malicious adversary, and mostly honest nodes with one downtime node. Security testing was conducted with $(2, 3, 5)$ participants, with each scenario undergoing 100 actual tests, resulting in Figure 7.

From Figure 7, we can see that SMPTC³ can operate normally when all participants are honest nodes or when there are semi-honest adversaries. According to Formulas (4)–(8), the semi-honest adversary model can only obtain partial fragments of the secret set and cannot acquire effective secret information. When there is a malicious adversary among the participants, SMPTC³ cannot pass the verification, and the cross-chain transaction will be abandoned, strictly ensuring the safety of cross-chain assets and information. Therefore, in a malicious adversary environment, the number of successful verifications is zero. In the downtime node test environment, we divided it into two scenarios: one where the node downtime time exceeds the verification waiting time, and the other where the node recovers and re-responds to verification. Experimental tests show that if the node recovers from the crash and promptly responds and continues to participate honestly in verification, the verification task can still be successfully completed. This experiment demonstrates that SMPTC³ has good security and robustness, ensuring the safety of cross-chain assets and information.

6.3. Verify Time of SMPTC³

We measured the time overhead required for cross-chain transactions. For comparison with SMPTC³, we deployed conventional multi-signature notary mechanisms and sidechain mechanisms as control groups in the same experimental environment. Due to the complexity of multi-chain cross-chain scenarios, we designed the control group to achieve optimal experimental results, as shown in Figure 8. This ideal situation assumes there are only $n-1$ cross-chain operations (with $n$ cross-chain participants, the maximum number of cross-chain operations could be ${\displaystyle \frac{n(n-1)}{2}}$, and the minimum is $n-1$).

After executing each set of experiments ten times and averaging the results, we obtained the data presented in Figure 9. As shown in Figure 8, the ideal verify time for the multi-signature notary mechanism and the sidechain mechanism increases linearly ($n$) with the number of participants. Given that the maximum number of cross-chain operations could be ${\displaystyle \frac{n(n-1)}{2}}$, it is evident that the worst-case scenario will show a quadratic increase ($n^2$).

In contrast, for SMPTC³, the horizontal axis range of participants is 2–32, and the overall trend remains horizontal. It is worth noting that with only two participants, the verify time of SMPTC³ is slightly higher than in the multi-participant scenario. According to Formulas (10)–(12), this is likely due to the computation time for exponential and modular operations. For multiple participants, as the number of participants increases, the SMPTC³ verify time generally remains stable. However, when there are too many participants, such as 16–32, the verify time slightly increases. As indicated by Protocols 1 and 2, this is due to the increased communication and computation costs caused by the larger number of elements involved in the computation, but such situations are uncommon in practical applications and do not hold significant practical value.

In summary, SMPTC3 can effectively solve the complex problem of cross-chain interactions among multiple participants in practical applications. It also satisfactorily meets the basic requirements for two-party interactions.

7. Conclusions

The paper proposes an improved decentralized cross-chain method, SMPTC3, based on multi-party secure computation (MPC). The improved MPC method addresses the centralization issue inherent in traditional blockchain cross-chain methods, providing enhanced privacy and security. It innovatively solves the problem of multiple cross-chain operations in multi-chain ecosystems, significantly reducing the complexity of cross-chain interactions for multi-chain participants. Additionally, by leveraging the characteristics of blockchain technology, it extends MPC to two-party secure computation (2PC), meeting the basic cross-chain needs between two blockchains. Furthermore, SMPTC3 replaces the original cross-chain bridge solution, avoiding high cross-chain fees. Experimental results show that in blockchain cross-chain application scenarios, SMPTC3 effectively resolves issues that previously required multiple cross-chain operations through a single cross-chain interaction. For basic two-chain cross-chain requirements, its performance also surpasses that of previous methods. Unlike previous cross-chain bridge methods, SMPTC3 further reduces the various costs associated with cross-chain interactions, thereby avoiding limitations on blockchain ecosystem performance due to cross-chain operations.

8. Discussion and Future Research Work

This paper proposed a blockchain-based multi-party secure computation cross-chain method, addressing the complex issue of multiple cross-chain verifications with multiple participants and extending the multi-party participation model to a two-party model. However, it primarily focuses on blockchain cross-chain security issues and multi-party, multi-cross-chain scenarios issues, and does not address the recalculation load problem in MPC. In the future, we will continue to research the issue of recomputation load after interruptions in on-chain multi-party secure computation and further reduce the computational load of MPC algorithms.