Intelligent contract distributed computing method based on virtual block chain nodes

Abstract

The invention provides an intelligent contract distributed computing method based on a virtual block chain node, which comprises the following steps: S1, a central coordination node and a plurality of cooperative terminal nodes are dynamically combined on a logic level to form a virtual block chain node, and the central coordination node performs management and task scheduling on the cooperative terminal nodes; s2, the central coordination node receives the smart contract execution request, performs logic analysis on the smart contract and decomposes the smart contract into a plurality of parallel subtasks; s3, the central coordination node assigns the subtasks to the cooperation terminal nodes for parallel processing, and validity verification is carried out on a calculation result through a verification process; and S4, the central coordination node encapsulates the verified final execution result into a transaction and submits the transaction to the target block chain network, and after the transaction is subjected to consensus processing, the smart contract is executed to update the state data on the chain. According to the method, the contradiction between limited computing resources of the Internet of Things equipment and high computing resource overhead of the block chain during integration of the Internet of Things and the block chain is solved.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a distributed computing method for smart contracts based on virtual blockchain nodes. Background Technology

[0002] Blockchain technology, as a crucial field of distributed computing, has demonstrated immense potential in scenarios such as finance, supply chain, and the Internet of Things (IoT) due to its decentralized, traceable, and tamper-proof characteristics. However, in practical applications, the execution efficiency and reliability of smart contracts have become bottlenecks restricting the widespread adoption of blockchain networks. Smart contracts, as automatically executed program code, can implement complex business logic, but their operation relies on the joint computation of all nodes in the blockchain network, placing extremely high demands on computing resources and execution efficiency. In high-performance business scenarios, balancing efficient execution with reliable results has become a critical issue that blockchain technology urgently needs to overcome. Currently, the execution of smart contracts in blockchain networks is typically completed jointly by all nodes, with each node independently running the complete contract logic. This approach leads to a surge in computational load when dealing with complex contracts, resulting in slow execution speeds. For example, in cross-border payment scenarios in the financial sector, smart contracts need to handle complex logic such as multi-party transaction verification, exchange rate calculation, and compliance checks. Differences in node computing power make some nodes performance bottlenecks, slowing down the overall execution speed.

[0003] Furthermore, the lack of flexibility in resource allocation among nodes, failing to dynamically adjust according to task requirements, leads to wasted or insufficient computing resources. This inefficient execution method directly impacts the responsiveness of blockchain systems in high-concurrency scenarios. A deeper problem lies in the difficulty of verifying the credibility of smart contract execution results. Traditional blockchains rely on full-node consensus to ensure consistency, but when the number of nodes is large or network latency is high, the consensus process is time-consuming. For example, in supply chain management, smart contracts need to verify the authenticity of data sources from multiple parties. If a node returns abnormal results due to calculation errors or malicious behavior, existing mechanisms struggle to quickly locate the problem and ensure the correctness of the result. This inefficient verification not only increases system operating costs but may also undermine user trust due to unreliable results. Therefore, how to achieve efficient parallel execution of smart contracts in a blockchain network, while ensuring the credibility of results through dynamic resource allocation and reliable verification mechanisms, has become a critical issue that blockchain technology urgently needs to address in high-performance application scenarios. Summary of the Invention

[0004] This invention provides a distributed computing method for smart contracts based on virtual blockchain nodes, mainly comprising: S1. A central coordinating node and multiple collaborating terminal nodes dynamically combine at the logical level to form a virtual blockchain node. The central coordinating node manages and schedules tasks for the collaborating terminal nodes. S2. The central coordinating node receives smart contract execution requests, performs logical analysis on the smart contract, and decomposes it into multiple parallel subtasks. S3. The central coordinating node assigns the subtasks to the collaborating terminal nodes for parallel processing and verifies the validity of the calculation results through a verification process. S4. The central coordinating node encapsulates the final, verified execution result into a transaction and submits it to the target blockchain network for consensus confirmation and state update.

[0005] Furthermore, the central coordinating node and multiple collaborating terminal nodes are dynamically combined at the logical level to form a virtual blockchain node, including: S11. The collaborating terminal node initiates a registration request to the central coordinating node, the registration request including resource capabilities and identity information; S12. The central coordinating node approves the registration request and obtains the resource information of the approved collaborating terminal nodes; S13. The central coordinating node includes the approved collaborating terminal nodes in a resource pool and monitors their status using a heartbeat detection mechanism; S14. The central coordinating node dynamically adjusts the composition of the virtual blockchain node according to the resource capabilities and status of the collaborating terminal nodes in the resource pool.

[0006] Furthermore, the step of logically analyzing and decomposing the smart contract into multiple parallelizable subtasks includes: S21. The central coordination node obtains the program logic of the smart contract and determines its computational logic structure through static or dynamic analysis; S22. The central coordination node identifies independent function calls in the smart contract based on function boundaries and generates corresponding subtasks; S23. For parallel data operations, the central coordination node decomposes the loop processing the data set into multiple subtasks processing subsets of the data; S24. The central coordination node identifies conditional branches or independent code blocks in the smart contract and generates independent subtasks; S25. The central coordination node assigns a task identifier and input parameters to each subtask and generates a dispatchable computation package.

[0007] Furthermore, the validity verification of the calculation results through the verification process includes: S31. The central coordination node generates multiple computation replicas based on the subtask results returned by the collaborating terminal nodes using replica assignment; S32. The central coordination node collects the return results of the computation replicas and groups and votes on the results according to weighted voting rules; S33. If the voting result meets the preset quorum threshold, the central coordination node determines that the result is a valid subtask result; S34. If the voting result does not meet the quorum threshold, the central coordination node initiates an abnormal arbitration mechanism, and the subtask is re-executed by a high-trust-level entity; S35. The central coordination node generates the final execution result based on the valid subtask results.

[0008] Furthermore, the grouping and voting of the results according to the weighted voting rules includes: S321. The central coordination node determines the voting weight of each node based on the historical task success rate and hardware performance of the collaborating terminal nodes; S322. The central coordination node collects the calculation results of each collaborating terminal node and groups them according to the result content; S323. The central coordination node performs a weighted vote on the grouped results according to the voting weights and obtains the result group with the highest number of votes; S324. The central coordination node determines whether the result group with the highest number of votes meets the quorum threshold and determines the valid sub-task result.

[0009] Furthermore, the validity verification of the calculation results through the verification process includes: S41. The central coordinating node generates a data source proof based on a Merkle tree according to the valid sub-task results; S42. The central coordinating node digitally signs the root hash of the Merkle tree to generate verifiable proof data; S43. If the abnormal arbitration ratio in the first stage sub-task verification exceeds a preset threshold, the central coordinating node triggers a multi-coordinating node consensus mechanism; S44. Multiple central coordinating nodes execute the convergence operation in parallel and confirm the convergence result through a Byzantine fault-tolerant algorithm; S45. The central coordinating node obtains the consensus-confirmed convergence result as the final execution result.

[0010] Furthermore, the step of encapsulating the verified final execution result into a transaction includes: S51. The central coordinating node encapsulates the final execution result and data source proof into transaction data; S52. The central coordinating node submits the transaction data to the target blockchain network through a standard interface; S53. The target blockchain network performs signature verification and consensus processing on the transaction data; S54. The target blockchain network updates the on-chain state of the smart contract based on the consensus result.

[0011] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a method for dynamically combining a central coordinating node and collaborating terminal nodes to form virtual blockchain nodes, addressing the challenges of efficient smart contract execution and result reliability assurance in distributed computing scenarios. In blockchain networks, the complex logic and high computational demands of smart contracts often lead to low execution efficiency and difficulties in result verification. This invention uses a central coordinating node to logically decompose smart contracts into parallelizable lightweight subtasks, dynamically allocating tasks based on node resource capabilities to achieve efficient parallel computing. Simultaneously, a two-stage verification mechanism is employed, using replica allocation and weighted voting to ensure the correctness of subtask results, and utilizing Merkle trees to generate data source proofs to guarantee the reliability of the converged results. When verification anomalies occur, an anomaly arbitration and multi-coordinating node consensus mechanism are initiated, ensuring result consistency through a high-trust arbitration entity and Byzantine fault tolerance algorithms. This invention significantly improves the execution efficiency and reliability of smart contracts, reduces the computational cost of blockchain networks, enhances the robustness and security of distributed systems, and is suitable for high-performance blockchain application scenarios. Attached Figure Description

[0012] Figure 1 This is a flowchart of a smart contract distributed computing method based on virtual blockchain nodes according to the present invention; Figure 2 This is a schematic diagram of the virtual blockchain node system architecture in this invention; Figure 3 This is a schematic diagram of the two-stage result verification process in this invention; Figure 4 This is a timing diagram of the interaction between the central coordination node and the cooperating terminal nodes in this invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and thoroughly described below with reference to the accompanying drawings. The described embodiments are merely some embodiments of the present invention.

[0014] like Figure 1 This embodiment of a distributed computing method for smart contracts based on virtual blockchain nodes may specifically include: S1, the central coordinating node and multiple collaborating terminal nodes are dynamically combined at the logical level to form a virtual blockchain node, and the central coordinating node performs lifecycle management and task scheduling for the collaborating terminal nodes.

[0015] The central coordinating node receives registration requests from collaborating terminal nodes, approves the requests through a pre-defined identity verification process, and stores the information of approved collaborating terminal nodes in a resource pool, forming a list of collaborating terminal nodes. Based on the node performance parameters in the list, the central coordinating node constructs a task allocation matrix, which records the computing power and current load of each collaborating terminal node. The central coordinating node parses the smart contract execution request, decomposes it into multiple sub-tasks, and assigns these sub-tasks to collaborating terminal nodes with lower loads for parallel processing according to the task allocation matrix. The collaborating terminal nodes process the sub-tasks in a lightweight and secure execution environment and return the computation results to the central coordinating node. The central coordinating node aggregates the results according to the task allocation matrix, forming the contract execution output of the virtual blockchain node.

[0016] For example, when the central coordinating node receives a registration request from a collaborative terminal node, it approves the request through a preset authentication process. This process includes checking the node's digital certificate and network address to ensure the node's security and reliability. The approved node information is stored in a resource pool to form a list of collaborative terminal nodes. This effectively manages the node joining process, prevents unauthorized nodes from participating in the computation, and thus improves the overall system security.

[0017] In one possible implementation, when a collaborative terminal node sends a registration request, the central coordinating node first verifies the validity period and signature of its certificate. If the verification is successful, the node's identifier, IP address, and performance indicators such as the number of CPU cores are recorded in the resource pool's database, forming a dynamically updated list. The purpose of this list is to provide basic data for subsequent task allocation and support the lifecycle management of nodes, such as periodically checking the online status of nodes in the list to remove failed nodes. The resulting technical effect is to achieve dynamic combination of resources and form stable virtual blockchain nodes.

[0018] Specifically, in the process of constructing the task allocation matrix, the central coordinating node constructs a matrix based on the node performance parameters in the list of collaborative terminal nodes, such as computing power and current load. The rows represent nodes and the columns represent parameters. For example, the elements of the matrix can represent the percentage of available computing resources of a node. This allows for a more intuitive quantification of the load of each node, helping the central coordinating node to identify nodes with lower loads for task allocation. The beneficial effect is to optimize resource utilization and avoid computational delays caused by overload of a single node.

[0019] In one possible implementation, assuming there are three nodes in the list, the first node has a high load of 80%, the second has a low load of 20%, and the third has a medium load of 50%, the matrix will record these values, and the central coordinating node will prioritize the second node to assign tasks. This not only improves the efficiency of parallel processing, but also ensures the balanced distribution of tasks and supports the logical formation of virtual blockchain nodes.

[0020] For example, when parsing a smart contract execution request and breaking it down into multiple subtasks, the central coordinating node assigns the subtasks to collaborative terminal nodes with lower loads for parallel processing based on the task allocation matrix. For instance, if a smart contract request involves data verification and computation, the central coordinating node breaks it down into verification subtasks and computation subtasks, and then selects appropriate nodes by referring to the matrix. This achieves distributed computing, reduces the burden on the central node, and has the beneficial effect of improving the speed and reliability of contract execution and avoiding single points of failure.

[0021] In one possible implementation, if the matrix shows that some nodes have low load, the central coordinating node will assign verification subtasks to them. These nodes process the tasks in a lightweight, secure execution environment and return the results, thus connecting to the next aggregation process and ensuring the integrity of the results.

[0022] Specifically, after processing subtasks, the collaborative terminal nodes return the calculation results to the central coordinating node. The central coordinating node then aggregates the results according to the task allocation matrix to form the contract execution output of the virtual blockchain node. For example, some results returned by the nodes are merged after being checked for consistency. This verifies the validity of the results and ensures the accuracy of contract execution. It also supports the central coordinating node in managing the lifecycle of collaborative terminal nodes and scheduling tasks, thus enabling dynamically combined virtual blockchain nodes.

[0023] S2, the central coordinating node receives smart contract execution requests, performs logical analysis on the smart contract and decomposes it into multiple parallel lightweight subtasks, and assigns them to collaborating terminal nodes according to the characteristics of the subtasks.

[0024] The central coordinating node receives smart contract execution requests and parses the smart contract's code structure through the contract management unit, identifying conditional branches and independent code blocks, and decomposing them into multiple parallelizable lightweight subtasks. For each lightweight subtask, the central coordinating node constructs a task density matrix based on its computational complexity and resource requirements, recording the computational cost and priority of each subtask. According to the task density matrix, the central coordinating node assigns the subtasks to collaborating terminal nodes, prioritizing nodes with low resource consumption to execute high-priority subtasks, ensuring load balancing during parallel execution. The collaborating terminal nodes execute the assigned tasks in a lightweight, secure execution environment and return the computation results to the central coordinating node, which verifies the consistency of the results against the task density matrix.

[0025] In one possible implementation, the central coordinating node receives smart contract execution requests and parses the code structure through the contract management unit. This parsing process involves scanning the syntax tree of the contract code, identifying independent code blocks such as if-else conditional branches or function calls, and decomposing them into multiple lightweight subtasks that can be parallelized. This improves the overall execution efficiency because the decomposed subtasks can be processed independently, avoiding the bottleneck of a single thread and benefiting the resource utilization of the distributed system.

[0026] It should be noted that for the lightweight subtasks obtained from the decomposition, the central coordinating node constructs a task density matrix based on computational complexity and resource requirements. This matrix is ​​a two-dimensional structure used to record the computational amount of each subtask, such as the number of instructions, and its priority, such as urgency. This construction helps to quantify task characteristics, provide a basis for assignment, optimize resource allocation, and avoid overloading of high-load nodes.

[0027] For example, in a contract execution scenario, if a subtask involves a complex loop and has a high computational cost, it is marked as a high value in the matrix, while another simple query is marked as a low value. The integrity of the matrix is ​​supported from multiple aspects such as complexity and priority, ensuring accurate subsequent assignment.

[0028] It should be noted that the central coordination node assigns subtasks to collaborating terminal nodes based on the task density matrix, prioritizing nodes with low resource occupancy to execute high-priority subtasks, thus ensuring load balancing during parallel execution. This assignment logic is achieved by comparing matrix values ​​and node status, which is beneficial to system stability and prevents the failure of a single node from affecting the whole system.

[0029] For example, high-priority subtasks such as real-time transaction verification are assigned to idle nodes, while low-priority tasks such as log recording are assigned to medium-load nodes. This mutual support between load balancing and priority matching achieves efficient assignment.

[0030] It should be noted that the collaborative terminal nodes execute the assigned tasks in the lightweight and secure execution environment and return the calculation results to the central coordinating node. The central coordinating node verifies the consistency of the results based on the task density matrix. This verification process compares the return results of multiple nodes with the expected results recorded in the matrix, which helps to ensure data accuracy and enhance the reliability of the system.

[0031] For example, if the matrix records the computational amount of the subtask, the verification checks whether the result matches the expected value, supporting the validity of the verification from the perspectives of consistency and security, and ultimately closely aligning with the central coordination node's goals of logical analysis, decomposition, and assignment of smart contracts.

[0032] S3, the central coordination node performs a two-stage verification process on the sub-task results returned by the collaborative terminal nodes. The two-stage verification includes sub-task result verification and convergence result verification to ensure the integrity and correctness of the calculation process.

[0033] The central coordinating node obtains the subtask computation results from the collaborating terminal nodes. Based on preset replica allocation rules, it generates multiple computation replicas for each subtask and assigns them to different collaborating terminal nodes for execution, generating a subtask replica result set. The central coordinating node performs weighted voting on the subtask replica result set, assigning weights based on the computational credibility of each collaborating terminal node to generate preliminary verification results for the subtasks. The central coordinating node compares the preliminary verification results of the subtasks with preset integrity verification rules, selecting subtask results that meet the consistency conditions to form the final verification results for the subtasks. The central coordinating node aggregates the final verification results of the subtasks, generates the final execution result of the contract according to preset contract execution logic, and submits it to the blockchain network through a standard interface for consensus processing and state storage, generating aggregated result verification data.

[0034] In one possible implementation, the process by which the central coordinating node obtains the subtask computation results from the collaborating terminal nodes involves collecting data packets returned by each node in real time. These packets contain computation outputs and metadata, such as timestamps and node identifiers, thereby ensuring the initial traceability of the results. This approach is beneficial for improving the robustness of the system because by distributing execution replicas, the overall failure caused by the failure of a single node can be reduced.

[0035] Specifically, the preset replica assignment rule refers to the replication strategy predefined according to the complexity level of the subtask. For example, three replicas are generated for high-complexity tasks and two replicas are generated for low-complexity tasks. The rule determines the number of replicas by evaluating the task input size and expected computation time. During assignment, nodes with stable historical performance are given priority for execution, thereby generating a set of subtask replica results. This helps to provide multiple sets of comparative data in subsequent verification and enhances the reliability of the results.

[0036] In one possible implementation, the process of performing weighted voting on the result set of subtask replicas involves the central coordinating node comparing the results of each replica and assigning weights based on the computational credibility of each collaborating terminal node. Here, the credibility is calculated based on a score derived from the node's past task success rate and response time. For example, a node with high credibility has a weight of 0.6, while a node with low credibility has a weight of 0.3. The preliminary verification results of the subtask are generated by calculating the weighted average or the majority consensus result. This mechanism is beneficial for filtering noisy data, ensuring that the preliminary results are closer to the true value, and laying a consistent foundation for subsequent steps.

[0037] In one possible implementation, comparing the preliminary verification results of the subtasks with preset integrity verification rules involves using a hash function to check the consistency of the results. The integrity verification rules are predefined threshold standards, such as requiring at least 80% of the replica results to match in hash value. Subtask results that meet the consistency conditions are selected to form the final verification results of the subtasks. This step helps to eliminate tampering or erroneous calculations, thereby ensuring the integrity of the verification and seamlessly connecting with the preliminary results of the previous step, providing reliable input to the aggregation stage.

[0038] In one possible implementation, the final verification results of the subtasks are aggregated according to a pre-defined contract execution logic. This logic is the aggregation rule defined in the smart contract, such as sequentially merging the sub-results to generate the overall output. Then, it is submitted to the blockchain network through a standard interface, which is a RESTful API used for data transmission. The blockchain network performs consensus processing, such as a proof-of-work mechanism, to confirm the transaction and stores the state to generate the aggregated result verification data. This process helps to achieve immutable records, ensuring the integrity and correctness of the entire two-stage verification process. Multi-node consensus further supports the accuracy of the aforementioned verification.

[0039] S4, the central coordinating node encapsulates the verified final execution result into a transaction and submits it to the target blockchain network. After consensus processing, the transaction executes a smart contract to update the on-chain state data.

[0040] The central coordinating node obtains the execution results of subtasks that have passed two-stage verification from the collaborating terminal nodes. These results include intermediate computation data and validity proofs for each subtask. The central coordinating node performs format and integrity verification on this intermediate computation data, generating a preliminary result set containing the results of all subtasks. For this preliminary result set, the central coordinating node's result aggregation unit performs combined computations on the intermediate computation data of each subtask according to the original smart contract's program logic, generating a final execution result consistent with the on-chain execution. The final execution result and its validity proof are encapsulated into a transaction, which the central coordinating node submits to the target blockchain network through a standard interface. The transaction includes the final execution result and the verification records of the subtasks. The target blockchain network performs consensus processing on the submitted transaction, verifying its legality and consistency, and then updates the on-chain state, completing an atomic state update.

[0041] For example, when obtaining the execution results of a subtask that has passed two-stage verification from the collaborative terminal node, two-stage verification means first confirming the correctness of the subtask through replica assignment and weighted voting in the subtask verification stage, and then verifying the overall consistency in the result aggregation stage. This ensures that the intermediate computation data of each subtask is reliable, avoids errors caused by the failure of a single node, and helps to improve the robustness of the entire system.

[0042] In one possible implementation, assuming a smart contract involves multiple function calls, such as transfers and balance updates, after the collaborating terminal nodes execute these subtasks, the intermediate computational data obtained by the central coordinating node includes the transfer amount and the updated balance value, as well as validity proofs such as digital signatures. The central coordinating node checks whether the data structure conforms to a predefined template through format validation and verifies integrity to prevent tampering, generating a preliminary result set. This helps the accuracy of subsequent combined calculations and supports data integrity from a security perspective.

[0043] In one possible implementation, a combined calculation is performed on the preliminary result set. According to the program logic of the original smart contract, for example, the result of the transfer subtask is added or subtracted from the result of the balance update subtask to generate the final execution result. This is consistent with on-chain execution and can bring the advantages of efficient off-chain computing, reduce the blockchain load, and support each other with the aforementioned security from the perspective of efficiency.

[0044] In one possible implementation, when the final execution result is encapsulated as a transaction, it includes a validity proof and a subtask verification record, and is submitted to the target blockchain network through a standard interface. This ensures the auditability of the transaction, benefits the trust foundation of consensus processing, and strengthens the overall process from the perspective of traceability.

[0045] In one possible implementation, the target blockchain network performs consensus processing, verifies the legality and consistency of transactions, and then updates the on-chain state. For example, in the Ethereum network, transactions are confirmed through the proof-of-work mechanism to complete atomic updates. This prevents double-spending attacks, is beneficial to the consistency and irreversibility of the state, and connects with the verification logic of previous steps from the perspective of reliability. Finally, the central coordinating node encapsulates the final execution result of the two-stage verification into a transaction and submits it to the target blockchain network for consensus confirmation and on-chain state updates.

[0046] S21, the central coordination node approves the registration request of the cooperating terminal node. The registration request includes the resource capabilities and identity information of the cooperating terminal node. The central coordination node includes the approved node into the resource pool management.

[0047] Collaborative terminal nodes generate registration requests, including hardware performance parameters, storage capacity, and identity information, and send them to the central coordinating node via a secure communication protocol. The central coordinating node receives the registration requests and stores them in a pending approval queue. The central coordinating node retrieves the registration requests from the pending approval queue, verifies the completeness and legality of the identity information, and if verification is successful, calculates the node capability score based on the hardware performance parameters and storage capacity, comparing it with a preset admission threshold. The central coordinating node marks collaborative terminal nodes with capability scores higher than the admission threshold as approved, generates a node resource description file containing the node identifier, capability score, and allocation status, and adds it to the resource pool database. Based on the node resource description files in the resource pool database, the central coordinating node periodically updates the resource pool management list and selects collaborative terminal nodes that meet the task requirements from the resource pool management list when allocating computational subtasks.

[0048] For example, the generation steps are as follows: 1. When a collaborative terminal node is about to join the system, it first collects its own hardware performance parameters, such as processor speed and memory size, as well as storage capacity and identity information. This information is packaged into a registration request and sent to the central coordinating node through a communication method using a transport layer security protocol. The central coordinating node receives the request and immediately stores it in the pending approval queue for subsequent processing. This ensures that requests are managed in an orderly manner, avoids loss or confusion, and is beneficial to the overall stability of the system.

[0049] In one possible implementation, a smartphone acts as a collaborative terminal node, generating a request containing its quad-core processor, 128GB of storage, and a digital certificate-based identity. This request is sent via an encrypted channel, and the central coordinating node receives it and stores it in a queue. This facilitates rapid response to requests from multiple nodes, forming an efficient registration process and bringing convenience to resource integration.

[0050] Specifically, if multiple nodes send requests simultaneously, the queuing mechanism allows the central coordinating node to process them in chronological order, preventing congestion, thereby improving approval efficiency and reducing problems caused by delays.

[0051] 2. The central coordinating node extracts registration requests from the pending approval queue. First, it verifies the identity information, including checking the validity period of the digital certificate and the integrity of the signature. If the verification is successful, it calculates the node capability score by weighted summation using hardware performance parameters and storage capacity. For example, it assigns a weight of 0.6 to the processor speed and 0.4 to the storage capacity, and then adds them together to obtain the score. This score is then compared with a preset admission threshold, such as 5.0. This process can filter out reliable nodes and is beneficial to the quality control of the resource pool.

[0052] In one possible implementation, a server node has hardware performance parameters that show high processor speed and a score of 7.2 after identity verification, which is higher than the threshold. This ensures that only qualified nodes are included, thus improving the reliability of system computing.

[0053] Specifically, the verification process involves comparing the public key in the certificate with known trusted sources. If they match, a score is calculated. This method supports subsequent management from a security perspective, reduces potential risks, and optimizes the accuracy of resource allocation.

[0054] 3. For collaborative terminal nodes whose capability scores are higher than the admission threshold, the central coordinating node marks them as approved and generates a node resource description file containing the node identifier, capability score and initial allocation status. Then, it adds the node to the resource pool database to achieve unified storage and management. This facilitates quick querying and updating and is beneficial for dynamic resource scheduling.

[0055] In one possible implementation, an approved node is identified by its description file record as Node-001, with a score of 7.2 and an available status. After being added to the database, it can be retrieved by the system, which helps to match efficiently during task allocation and brings about an overall performance improvement.

[0056] Specifically, the database uses structured tables to store these files, with each file serving as a record. This allows the central coordinating node to retrieve the files when needed, supporting the entire chain from registration to management and enhancing the system's scalability and responsiveness.

[0057] 4. The central coordination node updates the resource pool management list periodically, such as hourly, based on the node resource description files in the resource pool database. When allocating computing subtasks, it selects nodes whose capability scores match the task requirements. For example, it prioritizes nodes with high scores to execute complex tasks. This ensures that tasks are completed efficiently and is beneficial to load balancing in distributed computing.

[0058] In one possible implementation, after updating the list, for an image processing subtask, a node with a large storage capacity is selected from the list for allocation. This optimizes resource utilization and brings about timely and accurate execution results.

[0059] Specifically, the selection process involves scanning the list to compare task requirements with node descriptions. If a match is found, a node is assigned. This mechanism connects the aforementioned approval process with practical applications, strengthens the system's effective management of registered nodes, and ultimately supports the central coordination nodes in managing the resource pool of approved nodes.

[0060] S22, the central coordinating node performs static or dynamic analysis on the program logic of the smart contract, and decomposes the smart contract into multiple deterministic subtasks based on function boundaries, data parallelism, or control flow decomposition strategies.

[0061] The central coordinating node receives smart contract execution requests, parses the program logic of the contract code, extracts function call relationships and data dependencies, and generates a logic graph containing function boundaries and data flow. Each node in the logic graph represents a function or data operation, and edges represent calls or dependencies. Based on the logic graph, function boundaries and data parallelism opportunities are identified, and the logic graph is divided into multiple independent task units. Each task unit contains a single function or data processing logic, ensuring no state dependencies between task units, and a task decomposition table is generated. For each task unit in the task decomposition table, its control flow structure is analyzed, conditional branches and loop bodies are extracted, and deterministic computational subtasks are generated. Each subtask contains explicit input data and execution logic, stored in a subtask list. The computational subtasks in the subtask list are allocated to collaborating terminal nodes, and load balancing is performed based on node computing power and task complexity to generate a subtask allocation scheme. The subtask allocation scheme ensures that each subtask is correctly assigned, satisfying the goal of decomposing the smart contract into multiple deterministic subtasks.

[0062] For example, after receiving a smart contract execution request, the central coordinating node extracts function call relationships and data dependencies by parsing the program logic of the contract code, thereby generating a logic graph. This logic graph helps visualize the internal structure of the contract, making subsequent decomposition more efficient.

[0063] For example, in a transfer contract, the node parsing code discovers that the main function calls the verification function and the update function, and the data depends on the account balance. The resulting logic graph can clearly show these relationships, which helps to avoid dependency conflicts during decomposition and improves the overall reliability of the calculation.

[0064] In one possible implementation, function boundaries and data parallelism opportunities are identified based on the logic graph, and these are divided into independent task units to ensure statelessness and generate a task decomposition table. This division aims to improve parallel processing capabilities.

[0065] For example, in a voting contract, the logic diagram shows that vote counting and result aggregation are independent. After being divided into task units, they can be executed in parallel on different nodes, reducing bottlenecks and enhancing system throughput.

[0066] Specifically, for each task unit in the task decomposition table, the control flow structure is analyzed to extract conditional branches and loop bodies, generating deterministic computational subtasks and storing them in a list. This extraction process includes scanning the code for if-else structures and for loops to ensure that each subtask has explicit input and logic.

[0067] For example, in an auction contract, extracting the bidding check branch as a subtask helps isolate potential errors and improves the accuracy of the verification.

[0068] In one possible implementation, a list of subtasks is assigned to collaborating endpoints, with an allocation scheme generated through load balancing based on computing power and complexity. This scheme ensures fair distribution.

[0069] For example, in resource-constrained environments, high-complexity subtasks can be assigned to powerful nodes, while low-complexity subtasks can be assigned to weak nodes. This optimizes resource utilization and accelerates the overall contract execution process, which is beneficial for achieving the goal of decomposing smart contracts into multiple deterministic subtasks.

[0070] S31. During the subtask result verification phase, the central coordinating node distributes the same subtask to multiple collaborating terminal nodes for parallel execution through replica assignment, and votes on the returned results according to the weighted voting rules to determine the valid subtask result.

[0071] The central coordinating node extracts conditional branches and independent code blocks from the contract program to be executed, generating multiple computational subtasks and assigning a unique identifier to each subtask. Subtasks are stored as task description files based on their computational complexity and dependencies. The central coordinating node generates multiple copies of the same computational subtask based on the task description files and distributes them to different collaborating terminal nodes for parallel execution. Each copy is accompanied by a task identifier and a timestamp. Collaborating terminal nodes complete the computation in their local execution environment and return the subtask result. The central coordinating node collects the subtask results returned by the collaborating terminal nodes and compares the results of multiple copies with the same task identifier according to a preset weighted voting rule. Each copy result is weighted according to the computational reliability and historical execution records of the collaborating terminal node, and a weighted consistency score is calculated. Based on the weighted consistency score, the central coordinating node determines the subtask result with the highest score as the valid result. If there is a copy result with a score below a preset threshold, the returned data of the corresponding collaborating terminal node is discarded to ensure the validity of the subtask result.

[0072] For example, the process by which the central coordinating node extracts conditional branches and independent code blocks from the contract program to be executed can be understood as first scanning the program code structure to identify parts such as if-else statements or loop blocks. These parts are considered separable units, thereby generating multiple computational subtasks. This extraction helps ensure that each subtask is highly independent and reduces mutual interference. Doing so can bring the beneficial effect of improving overall computational efficiency because independent subtasks are easier to process in parallel.

[0073] In one possible implementation, when assigning a unique identifier to each subtask, a hash function is used to generate a string identifier based on the code content. This facilitates subsequent tracking and matching, and avoids confusion when returning results. Subtasks are stored as task description files based on computational complexity and dependencies. For example, complex subtasks may contain more dependency data, which is stored in JSON format. This helps with fast retrieval during subsequent dispatch, avoiding delays and thus improving system response speed.

[0074] Specifically, the process by which the central coordinating node generates multiple replicas based on the task description file involves copying the atomic task, attaching additional metadata such as task identifiers and timestamps, and distributing it to different collaborating terminal nodes. These nodes run computations in their local execution environments; for example, one node might process the conditional branch of a financial contract, calculate the interest portion, and return results including numerical values ​​and checksums. This replication mechanism enhances reliability through redundant execution because if one node fails, other replicas can still provide data, thus reducing the risk of single points of failure.

[0075] In one possible implementation, after the collaborating terminal nodes return the results of their subtasks, the central coordinating node collects these results, compares replicas with the same task identifier, and assigns weights according to a preset weighted voting rule. This weighted voting rule refers to a consensus mechanism where the weight of each replica is based on the node's computational reliability and historical execution record; for example, a reliable node has a weight of 0.8, and a node with a poor history has a weight of 0.4. Then, a weighted consistency score is calculated, with a higher score awarded if a majority of replicas are consistent. The detailed process of this rule involves first summing all replica results, multiplying each by its weight, summing the results, and then dividing by the total weight to obtain the average consistency value. This helps filter out noisy data, resulting in improved accuracy.

[0076] For example, when determining valid results based on weighted consistency scores, the highest-scoring replica is selected as valid. If some replicas score below a preset threshold, such as 0.7, the data returned by the corresponding node is discarded. For instance, in an image recognition contract, if a replica's result has a large deviation, it is discarded to ensure the validity of the final subtask result. This determination process enhances integrity through layer-by-layer verification because removing invalid data prevents malicious tampering, thus improving the overall system security.

[0077] Specifically, this mechanism is particularly useful in distributed environments, such as in blockchain networks, where multiple nodes execute the same subtask in parallel and confirm a consistent result through voting, thus avoiding the impact of a single node's error on the whole and bringing the beneficial effect of ensuring the reliability of contract execution.

[0078] In one possible implementation, the entire process from extraction to verification forms a closed loop. For example, after the extracted subtasks are distributed and voted on, the valid results are used for contract aggregation. This helps maintain stability under high load scenarios and brings the beneficial effect of optimizing resource utilization.

[0079] For example, in practical applications such as supply chain contracts, conditional branch extraction generates an inventory check subtask, copies are distributed to three nodes, and a consistent inventory value is selected as the valid result after voting, avoiding data inconsistency issues. This can bring the beneficial effect of improving the accuracy of decision-making.

[0080] S32, during the aggregation result verification phase, the central coordinating node generates a data source proof based on a Merkle tree. The proof consists of the hash values ​​of valid subtask results and is signed by the central coordinating node.

[0081] The central coordinating node obtains the hash values ​​of all subtask results from the collaborating terminal nodes, constructs the leaf nodes of the Merkle tree, and generates the root hash value of the Merkle tree through layer-by-layer hash calculation. The central coordinating node digitally signs the root hash value of the Merkle tree using its private key, generating a data provenance signature. The central coordinating node broadcasts the data provenance signature along with the root hash value of the Merkle tree to other nodes in the blockchain network. Nodes in the blockchain network verify the validity of the data provenance signature, confirm the consistency between the root hash value of the Merkle tree and the subtask results, and complete the aggregation result verification.

[0082] In one possible implementation, the central coordinating node obtains the hash value of the subtask result from the collaborating terminal node. This acquisition process ensures data integrity because the hash value is the unique fingerprint of the subtask result, which can prevent tampering.

[0083] For example, in a distributed computing scenario, suppose there are multiple collaborative terminal nodes processing an image recognition task. Each node calculates the result and generates a hash value. The central coordinating node collects these hash values ​​to construct the leaf nodes of a Merkle tree. This approach can achieve efficient verification because the Merkle tree allows for the rapid proof of the existence of specific data without transmitting all the data, thereby reducing network load and improving system security.

[0084] It should be noted that the process of generating the root hash value through layer-by-layer hashing involves pairing the hash values ​​of adjacent leaf nodes and hashing them again, repeating this operation until a single root value is obtained. This structure ensures that even if a leaf node changes, the entire root hash will change, which is beneficial for detecting any inconsistencies and thus ensuring the reliability of the convergence result.

[0085] In one possible implementation, the root hash value is digitally signed using a private key to generate proof signature data. This utilizes the principle of public-key cryptography, where the private key is held only by the central coordinating node, and any node holding the public key can verify the authenticity after signing.

[0086] For example, in blockchain transaction verification, if the root hash represents the transaction set, the signature ensures the authenticity of the source. This has the effect of preventing forgery because the signature is bound to the identity of the coordinating node, preventing malicious nodes from impersonating and submitting false proofs, thereby maintaining the trust mechanism of the entire network.

[0087] It should be noted that the process of broadcasting the proof signature data and the root hash value to other nodes in the blockchain network allows for distributed verification. Each node independently checks the validity of the signature and the consistency of the root hash, which is beneficial for achieving decentralized consensus and avoiding single points of failure.

[0088] For example, in supply chain tracking applications, verifying the origin of cargo data after node verification can improve transparency because all participants can audit the data path and ensure that the results of subtasks have not been tampered with.

[0089] For example, nodes in a blockchain network verify the validity of a signature and confirm the consistency between the root hash and the subtask result. This is done by comparing the locally computed hash with the broadcast root hash. If they match, the verification passes. This mechanism is beneficial for verifying the converged result because it detects any anomalies, such as missing or modified results, thereby ensuring the accuracy and non-repudiation of the final execution result.

[0090] In one possible implementation, the entire process from obtaining the hash value to final verification forms a closed loop, with each step supporting the others. For example, hash construction depends on the initial acquisition, signature depends on the root hash, and broadcasting and verification depend on the signature data. This approach provides overall robustness because layer-by-layer verification prevents data contamination and ensures the security and reliability of the converged results in high-risk environments such as financial transactions.

[0091] It should be noted that this combination of Merkle trees and digital signatures is particularly useful in multi-node consensus, such as in voting systems. Hash values ​​represent votes, and the root hash is signed and then broadcast for verification, which can prevent fraud because any tampering will cause the verification to fail, thus protecting the integrity of the democratic process.

[0092] S311, when the voting on the results of a subtask fails to produce a unique and valid result, the central coordination node initiates an abnormal arbitration mechanism, and the arbitration entity with a high level of trust re-executes the subtask and uses its result as the final valid result.

[0093] Collaborating terminal nodes perform weighted voting on the subtask execution results. Voting weights are dynamically calculated based on each node's hardware performance and historical task success rate, generating a preliminary voting result set. This preliminary set contains the weighted scores of all subtask results and records the identifiers of subtasks that failed to reach consensus. The central coordinating node retrieves the identifiers of the subtasks that failed to reach consensus from the preliminary voting result set, initiates an exception arbitration mechanism, and invokes a pre-defined high-trust-level arbitration entity to re-execute the subtask corresponding to the identifier, generating an arbitration execution result set. This set contains the re-executed subtask results and their corresponding digital signatures. The central coordinating node extracts the re-executed subtask results from the arbitration execution result set, replaces the corresponding invalid subtask results in the preliminary voting result set, and generates an updated voting result set. The updated voting result set is aggregated through deterministic logic to generate the final authoritative and valid result. The central coordinating node constructs a Merkle tree for the subtask results in the updated voting result set. The leaf nodes consist of the hash values ​​of each subtask result, and the root hash, digitally signed, serves as proof of data source and is submitted along with the final authoritative and valid result.

[0094] For example, in a distributed task execution environment, the cooperating terminal nodes first perform weighted voting on the execution results of subtasks. This voting mechanism ensures the reliability of the results by dynamically calculating the weight of each node. Weighted voting means quantifying the voting influence of each node based on its hardware performance, such as computing speed and storage capacity, and its historical task success rate, such as past execution accuracy. For example, if a node has a high historical success rate and powerful hardware, its voting weight will be increased accordingly. This can bring the beneficial effect of improving the overall decision-making accuracy because it prioritizes the opinions of reliable nodes and avoids low-performance nodes dominating the results.

[0095] In one possible implementation, the process of generating a preliminary voting result set involves collecting votes from all nodes and calculating a weighted score. The preliminary voting result set is a data structure that contains the cumulative score of each subtask result and identifies those subtasks whose scores have not reached the consensus threshold. In this way, the preliminary voting result set serves as the input basis for subsequent processing, which is beneficial for quickly identifying problem areas and improving system efficiency.

[0096] It should be noted that after the central coordinating node obtains the identifiers of the subtasks that failed to reach a consensus from the initial voting result set, it initiates the abnormal arbitration mechanism. This abnormal arbitration mechanism is a pre-set process that calls upon a high-trust-level arbitration entity. This entity is an authenticated independent computing unit with higher security credentials and computing power to re-execute the subtasks corresponding to the identifiers. The re-execution process includes reallocating resources and independently running the subtask logic, generating an arbitration execution result set. This result set contains the re-executed data and digital signatures. The digital signatures are encrypted using a public key to ensure immutability. The beneficial effect of doing so is to enhance the authority and tamper-proof capability of the results and prevent malicious interference.

[0097] In one possible implementation, the central coordinating node extracts the re-executed sub-task results from the arbitration execution result set and replaces the corresponding invalid parts in the initial voting result set to generate an updated voting result set. This replacement process involves matching the identifiers and updating the scores item by item to ensure data continuity and maintain the consistency of the overall results. Subsequently, the updated results are combined through deterministic logic convergence. Deterministic logic convergence refers to using fixed rules such as summation or averaging to calculate the final output and generate the final authoritative and valid result. This can bring the beneficial effect of ensuring the reproducibility of the results.

[0098] For example, the process of constructing a Merkle tree for the updated voting result set is to use the hash value of each subtask result as a leaf node, calculate the parent node hash layer by layer until the root hash. A Merkle tree is a binary tree structure used to efficiently verify data integrity. The root hash is digitally signed as proof of data source and submitted together with the final result. The beneficial effect of doing so is to provide a publicly verifiable chain of evidence, ensure that the aggregation process has not been tampered with, support third-party auditing, and improve the transparency and trustworthiness of the system.

[0099] In one possible implementation, these mechanisms support each other from multiple perspectives. For example, the reliability of weighted voting directly affects the quality of the initial result set, while the arbitration mechanism serves as a backup to supplement inconsistent parts. The update and aggregation steps integrate all inputs to form the final output, jointly ensuring the beneficial effect of obtaining an authoritative result through re-execution by a high-trust entity when voting fails to produce a unique and valid result.

[0100] S321 When the proportion of subtasks triggering abnormal arbitration exceeds the risk threshold, the central coordination node initiates the multi-coordination node consensus mechanism. Multiple central coordination nodes execute convergence operations in parallel and reach consensus through the Byzantine fault-tolerant algorithm.

[0101] The central coordinating node obtains the subtask execution status from multiple collaborating terminal nodes, calculates the proportion of abnormal arbitration subtasks, determines whether it exceeds a preset risk threshold, and generates an abnormal arbitration trigger signal. The abnormal arbitration trigger signal activates the multi-coordinating node consensus mechanism. Each central coordinating node collects the subtask results in parallel, performs a convergence operation, and generates its own convergence result set. Each central coordinating node calculates the hash value of the convergence result set and compares the hash values ​​using a Byzantine fault-tolerant consensus algorithm to reach a consensus result. The consensus result is digitally signed by the main central coordinating node, generating the final contract execution result, which is then stored in the shared ledger of the virtual blockchain nodes.

[0102] Specifically, the process by which the central coordinating node obtains the execution status of subtasks from multiple collaborating terminal nodes involves real-time monitoring of feedback data from each node. For example, in a distributed computing environment, when a smart contract is broken down into multiple subtasks, these nodes will report whether the execution is normal or whether arbitration has been triggered. This acquisition helps to identify the proportion of abnormal subtasks early, thereby ensuring system stability. The proportion of abnormal arbitration subtasks is statistically analyzed by counting the ratio of abnormal events to the total number of subtasks. An abnormal arbitration trigger signal is generated when the ratio exceeds a preset risk threshold, such as 0.3. This step serves to prevent potential risks and avoid the impact of a single node failure on the overall contract execution, thus improving the system's robustness.

[0103] In one embodiment, after the abnormal arbitration trigger signal activates the multi-coordination node consensus mechanism, each central coordination node collects the results of subtasks in parallel and performs aggregation operations. For example, assuming there are three central coordination nodes, they simultaneously pull result data from the collaborative terminal nodes and then aggregate these data into their respective aggregation result sets. This parallel approach can reduce latency and improve reliability through redundant computation. The reason is that when the risk is high, a single node may be compromised, and the participation of multiple nodes can disperse the risk and bring about a safer consensus process.

[0104] For example, the process by which each central coordinating node calculates the hash value of the converged result set includes using the SHA-256 hash function to generate a unique identifier for the result set data, and then comparing and voting on these hash values ​​using a Byzantine fault-tolerant consensus algorithm such as PBFT to reach a consistent result. Here, the Byzantine fault-tolerant consensus algorithm refers to a protocol that can tolerate a certain proportion of faulty nodes. Its principle is that nodes exchange messages and verify the majority consensus, thereby resisting malicious behavior. The beneficial effect is to ensure that even if a node fails or acts maliciously, the final result is still reliable, supporting the integrity of the system from multiple perspectives, such as preventing data tampering in high-risk scenarios.

[0105] Specifically, the consistency result is generated by the main central coordinating node through digital signature to produce the final contract execution result and store it in the shared ledger of the virtual blockchain nodes. For example, the main node uses the ECDSA signature algorithm to add a signature to the result to ensure non-repudiation, and then broadcasts the signature result to the shared ledger. The purpose of this storage method is to maintain data immutability. The reason is that the distributed nature of the blockchain can prevent single point of tampering. Beneficial effects include improved auditability and durability, and support the effectiveness of the overall mechanism from the perspective of contract traceability.

[0106] In one embodiment, the entire process, from obtaining the state to storing the result, forms a closed loop. For example, in a financial transaction contract, when the proportion of abnormal subtasks is high, multi-node consensus is triggered, which can prevent fraud and ensure the consistency of transaction results. This multi-faceted approach, such as combining monitoring and consensus, strengthens the fault tolerance of the system. Its beneficial effect is to achieve efficient distributed computing without sacrificing security.

[0107] The system architecture and components of this invention are as follows: Figure 2 As shown: The system architecture logically consists of three main parts: the collaboration layer, the coordination layer, and the consensus layer. 1. Collaborative Layer: Composed of a massive number of physically distributed collaborative terminal nodes 101; Hardware configuration: It can be any device with basic computing and communication capabilities, and its hardware resources (CPU, memory, storage) are usually limited; Software configuration: A lightweight secure execution environment (LSE) is deployed on each collaborative endpoint, which can be implemented using the following technologies: 1) WebAssembly (Wasm) Runtime: Wasm is a portable, high-performance binary instruction format with a very lightweight virtual machine (VM) and strong sandbox isolation capabilities. A central coordinating node can compile the computational logic of subtasks into Wasm modules and distribute them. 2) Lightweight container technologies: such as a slimmer version of Docker or container technologies specifically designed for edge computing, providing an isolated running space for each subtask; 3) Trusted Execution Environment (TEE) such as Software Protection Extension (SGX): When hardware supports it, LSE can run in a TEE, providing hardware-level security for the computing process and ensuring the confidentiality and integrity of code and data during execution. Core Functionality: The core function of LSE is to receive, decode, and securely execute subtasks “computation packets” from the coordination layer. After execution, it returns the results and clears all local state, ensuring statelessness and determinism.

[0108] 2. Coordination Layer: Consists of one or more central coordination nodes 102.

[0109] Hardware configuration: The central coordination node 102 is configured with the computing, storage and network resources required for functions such as contract parsing, task assignment, result verification and aggregation. For example, it can be a server, an edge computing node or a cloud instance. Software Composition: The core software consists of the following logical units: 1) Contract Management Unit (CMU): Responsible for interacting with the consensus layer and obtaining the ABI (Application Binary Interface) and bytecode of smart contracts. The CMU has a built-in contract analysis engine that can identify "hot functions" (computationally intensive) and parallelizable logic fragments in the contract through static analysis (analyzing bytecode structure and opcode sequence) and dynamic analysis (execution in a simulation environment). For example, it can identify loops that perform map or reduce operations on a large array, or multiple require checks that can be executed independently. 2) Task Assignment and Scheduling Unit (TDSU): Responsible for packaging the subtasks decomposed by CMU into standard "computation packages". A computation package typically includes: task ID, Wasm module or code snippet, input parameters (including state data read from the chain), execution timeout threshold, etc. TDSU also maintains a dynamic resource pool of cooperating terminal nodes, monitors the load, network latency, historical success rate, and other statuses of each terminal in real time, and uses optimized scheduling algorithms (such as load balancing and lowest latency priority) to select the most suitable terminal to execute the task based on this information. 3) Result Verification Unit (RVU): This is the specific executor of the two-stage verification process. Internally, it implements replica management, voting algorithms (such as weighted majority voting), arbitration triggering logic, Merkel proof generation and verification, and communication protocols for PBFT consensus with other coordinating nodes; 4) Result Aggregation Unit (RAU): Responsible for collecting all sub-task results that have passed the first phase verification, and strictly following the program logic of the original smart contract, combining and calculating these intermediate results to finally generate the final result that is completely consistent with the execution on the chain. 3. Consensus Layer: This is a foundational blockchain network. Technology selection: Any blockchain platform that supports smart contracts can be used, such as Ethereum, Hyperledger Fabric, Polkadot, etc. The method of this invention is independent of any specific blockchain platform; Core function: Provides the final trust anchor for the entire system, and it is responsible for: 1) Store the code and state of smart contracts.

[0110] 2) Through its global consensus mechanism (PoW, PoS, PBFT, etc.), it makes a final confirmation of the final computation results submitted by the coordination layer and verified in two stages.

[0111] 3) Perform state updates to permanently and immutably record the calculation results on the distributed ledger.

[0112] The two-stage result verification process in steps S3 and S4 of this invention is as follows: Figure 3 As shown; in this invention, the timing diagram of the interaction between the central coordination node and the cooperating terminal nodes is as follows. Figure 4 As shown.

[0113] The above description discloses only preferred embodiments of the present invention and should not be construed as limiting the scope of the invention. Those skilled in the art will understand that implementing all or part of the above embodiments and making equivalent changes in accordance with the claims of the present invention are still within the scope of the invention.

Claims

1. A distributed computing method for smart contracts based on virtual blockchain nodes, characterized in that, S1. A virtual blockchain node is formed by a central coordinating node and multiple collaborating terminal nodes in a dynamic combination at the logical level. The central coordinating node manages and schedules tasks for the collaborating terminal nodes. S2. The central coordination node receives smart contract execution requests, performs logical analysis on the smart contract, and decomposes it into multiple parallel subtasks. S3. The central coordination node assigns the sub-tasks to the collaborating terminal nodes for parallel processing, and verifies the validity of the calculation results through a verification process. S4. The central coordinating node encapsulates the verified final execution result into a transaction and submits it to the target blockchain network. After consensus processing, the transaction executes a smart contract to update the on-chain state data.

2. The method as described in claim 1, characterized in that, The central coordinating node and multiple collaborating terminal nodes dynamically combine at the logical level to form a virtual blockchain node, including: S11. The collaborative terminal node initiates a registration request to the central coordinating node, the registration request including resource capabilities and identity information; S12. The central coordination node approves the registration request and obtains the resource information of the approved cooperating terminal nodes; S13. The central coordination node will include the approved collaborative terminal nodes into the resource pool and monitor their status using a heartbeat detection mechanism. S14. The central coordinating node dynamically adjusts the composition of the virtual blockchain nodes based on the resource capabilities and status of the cooperating terminal nodes in the resource pool.

3. The method as described in claim 1, characterized in that, The logical analysis and decomposition of the smart contract into multiple parallel subtasks includes: S21. The central coordination node obtains the program logic of the smart contract and determines its computational logic structure through static or dynamic analysis; S22. The central coordinating node identifies independent function calls in the smart contract based on function boundaries and generates corresponding subtasks; S23. For parallel data operations, the central coordination node decomposes the loop of processing the data set into multiple subtasks that process subsets of the data. S24. The central coordination node identifies conditional branches or independent code blocks in the smart contract and generates independent subtasks; S25. The central coordination node assigns a task identifier and input parameters to each subtask, generating a dispatchable computation package.

4. The method as described in claim 1, characterized in that, The validity verification of the calculation results through the verification process includes: S31. The central coordination node generates multiple computation replicas based on the subtask results returned by the collaborating terminal nodes using replica assignment. S32. The central coordinating node collects the return results of the computation replicas and groups and votes on the results according to the weighted voting rules; S33. If the voting result meets the preset quorum threshold, the central coordination node determines that the result is a valid subtask result; S34. If the voting result does not meet the quorum threshold, the central coordination node will initiate an abnormal arbitration mechanism, and the sub-task will be re-executed by a high-trust-level entity; S35. The central coordination node generates the final execution result based on the results of the valid subtasks.

5. The method as described in claim 4, characterized in that, The grouping and voting of results according to the weighted voting rules includes: S321. The central coordinating node determines the voting weight of each node based on the historical task success rate and hardware performance of the cooperating terminal nodes. S322. The central coordination node collects the calculation results from each cooperating terminal node and groups them according to the content of the results; S323. The central coordinating node performs a weighted vote on the grouping results according to the voting weights, and obtains the result group with the highest number of votes; S324. The central coordination node determines whether the result group with the highest number of votes meets the quorum threshold and determines the valid subtask result.

6. The method as described in claim 1, characterized in that, The validity verification of the calculation results through the verification process includes: S41. The central coordination node generates a Merkle tree-based proof of data source based on the results of valid subtasks; S42. The central coordinating node digitally signs the root hash of the Merkle tree to generate verifiable proof data; S43. If the proportion of abnormal arbitrations in the first phase of subtask verification exceeds the preset threshold, the central coordination node will trigger the multi-coordination node consensus mechanism. S44. Multiple central coordinating nodes execute the convergence operation in parallel, and the convergence result is confirmed through consensus using the Byzantine fault-tolerant algorithm. S45. The central coordinating node obtains the converged result confirmed by consensus and uses it as the final execution result.

7. The method as described in claim 1, characterized in that, The process of encapsulating the verified final execution result into a transaction includes: S51. The central coordinating node encapsulates the final execution result and proof of data source into transaction data; S52. The central coordinating node submits the transaction data to the target blockchain network through a standard interface; S53. The target blockchain network performs signature verification and consensus processing on the transaction data; S54. The target blockchain network updates the on-chain state of the smart contract based on the consensus result.

Images