A universal fair exchange protocol method, off-chain channel structure and cross-chain exchange method

Abstract

The present invention belongs to the field of blockchain technology, and in particular, relates to a general fair exchange protocol method, an off-chain channel structure and a cross-chain exchange method thereof. The two parties to the transaction establish a hierarchical channel with multiple sub-channels in the same smart contract; the sub-channel is generated according to the transaction receipts of the two parties to the transaction in the upper channel; the exchange within the channel follows the general fair exchange protocol; when the channel is closed, all accounts involved in the transaction in each channel will package their final status and related transaction receipts into a transaction, upload them to the corresponding smart contract within a set time, and execute the hierarchical settlement protocol to complete the settlement. The present invention introduces a new hierarchical channel structure, a hierarchical settlement protocol and a general fair exchange protocol, which solves the problem of unsettled amount congestion and unfair exchange to ensure the scalability, fairness and atomicity of cross-chain interaction; by avoiding high latency in asynchronous networks, it provides strong security and practicality.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and in particular relates to a general fair exchange protocol method, an off-chain channel structure supporting fair and atomic cross-chain operations, and a cross-chain exchange method. Background Art

[0002] Off-chain channel technology establishes and closes channels on the chain and performs tasks off the chain. This method can provide faster transaction processing and has lower requirements for hardware configuration. Previous researchers have proposed many off-chain channel solutions based on off-chain channel technology, which can be divided into three types: payment channel solution, state channel solution, and virtual channel solution.

[0003] Payment channel solution: A payment channel is a temporary off-chain transaction channel used to increase the transaction throughput of the entire system. It was originally designed as a one-way channel, but later evolved into a two-way channel so that one party can be both the sender and the receiver. The most widely discussed projects recently are Lightning Network and Raiden, which have established payment channels in different blockchains.

[0004] State channel solution: The state channel enriches the functions based on the payment channel. Specifically, in addition to payment, users in the state channel can also execute complex smart contracts in an off-chain manner and allow two or more participants to exchange states. The concept of state channel was first proposed by Jeff Coleman, and then Counterfacture gave a detailed design. Dziembowski et al. provided a formal definition and security proof for the general state channel network. ForceMove is a framework that can support n parties to participate in the state channel.

[0005] Virtual channel solution: Virtual channels can create, maintain, and close channels without interacting with the underlying blockchain. Dziembowski et al. proposed Perun, Aumayr et al. designed a virtual channel, proving that the establishment of virtual channels can be independent of smart contracts.

[0006] However, in order to take advantage of the high throughput of channels for cross-chain operations, two outstanding challenges need to be addressed: congestion of unsettled amounts and the problem of unfair exchange.

[0007] Unsettled amount congestion problem: The transaction content conducted by the sender and the receiver during the off-chain channel maintenance period cannot be used by the receiver before settlement. Due to the increased complexity brought by the multi-chain heterogeneous design, this delay becomes even greater when cross-chain operations are involved.

[0008] Unfair exchange problem: In cross-chain scenarios, affected by the risk of large fluctuations in currency prices, more users choose to trade in the form of barter. This makes the current fair exchange scheme unable to guarantee the fairness of the interaction process, because neither party is willing to be the first to disclose the privacy of the exchange object it wants to protect. Summary of the invention

[0009] In order to make up for the shortcomings of the cross-chain solution in the prior art, the present invention first provides a general fair exchange protocol method to solve the problem of unfair exchange in the cross-chain scenario. The protocol method includes:

[0010] (1) Deployment: The sender constructs a fair exchange circuit and security parameters; and uses the fair exchange circuit and security parameters as inputs to the zero-knowledge proof to construct a public reference string. ; The fair exchange circuit takes n key shares as private input;

[0011] (2) Sharing: The sender and receiver generate their own encryption keys and divide them into n shares based on the splitting algorithm of the (t, n)-VSS protocol. Then, they perform a hash operation on the encryption key and the n-shared key, package the hash operation result, the number of key shares n, and the key threshold t into a transaction, and send the transaction to the smart contract.

[0012] After receiving the transaction from both parties, the smart contract randomly selects n addresses of validators with serial number Sn, binds each validator's address to the hash result of one-nth of the key share of the two encryption keys from the sender and the receiver, and makes the binding information public;

[0013] The sender and receiver sign their key shares with the serial number Sn and distribute the key shares to the verifier according to the binding information;

[0014] After receiving the information from the sender and the receiver, each verifier recalculates the hash operation result of the key share and compares it with the hash result in the smart contract; the verification algorithm based on the (t, n)-VSS protocol is used to verify the legitimacy of the key share;

[0015] (3) Exchange: The sender and receiver calculate the ciphertext of the object to be exchanged based on their respective encryption keys and , encryption key and calculated ciphertext to construct a zero-knowledge proof and send it to the other party; the sender and receiver use Verify the zero-knowledge proof of the received message respectively;

[0016] (4) Merge: If the verification of both parties is successful, the sender and the receiver send a merge key request to the smart contract. After receiving the request, the smart contract broadcasts this event to the selected verifier, and the verifier sends its stored key shares to the smart contract through a transaction. The smart contract verifies the legitimacy of each key share by comparing the hash result and checking the sender's address. When the number of valid key shares is greater than the key threshold t, the smart contract sends the collected key shares to the requester, who then uses the (t, n)-VSS protocol to recover the key and further decrypt the message.

[0017] Preferably, during the sharing phase, if the verifier detects an error, The detected erroneous key share, the signature on the key share and the serial number Sn are packaged into a report and then sent to the smart contract; when the smart contract receives the report, the signature of the key share owner is verified with the serial number Sn, and the hash result of the reported erroneous key share is recalculated to check whether the data in the report is legal; if the verification is successful, the smart contract terminates the general fair exchange protocol.

[0018] In order to solve the problem of unsettled amount congestion in cross-chain operations in the prior art, the present invention provides an off-chain channel structure that supports fair and atomic cross-chain operations. The transaction parties establish a hierarchical channel with multiple sub-channels in the same smart contract, which are recorded as The subchannel is generated based on the transaction receipts of the two parties in the upper channel layer, and is used for the exchange of unsettled currency or encrypted information in the transaction receipts; the exchange within the channel follows the general fair exchange protocol; when the channel is closed, all accounts involved in the transaction in each channel will package their final status and related transaction receipts into one transaction, and close at a set time. The transaction is uploaded to the corresponding smart contract and the hierarchical settlement protocol is executed to complete the settlement; operations related to sub-channels are performed off-chain.

[0019] Preferably, for intra-chain channel settlement, at a set time After that, the smart contract verifies the correctness of the uploaded data starting from layer 0; the uploaded transaction contains all sub-channel receipts agreed by the sender, and the smart contract uses these receipts to verify the correctness of the account balance; if the verification is successful, continue to verify the next layer until all levels are verified; if the smart contract fails to verify at any level, all sub-channels at that level and above will automatically fail to verify; the verifier in the blockchain updates the corresponding on-chain status based on the settlement result.

[0020] Preferably, for cross-chain channel settlement, when the transaction receipt determines that the final state is valid, the smart contract runs the HTLC protocol, so that the accounts of the two parties to the cross-chain transaction lock their final states based on the HTLC protocol, and complete the final settlement according to the HTLC protocol; the two parties to the transaction respectively and Submit the original image of the HTLC protocol requirement within 10 seconds and update the status of the corresponding smart contract; among them, submit the set time of one party of the transaction first. Greater than the time set by the party submitting the transaction later .

[0021] Preferably, if the trading account is not Submit the original image required by the HTLC protocol within the set time It allows validators in other smart contracts to provide the original image required by the HTLC protocol to assist in updating the status of the smart contract.

[0022] Based on the general fair exchange protocol method and off-chain channel structure proposed in the present invention, the present invention also provides a cross-chain exchange method, which is divided into four stages: initialization, communication, exchange and closing. The first three stages are executed on each single chain; the last stage realizes cross-chain operation through cross-chain channel settlement. Beneficial Effects

[0023] The present invention utilizes the high throughput of layered channels to perform cross-chain operations. Based on the general fair exchange protocol method and the layered settlement protocol, it can effectively support efficient and fair atomic cross-chain operations in a decentralized asynchronous network. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 : is a logic diagram of a fair exchange circuit in an embodiment of the present invention; the parameters marked with a gray background in the figure are private parameters protected by zk-SNARK;

[0025] Figure 2 A diagram showing the execution steps of the general fair exchange protocol in an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of cross-chain currency exchange in an embodiment of the present invention;

[0027] Figure 4 An example diagram of a three-level hierarchical channel provided in an embodiment of the present invention;

[0028] Figure 5 The figures are the results of the transaction delay test and throughput experiment in the embodiment of the present invention, where: (a) and (b) are the delays of various transactions when m=5; (c) and (d) are the delays of various transactions when m=10; (e) is the throughput in the three scenarios of CE, FE and EIE. DETAILED DESCRIPTION

[0029] In order to facilitate the understanding of the present invention, the present invention is described in more detail below in conjunction with the accompanying drawings and specific embodiments. However, the present invention can be implemented in many different forms and is not limited to the embodiments described in this specification. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present invention more thorough and comprehensive.

[0030] The present invention proposes a general fair exchange protocol (denoted as protocol ) method to solve the unfair exchange (UE) problem, which can ensure the fairness of encrypted information exchange (EIE). Figure 2 As shown, the whole protocol consists of four stages: deployment, sharing, exchange, and recovery.

[0031] 1. Deployment: First, the sender based on Figure 1 Building a fair switching circuit Compared with the traditional fair switching circuit, Adds n key shares as private input and provides a key recovery function to recover the encryption key The reason for designing this circuit is that the protocol The (t, n)-VSS protocol is used to split the encryption key into n key shares, but the input of the traditional fair exchange circuit is the complete key, and the traditional circuit cannot prove the correctness of the key splitting. Therefore, the present invention designs , it can not only prove the correctness of the key, but also prove the correctness of the key splitting, and will not expose any key-related information. , You also need to build a security parameter , and and As input to zk-SNARK to construct a public reference string .

[0032] 2. Sharing: This process corresponds to Figure 2 Steps 1.1 to 1.9. First, Generate an encryption key , and divide it into n parts based on the splitting algorithm of the (t, n)-VSS protocol. Then, right and the key share divided into n parts Perform hash operation and package the result of hash operation, number of key shares n and key threshold t into the transaction Next, Bundle Send to smart contract Following the same process, the receiver Will , n, t, and Package into your own transaction and sends it to the smart contract .

[0033] Smart Contracts Received from both parties After that, it will randomly select n validator addresses with serial number Sn and compare each validator address with the address from and The two encryption keys are bound by the hash result of one-nth of the key share and the binding information is made public. Then and Sign their key shares with the serial number Sn and distribute the key shares to the verifiers according to the binding information. After receiving the key shares, each verifier verifies the legitimacy of the key shares based on the verification algorithm of the (t, n)-VSS protocol. In addition, each verifier recalculates the hash operation result of the received key share and compares it with The hash result in the comparison is used to avoid possible errors.

[0034] If the validator detects an error, it Time-bound smart contracts Report. The verifier will package the detected erroneous key share, the signature on the key share and the sequence number Sn into and then send it to .when get , it verifies the signature of the key share owner with the serial number sn and recalculates the hash result of the reported incorrect key share to check Is the data in the smart contract legal? If the verification is successful, the smart contract Terminate the general fair exchange protocol. Here, the sequence number Sn can be obtained by The previous key share is provided in the protocol to prevent the adversary from maliciously disrupting the execution process of the protocol.

[0035] 3. Exchange: Sender First, based on the key Calculate the objects that need to be exchanged The ciphertext This process can be achieved through some common encryption technologies, such as elliptic curve cryptography (ECC) and MIMC. Then the sender Based on zk-SNARK , and Constructing a zero-knowledge proof , to the receiver Send Message Following a similar process, Towards Send Message . Afterwards, if Figure 2 As shown in steps 2.1 and 2.3, and use The received messages are verified based on zk-SNARK and .

[0036] 4. Merger: Figure 2 As shown in steps 3.1 to 3.7 in and Verification successful, and To smart contract Send merge key request. Smart Contract from and After receiving the request, it broadcasts this event to the selected validators, who then complete the transaction Send its stored key share to the smart contract . Smart Contracts The legitimacy of each key share is verified by comparing the hash results and checking the sender's address. When the number of valid key shares is greater than the key threshold t, the smart contract The collected key shares are sent to the requester, who then recovers the key using the (t, n)-VSS protocol and further decrypts the message.

[0037] The present invention provides an off-chain channel that supports fair and atomic cross-chain operations. For convenience, currency exchange is used as an example to illustrate the general process of the present invention. Figure 3 As shown, the user In blockchain There is an account in , and the user In blockchain There is an account in . and Try to use Currency exchange In order to achieve the above goals, Need to Create an account in To obtain currency, Also need to Create a sub-account in To obtain The whole process is: and Two accounts in two blockchains ( and ,or and ) executes the hierarchical interaction protocol to establish a channel, and then sends currency in this channel. The channel is a hierarchical channel with multiple sub-channels to spend unsettled amounts. The currency exchange within the channel follows the general fair exchange protocol, which also supports fair exchange and encrypted information exchange. When the channel needs to be closed, all accounts involved in the transaction in the channel, including the accounts of the sub-channels, upload their final status to the corresponding smart contract and execute the hierarchical settlement protocol to complete the settlement.

[0038] Layered Interaction Protocol (hereinafter referred to as Protocol ): Figure 4 is a hierarchical channel. As can be seen, the entire hierarchical channel has three levels, marked as 0-2. At level 0, the user and To smart contract Sending transactions , to establish the initial state Channel , which can be expressed as For convenience, and Can be seen as and The currency stored in the account. In, users and Can send transaction receipts to each other ,in , which means that the sender Through smart contracts The amount Transfer to recipient ,in Is the message signature. It can be omitted if the context makes it clear. and Refers to.

[0039] To consume channel The unsettled amount in the channel The two parties of a transaction can negotiate to open a sub-channel. For example, Can Send a request to open a file containing the user Subchannel , with consumer transaction receipts If you get The license will generate a subchannel receipt and send it to , yes right Then, Will Send to , Need to be based on verify of the legality of The message signature carried Verify transaction amount After verification, by As its initial capital, Open subchannel , expressed as , here is a subchannel dedicated to The unsettled amount of expenditure, and No other transactions are allowed between them. As described in the above process, the two parties in the first layer and It is also possible to generate sub-channels of the second layer. Figure 4 As shown, Based on transaction receipt With users Establishing Layer 2 subchannels It is worth noting that all subchannel-related operations are off-chain operations, which means that no smart contracts are involved, thus saving blockchain resources.

[0040] The hierarchical settlement protocol designed by the present invention (referred to as protocol ) can be used for both intra-chain channel settlement and cross-chain channel settlement, with slight differences in specific implementation.

[0041] (1) Intra-chain channel settlement

[0042] The present invention uses Figure 4 The example shown is used to illustrate the intra-chain channel settlement process. First, and Towards Send a request to close the channel. After receiving the channel closing request, the smart contract Set the timer , and broadcast this event to all blockchain participants and validators, while requiring users ( , , , )According to the corresponding transaction receipt ( and ) calculate their final state { }.For example, and Need to be based on , , and Calculate their final state. Then, each participant Packaged with related receipts into a transaction , and in During the time period Send to .

[0043] go through After the time period, the smart contract Verify the correctness of uploaded data starting from layer 0. Contains all subchannel receipts agreed by the sender, smart contract Use these receipts to verify the correctness of the account balance. If verification succeeds, the smart contract The data of layer 1 will be verified. If the verification is successful, the smart contract The next level will be verified until all levels are verified. If verification fails at any level, all subchannels at that level and above will automatically fail verification. This situation prompts smart contracts to According to the received Adjust the final status of each participant in all verified layers. Finally, the validators in the blockchain update the corresponding on-chain status according to the settlement results.

[0044] (2) Cross-chain channel settlement

[0045] To support cross-chain channel settlement, the protocol The Hash Time Lock Contract (HTLC) protocol is used to ensure the atomicity of the interaction. Figure 3 As shown, for cross-chain operations, and Need to be on the blockchain and Based on the above layered interaction protocol and intra-chain layered settlement protocols, within the same blockchain ( and ,or and ) account to establish a channel and send ,create The process of establishing sub-channels and uploading the final status of each channel when the channel needs to be closed.

[0046] Different from intra-chain channel settlement, the on-chain status will be updated immediately after intra-chain channel settlement. For cross-chain operations, When it determines that the final state is valid, it runs the HTLC protocol to make and The final state is locked based on the HTLC protocol.

[0047] Then and The final settlement is completed according to the HTLC protocol. On timer Time-bound smart contracts Submit the original image required by the HTLC protocol , On timer Smart contracts within a certain period of time Submit the original image required by the HTLC protocol , used to update the status of the corresponding smart contract. or timer No one submitted the original image required by the HTLC protocol before the timeout. , the smart contract will not update the state.

[0048] However, in asynchronous networks, affected by high latency, if supply Updating the blockchain After the state in May not be available Upload within time , which breaks the atomicity of HTLC. So in order to make HTLC suitable for asynchronous networks, the present invention uses A timer is set in During this period, any validator in the blockchain can help supply To obtain of income.

[0049] Based on the hierarchical interaction protocol and the general universal fair exchange protocol proposed in the present invention, the present invention can support various cross-chain services such as currency exchange (CE), fair exchange (FE) and encrypted information exchange (EIE).

[0050] Assume user and Negotiate blockchain exchange superior Information in With blockchain superior The whole scheme can be divided into four stages: initialization, communication, exchange and closing. The first three stages are executed on each single chain, and the last stage realizes cross-chain operation through cross-chain settlement. To represent the processes that need to be executed in the three scenarios (CE, FE, EIE), use Indicates additional processes that need to be performed in some scenarios.

[0051] initialization: :In blockchain and Each account uses a unique address and a key pair. Initialize.

[0052] :Each digital goods owner based on the agreement .Deployment generates a public reference string .

[0053] communicate: : According to the agreement , ( , )and( , ) are sent separately Calling smart contracts and , build channel and , and store its initial state in the channel. The initial state is recorded as .

[0054] : and Execution of the Agreement .share to distribute their share of the key.

[0055] exchange: :aisle Allows both parties to pay instantly.

[0056] :The sender executes the protocol .The exchange encrypts the changed information, generates a zero-knowledge proof, and verifies the proof sent by the recipient. Can be based on and Generate multiple encrypted messages and through Send them to .Then Can be without exposure and Generate a zero-knowledge proof in the case of To prove and authenticity. Then Will and Figure 4 The common parameters shown are sent to . Can be used and the received public parameters to verify .

[0057] closure: : Protocol-based , all participants in the hierarchical channel need to Send transactions within the time period Upload its final state.

[0058] : Generate a preimage , and the hash result Pack in Send to . get and use Will The status is locked in In. When In blockchain Learned back, Towards send To lock in Then, in the blockchain and Set the timer in and . and Need to be separately and Provided within , to update them separately and For example Structuring a transaction To update the blockchain Once Successfully verified , You can learn ,Then exist Middle Sending transactions Update According to the HTLC protocol, Should be less than , which ensures the atomicity of the interaction process. Considering the high latency of asynchronous networks, a timer needs to be set .when Timed out and no one uploaded When , validators in other smart contracts can Provided during the time period to gain profit.

[0059] : Compared with the process in CE, Need to use As .

[0060] :Apart from , and You also need to package the key hash result into middle. and At least t key shares will be obtained from the smart contract, and they can execute the agreement .Merge to get each other's keys fairly.

[0061] The performance of the present invention was tested on a local server and Alibaba Cloud. The local server was equipped with an Intelr Xeon (R) Silver 4214R CPU @ 2.40 GHz * 16 and 78.6 GB RAM, and the system was 64-bit Ubuntu 20.04.2 LTS. 50 ecs.g6.2xlarge instances were used in Alibaba Cloud, each of which ran the Ubuntu 20.04 system, used an Intel Xeon (Cascade Lake) Platinum 8269CY processor, had 8 vCPUs with a frequency of 2.5 / 3.2 GHz and 16 GB of RAM. Each instance started 4 docker nodes to form two blockchains with 100 nodes based on the proof-of-work (PoW) consensus algorithm, and the number of transactions in each blockchain was 1,000.

[0062] 1. Transaction delay.

[0063] This example simulates an EIE scenario to test the latency of each transaction. Specifically, we first build a blockchain network with N nodes on Alibaba Cloud, and then let each node open m channels. Each channel has two levels, and the average communication time is about 100 seconds, during which users are allowed to interact in the channel. The transmission rate is set to 390MB / s. Based on the above experimental settings, we change the size of N and m to test the transaction latency, where .

[0064] Transaction delays such as Figure 5 As shown in (a), (b), (c), and (d). It can be seen that when the number of nodes increases from 10 to 100, the transaction delay increases. The reason for this trend is that the more nodes there are in the network, the longer it takes to broadcast and reach consensus on transactions. In addition, the number of channels created in the network also affects transaction delay. For example, in a network with 100 nodes, when m=5, a total of 500 channels are built between nodes, and the transaction delay is about 3.0-6.0 seconds ( Figure 5 (a), (b)). When m=10, the latency of various transactions to build 1000 channels increases to about 3.2-7.4 seconds ( Figure 5 (c), (d)). This shows that when the number of created channels increases, the number of transactions waiting in the queue increases, thereby increasing transaction latency.

[0065] 2. Throughput (TPS) and scalability.

[0066] This example simulates a dynamic equilibrium state with a fixed number of channels. In this context, the throughput and scalability of the three scenarios of CE, FE, and EIE are discussed. The unit of throughput is TPS, which refers to the number of transaction receipts that the solution can process per second. The number of open and closed channels is a dynamic variable, expressed as and In the experiment , and It does not affect the trend of the experimental results, so it is set and , ensuring that in the blockchain of N nodes, the total number of channels remains unchanged, the number of open channels and closed channels is constant, and a dynamic balance is maintained. In addition, the transmission rate of the channel is set to 390MB / s, and the test time is 100 seconds. The transaction receipt is about 130 bytes in the CE scenario and about 1.3 KB in the FE and EIE scenarios (adding encrypted data blocks and information related to zero-knowledge proofs). Based on the above data, it can be concluded that in CE, a channel can send transaction receipts, in FE and EIE, can be sent per second A transaction receipt.

[0067] Figure 5 (e) shows that the throughput of the scheme is linearly related to the network size, showing good scalability. This means that the more nodes there are in the network, the higher the system throughput. In a blockchain with N nodes, the number of channels in the network is proportional to the number of nodes, and the channels can process transaction receipts in parallel. Therefore, the overall transaction processing rate of the system is close to O(N), and the time to process the above transaction receipts increases at a rate of O(1).

[0068] The present invention introduces a new hierarchical channel structure, hierarchical settlement protocol and universal fair exchange protocol method, which solves the problems of unsettled amount congestion and unfair exchange to ensure the scalability, fairness and atomicity of cross-chain interactions; by avoiding high latency in asynchronous networks, it provides strong security and practicality.

[0069] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions only describe the principles of the present invention. The present invention may be subject to various changes and improvements without departing from the spirit and scope of the present invention. These changes and improvements fall within the scope of the present invention. The scope of protection claimed by the present invention is defined by the attached claims and their equivalents.

Claims

1. A general fair exchange protocol method, characterized in that: include: （1） Deployment: The sender builds a fair exchange circuit and security parameters; The fair exchange circuit and security parameters are used as inputs to the zero-knowledge proof to construct a public reference string ; The fair exchange circuit takes n key shares as private input; (2) Sharing: The sender and receiver generate their own encryption keys and divide them into n shares based on the splitting algorithm of the (t, n)-VSS protocol. Then, they perform a hash operation on the encryption key and the n-shared key, package the hash operation result, the number of key shares n, and the key threshold t into a transaction, and send the transaction to the smart contract. After receiving the transaction from both parties, the smart contract randomly selects n addresses of validators with serial number Sn, binds each validator's address to the hash result of one-nth of the key share of the two encryption keys from the sender and the receiver, and makes the binding information public; The sender and receiver sign their key shares with the serial number Sn and distribute the key shares to the verifier according to the binding information; After receiving the information from the sender and the receiver, each verifier recalculates the hash operation result of the key share and compares it with the hash result in the smart contract; the verification algorithm based on the (t, n)-VSS protocol is used to verify the legitimacy of the key share; (3) Exchange: The sender and receiver calculate the ciphertext of the object to be exchanged based on their respective encryption keys and , encryption key and calculated ciphertext to construct a zero-knowledge proof and send it to the other party; the sender and receiver use Verify the zero-knowledge proof of the received message respectively; (4) Merge: If the verification of both parties is successful, the sender and the receiver send a merge key request to the smart contract. After receiving the request, the smart contract broadcasts this event to the selected verifier, and the verifier sends its stored key shares to the smart contract through a transaction. The smart contract verifies the legitimacy of each key share by comparing the hash result and checking the sender's address. When the number of valid key shares is greater than the key threshold t, the smart contract sends the collected key shares to the requester, who then uses the (t, n)-VSS protocol to recover the key and further decrypt the message.

2. The general fair exchange protocol method according to claim 1, characterized in that: During the sharing phase, if the verifier detects an error, The detected erroneous key share, the signature on the key share and the serial number Sn are packaged into a report and then sent to the smart contract; when the smart contract receives the report, the signature of the key share owner is verified with the serial number Sn, and the hash result of the reported erroneous key share is recalculated to check whether the data in the report is legal; if the verification is successful, the smart contract terminates the general fair exchange protocol.

3. An off-chain channel structure that supports fair and atomic cross-chain operations, characterized by: The two parties to the transaction establish a hierarchical channel with multiple sub-channels in the same smart contract, which are recorded as Layer; the sub-channel is generated according to the transaction receipts of the two parties in the upper channel layer, and is used for the exchange of unsettled currency or encrypted information in the transaction receipts; the exchange within the channel follows the general fair exchange protocol method described in any one of claims 1-2; when the channel is closed, all accounts involved in the transaction in each channel will package their final status and related transaction receipts into one transaction, and at a set time The transaction is uploaded to the corresponding smart contract and the hierarchical settlement protocol is executed to complete the settlement; operations related to sub-channels are performed off-chain.

4. The off-chain channel structure supporting fair and atomic cross-chain operations according to claim 3 is characterized by: For intra-chain channel settlement, at the set time After that, the smart contract verifies the correctness of the uploaded data starting from layer 0; the uploaded transaction contains all sub-channel receipts agreed by the sender, and the smart contract uses these receipts to verify the correctness of the account balance; if the verification is successful, continue to verify the next layer until all levels are verified; if the smart contract fails to verify at any level, all sub-channels at that level and above will automatically fail to verify; the verifier in the blockchain updates the corresponding on-chain status based on the settlement result.

5. The off-chain channel structure supporting fair and atomic cross-chain operations according to claim 3 is characterized by: For cross-chain channel settlement, when the transaction receipt determines that the final state is valid, the HTLC protocol is run to make the accounts of both parties of the cross-chain transaction lock their final state based on the HTLC protocol, and complete the final settlement according to the HTLC protocol; The transaction parties shall set and Submit the original image of the HTLC protocol requirement within 10 seconds and update the status of the corresponding smart contract; among them, submit the set time of one party of the transaction first. Greater than the time set by the party submitting the transaction later .

6. The off-chain channel structure supporting fair and atomic cross-chain operations according to claim 5 is characterized by: If the trading account is not Submit the original image required by the HTLC protocol within the set time It allows validators in other smart contracts to provide the original image required by the HTLC protocol to assist in updating the status of the smart contract.

7. A cross-chain exchange method, characterized in that: The method is based on the fair exchange protocol method described in any one of claims 1-2 and the off-chain channel structure supporting fair and atomic cross-chain operations described in any one of claims 3-6, and is divided into four stages: initialization, communication, exchange and closing. The first three stages are executed on each single chain; the last stage realizes cross-chain exchange through cross-chain channel settlement.

Images