Block chain transaction processing method and system based on master-slave cooperation

Abstract

The invention discloses a block chain transaction processing method and system based on master-slave cooperation, and is used for solving the technical problem of low transaction execution efficiency caused by an existing block chain transaction processing method. The method comprises the following steps: a main node sends recruitment information, and each lightweight node generates a join request based on the recruitment information and sends the join request to the main node; the main node takes the lightweight node corresponding to each joining request as a slave node, performs division and key value operation on a local state tree of the block chain, and determines a plurality of non-overlapping regions and interval key values; each slave node constructs a block chain local state sub-tree based on the received non-overlapping region and the interval key value; when the master node receives multiple pieces of to-be-processed transaction data, the master node sends the multiple pieces of to-be-processed transaction data to each slave node based on a preset scheduling mode and the network delay of each slave node; and each slave node executes a transaction according to the block chain local state sub-tree corresponding to each slave node and the plurality of pieces of transaction data to be processed, and outputs a transaction result corresponding to each slave node.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain, and in particular, to a blockchain transaction processing method and system based on master-slave cooperation. Background Art

[0002] Blockchain technology is the foundation of a decentralized network, ensuring the transparency, immutability, distribution, and anonymity of the network. Through a consensus protocol, blockchain technology enables nodes that do not trust each other and are distributed around the world to reach a consensus with each other, ensuring the unique result of a transaction. Although blockchain has great development potential, mainstream blockchains such as Bitcoin and Ethereum face significant challenges in terms of scalability, and their transactions per second (TPS, Transactions Per Second) are fewer compared to traditional systems such as Visa.

[0003] The master-slave architecture is a design pattern widely used in distributed systems, and its core idea is to achieve efficient cooperation through role division. In this architecture, the master node undertakes the role of command and coordination, responsible for task allocation, global scheduling, and data integration and publication; the slave node focuses on the execution of specific tasks or local processing of data. The significant advantages of the master-slave architecture lie in its high efficiency and scalability: the master node simplifies system management through centralized control, while the parallel work of the slave nodes improves the overall throughput. This architecture is suitable for scenarios with uniform load distribution and decomposable tasks, such as master-slave synchronization of databases, cluster computing, and distributed storage. To ensure the reliability of the system, the master-slave architecture usually comes with a failover and health check mechanism, enabling the slave nodes to take over some responsibilities when the master node fails, thus achieving high availability of the system.

[0004] Most existing blockchain transaction processing methods require all nodes to store complete blockchain data or process all transactions, and transaction execution and block packaging are usually completed by the same node. This is a huge burden for nodes with limited resources, making it difficult for the system to achieve decentralization and not easy to expand, resulting in low transaction execution efficiency. Summary of the Invention

[0005] The present invention provides a blockchain transaction processing method and system based on master-slave cooperation, which is used to solve the technical problem that the existing blockchain transaction processing method leads to low transaction execution efficiency.

[0006] A blockchain transaction processing method based on master-slave cooperation provided by the first aspect of the present invention includes:

[0007] When multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node, each of the lightweight nodes generates a join request based on the recruitment information and sends it to the master node;

[0008] The master node receives a plurality of the join requests, takes the lightweight nodes corresponding to the respective join requests as slave nodes, and divides and performs key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the plurality of slave nodes, to determine non-overlapping regions and interval key values corresponding to the respective slave nodes;

[0009] Each of the slave nodes constructs a blockchain local state subtree based on the received non-overlapping regions and interval key values;

[0010] When the master node receives a plurality of transaction data to be processed, the master node sends the plurality of transaction data to the respective slave nodes based on a preset scheduling method and the network latency of the respective slave nodes;

[0011] Each of the slave nodes executes transactions according to the blockchain local state subtree corresponding to the respective slave nodes and the plurality of transaction data to be processed, and outputs transaction results corresponding to the respective slave nodes.

[0012] Optionally, the lightweight node generates a join request based on the recruitment information and sends it to the master node, including:

[0013] The lightweight node compares the network bandwidth and network latency in the recruitment information with a preset bandwidth threshold and a preset latency threshold;

[0014] If the network bandwidth is greater than the preset bandwidth threshold and the network latency is less than or equal to the preset latency threshold, the lightweight node generates a join request and sends it to the master node.

[0015] Optionally, the master node divides and performs key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the plurality of slave nodes, to determine non-overlapping regions and interval key values corresponding to the respective slave nodes, including:

[0016] The master node divides the global key space in the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the plurality of slave nodes, to determine non-overlapping regions corresponding to the respective slave nodes;

[0017] The master node performs operations on the keys in the key-value pairs in the blockchain local state tree to determine hash values corresponding to the respective slave nodes;

[0018] The master node performs interval mapping on the respective hash values to determine interval key values corresponding to the respective slave nodes.

[0019] Optionally, the preset scheduling method includes batch scheduling and streaming scheduling; when the master node receives a plurality of transaction data to be processed, the master node sends the plurality of transaction data to each slave node based on the preset scheduling method and the network latency of each slave node, including:

[0020] When the master node receives a plurality of transaction data to be processed, the master node calculates the average value of the network latency of each slave node, determines the average network latency, and compares the average network latency with a preset average threshold;

[0021] When the average network latency is greater than the preset average threshold, the master node batch-divides the plurality of transaction data to be processed based on batch scheduling and sends them to each slave node;

[0022] When the average network latency is less than or equal to the preset average threshold, the master node distributes each transaction data to be processed to each slave node in sequence based on streaming scheduling.

[0023] Optionally, after the step of each slave node executes a transaction according to the blockchain local status subtree corresponding to each slave node and the plurality of transaction data to be processed and outputs the transaction result corresponding to each slave node, it includes:

[0024] Each slave node updates the blockchain local status subtree corresponding to each slave node with the transaction result corresponding to each slave node to determine the new blockchain local status subtree corresponding to each slave node;

[0025] Each slave node calculates the root hash value corresponding to each slave node according to the transaction result corresponding to each slave node and the new blockchain local status subtree corresponding to each slave node, and sends the transaction result and the root hash value corresponding to each slave node to the master node;

[0026] The master node verifies the received plurality of transaction results based on a cross-verification method;

[0027] If the verification passes, the master node updates the blockchain local status tree with the received plurality of root hash values to determine a new blockchain local status tree;

[0028] The master node packs the plurality of transaction results to generate a block.

[0029] A blockchain transaction processing system based on master-slave cooperation provided by the second aspect of the present invention includes:

[0030] Recruitment module, which is used to generate join requests and send them to the master node based on the recruitment information when multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node;

[0031] Partition module, which is used for the master node to receive each of the join requests, take the lightweight nodes corresponding to each of the join requests as slave nodes, and partition and perform key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number of the multiple slave nodes, so as to determine non-overlapping regions and interval key values corresponding to each of the slave nodes;

[0032] Construction module, which is used for each of the slave nodes to construct a blockchain local state subtree based on the received non-overlapping regions and interval key values;

[0033] Scheduling module, which is used for the master node to send multiple pieces of to-be-processed transaction data to each of the slave nodes based on a preset scheduling method and the network latency of each of the slave nodes when the master node receives the multiple pieces of to-be-processed transaction data;

[0034] Transaction module, which is used for each of the slave nodes to execute transactions according to the blockchain local state subtree corresponding to each of the slave nodes and the multiple pieces of to-be-processed transaction data, and output transaction results corresponding to each of the slave nodes.

[0035] A blockchain transaction processing method provided in the third aspect of the present invention, which is applied to a master node in a blockchain, includes:

[0036] Sending recruitment information to multiple lightweight nodes in the blockchain and obtaining join requests sent by the multiple lightweight nodes;

[0037] Taking the lightweight nodes corresponding to each of the join requests as slave nodes, and partitioning and performing key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number of the multiple slave nodes, so as to determine non-overlapping regions and interval key values corresponding to each of the slave nodes;

[0038] When receiving multiple pieces of to-be-processed transaction data, sending the multiple pieces of to-be-processed transaction data to each of the slave nodes based on a preset scheduling method and the network latency of each of the slave nodes.

[0039] A computer device provided in the fourth aspect of the present invention includes a memory and a processor. When a computer program stored in the memory is executed by the processor, the processor is caused to execute the steps of the blockchain transaction processing method based on master-slave cooperation as described in any one of the above.

[0040] A computer-readable storage medium provided by the fifth aspect of the present invention stores a computer program, and when the computer program is executed, the steps of the blockchain transaction processing method based on master-slave cooperation as described in any one of the above are implemented.

[0041] A computer program product provided by the sixth aspect of the present invention includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer is caused to execute the steps of the blockchain transaction processing method based on master-slave cooperation as described in any one of the above.

[0042] It can be seen from the above technical solutions that the present invention has the following advantages:

[0043] The above technical solution of the present invention provides a blockchain transaction processing method based on master-slave cooperation. When multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node, each lightweight node generates a join request based on the recruitment information and sends it to the master node; the master node receives multiple join requests, takes the lightweight nodes corresponding to each join request as slave nodes, and divides and performs key-value operations on the blockchain-local state tree corresponding to the blockchain according to the total number corresponding to the multiple slave nodes to determine the non-overlapping regions and interval key values corresponding to each slave node; each slave node constructs a blockchain-local state subtree based on the received non-overlapping regions and interval key values; when the master node receives multiple to-be-processed transaction data, the master node sends the multiple to-be-processed transaction data to each slave node based on a preset scheduling method and the network latency of each slave node; each slave node executes transactions according to the blockchain-local state subtree corresponding to each slave node and the multiple to-be-processed transaction data, and outputs the transaction results corresponding to each slave node; based on the above solution, when the master node receives multiple to-be-processed transaction data, the master node sends the multiple to-be-processed transaction data to each slave node based on a preset scheduling method and the network latency of each slave node; in the process where each slave node executes transactions according to the blockchain-local state subtree corresponding to each slave node and the multiple to-be-processed transaction data and outputs the transaction results corresponding to each slave node, the present invention, through the master-slave node architecture, where the master node is responsible for transaction scheduling and the slave node is responsible for transaction execution, can avoid the performance bottleneck of a single node when processing a large number of transactions, thereby improving the transaction execution efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can also obtain other drawings without creative efforts based on these drawings.

[0045] Figure 1 It is a flowchart of steps of a blockchain transaction processing method based on master-slave cooperation provided in the first embodiment of the present invention;

[0046] Figure 2 It is an overall framework diagram of the segmentation of the blockchain local state tree (MPT, Merkle Patricia Trie) provided in the first embodiment of the present invention;

[0047] Figure 3 It is an operation flowchart of a blockchain transaction processing method based on master-slave cooperation provided in the second embodiment of the present invention;

[0048] Figure 4 It is a schematic structural diagram of the master-slave blockchain architecture design provided in the second embodiment of the present invention;

[0049] Figure 5 It is a structural block diagram of a blockchain transaction processing system based on master-slave cooperation provided in the third embodiment of the present invention;

[0050] Figure 6 It is a flowchart of steps of a blockchain transaction processing method based on master-slave cooperation applied to a master node in a blockchain provided in the fourth embodiment of the present invention. Detailed implementation manners

[0051] The embodiments of the present invention provide a blockchain transaction processing method and system based on master-slave cooperation, which are used to solve the technical problem that the existing blockchain transaction processing method leads to low transaction execution efficiency.

[0052] In order to make the objectives, features, and advantages of the present invention more obvious and understandable, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the embodiments described below are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0053] Term explanations:

[0054] Scalability: If the performance (throughput) of the entire system improves as the number of consensus nodes increases, then this system has scalability.

[0055] Sharding: A database partitioning technology applied to blockchains to improve the scalability of the network. By dividing the network and data into multiple smaller parts, each node only needs to process a part of the data.

[0056] Merkle Patricia Trie (MPT): It is an efficient data structure that combines Merkle trees and Patricia Tries, with the characteristics of hash verification and compact storage, and is used to store key-value pair data. It can be efficiently retrieved and dynamically updated in the blockchain while ensuring data integrity.

[0057] Please refer to Figure 1 , Figure 1 which is the step flowchart of a blockchain transaction processing method based on master-slave cooperation provided in the first embodiment of the present invention.

[0058] A blockchain transaction processing method based on master-slave cooperation provided by the present invention includes:

[0059] Step 101: When multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node, each lightweight node generates a join request based on the recruitment information and sends it to the master node.

[0060] Specifically, step 101 may include the following sub-steps S11 - S12:

[0061] Step S11: The lightweight node compares the network bandwidth and network latency in the recruitment information with the preset bandwidth threshold and preset latency threshold;

[0062] Step S12: If the network bandwidth is greater than the preset bandwidth threshold and the network latency is less than or equal to the preset latency threshold, the lightweight node generates a join request and sends it to the master node.

[0063] It should be noted that the establishment of the master-slave relationship in the present invention is usually achieved through smart contracts and decentralized node discovery protocols. The master node needs to publish recruitment information to attract lightweight nodes to join. Lightweight nodes that want to participate can select a suitable master node according to the recruitment information and complete the preliminary registration by sending a join request. Specifically, the recruitment information published by the master node may include: network bandwidth (used to measure the transaction scheduling ability of the master node), computing resources (CPU, GPU, etc.), current load status (the number of recruited slave nodes), average transaction processing latency (transaction confirmation time in historical records). For slave nodes, they can screen the received recruitment information, mainly based on the network bandwidth threshold for the first round of filtering (i.e., the network bandwidth of the master node must be higher than a certain preset threshold), that is, the network bandwidth is greater than the preset bandwidth threshold. In addition, the network latency between the slave node and the master node also needs to be considered (preferably choose a master node with low latency), that is, the network latency is less than or equal to the preset latency threshold. If the network bandwidth is less than or equal to the preset bandwidth threshold or the network latency is greater than the preset latency threshold, the lightweight node does not choose to join this master node.

[0064] Furthermore, once the master node confirms successful recruitment, it needs to deploy a smart contract on the chain to register the public keys and receiving addresses of the slave nodes, and at the same time pledge a certain amount of commission as the reward fund pool. The smart contract is responsible for recording the formal establishment of the master-slave relationship and ensuring the fairness of task and reward distribution. In this way, the master node can assign the transaction verification and status storage tasks to the slave nodes, and the slave nodes obtain rewards by executing tasks, achieving efficient utilization and transparent management of resources.

[0065] It is worth mentioning that the dissolution of the master-slave relationship needs to balance system stability and node rights and interests protection. The slave node can actively send an exit request through the smart contract on the chain, or be automatically removed by the master node due to network failures. After the exit request is sent, the slave node needs to complete the currently assigned tasks to ensure that the task chain is not interrupted, and the smart contract will allow it to exit after confirmation. In addition, the system should design a timeout exit mechanism. When the slave node fails to respond for a long time due to network problems, the master node can replace the node according to the rules and recruit a new node from the slave node pool to fill the vacancy. The exit of the master node needs to complete all unsettled tasks and liquidate the pledged funds to ensure that other nodes in the system are not affected. Through a reasonable exit mechanism, the blockchain system can maintain efficient operation and avoid data loss or service interruption.

[0066] Step 102: The master node receives multiple join requests, takes the lightweight nodes corresponding to the respective join requests as slave nodes, and divides and performs key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the multiple slave nodes, to determine non-overlapping regions and interval key values corresponding to the respective slave nodes.

[0067] It should be noted that, please refer to Figure 2 , the data storage in the present invention mainly focuses on the slave nodes. The master-slave architecture splits the world state of the blockchain into multiple subtrees and stores them on each slave node, reducing the storage burden on the master node. Specifically, the master node divides the MPT (Merkle Patricia Trie) into multiple subtrees, each subtree corresponding to a part of the blockchain state, and assigns them to specific slave nodes for management. This partitioning method ensures the integrity and security of the entire system state, while supporting efficient distributed transaction execution and state management. Each slave node only maintains the state of its assigned subtree, greatly reducing the resource requirements of a single node, thereby achieving efficient storage utilization and task allocation.

[0068] Specifically, step 102 may include the following sub-steps S21 - S23:

[0069] Step S21: The master node divides the global key space in the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the multiple slave nodes, to determine non-overlapping regions corresponding to the respective slave nodes;

[0070] Step S22: The master node performs calculations based on the keys in the key-value pairs in the local blockchain state tree to determine the hash values corresponding to each slave node;

[0071] Step S23: The master node performs interval mapping on each hash value to determine the interval key values corresponding to each slave node.

[0072] It should be noted that the master node divides the global key-space in the MPT into non-overlapping regions, and each region is managed by a unique slave node. During the division process, a hash function (such as SHA-256) is used to calculate the hash value of the key in the key-value pair in the MPT storage, and then the hash value is mapped to different intervals, with each interval corresponding to a slave node, thereby determining the interval key value corresponding to each slave node. For example, the key space is divided into N intervals and assigned to N slave nodes respectively.

[0073] Step 103: Each slave node constructs a local blockchain state subtree based on the received non-overlapping regions and interval key values.

[0074] It should be noted that each slave node constructs and maintains the corresponding MPT subtree (local blockchain state subtree) according to the assigned key range. These subtrees are independent of each other and only store relevant state data. The master node re-runs the splitting algorithm when a slave node joins or exits, dynamically adjusts the subtree allocation, and ensures the continuity and reliability of distributed storage.

[0075] Step 104: When the master node receives multiple transaction data to be processed, the master node sends the multiple transaction data to each slave node based on a preset scheduling method and the network latency of each slave node.

[0076] The preset scheduling methods include batch scheduling and streaming scheduling.

[0077] Specifically, Step 104 may include the following sub-steps S41 - S43:

[0078] Step S41: When the master node receives multiple transaction data to be processed, the master node calculates the average value of the network latency of each slave node, determines the average network latency, and compares the average network latency with a preset average threshold;

[0079] Step S42: When the average network latency is greater than the preset average threshold, the master node performs batch division on the multiple transaction data to be processed based on batch scheduling and sends them to each slave node;

[0080] Step S43: When the average network latency is less than or equal to the preset average threshold, the master node distributes each transaction data to be processed to each slave node in turn based on streaming scheduling.

[0081] It should be noted that the transaction scheduling in the present invention is allocated by the master node according to the MPT subtree maintained by the slave nodes to achieve efficient task management and execution. The present invention provides two transaction scheduling methods: batch scheduling and streaming scheduling. In the batch scheduling method, the master node groups transactions into a certain number of batches and distributes them to the corresponding slave nodes, that is, the master node divides multiple to-be-processed transaction data into batches to obtain multiple batches of transaction data, and then distributes them to each slave node. After a slave node completes a batch of transactions, it returns the final updated state root of its MPT subtree to the master node. The master node will only distribute the next batch of transactions after receiving the state roots of all slave nodes involved in the current batch; although this method introduces the delay of synchronous waiting, it can significantly reduce the communication overhead.

[0082] Furthermore, the streaming scheduling method is to send transactions and their related state roots to the corresponding slave nodes in real time, that is, to distribute each to-be-processed transaction data to each slave node in turn. The slave node immediately returns the updated state root after executing the transaction. This method improves the real-time performance of the system by reducing the synchronous delay, but the frequent state root updates will increase the communication cost. In actual deployment, the choice of these two methods depends on the trade-off between delay and communication overhead.

[0083] Step 105: Each slave node executes transactions according to the blockchain local state subtree corresponding to each slave node and multiple to-be-processed transaction data, and outputs the transaction results corresponding to each slave node.

[0084] It should be noted that the parallel execution of transactions is achieved by the slave nodes maintaining independent MPT subtrees. Each slave node has an independent transaction processing queue, and the transaction execution processes between the queues are parallel. It should be noted here that different from the scheme of concurrently executing transactions through multi-threads / processes on a single node, the master-slave architecture scheme, on the one hand, avoids the limitations of the performance (CPU computing power, I / O) of a single node to achieve true parallelism, and on the other hand, has more advantages in resource scheduling and isolation. Even if a slave node fails, it can be quickly restored. If resource competition, deadlock or host failure occurs in a single node, the entire system may crash, and the fault tolerance ability is weak.

[0085] Furthermore, each slave node is only responsible for processing transactions related to its subtree, and there is no overlap in the states between different subtrees, thus avoiding state conflicts and ensuring the parallel execution of transactions among slave nodes. For transactions involving multiple slave nodes, the master node coordinates the execution processes of each slave node to ensure the atomicity of the transaction. Specifically, the master node dispatches the transaction to the slave node that manages the relevant account state. Each slave node independently executes the part of the transaction that affects its local state and generates an updated state root. After collecting these partial results, the master node verifies the consistency and integrity of the execution. If all relevant slave nodes confirm that the transaction has been fully executed, the master node considers the transaction as atomically successful and includes it in the block; otherwise, the transaction is marked as incomplete, and the slave nodes that have successfully executed are instructed to roll back their corresponding account states, thus maintaining the consistency of the global state of the blockchain.

[0086] Optionally, after the step where each slave node executes transactions according to the local blockchain state subtree corresponding to each slave node and multiple pending transaction data and outputs the transaction results corresponding to each slave node, the following steps S1 - S5 are further executed:

[0087] Step S1: Each slave node updates the local blockchain state subtree corresponding to each slave node with the transaction results corresponding to each slave node, and determines the new local blockchain state subtree corresponding to each slave node;

[0088] Step S2: Each slave node calculates the root hash value corresponding to each slave node according to the transaction results corresponding to each slave node and the new local blockchain state subtree corresponding to each slave node, and sends the transaction results and root hash values corresponding to each slave node to the master node;

[0089] Step S3: The master node verifies the multiple received transaction results based on a cross - verification method;

[0090] Step S4: If the verification passes, the master node updates the local blockchain state tree with the multiple received root hash values and determines the new local blockchain state tree;

[0091] Step S5: The master node packs the multiple transaction results to generate a block.

[0092] It should be noted that after executing the transaction, the slave node updates the state of its local MPT subtree, that is, updates the local blockchain state subtree with the transaction results, and generates a root hash value based on the transaction results and the state data of the new local blockchain state subtree, and submits it to the master node.

[0093] Furthermore, although the present invention avoids the master node storing the complete MPT tree to relieve the computing and storage pressure, it also brings potential security risks. For example, a malicious slave node may claim to have successfully executed a transaction but not actually updated the local state; similarly, an attacked master node may tamper with the execution result, exclude valid transactions or include invalid transactions. To address these security risks, the invention enhances the security of cooperation between the master and slave nodes by introducing a cross-verification scheme (cross-verification method). Specifically, during the transaction execution process, the master node randomly selects multiple slave nodes to cross-verify the transaction result. Each slave node not only executes the transactions assigned to itself but also verifies the partial state update results returned by other nodes. The master node collects and compares all the verification results to ensure the consistency and authenticity of the state update. If the verification fails, the master node instructs the slave nodes that have reported successful transactions to roll back based on their corresponding state data and output the synchronized state data (i.e., output the state data at the previous moment and keep it synchronized with the data of other slave nodes that have not successfully executed the transactions). In addition, the master node can adopt a random auditing mechanism to sample and verify the historical transactions executed by the slave nodes and take punitive measures when anomalies are found. Through cross-verification, the invention effectively guards against the false execution and reporting behaviors of malicious nodes and ensures the integrity and security of the blockchain state.

[0094] For example, suppose there are slave node A and slave node B. Slave node A will receive the transaction data sent to slave node B and its own transaction data to be executed, thus generating transaction result A and transaction result B. Slave node B will receive the transaction data sent to slave node A and its own transaction data to be executed, thus generating transaction result A and transaction result B. Slave node A and slave node B will send all the transaction results to the master node. The master node will compare the transaction result A and transaction result B generated by slave node A and slave node B respectively. If the transaction result A and transaction result B output by both are the same, the verification passes; if the transaction result A and transaction result B output by both are different, the verification fails.

[0095] Furthermore, when the verification passes, the master node is responsible for integrating the root hash values of each subtree, updating the root of the global world state (i.e., updating the local state tree of the blockchain), and packing multiple transaction results to generate a block. At the same time, it coordinates the state dependencies among multiple slave nodes to ensure the consistency and atomicity of the network state. When a slave node goes offline (times out and exits) or crashes, the master node restores its subtree from other nodes and redistributes this part of the subtree to other active slave nodes. Through this dynamic management and synchronization mechanism, the invention not only significantly optimizes the resource utilization of lightweight nodes but also enhances the reliability and scalability of the system.

[0096] It is worth mentioning that the present invention ensures the fair distribution of transaction tasks among heterogeneous slave nodes through a dynamic load balancing strategy, thereby improving the overall execution efficiency. Load refers to the transaction workload assigned to each slave node. Since the computing capabilities of slave nodes vary, the system must avoid overloading low-performance nodes to maintain the efficient operation of the network. However, when the MPT tree is evenly divided into subtrees and assigned to slave nodes, the inherent differences in transaction frequencies among different accounts may lead to uneven load. In addition, the heterogeneity of slave nodes further exacerbates this imbalance, which may result in significant differences in transaction execution speeds. To address these issues, the master node dynamically evaluates the transaction distribution of each MPT subtree based on historical transaction patterns and predicts the transaction volume of each subtree. Then, in combination with the processing capabilities of the slave nodes, transactions are proportionally assigned to the corresponding slave nodes. Low-performance nodes will be assigned fewer transactions to avoid exceeding their carrying capacity. This dynamic allocation strategy not only reduces the execution latency of low-performance nodes but also reduces the tail latency of global state updates in batch transaction scheduling, thus achieving efficient load balancing and system performance optimization.

[0097] As a comparison of technical effects, it can be referred to in combination with the prior art. Single-Chain Full Node Architecture: In the single-chain full node architecture, each node participates in the transaction verification, block generation, and state maintenance of the entire blockchain. All nodes store the complete ledger data, providing a high degree of decentralized security. However, due to the large storage and computing pressure, the scalability is poor. Ethereum PBS Architecture (Proposer-Builder Separation Architecture): By separating the proposer and the block builder, it aims to improve the decentralization degree of the blockchain network while optimizing the distribution of block rewards. In this solution, the proposer is responsible for selecting the appropriate block builder, and the block builder is responsible for verifying and packing transactions. In this way, the system can reduce the single point of failure risk of the proposer and optimize the reward mechanism. Sharding Blockchain Architecture: The sharding blockchain architecture divides the entire blockchain network into multiple sub-networks (shards), and each shard processes a part of the transactions and stores data, thereby improving the scalability and throughput of the blockchain. Communication and data synchronization between different shards are crucial. Multi-Thread Architecture: The multi-thread architecture of a single node allows a single node to process transaction and block generation tasks in parallel through multiple threads. This architecture improves the processing efficiency by utilizing multi-core processors on a single node but cannot provide the decentralized characteristics of a distributed system.

[0098] The design and development directions of these blockchain architectures mainly focus on improving scalability, decentralization, and performance optimization. The sharding architecture and the single-node multi-threaded architecture improve the system's throughput through parallel processing and distributed storage, meeting the needs of large-scale transactions; the Ethereum PBS architecture optimizes resource allocation by separating the proposer from the builder, taking into account both security and efficiency; while the single-chain full-node architecture adheres to decentralization, ensuring the security of the network, but faces challenges in scalability. In the future, blockchain systems will focus on finding a better balance among security, efficiency, and resource optimization.

[0099] When faced with high-concurrency transactions, these blockchain architectures are difficult to efficiently scale. Especially when the transaction volume increases sharply, the system may face performance bottlenecks. The increase in storage and computing loads leads to a decrease in the response speed of nodes, affecting the overall system's throughput and response time. At the same time, all nodes are required to store the complete blockchain data or process all transactions, which is a huge burden for nodes with limited resources, making it difficult for the system to achieve decentralization and be easily scalable, especially in terms of storage and bandwidth consumption.

[0100] In many traditional blockchain architectures, transaction execution and block packing are usually completed by the same node, which results in low efficiency of block generation. Especially in the case of high transaction volumes, the processing capacity of nodes is easily bottlenecked. The execution and packing processes are tightly coupled, reducing the efficiency of parallel processing. Moreover, when a bottleneck occurs in a certain link, the throughput of the entire blockchain will also be affected. In addition, many blockchain architectures require all nodes to store the complete ledger and process all transactions, resulting in nodes requiring a large amount of storage, computing, and bandwidth resources. Without the support of dedicated hardware, many lightweight devices or edge nodes are difficult to participate, limiting the degree of decentralization and increasing the hardware resource pressure on the overall system.

[0101] In view of the above problems, the present invention proposes a blockchain transaction processing method based on master-slave cooperation. Through the master-slave node architecture, the master node is responsible for scheduling, and the slave nodes only process local data, reducing the computational burden of a single node. Parallel transaction processing and state management at the subtree level enable the system to better scale and handle large transaction volumes. Additionally, by assigning transaction verification and storage tasks to lightweight slave nodes and having the master node undertake the block generation task, the computational and storage pressure on each node is greatly reduced. This not only maintains decentralization but also avoids excessive resource consumption. Meanwhile, in the present invention, the master node is responsible for block packaging and transaction scheduling, while the slave nodes are responsible for transaction execution. This decoupling allows block packaging and transaction execution to be carried out independently and in parallel, improving the system's processing efficiency and avoiding the performance bottleneck of a single node when processing a large number of transactions. Furthermore, by assigning transaction execution and storage tasks to lightweight slave nodes, the master node does not need to undertake heavy computational and storage tasks, thereby reducing the high requirements for node hardware. Lightweight nodes (such as edge devices) can store only part of the ledger data and process transactions related to them, greatly reducing the demand for node hardware resources and supporting wider device participation.

[0102] Generally speaking, through the introduction of the master-slave node architecture, that is, the master node is responsible for receiving transaction requests in the network and distributing them to the slave nodes for processing. The slave nodes independently maintain the account states (subtrees based on the world state tree) they manage and execute transactions in parallel, achieving the decoupling of the efficient transaction execution and block packaging processes. At the same time, the demand for node hardware resources is reduced, thus enabling an efficient transaction execution and packaging process. By optimizing parallel transaction processing and task scheduling, resource competition among slave nodes is avoided, reducing the computational and storage pressure on nodes and enabling low-resource lightweight nodes to participate, promoting the decentralization and efficient operation of the blockchain. It can improve the transaction processing efficiency while ensuring data consistency and atomicity.

[0103] In an embodiment of the present invention, the present invention provides a blockchain transaction processing method based on master-slave cooperation. When multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node, each lightweight node generates a join request based on the recruitment information and sends it to the master node; the master node receives multiple join requests, takes the lightweight nodes corresponding to each join request as slave nodes, and divides and performs key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number of the multiple slave nodes to determine non-overlapping regions and interval key values corresponding to each slave node; each slave node constructs a blockchain local state subtree based on the received non-overlapping regions and interval key values; when the master node receives multiple transaction data to be processed, the master node sends the multiple transaction data to each slave node based on a preset scheduling method and the network latency of each slave node; each slave node executes the transaction according to the blockchain local state subtree corresponding to each slave node and the multiple transaction data to be processed, and outputs the transaction results corresponding to each slave node; based on the above solution, when the master node receives multiple transaction data to be processed, the master node sends the multiple transaction data to each slave node based on a preset scheduling method and the network latency of each slave node; in the process that each slave node executes the transaction according to the blockchain local state subtree corresponding to each slave node and the multiple transaction data to be processed and outputs the transaction results corresponding to each slave node, the present invention, through the master-slave node architecture, where the master node is responsible for transaction scheduling and the slave node is responsible for transaction execution, can avoid the performance bottleneck of a single node when processing a large number of transactions, thereby improving the transaction execution efficiency.

[0104] For better illustration, refer to Figure 3 , which shows the operation flowchart of the blockchain transaction processing method based on master-slave cooperation provided in the second embodiment of the present invention. It should be noted that this embodiment only briefly describes the general process of the blockchain transaction processing method based on master-slave cooperation. The specific implementation process of each step can be understood by referring to the relevant content in the foregoing embodiment, and will not be elaborated here. It can be understood that the present invention places no restrictions on this.

[0105] The operation process of the blockchain transaction processing method based on master-slave cooperation proposed by the present invention is roughly divided into the following 5 steps:

[0106] 1. The master node receives transactions from the network and distributes the transactions to different slave nodes for processing according to preset rules, and the transaction sets received by each slave node do not overlap.

[0107] 2. The slave node executes the assigned transactions and simultaneously maintains the MPT subtree of the corresponding account state. Each slave node only processes transactions related to its subtree, so multiple slave node transactions can be processed in parallel, improving system efficiency.

[0108] 3. If a transaction involves multiple slave nodes, the master node will distribute the transaction to all relevant slave nodes. Each slave node only processes the part related to its own account, and returns the transaction hash and the root hash of the updated MPT subtree to the master node after execution.

[0109] 4. After receiving the feedback from all slave nodes, the master node verifies the atomicity of cross-slave node transactions. If a transaction fails the atomicity verification, the master node will remove it from the candidate block and notify the relevant slave nodes to roll back the state.

[0110] 5. The master node packs all valid transactions into a new block, constructs the MPT root of the entire world state at the same time, writes it into the block header, and finally broadcasts the block to the network to complete the consensus process.

[0111] It should be noted that, please refer to Figure 4 , the present invention is a blockchain architecture designed for lightweight device nodes with low resources, aiming to attract low-resource devices to join the blockchain system to increase the overall computing power and storage of the system, and optimize resource utilization to improve system scalability. Nodes in the system are divided into two categories (as shown in Figure 4): master nodes (Master) and slave nodes (Slave). Master nodes have good network performance and are responsible for maintaining the transaction pool, distributing transactions, coordinating slave nodes to execute tasks, and packing the verified transactions into blocks. Slave nodes can be lightweight nodes with limited computing and storage capabilities, only manage a part of the global state (such as the subtree of MPT), and execute transactions related to their branches. The master node recruits slave nodes through a decentralized node discovery protocol, and the two parties establish an intelligent contract relationship to ensure transparent and trustworthy task distribution and reward allocation. By allocating tasks to slave nodes, the invention reduces the computing and storage pressure on the master node and improves the utilization rate of lightweight nodes at the same time.

[0112] Furthermore, the master-slave architecture in the present invention has significant advantages in terms of blockchain resource optimization, scalability, and system reliability. First, the master node can significantly reduce its own computing and storage burden by task distribution, and slave nodes only need to maintain the relevant state subtree to participate, reducing the hardware threshold. Second, this design supports dynamic node expansion, and the master node can recruit more slave nodes according to needs to cope with the growth of transaction volume. Third, the master-slave architecture promotes mutual cooperation among nodes to obtain benefits on the one hand, and attracts low-resource devices to participate on the other hand, expanding the on-chain computing power and storage resources. In addition, a timeout exit and task reallocation mechanism is introduced in the invention to effectively handle node failures or disconnections, enhancing the system's fault tolerance. Compared with the traditional full-node design, it is more flexible and resource-efficient, and is suitable for diverse application scenarios.

[0113] In an embodiment of the present invention, the present invention designs an efficient blockchain architecture through the cooperation of master and slave nodes. The master node and slave nodes can form a heterogeneous cluster of devices. Each cluster contains 1 master node and multiple slave nodes, and the number and device types of the slave nodes in each cluster can be different. The master node is responsible for receiving transaction data in the network and distributing it to the slave nodes for processing. The slave nodes independently maintain the account status (sub-tree based on the world state tree) they manage and execute transactions in parallel. The key objective of the system is to achieve efficient transaction processing and block generation through task allocation and cooperation. The master and slave nodes ensure the atomicity of transactions and the integrity of block generation through clear task division and verification mechanisms.

[0114] Please refer to Figure 5 , Figure 5 which is a structural block diagram of a blockchain transaction processing system provided in Embodiment 3 of the present invention.

[0115] A blockchain transaction processing system based on master-slave cooperation provided by the present invention includes:

[0116] A recruitment module 501, configured to, when multiple lightweight nodes in the blockchain receive recruitment information sent by the master node, each lightweight node generates a join request based on the recruitment information and sends it to the master node;

[0117] A partitioning module 502, configured to the master node receives each join request, takes the lightweight nodes corresponding to each join request as slave nodes, and partitions and performs key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the multiple slave nodes, to determine non-overlapping regions and interval key values corresponding to each slave node;

[0118] A construction module 503, configured to each slave node constructs a blockchain local state sub-tree based on the received non-overlapping regions and interval key values;

[0119] A scheduling module 504, configured to, when the master node receives multiple pieces of transaction data to be processed, the master node sends the multiple pieces of transaction data to each slave node based on a preset scheduling method and the network latency of each slave node;

[0120] A transaction module 505, configured to each slave node executes transactions according to the blockchain local state sub-tree corresponding to each slave node and the multiple pieces of transaction data to be processed, and outputs transaction results corresponding to each slave node.

[0121] Further, the recruitment module 501 is specifically configured to:

[0122] The lightweight node compares the network bandwidth and network latency in the recruitment information with a preset bandwidth threshold and a preset latency threshold;

[0123] If the network bandwidth is greater than the preset bandwidth threshold and the network latency is less than or equal to the preset latency threshold, the lightweight node generates an access request and sends it to the master node.

[0124] Further, the partitioning module 502 is specifically configured to:

[0125] The master node partitions the global key space in the blockchain local state tree corresponding to the blockchain according to the total number corresponding to multiple slave nodes, and determines non-overlapping regions corresponding to each slave node;

[0126] The master node performs operations on the keys in the key-value pairs in the blockchain local state tree to determine the hash values corresponding to each slave node;

[0127] The master node performs interval mapping on each hash value to determine the interval key values corresponding to each slave node.

[0128] Further, the preset scheduling methods include batch scheduling and streaming scheduling; the scheduling module 504 is specifically configured to:

[0129] When the master node receives multiple transaction data to be processed, the master node calculates the average value of the network latencies of each slave node to determine the average network latency, and compares the average network latency with the preset average threshold;

[0130] When the average network latency is greater than the preset average threshold, the master node performs batch partitioning on the multiple transaction data to be processed based on batch scheduling and sends them to each slave node;

[0131] When the average network latency is less than or equal to the preset average threshold, the master node distributes each transaction data to be processed to each slave node in sequence based on streaming scheduling.

[0132] In an alternative embodiment, the system further includes:

[0133] The first module is used for each slave node to update the blockchain local state subtree corresponding to each slave node with the transaction result corresponding to each slave node, and determine the new blockchain local state subtree corresponding to each slave node;

[0134] The second module is used for each slave node to calculate the root hash value corresponding to each slave node according to the transaction result corresponding to each slave node and the new blockchain local state subtree corresponding to each slave node, and send the transaction result and the root hash value corresponding to each slave node to the master node;

[0135] The third module is used for the master node to verify the multiple received transaction results based on a cross-verification method;

[0136] The fourth module is used for if the verification is passed, the master node updates the blockchain local state tree with the multiple received root hash values to determine the new blockchain local state tree;

[0137] The fifth module is used for the master node to package multiple transaction results to generate a block.

[0138] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the systems and modules described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0139] Please refer to Figure 6 , Figure 6 which is a step flowchart of a master-slave cooperation-based blockchain transaction processing method applied to a master node in a blockchain provided in Embodiment 4 of the present invention.

[0140] A master-slave cooperation-based blockchain transaction processing method provided by the present invention is applied to a master node in a blockchain and includes:

[0141] Step 601: Send recruitment information to multiple lightweight nodes in the blockchain and obtain join requests sent by the multiple lightweight nodes;

[0142] Step 602: Use the lightweight nodes corresponding to the respective join requests as slave nodes, and divide and perform key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the multiple slave nodes to determine non-overlapping regions and interval key values corresponding to the respective slave nodes;

[0143] Step 603: When receiving multiple to-be-processed transaction data, send the multiple to-be-processed transaction data to the respective slave nodes based on a preset scheduling method and the network latency of the respective slave nodes.

[0144] In an embodiment of the present invention, the master node sends recruitment information to multiple lightweight nodes in the blockchain and obtains join requests sent by the multiple lightweight nodes; uses the lightweight nodes corresponding to the respective join requests as slave nodes, and divides and performs key-value operations on the blockchain local state tree corresponding to the blockchain according to the total number corresponding to the multiple slave nodes to determine non-overlapping regions and interval key values corresponding to the respective slave nodes; when receiving multiple to-be-processed transaction data, send the multiple to-be-processed transaction data to the respective slave nodes based on a preset scheduling method and the network latency of the respective slave nodes. Through the master-slave node architecture of the present invention, the master node is responsible for transaction scheduling, and the slave nodes are responsible for transaction execution, which can avoid the performance bottleneck of a single node when processing a large number of transactions, thereby improving transaction execution efficiency.

[0145] An embodiment of the present invention further provides a computer device, including a memory and a processor, where a computer program is stored in the memory; when the computer program is executed by the processor, the processor is caused to execute the steps of the master-slave cooperation-based blockchain transaction processing method in any of the foregoing embodiments.

[0146] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program / instructions are stored. When the computer program / instructions are executed by a processor, the steps of the blockchain transaction processing method based on master-slave cooperation in any of the above embodiments are implemented.

[0147] An embodiment of the present invention further provides a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the blockchain transaction processing method based on master-slave cooperation in any of the above embodiments are implemented.

[0148] In several embodiments provided by the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical or other forms.

[0149] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0150] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain transaction processing method based on master-slave collaboration, characterized in that: include: When multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node, each of the lightweight nodes generates a joining request based on the recruitment information and sends it to the master node; The master node receives a plurality of the joining requests, uses a lightweight node corresponding to each joining request as a slave node, and divides and performs key value operations on the blockchain local state tree corresponding to the blockchain according to the total number of the plurality of slave nodes, and determines the non-overlapping regions and interval key values ​​corresponding to each of the slave nodes; Each of the slave nodes constructs a blockchain local state subtree based on the received non-overlapping regions and interval key values; When the master node receives a plurality of transaction data to be processed, the master node sends the plurality of transaction data to be processed to each of the slave nodes based on a preset scheduling method and a network delay of each of the slave nodes; Each of the slave nodes executes a transaction according to the local state subtree of the blockchain corresponding to each of the slave nodes and the plurality of transaction data to be processed, and outputs a transaction result corresponding to each of the slave nodes.

2. The method for processing blockchain transactions based on master-slave collaboration according to claim 1 is characterized in that: The lightweight node generates a joining request based on the recruitment information and sends the request to the master node, including: The lightweight node compares the network bandwidth and network delay in the recruitment information with a preset bandwidth threshold and a preset delay threshold; If the network bandwidth is greater than the preset bandwidth threshold and the network delay is less than or equal to the preset delay threshold, the lightweight node generates a join request and sends it to the master node.

3. The method for processing blockchain transactions based on master-slave collaboration according to claim 1 is characterized in that: The master node divides the blockchain local state tree corresponding to the blockchain and performs key value calculation according to the total number of slave nodes corresponding to the plurality of slave nodes, and determines the non-overlapping regions and interval key values ​​corresponding to each of the slave nodes, including: The master node divides the global key space in the blockchain local state tree corresponding to the blockchain according to the total number of slave nodes corresponding to the plurality of slave nodes, and determines the non-overlapping areas corresponding to the slave nodes; The master node performs operations according to the keys in the key-value pairs in the local state tree of the blockchain to determine the hash values ​​corresponding to the slave nodes; The master node performs interval mapping on each of the hash values ​​to determine the interval key value corresponding to each of the slave nodes.

4. The method for processing blockchain transactions based on master-slave collaboration according to claim 1 is characterized in that: The preset scheduling mode includes batch scheduling and streaming scheduling; when the master node receives a plurality of transaction data to be processed, the master node sends the plurality of transaction data to be processed to each slave node based on the preset scheduling mode and the network delay of each slave node, including: When the master node receives a plurality of transaction data to be processed, the master node performs an average operation on the network delays of the slave nodes, determines the average network delay, and compares the average network delay with a preset average threshold; When the network delay mean is greater than the preset mean threshold, the master node divides the plurality of transaction data to be processed into batches based on batch scheduling and sends the batches to each of the slave nodes; When the network delay mean is less than or equal to the preset mean threshold, the master node distributes each of the to-be-processed transaction data to each of the slave nodes in sequence based on streaming scheduling.

5. The method for processing blockchain transactions based on master-slave collaboration according to claim 1 is characterized in that: After each of the slave nodes executes a transaction according to the local state subtree of the blockchain corresponding to each of the slave nodes and the plurality of the transaction data to be processed, and outputs the transaction result corresponding to each of the slave nodes, the method includes: Each of the slave nodes uses the transaction result corresponding to each of the slave nodes to update the local state subtree of the blockchain corresponding to each of the slave nodes, and determines a new local state subtree of the blockchain corresponding to each of the slave nodes; Each of the slave nodes calculates the root hash value corresponding to each of the slave nodes according to the transaction result corresponding to each of the slave nodes and the new blockchain local state subtree corresponding to each of the slave nodes, and sends the transaction result and the root hash value corresponding to each of the slave nodes to the master node; The master node verifies the received multiple transaction results based on a cross-validation method; If the verification is successful, the master node updates the blockchain local state tree using the received multiple root hash values ​​to determine a new blockchain local state tree; The master node packages the multiple transaction results to generate a block.

6. A blockchain transaction processing system based on master-slave collaboration, characterized in that: include: A recruitment module, configured to generate a joining request based on the recruitment information and send it to the master node when multiple lightweight nodes in the blockchain receive the recruitment information sent by the master node; A partitioning module, used for the master node to receive each of the joining requests, use the lightweight node corresponding to each of the joining requests as a slave node, and divide the blockchain local state tree corresponding to the blockchain according to the total number of the slave nodes, and perform key value calculations, and determine the non-overlapping areas and interval key values ​​corresponding to each of the slave nodes; A construction module, configured for each of the slave nodes to construct a blockchain local state subtree based on the received non-overlapping regions and interval key values; A scheduling module, configured to, when the master node receives a plurality of transaction data to be processed, send the plurality of transaction data to be processed to each of the slave nodes based on a preset scheduling mode and a network delay of each of the slave nodes; The transaction module is used for each of the slave nodes to execute transactions according to the local state subtree of the blockchain corresponding to each of the slave nodes and the plurality of transaction data to be processed, and output the transaction results corresponding to each of the slave nodes.

7. A blockchain transaction processing method based on master-slave collaboration, characterized in that: Applied to a master node in a blockchain, the method comprises: Sending recruitment information to multiple lightweight nodes in the blockchain, and obtaining joining requests sent by multiple lightweight nodes; The lightweight node corresponding to each of the joining requests is used as a slave node, and the blockchain local state tree corresponding to the blockchain is divided and key-valued according to the total number of the slave nodes, and the non-overlapping area and interval key value corresponding to each of the slave nodes are determined; When a plurality of transaction data to be processed are received, the plurality of transaction data to be processed are sent to each of the slave nodes based on a preset scheduling method and a network delay of each of the slave nodes.

8. A computer device, characterized in that: It includes a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the blockchain transaction processing method based on master-slave collaboration as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed, it implements the blockchain transaction processing method based on master-slave collaboration as described in any one of claims 1 to 6.

10. A computer program product, characterized in that The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions, wherein when the program instructions are executed by a computer, the computer is caused to execute the blockchain transaction processing method based on master-slave collaboration as described in any one of claims 1 to 6.

Images