Transaction request processing method and device based on monitoring sub-chain, and storage medium

Abstract

The invention discloses a transaction request processing method and device based on a monitoring sub-chain, and a storage medium, and relates to the field of block chains. The method comprises the following steps: after a monitoring sub-chain detects a cross-chain request and successfully verifies the cross-chain request, generating a cross-chain transaction certificate; the state of the source chain and the state of the target chain are locked, then the cross-chain transaction voucher is sent to the target chain, the target chain transfers the target fund on the source chain into the target chain when the cross-chain transaction voucher is successfully verified, and then receipt information of successful fund transfer is sent to the monitoring sub-chain; after the monitoring sub-link receives the receipt information, a random key is sent to the source chain; and after the monitoring sub-link receives the on-link voucher, the states of the source chain and the target chain are unlocked. The technical problem that in the prior art, due to the fact that cross-chain interaction lacks an effective coordination mechanism and atomicity guarantee, fund safety and transaction reliability are poor is solved.

Description

Technical Field

[0001] This application relates to the field of blockchain, and more specifically, to a method, apparatus, and storage medium for processing transaction requests based on a monitored subchain. Background Technology

[0002] Under the existing model, the atomicity of cross-chain transactions (i.e., either all transactions succeed simultaneously on all participating chains, or all transactions are rolled back to their initial state) is difficult to guarantee effectively. This means that if any step fails, especially when funds have been transferred from the source chain but have not yet been confirmed as received on the target chain, the complexity of the rollback mechanism will increase significantly, thus compromising the security of funds.

[0003] Existing cross-chain solutions, such as notary mechanisms, rely on trusted third-party nodes to verify transactions on the source chain, thereby triggering corresponding operations on the target chain. However, this mechanism may compromise the security and reliability of transactions due to single points of failure or potential malicious behavior by the third party.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a transaction request processing method, apparatus, and storage medium based on a monitored subchain, to at least solve the technical problem in the prior art where the lack of an effective coordination mechanism and atomicity guarantee in cross-chain interaction leads to poor fund security and transaction reliability.

[0006] According to one aspect of the embodiments of this application, a transaction request processing method based on a monitoring subchain is provided. The method is applied to a monitoring subchain, which coordinates and verifies cross-chain interactions between different blockchains. The method includes: after the monitoring subchain detects a cross-chain request and successfully verifies it, generating a cross-chain transaction certificate. The cross-chain request is used to request the transfer of target funds from the source chain to the target chain, and the cross-chain transaction certificate is used to characterize the validity of the cross-chain request occurring on the source chain; locking the states of the source chain and the target chain, and then processing the cross-chain transaction... The credential is sent to the target chain. Upon successful verification of the cross-chain transaction credential, confirmation that the target funds on the source chain are frozen, and the corresponding zero-knowledge proof verification on the source chain is passed, the target chain transfers the target funds from the source chain to its own chain and then sends a receipt indicating successful fund transfer to the monitoring sub-chain. After receiving the receipt, the monitoring sub-chain sends a random key to the source chain. The source chain uses the received random key to unfreeze the target funds and generate an on-chain credential, which is then sent to the monitoring sub-chain. Upon receiving the on-chain credential, the monitoring sub-chain unlocks the states of both the source and target chains.

[0007] Optionally, monitoring the subchain's verification operation for cross-chain requests includes: detecting whether the number of transaction confirmations occurring on the source chain has reached a preset minimum confirmation threshold, wherein the number of transaction confirmations is used to determine whether the transaction is stable; and if the number of transaction confirmations occurring on the source chain has reached the minimum confirmation threshold, invoking a zero-knowledge proof protocol to verify the validity of the cross-chain request.

[0008] Optionally, locking the state of the source chain and the target chain includes: performing a state locking operation on the source chain, including: freezing the target funds on the source chain, wherein the frozen target funds are prohibited from being withdrawn or transferred again by the user during the cross-chain request; performing a state locking operation on the target chain, including: creating a receiving account on the target chain with an inactive account balance, wherein the receiving account is used to receive the target funds on the target chain.

[0009] Optionally, after locking the states of the source chain and the target chain, the method further includes: creating a bidirectional hash time lock, wherein the bidirectional hash time lock is used to coordinate the transaction time of the source chain and the target chain; after creating the bidirectional hash time lock, generating a random key, and then using a cryptographic algorithm to calculate the hash value of the random key; obtaining network status information between the source chain and the target chain; and adjusting the timeout window corresponding to the bidirectional hash time lock according to the network status information, wherein the timeout window is a preset time threshold for automatically triggering transaction rollback, and the preset time threshold is determined based on the network latency and security threshold between the source chain and the target chain.

[0010] Optionally, the verification process of the zero-knowledge proof corresponding to the source chain includes: after the monitoring sub-chain generates a cross-chain transaction certificate, using a zero-knowledge proof protocol to verify the legality of the cross-chain request, and verifying whether the target funds involved in the cross-chain request have been used for other transaction requests besides the cross-chain request.

[0011] Optionally, a transaction request processing method based on monitoring subchains further includes: if the target chain does not return a successful verification signal within the timeout window, or if it is found during the verification process that the target funds on the source chain are not frozen, or if the zero-knowledge proof corresponding to the source chain fails verification, then it is determined that the cross-chain request has not been successfully executed, and then a refund process is initiated. The refund process includes: the source chain unfreezing the target funds and returning the target funds to the user's account.

[0012] Optionally, after unlocking the states of the source chain and the target chain, the method further includes: calculating the asset reduction on the source chain and the asset increase on the target chain based on the information in the cross-chain transaction certificate, and updating the global ledger, wherein the global ledger is used to record the execution status and execution result of the cross-chain request; and generating notification information about the transaction completion status based on the update result of the global ledger.

[0013] Optionally, the source chain is an Ethereum blockchain and the target chain is a consortium blockchain; or the source chain is a consortium blockchain and the target chain is an Ethereum blockchain.

[0014] According to another aspect of the embodiments of this application, a transaction request processing apparatus based on a monitoring subchain is also provided, comprising: a generation unit, configured to generate a cross-chain transaction certificate after the monitoring subchain detects a cross-chain request and successfully verifies the cross-chain request, wherein the cross-chain request is used to request the transfer of target funds on the source chain to the target chain, and the cross-chain transaction certificate is used to characterize the validity of the cross-chain request occurring on the source chain; a first processing unit, configured to lock the states of the source chain and the target chain, and then send the cross-chain transaction certificate to the target chain, wherein the target chain, after successfully verifying the cross-chain transaction certificate and confirming that the target funds on the source chain have been frozen and the zero-knowledge proof verification of the source chain has passed, transfers the target funds on the source chain to the target chain, and then sends a receipt information indicating successful fund transfer to the monitoring subchain; a second processing unit, configured to send a random key to the source chain after the monitoring subchain receives the receipt information, wherein the source chain unfreezes the target funds and generates an on-chain certificate based on the received random key, and then sends the on-chain certificate to the monitoring subchain; and a third processing unit, configured to unlock the states of the source chain and the target chain after the monitoring subchain receives the on-chain certificate.

[0015] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described transaction request processing method based on the monitoring subchain.

[0016] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to perform the above-described transaction request processing method based on a monitoring subchain.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described transaction request processing method based on a monitoring subchain.

[0018] In this application, the transaction request processing method based on the monitoring subchain first generates a cross-chain transaction certificate after the monitoring subchain detects and successfully verifies the cross-chain request. The cross-chain request is used to request the transfer of target funds from the source chain to the target chain, and the cross-chain transaction certificate represents the validity of the cross-chain request occurring on the source chain. The states of the source chain and the target chain are locked, and then the cross-chain transaction certificate is sent to the target chain. If the target chain successfully verifies the cross-chain transaction certificate, confirms that the target funds on the source chain are frozen, and that the corresponding zero-knowledge proof verification of the source chain is successful, the target chain transfers the target funds from the source chain to the target chain and then sends a receipt indicating successful fund transfer to the monitoring subchain. After receiving the receipt, the monitoring subchain sends a random key to the source chain. The source chain unfreezes the target funds and generates an on-chain certificate based on the received random key, and then sends the on-chain certificate to the monitoring subchain. After receiving the on-chain certificate, the monitoring subchain unlocks the states of the source chain and the target chain.

[0019] In this embodiment, a transaction request processing method based on a monitored subchain is employed. By generating cross-chain transaction credentials and simultaneously locking the asset state on both the source and target chains, the atomicity of transactions is enhanced, i.e., "full success or full rollback." Simultaneously, leveraging zero-knowledge proof verification technology, the target chain can confirm the legality of the transaction without exposing sensitive information from the source chain, thereby improving transaction security. Furthermore, through the coordination of the monitored subchain and the random key unfreezing mechanism, the entire transaction process is automated, improving the reliability of cross-chain interactions. Ultimately, this achieves secure and reliable cross-chain transactions, thus solving the technical problem in existing technologies where the lack of effective coordination mechanisms and atomicity guarantees in cross-chain interactions leads to poor fund security and transaction reliability. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a flowchart of an optional transaction request processing method based on a monitored subchain according to an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of an optional transaction request processing device based on a monitoring subchain according to an embodiment of this application. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] It should also be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected in this application are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0026] According to an embodiment of this application, an embodiment of a transaction request processing method based on a monitoring subchain is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0027] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0028] According to the embodiments of this application, a transaction request processing system based on a monitoring subchain can be used as the execution subject of the transaction request processing method based on a monitoring subchain in the embodiments of this application. The system can be a software system or an embedded system combining software and hardware. Of course, the execution subject of the method in the embodiments of this application can also be other forms of execution subject, such as devices, equipment, etc. It should be known by those skilled in the art that this application does not particularly limit the specific form of the execution subject.

[0029] Figure 1 This is a flowchart of a transaction request processing method based on a monitored subchain according to an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps:

[0030] Step S101: After the monitoring subchain detects the cross-chain request and successfully verifies the cross-chain request, a cross-chain transaction certificate is generated. The cross-chain request is used to request the transfer of target funds on the source chain to the target chain, and the cross-chain transaction certificate is used to characterize the validity of the cross-chain request occurring on the source chain.

[0031] Optionally, when a listening node on the monitoring subchain detects a cross-chain request issued by a user through a wallet calling the adapter contract on the source chain, the atomic execution engine immediately initiates the verification process.

[0032] The adapter's role is to convert transaction details and asset states from different chains into a common format, making it easier for the atomic execution engine within the monitoring sub-chain to understand and process them. The atomic execution engine is an important software module for monitoring sub-chains, mainly used to achieve atomic execution of cross-chain transactions.

[0033] Optionally, the verification process includes checking whether the number of confirmations for the source chain transaction has reached a predetermined threshold, and using zero-knowledge proofs to verify the validity of the transaction and whether double-spending has occurred. If the verification is successful, the atomic execution engine will generate a cross-chain transaction certificate, which includes details of the cross-chain request occurring on the source chain and a Merkel proof, characterizing the validity of the transaction on the source chain. The generation of the cross-chain transaction certificate is the starting point for the entire cross-chain interaction, contributing to the initial verification of the transaction and providing a basis for the legitimacy of subsequent operations.

[0034] Step S102: Lock the states of the source chain and the target chain, and then send the cross-chain transaction certificate to the target chain. If the target chain successfully verifies the cross-chain transaction certificate, confirms that the target funds on the source chain have been frozen, and confirms that the zero-knowledge proof of the source chain has been verified, the target chain will transfer the target funds on the source chain to the target chain, and then send a receipt message indicating that the funds have been successfully transferred to the monitoring sub-chain.

[0035] Optionally, after the cross-chain transaction certificate is generated, the atomic execution engine can simultaneously pre-lock states on both the source and target chains. Specifically, the adapter on the source chain pre-locks to keep assets frozen (preventing user withdrawal), while the adapter on the target chain pre-locks to pre-create the receiving account (at this time, the account balance is not active). This pre-locking operation helps prevent funds from being illegally used or double-transferred during cross-chain transaction processing.

[0036] Optionally, the monitoring subchain sends the cross-chain transaction certificate to the target chain. The target chain uses lightweight payment verification to prove the validity of the cross-chain transaction certificate, and simultaneously verifies through zero-knowledge proof that the mapped assets of the source chain have been frozen and that the transaction request has not been double-spent. This helps the target chain execute the fund transfer while ensuring the transaction is legal and the funds are secure. Finally, a successful execution receipt is sent to the monitoring subchain.

[0037] Step S103: After receiving the receipt information, the monitoring sub-chain sends a random key to the source chain. The source chain unfreezes the target funds and generates an on-chain certificate based on the received random key, and then sends the on-chain certificate to the monitoring sub-chain.

[0038] Optionally, when the monitoring subchain detects a successful fund transfer receipt sent by the target chain, the atomic execution engine immediately sends a random key to the source chain. The source chain can then unfreeze the target funds based on the received key and generate on-chain credentials.

[0039] Optionally, the on-chain certificate serves as proof of transaction completion, indicating that assets on the source chain have been successfully transferred to the target chain. The use of a random key enhances the security of fund unfreezing and reduces unauthorized asset releases. Subsequently, the source chain sends the on-chain certificate back to the monitoring sub-chain as a crucial step in closing the transaction loop.

[0040] Step S104: After the monitoring sub-link receives the on-chain credential, unlock the state of the source chain and the target chain.

[0041] Optionally, after the monitoring subchain receives the on-chain credentials sent by the source chain, it will unlock the previously locked state of the source chain and the target chain, which means the final completion of the cross-chain transaction. The account funds on the source chain and the target chain will be restored to normal circulation, realizing a closed loop for cross-chain asset transfer.

[0042] In one optional embodiment, the monitoring subchain's verification operation for cross-chain requests includes: detecting whether the number of transaction confirmations occurring on the source chain has reached a preset minimum confirmation threshold, wherein the number of transaction confirmations is used to determine whether the transaction is stable; and if the number of transaction confirmations occurring on the source chain has reached the minimum confirmation threshold, invoking a zero-knowledge proof protocol to verify the validity of the cross-chain request.

[0043] Optionally, when a monitored sub-link receives a cross-chain request, it first checks the confirmation count of the transaction corresponding to the request on the source chain.

[0044] Optionally, the transaction confirmation count refers to the number of times a transaction is confirmed and added to the blockchain network. This value reflects the stability of the transaction in the network; generally, the higher the confirmation count, the less likely the transaction is to be reversed or attacked.

[0045] Optionally, monitoring nodes on the subchain can periodically scan the source chain's blockchain to look for transaction records related to cross-chain requests, while also monitoring transaction confirmation status. When the number of transaction confirmations reaches a preset minimum threshold, it means that the transaction has been recognized in the network and has high credibility and stability, thus providing a reliable foundation for subsequent cross-chain operations.

[0046] Optionally, when the number of transaction confirmations meets the minimum confirmation threshold, the monitoring subchain will enter the second phase, which involves calling the zero-knowledge proof protocol to verify the validity of the cross-chain request.

[0047] Optionally, by using a zero-knowledge proof protocol, monitoring subchains can verify the validity of transactions, including key elements such as the correctness of the source of funds and whether the transaction has been double-spent, without disclosing detailed transaction data on the source chain.

[0048] Optionally, the monitoring subchain can use the verification logic in the smart contract to call pre-built zero-knowledge proofs to verify the transaction proofs generated by the source chain. This helps ensure that transactions comply with pre-set rules and conditions without adversely affecting the network. Upon successful verification, the smart contract will continue executing the cross-chain request; otherwise, it will terminate the request, thus ensuring that only legitimate and stable transactions can proceed to the next step of the cross-chain operation.

[0049] In one optional embodiment, locking the state of the source chain and the target chain includes: performing a state locking operation on the source chain, including: freezing the target funds on the source chain, wherein the frozen target funds are prohibited from being withdrawn or transferred again by the user during the cross-chain request; performing a state locking operation on the target chain includes: creating a receiving account on the target chain with an inactive account balance, wherein the receiving account is used to receive the target funds on the target chain.

[0050] Optionally, after the monitored subchain captures a cross-chain request, the atomic execution engine will freeze the target funds on the source chain. This freeze locks the state of the target funds on the source chain, preventing users from withdrawing or transferring them again during the cross-chain request process. The freeze is performed through an adapter contract on the source chain. The adapter contract automatically locks the target funds upon generating the cross-chain event, helping to prevent abnormal use of funds during verification and transfer, thus contributing to fund security.

[0051] Optionally, the atomic execution engine also performs a state-locking operation on the target chain, that is, pre-creating a receiving account on the target chain, but the account balance is not active at this time. In other words, although the receiving account is ready to receive the target funds, there is no actual asset transfer until the cross-chain transaction is finally confirmed. This design not only ensures the atomicity of the transaction, but also simplifies the subsequent fund transfer process and improves transaction efficiency by pre-creating the account.

[0052] In an optional embodiment, after locking the states of the source chain and the target chain, the method further includes: creating a bidirectional hash time lock, wherein the bidirectional hash time lock is used to coordinate the transaction time of the source chain and the target chain; after creating the bidirectional hash time lock, generating a random key, and then using a cryptographic algorithm to calculate the hash value of the random key; obtaining network status information between the source chain and the target chain; adjusting the timeout window corresponding to the bidirectional hash time lock according to the network status information, wherein the timeout window is a preset time threshold for automatically triggering transaction rollback, and the preset time threshold is determined based on the network latency and security threshold between the source chain and the target chain.

[0053] Optionally, after the source and target chains are locked, the atomic execution engine monitoring the sub-chain will create a two-way hash time lock. A two-way hash time lock is a mechanism for implementing atomic transactions on a blockchain. By locking funds simultaneously on both chains and using a common hash value as the unlocking condition, it ensures that funds can only be unlocked if the transaction is successfully executed on both chains. The creation of the two-way hash time lock establishes a mechanism for coordinating transaction timing between the source and target chains, helping transactions complete within a certain timeframe; otherwise, a rollback process will be automatically triggered.

[0054] Optionally, after creating the two-way hash timelock, the atomic execution engine generates a random key and uses a cryptographic algorithm to calculate the hash value of the random key. The random key is crucial for unlocking the two-way hash timelock; only the participant holding the random key can unfreeze the locked funds upon successful transaction. In other words, during cross-chain transactions, the target chain can only unfreeze the funds and transfer them to the receiving account after receiving the correct hash value, while the source chain unfreezes the funds and destroys the locked assets upon receiving the receipt and the random key.

[0055] Optionally, the atomic execution engine will continuously collect historical communication data between the source and target chains, including but not limited to transaction confirmation times, block generation intervals, and network latency statistics, and train an AI model based on this historical communication data. After the model training is complete, the atomic execution engine will use the AI ​​model to predict current network conditions in real time.

[0056] Optionally, the atomic execution engine can adjust the timeout window of the bidirectional hash time lock in real time based on current network conditions. The timeout window is a preset time threshold that automatically triggers a refund or rollback if a transaction is not completed within the specified time. Dynamically adjusting the timeout window can adapt to different network environments, helping transactions complete within a safe timeframe while reducing the risk of funds being frozen due to network latency.

[0057] In one optional embodiment, the verification process of the zero-knowledge proof corresponding to the source chain includes: after the monitoring sub-chain generates a cross-chain transaction certificate, using a zero-knowledge proof protocol to verify the legality of the cross-chain request, and verifying whether the target funds involved in the cross-chain request have been used for other transaction requests besides the cross-chain request.

[0058] Optionally, after the monitoring subchain generates cross-chain transaction credentials, a zero-knowledge proof protocol is used to verify the legitimacy of the cross-chain request. A zero-knowledge proof protocol allows one party (the prover) to prove to another party (the verifier) ​​that they possess certain information or meet certain conditions without revealing the information itself. In cross-chain scenarios, the prover is typically a transaction on the source chain, while the verifier is the monitoring subchain.

[0059] Specifically, the monitoring subchain will invoke a pre-built zero-knowledge proof verification algorithm to verify the Merkel proof and other relevant data in the cross-chain transaction certificate. This verifies whether the cross-chain request complies with preset rules and conditions, such as asset ownership and the non-double-spending status of the transaction. This verification process ensures that only legitimate transaction requests can proceed, thereby reducing the impact of malicious or erroneous transactions on cross-chain operations.

[0060] Optionally, the verification process will further examine whether the target funds involved in the cross-chain request have been used for other transaction requests besides this cross-chain request. In distributed networks, verifying the uniqueness of assets is crucial, especially in preventing double-spending attacks. Zero-knowledge proof protocols can prove that assets have not been reused or allocated without exposing detailed asset information.

[0061] Specifically, the monitoring subchain will utilize zero-knowledge proof technology to verify the state of the target funds, ensuring that the asset is not being used for other transactions simultaneously when initiating a cross-chain request. This verification step is executed through logic within a smart contract, which can generate a zero-knowledge proof protocol based on the target funds' transaction history.

[0062] In an optional embodiment, the transaction request processing method based on the monitored subchain further includes: if the target chain does not return a verification success signal within the timeout window, or if it is found during the verification process that the target funds on the source chain are not frozen, or if the zero-knowledge proof corresponding to the source chain fails the verification, then it is determined that the cross-chain request has not been successfully executed, and then a refund process is initiated, wherein the refund process includes: the source chain unfreezing the target funds and returning the target funds to the user account.

[0063] Optionally, there are three key points that trigger the refund process:

[0064] Key Point 1: The timeout window set when creating the two-way hash time lock is used to monitor the execution process of cross-chain transactions. If the target chain fails to send a successful verification signal within the timeout window, it means that the cross-chain transaction failed to complete within the expected time, triggering the refund process.

[0065] Key point 2: When a cross-chain request begins, the target funds will be frozen on the source chain. If it is found that the funds are not frozen during the verification process, it may mean that the funds have been used abnormally, and a refund process needs to be triggered.

[0066] Key Point 3: Zero-knowledge proofs are a crucial means of verifying the legality of transactions and the status of assets. If the zero-knowledge proof on the source chain fails verification, it indicates that the transaction has security risks or does not comply with preset rules, and a refund process should be initiated immediately.

[0067] Optionally, if the refund process is triggered, the monitoring subchain will take the following steps:

[0068] The first step involves the atomic execution engine sending an unfreezing command to the adapter contract on the source chain. This contract is responsible for releasing the frozen funds. This automated execution mechanism via smart contracts improves the efficiency and security of unfreezing the funds.

[0069] The second step, after the funds are unfrozen, is to return the target funds to the account from which the user initiated the cross-chain request. This step helps ensure the security of the user's funds; even if the cross-chain request fails, the funds can still be safely returned to the user.

[0070] In an optional embodiment, after unlocking the states of the source chain and the target chain, the transaction request processing method based on the monitored sub-chain further includes: calculating the asset reduction on the source chain and the asset increase on the target chain based on the information in the cross-chain transaction certificate, and updating the global ledger, wherein the global ledger is used to record the execution status and execution result of the cross-chain request; and generating notification information about the transaction completion status based on the update result of the global ledger.

[0071] Optionally, the global ledger is the core data structure in the monitoring subchain, used to record the execution status and results of all cross-chain requests, including but not limited to key events such as asset locking, transfer, and unlocking. The existence of the global ledger helps ensure the traceability and consistency of cross-chain transactions, and is the foundation for achieving transparency and automation in inter-chain asset transfers.

[0072] Optionally, cross-chain transaction credentials are captured and generated by monitoring sub-chains, serving as key information to prove the state of cross-chain transactions on the source chain and their execution on the target chain. Cross-chain transaction credentials include Merkel proofs, transaction details, and zero-knowledge proofs, and are crucial elements for verifying the legality of cross-chain transactions, asset status, and demonstrating transaction atomicity.

[0073] Optionally, the specific implementation steps are as follows:

[0074] The first step is information extraction after the state is unlocked: After the state of the source chain and the target chain is unlocked, the monitoring sub-chain will calculate the amount of asset reduction on the source chain and the amount of asset increase on the target chain based on the information in the cross-chain transaction certificate.

[0075] The second step, global ledger update: After calculating the asset transfer amount, the monitoring subchain will update the global ledger to reflect the decrease in assets on the source chain and the increase in assets on the target chain. This update process helps ensure the real-time performance and accuracy of the global ledger, providing a basis for subsequent account reconciliation and transaction confirmation.

[0076] The third step is notification generation and transmission: Based on the update results of the global ledger, the monitoring subchain will generate notification information about the transaction completion status. This information details the execution status of the cross-chain request (success or failure), the specific details of the asset transfer, and any other details that require user attention. The notification information is sent via the blockchain's smart contract or directly through the user's digital wallet, helping users to understand the final status of the transaction in a timely and accurate manner.

[0077] In one alternative embodiment, the source chain is an Ethereum blockchain and the target chain is a consortium blockchain; or the source chain is a consortium blockchain and the target chain is an Ethereum blockchain.

[0078] Alternatively, Ethereum is a public blockchain based on the Ethereum Virtual Machine, such as Ethereum itself or compatible sidechains. Ethereum is characterized by its support for complex smart contracts, a broad developer community, and a rich ecosystem of applications.

[0079] Alternatively, a consortium blockchain is a private or semi-private blockchain network limited to a predefined set of members, such as enterprises or institutions. Consortium blockchains typically offer higher transaction speeds and privacy protection, but their smart contract functionality and on-chain applications may be relatively limited.

[0080] In an optional embodiment, the monitoring subchain's operation mechanism further includes: using a consensus mechanism combined with dynamic sharding verification to achieve distributed Byzantine protection, wherein the consensus mechanism is used to reach a consensus on rules or algorithms for specific data or transactions among all nodes, and dynamic sharding verification is used to divide network nodes into multiple shards, each shard being responsible for verifying and processing a portion of transactions, and the composition of the shards can be dynamically adjusted as network demands change.

[0081] Figure 2 This is a schematic diagram of an optional transaction request processing device based on a monitoring subchain according to an embodiment of this application. According to another aspect of an embodiment of this application, a transaction request processing device based on a monitoring subchain is also provided, including: a generation unit 201, a first processing unit 202, a second processing unit 203, and a third processing unit 204.

[0082] The system comprises the following components: a generation unit 201, which generates a cross-chain transaction certificate after the monitoring sub-chain detects and successfully verifies the cross-chain request. The cross-chain request is used to request the transfer of target funds from the source chain to the target chain, and the cross-chain transaction certificate is used to characterize the validity of the cross-chain request occurring on the source chain. A first processing unit 202, which locks the states of the source chain and the target chain, and then sends the cross-chain transaction certificate to the target chain. The target chain, after successfully verifying the cross-chain transaction certificate and confirming that the target funds on the source chain are frozen and the corresponding zero-knowledge proof verification of the source chain is passed, transfers the target funds from the source chain to the target chain and then sends a receipt indicating successful fund transfer to the monitoring sub-chain. A second processing unit 203, which sends a random key to the source chain after the monitoring sub-chain receives the receipt information. The source chain unfreezes the target funds and generates an on-chain certificate based on the received random key, and then sends the on-chain certificate to the monitoring sub-chain. A third processing unit 204, which unlocks the states of the source chain and the target chain after the monitoring sub-chain receives the on-chain certificate.

[0083] Optionally, the generation unit 201 includes: a first verification subunit, used to detect whether the number of transaction confirmations occurring on the source chain reaches a preset minimum confirmation threshold, wherein the number of transaction confirmations is used to determine whether the transaction is stable; and a second verification subunit, used to call a zero-knowledge proof protocol to verify the validity of the cross-chain request when the number of transaction confirmations occurring on the source chain reaches the minimum confirmation threshold.

[0084] Optionally, the first processing unit 202 includes: a first locking subunit, used to perform a state locking operation on the source chain, including: freezing the target funds on the source chain, wherein the frozen target funds are prohibited from being withdrawn or transferred again by the user during the cross-chain request; and a second locking subunit, used to perform a state locking operation on the target chain, including: creating a receiving account on the target chain with an inactive account balance, wherein the receiving account is used to receive the target funds on the target chain.

[0085] Optionally, the transaction request processing device based on the monitored subchain further includes: a creation unit for creating a bidirectional hash time lock, wherein the bidirectional hash time lock is used to coordinate the transaction time of the source chain and the target chain; a calculation unit for generating a random key after creating the bidirectional hash time lock, and then using a cryptographic algorithm to calculate the hash value of the random key; an acquisition unit for acquiring network status information between the source chain and the target chain; and an adjustment unit for adjusting the timeout window corresponding to the bidirectional hash time lock according to the network status information, wherein the timeout window is a preset time threshold for automatically triggering transaction rollback, and the preset time threshold is determined based on the network latency and security threshold between the source chain and the target chain.

[0086] Optionally, the first processing unit 202 further includes: a verification subunit, used to verify the legality of the cross-chain request using a zero-knowledge proof protocol after the monitoring subchain generates a cross-chain transaction certificate, and to verify whether the target funds involved in the cross-chain request have been used for other transaction requests besides the cross-chain request.

[0087] Optionally, the transaction request processing device based on the monitored subchain further includes: a rollback unit, used to determine that the cross-chain request has not been successfully executed if the target chain does not send a signal of successful verification within the timeout window, or if it is found during the verification process that the target funds on the source chain are not frozen, or if the zero-knowledge proof corresponding to the source chain fails verification, and then initiate a refund process, wherein the refund process includes: the source chain unfreezing the target funds and returning the target funds to the user account.

[0088] Optionally, the transaction request processing device based on the monitored subchain further includes: an update unit, used to calculate the asset reduction on the source chain and the asset increase on the target chain based on the information in the cross-chain transaction certificate, and update the global ledger, wherein the global ledger is used to record the execution status and execution result of the cross-chain request; and a notification unit, used to generate notification information about the transaction completion status based on the update result of the global ledger.

[0089] Optionally, the source chain is an Ethereum blockchain and the target chain is a consortium blockchain; or the source chain is a consortium blockchain and the target chain is an Ethereum blockchain.

[0090] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described transaction request processing method based on the monitoring subchain.

[0091] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to perform the above-described transaction request processing method based on a monitoring subchain.

[0092] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described transaction request processing method based on a monitoring subchain.

[0093] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0094] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0095] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0096] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0097] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0098] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0099] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A transaction request processing method based on monitoring a subchain, wherein, The transaction request processing method based on the monitoring subchain is applied to the monitoring subchain, which is used to coordinate and verify cross-chain interaction operations between different blockchains. Its features include: After the monitored subchain detects a cross-chain request and successfully verifies the cross-chain request, a cross-chain transaction certificate is generated. The cross-chain request is used to request the transfer of target funds on the source chain to the target chain, and the cross-chain transaction certificate is used to characterize the validity of the cross-chain request occurring on the source chain. The states of the source chain and the target chain are locked, and then the cross-chain transaction certificate is sent to the target chain. Wherein, if the target chain successfully verifies the cross-chain transaction certificate, confirms that the target funds on the source chain have been frozen and the zero-knowledge proof corresponding to the source chain has been verified, the target chain transfers the target funds on the source chain to the target chain, and then sends a receipt message indicating that the funds have been successfully transferred to the monitoring sub-chain. After receiving the receipt information, the monitoring sub-chain sends a random key to the source chain, wherein the source chain unfreezes the target funds and generates an on-chain certificate based on the received random key, and then sends the on-chain certificate to the monitoring sub-chain; After the monitoring sub-link receives the on-chain credential, it unlocks the state of the source chain and the target chain.

2. The method according to claim 1, characterized in that, The verification operation of the monitoring subchain for the cross-chain request includes: The system detects whether the number of transaction confirmations occurring on the source chain has reached a preset minimum confirmation threshold, wherein the number of transaction confirmations is used to determine whether the transactions are stable. If the number of transaction confirmations occurring on the source chain reaches the minimum confirmation threshold, a zero-knowledge proof protocol is invoked to verify the validity of the cross-chain request.

3. The method according to claim 1, characterized in that, Locking the states of the source chain and the target chain includes: Performing a state locking operation on the source chain includes: freezing the target funds on the source chain, wherein the frozen target funds are prohibited from being withdrawn or transferred again by the user during the cross-chain request; The state locking operation on the target chain includes: creating a receiving account on the target chain with an inactive account balance, wherein the receiving account is used to receive the target funds on the target chain.

4. The method according to claim 1, characterized in that, After locking the states of the source chain and the target chain, the method further includes: Create a bidirectional hash time lock, wherein the bidirectional hash time lock is used to coordinate the transaction time of the source chain and the target chain; After creating the bidirectional hash time lock, the random key is generated, and then the hash value of the random key is calculated using an encryption algorithm; Obtain network status information between the source chain and the target chain; The timeout window corresponding to the bidirectional hash time lock is adjusted according to the network condition information. The timeout window is a preset time threshold for automatically triggering transaction rollback. The preset time threshold is determined based on the network latency and security threshold between the source chain and the target chain.

5. The method according to claim 1, characterized in that, The verification process of the zero-knowledge proof corresponding to the source chain includes: After the monitoring subchain generates the cross-chain transaction certificate, the legality of the cross-chain request is verified using a zero-knowledge proof protocol, and it is also verified whether the target funds involved in the cross-chain request have been used for other transaction requests besides the cross-chain request.

6. The method according to claim 4, characterized in that, The method further includes: If the target chain does not return a successful verification signal within the timeout window, or if it is found during the verification process that the target funds on the source chain are not frozen, or if the zero-knowledge proof corresponding to the source chain fails verification, then the cross-chain request is determined to have failed to execute, and a refund process is initiated. The refund process includes: the source chain unfreezing the target funds and returning the target funds to the user's account.

7. The method according to claim 1, characterized in that, After unlocking the states of the source chain and the target chain, the method further includes: Based on the information in the cross-chain transaction certificate, calculate the asset reduction on the source chain and the asset increase on the target chain, and update the global ledger, wherein the global ledger is used to record the execution status and execution result of the cross-chain request; Based on the update results of the global ledger, a notification message regarding the transaction completion status is generated.

8. The method according to any one of claims 1 to 7, characterized in that, The source chain is Ethereum, and the target chain is a consortium blockchain; or the source chain is a consortium blockchain, and the target chain is Ethereum.

9. A transaction request processing device based on a monitored subchain, characterized in that, include: A generation unit is used to generate a cross-chain transaction certificate after the monitored sub-chain detects a cross-chain request and successfully verifies the cross-chain request. The cross-chain request is used to request the transfer of target funds on the source chain to the target chain, and the cross-chain transaction certificate is used to characterize the validity of the cross-chain request occurring on the source chain. The first processing unit is used to lock the states of the source chain and the target chain, and then send the cross-chain transaction certificate to the target chain. Wherein, if the target chain successfully verifies the cross-chain transaction certificate, confirms that the target funds on the source chain have been frozen and the zero-knowledge proof corresponding to the source chain has been verified, the target chain transfers the target funds on the source chain to the target chain, and then sends a receipt message indicating that the funds have been successfully transferred to the monitoring sub-chain. The second processing unit is configured to send a random key to the source chain after the monitoring sub-chain receives the receipt information, wherein the source chain unfreezes the target funds and generates an on-chain certificate based on the received random key, and then sends the on-chain certificate to the monitoring sub-chain. The third processing unit is used to unlock the state of the source chain and the target chain after the monitoring sub-link receives the on-chain credential.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device containing the computer-readable storage medium performs the transaction request processing method based on a monitoring subchain as described in any one of claims 1 to 8.

11. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the transaction request processing method based on a monitoring subchain as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the transaction request processing method based on any one of claims 1 to 8.

Images