CN118337463A - Block chain cross-chain channel network - Google Patents

Abstract

The invention belongs to the technical field of blockchains, and particularly relates to a blockchain cross-chain channel network, which comprises a registration account and a blockchain, wherein users participate in on-chain interaction through the registration account, the cross-chain communication at least comprises three users, namely an initiator, an intermediate and a receiver, the intermediate has at least two accounts, and each of the two chains interacted with the account is provided with one registration account; the invention provides a new protocol R-HTLC to solve the problem of privacy and security conflict of cross-chain interaction. The R-HTLC contains a novel hourglass mechanism that allows nodes to spend a portion of their lock funds ahead of time against Sore Loser attacks. In addition, the R-HTLC adopts zero knowledge proof, provides a multipath refund strategy, hides Ha Xisuo, and the constraint node only plays a role of an auxiliary offline node, so that the asynchronous offline problem is solved.

Description

Block chain cross-chain channel network

Technical Field

The invention belongs to the technical field of block chains, and particularly relates to a block chain cross-chain channel network.

Background

Current cross-link schemes cannot achieve a balance between privacy protection and security in a cross-link channel network. The existing cross-link channel only allows the direct establishment of the cross-link channel between two nodes for transaction in design, and when the number of links and the number of nodes in the links are increased, the number of the channels under the links to be established is increased exponentially, so that a large amount of resources are consumed. The invention provides a new establishment mode of a cross-link channel, namely a cross-link channel network, which enables two nodes without direct cross-link channels to trade under a link by constructing a multi-hop cross-link path based on the existing channel.

The cross-chain channel network realizes the extension of the cross-chain channel, and HTLC protocol is required to ensure the correctness of inter-chain settlement, but the risk of privacy exposure is increased. The path of the nodes involved in the inter-chain interactions is related to the details of the user, and user participation in the cross-chain channel network may result in exposure of the path, specifically, exposure of the relationship between the parties to the transaction amount of the cross-chain interaction. Existing cross-chain schemes that provide path privacy protection are mostly limited to specially designed blockchain platforms, and therefore do not have versatility, and the risk of monetary exposure is ignored.

Disclosure of Invention

The invention aims to provide an efficient cross-link solution, which solves the problem of privacy and security conflict of cross-link interaction by utilizing a new protocol R-HTLC. The technical proposal is that,

A blockchain cross-chain channel network comprises a registration account and a blockchain, wherein users participate in on-chain interaction through the registration account, cross-chain communication at least comprises three users, namely an initiator A, an intermediate B and a receiver C, the intermediate has at least two accounts, and each of the two chains interacted with the account is provided with one registration account; each account corresponds to a node on the blockchain; the nodes on the blockchain include transaction nodes and verification nodes; the transaction nodes are nodes participating in a cross-link process, and form a cross-link path; the verification node is a node that executes a consensus protocol to create a new block; users participating in the cross-chain channel network need to perform on-chain and off-chain operations simultaneously, and rely on the R-HTLC protocol to ensure correctness of cross-chain interactions.

Furthermore, the user realizes the cross-link transaction of the open channel path through the under-link channel, and the transaction process of one under-link channel can be divided into three steps of opening, interaction and closing;

opening: both sides open the channel under the chain by depositing a certain amount into the intelligent contract, and establish the initial state of the channel;

Interaction: both parties interact in an in-chain manner within the channel using receipts; each receipt contains the sender's signature, the recipient's address, and the transfer amount; both parties need to execute each receipt to update the channel state, and each update state needs to be signed by both parties; each state change corresponds to a serial number, which records the sequence of each state change;

Closing: after interaction is completed, after agreement is achieved by the two parties, one party uploads the final state and then closes the channel. If the uploading party maliciously provides an error state, the other party can complain and modify to a correct state within a specified time, and the intelligent contract verifies the final state by cross checking the signature and the serial number provided by the two parties.

Furthermore, information protection is realized on a cross-chain channel network, and the security of the HTLC is enhanced by combining an hourglass mechanism and a multi-path refund strategy; the whole protocol can be divided into five steps of preparation, locking, sharing, unlocking and refund; the protocol protects privacy and enhances security by zk-SNARK, and each circuit in the protocol step is generated by zk-SNARK.

Further, the preparation steps are as follows:

initiator A of the cross-chain transfer generates two security parameters and corresponding circuitry Circuit arrangement Each output Ha Xisuo (h (s ₁₁),h(s₁₂,z₁₂),h(s₂₁)) and construct a relationship of z ₁₂ and the primary image (s ₁₁,s₁₂,s₂₁); in the circuitIn which the private input is s ₂₁, the public input is z ₁₂, and in the circuitThe two are exchanged;

Based on zk-SNARK construction process, for circuit Initiator A derives a key pair by means of security parameters and corresponding circuitryConstruction proofWherein the common inputPrivate inputInitiator a will pass through the under-link channelSend to intermediate B, intermediate B uses VerificationAccuracy of (3);

initiator A will To the recipient C, the recipient C relying on the authentication keyAnd a common inputVerificationAccuracy of (3).

Further, the locking step is as follows: initiator A constructs transaction Tx _Lock to send to smart contract ζ ^α, locks funds V _Lock based on Ha Xisuo h (s ₁₁) and h (s ₁₂,z₁₂), while setting time lock T ₁; in chain α intermediate B can unlock funds by providing a corresponding input, lock phase, ζ ^α will initiate an hourglass mechanism; the hourglass mechanism separates locked funds in the smart contract into frozen funds and available funds, with the frozen funds gradually converting over time into available funds, thereby allowing the node locking the funds to produce a plurality of commitments equal to or less than the available funds for payment purposes, the rate at which the frozen funds are converted into available funds being determined by both parties participating in the agreement.

Further, in the sharing phase, the initiator A, the intermediate B and the receiver C participating in the cross-chain interaction should check the result of frozen funds in the locking phase under the chain;

Assuming that the frozen funds for initiator A in chain alpha are M ^α and the frozen funds for intermediate B in chain beta are M ^β, receiver C constructs the circuit Receiver C derives a key pairGenerating a proof of authenticityReceiver C uses the account private keyConstruction signature for h (s ₂₁,M^β,M^α)And will be through the under-chain channelAnd a common parameter h (s ₂₁,M^β,M^α)、h(s₂₁), an amount of funds extracted M ^β、M^α to the initiator a and the intermediate B; initiator A and intermediate B authenticationAndAfter correctness of (a), the two respectively construct signature for h (s ₂₁,M^β,M^α) by using private key in chain alphaAnd intermediate B constructs a signature for h (s ₂₁,M^β,M^α) with the private key in chain βInitiator A and intermediate B exchange signature results, intermediate B willThe nodes within the same channel may obtain signatures of the results of the computations from each other, which are sent to the receiver C.

Further, during the unlocking phase, the receiver C constructs the circuitBased on the circuit, recipient C generates a proofProof and public inputPackaging into transaction Tx _Unlock, sending the transaction to smart contract ζ ^β;ξ^β for verification based on public inputAfter correctness of (a), transferring M ^β in-chain currencies to the account of the receiver C;

After the receiver C is unlocked, the intermediate B obtains the common parameter s ₂₁ and constructs the circuit Based on the circuit, intermediate B generates a proofProof and public inputPackaging into transaction Tx _Unlock, sending the transaction to smart contract ζ ^β;ξ^β for verification based on public inputAfter correctness of (a), M ^α in-chain currencies are transferred to the account of intermediate B.

Further, refund stage: in transactions Tx _Refund1 through ζ ^β, which are sent by intermediate B in chain β, ζ ^β verifies that the signature and amount of Tx _Re matches Tx _Lock, and if so, it transfers some of the available funds requested by Tx _Check to the corresponding node on chain β and transfers the remaining available funds to intermediate B.

Further, there are three cases of refund process of the remaining funds on chain α:

In the first case, the receiver C and the intermediate B successfully complete the unlocking operation within a prescribed time, acquire funds from the smart contract, and the intermediate B completes the refund flow in the chain β; initiator a then sends transactions Tx _Re to ζ ^α, ζ ^α performs a similar process to ζ ^β, transferring the remaining funds to the corresponding account; this situation indicates that the present cross-chain interaction was successful and that the available funds in the intelligent contracts on chain α and chain β are less than the initial lock amount;

In the second case, the cross-chain interaction is subject to Sore Loser attack, the receiver C and the intermediate B do not perform the unlocking operation within a prescribed time, and the intermediate B refunds the flow to be completed in the chain β; initiator a then sends transactions Tx _Refund2 and (s ₁₂,z₁₂) into ζ ^α; ζ ^α verifies if the signature and amount of Tx _Refund2 match Tx _Lock and if the hash value and h (s ₁₂,z₁₂) calculated (s ₁₂,z₁₂) are equal, if verification passes, ζ ^α sets time lock T ₃, after the end of time period T ₃, executes the same refund procedure as in the first case, in which case the available funds in the smart contracts on chains α and β are equal to the initial lock amount;

In the third case, the cross-chain interaction faces the problem of asynchronous offline, the receiver C completes the unlocking operation within a specified time, but the intermediate B fails to complete the unlocking operation, so that the initiator a may take malicious refund operation after timeout; in this case, the available funds in the smart contract on chain α are equal to the initial lock amount.

Further, it is the available funds in the chain β smart contract that are less than the initial lock amount; the initiator a may take two actions during the return:

First behavior: initiator A chooses to assist intermediate B in completing the funds unlock in chain alpha, initiator A constructs an AND circuit Circuits of identical construction and to be in common input when generating the proofReplaced byThen, the initiator A packages the certificate and the public input into a transaction Tx _Refun and sends the transaction Tx _Refun to the xi ^α;ξ^α to verify the correctness of the certificate, and then transfers funds which are required to be unlocked by the intermediate B to the account of the intermediate B, and after the transfer is finished, the refund process which is the same as the first case is executed;

Second behavior: the initiator A selects malicious retrieval fund, and sends Tx _Refund2 to ask for the fund which is transferred to the intermediate B, no matter the receiver C in the chain beta has completed unlocking operation; initiator A sends transactions Tx _Refun and (s ₁₂,z₁₂) into ζ ^α, which exposes s ₁₂ and z ₁₂, s ₂₁ being disclosed in the receiver C's unlock operation prior to this process, so that the authentication node in chain alpha can be dependent on the circuit The disclosed computational relationship between s ₁₁、s₁₂ and s ₂₁ derives s ₁₁ and initiates a complaint to ζ ^α in time T ₃ by sending transactions Tx _Appeal to ζ ^α to obtain the remaining available funds that should have been attributed to initiator a and the locked funds that should have been attributed to intermediate B.

Compared with the prior art, the beneficial effects are as follows:

The invention aims to provide an efficient cross-link solution, namely a cross-link channel network, and provides a new protocol R-HTLC to solve the problem of privacy and security conflict of cross-link interaction. The R-HTLC contains a novel hourglass mechanism that allows nodes to spend a portion of their lock funds ahead of time against Sore Loser attacks. In addition, the R-HTLC adopts zero knowledge proof, provides a multipath refund strategy, hides Ha Xisuo, and the constraint node only plays a role of an auxiliary offline node, so that the asynchronous offline problem is solved.

Drawings

Fig. 1 is an overview of a cross-chain channel network.

Fig. 2 is an exemplary diagram of a cross-chain channel network.

Fig. 3 is a circuit logic diagram of the preparation phase in the R-HTLC.

Fig. 4 is a schematic diagram of the hourglass mechanism during the lock and unlock phases.

Fig. 5 is a circuit logic diagram of the sharing phase in R-HTLC.

Fig. 6 is a circuit logic diagram of the unlock phase in R-HTLC.

Fig. 7 is Gas consumption of the present scheme across chain activity in a multi-chain environment.

Detailed Description

The present invention will be described in further detail with reference to the following examples in order to make the objects, technical solutions and advantages of the present invention more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.

A blockchain cross-chain channel network comprises a registration account and a blockchain, wherein users participate in on-chain interaction through the registration account, cross-chain communication at least comprises three users, namely an initiator A, an intermediate B and a receiver C, the intermediate has at least two accounts, and each of the two chains interacted with the account is provided with one registration account; each account corresponds to a node on the blockchain; the nodes on the blockchain include transaction nodes and verification nodes; the transaction nodes are nodes participating in a cross-link process, and form a cross-link path; the verification node is a node that executes a consensus protocol to create a new block; users participating in the cross-chain channel network need to perform on-chain and off-chain operations simultaneously, and rely on the R-HTLC protocol to ensure correctness of cross-chain interactions.

A cross-chain channel network supporting the R-HTLC protocol is shown in fig. 1. Entities participating in a cross-chain channel network need to perform both on-chain and off-chain operations.

On-chain interactions: each entity participates in-chain interactions through a registered account. An entity in the present invention refers to a user in the real world that can have multiple accounts, each account corresponding to a node on the blockchain. Further, nodes on a blockchain can be divided into two categories: a transaction node and a verification node. The transaction nodes are nodes participating in the cross-chain process, and form a cross-chain path. The validation node is the complete node that executes the consensus protocol to create the new chunk. They may execute intelligent contracts to determine the legitimacy of the uploaded information and the honest verification node will get a corresponding reward for the blockchain incentive scheme. Further, the present invention assumes that participants may initiate Sore Loser attacks, that the validation node may exhibit a byesthetic behavior in the blockchain network, and that the voting rights of the validation node are limited by a predetermined threshold to maintain the security of the blockchain consensus.

A chain down channel: each entity realizes the cross-link transaction of the open channel path through the under-link channel, the under-link channel is an extendibility solution of the block chain, the correctness of the cross-link interaction is ensured by means of R-HTLC, and a large number of transactions can be carried out in the under-link channel so as to reduce the congestion on the link. The invention utilizes the existing channel to find a cross-link path for connecting multi-cross links, thereby reducing the number of channels under the constructed links. The transaction process of one link-down channel can be divided into three steps of opening, interaction and closing.

Opening. Both parties open the under-link channel by depositing a certain amount into the intelligent contract, and establish the initial state of the channel.

And (5) interaction. Both parties interact in an in-chain fashion within the channel using receipts. Each receipt contains the sender's signature, the recipient's address, and the transfer amount. Both parties need to execute each receipt to update the channel status, each update requiring a both-party signature. Each state change corresponds to a sequence number that records the order of each state change.

And closing. After interaction is completed, after agreement is achieved by the two parties, one party uploads the final state and then closes the channel. If the uploading party maliciously provides an error state, the other party can complain and modify to a correct state within a specified time. The smart contract will verify the final state by cross checking the signature and serial number provided by both parties.

An example of a cross-chain channel network is shown in fig. 2, where the cross-chain transport consists of blockchain α and blockchain β, and an under-chain channel Ω ^α、Ω^β, where participants include Alice, bob, and Carol, who interact with registered accounts on the chain, each with a key pair (pk, vk) for sending transactions and verifying the correctness of the signature. By means of a Bob as an intermediary's path from Alice to Carol's path, alice initiates a cross-chain transfer of 10 in-chain currencies to Carol. Specifically, in chain α, alice sends 20 in-chain currencies to Bob using in-chain receipts, and 10 in-chain currencies using cross-chain receipts. In chain β, bob sends 50 in-chain currencies to Carol using in-chain receipts and 10 in-chain currencies using cross-chain receipts. After the end of the under-chain interaction, each channel uploads the final result to the blockchain, and the participants then settle the results of all channels on the chain using R-HTLC.

R-HTLC is a new protocol for enhancing HTLC, applied to implement privacy protection on a cross-chain channel network, and combines an hourglass mechanism and a multi-path refund policy to enhance HTLC security. The whole protocol can be divided into five steps of preparation, locking, sharing, unlocking and refund.

The protocol protects privacy and enhances security by zk-SNARK (zero knowledge proof), and each circuit in the protocol step is generated by zk-SNARK. The Zk-SNARK implementation steps are divided into construction, certification and verification:

And (3) construction: (pk, vk) ≡setup (1 ^λ, Λ). With the security parameter 1 ^λ and the circuit Λ as inputs, the algorithm obtains a key pair (pk, vk), where pk is the attestation key used to generate the attestation and vk is the verification key used to verify the attestation.

And (3) proving: To prove the key pk, public input And private inputAs input, a zero knowledge proof pi is generated.

And (3) verification: To verify the key vk and public input To verify proof pi, and if successful verification returns to 1, otherwise returns to 0.

The protocol illustrates the settlement process of R-HTLC across a chain channel network with the example of fig. 2.

Preparation: as shown in FIG. 3, the initiator Alice of the cross-chain transfer generates two security parameters and corresponding circuitry, the parameters of the gray background being private parameters protected by zk-SNARK. The left-hand circuit in the figure is shown asThe right side circuit is shown asThe dashed boxes represent three functions contained by the circuit, AND (logical AND), HASH (SHA-256), AND XOR (exclusive OR operation). Three hash locks (h (s ₁₁),h(s₁₂,z₁₂),h(s₂₁)) that the circuit is intended to output and construct the relationship of z ₁₂ and the original image (s ₁₁,s₁₂,s₂₁), the circuitThe constraint conditions of (c) are as follows,

XOR operation:

AND (3) AND operation: s ₁₂＝s₁₁^s₂₁;

HASH operation: h (s ₁₁)＝SHA-256(s₁₁);

h(s₁₂,z₁₂)＝SHA-256(s₁₂,z₁₂)；

h(s₂₁)＝SHA-256(s₂₁)。

Circuit arrangement The constraints of (2) are as follows:

XOR operation:

AND (3) AND operation: s ₁₂＝s₁₁^s₂₁;

HASH operation: h (s ₁₁)＝SHA-256(s₁₁);

h(s₁₂,z₁₂)＝SHA-256(s₁₂,z₁₂)；

h(s₂₁)＝SHA-256(s₂₁)。

The input of the circuit is 256-bit integer z ₁₂ and 256-bit primary image s ₂₁, in the circuit In which the private input is s ₂₁, the public input is z ₁₂, and in the circuitAnd vice versa. Based on zk-SNARK construction process, for circuitAlice may derive a key pair by means of the security parameters and corresponding circuitryFurther, construct proofWherein the common input Private inputFurther, alice will pass through the under-chain channelSend to Bob, bob usesVerificationAccuracy of (3). For electric circuitsAnd all circuits of the following steps, construction process and circuitThe same, further, alice willSent to Carol, carol relies on authentication keysAnd a common inputVerificationAccuracy of (3).

Locking: alice constructs transaction Tx _Lock to smart contract ζ ^α, locks funds V _Lock based on Ha Xisuo h (s ₁₁) and h (s ₁₂,z₁₂), and sets time lock T ₁. Bob can unlock funds in chain α by providing a corresponding entry. During the lock phase, ζ ^α will initiate the hourglass mechanism.

The hourglass mechanism separates locked funds in the smart contract into frozen funds and available funds. Over time, the frozen funds gradually convert to available funds, allowing the node locking the funds to produce a number of commitments equal to or less than the available funds for payment, the rate at which the frozen funds convert to available funds being determined by both parties participating in the agreement. As shown in fig. 4, the frozen funds are from transaction Tx _Lock sent by Alice locked funds, with the available funds set to 0 at the start time. As the available funds increase over time, alice may choose to construct transaction Tx _Check to send to ζ ^α.Tx_Check to include sender snd, receiver rcv, send amount V _cmt,ξ^α to verify that V _cmt in transaction Tx _Check is less than or equal to the available funds, The available funds are used to generate a signature of the commitment cmt= (snd, rcv, V _cmt)σ^ξ,σ^ξ is ζ ^α. ζ ^α sends the cmt to Alice, who sends the cmt to the recipient rcv. The recipient may obtain the corresponding funds based on the cmt during the refund phase of the agreement. Upon completion of Alice locking process, bob constructs transaction Tx _Lock on chain β to send to smart contract ζ ^β to lock funds V _Lock sent to Carol, set time lock T ₂(T₂<T₁) and activate the hourglass mechanism. In this process, alice and Bob send Tx _Lock and lock funds with a time difference Δt _Lock, and the period of time from Alice locking funds to Bob locking funds is affected by the hourglass mechanism, resulting in a portion of the available funds, and therefore the difference in the period of Δt _Lock should be subtracted when Bob locks funds V _Lock.

Sharing: to ensure the correctness of the unlocking, alice, bob, carol participating in the cross-chain interaction should check the outcome of frozen funds in the under-chain phase. As shown in FIG. 5, carol structure circuitThe parameters of the gray background are private parameters protected by zk-SNARK, α, β represent the blockchain to which the amount belongs, and due to the influence of the hourglass mechanism, suppose that Alice in chain α is frozen with M ^α =27 and Bob in chain β is frozen with M ^β =57.

Circuit arrangementThe constraint conditions of (c) are as follows,

HASH operation: h (s ₂₁)＝SHA-256(s₂₁);

h(s₂₁,57,27)＝SHA-256(s₂₁，57，27)。

Carol derived key pair based on circuitry Generating a proof of authenticityFurther, carol uses the account private keyConstructing a signature for h (s ₂₁, 57, 27)And will be through the under-chain channelAnd the common parameter h (s ₂₁,57,27)、h(s₂₁), the amount of funds withdrawn 57, 27 are sent to Alice and Bob. Alice and Bob authenticationAndAfter correctness of (a), the two respectively construct signature by using the private key pair h (s ₂₁, 57, 27) in the chain alphaAnd Bob constructs a signature for h (s ₂₁, 57, 27) with the private key in chain βAlice and Bob exchange signature results, bob willThe nodes sent to Carol, i.e. within the same channel, can obtain signatures of the results of the calculation from each other.

Unlocking: as shown in fig. 6, carol structure circuitThe parameters of the gray background are private parameters protected by zk-SNARK, the dashed box represents two types of functions contained by the whole circuit: HASH (HASH operation), VISG (signature verification), circuitThe constraint conditions of (c) are as follows,

HASH operation: h (s ₂₁)＝SHA-256(s₂₁);

h(s₂₁,57,27)＝SHA-256(s₂₁，57，27)；

VSIG operation:

Based on the circuit, carol generated proof Proof and public inputPackaging into transaction Tx _Unlock, sending the transaction to smart contract ζ ^β.ξ^β for verification based on public inputAfter the correctness of (1), 57 in-chain currencies are transferred to Carol's account.

After Carol is unlocked, bob obtains the common parameter s ₂₁ and constructs the circuitThe parameters of the gray background are private parameters protected by zk-SNARK, and the dashed box represents three types of functions contained in the whole circuit: XOR (exclusive OR), HASH (HASH), VISG (signature verification), circuitThe constraint conditions of (c) are as follows,

XOR operation:

HASH operation: h (s ₁₁)＝SHA-256(s₁₁);

h(s₂₁,57,27)＝SHA-256(s₂₁，57，27)；

VSIG operation:

Based on the circuit, bob generates a proof Proof and public inputPackaging into transaction Tx _Unlock, sending the transaction to smart contract ζ ^α.ξ^α for verification based on public inputAfter the correctness of (2), 27 in-chain currencies are transferred to Bob's account.

If the unlocking operation is not successfully performed, all frozen funds will gradually be transferred to available funds.

Refund: the refund stage is used to settle the remaining funds and the amount of available funds requested by Tx _Check. The multipath refund strategy provided by the R-HTLC solves the Sore Loser attack and asynchronous offline problems in the inter-link interaction of the link-down channel network. Entering the refund phase after the end of the protocol preceding steps, in Bob's send transactions Tx _Refund1 through ζ ^β in chain β, ζ ^β verifies if the signature and amount of Tx _Refun match Tx _Lock, and if so, it transfers part of the available funds requested by Tx _Check to the corresponding node on chain β and transfers the remaining available funds to Bob. There are three situations in the refund process of the remaining funds on chain alpha.

In the first case, carol and Bob successfully complete the unlocking operation within a specified time, obtain funds from the smart contract, and Bob completes the refund process in chain β. Alice then sends transactions Tx _Refund2 to ζ ^α, ζ ^α performs a similar process to ζ ^β, transferring the remaining funds into the corresponding account. This indicates that the present cross-chain interaction was successful and that the available funds in the smart contracts on chain alpha and chain beta were less than the initial lock amount.

The second case is that the cross-chain interaction is subject to Sore Loser attacks, carol and Bob do not perform the unlocking operation within a specified time, and Bob completes the refund flow in chain β. Alice then sends transactions Tx _Refund2 and (s ₁₂,z₁₂) to ζ ^α, ζ ^α verifies if the signature and amount of Tx _Refund2 match Tx _Lock, and calculates (s ₁₂,z₁₂) if the hash value and h (s ₁₂,z₁₂) are equal, if the verification passes, ζ ^α sets time lock T ₃, after the end of time period T ₃, the same refund procedure is performed as in the first case, in which case the available funds in the smart contracts on chains α and β are equal to the initial lock amount.

In the third case, cross-chain interaction faces the problem of asynchronous offline, carol completes the unlocking operation within a specified time, but Bob fails to complete the unlocking operation, so Alice may take a malicious refund after timeout. In this case, the available funds in the smart contract on chain α are equal to the initial lock amount, but the available funds in the smart contract on chain β are less than the initial lock amount. Further, alice may take two actions during the refund process.

First behavior: alice chooses to assist Bob in completing the funds unlock in chain a. Alice constructs an AND circuitCircuits of identical construction and to be in common input when generating the proofReplaced byThen Alice packs the proof and public input into transaction Tx _Refund3 and sends to ζ ^α.ξ^α to verify the correctness of the proof, transferring funds that Bob should unlock to Bob's account, and after transfer, executing the same refund flow as the first case.

Second behavior: alice chooses to maliciously retrieve funds, and sends Tx _Refun to ask for funds that should have been transferred to Bob, regardless of Carol in chain β having completed the unlock operation. Alice sends transactions Tx _Refun and (s ₁₂,z₁₂) to ζ ^α, which exposes s ₁₂ and z ₁₂, s ₂₁ being disclosed in the Carol unlock operation prior to this process, so that the authentication node in chain a can rely on the circuitThe disclosed computational relationship between s ₁₁、s₁₂ and s ₂₁ derives s ₁₁ and initiates a complaint to ζ ^α in time T ₃, sending transaction Tx _Appeal to ζ ^α to obtain the remaining available funds that should belong to Alice and the locked funds that should belong to Bob. The verification node activity in the process causes Alice to suffer loss, so that Alice is forced to select the action, and the problem of asynchronization offline is solved.

To demonstrate the feasibility of using zk-SNARK in our scheme, we conducted a comparative experiment with both schemes employing zero knowledge proof Zerocash and zkBridge on the communication cost issues associated with public data including keys, public inputs, and the proof itself. As shown in table 1, our solution maintains low communication costs even with a 12-hop count across the chain.

Table 1 comparison of communication costs for this scheme with other schemes

We further tested the Gas consumption of different cross-link activities in this scheme, as shown in table 2, we first compared our solution with the Gas consumption of other cross-link schemes in a single-cross-link hop scenario. In contrast to HTLC, the present scheme does not exhibit a linear increase with an increasing number of cross-chain operations. However, our Gas consumption is higher than Cross-Channel due to our higher security and privacy requirements. Cross-Channel only supports pairwise interactions, however, and therefore Gas consumption proportional to the square of the number of blockchains is required to meet the Cross-chain requirements of all nodes (approximately 1330858 n ², n being the number of blockchains).

TABLE 2 Gas consumption comparison of this scheme with other cross-chain schemes (pair of nodes)

Finally, we tested the effect of the number of chain hops across on Gas consumption in a multi-link environment. As shown in FIG. 7, it is shown that the Gas consumption of the present scheme is proportional to the number of blockchains.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When used in whole or in part, is implemented in the form of a computer program product comprising one or more computer instructions. When loaded or executed on a computer, produces a flow or function in accordance with embodiments of the present invention, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL), or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk Solid STATE DISK (SSD)), etc.

The foregoing description of the preferred embodiments of the invention is not intended to be limiting, but rather is intended to cover all modifications, equivalents, and alternatives falling within the spirit and principles of the invention.

Claims (10)

1. The blockchain cross-chain channel network is characterized by comprising a registration account and a blockchain, wherein a user participates in on-chain interaction through the registration account, the cross-chain communication at least comprises three users, namely an initiator A, an intermediate B and a receiver C, the intermediate has at least two accounts, and each of the two chains interacted with the account is provided with one registration account; each account corresponds to a node on the blockchain; the nodes on the blockchain include transaction nodes and verification nodes; the transaction nodes are nodes participating in a cross-link process, and form a cross-link path; the verification node is a node that executes a consensus protocol to create a new block; users participating in the cross-chain channel network need to perform on-chain and off-chain operations simultaneously, and rely on the R-HTLC protocol to ensure correctness of cross-chain interactions.

2. The blockchain cross-link channel network according to claim 1, wherein a user realizes cross-link transactions of an open channel path through a link-down channel, and the transaction process of the link-down channel can be divided into three steps of opening, interaction and closing;

opening: both sides open the channel under the chain by depositing a certain amount into the intelligent contract, and establish the initial state of the channel;

Interaction: both parties interact in an in-chain manner within the channel using receipts; each receipt contains the sender's signature, the recipient's address, and the transfer amount; both parties need to execute each receipt to update the channel state, and each update state needs to be signed by both parties; each state change corresponds to a serial number, which records the sequence of each state change;

Closing: after interaction is completed, after agreement is achieved by the two parties, one party uploads the final state and then closes the channel. If the uploading party maliciously provides an error state, the other party can complain and modify to a correct state within a specified time, and the intelligent contract verifies the final state by cross checking the signature and the serial number provided by the two parties.

3. The blockchain cross-chain channel network of claim 1, wherein information protection is implemented on the cross-chain channel network, and an hourglass mechanism and a multi-path refund strategy are combined to enhance security of the HTLC; the whole protocol can be divided into five steps of preparation, locking, sharing, unlocking and refund; the protocol protects privacy and enhances security by zk-SNARK, and each circuit in the protocol step is generated by zk-SNARK.

4. A blockchain cross-chain channel network as in claim 3 wherein the preparing step is as follows:

initiator A of the cross-chain transfer generates two security parameters and corresponding circuitry Circuit arrangement Each output Ha Xisuo (h (s ₁₁),h(s₁₂,z₁₂),h(s₂₁)) and construct a relationship of z ₁₂ and the primary image (s ₁₁,s₁₂,s₂₁); in the circuitIn which the private input is s ₂₁, the public input is z ₁₂, and in the circuitThe two are exchanged;

Based on zk-SNARK construction process, for circuit Initiator A derives a key pair by means of security parameters and corresponding circuitryConstruction proofWherein the common inputPrivate inputInitiator a will pass through the under-link channelSend to intermediate B, intermediate B uses VerificationAccuracy of (3);

initiator A will To the recipient C, the recipient C relying on the authentication keyAnd a common inputVerificationAccuracy of (3).

5. The blockchain cross-chain channel network of claim 4, wherein the locking step is as follows: initiator A constructs transaction Tx _Lock to send to smart contract ζ ^α, locks funds V _Lock based on Ha Xisuo h (s ₁₁) and h (s ₁₂,z₁₂), while setting time lock T ₁; in chain α intermediate B can unlock funds by providing a corresponding input, lock phase, ζ ^α will initiate an hourglass mechanism; the hourglass mechanism separates locked funds in the smart contract into frozen funds and available funds, with the frozen funds gradually converting over time into available funds, thereby allowing the node locking the funds to produce a plurality of commitments equal to or less than the available funds for payment purposes, the rate at which the frozen funds are converted into available funds being determined by both parties participating in the agreement.

6. The blockchain cross-chain channel network of claim 4, wherein during the sharing phase, the initiator a, intermediate B, and receiver C participating in the cross-chain interaction should check the outcome of the locked phase frozen funds under the chain;

Assuming that the frozen funds for initiator A in chain alpha are M ^α and the frozen funds for intermediate B in chain beta are M ^β, receiver C constructs the circuit Receiver C derives a key pairGenerating a proof of authenticityReceiver C uses the account private keyConstruction signature for h (s ₂₁,M^β,M^α)And will be through the under-chain channelAnd a common parameter h (s ₂₁,M^β,M^α)、h(s₂₁), an amount of funds extracted M ^β、M^α to the initiator a and the intermediate B; initiator A and intermediate B authenticationAndAfter correctness of (a), the two respectively construct signature for h (s ₂₁,M^β,M^α) by using private key in chain alphaAnd intermediate B constructs a signature for h (s ₂₁,M^β,M^α) with the private key in chain βInitiator A and intermediate B exchange signature results, intermediate B willThe nodes within the same channel may obtain signatures of the results of the computations from each other, which are sent to the receiver C.

7. The blockchain cross-chain channel network of claim 4, wherein the unlocking phase, receiver C, constructs the circuitBased on the circuit, recipient C generates a proofProof and public inputPackaging into transaction Tx _Unlock, sending the transaction to smart contract ζ ^β;ξ^β for verification based on public inputAfter correctness of (a), transferring M ^β in-chain currencies to the account of the receiver C;

After the receiver C is unlocked, the intermediate B obtains the common parameter s ₂₁ and constructs the circuit Based on the circuit, intermediate B generates a proofProof and public inputPackaging into transaction Tx _Unlock, sending the transaction to smart contract ζ ^β;ξ^β for verification based on public inputAfter correctness of (a), M ^α in-chain currencies are transferred to the account of intermediate B.

8. The blockchain cross-chain channel network of claim 4, wherein the refund phase: in transactions Tx _Refun through ζ ^β, which are sent by intermediate B in chain β, ζ ^β verifies that the signature and amount of Tx _Refun matches Tx _Lock, and if so, it transfers some of the available funds requested by Tx _Check to the corresponding node on chain β and transfers the remaining available funds to intermediate B.

9. A blockchain cross-chain channel network as in claim 8 wherein there are three cases of refund of the remaining funds on chain α:

In the first case, the receiver C and the intermediate B successfully complete the unlocking operation within a prescribed time, acquire funds from the smart contract, and the intermediate B completes the refund flow in the chain β; initiator a then sends transactions Tx _Refund2 to ζ ^α, ζ ^α performs a similar process to ζ ^β, transferring the remaining funds to the corresponding account; this situation indicates that the present cross-chain interaction was successful and that the available funds in the intelligent contracts on chain α and chain β are less than the initial lock amount;

In the second case, the cross-chain interaction is subject to Sore Loser attack, the receiver C and the intermediate B do not perform the unlocking operation within a prescribed time, and the intermediate B refunds the flow to be completed in the chain β; initiator a then sends transactions Tx _Refund2 and (s ₁₂,z₁₂) into ζ ^α; ζ ^α verifies if the signature and amount of Tx _Refund2 match Tx _Lock and if the hash value and h (s ₁₂,z₁₂) calculated (s ₁₂,z₁₂) are equal, if verification passes, ζ ^α sets time lock T ₃, after the end of time period T ₃, executes the same refund procedure as in the first case, in which case the available funds in the smart contracts on chains α and β are equal to the initial lock amount;

In the third case, the cross-chain interaction faces the problem of asynchronous offline, the receiver C completes the unlocking operation within a specified time, but the intermediate B fails to complete the unlocking operation, so that the initiator a may take malicious refund operation after timeout; in this case, the available funds in the smart contract on chain α are equal to the initial lock amount.

10. A blockchain cross-chain channel network as in claim 9 wherein the available funds in the smart contract on chain β are less than the initial lock amount; the initiator a may take two actions during the return:

First behavior: initiator A chooses to assist intermediate B in completing the funds unlock in chain alpha, initiator A constructs an AND circuit Circuits of identical construction and to be in common input when generating the proofReplaced byThen, the initiator A packages the certificate and the public input into a transaction Tx _Refun and sends the transaction Tx _Refun to the xi ^α;ξ^α to verify the correctness of the certificate, and then transfers funds which are required to be unlocked by the intermediate B to the account of the intermediate B, and after the transfer is finished, the refund process which is the same as the first case is executed;

Second behavior: the initiator A selects malicious retrieval fund, and sends Tx _Refund2 to ask for the fund which is transferred to the intermediate B, no matter the receiver C in the chain beta has completed unlocking operation; initiator A sends transactions Tx _Refun and (s ₁₂,z₁₂) into ζ ^α, which exposes s ₁₂ and z ₁₂, s ₂₁ being disclosed in the receiver C's unlock operation prior to this process, so that the authentication node in chain alpha can be dependent on the circuit The disclosed computational relationship between s ₁₁、s₁₂ and s ₂₁ derives s ₁₁ and initiates a complaint to ζ ^α in time T ₃ by sending transactions Tx _Appeal to ζ ^α to obtain the remaining available funds that should have been attributed to initiator a and the locked funds that should have been attributed to intermediate B.