Contract processing methods, apparatus, computer equipment and storage media

Abstract

This application discloses a method, apparatus, computer device, and storage medium for contract processing, applied in the field of computer technology. The method includes: receiving a cross-contract transaction request sent by a client node; constructing a contract collaboration group based on a list of contract addresses; sending corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node executes a processing operation for the cross-contract transaction based on the corresponding pre-operation instructions; receiving pre-operation results sent by each contract node, obtaining M pre-operation results; and, if the M pre-operation results include a failed execution result, sending a corresponding first rollback instruction to each contract node in the contract collaboration group, so that each contract node performs a rollback processing on the corresponding processing operation based on the first rollback instruction. The aim is to ensure the atomicity of each node during cross-contract transactions and reduce asset losses caused by inconsistent states.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to methods, apparatus, computer equipment and storage media for contract processing. Background Technology

[0002] A smart contract is a computer program stored on the blockchain that can automatically execute the terms of the contract. Understandably, a single smart contract can only perform a single function such as "deducting payment" or "adding points." However, in real-world business transactions (such as e-commerce orders, financial transfers, and supply chain settlements), multiple contracts are usually required to collaborate and complete a transaction through cross-contract coordination.

[0003] Currently, the mainstream method for cross-contract transactions involves developers sequentially invoking multiple smart contracts at the code level using call instructions and execution call instructions. Correspondingly, its atomicity relies on developers manually writing rollback logic within the contracts to process the execution results of each contract one by one.

[0004] However, since manually writing code cannot cover all failure scenarios, and blockchain operations are irreversible, if subsequent code continues to be executed without recognizing a failed operation, previous operations (such as deductions) will be irreversible due to the updated state, and subsequent operations (receiving payment or shipping goods) will fail to execute due to operational errors. If a rollback mechanism is triggered at this point, some operations will roll back successfully, while others will fail, resulting in irreparable asset losses. Summary of the Invention

[0005] This application provides a method, apparatus, computer equipment, and storage medium for contract processing, aiming to ensure the atomicity of each node during cross-contract transactions and reduce asset losses caused by inconsistent states.

[0006] This application provides a method for contract processing, including: Receive cross-contract transaction requests sent by client nodes. The cross-contract transaction requests carry pre-operation information and a list of contract addresses. The list of contract addresses includes M smart contract addresses, where M is an integer greater than 1. A contract collaboration group is constructed based on the list of contract addresses. The contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to a smart contract address. Send corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node can perform processing operations for cross-contract transactions based on the corresponding pre-operation instructions; Receive the pre-operation results sent by each contract node to obtain M pre-operation results; If the M pre-operation results include failure execution results, send the corresponding first rollback instruction to each contract node in the contract collaboration group, so that each contract node can roll back the corresponding processing operation based on the first rollback instruction.

[0007] Another aspect of this application provides a contract processing apparatus, comprising: The receiving module is used to receive cross-contract transaction requests sent by client nodes. The cross-contract transaction request carries pre-operation information and a list of contract addresses. The list of contract addresses includes M smart contract addresses, where M is an integer greater than 1. The processing module is used to construct a contract collaboration group based on the list of contract addresses. The contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to a smart contract address. The sending module is used to send corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node can perform processing operations for cross-contract transactions based on the corresponding pre-operation instructions. The receiving module is also used to receive the pre-operation results sent by each contract node, resulting in M ​​pre-operation results; The processing module is also used to send a corresponding first rollback instruction to each contract node in the contract collaboration group through the sending module when the M pre-operation results include failure execution results, so that each contract node can roll back the corresponding processing operation based on the first rollback instruction.

[0008] Optionally, in some possible implementations of this application, The processing module is specifically used to determine M nodes as contract nodes from the candidate node set of the blockchain network based on the number of smart contract addresses in the contract address list. The sending module is specifically used to send the corresponding smart contract address to each contract node, so that each contract node can call the corresponding smart contract based on the corresponding smart contract address. The calling module is used to call the corresponding smart contract M contract nodes as a contract collaboration group.

[0009] Optionally, in some possible implementations of this application, the pre-operation information includes simulated operation information and resource locking information; The processing module is specifically used to generate corresponding simulated operation instructions based on the pre-operation information; Generate corresponding resource locking instructions based on resource locking information. The sending module is specifically used to send corresponding simulation operation instructions and resource lock instructions to each contract node in the contract collaboration group. The simulation operation instructions are used to trigger each contract node to perform simulation processing operations for cross-contract transactions, and the resource lock instructions are used to trigger each contract node to perform resource lock operations for cross-contract transactions.

[0010] Optionally, in some possible implementations of this application, The sending module is also used to send a corresponding confirmation execution instruction to each contract node in the contract collaboration group when all M pre-operation results include a successful execution result, so that each contract node runs the corresponding smart contract based on the confirmation execution instruction.

[0011] Optionally, in some possible implementations of this application, the contract collaboration group also includes multiple witness nodes. Witness nodes are nodes that are different from contract nodes and are determined from the candidate node set of the blockchain network. They are used to verify the pre-operation results of each contract node and to vote on consensus. The sending module is also used to send corresponding consensus trigger instructions to each contract node and each witness node in the contract collaboration group when all M pre-operation results include successful execution results, so that each contract node votes on the M pre-operation results and each witness node votes on the M pre-operation results. The receiving module is also used to receive the voting results sent by each contract node and each witness node respectively; The processing module is also used to confirm that each contract node and each witness node have the same consensus when the number of votes reaches a threshold among multiple voting results. The sending module is also used to send corresponding confirmation execution instructions to each contract node in the contract collaboration group, provided that the consensus between each contract node and each witness node is consistent and all M pre-operation results include successful execution.

[0012] Optionally, in some possible implementations of this application, The acquisition module is used to obtain the account private key hash value, account public key, and permission validity period from cross-contract transaction requests; The processing module is also used to combine the account public key, permission validity period, and contract address list into verification input information; The account private key hash value, account public key, permission validity period and contract address list are encrypted and calculated to generate a proof subject; Hash the account public key, permission validity period, and contract address list to obtain the credential hash value; The proof subject and the certificate hash value are combined to form the verification certificate information; The sending module is also used to send the verification credential information and the verification input information to each contract node respectively; If each contract node determines that the verification rules are met based on the verification certificate information and the verification input information, then it sends the corresponding pre-operation instruction to each contract node in the contract collaboration group.

[0013] Optionally, in some possible implementations of this application, The processing module is also used to generate temporary public keys for cross-contract transaction requests based on cryptographic algorithms; The acquisition module is also used to acquire the group identifier of the contract collaboration group; The processing module is also used to combine the group identifier, temporary public key, verification credential information, and verification input information into a temporary token; The sending module is also used to send temporary tokens to each contract node, so that each contract node can verify the legality of cross-contract transactions based on the temporary tokens.

[0014] Optionally, in some possible implementations of this application, The acquisition module is also used to obtain the whitelist information corresponding to the account's public key; The processing module is also used to perform legality verification on each contract address in the contract address list based on the whitelist information; When all contract addresses are included in the whitelist information, the legality of each smart contract corresponding to the contract address list is determined. The sending module is also used to send corresponding pre-operation instructions to each contract node in the contract collaboration group, provided that the cross-contract transaction is legal and all contract addresses are included in the whitelist information.

[0015] Optionally, in some possible implementations of this application, The acquisition module is also used to acquire abnormal status information corresponding to the contract node that is in an abnormal running state when any contract node is in an abnormal running state. The processing module is also used to determine the abnormality level corresponding to the abnormality status information based on the abnormality status information and the abnormality level mapping table; The sending module is also used to send corresponding exception handling instructions to the corresponding contract nodes according to the exception level corresponding to the exception status information, so that the corresponding contract nodes can perform exception handling operations according to the exception level corresponding to the exception status information based on the exception handling instructions.

[0016] Optionally, in some possible implementations of this application, The sending module is specifically used to send a corresponding second rollback instruction to each contract node when the abnormality level corresponding to the abnormal status information includes the first level, so that each contract node can roll back to the state before receiving the cross-contract transaction request based on the second rollback instruction. If the abnormal status information corresponds to the second level of abnormality, a corresponding third rollback instruction is sent to each contract node in the abnormal running state so that each contract node in the abnormal running state rolls back the target operation based on the second rollback instruction. The target operation is the processing operation of each contract node corresponding to the abnormal status information, and the first level is higher than the second level. The processing module is specifically used to store the abnormal status information as an abnormal log when the abnormal status information corresponds to the third level of abnormality.

[0017] Optionally, in some possible implementations of this application, The processing module is also used to generate retry parameters based on the cross-contract transaction request when it receives the rollback confirmation information sent by each contract node in an abnormal running state. The rollback confirmation information is used to indicate that the contract node in an abnormal running state has successfully rolled back the target operation. Sign the hash value of the retry parameter based on the private key corresponding to the retry function; Based on the hash value of the retry parameters after signing, the retry interface address is provided to the client node, so that the client node can execute the transaction retry request based on the retry interface address.

[0018] Optionally, in some possible implementations of this application, The processing module is also used to determine the target error type corresponding to the abnormal status information based on the mapping table between abnormal status information and error type; The acquisition module is also used to obtain the processing scheme corresponding to the target error type based on the type scheme mapping table; The sending module is also used to send corresponding prompt messages to client nodes based on the processing scheme.

[0019] Another aspect of this application provides a computer device, comprising: Memory, transceiver, processor, and bus system; The memory is used to store programs; The processor is used to execute programs in memory, including methods for performing contract processing of the above aspects; Bus systems are used to connect memory and processor to enable communication between them.

[0020] Another aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the contract processing described above.

[0021] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the contract processing methods provided in the above aspects.

[0022] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: This application establishes a contract collaboration group, with a coordinating node acting as the master node and each contract node as a slave node, enabling all contract nodes to work uniformly under the coordination of the coordinating node. Furthermore, since each contract node in the collaboration group runs a smart contract from the contract address list, all smart contracts can execute uniformly under the coordination of the coordinating node. Simultaneously, combined with a two-phase commit mechanism, the coordinating node can also coordinate all contract nodes to perform pre-operations to determine whether all smart contracts can be executed correctly, thereby identifying potential failure risks before formal execution.

[0023] Since the pre-operation actions do not change the state of the smart contract, the coordinating node can control all contract nodes to roll back precisely to the state before the pre-operation if it is determined that some contract nodes have failed to execute. This avoids the irreversibility of blockchain operations, which would cause the previous operations to be irreversible. As a result, it can avoid the situation where some operations are rolled back successfully while others fail to roll back, thereby reducing the corresponding asset losses. Attached Figure Description

[0024] Figure 1 An architecture diagram illustrating the application scenario of the method provided in the embodiments of this application in a cross-border e-commerce process; Figure 2 An architecture diagram illustrating the application scenario of the method provided in the embodiments of this application in a distributed financial process; Figure 3 A flowchart illustrating the contract processing method provided in this application embodiment; Figure 4 A schematic diagram of the structure of the temporary token provided in the embodiments of this application; Figure 5 A timing diagram of the contract processing method provided in the embodiments of this application in the event of a transaction failure; Figure 6A flowchart illustrating the workflow of the cross-contract atomicity coordination module provided in this application embodiment; Figure 7 A flowchart illustrating the workflow of the cross-contract permission proxy module provided in this application embodiment; Figure 8 A flowchart illustrating the workflow of the cross-contract exception collaborative processing module provided in this application embodiment; Figure 9 A flowchart illustrating the workflow of the dynamic transaction fee pre-allocation and adjustment module provided in this application embodiment; Figure 10 A flowchart illustrating the workflow of the contract collaboration log storage and traceability module provided in this application embodiment; Figure 11 A structural diagram of the contract processing apparatus provided in the embodiments of this application; Figure 12 A structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] This application provides a method for contract processing. By combining a contract collaboration group with a two-phase commit mechanism, in the event that a contract node fails to execute, a coordinating node coordinates all contract nodes to precisely roll back to the point before the pre-operation, thus avoiding the irreversibility of blockchain operations that would prevent previous operations from being undone and reducing corresponding asset losses.

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0027] 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.

[0028] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0029] It should be noted that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0030] Before introducing the specific methods of this application, we will first provide an illustrative example of the application scenarios for the contract processing methods in this application. It should be understood that the following application scenarios are merely illustrative and are not limited to these examples.

[0031] (i) The method provided in the embodiments of this application can be applied in cross-border payments. For example... Figure 1 As shown, Figure 1 This diagram illustrates the architecture of the method provided in this application embodiment in a cross-border e-commerce process. The client node can be a server or terminal used by the user; this application uses the client node as a terminal as an example for illustration. The architecture includes: terminal 101, server 102, and network 103.

[0032] like Figure 1 When a user initiates a cross-contract transaction request in a cross-border e-commerce scenario: Step S201: Terminal 101, acting as a client node, sends a cross-contract transaction request; Step S202: Terminal 101 sends a cross-contract transaction request to server 102 via network 103; Step S203: Server 102 receives a cross-contract transaction request. The cross-contract transaction request carries pre-operation information of the cross-border e-commerce process (such as deduction operation information such as buyer account balance and buyer account address, exchange rate and payment currency conversion operation information, and payment operation information such as goods delivery certificate and seller account address) and a list of contract addresses of the cross-border e-commerce process. The list of contract addresses includes M smart contract addresses, such as fund custody contract address, exchange rate conversion contract address, verification and delivery contract address, and fund release contract address, where M is an integer greater than 1. Step S204: Server 102 constructs a contract collaboration group based on the contract address list of the cross-border e-commerce process. The contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to a smart contract address. In step S205, server 102 sends the corresponding pre-operation instructions for the cross-border e-commerce process to each contract node in the contract collaboration group, so that each contract node performs processing operations for cross-contract transactions of the cross-border e-commerce process based on the corresponding pre-operation instructions for the cross-border e-commerce process (e.g., simulated deduction operation, simulated currency conversion operation, simulated payment operation, etc.). The pre-operation instructions for the cross-border e-commerce process carry the smart contract address of the cross-border e-commerce process. Step S206: Server 102 receives the pre-operation results of the cross-border e-commerce process sent by each contract node, and obtains the pre-operation results of M cross-border e-commerce processes. In step S207, if the server 102 sends a corresponding first rollback instruction to each contract node in the contract collaboration group when the M pre-operation results include failure execution results, so that each contract node can roll back the processing operation of the corresponding cross-border e-commerce process based on the first rollback instruction.

[0033] In the application scenarios of cross-border e-commerce processes, the method provided in this application uses a server in the blockchain network as a coordinating node, and the coordinating node selects other servers in the blockchain network as contract nodes, so that the coordinating node and the contract nodes together form a contract collaboration group. Each contract node calls the corresponding smart contract according to M smart contract addresses, such as the fund custody contract address, currency exchange contract address, verification and delivery contract address, and fund release contract address sent by the coordinating node, so that each smart contract runs on an independent server. Based on this, the coordinating node can coordinate the operation of multiple smart contracts simultaneously, thereby uniformly verifying the execution conditions of each contract and locking relevant resources during the preparation stage. After all contracts are confirmed to be executable, a formal submission instruction is sent uniformly. If any contract fails to execute, a full rollback is triggered, achieving atomicity protection in the cross-border e-commerce process, reducing transaction disputes, and lowering platform compliance risks.

[0034] (ii) The method provided in the embodiments of this application can be applied in supply chain finance. For example... Figure 2 As shown, Figure 2 This diagram illustrates the architecture of the method provided in this application embodiment in a distributed financial process. The client node can be a server or terminal used by the user; this application uses a terminal as an example for illustration. The architecture includes: terminal 301, server 302, and network 303.

[0035] like Figure 2When a user initiates a cross-contract transaction request in a distributed financial process within a merchant payment scenario: Step S401: Terminal 301, acting as a client node, sends a cross-contract transaction request; Step S402: Terminal 301 sends the cross-contract transaction request to server 302 via network 303; In step S403, server 302 receives a cross-contract transaction request. The cross-contract transaction request carries pre-operation information of the distributed financial process (such as warehouse receipt generation operation information such as the quantity and location of the pledged goods, loan operation information such as the associated loan contract, payee account address, and lender account address, and repayment and release operation information such as the associated original loan, repayment amount, and quantity of released goods, which are not limited here) and a list of contract addresses of the distributed financial process. The list of contract addresses includes M smart contract addresses, including digital warehouse receipt contract address, credit approval contract address, payment settlement contract address, and automatic release contract address, where M is an integer greater than 1. Step S404: Server 302 constructs a contract collaboration group based on the contract address list of the distributed financial process. The contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to a smart contract address. In step S405, server 302 sends the corresponding pre-operation instructions of the distributed financial process to each contract node in the contract collaboration group, so that each contract node performs cross-contract transaction processing operations for the distributed financial process based on the corresponding pre-operation instructions of the distributed financial process (e.g., simulated warehouse receipt generation, simulated loan disbursement, simulated loan repayment and release of collateral, etc.). The pre-operation instructions of the distributed financial process carry the smart contract address of the distributed financial process. Step S406: Server 302 receives the pre-operation results of the distributed financial process sent by each contract node, and obtains M pre-operation results of the distributed financial process. In step S407, if all M pre-operation results include successful execution results, server 302 sends a corresponding confirmation execution instruction to each contract node in the contract collaboration group, so that each contract node runs the smart contract of the corresponding distributed financial process based on the confirmation execution instruction.

[0036] In distributed financial processes, the method provided in this application combines a server as a coordinating node with contract nodes running various smart contracts to form a contract collaboration group. The coordinating node coordinates the contract nodes to perform pre-operations to determine if all operations corresponding to each smart contract can be executed normally. After confirming that all operations corresponding to all smart contracts can be executed normally, the coordinating node then sends execution instructions to each contract node, driving them to execute the operations determined in the preparation phase. Based on this two-phase coordination scheme of the contract collaboration group, the distributed financial process can avoid falling into an intermediate state where some operations rollback successfully while others fail, ensuring the safe flow of financial funds between smart contracts. This achieves atomicity in cross-contract transactions within the distributed financial process, reduces the risk of asset loss due to transaction failures, and enhances user trust.

[0037] It should be noted that the above application scenarios are merely examples, and the contract processing method provided in this embodiment can also be applied to other scenarios, which are not limited here.

[0038] Given that this application involves some technical terms, explanations will be provided below for ease of understanding.

[0039] (1) Atomicity: This is the core requirement of transaction processing. A transaction can only succeed completely and be permanently effective, or it can only fail completely and the system state can be completely rolled back to before the start of the transaction. There is no intermediate state of "partial success and partial failure". In cross-contract transactions, atomicity means that the state changes of all smart contracts involved must be consistent. There cannot be a situation where some contracts succeed while others fail.

[0040] (2) Cross-contract transaction: A complex transaction completed by multiple independent contracts in collaboration according to a preset logic. Cross-contract atomic transaction is a cross-contract transaction that satisfies the characteristics of "full success or full rollback". When any contract fails to execute, all executed contract operations can be accurately rolled back to the state before the transaction, and there is no intermediate state.

[0041] (3) Contract Collaboration Group (CCG): A temporary collaboration unit built for a single cross-contract transaction, which includes all contract nodes, coordination nodes and witness nodes involved in the transaction, and realizes instruction synchronization and status interaction through a unified communication protocol.

[0042] (4) Cross-contract authorization proxy (CPA): The authorization transfer mechanism implemented with zero-knowledge proof technology does not require users to repeatedly authorize multiple contracts. It completes the verification of multi-contract call permissions through a one-time proxy certificate, ensuring authorization security and convenience.

[0043] (5) Two-Phase Commit Coord (2PC-Coord): A two-phase commit scheme adapted to the cross-contract atomicity guarantee mechanism of blockchain. The two-phase commit includes a preparation phase and an execution phase. The preparation phase is used to complete all contract pre-operations and state locking. The execution phase is used to synchronously execute the commit or rollback operation based on the pre-operation results.

[0044] (6) State Snapshot Chain: A chain structure that records the state changes of each contract throughout the entire lifecycle of cross-contract transactions. Each snapshot is associated with a unique identifier, supporting precise rollback at the snapshot level in case of failure, ensuring rollback consistency.

[0045] Based on the above introduction, the contract processing method in this application will be described. It should be noted that this application can be completed independently by the server.

[0046] Please see Figure 3 One embodiment of the contract processing method in this application includes: S501. Receive a cross-contract transaction request sent by the client node. The cross-contract transaction request carries pre-operation information and a list of contract addresses. The list of contract addresses includes M smart contract addresses, where M is an integer greater than 1. In one or more embodiments, the client node can be a terminal used by the user (such as a mobile phone, tablet, or other device) or a server connected to the interactive device (such as a desktop server); cross-contract transaction refers to a transaction in which two or more different smart contracts need to be called sequentially or simultaneously to complete a blockchain transaction. The two or more different smart contracts can be smart contracts on the same blockchain or cross-chain smart contracts; smart contract address is the storage address of the smart contract in the blockchain; pre-operation information includes at least the type of operation to be performed by each smart contract (such as deduction type, exchange type, or payment type), operation parameters (such as amount parameters, account address parameters, or currency parameters), and verification rules for verifying whether the pre-operation is successful.

[0047] It should be noted that when submitting a cross-contract transaction request, in addition to submitting the necessary payment account address and receiving account address, users also need to select M smart contracts required for this transaction. For example, these could be digital warehouse receipt contracts, credit approval contracts, or payment settlement contracts required in distributed finance. The client node summarizes the smart contract addresses corresponding to these smart contracts into a contract address list, and obtains the corresponding pre-operation parameters based on the contract content within the smart contracts. The contract address list and the pre-operation parameters are then added together to the cross-contract transaction request.

[0048] Subsequently, when a client node uploads a cross-contract transaction request to the blockchain, it needs to first select a node with coordination capabilities from the candidate node set of the blockchain network. This node will then act as the coordination node to send the cross-contract transaction request, thus enabling the transaction to be uploaded to the blockchain (in other words, the execution entity of the method in this application is the coordination node). The coordination capabilities of each node in the candidate node set are pre-configured by the developers.

[0049] This application receives cross-contract transaction requests sent by client nodes, extracts the pre-operation information and contract address list carried in the cross-contract transaction requests, provides basic data support for the subsequent construction of contract collaboration groups and coordination of various contract nodes, and avoids the impact of data loss on subsequent processing procedures.

[0050] S502. Construct a contract collaboration group based on the contract address list. The contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to a smart contract address. In one or more embodiments, a contract collaboration group is a "temporary dedicated working group" formed for a single cross-contract transaction. All nodes within the group serve only this transaction, and the working group is disbanded upon completion of the transaction. A contract collaboration group includes a coordinating node involved in the transaction and all contract nodes, which synchronize instructions and exchange states through a unified communication protocol.

[0051] Specifically, building contract collaboration groups based on the list of contract addresses includes: Based on the number of smart contract addresses in the contract address list, M nodes are selected as contract nodes from the candidate node set of the blockchain network; Send the corresponding smart contract address to each contract node so that each contract node can call the corresponding smart contract based on the corresponding smart contract address; M contract nodes that invoke the corresponding smart contract form a contract collaboration group.

[0052] Taking a distributed financial process as an example: After obtaining the list of contract addresses for the distributed financial process, the coordinating node determines a corresponding number (where M is 4) of nodes with consensus functionality (i.e., consensus nodes) from the candidate node set of the blockchain network, based on the number of smart contract addresses in the list (e.g., when the list includes digital warehouse receipt contract addresses, credit approval contract addresses, payment settlement contract addresses, and automatic collateral release contract addresses, the number of smart contract addresses is 4). Then, each smart contract address in the list is sent to the corresponding contract node, enabling each contract node to invoke the corresponding smart contract based on its received smart contract address. Thus, the coordinating node is designated as the master node, and the contract nodes as slave nodes, constructing a contract collaboration group to handle the distributed financial process.

[0053] Before selecting a contract node, the coordinating node must first check the blockchain node state database to confirm whether there are any nodes in the candidate node set of the blockchain network that are in a frozen or abnormal state. If there are any nodes in a frozen or abnormal state, they will be removed from the candidate node set of the blockchain network.

[0054] This application establishes a contract collaboration group, creating a temporary dedicated working group for each cross-contract transaction within the blockchain network. By clearly defining the roles of each node within this working group, each node communicates and operates according to unified collaboration rules based on its role within the group. This ensures that the contract collaboration group serves only the current transaction and that all nodes within the group can be uniformly coordinated and managed, laying the foundation for subsequent atomic transaction processing.

[0055] Furthermore, since existing blockchain nodes typically work in parallel, meaning a single node may participate in multiple transactions, to avoid this situation, it is possible to encode the contract collaboration group and generate a corresponding group identifier. This ensures that during subsequent information transmissions (including instruction sending), each node only receives and processes information with the group identifier.

[0056] S503. Send the corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node can perform processing operations for cross-contract transactions based on the corresponding pre-operation instructions. In one or more embodiments, the pre-operation instruction is a task order sent by the coordinating node to each contract node during the preparation phase of the two-phase commit, which enables the node to determine the processing operation to be simulated, how to perform the operation, and the resources that need to be locked.

[0057] Specifically, the following explanation will use the aforementioned example of a distributed financial process: In the contract collaboration group of a distributed financial process, after each contract node invokes the corresponding smart contract based on the received smart contract address, it sends corresponding pre-operation instructions to each contract node according to the specific information of the cross-contract transaction request. For example, the pre-operation instruction sent to contract node A1 (which invokes a payment settlement contract) includes the following: transfer amount from the sender's account to the receiver's address (i.e., the operation type is loan disbursement), sender's address, receiver's address, transfer amount A (operation parameters), and temporary locking of the sender's account (resource locking rules).

[0058] At this point, after receiving the pre-operation instruction, contract node A1 parses the instruction to determine the operation type, operation parameters, and resource locking rules, thereby executing the transfer logic in the sandbox environment and locking the sender's account.

[0059] Furthermore, the pre-operation instruction can also carry the smart contract address, allowing each contract node to compare and verify the smart contract address in the pre-operation instruction with its own assigned smart contract address after receiving the instruction. If the two are inconsistent, the contract node can refuse execution and report an exception, preventing erroneous operations caused by system configuration errors, malicious attacks, or node software defects.

[0060] This solution, through the above process, enables the coordinating node to send corresponding pre-operation instructions to each contract node, triggering each node to perform pre-operations based on the corresponding pre-operation instructions, in order to determine whether each contract node can normally execute the various operations in the corresponding smart contract, thus laying the foundation for subsequent atomic commits.

[0061] S504. Receive the pre-operation results sent by each contract node to obtain M pre-operation results; In one or more embodiments, the pre-operation result is used to characterize whether each contract node has successfully pre-operated on the operations in the smart contract it invoked.

[0062] It is understandable that each contract node is used to pre-operate on various operations of a smart contract. Therefore, each contract node sends a pre-operation result. That is, when each contract node sends a pre-operation result to the coordinating node, the coordinating node receives a total of M pre-operation results.

[0063] Specifically, the above embodiments will be used for further explanation: After contract node A1 completes the pre-operation according to the received pre-operation instructions, if it can transfer the amount A from the sender's account to the receiver's account normally according to the payment settlement contract, the pre-operation result is determined to be a successful execution result; if it cannot transfer the amount A from the sender's account to the receiver's account normally according to the payment settlement contract due to insufficient amount, incorrect receiver address, execution timeout, or other reasons, the pre-operation result is determined to be a failed execution result.

[0064] Afterwards, contract node A1 and other contract nodes in the contract collaboration will return the corresponding pre-operation results (with the reason for failure if the execution fails) to coordinating node A (i.e., the coordinating node in the contract collaboration group of distributed finance), and coordinating node A will collect all the pre-operation results.

[0065] Furthermore, the pre-operation results can also carry an identifier of locked resources, which is used to mark the resources locked by the corresponding contract node during the pre-operation process, so that they can be transferred, used or unlocked in the subsequent formal operation.

[0066] The pre-operation results reported by each contract node in this application after independently conducting pre-operations provide a definitive basis for judging whether cross-contract transactions can enter the next stage, reducing the possibility of some operations succeeding and others failing during the formal execution process.

[0067] S505. If the M pre-operation results include failure execution results, send the corresponding first rollback instruction to each contract node in the contract collaboration group, so that each contract node can roll back the corresponding processing operation based on the first rollback instruction.

[0068] In one or more embodiments, the first rollback instruction is used to trigger the rollback of the pre-operation to be performed by each contract node, so that each contract node is restored to the state before the pre-operation.

[0069] Understandably, in order to ensure the atomicity of subsequent operations of each contract node, the state of each contract node needs to be unified (all executed successfully or all executed unsuccessfully). Therefore, if any contract node reports an execution failure, then in the subsequent formal execution process, there is a high possibility that some operations will be executed successfully and some operations will be executed unsuccessfully, resulting in the atomicity of each contract node being violated.

[0070] Therefore, the coordinating node is configured to send a first rollback instruction upon receiving any failed execution result, in order to roll back each pre-operation to its state before execution.

[0071] Specifically, following the above embodiment, assuming M is 3, the contract collaboration group corresponding to distributed finance also includes contract node A2 and contract node A3. Among them, contract node B is used to perform pre-operations for warehouse receipt generation and pre-operations for repayment and release of collateral. In the event of three pre-operation results, including a failed execution, coordinating node A sends corresponding first rollback instructions to contract nodes A1, A2, and A3 respectively. At this point, contract node A1 rolls back the pre-operation for loan disbursement to its previous state. In the sandbox environment, the sender's account has not yet transferred funds to the recipient's address. Similarly, contract node A2 rolls back the pre-operation for warehouse receipt generation to its previous state, and contract node A3 rolls back the pre-operation for loan repayment and release. Furthermore, all assets locked during the pre-operation process are simultaneously unlocked, globally and consistently returning the status of all contract nodes in the contract collaboration group to their original state.

[0072] Since the pre-operations of each contract node are not committed to the blockchain, all modifications are local and temporary. Therefore, even if some contract nodes succeed while others fail during pre-operations, the temporary states of all contract nodes will be uniformly revoked through the first rollback instruction because the pre-operation results have not yet been solidified. This avoids the possibility of some operations succeeding while others fail.

[0073] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, the pre-operation information includes simulated operation information and resource locking information; Sending corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node can perform processing operations for cross-contract transactions based on the corresponding pre-operation instructions, including: Generate corresponding simulated operation instructions based on pre-operation information; Generate corresponding resource locking instructions based on resource locking information. Send corresponding simulation operation instructions and resource lock instructions to each contract node in the contract collaboration group. The simulation operation instructions are used to trigger each contract node to perform simulation processing operations for cross-contract transactions, and the resource lock instructions are used to trigger each contract node to perform resource lock operations for cross-contract transactions.

[0074] In one or more embodiments, simulation operation refers to the process of a contract node running various operations in a smart contract that is about to be executed in a local sandbox environment. This operation does not change the final state of the blockchain. Resource locking refers to the process of a contract node temporarily isolating the resources involved in the smart contract to ensure that these resources are not modified by other concurrent operations before the transaction is officially submitted.

[0075] It is understandable that when each contract node executes the pre-operation, the operations it simulates and the resources it locks will differ depending on the smart contract it invokes. Specifically, the above embodiment will be used for illustration: For distributed financial processes, when coordinating node A generates pre-operation instructions, it determines the smart contracts to be run based on the list of contract addresses it has obtained, and determines the various operations that the corresponding contract node needs to test in the local sandbox based on the content of each smart contract. It then generates corresponding simulated operation instructions based on these test operations. Additionally, it determines the resources that the corresponding contract node needs to lock in advance based on the content of each smart contract, and generates corresponding resource locking instructions based on these resources.

[0076] For example, for payment settlement contracts, simulated operation instructions include operations required for loan disbursement such as verifying the borrower's account eligibility (e.g., whether it meets credit conditions), whether the sender's account has sufficient available balance, and whether the current interest rate meets a preset threshold. Resource lock instructions include the amount of A value to be transferred in the sender's account required for loan disbursement.

[0077] Subsequently, coordinating node A packages the simulated operation instructions and resource locking instructions corresponding to each smart contract into pre-operation instructions, and sends different pre-operation instructions to the corresponding contract nodes according to the smart contracts called by each contract node. This enables each contract node to perform simulated processing operations for cross-contract transactions according to the corresponding simulated operation instructions, and to perform resource locking operations for cross-contract transactions according to the corresponding resource locking instructions.

[0078] For example, for contract node A1, it performs operations such as verifying the borrower's eligibility, querying the available balance in the sender's account, and obtaining the current interest rate and preset threshold according to the simulated operation instructions corresponding to the payment settlement contract. At the same time, according to the resource locking instructions corresponding to the payment settlement contract, it locks the amount of A value to be transferred in the sender's account to ensure that this part of the resources will not be occupied by other concurrent transactions during the pre-operation period.

[0079] This application enables each contract node to run transaction logic statelessly in a local sandbox environment by setting simulated operation instructions. This allows for the early detection and interception of failed operations due to insufficient balance, missing permissions, etc., ensuring that the transaction only enters the execution phase when all execution conditions are met, fundamentally eliminating the intermediate state of partial success and partial failure. Furthermore, by setting resource locking instructions, each contract node temporarily locks the relevant resources, ensuring that these resources are not occupied or tampered with by other concurrent operations before the transaction is officially submitted, providing a deterministic guarantee for the atomic execution of the transaction.

[0080] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, after receiving the pre-operation results sent by each contract node and obtaining M pre-operation results, the method further includes: If all M pre-operation results include successful execution results, send a corresponding confirmation execution instruction to each contract node in the contract collaboration group, so that each contract node runs the corresponding smart contract based on the confirmation execution instruction.

[0081] In one or more embodiments, the confirmation execution instruction is an instruction that triggers each contract node to formally execute the corresponding operation and unlock the locked resources, used to coordinate each contract node to enter the formal execution phase.

[0082] Specifically, the above embodiments will be used for illustration, where M is 3, and the contract collaboration group corresponding to distributed finance includes contract node A1, contract node A2, and contract node A3: If all three pre-operation results include a successful execution result, coordinating node A sends corresponding confirmation execution instructions to contract nodes A1, A2, and A3 respectively. At this point, contract node A1 officially executes the loan disbursement operation, contract node A2 officially executes the warehouse receipt generation operation, and contract node A3 officially executes the loan repayment and release operation. Furthermore, all assets locked during the pre-operation process are simultaneously unlocked and transferred accordingly based on each operation.

[0083] This application ensures that all contract nodes in the contract collaboration group execute formal operations synchronously by having a coordinating node coordinate with each other to enter the execution phase, provided that all M pre-operation results include successful execution. Through the coordinating node's unified confirmation of each contract node, the atomicity of all operations is ensured during the execution of cross-contract transactions, fundamentally guaranteeing the fund security of all parties involved in the transaction.

[0084] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, the contract collaboration group further includes multiple witness nodes. The witness nodes are nodes that are different from the contract nodes and are determined from the candidate node set of the blockchain network. They are used to verify the pre-operation results of each contract node and to vote on consensus. Before sending the corresponding confirmation execution instruction to each contract node in the contract collaboration group, the following steps are also included: If all M pre-operation results include successful execution results, send corresponding consensus trigger instructions to each contract node and each witness node in the contract collaboration group, so that each contract node votes on the M pre-operation results and each witness node votes on the M pre-operation results. Receive the voting results sent by each contract node and each witness node respectively; When the number of votes reaches a threshold among multiple voting results, it is confirmed that each contract node and each witness node have a consensus. If all M pre-operation results include successful execution results, send a corresponding confirmation execution instruction to each contract node in the contract collaboration group, including: If the consensus is consistent between each contract node and each witness node, and all M pre-operation results include successful execution, a corresponding confirmation execution instruction is sent to each contract node in the contract collaboration group.

[0085] In one or more embodiments, a witness node is a consensus node in the blockchain network that is not associated with the coordinating node or the contract node. It is used to supervise the consensus process and verify the various operations of the coordinating node and the contract node. Specifically, the witness node is selected by the coordinating node from the candidate node set of the blockchain network.

[0086] The consensus trigger instruction is an instruction that triggers all contract nodes and witness nodes to conduct consensus voting on the results of pre-operations. It includes a summary of M pre-operations. Consensus voting refers to the process by which multiple independent nodes collectively decide on a proposal (in this application, the results corresponding to each operation). It is used to avoid the entire transaction from being stuck due to node failure or malicious behavior (such as deliberately returning incorrect results) in the distributed system.

[0087] The voting threshold is set by the developers and is usually set to 2 / 3 of the total votes. This is to ensure that each participating node can still make the correct decision even when a small number of nodes are abnormal (failed or malicious).

[0088] In this application, voting on M pre-operation results means packaging these M pre-operation results into a list and voting on the authenticity of this list, that is, voting on whether all M pre-operation results are true.

[0089] The above embodiments will be used for illustration, wherein the contract collaboration group of distributed finance also includes witness node A1 and witness node A2: After receiving M pre-operation results, coordinating node A packages these M results and sends them to witness nodes A1, A2, contract nodes A1, A2, and A3 respectively via consensus trigger instructions. Each node then communicates with the others to synchronously begin voting and sends its voting results back to coordinating node A.

[0090] Coordinating node A will summarize the received voting results. Since a total of 5 nodes participated in the voting, the total number of votes is 5, meaning the voting threshold is set to 4. Based on this, if 4 or more of the voting results collected by coordinating node A are approved, it is considered that each contract node and each witness node have reached a consensus. This consensus means that there is agreement among all the nodes participating in this vote (as mentioned above, each contract node and each witness node participated in the voting).

[0091] At this point, coordinating node A sends corresponding confirmation execution instructions to contract nodes A1, A2, and A3 respectively, triggering contract nodes A1, A2, and A3 to enter the execution phase and formally execute the operations in the corresponding smart contracts.

[0092] Accordingly, if less than four of the votes collected by coordinating node A pass, it is considered that the consensus between each contract node and each witness node is inconsistent. In this case, coordinating node A sends a corresponding fourth rollback instruction to contract nodes A1, A2, and A3 respectively. This fourth rollback instruction is similar to the first rollback instruction and is used to trigger the rollback of the pre-operation to be executed by each contract node, so that each contract node is restored to its state before the pre-operation.

[0093] This application establishes a consensus voting mechanism, where multiple independent nodes collectively decide on the authenticity of M pre-operation results. This ensures that consensus conclusions can still be generated normally even when some nodes malfunction, avoiding atomicity corruption caused by node failures or malicious behavior, and improving the fault tolerance of this transaction. Furthermore, by adding witness nodes that are not directly related to the specific business logic of the transaction, the impact of contract node anomalies on consensus voting can be further reduced, increasing the credibility of the consensus results.

[0094] Furthermore, before voting on the authenticity of the M results and the pre-operation results, each node participating in the consensus vote can first conduct a consensus vote on whether to proceed with the vote. Only when a threshold of votes is reached will the nodes formally vote on the authenticity of the M results and the pre-operation results. This ensures that all participating nodes reach a consensus on initiating the formal vote in advance, avoiding invalid votes due to inconsistent node states or malicious behavior, and improving the reliability and efficiency of the consensus process.

[0095] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, the cross-contract transaction request further includes authorization information, and after receiving the cross-contract transaction request sent by the client node, it further includes: From cross-contract transaction requests, obtain the account's private key hash, account's public key, and permission validity period; Combine the account public key, permission validity period, and contract address list into the verification input information; The account private key hash value, account public key, permission validity period and contract address list are encrypted and calculated to generate a proof subject; Hash the account public key, permission validity period, and contract address list to obtain the credential hash value; The proof subject and the certificate hash value are combined to form the verification certificate information; Send the verification credentials and verification input information to each contract node respectively; Sending the corresponding pre-operation instructions to each contract node in the contract collaboration group also includes: If each contract node determines that the verification rules are met based on the verification certificate information and the verification input information, it sends the corresponding pre-operation instruction to each contract node in the contract collaboration group.

[0096] In one or more embodiments, the private key hash value is the hash value obtained by the client node after receiving the user's private key and hashing it. The permission validity period is the validity period of the various permissions required by the smart contract selected by the user. The user public key is the public identity information obtained by transforming the user's private key through a one-way mathematical transformation. In other words, signing a transaction with the private key is equivalent to the user stamping the transaction. Converting the private key into a public key hides the private key, and the public key is used to verify whether the corresponding signature was generated by the private key holder.

[0097] Verification rules refer to the judgment logic that determines whether a corresponding operation is legal (e.g., whether it has been tampered with) and valid (e.g., whether the sending entity is genuine) based on verification credentials and encrypted hash values. In this application, it specifically refers to verifying whether a pre-operation instruction is legal and valid based on verification credential information and verification input information.

[0098] Understandably, the process of verifying based on hash values ​​involves inputting multiple publicly available input parameters and the hash values ​​generated by these input parameters into the receiver. The receiver then calculates the hash value of the calculated hash value and compares it with the received hash value to determine whether the received publicly available parameters have been tampered with.

[0099] Specifically, the above embodiments will be used for further explanation: After receiving a cross-contract transaction request, coordinating node A obtains the account private key hash value = sk, the account public key = pub, the permission validity period (e.g., 24 hours), and the list of contract addresses (including digital warehouse receipt contract addresses, credit approval contract addresses, payment settlement contract addresses, automatic release contract addresses, etc.) from the cross-contract transaction request.

[0100] Subsequently, coordinating node A processes the private key hash value sk using an encryption algorithm (such as the Groth16 algorithm, which is an elliptic curve cryptography algorithm) to generate the corresponding public parameter pp=(α,β,γ,δ), where α, β, γ, and δ are all points on the elliptic curve; it then performs encrypted calculations on the account private key hash value sk, the account public key pub, the permission validity period, and the contract address list to generate the proof subject π=(A,B,C), where A, B, and C are all points on the elliptic curve; and finally, it hashes the account public key, the permission validity period, and the contract address list to obtain the credential hash value pub1.

[0101] Coordinating node A combines the proof subject π with the credential hash value pub1 as the verification credential information, and combines the account public key, permission validity period, and contract address list as the verification input information. After establishing the contract collaboration group, the verification credential information and verification input information are jointly distributed to each contract node for permission verification.

[0102] Taking contract node A as an example, after receiving the verification credential information and verification input information, contract node A first verifies the public inputs, such as the account public key, permission validity period, and contract address list. Using the account public key, permission validity period, and contract address list, it calculates the verification hash value pub2. If pub1 = pub2, the public input is deemed valid. Next, contract node A verifies the proof subject π using the public parameters pp = (α, β, γ, δ) and the public input pub1, based on the Groth16 verification equation, to verify and calculate e(α, β). e(pub1 γ,δ) If e(C,δ) and e(A,B) are equal, then the verification of the proof subject π is successful, proving that the user possesses the private key corresponding to the public key, and that this private key has the right to operate on the specified list of contracts; otherwise, e(A,B)≠e(α,β). e(pub1 γ,δ) When e(C,δ), the verification fails, proving that the user does not possess the private key corresponding to the public key. Here, e is a bilinear pairing operation on an elliptic curve.

[0103] This application generates a verification credential containing the transaction scope and authorization validity period for a single user authorization operation, and distributes it to the contract nodes corresponding to multiple smart contracts. This avoids the need for users to authorize each contract individually, simplifying the authorization process. Furthermore, this application encrypts the user's private key hash value and uses it along with the account's public key, authorization validity period, and a list of contract addresses as the proof. This ensures that the credential does not contain any sensitive user information. Even if the credential is intercepted, attackers cannot deduce the user's private key or expand the scope of authorization. Thus, without disclosing sensitive information such as the user's private key and the complete authorization scope, the application proves to the contract nodes that the user possesses legitimate permissions, ensuring authorization security and preventing the risk of permission leakage when permissions are repeatedly applied subsequently.

[0104] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, the verification certificate information and verification input information are sent to each contract node respectively, so that each contract node verifies the legality of cross-contract transactions based on the verification certificate information and verification input information, including: The verification credential information and verification input information are combined and converted to generate a temporary token. Obtain the group identifier of the contract collaboration group; Bind the temporary token to the group identifier to obtain the bound temporary token; The bound temporary tokens are input into each contract node so that each contract node can verify the legality of cross-contract transactions based on the temporary tokens.

[0105] In one or more embodiments, the temporary token is a lightweight data structure that compresses the size of the verification data from KB to byte by storing only a hash digest (zkp_digest) of the verification credentials and the necessary transaction context; the temporary public key is generated by the coordinating node based on the user's public key and is only valid for the transaction corresponding to the cross-contract transaction request.

[0106] The above embodiments will be used for illustration: After receiving a cross-contract transaction request, coordinating node A generates a corresponding temporary public key `pubkey1` based on the user's public key. After establishing a contract collaboration group, it encodes the group and obtains its group identifier `CCG_ID1`. Next, coordinating node A performs data conversion on the generated verification credential information, converting each coordinate point within it into binary data, and hashes the converted verification credential information to obtain the verification credential digest `zkp_digest1`. Then, the verification credential digest `zkp_digest1`, the temporary public key `pubkey1`, the group identifier `CCG_ID1`, the contract address list `contract_list1`, and the permission expiration time `expire_time1` are combined to form... Figure 4 The temporary token shown.

[0107] This application improves data transmission speed by converting credential information into temporary tokens and compressing the size of verification data. At the same time, by setting a group identifier and a temporary public key, it ensures a unique binding relationship between the temporary token and the cross-contract transaction, and that the token is only valid within the cross-contract transaction, thus preventing the temporary token from being used after the transaction ends.

[0108] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, after receiving the cross-contract transaction request sent by the client node, it further includes: Obtain the whitelist information corresponding to the account's public key; Based on the whitelist information, the legality of each contract address in the contract address list is verified; When all contract addresses are included in the whitelist information, the legality of each smart contract corresponding to the contract address list is determined. Sending the corresponding pre-operation instructions to each contract node in the contract collaboration group also includes: Once it is determined that the cross-contract transaction is legitimate and that all contract addresses are included in the whitelist information, the corresponding pre-operation instructions are sent to each contract node in the contract collaboration group.

[0109] In one or more embodiments, the whitelist information is a list of addresses of various smart contracts authorized by the user (determined by the account's public key) stored in a database of the blockchain network (such as a distributed key-value database, where the account's public key is the primary key and the whitelist information is the value). Users can preset the whitelist through an API (Application Programming Interface) or specify it temporarily when initiating cross-contract transactions.

[0110] Specifically, the above embodiments will be used for further explanation: After obtaining the list of contract addresses, coordinating node A retrieves the whitelist information corresponding to the account public keys from the blockchain database. It then matches the addresses of each smart contract in the contract address list with the addresses of each smart contract in the whitelist to determine if all addresses in the contract address list are included in the whitelist. If all addresses in the contract address list are included in the whitelist, it is determined that the smart contracts corresponding to these addresses are authorized by the user, i.e., the smart contracts in the contract address list are deemed legitimate. At this point, after verifying the contract address list and confirming that the cross-contract transactions are legitimate among the contract nodes in the contract collaboration group, coordinating node A sends corresponding pre-operation instructions to each contract node.

[0111] Accordingly, if there is a smart contract whose address is not included in the whitelist information, it is determined that the smart contract corresponding to that address has not been authorized by the user, that is, the smart contracts corresponding to the contract address list are determined to be illegal.

[0112] Furthermore, the verification results of the contract address list need to be returned to the client node. When all smart contract addresses in the contract address list are within the whitelist, "verification passed" is returned; if there are unauthorized contract addresses in the contract address list, "verification rejected" is returned and the unauthorized contract addresses are marked, so that users can make adjustments.

[0113] This application manages a user-preset contract whitelist. During the verification phase, it compares each smart contract called by all nodes in a cross-contract transaction against the whitelist. The transaction is only processed if all called contracts are on the whitelist; if any contract is not on the whitelist, the transaction is immediately rejected. This achieves precise control over the scope of permissions and further enhances permission security.

[0114] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, the method further includes: If any contract node is in an abnormal operating state, obtain the abnormal state information corresponding to the contract node in the abnormal operating state; The abnormality level corresponding to the abnormality status information is determined based on the mapping table between abnormal status information and abnormality level. Based on the anomaly level corresponding to the anomaly status information, the corresponding anomaly handling instruction is sent to the corresponding contract node, so that the corresponding contract node executes the anomaly handling operation corresponding to the anomaly level of the anomaly status information based on the anomaly handling instruction.

[0115] In one or more embodiments, the abnormal status information includes event characteristics and error codes. The coordinating node can classify the acquired abnormal status information according to the event characteristics and error codes. The abnormal status mapping table is a list that represents the mapping relationship between error types and abnormal levels. It is set by the developers according to actual needs. The abnormal handling instruction is an instruction that triggers the contract node to perform the abnormal handling operation corresponding to the abnormal level of the abnormal status information.

[0116] It is understandable that during contract processing, contract nodes often experience code-level runtime anomalies for various reasons. For example, contract node execution errors such as insufficient user balance or stack overflow during contract transfer execution, malicious behaviors of contract nodes such as unauthorized calls and data tampering (such as attempting to modify unauthorized data of other contracts or forging execution results), and timeouts in various operation responses caused by network interruptions of participating nodes.

[0117] The aforementioned anomalies differ significantly in nature, scope of impact, recoverability, and response strategies. For example, insufficient user balance typically only requires terminating the transaction and notifying the user, without complex processing; however, malicious node behavior can compromise the security of the entire transaction, necessitating consensus penalties and a global rollback; network timeouts may be temporary failures that can be recovered through retry mechanisms. Applying a uniform approach to all anomalies would not only waste resources (e.g., rolling back all recoverable anomalies) but could also introduce security vulnerabilities (e.g., simply logging malicious behavior).

[0118] Therefore, this solution has a pre-set anomaly classification mapping table. When the coordinating node detects that any contract node is in an abnormal operating state, it matches the abnormal state information with the anomaly classification mapping table based on the event characteristics and error codes of the abnormal state information of the contract node to determine the anomaly level of the abnormal state information. Then, it sends a corresponding anomaly handling instruction to each contract node according to the anomaly level, so that each contract node executes the anomaly handling operation corresponding to the anomaly level based on the anomaly handling instruction.

[0119] Specifically, this application divides abnormal status information into three levels, including a first level, a second level, and a third level. Based on the abnormal status level corresponding to the abnormal status information, a corresponding abnormal handling instruction is sent to the corresponding contract node, so that each contract node executes the abnormal handling operation corresponding to the abnormal status level based on the abnormal handling instruction, including: If the abnormal status information corresponds to the first level of abnormality, a corresponding second rollback instruction is sent to each contract node so that each contract node can roll back to the state before receiving the cross-contract transaction request based on the second rollback instruction. If the abnormal status information corresponds to the second level of abnormality, a corresponding third rollback instruction is sent to each contract node in the abnormal running state so that each contract node in the abnormal running state rolls back the target operation based on the second rollback instruction. The target operation is the processing operation of each contract node corresponding to the abnormal status information, and the first level is higher than the second level. If the abnormal status information corresponds to an abnormal level including the third level, the abnormal status information will be stored as an abnormal log.

[0120] Continuing with the above embodiments, we assume that the first level is a core anomaly that cannot be locally repaired, such as inconsistent running states of multiple smart contracts or a complete overflow of Gas (transaction fees, a unit used to measure the computational work required to perform a specific operation on the blockchain). The second level is a local anomaly that can be repaired through snapshot rollback, such as an error in the execution of a single step of a smart contract. The third level is a minor anomaly that does not affect transaction execution, such as missing non-critical logs. In the process of handling cross-contract transactions in distributed finance, the coordinating node A captures the abnormal status information of each contract node in real time through anomaly probes. Each contract node reports automatically at a certain period (such as every 10ms), or the contract nodes report to each other through state synchronization and mutual detection.

[0121] When coordinating node A receives abnormal status information, it determines that at least one contract node is in an abnormal operating state. At this time, coordinating node A classifies the obtained abnormal status information according to the abnormal classification mapping table.

[0122] If the abnormal status information indicates that the running states of multiple smart contracts are inconsistent, the abnormal status information is determined to be of the first level. At this time, the coordinating node A sends a second rollback instruction to all contract nodes (contract node A1, contract node A2, contract node A3) and witness nodes (witness node A1, witness node A2) in the contract collaboration group, so that each contract node rolls back to the state before receiving the cross-contract transaction request, that is, all its operations are rolled back until before the execution of the pre-operation. The coordinating node A determines that the second rollback instruction was successfully executed by voting on the fact that all nodes have successfully rolled back. When all nodes reach a consensus (for example, more than 2 / 3 of the nodes return that the rollback was successful), the coordinating node A determines that the second rollback instruction was successfully executed.

[0123] If the abnormal status information indicates that the payment settlement contract failed to lock resources during the pre-operation, then the abnormal status information is determined to be of the second level. At this time, the coordinating node A sends a third rollback instruction to the contract node A1 related to the payment settlement contract. After the contract node A1 rolls back to the time point when the payment settlement contract did not lock resources according to the third rollback instruction, it sends a rollback confirmation message to the coordinating node A so that the coordinating node A can continue to control the contract node A1 to retry the operation.

[0124] If the abnormal status information indicates that the database query took a long time, then the abnormal status information is determined to be of the third level. At this time, the coordinating node A records the abnormality, stores it as an abnormal record log, and continues to coordinate the subsequent operations of each contract node.

[0125] It should be noted that the reason this application can coordinate each contract node to perform precise or full rollbacks is that when the coordinating node sends each instruction, it binds a unique instruction identifier to that instruction and saves a state snapshot based on the information of each contract node corresponding to that instruction (including its running status and trigger time). That is, the second rollback instruction contains the initial snapshot ID corresponding to the state before the transaction execution, and the third rollback instruction contains the target snapshot ID corresponding to the single contract node involved in the anomaly and the rollback scope (only the abnormal part of that contract). Thus, each node can roll back the various operations of the contract node based on the stored state snapshots, restoring its running state.

[0126] Furthermore, to ensure consistency across multiple nodes during rollback, this application sets a rollback time threshold (e.g., 500ms). Nodes that fail to complete the rollback within this threshold will automatically trigger a second rollback instruction. Similarly, if the second rollback fails, the coordinating node will mark the node as an abnormal node and obtain a backup node from the candidate node set of the blockchain network.

[0127] Furthermore, this application also sets up a continuous confirmation mechanism for reported information, that is, the same abnormal status information needs to be reported multiple times (such as 3 times) to be judged as valid, thereby filtering out occasional instantaneous errors such as response delays caused by single network jitter and reducing the false alarm rate.

[0128] This application improves the success rate of transactions by classifying different anomalies. Based on the anomaly level, it controls each contract node to store the anomaly status information corresponding to the third level, which does not affect the transaction, as an anomaly log and continues the current transaction. It accurately rolls back the second level of recoverable anomalies and retryes the operation, avoiding the waste of resources caused by rolling back all recoverable anomalies. It also rolls back all the first level of unrecoverable anomalies to before the pre-operation, eliminating the intermediate state of some nodes succeeding and others failing, and ensuring the consistency of state among all nodes.

[0129] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, the method further includes: Upon receiving rollback confirmation information from each contract node in an abnormal running state, retry parameters are generated based on the cross-contract transaction request. The rollback confirmation information is used to indicate that the contract node in an abnormal running state has successfully rolled back the target operation. Sign the retry parameters based on the private key corresponding to the retry function; Based on the retry parameters after signing, a retry interface address is provided to the client node, so that the client node can execute a transaction retry request based on the retry interface address.

[0130] In one or more embodiments, after receiving the rollback confirmation information sent by the corresponding contract nodes, the coordinating node determines that the abnormal status information can be retried. At this time, the coordinating node obtains the original transaction parameters of the cross-contract transaction (including the list of contract addresses and the execution logic of each smart contract), the group identifier of the contract collaboration group, the retry validity period (e.g., 1 hour), and the number of retries (initially 0), generates retry parameters, and signs the retry parameters based on the private key corresponding to the retry function to prevent parameter tampering.

[0131] The coordinating node then binds the retry parameters to the retry interface, providing the user with the retry interface address. This allows the user to re-initiate the rolled-back operation using the interface retry parameters without needing to resubmit authorization. The retry interface can display corresponding text information to the user based on the retry parameters, such as "Transaction rolled back due to insufficient balance; can be retried within 1 hour."

[0132] In addition, developers can set a threshold to limit the number of retries for abnormal operations. When the number of retries exceeds the threshold (e.g., 3 times), the retry interface will automatically reject the retry call.

[0133] This application constructs a reusable and verifiable retry credential by signing retry parameters, including original transaction parameters, contract collaboration group identifier, and retry validity period, with a private key. Based on this credential, a retry interface address is provided to the user, allowing the user to directly reuse the original transaction authorization information for execution failures caused by temporary faults (such as network jitter or node timeout) in cross-contract transactions without having to repeat signing and authorization, thereby improving the overall success rate and user experience of cross-contract transactions.

[0134] Optionally, in the above Figure 3 Based on the corresponding embodiments, in the first optional embodiment of the contract processing method provided in this application, after obtaining the abnormal state information corresponding to the contract node in the abnormal running state when any contract node is in an abnormal running state, the method further includes: Based on the mapping table between abnormal status information and error type, determine the target error type corresponding to the abnormal status information; Based on the type scheme mapping table, obtain the processing scheme corresponding to the target error type; Based on the processing plan, the corresponding prompt message is sent to the client node.

[0135] In one or more embodiments, an error type mapping table is used to represent the mapping relationship between parameters such as error codes and event characteristics in abnormal state information and preset error types. The preset error types are set by developers according to actual business needs. A type scheme mapping table is used to represent the mapping relationship between error types and preset processing schemes. It is understood that before the actual use of the blockchain network or during maintenance, developers can associate corresponding processing schemes for different error types, where the processing scheme for each error type is based on a summary of historical abnormal cases.

[0136] Upon receiving an anomaly status information, the coordinating node retrieves the error code and event characteristics from the information. Based on the error code, event characteristics, and error type mapping table, it determines the target error type corresponding to the anomaly status information. Then, the coordinating node reads the type scheme mapping table from the blockchain network's database, queries the corresponding handling scheme from the table based on the target error type, and sends the corresponding prompt information to the client nodes based on the handling scheme.

[0137] The following detailed description will continue using the above embodiments: Assuming that in the error type mapping table, the error type corresponding to error code 0x1001 and event feature ERR_BALANCE_INSUFFICIENT is insufficient balance, then when coordinating node A receives abnormal status information A with error code 0x1001 and time feature ERR_BALANCE_INSUFFICIENT, coordinating node A determines the target error type of abnormal status information A as insufficient balance according to the error type mapping table.

[0138] Next, coordinating node A reads the type scheme mapping table from the blockchain network's database and queries the table for the handling scheme corresponding to insufficient balance. When the handling scheme corresponding to insufficient balance is to prompt the user to recharge, coordinating node A sends voice or text messages such as "Insufficient balance" or "Please recharge and try again" to the client node.

[0139] This application, by pre-setting multiple error types and corresponding handling schemes for each error type, enables the coordinating node to quickly determine the error type and execute the corresponding handling action when an anomaly occurs, achieving rapid response to various abnormal situations in cross-contract transactions. Thus, this application further enhances system stability and efficiency while ensuring the atomicity of each node.

[0140] For easier understanding, please refer to Figure 5 , Figure 5 The diagram illustrates the timing of the contract processing method in the event of a transaction failure. This timing diagram explains the interaction process between the coordinating node and the contract node in this application from the code level of the blockchain network. The blockchain network is divided at the code level into a cross-contract atomicity coordination module 610, a cross-contract permission proxy module 620, a dynamic Gas pre-allocation and adjustment module 630, contract nodes 640, a cross-contract exception collaborative processing module 650, and a contract collaboration log storage and traceability module 660.

[0141] like Figure 5 When a user initiates a cross-contract transaction request: Step 1: User 600 submits a cross-contract transaction request to the cross-contract atomicity coordination module 610. The cross-contract transaction request includes a list of contract addresses, the execution logic of each smart contract, and authorization information. Step 2: The cross-contract atomicity coordination module 610 transmits the CCG (Contract Collaboration Group) identifier and transaction scope (determined by the contract address list) to the cross-contract authorization proxy module 620 to trigger authorization verification; Step 3: The cross-contract permission proxy module 620 returns the verification result (verification passed or verification rejected) and a temporary token to the cross-contract atomicity coordination module 610; Step 4: The cross-contract atomicity coordination module 610 transmits the number of contracts (i.e., the number of smart contracts contained in the contract address list), operation complexity, and network status to the dynamic Gas pre-allocation and adjustment module 630 to trigger Gas pre-allocation. Step 5: The dynamic Gas pre-allocation and adjustment module 630 returns the initial Gas quota and redundant Gas pool configuration to the cross-contract atomicity coordination module 610. Step 6: The cross-contract atomicity coordination module 610 transmits the temporary token, gas quota and execution instructions to the contract node 640, triggering the pre-execution operation (i.e. the pre-operation in this application) and the commit operation of the contract node 640. Step 7: Contract node 640 returns the following to the cross-contract atomicity coordination module 610: execution status (i.e., whether to enter the execution phase based on M pre-operation results) and real-time Gas consumption data; Step 8: Contract node 640 pushes the abnormal event (i.e. the aforementioned abnormal status information) to the cross-contract abnormal collaborative processing module 650. The abnormal event includes the error type, abnormal level and triggering time. Step 9: The dynamic gas pre-allocation and adjustment module 630 deploys gas probes to the contract nodes 640 to collect consumption data in order to detect the gas consumption of each contract node 640 in real time. Step 10: Contract node 640 reports the gas consumption progress to dynamic gas pre-allocation and adjustment module 630. The reporting period can be once every 10ms. Step 11: The dynamic gas pre-allocation and adjustment module 630 transmits gas adjustment instructions to the cross-contract atomicity coordination module 610 to realize the dynamic allocation of gas allocated to each contract node 640. The gas adjustment instructions may include the replenishment of gas or the reclamation of unused gas. Step 12: The cross-contract atomicity coordination module 610 synchronizes the Gas adjustment results to the contract node 640; Step 13: The cross-contract atomicity coordination module 610 transmits the exception level, CCG identifier (i.e., the group identifier of the aforementioned contract collaboration group), and target snapshot ID to the cross-contract exception collaboration processing module 650 to trigger the cross-contract exception collaboration processing module 650 to process the exception. Step 14: The cross-contract exception coordination module 650 returns a rollback instruction, retry suggestion, or exception log to the cross-contract atomicity coordination module 610. Step 15: The cross-contract exception collaborative processing module 650 transmits snapshot chain data to the contract node 640 to generate corresponding rollback instructions based on the snapshot data. Step 16: Contract node 640 returns the snapshot generation result or rollback confirmation (i.e., the aforementioned rollback confirmation information) to the cross-contract exception collaborative processing module 650. Step 17: The cross-contract atomicity coordination module 610 pushes full-link data, including CCG information, execution results, Gas details, and exception logs, to the contract collaboration log storage and traceability module 660. Step 18: The cross-contract authorization proxy module 620 pushes the authorization log to the contract collaboration log storage and traceability module 660. The authorization log includes credential and token information (including verification credential information, verification input information and temporary token). Step 19: The dynamic gas pre-allocation and adjustment module 630 pushes the gas allocation and adjustment log to the contract collaboration log storage and traceability module 660. Step 20: The cross-contract exception collaborative processing module 650 pushes the exception processing log and processing results to the contract collaboration log storage and traceability module 660; Step 21: Contract node 640 pushes contract execution logs and status snapshot identifiers to contract collaboration log storage and traceability module 660; Step 22: The contract collaboration log storage and traceability module 660 feeds back the storage result (Merkel root hash) and resource release status to the cross-contract atomicity coordination module 610; Step 23: The cross-contract atomicity coordination module 610 provides feedback to user 600 on the final transaction status (failure) and a summary of gas consumption.

[0142] This application ensures the atomicity of cross-contract transactions by setting up a Contract Collaboration Group (CCG) and a two-phase commit mechanism, avoiding the risk of partial success and partial failure of operations; improves gas utilization and reduces user costs through a dynamic gas pre-allocation and adjustment mechanism; simplifies the authorization process and enhances permission security through a permission proxy module; achieves precise rollback and rapid retries through an exception collaborative handling mechanism, ensuring state consistency; improves auditing convenience through a collaboration log storage and traceability mechanism; and adapts to various collaboration scenarios such as same-chain, cross-chain, same-channel, and cross-channel through modular design, ultimately achieving atomic, efficient, and secure management of cross-contract calls, supporting the implementation of complex blockchain businesses.

[0143] Specifically, in combination Figures 6 to 10 The following is a description of each of the above modules: Please see Figure 6 , Figure 6 This is a flowchart of the workflow for the cross-contract atomicity coordination module.

[0144] 1. Core Positioning: The cross-contract atomicity coordination module serves as the "coordination hub" for cross-contract transactions, ensuring the atomicity of multi-contract collaboration and resolving some execution issues.

[0145] 2. Key Components: (1) Input processing unit In one or more embodiments, the input processing unit is used to convert external input data into standardized data through data standardization logic, and to perform format verification and preliminary filtering through data verification rules to prevent illegal requests from entering subsequent processes.

[0146] The data verification rules specifically include verifying the "contract address format (e.g., Hex format)," "execution logic syntax (i.e., syntax compliance)," and "authorization information completeness (including user signature and permission expiration fields)" in the transaction request. When verification fails, an error code is returned directly, such as ERR_TX_FORMAT (transaction format verification failed) or ERR_AUTH_INCOMPLETE (authorization information missing).

[0147] Data standardization specifically includes converting transaction parameters from different blockchain platforms (such as Hyperledger Fabric distributed ledger) into a unified standard format within the module. For example, contract addresses are standardized to lowercase, and execution logic is converted into JSON structure (JavaScript Object Notation, a lightweight, text-based data exchange format) to adapt to multi-chain compatibility.

[0148] (2) CCG generation unit

[0149] In one or more embodiments, the CCG generation unit is used to dynamically create a contract collaboration group (CCG) for each cross-contract transaction based on the CCG composition rules, and generate a corresponding CCG identifier, thereby clarifying the roles of nodes within the group and communication rules, and ensuring the uniqueness and controllability of the collaboration unit.

[0150] The specific rules for CCG composition include: One node with a historical consensus success rate of ≥99.9%, no abnormal behavior in the past 30 days, and whose legitimacy is verified by a node identity certificate (such as an X.509 certificate) is randomly selected from the blockchain verification node pool as the coordinating node; the blockchain node state database (i.e., the aforementioned candidate node set) is queried to filter nodes in the "frozen" or "abnormal" state, and the corresponding contract node is selected from the node state database; three third-party nodes that are not associated with the contract node are selected as witness nodes. The witness nodes are used to supervise the consensus process and prevent the coordinating node from cheating at a single point.

[0151] CCG identifier generation specifically includes: A unique CCG identifier is generated by combining the first 16 bits of the hash value of the cross-contract transaction, the timestamp (millisecond level), and a random number (usually 8 bits, but not limited here). The identifier is then immediately written to the CCG information cache.

[0152] In addition, this solution also supports CCG lifecycle management, automatically destroying group information 30 minutes after the transaction is completed to release cache resources.

[0153] (3) Two-phase delivery execution unit

[0154] In one or more embodiments, the two-phase commit execution unit is used as the core unit to ensure cross-contract atomicity. It is used to coordinate the execution of the "preparation-execution" two-phase commit logic by each contract node, and to generate the final operation instruction (first rollback instruction or confirmation execution instruction) based on the results of each pre-operation and the consensus conclusion.

[0155] Phase 1 (Preparation Phase): A pre-operation instruction containing a "CCG identifier, pre-operation logic fragment, and resource locking rules (such as prohibiting other transactions from modifying the assets to be operated on in the current contract)" is generated and pushed to all contract nodes through the state synchronization unit. A timeout threshold is set (default 500ms, which can be dynamically adjusted according to network latency). Nodes that do not return a result within the timeout period are automatically judged as "uncommittable" to avoid process blockage.

[0156] Phase Two (Execution Phase): After receiving all the pre-operation results, the results are statistically analyzed. Only when 100% of the contract nodes return "can be committed" will the second stage be entered, generating a confirmation execution instruction containing "resource unlocking rules (allowing formal modification of assets) and requirements for uploading execution results to the blockchain (must be written to the contract state database)" to ensure that all contract nodes execute the formal operation synchronously.

[0157] Otherwise, a first rollback instruction is generated, which includes "resource unlocking rules (restoring the state before the pre-operation) and rollback log recording requirements (the reason for rollback must be noted, such as the failure of a node's pre-operation)", triggering the rollback process. This first rollback instruction supports precise rollback to the state before the pre-operation.

[0158] This two-phase commit execution unit ensures that all nodes perform a full commit or a full rollback by setting a unique instruction identifier (UUID) and an execution confirmation feedback mechanism, leaving no intermediate state residue.

[0159] (4) Consensus Unit

[0160] In one or more embodiments, the consensus unit is used to solve the consistency problem of nodes within the CCG (especially contract nodes and witness nodes), avoid atomicity destruction caused by node failure or malicious behavior, and improve consensus credibility.

[0161] Specifically, consensus voting consists of three parts: During the pre-preparation phase, the coordinating node sends a "consensus request (including a summary of pre-operation results and CCG identifier)" to all nodes within the CCG, along with a digital signature (to ensure that the request has not been tampered with).

[0162] During the preparation phase, after the contract node verifies the legitimacy of the request, it sends a "prepare to vote" message. At the same time, the witness node verifies the legitimacy of the request synchronously. When it receives "prepare to vote" messages from ≥2 / 3 of the nodes (the total number of contract nodes and witness nodes), it proceeds to the next phase.

[0163] During the submission phase, nodes send a "submit vote" (i.e., the aforementioned pass result), which also requires ≥2 / 3 of the nodes to vote in favor, ultimately generating a consensus conclusion; if the threshold is not reached, an inconsistent consensus conclusion is generated, triggering a rollback.

[0164] The consensus unit improves consensus efficiency in high-concurrency scenarios by using a batch consensus mechanism that allows multiple cross-contract transactions to share some consensus steps within the same time period. At the same time, it can still generate consensus conclusions normally when some nodes are abnormal (faulty or malicious), which meets the distributed fault tolerance requirements of blockchain.

[0165] (5) State synchronization unit

[0166] In one or more embodiments, the state synchronization unit serves as a data transmission hub between the module and other modules and contract nodes, responsible for instruction pushing, result reception, and state synchronization, ensuring the real-time performance and reliability of data transmission.

[0167] The state synchronization unit adopts the "WebSocket+TLS1.3" communication protocol, supports bidirectional real-time communication, avoids short connection delay issues, and encrypts data with the AES-256 encryption algorithm before data transmission to prevent data leakage or tampering.

[0168] For any unconfirmed instructions, an exponential backoff retransmission strategy is employed. For example, the initial retransmission interval is 100ms, and subsequent retransmissions double the interval (up to a maximum of 3 retransmissions) to ensure instruction reachability. Furthermore, the execution status of contract nodes is synchronized in real time to ensure that the module can promptly obtain external execution progress, avoiding decision-making errors caused by information lag.

[0169] (6) Result Processing Unit

[0170] In one or more embodiments, the result processing unit is used to integrate and store the entire transaction process results, such as execution status, consensus conclusion, and rollback reasons, and to send standardized results to the outside world to support subsequent log storage and user feedback.

[0171] Specifically, the result processing unit writes the results to the transaction status database (using a MySQL master-slave architecture, supporting read-write separation) and generates a "result summary" (including the result hash) for integrity verification by the subsequent log storage module. Furthermore, for transactions in a failed state, it automatically associates the CCG information cache with the consensus log database, supplementing details such as the "abnormal node list" and "percentage of consensus failure nodes" to provide a basis for subsequent troubleshooting.

[0172] (7) Data storage layer

[0173] In one or more embodiments, the data storage layer is used to provide persistent storage and fast query of data within the module, support the functional implementation of each unit, and ensure data traceability and high availability.

[0174] Specifically, the data storage layer includes a CCG information cache, a transaction status database, and a consensus log database. The CCG information cache uses a Redis Cluster (a distributed database) cluster with a master-slave architecture to store CCG identifiers, node lists, and lifecycle states, and supports automatic failover to meet high-frequency query requirements. The transaction status database uses a MySQL 8.0 database with master-slave synchronization capabilities and a table partitioning strategy (partitioning by the first two digits of the transaction hash, resulting in 256 tables) to meet data storage needs in high-concurrency scenarios. The consensus log database uses Elasticsearch (a search server) to store all logs during the consensus process, including request time, voting nodes, and voting results. It supports fast retrieval by CCG identifier, time range, and node address, facilitating auditing and problem tracing.

[0175] In summary, the cross-contract atomicity coordination module ensures the atomicity of the state of each node in a cross-contract transaction by setting up two-phase commit and consensus voting, thereby guaranteeing the success or rollback of all operations. Core units (such as CCG generation and consensus) support master-slave deployment, and the data storage layer adopts a cluster architecture, so a single point of failure does not affect the overall operation of the module, improving the availability of the solution. All operations in the transaction, including CCG creation, consensus voting, and instruction push, are recorded in detail and associated with unique identifiers (CCG identifier and instruction UUID), supporting full-process reverse traceability, which facilitates problem investigation and compliance auditing.

[0176] Please refer to Figure 7 , Figure 7 This is a flowchart of the workflow for the cross-contract permission proxy module.

[0177] 1. Core Positioning: The cross-contract permission proxy module simplifies the cross-contract authorization process, improves the security of permission management, and solves the problems of cumbersome multi-contract authorization and leakage risks.

[0178] 2. Key Components: (1) Authorization request receiving unit In one or more embodiments, the authorization request receiving unit is used to standardize the reception of user authorization requests and the associated information transmitted by the cross-contract atomicity coordination module, complete data format verification and preliminary filtering, ensure that the input information is legal and complete, and provide a basis for subsequent permission processing.

[0179] Specifically, upon receiving a user authorization request, the authorization request receiving unit parses the user authorization request, extracts the user's private key signature (which must conform to the blockchain platform's signature specifications, such as ECDSA signature), the scope of transaction permissions (including the list of participating contract addresses and the types of operations that can be performed, such as transfer, query, or modify status), the validity period of the permissions (default 24 hours, which can be customized by the user), and receives the CCG identifier transmitted by the cross-contract atomicity coordination module to ensure that the permissions are bound to specific cross-contract transactions and to avoid permission reuse.

[0180] Next, the validity of the signature (e.g., verified by blockchain public key), the contract address format (e.g., Hex encoding, Hyperledger Fabric channel contract ID format), and the validity of the authorization validity period are verified. If the verification fails, an error code is returned, such as ERR_SIGN_INVALID (invalid signature) or ERR_CONTRACT_ADDR_FORMAT (incorrect contract address format).

[0181] (2) Zero-knowledge proof generation unit

[0182] In one or more embodiments, the zero-knowledge proof generation unit is used to generate zero-knowledge proof credentials based on user authorization information. Without disclosing sensitive information such as the user's private key and the full scope of authorization, it proves to the contract node that the user has legitimate permissions and is the core unit for ensuring authorization security.

[0183] Among them, the zero-knowledge proof algorithm adopts the Groth16 algorithm, which has the characteristics of high proof generation efficiency and fast verification speed, and is suitable for the real-time permission verification requirements in blockchain scenarios.

[0184] Specifically, in the proof generation process, parameters are first initialized by loading pre-generated public parameters (PP, PublicParameters). These public parameters are generated based on security curves (such as BN254) and are updated quarterly to avoid security risks caused by parameter aging.

[0185] Subsequently, the zero-knowledge proof generation unit uses the hashed user private key (i.e., the private key hash value) as the privacy input, and the CCG identifier, contract address list, permission validity period, and user public key as the public input, and calculates the zero-knowledge proof credential (containing the proof subject π and the public input hash) using the Groth16 algorithm.

[0186] Understandably, the credentials do not contain any sensitive user information. Therefore, even if the credentials are intercepted, attackers cannot deduce the user's private key or expand the scope of permissions, greatly reducing the risk of permission leakage.

[0187] (3) Whitelist Management Unit

[0188] In one or more embodiments, the whitelist management unit is used to manage the user-preset contract whitelist, verify whether the contract node is within the whitelist range, achieve precise control over the scope of permissions, refuse unauthorized contracts from participating in cross-contract transactions, and further improve permission security.

[0189] Specifically, a distributed key-value database is used to store the user whitelist, where the user's public key and CCG identifier serve as the primary key, and the list of contract addresses (supporting batch addition / deletion) serves as the value. Whitelist updates take effect in real time, and users can preset the whitelist through the API interface, or temporarily specify it when initiating cross-contract transactions, meeting flexible management needs.

[0190] When performing verification based on a whitelist, the whitelist management unit receives the list of contract addresses transmitted by the permission token conversion unit and compares it with the user's whitelist. It returns "verification passed" only when all smart contracts are in the whitelist; if there are unauthorized contracts, it returns "verification rejected" and marks the address of the unauthorized contract, so that users can make adjustments.

[0191] (4) Permission Token Conversion Unit

[0192] In one or more embodiments, the permission token conversion unit is used to convert zero-knowledge proof credentials into temporary permission tokens that can be directly verified by contract nodes, thereby completing the format adaptation of the proof and the token, and binding the CCG identifier and permission validity period to ensure the uniqueness and validity of the token.

[0193] Specifically, the permission token conversion unit dynamically generates a temporary public key based on the ECC elliptic curve algorithm, calculates the zkp_digest (hash digest) based on zero-knowledge proof credentials, and signs the token using a module-specific private key (which is periodically rotated based on a preset period) to obtain the temporary tokens shown in Table 1:

[0194] Table 1 Temporary Token Structure

[0195] In the above scheme, the temporary public key is not associated with the user's public key, which can avoid identity leakage and ensure that the credentials have not been tampered with; retaining the hash digest of the zero-knowledge proof credentials can ensure that the credentials have not been tampered with; through the module's exclusive private key, the contract node can verify the signature's legality through the module's public key.

[0196] (5) Permission verification feedback unit

[0197] In one or more embodiments, the permission verification feedback unit is used to integrate the whitelist verification result and the temporary permission token to generate a standardized permission verification result, complete the authorization log storage, and at the same time feed back the result to the core processing layer to support subsequent cross-contract transaction execution decisions.

[0198] When verifying permissions, the permission verification feedback unit generates a verification success result along with a temporary permission token if the whitelist verification passes and the token is successfully generated. If either step fails, a verification rejection result is generated, indicating the reason for the failure (e.g., "Whitelist verification failed" or "Token signature failed"). The result format is uniformly JSON for easy parsing by the cross-contract atomicity coordination module.

[0199] Upon successful verification, the authorization verification feedback unit writes information such as the user's public key, CCG identifier, verification result, token ID, and expiration time into the authorization log database, completing the authorization log storage. The log records are immutable (ensuring this through database transactions and audit logs), supporting subsequent traceability and auditing.

[0200] When verification fails, such as when a signature fails during token generation, the permission verification feedback unit automatically retryes. If the retry fails, an alarm is triggered and an exception log is recorded to ensure that the problem can be investigated.

[0201] (6) External output agent unit

[0202] In one or more embodiments, the external sending agent unit is used as a communication hub between the module and the outside (cross-contract atomic coordination module, contract node) to complete the secure push of permission verification results and temporary permission tokens, ensuring the reliability and compatibility of data transmission.

[0203] In terms of data transmission, the external sending proxy unit adopts the "WebSocket+TLS1.3" communication protocol, supporting bidirectional real-time communication and avoiding short connection latency issues. Furthermore, data is encrypted using the AES-256 encryption algorithm before transmission to prevent data leakage or tampering. Simultaneously, the external sending proxy unit also features a push confirmation mechanism; if the receiver does not return confirmation information within a timeout period, it automatically retryes twice (the retry interval can be 100ms, 200ms, etc.).

[0204] In terms of format conversion, the external sending agent unit converts the sending format according to the requirements of the external module. For example, it pushes the complete verification result (including the token) to the "cross-contract atomicity coordination module" and only pushes the core fields of the token (token_id, temp_pubkey, signature) to the "contract node" to adapt to the information requirements of different modules.

[0205] In the workflow of the cross-contract authorization proxy module, zero-knowledge proofs are used to achieve authorization without privacy leakage. At the same time, a single authorization generates a token usable by multiple contracts, reducing operation steps and solving the pain points of traditional multi-contract authorization being cumbersome and insecure. The CCG identifier is bound to the time limit of the temporary token, which automatically expires after the transaction is completed. Combined with whitelist verification, this reduces the risk of permission leakage and protects user asset security. The authorization log fully records the entire process of request, proof, token, and result, and associates the CCG identifier with the token ID, supporting reverse traceability and meeting compliance audit requirements.

[0206] Please refer to Figure 8 , Figure 8 This is a flowchart of the workflow for the cross-contract exception collaborative handling module.

[0207] 1. Core positioning: To achieve accurate identification, hierarchical processing and collaborative rollback of cross-contract transaction anomalies, and to ensure system consistency.

[0208] 2. Key Components: (1) Anomaly monitoring unit In one or more embodiments, the anomaly monitoring unit is used as the "anomaly perception entry point" of the module to collect abnormal events (contract execution errors, module coordination failures, etc.) in the entire cross-contract transaction process in real time, complete anomaly capture and preliminary filtering, and ensure that no abnormal events are missed or falsely reported.

[0209] The abnormal event acquisition in this application adopts a dual mode of active reporting and passive retrieval. Abnormal events are reported in real time through contract nodes, and missing monitoring data can be retrieved by CCG identifier to avoid omission of abnormal events.

[0210] Specifically, passive pull involves deploying lightweight anomaly probes to contract nodes to capture code-level errors in real time and reporting monitoring data periodically (e.g., every 10ms). Furthermore, the anomaly monitoring unit establishes a "heartbeat synchronization" with other core modules (e.g., synchronizing every 50ms). Failure to receive a heartbeat or abnormal synchronization data (e.g., incorrect signature of a collaborative instruction) is considered a module collaboration failure.

[0211] The monitoring scope includes contract nodes and various external modules. Specific event types include contract node execution errors (stack overflow, insufficient balance), malicious behavior of contract nodes (unauthorized calls / data tampering), cross-contract atomic coordination module collaboration timeout (pre-operation / commit response timeout), and dynamic gas module gas overflow (a contract performs complex calculations, and the gas consumption exceeds the initial and redundant pool total amount).

[0212] Furthermore, the anomaly monitoring unit is also used to filter out "occasional transient errors" (such as response delays caused by a single network jitter) through a multi-continuous monitoring and confirmation mechanism, thereby reducing the false alarm rate. For example, the same anomaly is only considered valid if it is reported three times consecutively.

[0213] (2) Abnormal classification unit

[0214] In one or more embodiments, the anomaly classification unit is used to determine the level and type of valid anomalies, clarify the severity and root cause of the anomalies, provide a basis for decision-making for subsequent differentiated processing, and avoid wasting efficiency.

[0215] Specifically, abnormal events are divided into three levels: warning (i.e., the aforementioned third level), recoverable (i.e., the aforementioned second level), and unrecoverable (i.e., the aforementioned first level). Among them, warning refers to minor anomalies that do not affect transaction execution (such as missing non-critical logs), recoverable refers to local anomalies that can be repaired by snapshot rollback (such as an error in the execution steps of a certain contract), and unrecoverable refers to core anomalies that cannot be partially repaired (such as inconsistent states of multiple contracts or complete gas overflow).

[0216] The anomaly classification unit automatically classifies anomalies based on error codes and event characteristics. It presets multiple core error types (such as ERR_BALANCE_INSUFFICIENT and ERR_GAS_OVERFLOW) and associates each type of error with typical handling schemes (such as prompting users to recharge when the balance is insufficient), and matches them with the historical anomaly database.

[0217] Subsequently, basic information such as the anomaly level, error type, trigger time, associated CCG identifier, and the smart contract address involved will be synchronized to the anomaly handling decision unit and the state snapshot chain management unit to ensure data consistency in subsequent processing stages.

[0218] (3) Status snapshot chain management unit

[0219] In one or more embodiments, the State Snapshot Chain Management Unit is used to manage state snapshots across the entire lifecycle of a contract transaction, construct a chain-like snapshot structure, provide a precise data source for rollback of recoverable anomalies, and ensure that the state after rollback is completely consistent with that before the anomaly.

[0220] Specifically, the state snapshot chain management unit automatically generates a snapshot after each sub-contract call (e.g., from the completion of contract A to the execution of contract B), or urgently generates a snapshot when the anomaly monitoring unit triggers an anomaly. The snapshot includes participating contract storage data (e.g., account balance, contract variable values), current execution progress (completed contracts, pending contracts), gas consumption details (gas consumed, remaining amount), and a snapshot ID (including CCG identifier, step number, and timestamp).

[0221] Subsequently, the snapshot chain management unit organizes the snapshots into a snapshot chain according to the execution order. Each snapshot is associated with the ID of the previous snapshot, forming a unidirectional chain structure, for example, snapshot 1 → snapshot 2 → snapshot 3. The snapshot chain supports tracing historical states in reverse by ID and is stored using LevelDB (with CCG identifier as the key and a list of snapshots as the value).

[0222] Upon receiving a rollback request from the anomaly handling decision unit (including the aforementioned first, second, and third rollback instructions), the state snapshot chain management unit quickly locates the target snapshot using the execution progress field of the snapshot chain and returns snapshot data with the target snapshot ID. For example, if the third rollback instruction instructs a rollback to the state before the execution of smart contract B, the state snapshot chain management unit returns the target snapshot ID corresponding to the state before the execution of smart contract B and the snapshot data corresponding to that state. Furthermore, the anomaly handling decision unit can also verify the integrity of the snapshot by comparing the snapshot data using SHA-256 hashes, thereby preventing tampering.

[0223] Snapshot cleanup: After a transaction is completed (successful / failed), the snapshot chain is retained for 24 hours (for subsequent problem tracing). After the timeout, it is automatically cleaned up (only the snapshot ID and hash digest are retained) to release storage resources. The cleanup strategy can be adjusted through configuration.

[0224] (4) Exception handling decision unit

[0225] In one or more embodiments, the exception handling decision unit serves as the decision-making center of the module. It formulates differentiated handling schemes based on the exception level and type, triggers operations such as precise rollback, full rollback, and log recording only, and decides whether to support exception retries to ensure that the handling scheme is optimal.

[0226] Specifically, for warning-type anomalies, the anomaly handling decision unit only records the anomaly log, does not interrupt transaction execution, and pushes the log to the anomaly result collection unit to continue tracking the transaction progress; for recoverable anomalies, the anomaly handling decision unit precisely rolls back to the most recent valid snapshot before the anomaly, re-executes this step, and sends a precise rollback instruction containing the target snapshot ID to the rollback execution unit; for unrecoverable anomalies, the anomaly handling decision unit triggers a full CCG collaborative rollback, terminates transaction execution, and sends a full rollback instruction containing all contract addresses to the rollback execution unit.

[0227] Understandably, the exception handling decision unit only supports retries for recoverable exceptions and successful rollbacks (such as contract execution failures caused by temporary network fluctuations). It generates retry parameters containing the original transaction parameters, CCG identifier, retry limit (e.g., 3 times), and retry validity period (e.g., 1 hour), and triggers the corresponding contract section to retry the abnormal operation based on these retry parameters. For unrecoverable exceptions such as gas overflow, the exception handling decision unit refuses to retry and returns the reason why retry is unavailable.

[0228] Furthermore, if the same CCG experiences multiple unrecoverable anomalies within a preset time period (e.g., ≥3 times within 10 minutes), the CCG circuit breaker will be automatically triggered, meaning that the CCG will be prohibited from initiating further transactions. Simultaneously, the anomaly handling decision unit sends an alarm to the cross-contract atomicity coordination module to avoid resource waste. The circuit breaker status can be lifted through manual intervention.

[0229] (5) Collaborative rollback execution unit

[0230] In one or more embodiments, performing precise rollback or full rollback operations, synchronously coordinating all participating nodes to complete the rollback, and ensuring the consistency of rollback results (no intermediate states where some operations are rolled back successfully or some operations fail) is a key unit for ensuring cross-contract state consistency.

[0231] Specifically, for recoverable anomalies, precise rollback is performed. The collaborative rollback execution unit obtains the corresponding snapshot data from the snapshot chain management unit using the received target snapshot ID, and sends a precise rollback instruction (i.e., the aforementioned third rollback instruction) containing the snapshot data and the rollback scope (only the abnormal part of the contract) to the individual contract node involved in the anomaly. This triggers the contract node to execute the rollback, restoring the data to the snapshot state. In addition, upon successful rollback, the contract node will also return rollback confirmation feedback information.

[0232] For unrecoverable anomalies, a full rollback is performed. The collaborative rollback execution unit sends a full rollback instruction containing the initial snapshot ID (state before transaction execution) and the rollback time window (e.g., 1 second) to all contract nodes and witness nodes within the CCG, and uses the Byzantine Fault Tolerance formula to ensure rollback consistency (≥2 / 3 of nodes must return a successful rollback). After all nodes have completed the rollback, the collaborative rollback execution unit releases the locked Gas and contract resources.

[0233] Understandably, the collaborative rollback execution unit monitors the node status in real time during the rollback process. Nodes that fail to complete the rollback within the specified time are automatically triggered with a second rollback instruction. If the second rollback fails, the node is marked as an abnormal node, and a backup node is switched over through the cross-contract atomicity coordination module.

[0234] After the rollback is completed, a rollback log is generated containing the rollback type, target snapshot ID, list of participating nodes, rollback result, and time taken, and is pushed to the abnormal result collection unit in real time.

[0235] (6) Abnormal Result Collection Unit and Abnormal Log Database

[0236] In one or more embodiments, the abnormal result collection unit and the abnormal log database are used to collect abnormal information, processing solutions, rollback results, retry status and other abnormal processing data throughout the entire process, thereby completing persistent storage, providing searchable data for subsequent tracing and auditing, and supporting module optimization (such as error type statistics).

[0237] Specifically, the anomaly log database adopts a MySQL master-slave architecture (master database writes, slave database queries), and stores the anomaly results data in Table 2 by CCG identifier and month partitioning; the log data is immutable (protected by database transactions and row-level locking), meeting compliance audit requirements.

[0238] The abnormal results collection unit synchronizes abnormal results to the contract collaboration log storage and traceability module in real time to ensure the integrity of cross-module log data.

[0239]

[0240] Table 2 Abnormal Result Data Structure

[0241] (7) Abnormal retry agent unit and external output adapter unit

[0242] In one or more embodiments, the exception retry proxy unit and the external output adaptation unit are used to generate exception retry parameters, complete the result feedback between the module and external entities such as the cross-contract atomicity coordination module, users, and contract nodes, ensure that external modules obtain exception handling status in a timely manner, and support users to retry quickly.

[0243] The exception retry agent unit is specifically used to generate retry parameters and trigger retries.

[0244] By integrating the original transaction parameters such as the contract list and execution logic, CCG identifier, retry validity period, and number of retries (initially 0), standardized retry parameters are generated. These parameters include a retry signature (signed with the module's private key to prevent parameter tampering). A retry interface is then provided to users, allowing them to reuse the retry parameters and initiate calls without needing to resubmit authorization and Gas pre-allocation. The interface automatically rejects calls after the retry limit is exceeded.

[0245] The external output adaptation unit is specifically used for format adaptation and push.

[0246] The sending format is converted according to the requirements of external modules. For example, the rollback result in JSON format is sent to the cross-contract atomic coordination module, and a concise text prompt is sent to the user (such as "The transaction is rolled back due to insufficient balance. It can be retried within 1 hour"). A dual mode of real-time push and alarm notification is adopted to push the rollback result and retry parameters to the cross-contract atomic coordination module in real time, and to alert the relevant parties to unrecoverable high-risk anomalies via SMS or email to ensure that the relevant parties are informed in a timely manner.

[0247] In summary, the cross-contract anomaly collaborative processing module differentiates its handling based on the severity of anomalies, accurately rolling back recoverable anomalies via snapshots to avoid wasted efficiency. Full rollback utilizes Byzantine consensus, supporting fault tolerance for some nodes and ensuring synchronized rollback across all participating nodes without intermediate inconsistencies, thus addressing the pain points of fragmented rollback in traditional cross-contract anomalies. Retry parameters reuse original transaction information, eliminating the need for users to repeat operations and improving transaction success rates. The combination of retry counts and permission control prevents malicious retries from consuming resources. Anomaly logs comprehensively record data across the entire chain of monitoring, classification, processing, rollback, and retry, linked to CCG identifiers and snapshot IDs, supporting reverse tracing of the root cause of problems and improving auditing and investigation efficiency. Furthermore, it interacts with other core modules through standardized interfaces, allowing integration without modifying external module logic.

[0248] Please refer to Figure 9 , Figure 9 Workflow diagram for the dynamic gas pre-allocation and adjustment module.

[0249] 1. Core positioning: To achieve accurate pre-allocation and real-time optimization of gas quota for cross-contract transactions, and solve the problems of gas waste and overflow.

[0250] 2. Key Components: (1) Input adapter unit In one or more embodiments, the input adaptation unit is used to standardize the reception of external input data, complete multi-dimensional parameter parsing and format conversion, provide input features in a unified format for subsequent pre-allocated models, and adapt to parameter differences of different blockchain platforms.

[0251] Specifically, the input adaptation unit extracts the number of participating contracts (N), the quantification of the operational complexity of each contract, and the average gas consumption of similar historical transactions (by querying the blockchain's historical transaction database for cross-contract transaction data of the same type over the past 30 days). It also collects real-time network gas prices (e.g., in Gwei units), the remaining block gas limit, and the network congestion index. Contract operational complexity includes storage writes (weight 1.5), reads (weight 0.8), and computation logic (weight 1.2). For example, a contract with 2 storage writes + 3 computations has a complexity of 2 × 1.5 + 3 × 1.2 = 6.6. The network congestion index is calculated as "current number of pending transactions / historical average," and a threshold > 1.5 indicates congestion.

[0252] Next, the extracted parameters are associated with a unique contract collaboration group identifier to ensure that the Gas data corresponds one-to-one with cross-contract transactions. Furthermore, parameters from different platforms (such as chaincode call costs for Hyperledger Fabric and opcode consumption for other blockchain platforms) are uniformly converted into standard feature vectors within the module, for example, with a dimension of 8, including the number of contracts, complexity, historical average, network price, etc.

[0253] For inputs lacking key parameters (such as no historical transaction data), default values ​​are automatically filled in (such as the median of the same contract type for historical averages) to avoid abnormal model inputs.

[0254] (2) DQN (Deep Reinforcement Learning) Gas Pre-allocation Model

[0255] In one or more embodiments, the DQNGas pre-allocation model is based on the deep Q-network algorithm, learns the gas consumption patterns of cross-contract transactions, and sends the initial gas quota for each sub-contract call link to ensure pre-allocation accuracy with a deviation rate of ≤12%.

[0256] Specifically, the model training data includes input features such as the number of contracts and complexity, actual gas consumption, and historical cross-contract transaction data such as transaction results (success / failure due to gas overflow); the network structure includes an input layer (8-dimensional features), a hidden layer (2 fully connected layers with 64 and 32 neurons respectively, activation function ReLU), and a sending layer (sending N initial gas quotas, N = number of participating contracts, activation function Linear); the reward function uses gas utilization rate (actual consumption / pre-allocated quota) as the core reward to guide the model to optimize pre-allocation accuracy.

[0257] In real-time inference, the model loads pre-trained weights and sends the initial Gas quota for each subcontract (e.g., Contract A: 120,000 Gas, Contract B: 85,000 Gas) and the overall redundancy pool ratio (fixed at 20%, e.g., total initial quota of 100,000 Gas, redundancy pool of 20,000 Gas).

[0258] (3) Redundant Gas Pool Management Unit

[0259] In one or more embodiments, the redundant Gas pool management unit is used to manage the overall redundant Gas pool for cross-contract transactions. It is responsible for redundant pool creation, Gas quota allocation, and remaining amount statistics, providing resource support for dynamic adjustment and avoiding local Gas overflow that could lead to overall transaction failure.

[0260] Specifically, the redundant pool creation rule calculates the total redundant pool amount as "the sum of the initial Gas quota of all sub-contracts × 20%", locks this part of Gas during creation (prohibiting other transactions from occupying it), and generates a unique "Gas Pool ID" (associated with CCG identifier) ​​for easy identification.

[0261] During the allocation of quotas, when a subcontract's gas consumption exceeds 80% of the initial quota and still needs to be executed, gas is allocated from the redundancy pool to that subcontract. The amount allocated in a single transaction shall not exceed 50% of the remaining amount in the redundancy pool to avoid excessive consumption by a single contract. When a subcontract completes its execution ahead of schedule (e.g., the actual consumption is only 60% of the initial quota), the unused gas is automatically recovered to the redundancy pool, and the remaining amount in the redundancy pool is updated immediately after recovery.

[0262] Meanwhile, the initial total amount, allocated amount, and remaining amount of the redundancy pool are recorded in real time, and the status is updated once every cycle (e.g., 5ms) and synchronized to the real-time tracking unit and the dynamic allocation unit to ensure data consistency.

[0263] (4) Real-time Gas Follow-up Unit

[0264] In one or more embodiments, the real-time Gas tracking unit deploys a Gas tracking probe to the contract node to collect Gas consumption progress in real time, analyze consumption trends, provide trigger signals for dynamic adjustments, and ensure timely detection of Gas consumption anomalies.

[0265] Specifically, by pushing a lightweight follow-up probe to each contract node, opcode-level (code-level) gas consumption is captured in real time (e.g., the SSTORE instruction consumes 20,000 Gas, and the ADD instruction consumes 3 Gas). At the same time, a data request is sent to the probe once every cycle (e.g., 10ms) to collect the gas consumption of the current subcontract and the estimated gas demand of the remaining executable steps, ensuring real-time performance.

[0266] The collected data is analyzed using a sliding window to determine three states: "consumption exceeds 80% (replenishment required)," "completion ahead of schedule (recovery required)," and "consumption is stable (no adjustment required)." Corresponding trigger signals are then generated and pushed to the dynamic allocation unit.

[0267] Specifically, if the probe fails to return data multiple times in a row (node ​​failure), an alarm for abnormal node gas follow-up is immediately sent to the cross-contract atomicity coordination module, triggering the backup node switching logic.

[0268] (5) Dynamic Gas Dispensing Unit

[0269] In one or more embodiments, the dynamic gas allocation unit receives a trigger signal from the real-time follow-up unit, performs gas quota replenishment or recovery operations, updates the gas quota of each sub-contract, and records allocation logs to ensure that adjustments are traceable.

[0270] Specifically, upon receiving a "consumption exceeds 80%" signal, the dynamic gas allocation unit first checks the remaining amount in the redundancy pool. If the remaining amount is greater than or equal to the gas still needed by the current subcontract (estimated based on the remaining steps), it generates a supplementary instruction (including supplementary amount and target contract address). If the remaining amount is insufficient, it sends a "Gas shortage warning" to the cross-contract atomic coordination module, suggesting that the user choose whether to add gas. Upon receiving an "early completion" signal, it calculates the unused gas amount (the difference between the initial amount and the actual consumption), generates a recycling instruction, reclaims the unused gas to the redundancy pool, and updates the final gas consumption record of the subcontract.

[0271] The allocation instructions are pushed to the contract nodes via encrypted communication (TLS1.3) to ensure that the instructions cannot be tampered with. In addition, the dynamic gas allocation unit generates a unique UUID for each allocation instruction. The contract nodes only execute instructions with unprocessed UUIDs to avoid gas data chaos caused by repeated allocations.

[0272] (6) Results collection unit and Gas log database

[0273] In one or more embodiments, the result collection unit and the Gas log database are used to collect full-process data on Gas pre-allocation, dynamic adjustment, and final consumption, complete persistent storage, provide data support for subsequent auditing and traceability, and send standardized results to external modules.

[0274] Specifically, the database uses the InfluxDB time-series database, and stores the Gas result data as shown in Table 3 by partitioning by CCG identifier and timestamp. It supports fast query by CCG identifier, contract address, and time range. The previous day's Gas log data is automatically backed up every morning at midnight (backed up to a distributed storage system, such as MinIO), and 90 days of backups are retained to meet the data retention requirements for compliance audits.

[0275]

[0276] Table 3 Gas Results Data Structure

[0277] (7) Output adapter unit

[0278] In one or more embodiments, the output adaptation unit converts the Gas results (pre-allocation, dynamic adjustment, and final consumption) generated by the module into a format recognizable by external modules such as the cross-contract atomic coordination module and the contract collaboration log storage and traceability module, and completes the data push to ensure cross-module data compatibility.

[0279] Specifically, the output adaptation unit converts data formats according to the requirements of external modules, such as sending the initial gas quota and dynamic allocation record in JSON format to the cross-contract atomic coordination module, and sending the gas consumption details in CSV format to the log storage module; it adopts a dual mechanism of active push and passive pull to push the allocation results to the coordination module in real time, and provides a RESTful API for the log storage module to query data.

[0280] If the push fails (e.g., due to network interruption), it will automatically retry 3 times (with retry intervals of 100ms, 200ms, and 500ms respectively). If the retry fails, the push exception log will be recorded and a manual alarm will be triggered.

[0281] In summary, the dynamic Gas pre-allocation and adjustment module, based on the DQN reinforcement learning model and combined with historical data and real-time network status, significantly reduces transaction failures caused by improper pre-allocation. By tracking the millisecond-level allocation response in real time, it improves Gas utilization and avoids Gas waste, while a redundancy pool ensures resource replenishment in case of local overflow. All Gas pre-allocation, adjustment, and consumption data are stored and associated with CCG identifiers and Gas pool IDs, supporting reverse traceability and meeting compliance audit requirements.

[0282] Please refer to Figure 10 , Figure 10 Workflow diagram for the contract collaboration log storage and traceability module.

[0283] 1. Core positioning: To achieve end-to-end evidence storage and traceability in cross-contract collaboration processes, meet compliance audit requirements, and assist in risk identification.

[0284] 2. Key Components

[0285] (1) Log data receiving unit

[0286] In one or more embodiments, the log data receiving unit serves as the data entry point for the module and other external core modules such as the cross-contract atomic coordination module and the dynamic gas pre-allocation and adjustment module. It receives end-to-end collaborative log data to ensure data integrity and real-time performance, laying the foundation for subsequent preprocessing and evidence storage.

[0287] The scope of received data includes CCG collaboration basic data of the cross-contract atomic coordination module, gas allocation and adjustment logs of the dynamic gas pre-allocation and adjustment module, permission authorization logs of the cross-contract permission proxy module, exception handling logs of the cross-contract exception collaborative processing module, and contract execution logs of contract nodes.

[0288] The CCG collaboration basic data includes CCG identifier, participating contract address, coordinating node address, and execution stage; the Gas allocation and adjustment log includes Gas pool ID, initial quota, allocation record, and final consumption details; the permission authorization log includes token ID, zero-knowledge proof digest, and whitelist verification result; the exception handling log includes exception event ID, exception level, rollback snapshot ID, and processing result; and the contract execution log includes contract address, execution status, and status change record.

[0289] Specifically, a dual-mode approach of active push and passive pull is adopted. The external module pushes logs in real time according to the transaction lifecycle, while the module also provides a pull interface (supporting the pull of missing data by CCG identifier) ​​to avoid data loss. The communication protocol uses TLS1.3 encryption to prevent data transmission leakage.

[0290] In addition, when receiving data, it is also necessary to verify the uniqueness of the CCG identifier and the completeness of the fields (such as the Gas log must contain the Gas pool ID). If key fields are missing, an ERR_LOG_INCOMPLETE error code will be returned, requiring a re-push.

[0291] (2) Log data preprocessing unit

[0292] In one or more embodiments, the log data preprocessing unit performs standardization processing on the received multi-source heterogeneous log data, eliminates format differences, supplements association identifiers, and generates log data with a unified structure, providing standardized input for Merkle tree evidence storage and query.

[0293] Specifically, the log formats of different modules (such as the JSON format of the Gas module and the ProtoBuf format of contract nodes) are uniformly converted into the standard JSON structure within the module. Field names are named according to "module type_field meaning" (such as gas_initial_quota / auth_token_id) to avoid field conflicts. A global identification ID (GTID) is added to each log data, in the format of CCG identifier, data type encoding, and timestamp (millisecond level) to ensure that a single log is uniquely bound to cross-contract transactions. At the same time, the data source module encoding is supplemented (such as coordination module=01, Gas module=02) to facilitate traceability. Redundant fields (such as duplicate execution status records) are filtered, format errors are corrected (such as unifying the timestamp format to millisecond level), and range validation is performed on numerical fields (such as Gas quota) (rejecting negative numbers or outliers exceeding the blockchain Gas limit).

[0294] (3) Merkle Tree Evidence Engine

[0295] In one or more embodiments, the Merkle tree evidence storage engine is used to construct a Merkle tree from standardized log data, generate an immutable root hash and associate it with the main transaction block, realize blockchain-level evidence storage of cross-contract collaborative logs, ensure the integrity and immutability of logs, and is the core evidence storage unit of the module.

[0296] The Merkle tree construction rules specifically include three parts: leaf node generation, tree structure construction, and data association. Leaf node generation calculates the hash value of a single standardized log data entry using the SHA-256 algorithm, which serves as the leaf node of the Merkle tree. All log leaf nodes for the same cross-contract transaction are sorted by data reception time to ensure uniqueness. Tree structure construction uses a binary Merkle tree structure. Leaf nodes are paired to calculate the parent node hash (if the number of leaf nodes is odd, the last node is copied and its parent node is calculated), iterating upwards layer by layer until a unique root hash (Merkle Root) is generated. Parallel computation is supported during the construction process (enabled when the number of leaf nodes > 100). Data association binds the Merkle root hash to the main transaction hash of the cross-contract transaction, while recording the total number of leaf nodes and the tree construction timestamp, generating a certificate containing the root hash, CCG identifier, and main transaction hash.

[0297] Furthermore, the Merkle tree proof engine generates a corresponding Merkle proof for each leaf node (including hashes of all parent nodes from the leaf node to the root node). The verifier can verify whether the log data has been tampered with by using the leaf node hash, the Merkle proof, and the root hash. Additionally, if the hash calculation for a log data entry fails during the construction process, it automatically retryes three times (with a retry interval of 10ms). If a retry fails, the data is marked as abnormal and stored separately in an abnormal log table, without affecting the overall Merkle tree construction.

[0298] (4) Block header writing unit

[0299] In one or more embodiments, the block header writing unit is used to write the Merkle root hash into the block header corresponding to the cross-contract transaction, complete the association between the log notarization and the main blockchain, and ensure that the notarization result has blockchain-level immutability and credibility.

[0300] When writing, the block header writing unit first receives the notarization certificate sent by the Merkel engine and queries the block header structure of the block on the main exchange (obtained through the blockchain node API). Then, it writes the Merkel root hash into the extended fields of the block header (such as the extraData field and the metadata field of Hyperledger Fabric), and simultaneously records the log notarization identifier (indicating that the block contains cross-contract collaboration log notarization). Next, it calls the blockchain node's block update interface, submits the block header modification, and waits for node consensus confirmation (confirmation time varies depending on the blockchain platform; Fabric ≤ 2s). After confirmation, it generates the corresponding notarization result (including block height, root hash, and write time).

[0301] The block header writing unit also provides adaptation plugins (such as Fabric plugins) to address the differences in block header structures across different blockchain platforms. This allows for root hash writing without modifying the core logic. Plugins support dynamic loading, so when adding a new platform, only the corresponding plugin needs to be developed, shortening the adaptation cycle.

[0302] If the block header writing fails (e.g., due to network interruption), the block status is automatically detected and retried (retry intervals are exponentially backed up by 1s, 2s, and 4s, with a maximum of 5 retries). If the retry fails, an alarm is triggered and an evidence storage anomaly log is recorded, supporting manual intervention to rewrite.

[0303] (5) Log query database and Merkle tree database

[0304] In one or more embodiments, the log query database stores standardized log data, and the Merkle tree database stores Merkle tree structures. Together, they provide high-concurrency, low-latency query support, supporting multi-dimensional queries and Merkle proof verification, which is the core of the module's data storage.

[0305] Technical details: The log query database (QueryDB) uses an Elasticsearch cluster (3 master and 3 slave architecture), supports full-text search and multi-dimensional filtering, and is adapted to the high-frequency query needs of log data. It is indexed by CCG identifier, and each index contains fields such as "GTID, data type, timestamp, log content". At the same time, it creates inverse indexes from CCG identifier to log list and from exception event ID to associated log.

[0306] The log query database supports retaining logs according to configuration (default 90 days). Expired data is automatically archived to distributed storage (such as MinIO). After archiving, it can be queried through the archive interface, ensuring that storage resources are controllable.

[0307] MerkleDB uses a LevelDB key-value database (supporting persistence and high-performance read / write). The key is a CCG identifier, and the value is Merkle tree structure data (including a list of leaf node hashes, parent node hash levels, and root hash). It adopts an "incremental storage" strategy, storing only the hash data of the Merkle tree (not the original log). At the same time, the data is compressed periodically (using the LZ4 compression algorithm) to reduce storage costs. It adopts a master-slave synchronous architecture, synchronizing data to the slave database within 100ms after writing data to the master database, and automatically switching to the slave database in case of master database failure.

[0308] (6) Multi-dimensional query API unit

[0309] In one or more embodiments, the multi-dimensional query API unit is used to provide a standardized RESTful API interface, supporting multi-dimensional queries of cross-contract collaboration logs, returning structured results and Merkel proofs, and meeting the query needs of users for reconciliation and audit institutions for compliance review.

[0310] Supported query dimensions include transaction hash, CCG identifier, contract address, time range, and abnormal event ID. The transaction hash includes all log data associated with the transaction and the Merkle root hash. The CCG identifier includes the full-link log of the corresponding CCG and the Merkle tree structure. The contract address includes all cross-contract transaction logs in which the contract participated. The time range includes log summaries of all cross-contract transactions within the time period. The abnormal event ID includes the full-process log of abnormal handling and associated snapshot data.

[0311] The results support two output formats: JSON (default) and CSV. CSV format supports batch export. The results include a link to obtain the Merkel proof for a single log entry, which users can use for integrity verification. Furthermore, API calls require API key authentication to prevent unauthorized queries and ensure data security.

[0312] (7) Audit Analysis Module and Report Management Unit

[0313] In one or more embodiments, the audit analysis module and the report management unit are used to mine abnormal collaboration patterns based on historical log data, generate risk warning reports, assist audit institutions and platform operators in identifying security risks, meet compliance audit requirements, and improve system security.

[0314] Specifically, the audit analysis module uses association rule algorithms to uncover abnormal features, such as transactions with the same contract combination failing ≥5 times in the past hour, gas consumption fluctuations exceeding 50%, and a sudden increase in whitelist verification rejection rate. The identification threshold can be dynamically adjusted through configuration. Risks are divided into three levels according to the scope of the anomaly's impact: low (single transaction), medium (single contract), and high (multiple contracts). High-risk events (such as high-frequency failures of multiple contracts) trigger alarms in real time (alarm delay ≤10s), while medium and low risks are included in periodic reports. The module also calculates the success rate, anomaly rate, and gas utilization rate of cross-contract transactions on a daily / weekly basis, generates trend curves, and identifies long-term anomalies (such as a contract's weekly failure rate rising from 1% to 10%).

[0315] The report management unit automatically generates regular reports (daily / weekly reports), which include overall transaction statistics, summaries of abnormal events, risk level distribution, optimization suggestions, etc.; it also supports manual triggering of customized reports (selected according to the audit firm's needs); the reports are stored in PDF format in ReportDB (MySQL database) and pushed to preset recipients (such as the audit firm's email address, platform operation backend), and the push records are written to the audit log to ensure traceability.

[0316] The contract collaboration log storage and traceability module is based on Merkle trees and a block header writing mechanism. The log data root hash is associated with the main blockchain, making tampering as difficult as tampering with the blockchain itself, ensuring log credibility and meeting the needs of highly compliant scenarios such as finance and government. It incorporates an Elasticsearch database and inverted indexes, supporting multi-dimensional queries by transaction, contract, and time, with batch export functionality adapted to the large-scale data extraction needs of auditing institutions. An association rule algorithm automatically identifies abnormal collaboration patterns, provides real-time alerts for high-risk events, and offers regular reports with trend analysis, enabling early detection of security vulnerabilities (such as frequent malicious contract failures) and improving system stability. Through adaptable plugins, it supports block header writing for multiple blockchain platforms such as Hyperledger Fabric. Log preprocessing eliminates differences between multi-source data, allowing for integration without reconstruction and strong adaptability. The database adopts a cluster architecture with robust data retention and archiving mechanisms. Each log entry contains a GTID and source identifier, supporting reverse tracing from query results to the original module, improving troubleshooting efficiency.

[0317] The contract processing apparatus in this application is described in detail below. Please refer to [link / reference]. Figure 11 , Figure 11 This is a schematic diagram of one embodiment of the contract processing apparatus in this application. The contract processing apparatus 700 includes: The receiving module 710 is used to receive cross-contract transaction requests sent by client nodes. The cross-contract transaction requests carry pre-operation information and a list of contract addresses. The list of contract addresses includes M smart contract addresses, where M is an integer greater than 1. The processing module 720 is used to construct a contract collaboration group based on the list of contract addresses. The contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to a smart contract address. The sending module 730 is used to send corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node can perform processing operations for cross-contract transactions based on the corresponding pre-operation instructions. The receiving module 710 is also used to receive the pre-operation results sent by each contract node, and obtain M pre-operation results; The processing module 720 is also used to send a corresponding first rollback instruction to each contract node in the contract collaboration group through the sending module 730 when the M pre-operation results include failure execution results, so that each contract node performs rollback processing on the corresponding processing operation based on the first rollback instruction.

[0318] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The processing module 720 is specifically used to determine M nodes as contract nodes from the candidate node set of the blockchain network based on the number of smart contract addresses in the contract address list. The sending module 730 is specifically used to send the corresponding smart contract address to each contract node, so that each contract node can call the corresponding smart contract based on the corresponding smart contract address. The calling module is used to call the corresponding smart contract M contract nodes as a contract collaboration group.

[0319] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, the pre-operation information includes simulated operation information and resource locking information; The processing module 720 is specifically used to generate corresponding simulated operation instructions based on the pre-operation information; Generate corresponding resource locking instructions based on resource locking information. The sending module 730 is specifically used to send corresponding simulation operation instructions and resource lock instructions to each contract node in the contract collaboration group. The simulation operation instructions are used to trigger each contract node to perform simulation processing operations for cross-contract transactions, and the resource lock instructions are used to trigger each contract node to perform resource lock operations for cross-contract transactions.

[0320] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The sending module 730 is also used to send a corresponding confirmation execution instruction to each contract node in the contract collaboration group when all M pre-operation results include a successful execution result, so that each contract node runs the corresponding smart contract based on the confirmation execution instruction.

[0321] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, the contract collaboration group further includes multiple witness nodes. The witness nodes are nodes that are different from the contract nodes and are determined from the candidate node set of the blockchain network. They are used to verify the pre-operation results of each contract node and to vote on consensus. The sending module 730 is also used to send corresponding consensus trigger instructions to each contract node and each witness node in the contract collaboration group when all M pre-operation results include successful execution results, so that each contract node votes on the M pre-operation results and each witness node votes on the M pre-operation results. The receiving module 710 is also used to receive the voting results sent by each contract node and each witness node respectively; The processing module 720 is also used to confirm that each contract node and each witness node have the same consensus when the result reaches the voting number threshold among multiple voting results; The sending module 730 is also used to send a corresponding confirmation execution instruction to each contract node in the contract collaboration group when the consensus between each contract node and each witness node is consistent and all M pre-operation results include successful execution.

[0322] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The acquisition module is used to obtain the account private key hash value, account public key, and permission validity period from cross-contract transaction requests; The processing module 720 is also used to combine the account public key, permission validity period and contract address list into verification input information; The account private key hash value, account public key, permission validity period and contract address list are encrypted and calculated to generate a proof subject; Hash the account public key, permission validity period, and contract address list to obtain the credential hash value; The proof subject and the certificate hash value are combined to form the verification certificate information; The sending module 730 is also used to send the verification certificate information and the verification input information to each contract node respectively, so that each contract node can verify the legality of cross-contract transactions based on the verification certificate information and the verification input information; Once each contract node confirms that the cross-contract transaction is legal, a corresponding pre-operation instruction is sent to each contract node in the contract collaboration group.

[0323] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, Processing module 720 is also used to generate a temporary public key for cross-contract transaction requests based on a cryptographic algorithm; The acquisition module is also used to acquire the group identifier of the contract collaboration group; The processing module 720 is also used to combine the group identifier, temporary public key, verification credential information and verification input information into a temporary token; The sending module 730 is also used to send temporary tokens to each contract node so that each contract node can verify the legality of cross-contract transactions based on the temporary tokens.

[0324] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The acquisition module is also used to obtain the whitelist information corresponding to the account's public key; The processing module 720 is also used to perform legality verification on each contract address in the contract address list based on the whitelist information; When all contract addresses are included in the whitelist information, the legality of each smart contract corresponding to the contract address list is determined. The sending module 730 is also used to send corresponding pre-operation instructions to each contract node in the contract collaboration group when it is determined that the cross-contract transaction is legitimate and that each contract address is included in the whitelist information.

[0325] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The acquisition module is also used to acquire abnormal status information corresponding to the contract node that is in an abnormal running state when any contract node is in an abnormal running state. The processing module 720 is also used to determine the abnormal level corresponding to the abnormal state information based on the abnormal state information and the abnormal level mapping table; The sending module 730 is also used to send corresponding exception handling instructions to the corresponding contract nodes according to the exception level corresponding to the exception status information, so that the corresponding contract nodes can perform exception handling operations corresponding to the exception level of the exception status information based on the exception handling instructions.

[0326] Optionally, in the above Figure 11Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The sending module 730 is specifically used to send a corresponding second rollback instruction to each contract node when the abnormality level corresponding to the abnormal status information includes the first level, so that each contract node can roll back to the state before receiving the cross-contract transaction request based on the second rollback instruction. If the abnormal status information corresponds to the second level of abnormality, a corresponding third rollback instruction is sent to each contract node in the abnormal running state so that each contract node in the abnormal running state rolls back the target operation based on the second rollback instruction. The target operation is the processing operation of each contract node corresponding to the abnormal status information, and the first level is higher than the second level. The processing module 720 is specifically used to store the abnormal status information as an abnormal log when the abnormal status information corresponds to the third level of abnormality.

[0327] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The processing module 720 is also used to generate retry parameters based on the cross-contract transaction request when receiving rollback confirmation information sent by each contract node in an abnormal running state. The rollback confirmation information is used to indicate that the contract node in an abnormal running state has successfully rolled back the target operation. Sign the hash value of the retry parameter based on the private key corresponding to the retry function; Based on the hash value of the retry parameters after signing, the retry interface address is provided to the client node, so that the client node can execute the transaction retry request based on the retry interface address.

[0328] Optionally, in the above Figure 11 Based on the corresponding embodiments, in another embodiment of the contract processing apparatus 700 provided in this application, The processing module 720 is also used to determine the target error type corresponding to the abnormal status information based on the mapping table between abnormal status information and error type; The acquisition module is also used to obtain the processing scheme corresponding to the target error type based on the type scheme mapping table; The sending module 730 is also used to send corresponding prompt information to the client node based on the processing scheme.

[0329] Figure 12This is a schematic diagram of a computer device structure provided in an embodiment of this application. The computer device 800 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 830 (e.g., one or more processors) and a memory 810, and one or more storage media 820 (e.g., one or more mass storage devices) for storing application programs 823 or data 822. The memory 810 and storage media 820 can be temporary or persistent storage. The program stored in the storage media 820 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the computer device. Furthermore, the CPU 830 may be configured to communicate with the storage media 820 and execute the series of instruction operations in the storage media 820 on the computer device 800.

[0330] Computer device 800 may also include one or more power supplies 840, one or more wired or wireless network interfaces 860, one or more input / output interfaces 850, and / or one or more operating systems 821, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM And so on. The steps performed by the computer device in the above embodiments can be based on this... Figure 12 The computer device structure shown.

[0331] The steps performed by the computer device in the above embodiments can be based on this Figure 12 The computer device structure shown.

[0332] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0334] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0335] 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.

[0336] 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0337] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for contract processing, characterized in that, include: Receive cross-contract transaction requests sent by client nodes, wherein the cross-contract transaction requests carry pre-operation information and a list of contract addresses, the list of contract addresses including M smart contract addresses, where M is an integer greater than 1; A contract collaboration group is constructed based on the contract address list, wherein the contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to one of the smart contract addresses; Send corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node performs processing operations for cross-contract transactions based on the corresponding pre-operation instructions; Receive the pre-operation results sent by each contract node to obtain M pre-operation results; If the M pre-operation results include failure execution results, a corresponding first rollback instruction is sent to each contract node in the contract collaboration group, so that each contract node performs rollback processing on the corresponding processing operation based on the first rollback instruction.

2. The method as described in claim 1, characterized in that, The step of constructing a contract collaboration group based on the contract address list includes: Based on the number of smart contract addresses in the contract address list, M nodes are selected from the candidate node set of the blockchain network as the contract nodes; Send the corresponding smart contract address to each contract node, so that each contract node can call the corresponding smart contract based on the corresponding smart contract address; Based on the M contract nodes that invoke the corresponding smart contract, a contract collaboration group is formed.

3. The method as described in claim 1, characterized in that, The pre-operation information includes simulated operation information and resource locking information; The step of sending corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node performs processing operations for cross-contract transactions based on the corresponding pre-operation instructions, includes: Generate corresponding simulated operation instructions based on the pre-operation information; Generate a corresponding resource locking instruction based on the resource locking information. Send corresponding simulation operation instructions and resource lock instructions to each contract node in the contract collaboration group. The simulation operation instructions are used to trigger each contract node to perform a simulation processing operation for cross-contract transactions, and the resource lock instructions are used to trigger each contract node to perform a resource lock operation for cross-contract transactions.

4. The method as described in claim 1, characterized in that, After receiving the pre-operation results sent by each contract node and obtaining M pre-operation results, the process further includes: If all M pre-operation results include a successful execution result, a corresponding confirmation execution instruction is sent to each contract node in the contract collaboration group, so that each contract node runs the corresponding smart contract based on the confirmation execution instruction.

5. The method as described in claim 4, characterized in that, The contract collaboration group also includes multiple witness nodes, which are nodes different from the contract nodes and are determined from the candidate node set of the blockchain network. They are used to verify the pre-operation results of each contract node and to vote on consensus. Before sending the corresponding confirmation execution instruction to each contract node in the contract collaboration group, the method further includes: If all M pre-operation results include successful execution results, a corresponding consensus trigger instruction is sent to each contract node and each witness node in the contract collaboration group, so that each contract node votes on the M pre-operation results and each witness node votes on the M pre-operation results. Receive the voting results sent by each contract node and each witness node respectively; When the number of votes reaches a threshold among multiple voting results, it is confirmed that each contract node and each witness node have a consensus. If all M pre-operation results include a successful execution result, then a corresponding confirmation execution instruction is sent to each contract node in the contract collaboration group, including: If each contract node and each witness node reach a consensus, and all M pre-operation results include successful execution, a corresponding confirmation execution instruction is sent to each contract node in the contract collaboration group.

6. The method as described in claim 1, characterized in that, The cross-contract transaction request also includes authorization information, and after receiving the cross-contract transaction request sent by the client node, it also includes: From the cross-contract transaction request, obtain the account private key hash value, account public key, and permission validity period; The account public key, the permission validity period, and the contract address list are combined to form the verification input information; The account private key hash value, the account public key, the permission validity period, and the contract address list are encrypted and calculated to generate a proof entity; The account public key, the permission validity period, and the contract address list are hashed to obtain the credential hash value; The proof subject and the certificate hash value are combined to form the verification certificate information; The verification credential information and the verification input information are sent to each contract node respectively; The step of sending corresponding pre-operation instructions to each contract node in the contract collaboration group also includes: If each contract node determines that the verification rules are met based on the verification credential information and the verification input information, then it sends a corresponding pre-operation instruction to each contract node in the contract collaboration group.

7. The method as described in claim 6, characterized in that, The step of sending the verification credential information and the verification input information to each contract node, so that each contract node verifies the legality of the cross-contract transaction based on the verification credential information and the verification input information, includes: Based on the encryption algorithm, a temporary public key for the cross-contract transaction request is generated; Obtain the group identifier of the contract collaboration group; The group identifier, the temporary public key, the verification credential information, and the verification input information are combined into a temporary token; The temporary token is input into each contract node so that each contract node can verify the legality of the cross-contract transaction based on the temporary token.

8. The method as described in claim 6, characterized in that, Following the receipt of the cross-contract transaction request sent by the client node, the following is also included: Obtain the whitelist information corresponding to the account's public key; Based on the whitelist information, the legality of each contract address in the contract address list is verified; When all the contract addresses are included in the whitelist information, the smart contracts corresponding to the contract address list are determined to be legitimate. The step of sending corresponding pre-operation instructions to each contract node in the contract collaboration group also includes: Once it is determined that the cross-contract transaction is legitimate and that all contract addresses are included in the whitelist information, a corresponding pre-operation instruction is sent to each contract node in the contract collaboration group.

9. The method as described in claim 1, characterized in that, The method further includes: If any contract node is in an abnormal operating state, obtain the abnormal state information corresponding to the contract node in the abnormal operating state; Based on the abnormal status information and the abnormal classification mapping table, the abnormal level corresponding to the abnormal status information is determined; Based on the anomaly level corresponding to the anomaly status information, a corresponding anomaly handling instruction is sent to the corresponding contract node, so that the corresponding contract node executes the anomaly handling operation corresponding to the anomaly level of the anomaly status information based on the anomaly handling instruction.

10. The method as described in claim 9, characterized in that, The step of sending a corresponding exception handling instruction to the corresponding contract node according to the exception level corresponding to the exception status information, so that the corresponding contract node executes the exception handling operation corresponding to the exception level of the exception status information based on the exception handling instruction, includes: If the abnormality level corresponding to the abnormal status information includes the first level, a corresponding second rollback instruction is sent to each contract node so that each contract node rolls back to the state before receiving the cross-contract transaction request based on the second rollback instruction. If the abnormality level corresponding to the abnormal status information includes the second level, a corresponding third rollback instruction is sent to each contract node in the abnormal operating state, so that each contract node in the abnormal operating state rolls back the target operation based on the second rollback instruction. The target operation is the processing operation of each contract node corresponding to the abnormal status information, and the first level is higher than the second level. If the anomaly level corresponding to the abnormal status information includes the third level, the abnormal status information will be stored as an anomaly log.

11. The method as described in claim 10, characterized in that, The method further includes: Upon receiving rollback confirmation information from each contract node in an abnormal operating state, retry parameters are generated based on the cross-contract transaction request, wherein the rollback confirmation information is used to indicate that the contract node in an abnormal operating state has successfully rolled back the target operation. Sign the hash value of the retry parameter based on the private key corresponding to the retry function; Based on the hash value of the retry parameters after signing, a retry interface address is provided to the client node, so that the client node executes a transaction retry request based on the retry interface address.

12. The method as described in claim 9, characterized in that, After obtaining the abnormal state information corresponding to the contract node in the case that any contract node is in an abnormal operating state, the method further includes: Based on the mapping table between the abnormal status information and the error type, determine the target error type corresponding to the abnormal status information; According to the type scheme mapping table, obtain the processing scheme corresponding to the target error type; Based on the processing scheme, a corresponding prompt message is sent to the client node.

13. A contract processing apparatus, characterized in that, include: The receiving module is used to receive cross-contract transaction requests sent by client nodes. The cross-contract transaction requests carry pre-operation information and a list of contract addresses. The list of contract addresses includes M smart contract addresses, where M is an integer greater than 1. The processing module is used to construct a contract collaboration group based on the contract address list, wherein the contract collaboration group includes M contract nodes, and each contract node is used to run a smart contract corresponding to the smart contract address; The sending module is used to send corresponding pre-operation instructions to each contract node in the contract collaboration group, so that each contract node can perform processing operations for cross-contract transactions based on the corresponding pre-operation instructions. The receiving module is also used to receive the pre-operation results sent by each contract node, and obtain M pre-operation results; The sending module is further configured to, in the case that the M pre-operation results include failure execution results, send a corresponding first rollback instruction to each contract node in the contract collaboration group, so that each contract node performs rollback processing on the corresponding processing operation based on the first rollback instruction.

14. A computer device, characterized in that, include: Memory, transceiver, processor, and bus system; The memory is used to store programs; The processor is configured to execute a program in the memory, including a method for performing contract processing as described in any one of claims 1 to 12; The bus system is used to connect the memory and the processor to enable communication between the memory and the processor.

15. A computer-readable storage medium, characterized in that, Includes instructions that, when run on a computer, cause the computer to perform a method of contract processing as described in any one of claims 1 to 12.

Images