Block chain transaction processing method and device, electronic equipment and readable medium

Abstract

The invention provides a block chain transaction processing method and device, electronic equipment and a readable medium. The method comprises the steps of obtaining a to-be-processed block chain transaction, wherein the block chain transaction comprises transaction identification information; according to the transaction identification information of the block chain transaction, a target data partition corresponding to the block chain transaction in a node transaction pool is determined, the node transaction pool comprises a plurality of data partitions, and each data partition corresponds to one block chain node group in the block chain; if the transaction pool contains the target data partition, adding the block chain transaction into the target data partition of the transaction pool and a transaction log of the local node; and sending the transaction log to other nodes in the target block chain node group according to the target block chain node group corresponding to the target data partition, so as to add the block chain transaction into the target data partition in the transaction pool of other nodes through the transaction log. According to the method, the data consistency of the block chain nodes can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and readable medium for processing blockchain transactions. Background Art

[0002] With the development of blockchain technology, more and more organizations are choosing to build alliance chains and other methods to carry out their business. In a blockchain system, frequent data sharing is required between blockchain nodes to ensure that each blockchain node has the same data.

[0003] In related technologies, after receiving transaction data requested by a user, a blockchain node broadcasts the transaction data to other nodes in the blockchain through network communication, so that each node in the blockchain obtains the transaction data.

[0004] However, in such schemes, due to the uncertainty of network transmission, some nodes often fail to obtain transaction data in a timely manner, resulting in inconsistency with the data of other nodes in the blockchain, which in turn leads to incomplete transaction data when blocks are packaged and uploaded to the chain, affecting the transaction processing efficiency in the blockchain. Summary of the Invention

[0005] Based on the above technical problems, the present application provides a method, device, electronic device and readable medium for processing blockchain transactions to improve the data consistency of blockchain nodes.

[0006] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by practice of the present application.

[0007] According to one aspect of an embodiment of the present application, a method for processing a blockchain transaction is provided, comprising:

[0008] Obtaining a blockchain transaction to be processed, wherein the blockchain transaction includes transaction identification information;

[0009] Determining, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in a node transaction pool, wherein the node transaction pool includes multiple data partitions, each data partition corresponding to a blockchain node group in the blockchain;

[0010] If the target data partition is included in the transaction pool, the blockchain transaction is added to the target data partition of the transaction pool and the transaction log of the local node;

[0011] According to the target blockchain node group corresponding to the target data partition, the transaction log is sent to other nodes in the target blockchain node group, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0012] According to one aspect of an embodiment of the present application, a device for processing blockchain transactions is provided, including:

[0013] a transaction acquisition module configured to acquire a blockchain transaction to be processed, wherein the blockchain transaction includes transaction identification information;

[0014] a partition determination module configured to determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in a node transaction pool, wherein the node transaction pool includes a plurality of data partitions, each data partition corresponding to a blockchain node group in the blockchain;

[0015] a log update module configured to add the blockchain transaction to the target data partition of the transaction pool and to the transaction log of the local node if the target data partition is included in the transaction pool;

[0016] The log distribution module is configured to send the transaction log to other nodes in the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0017] In some embodiments of the present application, based on the above technical solution, the log distribution module is further configured to: determine the partition to be packaged according to the partition sequence of the multiple data partitions; select blockchain transactions from the partition to be packaged and add them to the transaction set to be on the chain, wherein the blockchain transactions included in the transaction set to be on the chain are obtained from the data partitions in sequence according to the partition order in the partition sequence; if the transaction set to be on the chain meets the block proposal strategy, block packaging is performed according to the blockchain transactions in the transaction set to be on the chain to obtain a block to be on the chain; broadcast the block to be on the chain to other nodes in the blockchain to chain the block to the blockchain.

[0018] In some embodiments of the present application, based on the above technical solution, the log distribution module is further configured to: if the set of transactions to be on-chain does not satisfy the block proposal strategy, then according to the partition order in the partition sequence, obtain blockchain transactions from the next data partition and add them to the set of transactions to be on-chain until the set of transactions to be on-chain satisfies the block proposal strategy.

[0019] In some embodiments of the present application, based on the above technical solution, the log distribution module is further configured to: send the block to be chained to the leader node of each blockchain node group in the blockchain, so as to add the block to be chained to the transaction log of the leader node; through the leader node of each blockchain node group, send the transaction log of the corresponding leader node to other nodes in each blockchain node group, so as to verify and vote on the block to be chained through the other nodes.

[0020] In some embodiments of the present application, based on the above technical solution, the log distribution module is further configured to: if the target data partition does not exist in the transaction pool, create the target data partition in the transaction pool; send a node expansion request to the leader node in the target blockchain node group corresponding to the target data partition to join the target blockchain node group; receive the transaction log containing the blockchain transaction sent by the leader node; and add the blockchain transaction to the target data partition according to the transaction log.

[0021] In some embodiments of the present application, based on the above technical solution, the log distribution module is further configured to: when the local node is not the leader node in the target blockchain node group, distribute the blockchain transaction to the leader node in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the transaction log of the leader node; receive the transaction log sent by the leader node; and add the blockchain transaction to the target data partition in the transaction pool of the local node according to the transaction log of the leader node.

[0022] In some embodiments of the present application, based on the above technical solution, the partition determination module is further configured to: receive a node expansion request corresponding to a newly added node; according to the node expansion request, add the node information of the newly added node to the group configuration information of the target blockchain node group; add the updated group configuration information to the transaction log; and send the transaction log to other nodes in the target blockchain node group so that the newly added node can communicate with the nodes in the target blockchain node group.

[0023] In some embodiments of the present application, based on the above technical solution, the partition determination module is also configured to: if the transaction log or status notification of the leader node in the target blockchain node group is not received within the specified time, the other nodes in the target blockchain node group are used to re-determine the leader node of the target blockchain node group; and data is synchronized with the other nodes in the target blockchain node group through the leader node.

[0024] In some embodiments of the present application, based on the above technical solution, the partition determination module is further configured to: obtain the transaction data volume of each data partition and the group load data of each blockchain node group; determine the data overload partition among the multiple data partitions based on the transaction data volume of each data partition; determine the low-load node group based on the group load data of each blockchain node group; split the data overload partition into a first partition and a second partition, wherein the first partition corresponds to the blockchain node group of the data overload partition; and establish a mapping relationship between the second partition and the low-load node group.

[0025] In some embodiments of the present application, based on the above technical solution, the transaction identification information includes a transaction serial number; the partition determination module is further configured to: determine the partition key value corresponding to the transaction serial number according to the transaction serial number of the blockchain transaction and the transaction serial number partitioning strategy, wherein the transaction serial number partitioning strategy includes a mapping relationship between the transaction serial number range and the data partition; determine the target data partition corresponding to the blockchain transaction according to the mapping relationship between the partition key value and the partition key value interval corresponding to each data partition in the transaction pool.

[0026] In some embodiments of the present application, based on the above technical solution, the transaction acquisition module is further configured to: send a transaction distribution result notification to the requester of the blockchain transaction; receive a transaction result query request for the blockchain transaction; in response to the transaction result query request, determine the transaction execution result of the blockchain transaction based on the blockchain data of the local node and the transaction data in the target data partition of the transaction pool; and send the transaction execution result to the requester of the blockchain transaction.

[0027] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the method for processing blockchain transactions as in the above technical solution by executing the executable instructions.

[0028] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for processing blockchain transactions in the above technical solution is implemented.

[0029] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain transaction processing methods provided in the various optional implementations described above.

[0030] In an embodiment of the present application, the transaction pool of the blockchain node is divided into multiple data partitions, each data partition corresponds to a blockchain node group, and the blockchain node will first determine the data partition described in the blockchain transaction, and then distribute the blockchain transaction in the blockchain node group corresponding to the data partition in the form of transaction log distribution, so that the blockchain transaction is sent to the transaction pool of each node in the blockchain node group. In this way, the blockchain transaction will only be added to one data partition and distributed only between the nodes in the corresponding blockchain node group, thereby reducing the impact of network transmission on data synchronization between nodes, improving the data consistency of blockchain nodes, ensuring the integrity of transaction data when blocks are packaged and uploaded to the chain, and thus improving transaction processing efficiency.

[0031] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0033] Figure 1 This is a system architecture for a key update solution applied to blockchain nodes according to an embodiment of the present application.

[0034] Figure 2 This is a schematic diagram of the blockchain network in an embodiment of the present application.

[0035] Figure 3 This is a schematic diagram of blocks in a blockchain network in an embodiment of the present application.

[0036] Figure 4 Flowchart of a method for processing blockchain transactions according to an embodiment of the present application.

[0037] Figure 5 Flowchart of a method for processing blockchain transactions according to an embodiment of the present application.

[0038] Figure 6 Flowchart of a method for processing blockchain transactions according to an embodiment of the present application.

[0039] Figure 7 Flowchart of a method for processing blockchain transactions according to an embodiment of the present application.

[0040] Figure 8 This is a schematic diagram of the blockchain transaction pool in an embodiment of the present application.

[0041] Figure 9 The block diagram schematically shows the composition of the blockchain transaction processing device in an embodiment of the present application.

[0042] Figure 10 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0043] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0044] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0045] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0046] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0047] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0048] It should be understood that the solution of the present application can be applied in a blockchain system, and specifically in scenarios where blockchain transactions are distributed to the transaction pool of a blockchain node. In a blockchain system, after a blockchain transaction is submitted to a blockchain node, it will be added to the node's transaction pool and await packaging and uploading to the chain. In some blockchain systems, each blockchain node will take turns packaging blocks, specifically packaging and uploading blockchain transactions based on the blockchain transactions in its local transaction pool. In such cases, the blockchain system needs to maintain data synchronization between the transaction pools of each blockchain node to ensure that blockchain transactions can be processed in a timely manner. In such scenarios, after receiving a new blockchain transaction, each blockchain node will distribute the transaction to other nodes to ensure that the transaction pool of each blockchain node in the blockchain system stores all blockchain transactions awaiting uploading to the chain.

[0049] With the development of blockchain technology, more and more organizations are choosing to build consortium chains and other methods to carry out their business. In blockchain systems, frequent data sharing is required between blockchain nodes to ensure that all nodes have the same data. In related technologies, after receiving transaction data requested by a user, a blockchain node broadcasts the transaction data to other nodes in the blockchain via network communication, ensuring that all nodes in the blockchain have access to the transaction data. However, due to the uncertainty of network transmission, this approach often results in some nodes not being able to obtain transaction data in a timely manner, resulting in inconsistencies with the data of other nodes in the blockchain. This, in turn, leads to incomplete transaction data when blocks are packaged and uploaded to the blockchain, affecting transaction processing efficiency within the blockchain.

[0050] Based on this, the technical solution of the embodiment of this application proposes a solution for processing blockchain transactions. Specifically, Figure 1As shown, the system architecture 100 for a blockchain transaction processing solution according to an embodiment of the present application may include a terminal device 110, a network 120, and a server 130. Terminal device 110 may include a smartphone, tablet computer, laptop computer, intelligent voice interaction device, smart home appliance, vehicle-mounted terminal, aircraft, and the like. Server 130 may be a server that provides various services. It may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Network 120 may be a communication medium of various connection types that can provide a communication link between terminal device 110 and server 130, such as a wired communication link or a wireless communication link.

[0051] Depending on the implementation needs, the system architecture in the embodiment of the present application can have any number of terminal devices, networks and servers. For example, the server 130 can be a server group composed of multiple server devices. In addition, the technical solution provided in the embodiment of the present application can be applied to the terminal device 110, can also be applied to the server 130, or can be implemented by the terminal device 110 and the server 130 together, and this application does not make any special restrictions on this. In the embodiment of the present application, the client software of the blockchain is running on the terminal device 110, so as to communicate with the server 130 to submit blockchain transactions to the blockchain. The server 130 distributes the blockchain transactions submitted by the terminal device 110 to the transaction pool of each node in the corresponding node group according to the solution of the present application.

[0052] Both the server 130 and the terminal device 110 can be blockchain nodes in the blockchain. Blockchain is a peer-to-peer distributed ledger composed of multiple nodes. Each node contains all transaction records, and all nodes are required to verify each transaction. Each node in the blockchain network can be a full node or a local data sub-blockchain node. A full node can connect to other nodes, while a local data sub-blockchain node refers to an independent node running in the blockchain and is not connected to other nodes. The local data sub-blockchain node does not participate in the consensus mechanism of the blockchain network like a full node, but it can independently verify transactions and create new blocks. The confidential information sent by the second node to the first node can only be decrypted by the first node to obtain the content, thereby achieving confidential communication between the two nodes.

[0053] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, a string of data blocks (i.e., blocks) generated by cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. The blockchain is maintained by the nodes in the blockchain network. For example, in Figure 2 The blockchain network shown may include multiple nodes 201, which may be the individual clients that form the blockchain network. Each node 201 may receive input information during normal operation and, based on the received input information, maintain shared data within the blockchain network. To ensure information interoperability within the blockchain network, information connections may exist between each node in the blockchain network, allowing nodes to transmit information through these connections. For example, when any node in the blockchain network receives input information, the other nodes in the blockchain network obtain the input information according to a consensus algorithm and store it as shared data, ensuring that the data stored on all nodes in the blockchain network is consistent.

[0054] Each node in a blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes so that it can subsequently broadcast generated blocks to other nodes in the blockchain network based on the node identifiers of other nodes. Each node can maintain a node identifier list, storing the node name and node identifier in the node identifier list. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0055] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 3 As shown in the figure, the blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, etc., and the block body stores the input information. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp, and difficulty value of the parent block, etc., and so on. Therefore, the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0056] The following is a detailed description of the implementation details of the technical solution of the embodiment of the present application: Figure 4A flowchart of a method for processing blockchain transactions according to an embodiment of the present application is shown. The method for processing blockchain transactions is applied to a blockchain system and can be executed by a device with computing and processing functions, such as a server or terminal device where a consensus node is located. Figure 4 As shown, the blockchain transaction processing method includes at least steps S410 to S440, which are described in detail as follows:

[0057] Step S410: Obtain a blockchain transaction to be processed, where the blockchain transaction includes transaction identification information.

[0058] In this embodiment, a blockchain node obtains blockchain transactions submitted by the client. These transactions are typically newly submitted to the blockchain, meaning they have not yet been uploaded to the blockchain or distributed to other nodes in the blockchain. Typically, upon receiving a blockchain transaction, the blockchain node performs preliminary verification. This involves verifying the validity and integrity of the blockchain transaction based on the blockchain data in the local node's local ledger. This typically involves verifying the signature and timestamp.

[0059] Step S420: Determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in the node transaction pool, wherein the node transaction pool includes multiple data partitions, and each data partition corresponds to a blockchain node group in the blockchain.

[0060] A blockchain node needs to distribute the blockchain transaction to other blockchain nodes. To do this, the blockchain node uses the transaction identification information of the blockchain transaction to determine the target data partition corresponding to the blockchain transaction. In this embodiment, the local node's transaction pool contains multiple data partitions, each corresponding to a different range of transaction identification information values. The blockchain node can directly determine the target data partition corresponding to the blockchain transaction based on the range of the transaction identification information. Each data partition corresponds to a blockchain node group. A blockchain node group is composed of multiple nodes in the blockchain and is typically a subset of the total number of nodes in the blockchain. The value ranges of transaction identification information corresponding to different data partitions generally do not overlap, ensuring that a blockchain transaction is mapped to only one data partition. However, the blockchain node groups corresponding to different data partitions may overlap, but they are generally not identical. For example, blockchain node group A for data partition A may include nodes 1, 2, and 3, while blockchain node group B for data partition B may include nodes 2, 3, and 4. It can be understood that in this example, the transaction pools of node 2 and node 3 both contain data partition A and data partition B, while the transaction pool of node 1 only contains data partition A, and the transaction pool of node 4 only contains data partition B.

[0061] Step S430: If the target data partition is included in the transaction pool, the blockchain transaction is added to the target data partition of the transaction pool and the transaction log of the local node.

[0062] If the target data partition is included in the local node's transaction pool, it indicates that the local node is a member of the target blockchain node group. Therefore, the blockchain transaction can be added to the local node's transaction log. Specifically, in this embodiment, the local node is in the target blockchain node group corresponding to the target data partition and is the node responsible for data updates within that group. In this application, the transaction log is a file maintained by the blockchain node, containing a series of actions executed by the blockchain node in a certain order. The log consists of sequentially numbered log entries, which include the action of adding the blockchain transaction to the transaction pool.

[0063] Step S440: Send the transaction log to other nodes in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0064] The blockchain node will send the transaction log to the other nodes in the target blockchain node group corresponding to the target data partition. Nodes in the blockchain that are not members of the target blockchain node group will not receive the transaction log. Based on the content in the transaction log, the other nodes in the target blockchain node group will add the blockchain transaction to the target data partition in their local transaction pools. The target data partition will be included in the transaction pools of all nodes in the target blockchain node group. After the transaction log is distributed, all nodes will contain the blockchain transaction, thus completing the blockchain transaction distribution process.

[0065] In an embodiment of the present application, the transaction pool of the blockchain node is divided into multiple data partitions, each data partition corresponds to a blockchain node group, and the blockchain node will first determine the data partition described in the blockchain transaction, and then distribute the blockchain transaction in the blockchain node group corresponding to the data partition in the form of transaction log distribution, so that the blockchain transaction is sent to the transaction pool of each node in the blockchain node group. In this way, the blockchain transaction will only be added to one data partition and distributed only between the nodes in the corresponding blockchain node group, thereby reducing the impact of network transmission on data synchronization between nodes, improving the data consistency of nodes in the blockchain node group, ensuring the integrity of transaction data when blocks are packaged and uploaded to the chain, and thus improving transaction processing efficiency.

[0066] In some optional embodiments of the present application, based on other technical solutions of the present application, a blockchain node may also receive a node expansion request corresponding to a newly added node. Based on the node expansion request, the node information of the newly added node is added to the group configuration information of the target blockchain node group. The updated group configuration information is then added to the transaction log. Finally, the transaction log is sent to other nodes in the target blockchain node group to enable the newly added node to communicate with the nodes in the target blockchain node group. In the solution of the present application, when a new node wishes to join a blockchain node group, it initiates an expansion request to the leader node in the blockchain node group. Upon receiving the node expansion request from the newly added node, the leader node adds the node information of the newly added node to the group configuration information of the target blockchain node group. Group configuration information is information used to describe the communication configuration and node configuration between the nodes in the target blockchain node group. The updated group configuration information is added to the transaction log. The leader node distributes the transaction date to the other nodes in the target blockchain node group. After receiving the transaction log, the other nodes also update their configured group configuration information based on the transaction log, enabling the newly added node to communicate with all nodes in the target blockchain node group and participate in data synchronization between nodes. In this embodiment, the newly added node is added to the target blockchain node group via the transaction log, allowing the number of nodes and node configuration in the target blockchain node group to be directly adjusted during blockchain operation. This allows for online splitting and reorganization of node groups, which improves the flexibility of the node grouping scheme.

[0067] In some optional embodiments of the present application, based on other technical solutions of the present application, if a transaction log or status notification from the leader node in the target blockchain node group is not received within a specified time, the blockchain node will communicate with other nodes in the target blockchain node group to re-determine the leader node of the target blockchain node group. The leader node will then synchronize data with the other nodes in the target blockchain node group. In this embodiment, if a transaction log or status notification from the leader node in the target blockchain node group is not received within the specified time, it indicates that the leader node may have failed. In this case, the local node communicates with the other nodes in the target blockchain node group to elect a new leader node. Specifically, during the election process, nodes in the target blockchain node group will declare themselves candidate nodes. Voting will then be conducted based on the candidate node's status. If a candidate node receives votes from a majority of nodes within the predetermined election time, it will become the new leader node. The new leader node will synchronize data with the other nodes in the target blockchain node group to ensure that the data status of all nodes is consistent. This synchronization process is still carried out in the form of transaction logs. In this embodiment, when it is determined that a fault occurs in the target blockchain node group, a leader node is re-elected, so that the fault can be eliminated and recovered in a timely manner, which is conducive to improving the stability of the solution.

[0068] In some optional embodiments of the present application, based on other technical solutions of the present application, the blockchain node also obtains the transaction data volume of each data partition and the group load data of each blockchain node group. Then, based on the transaction data volume of each data partition, it determines the data overload partition among the multiple data partitions, and based on the group load data of each blockchain node group, it determines the low-load node group. Subsequently, the blockchain node splits the data overload partition into a first partition and a second partition, wherein the first partition corresponds to the blockchain node group of the data overload partition, and establishes a mapping relationship between the second partition and the low-load node group. In this embodiment, when a data overload partition and a low-load node group appear, the blockchain node splits the data overload partition into two partitions, one of which still corresponds to the original node group, and the other partition corresponds to the low-load node group. The low-load node group can be obtained by combining nodes from one or more blockchain node groups. For example, a portion of nodes can be selected from each of multiple blockchain node groups whose load data is below a threshold to form a low-load node group. It is understood that once the mapping relationship between the low-load node group and the second partition is established, a corresponding second partition will be created in the transaction pool of the nodes in the low-load node group, and the data for the second partition will be obtained from the transaction pool of the original blockchain node group corresponding to the first partition. For nodes in the blockchain node group corresponding to the first partition, if they are not added to the low-load node group, the relevant data of the second partition will be deleted from the transaction pool, thereby reducing the data load of their group. In this embodiment, by splitting the data partitions, the load of each data partition and the corresponding node group is more balanced, avoiding excessive data concentration that may cause a decrease in node processing efficiency, which is conducive to improving the transaction processing efficiency of the blockchain.

[0069] In some optional embodiments of the present application, based on other technical solutions of the present application, the transaction identification information includes a transaction sequence number. In the process of determining the target data partition corresponding to the blockchain transaction based on the transaction identification information of the blockchain transaction, the blockchain node determines the partition key corresponding to the transaction sequence number based on the transaction sequence number and the transaction sequence number partitioning strategy. The transaction sequence number partitioning strategy includes a mapping relationship between transaction sequence number ranges and data partitions. The target data partition corresponding to the blockchain transaction is then determined based on the mapping relationship between the partition key value and the partition key value interval corresponding to each data partition in the transaction pool. In the solution of the present application, the partition key value is calculated based on the transaction sequence number, and each data partition corresponds to a partition key value interval, thereby determining the target data partition corresponding to the blockchain transaction. The transaction sequence number partitioning strategy can specifically include, for example, taking the modulus of the transaction sequence number, directly setting the modulus as the number of partitions, or determining the corresponding partition based on a keyword in the transaction sequence number. This embodiment provides a specific method for determining the data partition to which a transaction belongs, which helps improve the operability of the solution.

[0070] In some optional embodiments of the present application, based on other technical solutions of the present application, after sending the transaction log to other nodes in the target blockchain node group, the blockchain node also sends a transaction distribution result notification to the requester of the blockchain transaction. Subsequently, the blockchain node receives a transaction result query request for the blockchain transaction. In response to the transaction result query request, the blockchain node determines the transaction execution result of the blockchain transaction based on the blockchain data of the local node and the transaction data in the target data partition of the transaction pool, and sends the transaction execution result to the requester of the blockchain transaction. In this solution of the present application, after adding a blockchain transaction to the transaction pool, the result of adding the blockchain transaction to the transaction pool is first fed back to the user. In this case, the transaction can be executed asynchronously, and the user does not need to wait synchronously for the execution result. After execution is completed, the transaction execution result of the blockchain transaction is provided to the user based on the user's query request. Asynchronous transaction execution eliminates the need to maintain communication between the blockchain node and the user client, avoiding the use of communication resources during the waiting time for transaction execution, which helps improve node communication efficiency.

[0071] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 5 As shown, in a method for processing blockchain transactions in one embodiment of the present application, the solution of the present application may include the following steps:

[0072] Step S510: Obtain a blockchain transaction to be processed, where the blockchain transaction includes transaction identification information.

[0073] Optionally, the implementation details of step S510 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0074] Step S520: Determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in the node transaction pool, wherein the node transaction pool includes multiple data partitions, each data partition corresponding to a blockchain node group in the blockchain.

[0075] Optionally, the implementation details of step S520 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0076] Step S530: If the target data partition is included in the transaction pool, the blockchain transaction is added to the target data partition of the transaction pool and the transaction log of the local node.

[0077] Optionally, the implementation details of step S530 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0078] Step S540: Send the transaction log to other nodes in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0079] Optionally, the implementation details of step S540 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0080] Step S550, determining a partition to be packaged according to the partition sequence of the multiple data partitions;

[0081] Step S560: Select blockchain transactions from the partition to be packaged and add them to the set of transactions to be uploaded to the chain, wherein the blockchain transactions included in the set of transactions to be uploaded to the chain are obtained from the data partitions in order of the partitions in the partition sequence;

[0082] Step S570: If the transaction set to be on-chain meets the block proposal strategy, block packaging is performed according to the blockchain transactions in the transaction set to be on-chain to obtain a block to be on-chain;

[0083] Step S580: broadcast the block to be chained to other nodes in the blockchain to chain the block to be chained in the blockchain.

[0084] In this embodiment, the local node is responsible for packaging transactions in the transaction pool. Specifically, the node contains a partition sequence for multiple data partitions in the transaction pool. This partition sequence indicates the order in which the data partitions will be processed during packaging. The partition to be packaged can be a partition of a specified order within the partition sequence, such as the first partition in the sequence. The node retrieves blockchain transactions from the identified partition to be packaged and adds them to the set of transactions to be uploaded. The set of transactions to be uploaded is used to archive transactions to be uploaded. Transactions are retrieved from the data partitions in the order of the partition sequence. For example, for a sequence of three partitions, when processing the third partition, the set of transactions to be uploaded will include blockchain transactions from the first and / or second partitions. The node continuously polls each partition in the order of the partition sequence and retrieves blockchain transactions from each partition and adds them to the set of transactions to be uploaded until the set of transactions to be uploaded meets the block proposal policy. Subsequently, the blockchain node packages the blockchain transactions in the set of transactions to be uploaded, obtaining a block to be uploaded, and broadcasts the block to other nodes in the blockchain to be uploaded. In this embodiment, the blockchain transactions to be packaged are obtained from the data partitions in sequence according to the partition order in the partition sequence, so that the transactions in each data partition can be processed evenly, avoiding timeout due to a long waiting time for a single transaction, and improving the stability of transaction processing.

[0085] In an embodiment of the present application, the transaction pool of the blockchain node is divided into multiple data partitions, each data partition corresponds to a blockchain node group, and the blockchain node will first determine the data partition described in the blockchain transaction, and then distribute the blockchain transaction in the blockchain node group corresponding to the data partition in the form of transaction log distribution, so that the blockchain transaction is sent to the transaction pool of each node in the blockchain node group. In this way, the blockchain transaction will only be added to one data partition and distributed only between the nodes in the corresponding blockchain node group, thereby reducing the impact of network transmission on data synchronization between nodes, improving the data consistency of nodes in the blockchain node group, ensuring the integrity of transaction data when blocks are packaged and uploaded to the chain, and thus improving transaction processing efficiency.

[0086] In some optional embodiments of the present application, based on other technical solutions of the present application, if the set of transactions to be on-chain does not satisfy the block proposal strategy, the blockchain node will obtain blockchain transactions from the next data partition according to the partition order in the partition sequence and add them to the set of transactions to be on-chain until the set of transactions to be on-chain satisfies the block proposal strategy. If the proposal strategy is not satisfied, transactions are obtained from each data partition in sequence, thereby providing each partition with equal opportunities to be on-chain, avoiding inconsistent transaction processing efficiency between data partitions and resulting in long transaction waiting times, which is conducive to improving transaction processing efficiency.

[0087] In some optional embodiments of the present application, based on other technical solutions of the present application, in the process of broadcasting the block to be chained to other nodes in the blockchain, the blockchain node sends the block to be chained to the leader node of each blockchain node group in the blockchain to add the block to be chained to the transaction log of the leader node, and then sends the transaction log of the corresponding leader node to other nodes in each blockchain node group through the leader node of each blockchain node group, so that the block to be chained can be verified and voted by the other nodes. In the process of consensus, the proposal node will send the block to be chained to the leader node of each blockchain node group, and then the leader node will distribute the block to be chained to the nodes in their respective blockchain node groups to verify and vote on the block to be chained, so as to ensure that the block to be chained is distributed to each blockchain node, avoid the problem of inconsistent data arrival caused by large-scale broadcasting, and help improve the efficiency of block chaining.

[0088] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 6 As shown, in a method for processing blockchain transactions in one embodiment of the present application, the solution of the present application may include the following steps:

[0089] Step S610: creating the target data partition in the transaction pool;

[0090] Step S620: Send a node expansion request to the leader node in the target blockchain node group corresponding to the target data partition, so as to join the target blockchain node group;

[0091] Step S630: receiving a transaction log containing the blockchain transaction sent by the leader node;

[0092] Step S640: Add the blockchain transaction to the target data partition according to the transaction log.

[0093] In this embodiment, when a local node is assigned as a new node to a target blockchain node group, it is necessary to initialize the local transaction pool. Specifically, the node creates a target data partition in the transaction pool and then sends a node expansion request to the leader node in the target blockchain node group corresponding to the target data partition, in order to join the target blockchain node group. Subsequently, the node receives the transaction log issued by the leader node in the target blockchain node group and, based on the transaction log, adds blockchain transactions to the target data partition. In this embodiment, before joining the target blockchain node group, the node proactively creates the target data partition and joins the corresponding target blockchain node group based on the assigned data partition of the blockchain. This allows the node to automatically join the node group according to the configuration without manual configuration modification, reducing the difficulty and cost of blockchain node maintenance.

[0094] Step S650: Obtain a blockchain transaction to be processed, where the blockchain transaction includes transaction identification information.

[0095] Optionally, the implementation details of step S650 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0096] Step S660: Determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in the node transaction pool, wherein the node transaction pool contains multiple data partitions, each data partition corresponding to a blockchain node group in the blockchain.

[0097] Optionally, the implementation details of step S660 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0098] Step S670: If the target data partition is included in the transaction pool, the blockchain transaction is added to the target data partition of the transaction pool and the transaction log of the local node.

[0099] Optionally, the implementation details of step S670 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0100] Step S680: Send the transaction log to other nodes in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0101] Optionally, the implementation details of step S680 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0102] In an embodiment of the present application, the transaction pool of the blockchain node is divided into multiple data partitions, each data partition corresponds to a blockchain node group, and the blockchain node will first determine the data partition described in the blockchain transaction, and then distribute the blockchain transaction in the blockchain node group corresponding to the data partition in the form of transaction log distribution, so that the blockchain transaction is sent to the transaction pool of each node in the blockchain node group. In this way, the blockchain transaction will only be added to one data partition and distributed only between the nodes in the corresponding blockchain node group, thereby reducing the impact of network transmission on data synchronization between nodes, improving the data consistency of nodes in the blockchain node group, ensuring the integrity of transaction data when blocks are packaged and uploaded to the chain, and thus improving transaction processing efficiency.

[0103] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 7 As shown, in a method for processing blockchain transactions in one embodiment of the present application, the solution of the present application may include the following steps:

[0104] Step S710: Obtain a blockchain transaction to be processed, where the blockchain transaction includes transaction identification information.

[0105] Optionally, the implementation details of step S710 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0106] Step S720: Determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in the node transaction pool, wherein the node transaction pool includes multiple data partitions, and each data partition corresponds to a blockchain node group in the blockchain.

[0107] Optionally, the implementation details of step S720 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0108] The blockchain node checks whether the local node is the leader node in the target blockchain node group. If so, it executes step S730. If not, it executes step S750.

[0109] Step S730: Add the blockchain transaction to the target data partition of the transaction pool and the transaction log of the local node.

[0110] Optionally, the implementation details of step S730 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0111] Step S740: Send the transaction log to other nodes in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0112] Optionally, the implementation details of step S740 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0113] Step S750: Distribute the blockchain transaction to a leader node in the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to a transaction log of the leader node;

[0114] Step S760: receiving the transaction log sent by the leader node;

[0115] Step S770: Add the blockchain transaction to the target data partition in the transaction pool of the local node according to the transaction log of the leader node.

[0116] In this embodiment, if the local node is not the leader node in the target blockchain node group, the local node will not distribute the blockchain transaction. Instead, it will distribute the blockchain transaction to the leader node in the target blockchain node group corresponding to the target data partition. The leader node will distribute the blockchain transaction to the local node via the transaction log according to the method described in the above embodiment. The local node will then execute the actions recorded by the leader node in the transaction log based on the leader node's transaction log, thereby adding the blockchain transaction to the target data partition in the local node's transaction pool. If the local node is not the leader node, the blockchain transaction is distributed to the leader node in the target blockchain node group to trigger the transaction distribution in the target blockchain node group. This ensures that only the leader node in the node group conducts broadcast communications. Compared to each node broadcasting individually, this can reduce the number of broadcast messages in the blockchain network, reduce network communication pressure, and improve communication efficiency.

[0117] In an embodiment of the present application, the transaction pool of the blockchain node is divided into multiple data partitions, each data partition corresponds to a blockchain node group, and the blockchain node will first determine the data partition described in the blockchain transaction, and then distribute the blockchain transaction in the blockchain node group corresponding to the data partition in the form of transaction log distribution, so that the blockchain transaction is sent to the transaction pool of each node in the blockchain node group. In this way, the blockchain transaction will only be added to one data partition and distributed only between the nodes in the corresponding blockchain node group, thereby reducing the impact of network transmission on data synchronization between nodes, improving the data consistency of nodes in the blockchain node group, ensuring the integrity of transaction data when blocks are packaged and uploaded to the chain, and thus improving transaction processing efficiency.

[0118] See also Figure 8 , Figure 8 This is a schematic diagram of the blockchain transaction pool in an embodiment of the present application. Figure 8Figure 4 shows four blockchain nodes in a blockchain. Each blockchain node's transaction pool contains a certain number of data partitions. For a particular data partition, the nodes containing that data partition constitute the blockchain node group for that data partition. For example, for data partition 1, its blockchain node group includes nodes 1, 2, and 3. Each transaction in the blockchain is represented by a transaction key, and each data partition corresponds to a different key range. Blockchain transactions are determined to which data partition they belong based on their transaction key and then distributed to the transaction pools of each node based on the blockchain node group corresponding to the data partition. In this embodiment, each blockchain node includes a transaction distribution module, a partition management module, and a storage module. The transaction distribution module processes transactions submitted by clients and routes them to the corresponding blockchain node group based on the transaction key range. Specifically, the transaction distribution module includes a transaction receiving submodule, which performs preliminary processing of transaction requests received from the client module. For each transaction, the submodule verifies the validity and integrity of the transaction, including signature verification and timestamp verification. The transaction classification submodule is responsible for classifying the received valid transactions so that they can be matched to the appropriate blockchain node group. This process is usually completed through the mapping relationship between key value ranges and data partitions. The submodule determines which blockchain node group the transaction should be distributed to by querying the key value range of the data partition. The transaction distribution submodule routes the valid transactions to the corresponding blockchain node group based on the classification results. This submodule is responsible for sending the transaction to the leader node of the target blockchain node group. The transaction tracking submodule is responsible for maintaining the status of sent transactions. For each sent transaction, this submodule tracks its processing status, including whether it has been successfully executed and whether it has been confirmed by the consensus system. This submodule is also responsible for handling failed or timed-out transactions, such as resubmitting or returning failure information to the user. The region mapping submodule is responsible for maintaining the mapping relationship between data partitions and key value ranges. This submodule handles the addition, deletion and load balancing of data partitions, and records how key value ranges are mapped to different blockchain node groups in the entire system. This submodule needs to work closely with the partition management module to ensure that the data partition map can be updated in real time during load balancing and failover.

[0119] The partition management module is responsible for data synchronization, consistency, load balancing, and fault recovery among blockchain node groups. The partition management module consists of a data partition management submodule, a data partition splitting submodule, a load balancing submodule, a fault recovery submodule, an election and membership change submodule, and a data synchronization submodule. The data partition management submodule maintains data partition information for the entire system. Data partitions logically divide data into distinct key value ranges, thereby distinguishing the blockchain node group to which the data belongs. This submodule manages and updates available data partitions across the system for addition, deletion, and load balancing operations. The data partition splitting submodule is responsible for splitting data partitions when data volume is excessive or load is unbalanced. This submodule further divides key value ranges and redistributes them to achieve data load balancing. The load balancing submodule monitors the load of each blockchain node group and takes appropriate action if load imbalance occurs. This submodule determines how to redistribute data partitions based on node performance metrics, disk usage, and other factors. Furthermore, the load balancing submodule is responsible for detecting and recovering from failed nodes. The fault recovery submodule is responsible for adjusting data partition allocation after detecting a node failure to restore normal service as quickly as possible. It also performs membership changes to ensure cluster availability and data consistency. The election and membership change submodule is responsible for maintaining and managing the election of leader nodes within blockchain node groups and controlling membership changes. Leader node election and membership change operations are triggered in scenarios such as fault recovery and load balancing. The data synchronization submodule is responsible for synchronizing blockchain data between different blockchain node groups. This submodule synchronizes data based on a log replication process to ensure data consistency across nodes.

[0120] The storage module is responsible for implementing persistent storage and version control for consortium chain transaction pool data. It includes a database, a transaction data receiving submodule, a transaction data query submodule, and a transaction data deletion submodule. The database is typically a high-performance key-value database. The transaction data receiving submodule processes consensus-reached transaction data sent by blockchain node groups. Upon receiving transaction data, it writes the data to the database. The transaction data query submodule provides client-side query functionality, including querying individual transactions, querying transaction ranges, and querying specific transaction attributes. This submodule reads data directly from the database storage and returns it to the client. The transaction data deletion submodule is responsible for deleting expired transaction data from the database storage.

[0121] In the embodiment of the present application, the processing flow mainly includes transaction processing flow, data synchronization flow, capacity expansion flow, transaction routing flow, fault recovery flow, transaction partitioning implementation flow and proposal node packaging block flow.

[0122] Transaction processing is primarily categorized as synchronous and asynchronous. In synchronous transactions, users submit synchronous transaction requests to the system through a client or application programming interface (API). After the system verifies the transaction, it is executed. The execution module waits for the transaction to complete and obtains the execution result. This result is then sent to the user, who can then determine whether the transaction was successfully executed. The main difference with asynchronous transactions is that after a node adds a transaction to the transaction pool, it provides feedback to the user confirming the successful addition. Users can then request a query for the transaction execution result, and the blockchain node will then provide feedback.

[0123] The data synchronization process primarily maintains node data consistency. First, a leader node election occurs within a blockchain node group. Each node in the group becomes a candidate or votes based on a predetermined election strategy to select a leader node. The leader node processes client requests and creates and maintains a transaction log. At any given time, the system has only one leader node, ensuring consistent data processing and sharing. When the leader node receives a transaction request from a client, it adds the transaction to its log. The leader node then sends the log information to all other nodes in the blockchain node group (follower nodes). Follower nodes replicate the leader node's log in the specified log order. This ensures that each node stores the same transaction log, ensuring consistency across multiple replicas. Once the leader node sends a log entry to a majority of follower nodes and receives a confirmation response from the majority, it considers the entry successfully committed. The leader node then applies the committed log entry to the state machine and returns a response to the client. Simultaneously, the leader node notifies followers to apply the committed log entry, ensuring consistent state across multiple replicas. If the leader node fails or goes offline, a new leader node is elected through leader node elections. The new leader node must first synchronize with the lagging nodes to ensure that the logs of all nodes are consistent before it can process new client requests. This ensures that the system still has strong data consistency and high availability during node failure or offline.

[0124] The expansion process is executed when a new node joins a blockchain node group. When a new node joins a blockchain node group, it initiates an expansion request. This request is typically initiated by an administrator or a node with a specific role. The leader node is responsible for processing the expansion request. Upon receiving the expansion request, the current leader node processes it. First, the leader node verifies that the request complies with the consortium chain's security policy and joining rules. The leader node then adds the new node's information to the updated cluster configuration and writes this change to the log. The leader node sends the updated cluster configuration to other follower nodes as a log entry. Once a majority of nodes confirm receipt of the update, the leader node commits the log entry. Once committed, the leader node updates the configuration of all nodes in the cluster. Before a new node officially joins the cluster, it must synchronize data with the leader node to ensure that it has access to the complete consortium chain transaction pool. The leader node sends a log snapshot and all uncommitted log entries to the new node. After receiving the snapshot and log entries, the new node rebuilds its log and state machine based on this information. After completing data synchronization, the node reads and rebuilds its state machine from the log, then joins the consortium chain cluster. At this point, the newly added node is capable of processing new client requests and other network communications with cluster nodes. The new node initially joins as a follower, but may become a leader node during future leader node elections.

[0125] The transaction routing process ensures that client transaction requests are correctly routed to the appropriate leader node. Specifically, all participating nodes in the cluster share leader node information. When a new leader node is elected, all nodes update their leader node information. When a client sends a transaction request, it first queries the current leader node in the cluster. The client then sends the transaction request to this leader node. If the client does not know the current leader node, it can send the transaction request to any connected follower node. In this case, the follower node forwards the request to the known leader node. If a follower node receives a client request but is not the leader node, it must forward the transaction request to the current leader node to ensure that transactions are processed in the order specified by the Raft algorithm. After receiving the client transaction request, the leader node writes the transaction to its own log and sends it to the follower nodes through log replication. When a majority of nodes confirm receipt of the log entry, the leader node commits the log entry, applies it to the state machine, and returns a response to the client. When the leader node changes (such as when a new leader node is elected or a failover occurs), all participating nodes must update their leader node information and communicate this information to the client. This helps clients send new transaction requests directly to the correct leader node.

[0126] The fault recovery process is used to detect and restore communication within a blockchain node group. Specifically, nodes in a blockchain node group are required to regularly send heartbeat messages to other nodes to detect faults. If a follower node does not receive a heartbeat message (or log replication request) from the leader node within a specified time, the follower node will determine that the leader node has failed. Upon detecting a leader node failure, the follower node initiates a new round of leader elections. The follower node switches its status to candidate and votes for the current election. A randomly set timeout is set during which other nodes are allowed to send votes. The candidate node exchanges votes with the other follower nodes to determine the new leader node. If the candidate node receives votes from a majority of nodes within the election timeout, it becomes the new leader node. The new leader node sends a message to other nodes announcing its victory. The newly elected leader node checks and synchronizes with any lagging nodes (including newly joined and recovered nodes). The new leader node synchronizes data with other nodes based on its log information and state machine to ensure that the logs and state machines of all nodes are consistent. The leader node will continue to process client transaction requests and propagate new transactions to other participating nodes through the log replication mechanism. At the same time, during the normal processing process, the leader node will send heartbeat messages to maintain contact with other nodes.

[0127] The transaction partitioning implementation process is responsible for determining data partitions for transactions. Specifically, for each transaction, the transaction sequence number is divided using a modulo operation (remainder calculation). The modulus is set to the number of data partitions. A key value range is defined for each data partition and the corresponding blockchain node group. Simultaneously, a mapping relationship is established between data partitions and blockchain node groups. For example, according to the transaction sequence number partitioning rules, transaction sequence numbers with a modulo result of 0 are mapped to data partition 1, transaction sequence numbers with a modulo result of 1 are mapped to data partition 2, and so on. When the transaction classification submodule receives a new valid transaction, it extracts the transaction sequence number from the transaction. This sequence number is used to perform calculations to determine the data partition to which the transaction belongs. By querying the data partition key value range, applying the classification rules, and comparing it with the transaction sequence number, the data partition and corresponding blockchain node group to which the transaction belongs are determined. Based on the matching results, the transaction is sent to the appropriate blockchain node group for further processing.

[0128] The proposal node's block packaging process is used to package transactions in the transaction pool and upload them to the blockchain. Specifically, when a node proposes a proposal, it sets a current data partition pointer, initially pointing to the first data partition. The selected transaction list is initially empty. One (or some) unselected transactions from the currently pointed-to data partition are selected and added to the selected transaction list. Depending on actual needs, transactions can be selected within the data partition based on priority, cost, or other criteria. The node checks whether the number of transactions in the selected transaction list meets the proposal requirements, or whether all transactions in all data partitions have been checked. If the end condition is met, block creation begins. Otherwise, the current data partition pointer is moved to the next data partition. If the last data partition has been reached, the pointer is returned to the first data partition. As the pointer moves, transactions are continuously selected from the current data partition until the end condition is met. Transactions in the selected transaction list are verified to ensure they are all valid. This verification process includes checking transaction signatures, preventing double spending, and verifying smart contract logic. After the end condition is met, the node packages the verified transactions into a new block. A block usually includes a block header (such as version number, previous block hash, timestamp, difficulty target, block hash, etc.) and verified transaction data. The newly created block is broadcast to other nodes, and synchronization, log replication and other tasks are completed through communication within the blockchain node group.

[0129] It should be noted that although the steps of the method of the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all steps must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0130] The following describes an implementation of the device of the present application, which can be used to execute the method for processing blockchain transactions in the above-mentioned embodiments of the present application. Figure 9 The block diagram of the processing device for blockchain transactions in the embodiment of the present application is schematically shown. Figure 9 As shown, the blockchain transaction processing device 900 may mainly include:

[0131] A transaction acquisition module 910 is configured to acquire a blockchain transaction to be processed, wherein the blockchain transaction includes transaction identification information;

[0132] a partition determination module 920 configured to determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in a node transaction pool, wherein the node transaction pool includes a plurality of data partitions, each data partition corresponding to a blockchain node group in the blockchain;

[0133] a log update module 930 configured to add the blockchain transaction to the target data partition of the transaction pool and to the transaction log of the local node if the target data partition is included in the transaction pool;

[0134] The log distribution module 940 is configured to send the transaction log to other nodes in the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

[0135] In some embodiments of the present application, based on the above technical solution, the log distribution module 940 is further configured to: determine the partition to be packaged according to the partition sequence of the multiple data partitions; select blockchain transactions from the partition to be packaged and add them to the transaction set to be on the chain, wherein the blockchain transactions included in the transaction set to be on the chain are obtained from the data partitions in sequence according to the partition order in the partition sequence; if the transaction set to be on the chain meets the block proposal strategy, block packaging is performed according to the blockchain transactions in the transaction set to be on the chain to obtain a block to be on the chain; broadcast the block to be on the chain to other nodes in the blockchain to chain the block to the blockchain.

[0136] In some embodiments of the present application, based on the above technical solution, the log distribution module is further configured to: if the set of transactions to be on-chain does not satisfy the block proposal strategy, then according to the partition order in the partition sequence, obtain blockchain transactions from the next data partition and add them to the set of transactions to be on-chain until the set of transactions to be on-chain satisfies the block proposal strategy.

[0137] In some embodiments of the present application, based on the above technical solution, the log distribution module 940 is further configured to: send the block to be chained to the leader node of each blockchain node group in the blockchain, so as to add the block to be chained to the transaction log of the leader node; through the leader node of each blockchain node group, send the transaction log of the corresponding leader node to other nodes in each blockchain node group, so as to verify and vote on the block to be chained through the other nodes.

[0138] In some embodiments of the present application, based on the above technical solution, the log distribution module 940 is further configured to: if the target data partition does not exist in the transaction pool, create the target data partition in the transaction pool; send a node expansion request to the leader node in the target blockchain node group corresponding to the target data partition to join the target blockchain node group; receive the transaction log containing the blockchain transaction sent by the leader node; and add the blockchain transaction to the target data partition according to the transaction log.

[0139] In some embodiments of the present application, based on the above technical solution, the log distribution module 940 is further configured to: when the local node is not the leader node in the target blockchain node group, distribute the blockchain transaction to the leader node in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the transaction log of the leader node; receive the transaction log sent by the leader node; and add the blockchain transaction to the target data partition in the transaction pool of the local node according to the transaction log of the leader node.

[0140] In some embodiments of the present application, based on the above technical solution, the partition determination module 920 is also configured to: receive a node expansion request corresponding to a newly added node; according to the node expansion request, add the node information of the newly added node to the group configuration information of the target blockchain node group; add the updated group configuration information to the transaction log; and send the transaction log to other nodes in the target blockchain node group so that the newly added node can communicate with the nodes in the target blockchain node group.

[0141] In some embodiments of the present application, based on the above technical solution, the partition determination module 920 is also configured to: if the transaction log or status notification of the leader node in the target blockchain node group is not received within the specified time, the other nodes in the target blockchain node group are used to re-determine the leader node of the target blockchain node group; and data is synchronized with the other nodes in the target blockchain node group through the leader node.

[0142] In some embodiments of the present application, based on the above technical solution, the partition determination module 920 is further configured to: obtain the transaction data volume of each data partition and the group load data of each blockchain node group; determine the data overload partition among the multiple data partitions based on the transaction data volume of each data partition; determine the low-load node group based on the group load data of each blockchain node group; split the data overload partition into a first partition and a second partition, wherein the first partition corresponds to the blockchain node group of the data overload partition; and establish a mapping relationship between the second partition and the low-load node group.

[0143] In some embodiments of the present application, based on the above technical solution, the transaction identification information includes a transaction serial number; the partition determination module 920 is further configured to: determine the partition key value corresponding to the transaction serial number according to the transaction serial number of the blockchain transaction and the transaction serial number partitioning strategy, wherein the transaction serial number partitioning strategy includes a mapping relationship between the transaction serial number range and the data partition; determine the target data partition corresponding to the blockchain transaction according to the mapping relationship between the partition key value and the partition key value interval corresponding to each data partition in the transaction pool.

[0144] In some embodiments of the present application, based on the above technical solution, the transaction acquisition module 910 is further configured to: send a transaction distribution result notification to the requester of the blockchain transaction; receive a transaction result query request for the blockchain transaction; in response to the transaction result query request, determine the transaction execution result of the blockchain transaction based on the blockchain data of the local node and the transaction data in the target data partition of the transaction pool; and send the transaction execution result to the requester of the blockchain transaction.

[0145] It should be noted that the apparatus provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module performs the operation has been described in detail in the method embodiment and will not be repeated here.

[0146] Figure 10 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown.

[0147] It should be noted that Figure 10 The computer system 1000 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0148] like Figure 10As shown, computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage 1008 into random access memory (RAM) 1003. RAM 1003 also stores various programs and data required for system operation. CPU 1001, ROM 1002, and RAM 1003 are connected to each other via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0149] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output section 1007 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1008 including a hard disk and the like; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as needed. Removable media 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1010 as needed, so that computer programs read therefrom can be installed into the storage section 1008 as needed.

[0150] In particular, according to an embodiment of the present application, the processes described in the various method flow charts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the methods shown in the flow charts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1009, and / or installed from a removable medium 1011. When the computer program is executed by the central processing unit (CPU) 1001, the various functions defined in the system of the present application are executed.

[0151] It should be noted that the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0152] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0153] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the application, the features and functions of two or more modules or units described above can be concretized in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0154] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0155] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this application and include common knowledge or customary techniques in the art that are not disclosed herein.

[0156] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for processing blockchain transactions, characterized in that: include: Obtaining a blockchain transaction to be processed, wherein the blockchain transaction includes transaction identification information; Determining, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in a node transaction pool, wherein the node transaction pool includes multiple data partitions, each data partition corresponding to a blockchain node group in the blockchain; If the target data partition is included in the transaction pool, the blockchain transaction is added to the target data partition of the transaction pool and the transaction log of the local node; According to the target blockchain node group corresponding to the target data partition, the transaction log is sent to other nodes in the target blockchain node group, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

2. The processing method according to claim 1, characterized in that The method further comprises: Determining a partition to be packaged according to a partition sequence of the multiple data partitions; Selecting blockchain transactions from the partitions to be packaged and adding them to the set of transactions to be uploaded to the chain, wherein the blockchain transactions included in the set of transactions to be uploaded to the chain are obtained from the data partitions in sequence according to the partition order in the partition sequence; If the transaction set to be on-chain meets the block proposal strategy, then the block is packaged according to the blockchain transactions in the transaction set to be on-chain to obtain a block to be on-chain; Broadcast the block to be chained to other nodes in the blockchain to chain the block to be chained in the blockchain.

3. The processing method according to claim 2, characterized in that The method further comprises: If the set of transactions to be on-chain does not satisfy the block proposal strategy, then according to the partition order in the partition sequence, blockchain transactions are obtained from the next data partition and added to the set of transactions to be on-chain until the set of transactions to be on-chain satisfies the block proposal strategy.

4. The processing method according to claim 2, characterized in that The broadcasting of the block to be chained to other nodes in the blockchain includes: Sending the block to be on-chain to the leader node of each blockchain node group in the blockchain, so as to add the block to be on-chain to the transaction log of the leader node; The leader node of each blockchain node group sends the transaction log of the corresponding leader node to other nodes in each blockchain node group, so that the other nodes can verify and vote on the block to be chained.

5. The processing method according to claim 1, characterized in that After determining the target data partition corresponding to the blockchain transaction based on the transaction identification information of the blockchain transaction, the method includes: If the target data partition does not exist in the transaction pool, creating the target data partition in the transaction pool; Sending a node expansion request to the leader node in the target blockchain node group corresponding to the target data partition, so as to join the target blockchain node group; Receiving a transaction log containing the blockchain transaction sent by the leader node; According to the transaction log, the blockchain transaction is added to the target data partition.

6. The processing method according to claim 1, characterized in that The method further comprises: When the local node is not a leader node in the target blockchain node group, distributing the blockchain transaction to the leader node in the target blockchain node group according to the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the transaction log of the leader node; Receiving the transaction log sent by the leader node; According to the transaction log of the leader node, the blockchain transaction is added to the target data partition in the transaction pool of the local node.

7. The processing method according to claim 1, characterized in that The method further comprises: Receive node expansion requests corresponding to newly added nodes; According to the node expansion request, the node information of the newly added node is added to the group configuration information of the target blockchain node group; Add the updated group configuration information to the transaction log; The transaction log is sent to other nodes in the target blockchain node group so that the newly added node can communicate with the nodes in the target blockchain node group.

8. The processing method according to claim 1, characterized in that The method further comprises: If no transaction log or status notification is received from the leader node in the target blockchain node group within the specified time, the other nodes in the target blockchain node group are used to re-determine the leader node of the target blockchain node group; Data synchronization is performed through the leader node and other nodes in the target blockchain node group.

9. The processing method according to claim 1, characterized in that: The method further comprises: Obtain the transaction data volume of each data partition and the group load data of each blockchain node group; determining a data overload partition among the plurality of data partitions according to the transaction data volume of each data partition; Determine low-load node groups based on the group load data of each blockchain node group; Splitting the data overload partition into a first partition and a second partition, wherein the first partition corresponds to the blockchain node grouping of the data overload partition; A mapping relationship between the second partition and the low-load node group is established.

10. The processing method according to claim 1, characterized in that: The transaction identification information includes a transaction sequence number; and determining a target data partition corresponding to the blockchain transaction based on the transaction identification information of the blockchain transaction includes: Determining a partition key value corresponding to the transaction number according to the transaction number of the blockchain transaction and a transaction number partitioning strategy, wherein the transaction number partitioning strategy includes a mapping relationship between transaction number ranges and data partitions; Determine the target data partition corresponding to the blockchain transaction according to a mapping relationship between the partition key value and the partition key value interval corresponding to each data partition in the transaction pool.

11. The processing method according to claim 1, characterized in that: After sending the transaction log to other nodes in the target blockchain node group, the method further includes: Sending a transaction distribution result notification to the requester of the blockchain transaction; Receiving a transaction result query request for the blockchain transaction; In response to the transaction result query request, determining a transaction execution result of the blockchain transaction based on the blockchain data of the local node and the transaction data in the target data partition of the transaction pool; Send the transaction execution result to the requester of the blockchain transaction.

12. A blockchain transaction processing device, characterized in that: include: a transaction acquisition module configured to acquire a blockchain transaction to be processed, wherein the blockchain transaction includes transaction identification information; a partition determination module configured to determine, based on the transaction identification information of the blockchain transaction, a target data partition corresponding to the blockchain transaction in a node transaction pool, wherein the node transaction pool includes a plurality of data partitions, each data partition corresponding to a blockchain node group in the blockchain; a log update module configured to add the blockchain transaction to the target data partition of the transaction pool and to the transaction log of the local node if the target data partition is included in the transaction pool; The log distribution module is configured to send the transaction log to other nodes in the target blockchain node group corresponding to the target data partition, so as to add the blockchain transaction to the target data partition in the transaction pool of the other nodes through the transaction log.

13. An electronic device, characterized in that: include: processor; a memory for storing executable instructions of the processor; The processor is configured to execute the method for processing blockchain transactions according to any one of claims 1 to 7 by executing the executable instructions.

14. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for processing blockchain transactions according to any one of claims 1 to 7 is implemented.

15. A computer program product, characterized in that The computer program product includes a computer program, which is stored in a computer-readable storage medium. The processor of the electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device performs the blockchain transaction processing method as claimed in any one of claims 1 to 11.

Images