A heterogeneous chain cross-chain method based on a virtual payment channel

Abstract

This invention relates to a heterogeneous blockchain cross-chain method based on a virtual payment channel, belonging to the field of blockchain cross-chain technology. Addressing issues such as consensus incompatibility, low cross-chain efficiency, insufficient privacy protection, and strong trust dependence of intermediate nodes in heterogeneous environments of public and consortium blockchains, this invention constructs a two-layer architecture with intermediate node coordination and decentralized threshold signature oracle supervision. It achieves compatibility with heterogeneous blockchain consensus differences through a consensus adaptation layer, implements zero-knowledge range proofs for privacy protection, relies on incremental sequence numbers and revocation secrets to ensure state linearization, and is complemented by a layered progressive dispute resolution mechanism. This invention enables an unlimited number of efficient off-chain cross-chain transactions between two blockchains, significantly reducing transaction latency and trust thresholds, improving the security and compatibility of cross-chain operations, and is suitable for compliant digital asset cross-chain transfer scenarios.

Description

Technical Field

[0001] This invention relates to a heterogeneous blockchain cross-chain method based on a virtual payment channel, belonging to the field of blockchain application technology. Background Technology

[0002] With the rapid development of blockchain technology, public blockchains and consortium blockchains have each formed their own independent application ecosystems. Public blockchains, with their decentralization, transparency, and programmability, support decentralized data and compliant digital asset applications; consortium blockchains, with their permission mechanisms, privacy protection, and efficient consensus mechanisms, are widely deployed in enterprise-level scenarios.

[0003] However, these two types of blockchains differ fundamentally in their consensus mechanisms, permission models, and privacy requirements. Public blockchains employ probabilistic finality consensus, where data updates require confirmation from multiple blocks before being considered final; consortium blockchains employ instant finality consensus, where data is finalized upon endorsement and submission. Public blockchains are permissionless networks, allowing any node to participate; consortium blockchains are permissioned networks, requiring participants to undergo identity verification and authorization. Furthermore, public blockchain data is publicly transparent, while consortium blockchains support private data sets to protect business privacy. These differences make secure and efficient data and digital asset interoperability between public and consortium blockchains difficult, creating "blockchain silos" that severely restrict the overall integration and collaborative development of blockchain technology in areas such as industrial collaboration and data sharing.

[0004] Existing cross-chain technologies offer various solutions to the interoperability problem between public and consortium blockchains. For example, the notary mechanism, which introduces a trusted third party to verify cross-chain data, is simple to implement but relies too heavily on the trust in the notary; hash time lock contracts require participating chains to support the same hash function, which faces compatibility challenges in heterogeneous chain scenarios; relay and sidechain solutions achieve interoperability by verifying block headers, but usually require modifications to existing chains.

[0005] Payment channels, as a core technology for Layer 2 scaling in blockchain, allow participants to perform high-frequency data updates off-chain through on-chain locking states. Virtual payment channels further allow two users without a direct channel to indirectly establish an off-chain channel through an intermediary node. The intermediary node only participates in opening and closing the channel, without intervening in the specific interaction process, thereby reducing the online pressure and resource requirements of the intermediary node while protecting interaction privacy. In recent years, researchers have begun exploring the application of virtual channels in cross-chain scenarios to address the problem of low efficiency in cross-chain interactions.

[0006] However, existing cross-chain virtual channel solutions were primarily designed for homogeneous or similar chain environments, assuming participating chains have similar trust models and functional support, failing to fully consider the fundamental differences between public and consortium blockchains. Specifically, existing solutions have significant shortcomings in the following aspects: First, they lack adaptation to heterogeneous chain consensus mechanisms. The probabilistic finality of public chains and the instantaneous finality of consortium blockchains require different verification strategies, and existing solutions do not provide a unified processing framework. Second, they neglect the privacy protection needs in consortium blockchain scenarios. The cross-chain verification process often exposes sensitive state information of the consortium blockchain, making it difficult to meet the data confidentiality requirements of practical applications. Third, they place too much trust in intermediary nodes. Most solutions rely on a single intermediary node or simple multi-signature, lacking effective supervision and checks and balances. Once an intermediary node acts maliciously or fails, the legitimate digital assets of the participants are at risk.

[0007] Therefore, how to achieve secure, efficient, and privacy-preserving cross-chain value transfer in heterogeneous environments of public and consortium blockchains, while reducing reliance on intermediary nodes, is a critical issue that urgently needs to be addressed. Summary of the Invention

[0008] The purpose of this invention is to address the technical challenges of cross-chain data interaction in heterogeneous environments of public and consortium blockchains, such as consensus differences, privacy protection, and trust dependence, and to propose a heterogeneous blockchain cross-chain method based on a virtual payment channel.

[0009] It should be noted that this invention is a blockchain underlying cross-chain technology solution, addressing only technical issues such as interoperability between public and consortium blockchains, secure data transmission, improved efficiency of off-chain data interaction, and privacy protection. The virtual payment channel described in this invention is a blockchain-based off-chain legal digital asset and data transfer technology channel, applicable only to blockchain application scenarios permitted by national laws and regulations, such as supply chain finance digital certificates, government data interoperability, enterprise-level digital asset ownership confirmation and transfer, and the application of digital RMB technology. The "digital assets" mentioned in this invention refer to digital records generated using blockchain technology, representing legitimate and compliant rights or information, within scenarios permitted by national laws and regulations, such as supply chain finance, government data interoperability, enterprise-level compliant digital asset ownership confirmation and transfer, and the application of digital RMB technology. The technical solution of this invention does not involve, support, or apply to any form of virtual currency issuance, trading, speculation, or illegal financial activities.

[0010] This invention draws inspiration from virtual payment channels, constructing a two-layer supervisory architecture by introducing an intermediate node I as the coordination layer and a decentralized oracle network as the supervisory layer. This enables efficient off-chain interactions between public and consortium blockchains, significantly reducing cross-chain data interaction latency and increasing throughput. This invention addresses the difference between the probabilistic finality of public blockchains and the instantaneous finality of consortium blockchains through a consensus and permission adaptation layer, achieving seamless compatibility between heterogeneous blockchains through endorsement signature verification and block confirmation parameterization. This invention employs zero-knowledge scope proofs and selective disclosure mechanisms, disclosing only necessary information when proving the validity of the consortium blockchain's state to the public blockchain, thus protecting the privacy of the consortium blockchain. This invention ensures state linearity through an incrementing sequence number and a secret revocation mechanism, penalizing any submission of outdated states; and by supervising intermediate nodes through a threshold signature oracle network, it reduces the trust assumption from "trusting a single entity" to "trusting the honesty of a majority of the oracle network."

[0011] The objective of this invention is achieved through the following technical solutions.

[0012] A heterogeneous blockchain cross-chain method based on a virtual payment channel includes the following steps:

[0013] Step 1: Channel Opening. User A on the public blockchain and User B on the consortium blockchain each send a channel opening request to intermediate node I. After verifying the signatures of both parties and the consortium blockchain's endorsement policy, intermediate node I coordinates both parties to update the payment channel status and lock assets on their respective chains. The decentralized oracle network simultaneously monitors the dual-chain locking event and generates a threshold signature proof, completing the establishment of the virtual channel.

[0014] Step 2: Off-chain interaction update. After the virtual channel is established, user A and user B negotiate to generate a new state containing an incrementing sequence number, the updated state value, and the hash of the predecessor state. They exchange signatures and synchronize the old state revocation secret, enabling an unlimited number of off-chain interactions. Intermediate node I does not intervene in the interaction process.

[0015] Step 3: Channel Closed. User A and User B negotiate the final state and send their signatures to intermediate node I. After verification, intermediate node I calls the smart contract or chaincode on the public chain and consortium chain respectively to execute the settlement, allocate digital assets according to the final state value, and release locked assets.

[0016] Step 4: Dispute resolution.

[0017] A layered, progressive dispute resolution protocol is adopted, which handles disputes through a four-level mechanism: off-chain negotiation between the two parties, coordination by intermediate nodes, threshold signature arbitration by the oracle network, and enforcement of smart contracts. The deposit of the party who commits wrongdoing is forfeited and the party who acts honestly is compensated.

[0018] Beneficial effects

[0019] Compared with the prior art, the method of the present invention has the following advantages:

[0020] 1. The method of this invention separates coordination and verification through a two-layer supervision architecture. The intermediate node I only participates in the opening and closing of the channel, and the oracle network independently supervises the cross-chain status, thereby achieving the unity of efficient off-chain interaction and security supervision and significantly reducing cross-chain interaction latency.

[0021] 2. The method of this invention addresses the difference between the probabilistic finality of public chains and the instantaneous finality of consortium chains through a consensus and permission adaptation layer. It achieves seamless compatibility between heterogeneous chains through endorsement signature verification and block confirmation parameterization, thus solving the problem of direct interoperability between heterogeneous chains caused by differences in consensus mechanisms and permission models.

[0022] 3. The method of this invention adopts zero-knowledge scope proof and selective disclosure mechanism. When proving the validity of the consortium blockchain state to the public blockchain, only necessary information is disclosed to protect the privacy of the consortium blockchain. At the same time, the linearization of the state is ensured by the incremental sequence number and the secret revocation mechanism, and any behavior of submitting an outdated state can be punished.

[0023] 4. The method of this invention supervises intermediate nodes through a threshold signature oracle network, reducing the trust assumption from "trusting a single entity" to "trusting the honesty of the majority of the oracle network," and combined with a hierarchical progressive dispute resolution protocol, provides a strong economic deterrent against malicious behavior. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the present invention. Detailed Implementation

[0025] To better illustrate the purpose and advantages of this invention, the following description, in conjunction with the accompanying drawings and examples, further clarifies the invention. It should be noted that the implementation of this invention is not limited to the following embodiments, and any modifications or alterations made to this invention will fall within the scope of protection of this invention. Special Note: In all embodiments of this invention, "digital assets," "status values," and "service fees," etc., refer to digital records of rights or information in scenarios permitted by national laws and regulations, such as supply chain finance, government data, and digital RMB. The units of measurement (such as "unit") in the embodiments are merely abstract expressions illustrating the logic of the technical solution and do not refer to any form of virtual currency or non-legal digital assets. The technical solution of this invention explicitly excludes virtual currency application scenarios.

[0026] like Figure 1 As shown, a heterogeneous blockchain cross-chain method based on a virtual payment channel includes the following steps:

[0027] Step 1: Channel Opening. User A on the public blockchain and User B on the consortium blockchain each send a channel opening request to intermediate node I. After verifying the signatures of both parties and the consortium blockchain's endorsement policy, intermediate node I coordinates both parties to update the payment channel status and lock assets on their respective chains. The decentralized oracle network simultaneously monitors the dual-chain locking events and generates a threshold signature proof, completing the establishment of the virtual channel.

[0028] Specifically, step 1 may include the following steps:

[0029] Step 1.1: Request generation and sending.

[0030] User A constructs an enable request and using the private key Signature generation .in, This represents the identifier of user A. H represents the identifier of user B, and H represents the hash operation.

[0031] User B constructs a request with the same content. Use private key Signature generation .

[0032] Meanwhile, user B collects at least [data / information] from the consortium blockchain. The signatures of each endorsing node form a multi-signature. .Will( , )and( , , ) are sent to intermediate node I respectively. Among them, and Users A and B are respectively in the virtual channel The initial state value in the data, where val is the channel validity period. , This is the service fee paid to intermediate node I.

[0033] Step 1.2: Intermediate Node I Verification and Coordination.

[0034] After receiving two requests, intermediate node I performs verification: Verification , and The validity, i.e. , ,and Number of valid signatures Check the consistency of the request parameters to confirm the consistency between the two requests. , , , , They are all equal; confirm that their own state values ​​in the payment channels on both chains meet the collateral requirements, that is, in the channel... The intermediate node I needs to have at least The state value in the channel The intermediate node I needs to have at least The state value. Among them, This represents user A's public key. This represents user B's public key.

[0035] If all passes, then intermediate node I constructs an agreement message. And generate signature Send to user and users .in, The identifier representing coordinating node I, This represents the private key of coordinating node I.

[0036] Step 1.3: Lock the status of dual-chain compliant digital assets.

[0037] user With intermediate nodes Updating payment channels on Ethereum User A's status value decreased ,in, As its initial state value in the virtual channel, it is locked. The transfer is made to intermediate node I; intermediate node I locks its state value. This serves as the initial state value for user B in the virtual channel. User B and intermediate node I update the payment channel on the consortium blockchain. User B's status value decreased ,in As its initial state value in the virtual channel, it is locked. The transfer is made to intermediate node I. Intermediate node I locks its state value. This serves as the initial state value for user A in the virtual channel. Both parties then send an update completion notification to intermediate node I.

[0038] Step 1.4: Oracle cross-chain verification.

[0039] After receiving notifications from both sides, intermediate node I requests the oracle network to provide proof of the consistency of the two-chain lock. The oracle nodes monitor both chains simultaneously, and each node... Independently verify whether the locking interaction on Ethereum has been recorded on-chain and confirmed with 6 blocks, and whether the locking interaction on the consortium blockchain has been correctly endorsed and committed. If the verification passes, the node will update the message. Generate signature fragment The aggregation node collects at least Generate a threshold signature from a signature fragment. , Oracle networks will Return to intermediate node I. Wherein, Represents a node private key, A unique identifier representing a virtual payment channel.

[0040] Step 1.5: Channel opening completed.

[0041] After receiving the threshold signature, intermediate node I constructs the channel opening credential. And distributed to user A and user B. Virtual channel Formally established, initial state is .in, This indicates the timestamp when the channel was established.

[0042] Step 2: Off-chain interaction update. After the virtual channel is established, user A and user B negotiate to generate a new state containing an incrementing sequence number, the updated state value, and the hash of the predecessor state. They exchange signatures and synchronize the old state revocation secret, enabling unlimited off-chain data interactions. Intermediate node I does not intervene in the specific interaction process.

[0043] Specifically, step 2 includes the following steps:

[0044] Step 2.1: Negotiate a new state.

[0045] Let the current state be When user A transfers a quantity to user B, the quantity is... And satisfy At that time, the two parties negotiated and a new status was achieved. :

[0046]

[0047] in, This represents the state value of user A in the current state. This represents the state value of user B in the current state.

[0048] Step 2.2: Signature exchange.

[0049] User A calculates Generate signature Send to user B; user B generates the signature after verifying it. Send to user A. Among them, This represents the state hash.

[0050] Step 2.3: Cancel the secret exchange.

[0051] Both sides exchanged with the old status Corresponding revocation of secret ,promise Included In the middle. After the exchange is completed, user A holds User B holds .in, This represents user A's signature on the new state. This represents user B's signature on the new state.

[0052] Step 2.4: Status update.

[0053] Both parties verify that the other party's signature is valid and After matching, The latest state is stored, the old state is archived, and the interaction is complete.

[0054] Step 3: Channel Closed. User A and User B negotiate the final state and send their signatures to intermediate node I. After verification, intermediate node I calls the smart contract or chaincode on the public chain and consortium chain respectively to execute the settlement, allocate digital assets according to the final state value, and release locked assets.

[0055] Specifically, step 3 includes the following steps:

[0056] Step 3.1: Negotiate the final state.

[0057] User A and User B determine the final state value. , ,structure ,in, Indicates the final state. This is the latest serial number. It is generated by both parties signing separately. , ,Will Send to intermediate node I.

[0058] Step 3.2: Verify intermediate node I.

[0059] Intermediate node I verifies that both signatures are valid and checks... The serial number must be at least the latest one recorded locally. If successful, proceed with the settlement.

[0060] Step 3.3: Dual-chain settlement.

[0061] On Ethereum, intermediate node I and user A jointly invoked a smart contract to close the channel. User A obtained Intermediate node I obtains On the consortium blockchain, intermediate node I and user B jointly invoke chaincode to close the channel. User B obtained Intermediate node I obtains The settlement process includes FinalState and signatures from both parties. After verification of the contract chaincode, the channel status is updated, and locked digital assets are released.

[0062] Step 4: Dispute resolution.

[0063] A layered, progressive dispute resolution protocol is adopted, which handles disputes through a four-level mechanism: off-chain negotiation between the two parties, coordination by intermediate nodes, threshold signature arbitration by the oracle network, and enforcement of smart contracts. The deposit of the party who commits wrongdoing is forfeited and the party who acts honestly is compensated.

[0064] The deposit refers to the initial state value locked by the user when the channel is opened. The locked assets of the perpetrator will be forfeited as the deposit.

[0065] Example

[0066] A heterogeneous blockchain cross-chain method based on a virtual payment channel includes the following steps:

[0067] Step 1: Open the channel.

[0068] Step 1.1: Request generation and sending.

[0069] In this embodiment, user A is located on the Ethereum public blockchain, and user B is located on the Hyperledger Fabric consortium blockchain. Let... , , Second, , (Service fees are measured in units pegged to fiat currency or on-chain resource consumption.) User A constructs... Use private key Signature, constructed by user B Use private key Signature, and user B collects at the same time. Each endorsement node's signature forms , respectively sent to intermediate node I.

[0070] Step 1.2: Intermediate Node I Verification and Coordination. Intermediate Node I verifies the signature validity and confirms its own presence in the channel. Medium state value In the passage Medium state value Then, construct the Agreement, sign it, and send it to user A and user B.

[0071] Step 1.3: Double strand Digital asset state locked. User A updates the channel with intermediate node I. User A's status value decreased Intermediate node I locked User B updates the channel with intermediate node I. User B's status value decreased Intermediate node I locked Both parties send an update completion notification to intermediate node I.

[0072] Step 1.4: Oracle Cross-Chain Verification. The oracle network consists of... Composed of nodes, threshold After each node verifies that the Ethereum locking interaction has reached 6 block confirmations and the consortium blockchain locking interaction meets the endorsement policy, a threshold signature is generated. Return to intermediate node I.

[0073] Step 1.5: Channel opening complete. Intermediate node I constructs an OpenProof distribution for user A and user B, creating a virtual channel. Establish.

[0074] Step 2: Off-chain data update. Let the current state be... The data flows from user A to user B. Negotiation between the two parties Exchange signatures , and the revocation of secrecy After verification, the local state is updated. This process is entirely off-chain and has a delay of approximately 50 milliseconds.

[0075] Step 3: Channel closed. After the interaction is complete, both parties negotiate the final state value. , The system constructs and signs the FinalState, sending it to intermediate node I. After verification by intermediate node I, settlement occurs on Ethereum: User A receives 90 units of state value, and intermediate node I receives 50.01 units; settlement occurs on the consortium blockchain: User B receives 60 units of state value, and intermediate node I receives 100.005 units. The channel is then closed.

[0076] Step 4: Dispute Resolution. If User B attempts to submit an outdated status... User A can submit a request to revoke the secret. The results are sent to the oracle. After verification, the oracle generates a threshold signature arbitration result. The smart contract forfeits user B's deposit and compensates user A.

Claims

1. A heterogeneous blockchain cross-chain method based on virtual payment channels, used in blockchain application scenarios permitted by national laws and regulations, including supply chain finance digital certificates, government data interoperability, enterprise-level compliant digital asset ownership confirmation and transfer, and digital RMB technology application, characterized in that, Includes the following steps: Step 1: Open the channel; User A, located on the public blockchain, and user B, located on the consortium blockchain, each send a channel opening request to intermediate node I. After intermediate node I verifies the signatures of both parties and the consortium blockchain endorsement strategy, it coordinates both parties to update the payment channel status and lock assets on their respective chains; the decentralized oracle network simultaneously monitors the dual-chain locking event and generates threshold signature proofs to complete the establishment of the virtual channel; Step 1.1: Request generation and sending; User A constructs an enable request and using the private key Signature generation ,in, This represents the identifier of user A. H represents the identifier of user B, and H represents the hash operation. User B constructs a request with the same content. Use private key Signature generation ; Meanwhile, user B collects at least [data / information] from the consortium blockchain. The signatures of each endorsing node form a multi-signature. ;Will( , )and( , , ) are sent to intermediate node I respectively; where, and Users A and B are respectively in the virtual channel The initial state value in the data, where val is the channel validity period. , The service fee to be paid to intermediate node I; Step 1.2: Intermediate Node I Verification and Coordination; After receiving two requests, intermediate node I performs verification: Verification , and The validity, i.e. , ,and Number of valid signatures Check the consistency of request parameters to confirm the consistency between the two requests. , , , , They are all equal; confirm that their own state values ​​in the payment channels on both chains meet the collateral requirements, that is, in the channel... The intermediate node I needs to have at least The state value in the channel The intermediate node I needs to have at least The state value; where, This represents user A's public key. This represents user B's public key; If all passes, then intermediate node I constructs an agreement message. And generate signature Send to user and users ;in, The identifier representing coordinating node I, This represents the private key of coordinating node I; Step 1.3: Locking the state of dual-chain compliant digital assets; user With intermediate nodes Updating payment channels on Ethereum User A's status value decreased ,in, As its initial state value in the virtual channel, it is locked. The transfer is made to intermediate node I; intermediate node I locks its state value. This serves as the initial state value for user B in the virtual channel; user B and intermediate node I update the payment channel on the consortium blockchain. User B's status value decreased ,in As its initial state value in the virtual channel, it is locked. The transfer is made to intermediate node I; intermediate node I locks its state value. As the initial state value of user A in the virtual channel; both parties will send update completion notifications to intermediate node I respectively; Step 1.4: Oracle cross-chain verification; After receiving notifications from both sides, intermediate node I requests the oracle network to provide proof of the consistency of the two-chain lock; the oracle nodes monitor both chains simultaneously, each node... Independently verify whether the locking interaction on Ethereum has been recorded on-chain and confirmed with 6 blocks, and whether the locking interaction on the consortium blockchain has been correctly endorsed and committed; if the verification passes, the node will update the message. Generate signature fragment Aggregator nodes collect at least Generate a threshold signature from a signature fragment. , Oracle networks will Return to intermediate node I; where, Represents a node private key, A unique identifier representing a virtual payment channel; Step 1.5: Channel opening complete; After receiving the threshold signature, intermediate node I constructs the channel opening credential. And distributed to user A and user B; virtual channel Formally established, initial state is ;in, Indicates the channel establishment timestamp; Step 2: Off-chain interaction update; After the virtual channel is established, user A and user B negotiate to generate a new state containing an incrementing sequence number, an updated state value, and a predecessor state hash. They exchange signatures and synchronize the old state revocation secret, enabling unlimited off-chain interactions. Intermediate node I does not intervene in the interaction process. Step 3: Close the channel; User A and User B negotiate the final state and sign it, sending it to intermediate node I. After verification, intermediate node I calls smart contracts or chaincode on the public chain and consortium chain respectively to execute settlement, allocate digital assets and release locked assets according to the final state value. Step 4: Dispute Resolution; A layered, progressive dispute resolution protocol is adopted, which handles disputes through a four-level mechanism: off-chain negotiation between the two parties, coordination by intermediate nodes, threshold signature arbitration by the oracle network, and enforcement of smart contracts. The deposit of the party who commits wrongdoing is forfeited and the party who acts honestly is compensated.

2. The heterogeneous blockchain cross-chain method based on a virtual payment channel as described in claim 1, characterized in that, Step 2 includes the following steps: Step 2.1: Negotiate a new state; Let the current state be When the amount transferred from user A to user B is And satisfy At that time, the two parties negotiated and a new status quo was reached. : in, This represents the state value of user A in the current state. This represents the state value of user B in the current state; Step 2.2: Signature exchange; User A calculates Generate signature Send to user B; user B generates the signature after verifying it. Send to user A; where, Represents the state hash; Step 2.3: Cancel the secret exchange; Both sides exchanged with the old status Corresponding revocation of secret ,promise Included In the middle; after the exchange is completed, user A holds User B holds ;in, This represents user A's signature on the new state. This represents user B's signature on the new state; Step 2.4: Status Update; Both parties verify that the other party's signature is valid and After matching, The latest state is stored, the old state is archived, and the interaction is complete.

3. The heterogeneous blockchain cross-chain method based on a virtual payment channel as described in claim 1, characterized in that, Step 3 includes the following steps: Step 3.1: Negotiate the final state; User A and User B determine the final state value. , ,structure ,in, Indicates the final state. This is the latest serial number; both parties sign it to generate the serial number. , ,Will Send to intermediate node I; Step 3.2: Verify intermediate node I; Intermediate node I verifies that both signatures are valid and checks... The serial number must be no less than the latest serial number recorded locally; if successful, proceed with the settlement. Step 3.3: Dual-chain settlement; On Ethereum, intermediate node I and user A jointly invoked a smart contract to close the channel. User A obtained Intermediate node I obtains On the consortium blockchain, intermediate node I and user B jointly invoke chaincode to close the channel. User B obtained Intermediate node I obtains The settlement interaction includes FinalState and signatures from both parties. After the contract chaincode is verified, the channel status is updated, and the locked digital assets are released.

4. The heterogeneous blockchain cross-chain method based on a virtual payment channel as described in claim 1, characterized in that, In step 4, if user B attempts to submit an outdated status... User A submitted a request to revoke the secret. The results are sent to the oracle. After verification, the oracle generates a threshold signature arbitration result. The smart contract forfeits user B's deposit and compensates user A.

Images