Universal cross-chain payment method with scalability and without continuous online monitoring

Abstract

The application discloses a general cross-chain payment method with scalability and without continuous online monitoring, and comprises the following steps: a starting timing channel stage: the stage uses time lock and shared address technology to realize the locking of the amount, which is used for off-chain transaction and as a penalty to prevent the interaction of both parties from being evil, and realizes the starting of the channel; a payment generation and update stage: the stage continuously updates the payment through security calculation, symmetric encryption and bit operation technology, and guarantees the correctness and security of the payment update; and a payment settlement stage: the stage on-chain and completes the settlement of an effective payment based on symmetric encryption and bit operation technology, and guarantees the correctness of the settlement. The application provides a new general cross-chain payment channel method, the security of which is equivalent to that of an in-chain channel, and the channel participants do not need to be continuously online or rely on a third party.

Description

Technical Field

[0001] The present invention relates to a payment method, and in particular to a universal cross-chain payment method that is scalable and does not require continuous online monitoring. Background Art

[0002] Since its inception, blockchain, a decentralized distributed ledger technology, has been widely embraced and supported across various sectors for its unique security and immutability. Blockchain ensures data integrity and security through decentralized consensus mechanisms and cryptographic methods, significantly facilitating the exchange of digital assets. However, while the core value of blockchain lies in asset exchange, the high degree of heterogeneity among blockchain networks in terms of technical architecture, consensus algorithms, and data structures makes communication and collaboration difficult, creating the "information silos" problem. This isolation limits the cross-chain flow of assets and data, becoming a major bottleneck hindering the widespread application of blockchain technology.

[0003] When designing solutions to address scalability in cross-chain scenarios, universality is paramount. Current blockchain scalability solutions primarily focus on single-chain scenarios. On-chain scaling solutions are suitable for specific blockchains but not for cross-chain scenarios involving multiple heterogeneous blockchains. Off-chain scaling solutions, however, require expensive sidechain resources. Payment channel technology avoids the challenges of hard forks, cross-shard communication, and interoperability associated with on-chain scaling solutions, and with its low resource requirements, offers a promising solution to cross-chain scalability.

[0004] Cross-channel and CrossChannel use payment channel technology to address cross-chain scalability issues. Unfortunately, Cross-channel relies on smart contracts, while CrossChannel requires the use of a relay chain as a third party, making both approaches unsuitable for universal application. In payment channel approaches, atomicity is crucial for ensuring correct execution. Generalized channels and Sleepy Channels rely on the characteristics of UTXO transactions for atomicity, while solutions like Tumblebit rely on the "Tumbler" in the payment channel hub. In cross-chain scenarios, blockchain models should not be constrained; they should neither be required to be based on the UTXO model nor be expected to have a payment channel hub. Ensuring atomicity during method execution is crucial for achieving universality.

[0005] Besides universality, user online requirements are a second key concern. HTLC-based payment channel methods, such as the Lightning Network, place high online requirements on both parties in the channel. Users must constantly monitor blockchain status to prevent malicious transactions from the other party, placing a significant burden on them. This burden is further exacerbated in cross-chain scenarios, where users must monitor the status of both chains simultaneously to prevent malicious activity. Existing research has not yet provided an ideal solution, typically introducing third-party "watchtowers" to help channel participants monitor the blockchain. Sleepy channels are the first bidirectional payment channel method that does not require channel parties to be constantly online, additional participants (even watchtowers), or additional trust assumptions. Unfortunately, however, they only work with the UTXO model and require additional collateral to meet the "no need for channel parties to be constantly online" requirement. Summary of the Invention

[0006] To address the deficiencies in the existing technology, this paper innovatively proposes a new universal cross-chain payment channel method, CCPC (Cross-Chain Payment Channels). CCPC offers security comparable to intra-chain channels, and does not require channel participants to be continuously online or rely on third parties. The technical solution is as follows: A new universal cross-chain payment channel method includes a timed channel opening phase, a payment generation and update phase, and a payment settlement phase. Its characteristics are:

[0007] Opening a timed channel: This phase uses time locks and shared address technology to lock the amount of money. This amount is used for off-chain transactions and as a penalty to prevent malicious behavior by both parties and to open the channel.

[0008] Fund generation and update stage: This stage continuously updates funds through secure computing, symmetric encryption, and bitwise operation technology to ensure the accuracy and security of fund updates;

[0009] Settlement stage: This stage uses symmetric encryption and bit operation technology to put a valid payment on the chain and complete the settlement to ensure the accuracy of the settlement.

[0010] The present invention also discloses a new universal cross-chain payment channel device, which is characterized by:

[0011] Opening the timed channel phase module: This phase uses time locks and shared address technology to lock the amount. This amount is used for off-chain transactions and as a penalty to prevent malicious behavior by both parties and to open the channel.

[0012] Generate and update payment phase module: This phase continuously updates payment through secure computing, symmetric encryption, and bitwise operation technology to ensure the accuracy and security of payment updates;

[0013] Settlement payment stage module: This stage uses symmetric encryption and bit operation technology to put a valid payment on the chain and complete the settlement to ensure the correctness of the settlement.

[0014] Beneficial effects

[0015] This invention reduces the number of transactions on-chain by updating funds off-chain, thereby addressing scalability issues in cross-chain scenarios. The method design prevents "multiple settlement attacks" and "interleaved settlements" caused by atomicity violations while also meeting the requirement of "not requiring channel parties to be constantly online." BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flow chart of the new universal cross-chain payment channel method of the present invention;

[0017] Figure 2 This is a schematic diagram of the generation and destruction modules of the present invention. DETAILED DESCRIPTION

[0018] 1. Problem Description

[0019] A payment channel is established between two users (e.g., Channel Party A and Channel Party B), who each deposit a certain amount of funds to open the channel. This channel allows both parties to conduct multiple transactions off-chain, such as the first transaction, the second transaction, and so on, until either party decides to close the channel, ultimately broadcasting the latest transaction to the blockchain.

[0020] The correct execution of the payment channel is inseparable from atomicity, that is, users must either honestly settle in a certain agreed state and close the channel, or be punished for malicious behavior. In order to better illustrate the problems that may arise from the destruction of atomicity in cross-chain payment channels, this paper describes it through a specific cross-chain payment channel scenario. Assume that channel party A is on the blockchain. 10 coins are staked on the blockchain. A cross-chain payment channel is established by staking 5 coins. The current channel state can be represented as {A:10-(10,0), B:5-(0,5)}. Within this channel, channel partners A and B can perform any number of off-chain transactions to update the channel state. It is worth noting that during the channel state update process, to ensure at least one valid channel state exists, a brief period occurs during which both payment i and payment i+1 are valid. Similar to single-chain payment channels, to ensure that both parties maintain control of the channel state, balance updates generate two versions: version A (controlled by channel partner A) and version B (controlled by channel partner B).

[0021] The first problem we face is called "multiple settlement attack". Assume that both parties have generated the latest channel status, that is, the i-th payment. At this time, channel party A pays 4 coins to channel party B, and channel party B pays 1 coin to channel party A. Therefore, the channel status is Normally, when channel party A wishes to settle with the i-th payment, channel party A first publishes version A. , then channel party B releases version A , in order to complete the settlement. However, since the coins are located in different addresses in the two chains, channel party B can re-publish the , so that the settlement process is repeated. Although channel party A can also re-release version B However, this behavior of settling with twice the amount goes against the original intention of closing the channel with the settlement of the i-th payment.

[0022] The second problem is the "interleaved settlement phenomenon". Suppose that in the i+1th payment, channel party A paid 5 coins to channel party B, and channel party B paid 3 coins to channel party A; at this time, the channel status is updated to During the payment update period, one party (such as channel party A) attempts to initiate a settlement application with the i-th payment (sending ), and the other party (such as channel party B) initiates a settlement application with the i+1th payment (sending ), which can lead to situations where the channel cannot be closed with the correct settlement amount.

[0023] 2. Technical Solution

[0024] The CCPC method reduces the number of transactions on-chain by updating funds off-chain, thereby solving the scalability problem in cross-chain scenarios. During the design process, the method prevents "multiple settlement attacks" and "interleaved settlement phenomena" caused by atomicity violations while meeting the requirement of "not requiring channel parties to be continuously online." The technical solution is as follows:

[0025] like Figure 1 As shown, the CCPC method consists of three operations: opening a timed channel, generating and updating funds, and settling funds. Both parties pledge coins to open the timed channel. New funds are generated off-chain, and old funds are destroyed to complete the fund update. The latest funds are then uploaded to the chain to settle the funds. After the specified time, the channel is automatically closed.

[0026] Opening a timed channel phase: This phase uses time locks and shared address technology to lock the amount of money, which is used for off-chain transactions and as a penalty to prevent the two parties from doing evil and to open the channel. Channel party A and channel party B first determine the time required for the channel. 、 、 and , . It is the time when channel party A closes the settlement initiation function. It is the time when channel party B closes the settlement initiation function. is the trial time (i.e. the user can The penalty for illegal transactions is completed before the time limit. Is the pledge time of the collateral (used to punish evil behavior), which is the longest time and is used to ensure the enforceability of the punishment. After that, the two parties generate a series of shared addresses on the two blockchains. After both parties stake the agreed amount in the corresponding shared addresses, the timed channel is considered to be successfully opened.

[0027] Payment generation and update phase: This phase continuously updates payments through secure computing, symmetric encryption, and bitwise operations to ensure the accuracy and security of payment updates. Each payment includes version A and version B. The two versions have the same structure and function. Channel A can actively initiate a payment request through version A. Similarly, channel B can actively initiate a payment request through version B. Each version contains three transactions. In the i-th payment, Belongs to version A, Belongs to version B. The transaction causes the sender to wait until After a certain time, you will get coins. The sender can directly obtain coins. The transaction ends the sender The three transactions in each version have a sequential dependency relationship (i.e., after the send transaction is released, the Fsend transaction can be released; after the Fsend transaction is released, the payout transaction can be released), thus achieving the function of "allowing channel parties to be not continuously online". For the generation of the first payment, both parties generate 、 , then generate 、 , and finally generate 、 . For subsequent update operations on funds, both parties use the "Generation and Destruction Module" to generate new funds and destroy old funds. The "Generation and Destruction Module" ensures the atomicity of the update process, thereby avoiding the occurrence of "multiple settlement attacks" and "interleaved settlement phenomena". Simply put, corresponding penalty transactions are generated for old funds and "multiple settlement attacks". For the "interleaved settlement phenomenon", when channel party A uses the i-th payment to initiate a settlement request, channel party B is granted the right to perform the following atomic operations: "Reject the request to initiate settlement with the i-th payment, and grant the right to settle with the i+1-th payment". The detailed method design will further introduce the specific structure of this module.

[0028] Settlement stage: This stage uses symmetric encryption and bit operation technology to put a valid payment on the chain and complete the settlement to ensure the accuracy of the settlement. Figure 1 The operation of using the i+1th payment for settlement is shown in the figure. Taking the channel party A as an example to introduce the specific operation of the settlement, channel party A first initiates the Make yourself Obtained after a period of time After the transaction is put on the chain, channel party B first checks the legality of the transaction. If it is legal, channel party B sends Get it now , and channel party A sees Can be sent after being uploaded to the chain , thus ending the wait and immediately obtaining For channel party B, he can also actively initiate the settlement operation through version B.

[0029] 3. CCPC Program Implementation

[0030] 3.1 Background: Time-Verifiable Signatures (VTS)

[0031] For a generator and order Group ,Time Verifiable Signature (VTS) contains four algorithms: , as follows:

[0032] The commitment algorithm is a random process that takes as input a discrete logarithm value and hidden time , outputs a promise and a proof In simple terms, this algorithm is equivalent to the value Make a "cryptographic commitment" and attach a proof.

[0033] :Verify that the input of the algorithm is a group element ,promise (including "difficulty and proof Its output is either 0 or 1 if and only if the value in the promise satisfy , output 1, otherwise output 0.

[0034] :The public algorithm is run by the committed party, and the input is the committed , the output is the value originally promised and the random number used to generate the commitment .

[0035] : Enforcing the public input of the algorithm is a commitment , output a discrete logarithm value .

[0036] 3.2 Method Flow

[0037] The method assumes that channel party A and channel party B are in the blockchain and There is a need for cross-chain transactions between channel parties A and B. and All have accounts.

[0038] 3.2.1 Opening a timing channel

[0039] Step 1: Channel A and Channel B first agree on the amount of money they will use. and , and the amount of the honesty deposit and ;Select the time required for the channel 、 、 and ; . It is the time when channel party A closes the settlement initiation function. It is the time when channel party B closes the settlement initiation function. is the trial time (i.e. the user can Punishment for illegal transactions completed before the time limit) is the pledge time of the collateral (used to punish evil behavior), the channel is After this time, it is considered closed automatically.

[0040] Step 2: Both parties in the blockchain Generate a shared address 、 、 ; In the blockchain Generate a shared address 、 、 .by Introduce the steps to generate a shared address:

[0041] The subscript of the shared address indicates that it is in the blockchain The superscript indicates that it belongs to channel party A after time T.

[0042] 1. In the blockchain The public and private key pairs are calculated together , both parties share the public key , channel party A holds part of the private key , channel party B holds part of the private key , Depend on and Calculated by combination.

[0043] 2. Channel B calculation -- (describe in words, this writing is not clear, and the meaning of VTS is not clear), where represents the commitment operation in a time-verifiable signature, is the initial time parameter. Channel party B will commit to the value and proof Send to channel party A;

[0044] 3. Channel Party A uses the verification operation in the time-verifiable signature To verify, the verification algorithm will group elements , time parameters Commitment and proof as input, and if and only if the embedding The value in satisfy Output 1. Otherwise, output 0. After verification, it is considered a shared address. Successfully generated, That is , Then The key of

[0045] 4. When generating other shared addresses, both parties will re-specify time parameters and roles and repeat the above three steps.

[0046] Step 3: Both parties generate the following transaction: , this transaction means that channel party A takes out a value of Funds are deposited into the initial shared address superior. , this transaction means that channel party B takes out a value of Funds are deposited into the initial shared address Similar generation pledge transactions are used for pledge margin. , .

[0047] When all four transactions are successfully recorded on their respective blockchains, the cross-chain payment channel is considered to be successfully opened. The initial state of the channel is: This state indicates that for channel party A, the state Indicates that he is in the channel blockchain The initial capital is , in the blockchain The initial capital is 0; for channel party B, the state Indicates that he is in the channel blockchain The initial capital is 0, in the blockchain The initial capital is .

[0048] Step 4: After the specified time, both parties use the calculated sk to retrieve the remaining amount in the shared address, and the channel is closed.

[0049] 3.2.2 Generate and update funds

[0050] Each payment consists of two versions, version A and version B. Each version contains three transactions. To better illustrate the following steps, we will rename the real signatures corresponding to these transactions. Let's take the transaction of the i-th payment as an example. For version B, Make from Transfer to The corresponding real signature is ; Make from Transferred to channel party A, its corresponding real signature is ; Make from It is immediately transferred to the hands of channel party B, and its corresponding real signature is For version A, Make from Transfer to The corresponding real signature is ; Make from Transferred to channel party B, its corresponding real signature is ; Make from It is immediately transferred to the hands of channel party A, and its corresponding real signature is .

[0051] Each payment contains two versions, version A is controlled by channel party A, and version B is controlled by channel party B; each version contains three transactions, namely 、 、 . Used to initiate a settlement request. Response to settlement request. Used to complete the settlement after receiving the response. The specific construction is detailed in the following steps:

[0052] Step 1: Generate the first payment off-chain.

[0053] The locked signature refers to the signature after encryption transformation. Represents one-time password encryption, where the encryption key is , the encrypted content is , H is the hash function;

[0054] The superscript indicates that it is a transaction in version A of the first payment, and the subscript indicates that it is Transaction, its transfer is from A to B, The specific content refers to the settlement amount of the first payment channel party B , from the shared address Transfer to the address controlled by channel party B;

[0055] Subsequent transactions generated with The description is similar to:

[0056] The superscript indicates that it is a transaction in version B of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from B to A, The specific content refers to the amount of the first payment belonging to channel party A , from the shared address Transfer to the address controlled by channel party A;

[0057] The superscript indicates that it is a transaction in version A of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from B to A, The specific content refers to the amount of the first payment belonging to channel party A , from the shared address Transfer to shared address middle go;

[0058] The superscript indicates that it is a transaction in version B of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from A to B, The specific content refers to the amount of the first payment belonging to channel party B , from the shared address Transfer to shared address middle go;

[0059] The superscript indicates that it is a transaction in version A of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from A to A, The specific content refers to the amount of the first payment belonging to channel party A , from the shared address Transfer to the address controlled by channel party A;

[0060] The superscript indicates that it is a transaction in version B of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from B to B, The specific content refers to the amount of the first payment belonging to channel party B , from the shared address Transfer to the address controlled by channel party B;

[0061] 1. Both parties are formed first (Corresponding to the real signature )、 (Corresponding to the real signature ), and their corresponding locking signatures , that is, channel party B holds, , that is, channel party A holds; generate 、 , and their corresponding signatures , that is, channel party A holds, , which is held by channel party B;

[0062] 2. Generate (Corresponding to the real signature )、 (Corresponding to the real signature ), and their corresponding locking signatures , channel party A holds, , held by channel party B;

[0063] Step 2: Off-chain, the "Generation and Destruction Module" is used to continuously destroy old funds and generate new funds. The i-th "Generation and Destruction Module" is used to illustrate the process of destroying the i-th payment and generating the i+1th payment.

[0064] The transaction generated here is similar to the transaction description in the first payment:

[0065] and The description is similar, the superscript indicates that it is a transaction in version A of the i+1th payment, and the subscript indicates that it is Transaction, its transfer is from A to B, The specific content refers to the settlement amount of the channel party B of the i+1 payment , from the shared address Transfer to the address controlled by channel party B; the subsequent transaction structure and meaning are similar to the above steps.

[0066] Represents the absolute value of the difference between the settlement amount of channel B for the i+1th payment and the settlement amount of channel B for the ith payment, used in the following The structure of the transaction; The superscript represents the i-th “generation and destruction module”, and the subscript represents the transaction name. The specific content refers to the value of Amount from shared address Transfer to shared address middle go;

[0067] for The locking signature of , the encrypted content is , stands for one-time password encryption, H is the hash function;

[0068] for The lock signature here Represents a symmetric encryption algorithm. The first parameter is the encryption key, which is composed of It is calculated that here It still represents one-time password encryption, H is still the hash function, and the second parameter is the encrypted content. The subsequent locking signature parameter description is similar to the above content;

[0069] 1. Both parties generate 、 and their corresponding locking signatures (Hold by channel party B), (Hold by channel party A).

[0070] 2. This step is to prevent A protective measure taken after the phenomenon of atomicity destruction occurred.

[0071] 2.1 Order ,like , then both parties generate a transaction ; Otherwise, generate transaction . Then jointly generate a locking transaction , both parties hold this locking signature.

[0072] 2.2 Both parties jointly generate transactions , and its locking signature , both parties hold this locking signature.

[0073] 2.3 Both parties jointly generate transactions , and its locking signature , held by channel party B.

[0074] 2.4 Both parties jointly generate transactions , and its locking signature , held by channel party A.

[0075] 2.5 Both parties jointly generate transactions and its locking signature 、 、 , all held by channel party B.

[0076] 2.6 Both parties jointly generate transactions , and its locking signature , held by channel party B.

[0077] 2.7 Both parties jointly generate transactions , and its locking signature , held by channel party A.

[0078] 3. Jointly generated by both parties , and its corresponding signature (held by channel party A).

[0079] 4. Both parties jointly generate a locking signature (held by channel party B), this locking signature is used to destroy .

[0080] 5. Jointly generated by both parties , and its corresponding signature (held by channel party B).

[0081] 6. Both parties jointly generate a locking signature (held by channel party A), this locking signature is used to destroy .

[0082] 7. Both parties jointly generate transactions 、 and their corresponding locking signatures (Hold by channel party B), (Hold by channel party A).

[0083] At this stage, both parties continuously cycle through the second step off-chain to update the payment.

[0084] 3.2.3 Settlement Payment

[0085] The two parties agree that one party will initiate the settlement request. Suppose channel party A initiates the settlement with i+1 valid payments.

[0086] The first step is Before time, channel party A first initiates the Make from Transfer to Published to the blockchain , initiate a request for settlement with the i+1th payment.

[0087] In the second step, channel party B After a moment, Check before time The correctness of the transaction, and the channel party B first checks the legitimacy of the transaction. If it is legal, the channel party B can pass the signature of the transaction. Calculated , channel party B sends Can be obtained from get .

[0088] Step 3: Channel A sees After the chain is on, it can be Signature Calculated , thus sending , making from It is immediately transferred to the hands of channel party A.

[0089] The payment has been settled successfully.

[0090] For channel party B, he can also actively initiate the settlement operation through version B. The above settlement operation is designed to provide convenience for both parties in the channel. Before the time, check whether channel party A is malicious and publish it after checking , both parties can complete the settlement. If the channel A reacts before the judgment moment, it can still Afterwards, I got .

[0091] 3.3 Explanation of the “Creating and Destroying Modules” steps.

[0092] In the first step, both parties first generate and , these two transactions are the contents of i+1 payments.

[0093] The second step is to prevent A protective measure taken after the atomicity is destroyed. Afterward, both parties have the ability to initiate settlement with the i-th payment, and channel partner A also has the ability to initiate settlement with the i+1th payment. To prevent "cross-settlement," steps 2.1-2.3 of 3.2.2 grant channel partner A the right to withdraw channel partner B's request to settle with the i-th payment. Upon withdrawal, channel partner B will gain the right to settle with the i+1th payment. A corresponding penalty transaction is signed to ensure the atomicity of the method is not affected. Steps 2.4-2.7 of 3.2.2 generate redemption transactions (reclaiming the funds involved in the malicious activity) and penalty transactions to prevent malicious actors.

[0094] For 2.1-2.3: First compare and The size of , thereby generating the corresponding prepare to withdraw transaction .if , then generate , so that channel party A can first withdraw aux, and then it is considered that channel party B settles with the amount of i+1 payment. , then generate , so that channel party B can get aux again, so that channel party B can settle with the amount of i+1 payments.

[0095] and Lock signature Held by two people, when aux is withdrawn or obtained, channel party B must know .

[0096] At this time, if channel party B needs to use To obtain i+1 payments again, channel party A can use When redeeming an amount i+1, both parties will finally settle the account with the amount i+1.

[0097] This is a solution created to prevent the malicious behavior of Phenomenon 1 from happening.

[0098] 1. Phenomenon 1: When channel party B initiates a request to settle with the i-th payment, channel party A withdraws it. After both parties settle with the i+1 payment, channel party A sends , accept the i-th payment, thereby attempting to obtain the entire amount of the i-th payment.

[0099] Solution 1: When the above phenomenon occurs, channel B can , to get back your portion of the i+1 payment and pass Channel Party A is punished. However, Channel Party B still loses the amount of i payments. To solve this problem, both parties generate a reverse transaction. and its corresponding locking signature Therefore, after this phenomenon occurs, channel party B can still get his share of the i-th payment. The final settlement is the i-th payment, and channel party A is punished.

[0100] 2. Phenomenon 2: After both parties settle the payment using version B of the i+1th payment, channel party B releases Perform a "double settlement attack." Corresponding to 2.4

[0101] Solution 2: Generate both sides and the corresponding locking signature When channel party B publishes When channel A can calculate ,make coins from Back to A's hands.

[0102] 3. Phenomenon 3: After both parties settle the i-th payment using version A, channel party A then releases Perform a "double settlement attack". Corresponding to 2.5

[0103] Solution 3: Generate on both sides And the corresponding locking signature When channel party A publishes , channel party B can calculate ,make coins from Return to B's hands.

[0104] 4. Phenomenon 4: After both parties settle the i-th payment using version B, channel party A releases Perform a "double settlement attack". Corresponding to 2.5

[0105] Solution 4: Both parties are again Generate locking signature 、 When channel party A publishes , channel party B can calculate ,make coins from Return to B's hands; when channel party A releases , channel party B can calculate ,make coins from Return to B's hands.

[0106] For 2.6-2.7, and After channel party A commits a crime, channel party B publishes To get back the amount of money that was used to commit evil, and at the same time publish To punish channel party A. Similarly, and After channel party B does something malicious, channel party A publishes To get back the amount of money that was used to commit evil, and at the same time publish To punish channel party B.

[0107] The third step is to generate This transaction contains the content of the i+1th payment. Channel party A can initiate a settlement request with the i+1th payment. Since the protection measures in the second step have been completed, the generation of this step will not destroy atomicity.

[0108] The fourth step is to destroy version A of the i-th payment. When channel party A initiates a settlement request with the i-th payment, it will receive a penalty.

[0109] Step 5: Generate This transaction contains the i+1 payment. Channel party B can initiate a settlement request with the i+1 payment.

[0110] The sixth step is to destroy version B of the i-th payment. When channel party B initiates a settlement request with the i-th payment, it will receive a penalty.

[0111] Step 7: Generate Transaction and And their corresponding locking signatures and This transaction is the content of i+1 payment.

[0112] At this point, the entire process of the i-th "generation and destruction module" is completed. Both parties successfully destroyed the i-th payment and generated the i+1-th payment.

[0113] This invention reduces the number of transactions on-chain by updating funds off-chain, thereby addressing scalability issues in cross-chain scenarios. The method design prevents "multiple settlement attacks" and "interleaved settlements" caused by atomicity violations while also meeting the requirement of "not requiring channel parties to be constantly online."

[0114] 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 merely illustrate the principles of the present invention. Various changes and modifications may be made to the present invention without departing from the spirit and scope of the present invention. Such changes and modifications are intended to fall within the scope of the present invention. The scope of protection claimed by the present invention is defined by the appended claims and their equivalents.

Claims

1. A new universal cross-chain payment channel method, including the phases of opening a timed channel, generating and updating funds, and settling funds, characterized by: Opening a timed channel: This phase uses time locks and shared address technology to lock the amount of money. This amount is used for off-chain transactions and as a penalty to prevent malicious behavior by both parties and to open the channel. Fund generation and update stage: This stage continuously updates funds through secure computing, symmetric encryption, and bitwise operation technology to ensure the accuracy and security of fund updates; Settlement stage: This stage uses symmetric encryption and bit operation technology to put a valid payment on the chain and complete the settlement to ensure the accuracy of the settlement; The timing channel opening phase includes the following: Step 1: Channel A and Channel B first agree on the amount of money they will use. and , and the amount of the honesty deposit and ;Select the time required for the channel 、 、 and ; ; It is the time when channel party A closes the settlement initiation function. It is the time when channel party B closes the settlement initiation function. is the trial time, that is, the user can Complete the punishment for illegal transactions before the deadline; It is the pledge, which is used to punish the evil behavior. The channel is After that time, it is considered to be automatically closed; Step 2: Both parties in the blockchain Generate a shared address 、 、 ; In the blockchain Generate a shared address 、 、 ; Steps to generate a shared address: The subscript of the shared address indicates that it is in the blockchain The superscript indicates that it belongs to channel party A after time T; (1) In blockchain The public and private key pairs are calculated together , both parties share the public key , channel party A holds part of the private key , channel party B holds part of the private key , Depend on and Calculated by combination; (2) Channel B calculation ,in represents the commitment operation in a time-verifiable signature, is the initial time parameter; channel party B will commit to the value and proof Send to channel party A; (3) Channel party A uses the verification operation in the time-verifiable signature To verify, the verification algorithm will group elements , time parameters Commitment and proof as input, and if and only if the embedding The value in satisfy Output 1 when it is valid, otherwise output 0; after verification, it is considered a shared address Successfully generated, That is , Then The key of (4) When generating other shared addresses, both parties will re-specify the time parameters and roles and repeat the above three steps; Step 3: Both parties generate the following transaction: , this transaction means that channel party A takes out the value of Funds are deposited into the initial shared address superior; , this transaction means that channel party B takes out a value of Funds are deposited into the initial shared address Similar generation of pledge transactions is used for pledge margin , ; When all four transactions are successfully recorded on their respective blockchains, the cross-chain payment channel is considered to be successfully opened. The initial state of the channel is: ; This state indicates that for channel party A, the state Indicates that it is in the channel blockchain The initial capital is , in the blockchain The initial capital is 0; for channel party B, the state Indicates that it is in the channel blockchain The initial capital is 0, in the blockchain The initial capital is ; Step 4: After the specified time, both parties use the calculated sk to retrieve the remaining amount in the shared address, and the channel is closed; The generation and update of funds phase includes the following: Each payment contains two versions, version A is controlled by channel party A, and version B is controlled by channel party B; each version contains three transactions, namely 、 、 ; Used to initiate a settlement request. Response to settlement request. Used to complete settlement after receiving the response. The specific construction is detailed in the following steps: Step 1: Generate the first payment off-chain: The locked signature refers to the signature after encryption transformation. Represents one-time password encryption, where the encryption key is , the encrypted content is , H is the hash function; The superscript indicates that it is a transaction in version A of the first payment, and the subscript indicates that it is Transaction, its transfer is from A to B, The specific content refers to the settlement amount of the first payment channel party B , from the shared address Transfer to the address controlled by channel party B; Subsequent transactions generated with The description is similar to: The superscript indicates that it is a transaction in version B of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from B to A, The specific content refers to the amount of the first payment belonging to channel party A , from the shared address Transfer to the address controlled by channel party A; The superscript indicates that it is a transaction in version A of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from B to A, The specific content refers to the amount of the first payment belonging to channel party A , from the shared address Transfer to shared address middle go; The superscript indicates that it is a transaction in version B of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from A to B, The specific content refers to the amount of the first payment belonging to channel party B , from the shared address Transfer to shared address middle go; The superscript indicates that it is a transaction in version A of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from A to A, The specific content refers to the amount of the first payment belonging to channel party A , from the shared address Transfer to the address controlled by channel party A; The superscript indicates that it is a transaction in version B of the first payment, and the subscript indicates that it is Transaction, the flow of funds in the transaction is from B to B, The specific content refers to the amount of the first payment belonging to channel party B , from the shared address Transfer to the address controlled by channel party B; (1) Both parties first form , corresponding to the real signature 、 , corresponding to the real signature , and their corresponding locking signatures , which is held by channel party B; , that is, channel party A holds; (2) Generate 、 , and their corresponding signatures , that is, channel party A holds; , which is held by channel party B; (3) Generate , corresponding to the real signature 、 , corresponding to the real signature , and their corresponding locking signatures , held by channel party A; , held by channel party B; Step 2: Continuously destroy old funds and generate new funds through the "Generation and Destruction Module" off-chain; the process of destroying the i-th payment and generating the i+1th payment is explained using the i-th "Generation and Destruction Module": The transaction generated here is similar to the transaction description in the first payment: and The description is similar, the superscript indicates that it is a transaction in version A of the i+1th payment, and the subscript indicates that it is Transaction, its transfer is from A to B, The specific content refers to the settlement amount of the channel party B of the i+1 payment , from the shared address Transfer to the address controlled by channel party B; the subsequent transaction structure and meaning are similar to the above steps; Represents the absolute value of the difference between the settlement amount of channel B for the i+1th payment and the settlement amount of channel B for the ith payment, used in the following The structure of the transaction; The superscript represents the i-th "generation and destruction module", and the subscript represents the transaction name. The specific content refers to the value of Amount from shared address Transfer to shared address middle go; for The locking signature of , the encrypted content is , stands for one-time password encryption, H is the hash function; for The lock signature here Represents a symmetric encryption algorithm. The first parameter is the encryption key, which is composed of It is calculated that here It still represents one-time password encryption, H is still the hash function, and the second parameter is the encrypted content. The subsequent locking signature parameter description is similar to the above content; (1) Both parties generate 、 and their corresponding locking signatures , channel party B holds, , held by channel party A; (2). This step is to prevent The protective measures taken after the phenomenon of destroying atomicity occurs: (2-1). ,like , then both parties generate a transaction ; Otherwise, generate transaction ; Then jointly generate a locking transaction , both parties hold this locking signature; (2-2) Both parties jointly generate transactions , and its locking signature , both parties hold this locking signature; (2-3) Both parties jointly generate transactions , and its locking signature , held by channel party B; (2-4) Both parties jointly generate transactions , and its locking signature , held by channel party A; (2-5) Both parties jointly generate transactions and its locking signature 、 、 , all held by channel party B; (2-6) Both parties jointly generate transactions , and its locking signature , held by channel party B; (2-7) Both parties jointly generate transactions , and its locking signature , held by channel party A; (3) Jointly generated by both parties , and its corresponding signature , held by channel party A; (4) Both parties jointly generate a locking signature , held by channel party B, this locking signature is used to destroy ; (5) Jointly generated by both parties , and its corresponding signature , held by channel party B; (6) Both parties jointly generate a locking signature , held by channel party A, this locking signature is used to destroy ; (7) Both parties jointly generate transactions 、 and their corresponding locking signatures , channel party B holds, , held by channel party A; At this stage, both parties continuously cycle through the second step off-chain to update the payment; The payment settlement phase includes the following: The first step is Before time, channel party A first initiates the Make from Transfer to Published to the blockchain , initiate a request for settlement with the i+1th payment; In the second step, channel party B After a moment, Check before time The correctness of the transaction, and the channel party B first checks the legitimacy of the transaction. If it is legal, the channel party B can pass the signature of the transaction. Calculated , channel party B sends Can be obtained from get ; Step 3: Channel A sees After the chain is on, it can be Signature Calculated , thus sending , making from It is immediately transferred to the hands of channel party A.

2. The new universal cross-chain payment channel method according to claim 1 is characterized by: The generation and destruction modules include the following: In the first step, both parties first generate and , these two transactions are the contents of i+1 payment; The second step is to prevent The protective measures taken after the phenomenon of atomicity destruction occurs; After that, both parties have the ability to initiate settlement with the i-th payment, and channel party A also has the ability to initiate settlement with the i+1-th payment; the above steps (2-1) to (2-3) are to prevent the occurrence of "staggered settlement phenomenon", giving channel party A the right to "withdraw channel party B's settlement request with the i-th payment". At the same time, channel party B will obtain the right to settle with the i+1-th payment after the request is withdrawn; the corresponding penalty transaction is signed to ensure that the atomicity of the method is not affected; the above steps (2-4)-(2-7) are redemption transactions and penalty transactions generated to prevent malicious phenomena.

3. The new universal cross-chain payment channel method according to claim 2 is characterized in that Above steps (2-1) to (2-3): First compare and The size of , thereby generating the corresponding prepare to withdraw transaction ;if , then generate , so that channel party A can first withdraw aux, then it is considered that channel party B settles with the amount of i+1 payment; if , then generate , so that channel party B can get aux again, so that channel party B settles with the amount of i+1 payment; and Lock signature Held by two people, when aux is withdrawn or obtained, channel party B must know ; At this time, if channel party B needs to use To obtain i+1 payments again, channel party A can use When redeeming an amount i+1, both parties will finally settle the account with the amount i+1.

4. A new universal cross-chain payment channel device, based on the method of claim 1, characterized by: Opening the timed channel phase module: This phase uses time locks and shared address technology to lock the amount. This amount is used for off-chain transactions and as a penalty to prevent malicious behavior by both parties and to open the channel. Generate and update payment phase module: This phase continuously updates payment through secure computing, symmetric encryption, and bitwise operation technology to ensure the accuracy and security of payment updates; Settlement payment stage module: This stage uses symmetric encryption and bit operation technology to put a valid payment on the chain and complete the settlement to ensure the correctness of the settlement.

5. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein when the program is executed, the device where the non-volatile storage medium is located is controlled to execute the method according to any one of claims 1 to 3.

6. An electronic device, characterized in that: The method comprises a processor and a memory; the memory stores computer-readable instructions, and the processor is used to execute the computer-readable instructions, wherein the computer-readable instructions execute the method according to any one of claims 1 to 3 when executed.

Images