Block processing method, block processing device, computer device and storage medium

Abstract

Embodiments of the present application provide a block processing method, a block processing device, a computer device and a storage medium, wherein the method comprises: a proposal node obtaining a proposal block comprising a block header and a transaction list, and performing sharding processing on the transaction list to obtain a plurality of transaction list segments; performing parallel data encoding processing on the plurality of transaction list segments through at least two threads to determine respective encoding data corresponding to each transaction list segment; constructing a target data structure according to the block header and each encoding data, and broadcasting the target data structure to a verification node. The verification node obtains the target data structure, obtains each encoding data and the block header from the target data structure, performs parallel data decoding processing on each encoding data through at least two threads to determine a transaction list segment corresponding to each encoding data, and constructs the proposal block according to the block header and each transaction list segment. In this way, the efficiency of proposal block processing can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to block processing methods, block processing devices, computer equipment, and computer-readable storage media. Background Technology

[0002] With the advent of the technological era and the development of the mobile internet, the pace of network transformation is accelerating. The process of achieving information integration within the same or multiple fields and providing clients with comprehensive IT solutions faces new challenges, such as system architecture improvements and shifts in support focus. Therefore, blockchain technology, as a specific implementation of distributed ledgers, is gradually becoming the preferred method for storing and trading data across various fields due to its inherent advantages in data storage and management.

[0003] Currently, common blockchain applications treat proposed blocks as a whole. While this approach is simple, it is inefficient and reduces the overall transaction throughput of the blockchain network. Summary of the Invention

[0004] This application provides a block processing method, a block processing device, a computer device, and a storage medium, which can effectively improve the efficiency of proposal block processing and thus increase the transaction throughput of the entire blockchain network.

[0005] A first aspect of this application provides a block processing method, the method comprising:

[0006] Obtain the proposal block, which includes a block header and a transaction list;

[0007] The transaction list is segmented to obtain multiple transaction list fragments;

[0008] The multiple transaction list fragments are processed in parallel data encoding by at least two threads to determine the encoded data corresponding to each transaction list fragment.

[0009] The target data structure is constructed based on the block header and each encoded data, and the target data structure is broadcast to the verification nodes in the blockchain network.

[0010] A second aspect of this application provides a block processing method, the method comprising:

[0011] Obtain the target data structure broadcast by the proposal node in the blockchain network. The target data structure is constructed by the proposal node through parallel data encoding processing of multiple transaction list fragments by at least two threads, determining the encoded data corresponding to each transaction list fragment, and constructing it based on each encoded data and the block header included in the proposal block. The multiple transaction list fragments are obtained by the proposal node through fragmentation processing of the transaction list included in the proposal block.

[0012] Obtain the coded data and the block header from the target data structure;

[0013] By performing parallel data decoding on each encoded data using at least two threads, the transaction list fragment corresponding to each encoded data is determined.

[0014] The proposal block is constructed based on the block header and fragments of each transaction list.

[0015] On one hand, embodiments of this application provide a block processing apparatus, the apparatus comprising:

[0016] A processing unit is used to obtain a proposal block, wherein the proposal block includes a block header and a transaction list;

[0017] The processing unit is also used to perform segmentation processing on the transaction list to obtain multiple transaction list fragments;

[0018] The processing unit is further configured to perform parallel data encoding processing on the plurality of transaction list fragments through at least two threads, and determine the encoded data corresponding to each transaction list fragment.

[0019] The processing unit is also used to construct a target data structure based on the block header and each encoded data.

[0020] A communication unit is used to broadcast the target data structure to the verification nodes in the blockchain network.

[0021] In one embodiment, the processing unit is specifically configured to: serialize at least two transaction list fragments from the plurality of transaction list fragments simultaneously using at least two threads to determine the bytecode corresponding to each transaction list fragment; and determine the bytecode corresponding to each transaction list fragment as the encoded data corresponding to each transaction list fragment.

[0022] In one embodiment, the processing unit is specifically configured to: determine the target arrangement order of each coded data according to the arrangement order of each transaction list fragment in the transaction list; and construct a target data structure, wherein the target data structure includes the block header and the coded data sorted according to the target arrangement order.

[0023] In one embodiment, the processing unit is specifically configured to: acquire relevant information about the system's data processing resources; determine the number of threads for parallel data encoding processing of the transaction list based on the relevant information about the data processing resources; and perform fragmentation processing on the transaction list based on the number of threads to obtain multiple transaction list fragments.

[0024] In one embodiment, the processing unit is further configured to: add one or more of a start identifier and an end identifier to each of the encoded data; or, add corresponding data volume information to each of the encoded data.

[0025] In one embodiment, the processing unit is specifically used to: when the sharding conditions are met, shard the transaction list to obtain multiple transaction list fragments; wherein, meeting the sharding conditions includes one or more of the following: the data volume of the transaction list is greater than or equal to a data volume threshold, the proposal block processing rules indicate that the transaction list in the proposal block needs to be sharded, and the system configuration supports multi-threaded parallel processing.

[0026] In one embodiment, the processing unit is further configured to: generate a block proposal message, wherein the block proposal message includes the target data structure and a shard identifier; the communication unit is specifically configured to: broadcast the block proposal message to the verification nodes in the blockchain network.

[0027] On the one hand, embodiments of this application provide another block processing apparatus, the apparatus comprising:

[0028] A communication unit is used to obtain the target data structure broadcast by the proposal node in the blockchain network. The target data structure is constructed by the proposal node through parallel data encoding processing of multiple transaction list fragments by at least two threads, determining the encoded data corresponding to each transaction list fragment, and constructing it based on each encoded data and the block header included in the proposal block. The multiple transaction list fragments are obtained by the proposal node by fragmenting the transaction list included in the proposal block.

[0029] A processing unit is configured to obtain the coded data and the block header from the target data structure;

[0030] The processing unit is further configured to perform parallel data decoding processing on each encoded data through at least two threads to determine the transaction list fragments corresponding to each encoded data.

[0031] The processing unit is also configured to construct the proposal block based on the block header and each transaction list fragment.

[0032] In one embodiment, the target data structure further includes a number of shards, and the processing unit is specifically used to: obtain the number of shards from the target data structure and determine the number of encoded data; when the number of encoded data is consistent with the number of shards, perform parallel data decoding processing on each encoded data through at least two threads to determine the transaction list fragments corresponding to each encoded data.

[0033] In one embodiment, the communication unit is specifically used to: receive a block proposal message broadcast by a proposal node in the blockchain network, wherein the block proposal message includes a target data structure; and obtain the target data structure from the block proposal message; the processing unit is specifically used to: when the block proposal message also includes a shard identifier, obtain the various encoded data and the block header from the target data structure.

[0034] On one hand, embodiments of this application provide a computer device, including: a processor, a communication interface, and a memory, wherein the processor, the communication interface, and the memory are interconnected, wherein the memory stores first executable program code, and the processor is used to call the executable program code to execute the block processing method provided in the first aspect of embodiments of this application; or, the memory stores second executable program code, and the processor is used to call the second executable program code to execute the block processing method provided in the second aspect of embodiments of this application.

[0035] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a first computer program that, when run on a computer, causes the computer to execute the block processing method provided in the first aspect of embodiments of this application; or, the computer-readable storage medium storing a second computer program that, when run on a computer, causes the computer to execute the block processing method provided in the second aspect of embodiments of this application.

[0036] Accordingly, embodiments of this application also provide a computer program product or computer program, which includes 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 block processing method provided in the first aspect of embodiments of this application, or to perform the block processing method provided in the second aspect of embodiments of this application.

[0037] In this embodiment, on the one hand, the transaction list in the proposal block is fragmented, and multiple transaction list fragments obtained from the fragmentation are encoded in parallel using at least two threads. This method, compared to encoding the transaction list as a whole (i.e., using a single thread), speeds up the encoding process and improves efficiency. On the other hand, the encoded data corresponding to the transaction list is decoded in parallel using at least two threads. This method, compared to decoding the encoded data corresponding to the transaction list as a whole (i.e., using a single thread), speeds up the decoding process and improves efficiency. Because the data encoding and decoding speeds in the proposal block processing are increased, the efficiency of proposal block processing is effectively improved, thereby increasing the transaction processing speed in the blockchain network and ultimately increasing the overall transaction throughput of the blockchain network. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a schematic diagram of the architecture of a distributed system provided in an embodiment of this application;

[0040] Figure 2 This is a schematic diagram of the structure of a block provided in an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of the architecture of a network system provided in an embodiment of this application;

[0042] Figure 4 This is a flowchart illustrating a block processing method provided in an embodiment of this application;

[0043] Figure 5 This demonstrates the sharding process for the transaction list;

[0044] Figure 6 This illustrates the correspondence between transaction list fragments and coded data;

[0045] Figure 7 This is a schematic diagram of the structure of a block processing device provided in an embodiment of this application;

[0046] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0048] To better understand the embodiments of this application, the blockchain technology involved in the embodiments of this application will be introduced below.

[0049] Blockchain (or blockchain): Distributed ledger, a technology that collectively maintains a reliable database in a decentralized and trustless manner.

[0050] A blockchain network is a distributed system that can be formed by multiple nodes (any form of computing device connected to the network, such as servers or user terminals) connected through network communication. See also Figure 1 This is a schematic diagram of an optional architecture for a distributed system applied to a blockchain network, as provided in this application embodiment. The blockchain network consists of multiple nodes forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the blockchain network, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0051] See Figure 1 The functions of each node in the blockchain network shown include:

[0052] 1) Routing: A basic function of nodes used to support communication between nodes.

[0053] In addition to routing capabilities, nodes can also have the following functions:

[0054] 2) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks record the data submitted by the nodes in the blockchain network, such as transaction data.

[0055] See Figure 2This is an optional schematic diagram of the block structure provided in this application embodiment. Each block includes the hash value of the data record stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain, in essence, is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0056] 3) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain network. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0057] For example, the business logic implemented by the application includes:

[0058] 3.1) A wallet is used to provide the function of trading virtual resources, including initiating a transaction, which means sending the transaction record of the current transaction to other nodes in the blockchain network. After the other nodes successfully verify the transaction, they store the transaction record data in a temporary block of the blockchain as a response to acknowledge the validity of the transaction.

[0059] 3.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain network. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. It can also send confirmation to the node that initiated the operation.

[0060] 3.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's virtual resources to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0061] 4) Consensus is used to solve and ensure the consistency and correctness of every transaction or data across all ledger nodes. The consensus mechanism of a blockchain determines how to reach and maintain that consensus. This mechanism enables blockchain to operate on a large scale and efficiently without relying on a centralized organization.

[0062] Nodes in a blockchain network include consensus nodes and other types of nodes, such as... Figure 1 Node 10 in the consensus node, such as Figure 1 Nodes 11 and 12 are mentioned in the original text. Consensus nodes (or block nodes) are nodes in a blockchain network that possess block-producing and consensus-building capabilities. They can be full nodes storing the complete blockchain. Consensus nodes in a blockchain network can be divided into master nodes and slave nodes. A master node is the consensus node responsible for producing blocks (i.e., generating blocks, also called proposal blocks) at the current stage. Slave nodes are consensus nodes other than master nodes. "Current stage" can refer to the current block height. Ordinary nodes can be any node in the blockchain network other than consensus nodes. Consensus nodes and other types of nodes can be computer devices such as terminals or servers. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, etc. Terminals can be smartphones (such as Android phones, iOS phones, etc.), tablets, laptops, desktop computers, smart speakers, smartwatches, etc., but are not limited to these. Nodes can be connected directly or indirectly via wired or wireless communication, and this application does not impose any restrictions on this.

[0063] To address the problem of low efficiency in proposal block processing, which consequently reduces the transaction throughput of the entire blockchain network, this application provides a block processing method based on blockchain technology to effectively improve the efficiency of proposal block processing, thereby increasing the transaction throughput of the entire blockchain network. This block processing method is applicable to… Figure 3 The network system shown can be implemented based on a blockchain network, including a proposal node 30 and one or more verification nodes 31. The proposal node 30 can be a consensus node in the blockchain network, or it can be another type of node besides a consensus node. When the proposal node 30 is a consensus node in the blockchain network, it can be the master node, meaning it is currently responsible for generating proposal blocks. The verification node 31 can be a consensus node in the blockchain network, or it can be another type of node besides a consensus node. When the verification node 31 is a consensus node in the blockchain network, it can be a slave node other than the master node, and it is currently responsible for reaching consensus on the proposal blocks generated by the master node.

[0064] The block processing method provided in this application embodiment is by Figure 3 In the network system shown, the proposal node 30 and the verification node 31 work together. On one hand, the proposal node fragments the transaction list in the proposal block and uses at least two threads to encode the multiple transaction list fragments in parallel. This method, compared to encoding the transaction list as a whole (i.e., using a single thread), speeds up the encoding process and improves efficiency. On the other hand, the verification node uses at least two threads to decode the encoded data corresponding to the transaction list in parallel. This method, compared to decoding the encoded data as a whole (i.e., using a single thread), speeds up the decoding process and improves efficiency. By increasing the speed of data encoding and decoding during the proposal block processing, the efficiency of proposal block processing is effectively improved, thereby increasing the transaction processing speed in the blockchain network and ultimately increasing the transaction throughput of the entire blockchain network.

[0065] The block processing method provided in the embodiments of this application is described in detail below. Please refer to... Figure 4 The above is a flowchart illustrating the block processing method provided in the embodiments of this application, including but not limited to the following steps:

[0066] S401. The proposal node obtains the proposal block, which includes a block header and a transaction list.

[0067] In this embodiment, the proposal block is generated based on transaction data obtained from the transaction pool. The block header of the proposal block stores the block header information, which may include the hash value (PreHash) of the previous block, the hash value (Hash) of the current block body, and the timestamp (TimeStamp), etc. The transaction list of the proposal block is generated based on the transaction data obtained from the transaction pool and is included in the block body of the proposal block. The transaction data in the transaction list corresponds to one or more transactions and is arranged in a certain order.

[0068] In one embodiment, when the proposing node is the master node in the current stage of the blockchain network, the proposing node can generate the proposal block. In another embodiment, when the proposing node is not the master node in the current stage of the blockchain network, but can broadcast the block proposal message on behalf of the master node, the proposing node can obtain the proposal block generated by the master node from the master node.

[0069] After obtaining the proposal block, when broadcasting it to the validator nodes in the blockchain network, it is usually necessary to encode data such as the transaction list in the proposal block before broadcasting. In this embodiment, after obtaining the proposal block, it is determined whether the sharding conditions are met. If the sharding conditions are met, steps S402-S403 are executed to shard the transaction list, and multiple threads are used to perform parallel data encoding on the multiple transaction list fragments obtained from the sharding process. Meeting the sharding conditions includes one or more of the following: the data volume of the transaction list is greater than or equal to a data volume threshold, the proposal block processing rules indicate that the transaction list in the proposal block needs to be sharded, and the system configuration supports multi-threaded parallel processing. Conversely, if the sharding conditions are not met, the transaction list is treated as a whole for data encoding, that is, a single thread is used to encode the transaction list.

[0070] S402, the proposal node performs fragmentation on the transaction list to obtain multiple transaction list fragments. For example... Figure 5 As shown, the transaction list can be split into M transaction list fragments, where M is a positive integer greater than 1. The order of the transaction data in each transaction list fragment can be consistent with or reversed from its sorting order in the original transaction list. In feasible implementations, when fragmenting the transaction list, it is ensured that the transaction data corresponding to the same transaction is assigned to the same transaction list fragment.

[0071] In one embodiment, the proposing node obtains information about the data processing resources of its system. This information may include one or more of the following: the number of system processors (such as a central processing unit, CPU), the number of cores of each system processor, and the number of threads corresponding to each core, the system processors currently in an idle state, the cores currently in an idle state, and the threads currently in an idle state, etc. Based on this information about the data processing resources, the number of threads and threads that the system can currently perform parallel data encoding processing on the transaction list can be determined.

[0072] Further, based on the relevant information of the data processing resources, the threads and number of threads required for parallel data encoding processing of the transaction list are determined. This can be done by identifying some or all of the threads currently capable of performing parallel data encoding processing on the transaction list. Finally, the transaction list is segmented into multiple transaction list fragments based on the determined number of threads N (N is a positive integer greater than 1) required for parallel data encoding processing. In feasible implementations, the number of transaction list fragments is K times the number of threads N, where K is a positive integer greater than or equal to 1. In feasible implementations, the transaction list can be segmented according to the number of transactions. For example, if the determined number of threads N is 10, the number of transaction list fragments K*N is 10 or 20, and the transaction list includes transaction data corresponding to 600 transactions, then each transaction list fragment includes transaction data corresponding to 60 or 30 transactions.

[0073] S403, the proposal node performs parallel data encoding processing on the multiple transaction list fragments using at least two threads to determine the encoded data corresponding to each transaction list fragment. For example... Figure 6 As shown, after encoding the data of M transaction list fragments, M encoded data are obtained.

[0074] In this embodiment of the application, the at least two threads can be the threads that need to perform parallel data encoding processing on the transaction list as determined above, or they can be some or all of the threads that the system is currently able to perform parallel data encoding processing on the transaction list.

[0075] In one embodiment, the proposal node uses at least two threads to simultaneously encode at least two transaction list fragments from a plurality of transaction list fragments to determine the encoded data corresponding to each transaction list fragment. In one embodiment, the number of transaction list fragments processed simultaneously is the same as the number of threads processing simultaneously.

[0076] In one embodiment, the data encoding process includes serializing the data, i.e., converting the data into a byte sequence. The proposal node simultaneously performs data encoding on at least two transaction list fragments from the plurality of transaction list fragments using at least two threads to determine the encoded data corresponding to each transaction list fragment. This includes: simultaneously serializing at least two transaction list fragments from the plurality of transaction list fragments using at least two threads to determine the bytecode corresponding to each transaction list fragment; and determining the bytecode corresponding to each transaction list fragment as the encoded data corresponding to each transaction list fragment.

[0077] In a feasible implementation, if the system currently has only one thread capable of performing data encoding processing on the transaction list, then that thread can be used to perform data encoding processing on multiple transaction list fragments obtained from the sharding. When other threads capable of performing parallel data encoding processing are available, then the previous thread and the other threads can be used to perform parallel data encoding processing on the remaining unprocessed transaction list fragments.

[0078] S404. The proposal node constructs the target data structure based on the block header and each encoded data.

[0079] In this embodiment, the proposal node determines the target arrangement order of each coded data based on the arrangement order of each transaction list fragment in the transaction list. The target arrangement order of each coded data can be consistent with the arrangement order of its corresponding transaction list fragments in the transaction list (e.g., ...). Figure 6 As shown), the order of the two can also be the reverse of the order of their respective transaction list fragments in the transaction list; of course, the order of the two can also be other correspondences; the specific correspondence of the order of the two can be agreed upon in advance in the blockchain network, for example, written into a smart contract.

[0080] The proposal node obtains the block header of the proposal block and sorts the coded data according to the target sorting order; then it constructs a target data structure that includes the block header and the sorted coded data.

[0081] In one embodiment, in addition to the block header and the sorted encoded data, the target data structure may also include the number of fragments. The number of fragments can refer to the number of transaction list segments obtained by fragmenting the transaction list, or the number of encoded data. Adding the number of fragments to the target data structure enables subsequent verification of the number of encoded data.

[0082] In one embodiment, before constructing the target data structure based on each encoded data, one or more of a start identifier and an end identifier can be added to each encoded data, or corresponding data volume information can be added to each encoded data, so that each encoded data can be quickly and accurately obtained when decoding each encoded data later.

[0083] In one embodiment, before constructing the target data structure based on the block header, signature data can be added to the block header, which may be obtained by signing the original proposal block.

[0084] It should be noted that additional data besides the block header and transaction list from the proposal block needs to be added to the target data structure to ensure that the subsequently recovered proposal block is consistent with the original proposal block.

[0085] S405, The proposing node broadcasts the target data structure to the verification nodes in the blockchain network.

[0086] In this embodiment of the application, the proposal node generates a block proposal message including the target data structure and broadcasts the block proposal message to the verification nodes in the blockchain network.

[0087] In one embodiment, in addition to the target data structure, the block proposal message may also include a shard identifier, which is used to indicate that there is sharded data in the target data structure.

[0088] S406. The verification node obtains the target data structure broadcast by the proposal node.

[0089] In this embodiment of the application, the verification node receives a block proposal message broadcast by the proposal node, which includes the target data structure, and obtains the target data structure from the block proposal message.

[0090] In one embodiment, after the verification node obtains the target data structure, it immediately executes steps S407-S409 to complete the construction of the proposal block, that is, to restore the proposal block.

[0091] In another embodiment, if the proposing node needs to carry a shard identifier in the block proposal message when there is sharded data in the target data structure, the verifying node will also query the shard identifier in the block proposal message when obtaining the target data structure from the block proposal message. If the shard identifier is found, steps S407-S409 are executed to complete the construction of the proposal block; otherwise, if the shard identifier is not found, the encoded data in the target data structure is treated as a whole and data decoding is performed, that is, a thread is used to perform data decoding on the encoded data in the target data structure.

[0092] S407. The verification node obtains the various encoded data and the block header from the target data structure.

[0093] In one embodiment, if the target data structure includes not only encoded data and the block header of the proposal block, but also requires the proposing node to write the number of fragments into the target data structure, then when the validating node obtains each piece of encoded data and the block header of the proposal block from the target data structure, it will also obtain the number of fragments from the target data structure and determine the number of encoded data in the target data structure. When the number of encoded data matches the number of fragments, steps S408-S409 are executed. When the number of encoded data does not match the number of fragments, an indication message indicating an encoding data error can be returned to the proposing node. When the proposing node receives indication messages indicating encoding data errors from more than a preset proportion (e.g., 2 / 3) of the validating nodes, it can reconstruct and broadcast the target data structure.

[0094] S408. The verification node performs parallel data decoding processing on each encoded data through at least two threads to determine the transaction list fragment corresponding to each encoded data.

[0095] In this embodiment of the application, the at least two threads may be some or all of the threads that the system is currently capable of performing parallel data decoding processing on each encoded data.

[0096] In one embodiment, the verification node uses at least two threads to simultaneously decode at least two pieces of encoded data from each encoded data set to determine the decoded data corresponding to each encoded data set, i.e., the transaction list fragment. In one embodiment, the number of encoded data sets processed simultaneously is consistent with the number of threads performing the processing simultaneously.

[0097] In one embodiment, if the data encoding process is to serialize the data, the verification node simultaneously performs data decoding processing on at least two encoded data in each encoded data using at least two threads to determine the transaction list fragments corresponding to each encoded data, including: simultaneously performing deserialization processing on at least two encoded data in each encoded data using at least two threads to determine the transaction list fragments corresponding to each encoded data.

[0098] In a feasible embodiment, if the system currently has only one thread capable of performing data decoding on each encoded data, then that thread can be used to perform data decoding on the encoded data first. When other threads capable of performing parallel data decoding are available, then the previous thread and the other threads can be used to perform parallel data decoding on the remaining unprocessed encoded data.

[0099] S409. The verification node constructs the proposal block based on the block header and each transaction list fragment, that is, performs proposal block recovery.

[0100] In this embodiment, after the verification node determines the transaction list fragments corresponding to each coded data, it constructs a transaction list based on each transaction list fragment, and then constructs a proposal block based on the block header and the transaction list. If the data obtained by the verification node is correct and the data recovery process is error-free, the proposal block constructed by the verification node is consistent with the proposal block obtained by the proposal node.

[0101] In one implementation, the verification node constructs the transaction list based on each transaction list fragment as follows: The verification node determines the order of each transaction list fragment according to the arrangement order of each coded data in the target data structure. The arrangement order of each transaction list fragment can be consistent with the arrangement order of its corresponding coded data in the target data structure, or it can be the reverse of the arrangement order of its corresponding coded data in the target data structure; of course, the arrangement order can also be other correspondences. The specific correspondence between the two arrangement orders can be consistent with the correspondence between the two arrangement orders during the construction of the target data structure, and can be pre-agreed in the blockchain network, for example, written into a smart contract. The verification node concatenates each transaction list fragment according to the determined arrangement order of each transaction list fragment to obtain the transaction list. If the data obtained by the verification node is correct, and the data recovery process is error-free, the transaction list constructed by the verification node is consistent with the transaction list in the original proposal block.

[0102] In this embodiment, after constructing the proposal block, the verification node can verify the proposal block (i.e., the actual block data), for example, by verifying the signature data carried in the block header and verifying the validity of transactions in the transaction list. Once the proposal block is verified, the transactions in the proposal block can be executed by means of methods such as calling a virtual machine. Furthermore, the verification node and the proposal node can reach a consensus on the proposal block and the execution results of the transactions related to it. After reaching a consensus, the proposal block and the execution results of the transactions related to it can be written into the ledger, and the next round of consensus can be initiated. Alternatively, new transaction data can be obtained from the transaction pool, and steps S401-S409 can be re-executed based on the obtained new transaction data.

[0103] In this embodiment, on the one hand, the proposing node fragments the transaction list in the proposal block and performs parallel data encoding on the multiple transaction list fragments obtained from the fragmentation process using at least two threads. This processing method, compared to encoding the transaction list as a whole (i.e., using a single thread for data encoding), can speed up the encoding of the transaction list, achieve higher encoding efficiency, and fully utilize the system's data processing resources. On the other hand, the verifying node performs parallel data decoding on the encoded data corresponding to the transaction list using at least two threads. This processing method, compared to decoding the encoded data corresponding to the transaction list as a whole (i.e., using a single thread for data decoding), can speed up the decoding of the encoded data, achieve higher decoding efficiency, and fully utilize the system's data processing resources. Because the data encoding and decoding speeds in the proposal block processing process are improved, the efficiency of proposal block processing can be effectively improved, thereby increasing the transaction processing speed in the blockchain network and ultimately increasing the transaction throughput of the entire blockchain network.

[0104] The following example illustrates the block processing method provided in this application, using data encoding processing as serialization processing and data decoding processing as deserialization processing.

[0105] In this embodiment of the application, nodes in the blockchain network can maintain two data structures. One data structure is a block structure similar to a known blockchain, which includes a block header and a transaction list. This block structure can be recognized and executed by nodes in the blockchain network (e.g., nodes call a virtual machine to execute it). The other data structure, proposal block, is the result of the block structure being sharded. It also includes a block header, as well as the bytecode of each shard, and may include the total number of shards.

[0106] The block proposal message (Proposal Msg) provides a sharding field, use Shard Flag, for sharding functionality. This field indicates whether the data structure contained in the block proposal message was obtained through sharding. If sharding was used, the block proposal message will include the aforementioned data structure, Proposal Block, but will not include the aforementioned block structure, Block. If sharding was not used, the block proposal message will include the aforementioned block structure, Block, but will not include the aforementioned data structure, Proposal Block.

[0107] The following describes the process of sharding the proposal block. When constructing a block proposal message, the proposal node first obtains sufficient transaction data from the transaction pool, builds a transaction list based on the obtained transaction data, constructs the aforementioned block structure (Block) based on this transaction list, and signs the block structure (Block), writing the signed data into the Block Header of the block structure (Block). The proposal node then determines whether sharding is necessary. If so (e.g., if the proposal block processing rules indicate that sharding is required), the block structure (Block) is sharded to construct the data structure (Proposal Block). This can be achieved by: assigning the Block Header of the Block structure to the Block Header of the Proposal Block data structure; fragmenting the transaction list within the Block structure according to system resources. For example, assuming the transaction list contains 2000 transactions, the system has 8 CPU cores, and each CPU can process 50 transactions, the transaction list is divided into 40 fragments. These 40 fragments are then serialized simultaneously using multiple threads. The bytecode set obtained after serialization of each fragment is appended to the data field of the Proposal Block data structure according to the order of the corresponding fragment in the Block structure (or the transaction list). The Proposal Block data structure can also record the total number of fragments, with a value of 40.

[0108] After processing the shards according to the above procedure, the proposal node fills the resulting data structure, `Proposal Block`, into the block proposal message, `Proposal Msg`. Simultaneously, the `useShardFlag` field of the `Proposal Msg` is marked as using sharding. The proposal node then broadcasts the constructed block proposal message to other validator nodes in the blockchain network.

[0109] After receiving the block proposal message broadcast by the proposing node, other validating nodes in the blockchain network need to verify the proposed block and execute it via the virtual machine. First, they determine if the `useShard Flag` field in the `Proposal Msg` message indicates that sharding is used. If so, the shards need to be decoded (or restored). First, the aforementioned block structure `Block` is constructed. The `Proposal Block` data structure is obtained from the `Proposal Msg` message, and its block header `Block Header` is assigned to the `Block Header` of the constructed block structure `Block`. Next, a transaction list space of a corresponding size is allocated based on the number of transactions in the `Block Header`. This transaction list space will be used for shard restoration. Multiple threads are then used to perform parallel deserialization of the shard data in the `Proposal Block` data structure, restoring each shard (i.e., each set of bytecode) into a transaction list fragment. In one implementation, the total number of shards in the Proposal Block data structure can be checked, and multiple threads of equal number can be used to perform parallel deserialization processing on the shard data in the Proposal Block data structure, restoring each shard data into a transaction list fragment. Then, the restored transaction list fragment is written to the corresponding position in the transaction list space of the constructed block structure according to the position of the corresponding shard data in the Proposal Block data structure.

[0110] After recovering the shards, validator nodes can verify the actual block data (i.e., the proposal block), such as verifying the signature data in the block header and the validity of transactions in the transaction list. Once the actual block data is verified, the virtual machine can be invoked to execute the transactions in the proposal block. Validator nodes and proposal nodes can also reach consensus on the proposal block and the execution results of transactions related to it. When consensus is reached, the proposal block and the execution results of transactions related to it can be written to the ledger, and the next round of consensus can be initiated. Alternatively, new transaction data can be retrieved from the transaction pool, and the above steps can be re-executed based on the new transaction data.

[0111] By employing the above method, proposal nodes and verification nodes in the blockchain network can fully utilize system resources (such as CPU computing resources and memory resources) through sharding. Parallel processing by multiple processes can accelerate the preprocessing (such as serialization), recovery, and verification of proposal blocks, speed up the broadcast of block proposals to verification nodes, and improve overall consensus efficiency. This allows for earlier entry into the next round of consensus, including the early generation of the next proposal block, thereby effectively increasing the transaction throughput of the blockchain network.

[0112] It should be noted that the execution entity used to perform each step in the above method embodiments can be hardware, software, or a combination of hardware and software.

[0113] Please see Figure 7 This is a schematic diagram of a block processing device provided in an embodiment of this application. The block processing device described in this embodiment can correspond to the proposal node mentioned above, and the device includes:

[0114] Processing unit 701 is used to obtain a proposal block, the proposal block including a block header and a transaction list;

[0115] The processing unit 701 is also used to perform segmentation processing on the transaction list to obtain multiple transaction list fragments;

[0116] The processing unit 701 is further configured to perform parallel data encoding processing on the plurality of transaction list fragments through at least two threads, and determine the encoded data corresponding to each transaction list fragment respectively;

[0117] The processing unit 701 is further configured to construct a target data structure based on the block header and each encoded data.

[0118] The communication unit 702 is used to broadcast the target data structure to the verification nodes in the blockchain network.

[0119] In one embodiment, the processing unit 701 is specifically configured to: perform serialization processing on at least two transaction list fragments from the plurality of transaction list fragments simultaneously using at least two threads to determine the bytecode corresponding to each transaction list fragment; and determine the bytecode corresponding to each transaction list fragment as the encoded data corresponding to each transaction list fragment.

[0120] In one embodiment, the processing unit 701 is specifically configured to: determine the target arrangement order of each coded data according to the arrangement order of each transaction list fragment in the transaction list; and construct a target data structure, wherein the target data structure includes the block header and the coded data sorted according to the target arrangement order.

[0121] In one embodiment, the processing unit 701 is specifically used to: obtain relevant information about the system's data processing resources; determine the number of threads for parallel data encoding processing of the transaction list based on the relevant information about the data processing resources; and perform fragmentation processing on the transaction list based on the number of threads to obtain multiple transaction list fragments.

[0122] In one embodiment, the processing unit 701 is further configured to: add one or more of a start identifier and an end identifier to each of the encoded data; or, add corresponding data volume information to each of the encoded data.

[0123] In one embodiment, the processing unit 701 is specifically used to: when the sharding conditions are met, to shard the transaction list to obtain multiple transaction list fragments; wherein, meeting the sharding conditions includes one or more of the following: the data volume of the transaction list is greater than or equal to a data volume threshold, the proposal block processing rules indicate that the transaction list in the proposal block needs to be sharded, and the system configuration supports multi-threaded parallel processing.

[0124] In one embodiment, the processing unit 701 is further configured to: generate a block proposal message, wherein the block proposal message includes the target data structure and a shard identifier; the communication unit 702 is specifically configured to: broadcast the block proposal message to the verification nodes in the blockchain network.

[0125] In another embodiment, the block processing apparatus described in this application can correspond to the verification node mentioned above. The processing unit 701 and communication unit 702 included in the apparatus are used to perform the following functions:

[0126] The communication unit 702 is used to obtain the target data structure broadcast by the proposal node in the blockchain network. The target data structure is constructed by the proposal node through parallel data encoding processing of multiple transaction list fragments by at least two threads, determining the encoded data corresponding to each transaction list fragment, and constructing it based on each encoded data and the block header included in the proposal block. The multiple transaction list fragments are obtained by the proposal node by fragmenting the transaction list included in the proposal block.

[0127] Processing unit 701 is used to obtain the various encoded data and the block header from the target data structure;

[0128] The processing unit 701 is further configured to perform parallel data decoding processing on each encoded data through at least two threads to determine the transaction list fragments corresponding to each encoded data.

[0129] The processing unit 701 is further configured to construct the proposal block based on the block header and each transaction list fragment.

[0130] In one embodiment, the target data structure further includes a number of shards, and the processing unit 701 is specifically used to: obtain the number of shards from the target data structure and determine the number of encoded data; when the number of encoded data is consistent with the number of shards, perform parallel data decoding processing on each encoded data through at least two threads to determine the transaction list fragments corresponding to each encoded data.

[0131] In one embodiment, the communication unit 702 is specifically used to: receive a block proposal message broadcast by a proposal node in the blockchain network, wherein the block proposal message includes a target data structure; and obtain the target data structure from the block proposal message; the processing unit 701 is specifically used to: when the block proposal message also includes a shard identifier, obtain the various encoded data and the block header from the target data structure.

[0132] It is understood that the functions of each functional unit of the block processing device in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0133] In feasible embodiments, the block processing apparatus provided in this application can be implemented in software. The block processing apparatus can be stored in a memory and can be software in the form of programs and plug-ins, and includes a series of units, including processing units and communication units; wherein, the processing units and communication units are used to implement the block processing method provided in this application.

[0134] In other feasible embodiments, the block processing device provided in this application embodiment can also be implemented in a combination of hardware and software. As an example, the block processing device provided in this application embodiment can be a processor in the form of a hardware decoding processor, which is programmed to execute the block processing method provided in this application embodiment. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0135] In this embodiment, on the one hand, the transaction list in the proposal block is fragmented, and multiple transaction list fragments obtained from the fragmentation are encoded in parallel using at least two threads. This method, compared to encoding the transaction list as a whole (i.e., using a single thread), speeds up the encoding process and improves efficiency. On the other hand, the encoded data corresponding to the transaction list is decoded in parallel using at least two threads. This method, compared to decoding the encoded data corresponding to the transaction list as a whole (i.e., using a single thread), speeds up the decoding process and improves efficiency. Because the data encoding and decoding speeds in the proposal block processing are increased, the efficiency of proposal block processing is effectively improved, thereby increasing the transaction processing speed in the blockchain network and ultimately increasing the overall transaction throughput of the blockchain network.

[0136] Please see Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device described in this embodiment can correspond to the proposal node mentioned above, including: a processor 801, a communication interface 802, and a memory 803. The processor 801, communication interface 802, and memory 803 can be connected via a bus or other means; this embodiment takes a bus connection as an example.

[0137] The processor 801 (or CPU, Central Processing Unit) is the computing and control core of the computer device. It can parse various instructions and process various data within the computer device. For example, the CPU can parse power-on / off commands sent by the user and control the computer device to perform power-on / off operations; it can also transmit various interactive data between internal structures of the computer device. The communication interface 802 may optionally include standard wired interfaces or wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and is controlled by the processor 801 for sending and receiving data. The memory 803 is the storage device in the computer device, used to store programs and data. It is understood that the memory 803 here can include the computer device's built-in memory, or it can include extended memory supported by the computer device. The memory 803 provides storage space for the computer device's operating system, which may include, but is not limited to, Android, iOS, Windows Phone, etc., and this application does not limit this.

[0138] In this embodiment, the processor 801 performs the following operations by running the executable program code in the memory 803:

[0139] Obtain a proposal block, which includes a block header and a transaction list; perform fragmentation on the transaction list to obtain multiple transaction list fragments; perform parallel data encoding on the multiple transaction list fragments using at least two threads to determine the encoded data corresponding to each transaction list fragment; construct a target data structure based on the block header and each encoded data, and broadcast the target data structure to the verification nodes in the blockchain network through communication interface 802.

[0140] In one embodiment, when the processor 801 performs parallel data encoding processing on the plurality of transaction list fragments using at least two threads to determine the encoded data corresponding to each transaction list fragment, it specifically performs the following steps: simultaneously serializes at least two transaction list fragments from the plurality of transaction list fragments using at least two threads to determine the bytecode corresponding to each transaction list fragment; and determines the bytecode corresponding to each transaction list fragment as the encoded data corresponding to each transaction list fragment.

[0141] In one embodiment, when the processor 801 constructs a target data structure based on the block header and each encoded data, it is specifically configured to: determine the target arrangement order of each encoded data according to the arrangement order of each transaction list fragment in the transaction list; and construct the target data structure, wherein the target data structure includes the block header and each encoded data sorted according to the target arrangement order.

[0142] In one embodiment, when the processor 801 performs fragmentation processing on the transaction list to obtain multiple transaction list segments, it is specifically used to: obtain relevant information about the system's data processing resources; determine the number of threads for parallel data encoding processing of the transaction list based on the relevant information about the data processing resources; and perform fragmentation processing on the transaction list based on the number of threads to obtain multiple transaction list segments.

[0143] In one embodiment, the processor 801 is further configured to: add one or more of a start identifier and an end identifier to each of the encoded data; or, add corresponding data volume information to each of the encoded data.

[0144] In one embodiment, the processor 801 is specifically used to: when the sharding conditions are met, to shard the transaction list to obtain multiple transaction list fragments; wherein, meeting the sharding conditions includes one or more of the following: the data volume of the transaction list is greater than or equal to a data volume threshold, the proposal block processing rules indicate that the transaction list in the proposal block needs to be sharded, and the system configuration supports multi-threaded parallel processing.

[0145] In one embodiment, the processor 801 is further configured to: generate a block proposal message, wherein the block proposal message includes the target data structure and a shard identifier; and broadcast the block proposal message to the verification nodes in the blockchain network via the communication interface 802.

[0146] In feasible embodiments, the computer device described in this application can correspond to the proposal node mentioned above, and the processor 801 performs the following operations by running executable program code in the memory 803:

[0147] The target data structure broadcast by the proposal node in the blockchain network is obtained through the communication interface 802. The target data structure is constructed by the proposal node through parallel data encoding processing of multiple transaction list fragments by at least two threads, determining the encoded data corresponding to each transaction list fragment, and constructing it based on each encoded data and the block header included in the proposal block. The multiple transaction list fragments are obtained by the proposal node by fragmenting the transaction list included in the proposal block.

[0148] Obtain the encoded data and the block header from the target data structure; perform parallel data decoding on the encoded data using at least two threads to determine the transaction list fragments corresponding to each encoded data; construct the proposal block based on the block header and the transaction list fragments.

[0149] In one embodiment, the target data structure further includes a number of shards, and the processor 801 is specifically configured to: obtain the number of shards from the target data structure and determine the number of encoded data; when the number of encoded data is consistent with the number of shards, perform parallel data decoding processing on each encoded data through at least two threads to determine the transaction list fragments corresponding to each encoded data.

[0150] In one embodiment, the processor 801 is specifically configured to: receive a block proposal message broadcast by a proposal node in the blockchain network via a communication interface 802, wherein the block proposal message includes a target data structure; obtain the target data structure from the block proposal message; and when the block proposal message also includes a shard identifier, obtain the respective encoded data and the block header from the target data structure.

[0151] In specific implementations, the processor 801, communication interface 802, and memory 803 described in the embodiments of this application can execute the implementation of the proposal node or verification node described in the block processing method provided in the embodiments of this application, or they can execute the implementation of the block processing device provided in the embodiments of this application, which will not be repeated here.

[0152] In this embodiment, on the one hand, the transaction list in the proposal block is fragmented, and multiple transaction list fragments obtained from the fragmentation are encoded in parallel using at least two threads. This method, compared to encoding the transaction list as a whole (i.e., using a single thread), speeds up the encoding process and improves efficiency. On the other hand, the encoded data corresponding to the transaction list is decoded in parallel using at least two threads. This method, compared to decoding the encoded data corresponding to the transaction list as a whole (i.e., using a single thread), speeds up the decoding process and improves efficiency. Because the data encoding and decoding speeds in the proposal block processing are increased, the efficiency of proposal block processing is effectively improved, thereby increasing the transaction processing speed in the blockchain network and ultimately increasing the overall transaction throughput of the blockchain network.

[0153] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to execute the block processing method provided in this application. The specific implementation is described above and will not be repeated here.

[0154] This application also provides a computer program product or computer program, which includes 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 block processing method provided in this application. Specific implementation details are provided above and will not be repeated here.

[0155] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0156] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0157] The above-disclosed embodiments are only some of the embodiments of this application, and should not be construed as limiting the scope of this application. Therefore, any equivalent changes made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A block processing method, characterized in that, The method includes: Obtain the proposal block, which includes a block header and a transaction list; Obtain relevant information about the system's data processing resources; determine the number of threads for parallel data encoding processing of the transaction list based on the relevant information about the data processing resources; perform sharding processing on the transaction list based on the number of threads to obtain multiple transaction list fragments; wherein, transaction data corresponding to the same transaction is assigned to the same transaction list fragment, and the number of multiple transaction list fragments is K times the number of threads, where K is a positive integer greater than or equal to 1; The plurality of transaction list fragments are processed in parallel by at least two threads to determine the encoded data corresponding to each transaction list fragment; wherein the number of transaction list fragments processed at the same time is the same as the number of threads processed at the same time. Add signature data to the block header, the signature data being obtained by signing the proposal block; Based on the order in which the various transaction list fragments are arranged in the transaction list, determine the target arrangement order of each coded data; Construct a target data structure, wherein the target data structure includes: a block header with the signature data added, each encoded data sorted according to the target arrangement order, and the number of shards in the transaction list; The target data structure is broadcast to the verification nodes in the blockchain network; wherein, the target data structure is used by the verification nodes to construct the proposal block when the number of encoded data is consistent with the number of shards, to verify the constructed proposal block based on the signature data, and to conduct transaction consensus on the proposal block if the verification is successful.

2. The method as described in claim 1, characterized in that, The step of performing parallel data encoding processing on the multiple transaction list fragments using at least two threads to determine the encoded data corresponding to each transaction list fragment includes: By simultaneously serializing at least two transaction list fragments from the plurality of transaction list fragments using at least two threads, the bytecode corresponding to each transaction list fragment is determined. The bytecode corresponding to each transaction list fragment is determined as the encoded data corresponding to each transaction list fragment.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: Add one or more of a start identifier and an end identifier to each of the encoded data; Alternatively, add corresponding data volume information to each of the encoded data.

4. The method as described in claim 1 or 2, characterized in that, The method further includes: When the fragmentation conditions are met, the transaction list is fragmented to obtain multiple transaction list fragments; The conditions for sharding include one or more of the following: the data volume of the transaction list is greater than or equal to the data volume threshold; the proposal block processing rules indicate that the transaction list in the proposal block needs to be sharded; and the system configuration supports multi-threaded parallel processing.

5. The method as described in claim 1 or 2, characterized in that, The step of broadcasting the target data structure to the verification nodes in the blockchain network includes: Generate a block proposal message, wherein the block proposal message includes the target data structure and the shard identifier; The block proposal message is broadcast to the validator nodes in the blockchain network.

6. A block processing method, characterized in that, The method includes: The target data structure broadcast by the proposal node in the blockchain network is obtained. This target data structure is constructed by the proposal node through parallel data encoding processing of multiple transaction list fragments using at least two threads, determining the encoded data corresponding to each transaction list fragment, and constructing the structure based on the encoded data sorted according to a target order, the block header with added signature data, and the number of transaction list fragments. The multiple transaction list fragments are obtained by the proposal node fragmenting the transaction list included in the proposal block according to the number of threads. The number of threads is determined by the proposal node based on relevant information about the system's data processing resources, and the target order is determined based on the order of the transaction list fragments within the transaction list. The proposal block also includes a block header without the added signature data. The signature data is obtained by signing the proposal block. Transaction data corresponding to the same transaction is grouped into the same transaction list fragment. The number of multiple transaction list fragments is K times the number of threads, where K is a positive integer greater than or equal to 1. Obtain the coded data, the block header, and the number of fragments from the target data structure; The number of encoded data is determined. When the number of encoded data is consistent with the number of fragments, each encoded data is processed in parallel by at least two threads to determine the transaction list fragment corresponding to each encoded data. The number of encoded data processed at the same time is consistent with the number of threads processed at the same time. The proposal block is constructed based on the block header and fragments of each transaction list. The constructed proposal block is verified based on the signature data, and if the verification is successful, a transaction consensus is reached for the proposal block.

7. The method as described in claim 6, characterized in that, The method for obtaining the target data structure broadcast by the proposal node in the blockchain network includes: Receive block proposal messages broadcast by proposal nodes in the blockchain network, wherein the block proposal messages include a target data structure; Obtain the target data structure from the block proposal message; The method further includes: When the block proposal message also includes a fragment identifier, the steps of obtaining the various encoded data, the block header, and the number of fragments from the target data structure are performed.

8. A block processing device, characterized in that, The device includes: A processing unit is used to obtain a proposal block, wherein the proposal block includes a block header and a transaction list; The processing unit is further configured to acquire relevant information about the system's data processing resources, determine the number of threads for parallel data encoding processing of the transaction list based on the relevant information about the data processing resources, and perform sharding processing on the transaction list based on the number of threads to obtain multiple transaction list fragments; wherein, transaction data corresponding to the same transaction is assigned to the same transaction list fragment, and the number of multiple transaction list fragments is K times the number of threads, where K is a positive integer greater than or equal to 1; The processing unit is further configured to perform parallel data encoding processing on the plurality of transaction list fragments through at least two threads, and determine the encoded data corresponding to each transaction list fragment; wherein the number of transaction list fragments processed simultaneously is consistent with the number of threads processed simultaneously. The processing unit is also configured to add signature data to the block header, wherein the signature data is obtained by signing the proposal block; The processing unit is also configured to determine the target arrangement order of each coded data according to the arrangement order of each transaction list fragment in the transaction list; The processing unit is further configured to construct a target data structure, wherein the target data structure includes: a block header with the signature data added, each encoded data sorted according to the target arrangement order, and the number of shards in the transaction list; A communication unit is used to broadcast the target data structure to verification nodes in the blockchain network; wherein, the target data structure is used by the verification node to construct the proposal block when the number of encoded data is consistent with the number of shards, to verify the constructed proposal block based on the signature data, and to conduct transaction consensus on the proposal block if the verification is successful.

9. A block processing device, characterized in that, The device includes: A communication unit is used to acquire the target data structure broadcast by the proposal node in the blockchain network. The target data structure is constructed by the proposal node through parallel data encoding processing of multiple transaction list fragments using at least two threads, determining the encoded data corresponding to each transaction list fragment, and constructing the structure based on the encoded data sorted according to a target order, the block header with added signature data, and the number of transaction list fragments. The multiple transaction list fragments are obtained by the proposal node fragmenting the transaction list included in the proposal block according to the number of threads. The number of threads is determined by the proposal node based on relevant information about the system's data processing resources, and the target order is determined based on the order of the transaction list fragments in the transaction list. The proposal block also includes a block header without the added signature data. The signature data is obtained by signing the proposal block. Transaction data corresponding to the same transaction is grouped into the same transaction list fragment. The number of multiple transaction list fragments is K times the number of threads, where K is a positive integer greater than or equal to 1. A processing unit is configured to obtain the various encoded data, the block header, and the number of fragments from the target data structure; The processing unit is further configured to determine the number of encoded data. When the number of encoded data is consistent with the number of fragments, at least two threads are used to perform parallel data decoding processing on each encoded data to determine the transaction list fragments corresponding to each encoded data. The number of encoded data processed simultaneously is consistent with the number of threads processed simultaneously. The processing unit is also configured to construct the proposal block based on the block header and each transaction list fragment; The processing unit is further configured to verify the constructed proposal block based on the signature data, and, if the verification is successful, to conduct transaction consensus on the proposal block.

10. A computer device, characterized in that, include: The processor, the communication interface, and the memory are interconnected. The memory stores first executable program code, and the processor is used to call the first executable program code to execute the block processing method as described in any one of claims 1-5; or, the memory stores second executable program code, and the processor is used to call the second executable program code to execute the block processing method as described in any one of claims 6-7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a first computer program that, when run on a computer, causes the computer to perform the block processing method as described in any one of claims 1-5; or, the computer-readable storage medium stores a second computer program that, when run on a computer, causes the computer to perform the block processing method as described in any one of claims 6-7.

12. A computer program product, characterized in that, The computer program product includes 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 block processing method as described in any one of claims 1-5, or to perform the block processing method as described in any one of claims 6-7.

Images