Method and apparatus for generating blocks, and blockchain network

Abstract

The specification provides a method and device for generating a block, and a blockchain network. The method is applied to a first node in a blockchain network comprising a proposal thread and an analysis thread. A rotating queue maintained by the proposal thread comprises a plurality of slots arranged in a sequence, each slot corresponding to an analysis thread. The method comprises: if any slot pointed to by a block formation pointer is empty, the proposal thread places a batch of transactions and their pre-execution read-write sets into the slot, and triggers the block formation pointer to point to a next slot; if a batch of transactions in any slot is not analyzed, a target analysis thread corresponding to the slot analyzes the batch of transactions according to the pre-execution read-write sets, and places the analysis result in the slot; if a batch of transactions in any slot pointed to by a proposal pointer has been analyzed, the proposal thread initiates a block generation proposal for the batch of transactions; and after the proposal passes the consensus, the transactions in the slot are emptied, and the proposal pointer is triggered to point to a next slot.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method and apparatus for generating blocks, and a blockchain network. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain network, data blocks are sequentially linked to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Users can participate in blockchain-related transactions through blockchain nodes. For example, multiple blockchain nodes corresponding to different users can perform secure multi-party computation (SMPC) on the private data of a particular node based on privacy technologies such as homomorphic encryption and zero-knowledge proofs.

[0003] In related technologies, to improve the efficiency and accuracy of blockchain transaction execution, nodes in a blockchain network typically need to pre-execute transactions. After analyzing the pre-executed read-write set, they propose transactions based on the analysis results, and then package the transactions into a new block after the proposal is approved. It is evident that the block generation chain is relatively long, and because analysis and proposal often consume time, the overall block generation efficiency is low, resulting in low overall transaction execution efficiency of the blockchain network and impacting its throughput. Summary of the Invention

[0004] The purpose of this specification is to provide a method and apparatus for generating blocks, and a blockchain network.

[0005] According to a first aspect of one or more embodiments of this specification, a method for generating blocks is provided, applied to a first node in a blockchain network, the first node comprising a proposal thread and a plurality of analysis threads, wherein a round-robin queue maintained by the proposal thread comprises a plurality of slots arranged in a sequential cycle, each slot corresponding to an analysis thread, the method comprising:

[0006] When any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write sets into the slot and triggers the block pointer to point to the next slot adjacent to the slot.

[0007] If a batch of transactions in any slot has not been analyzed, the target analysis thread corresponding to any slot analyzes the batch of transactions according to the pre-execution read-write set and puts the analysis results into the slot.

[0008] When the proposal thread points to any slot and a batch of transactions in that slot has been analyzed, it initiates a block generation proposal for that batch of transactions; and when the block generation proposal passes consensus, it clears the transactions in that slot and triggers the proposal thread to point to the next slot adjacent to that slot.

[0009] According to a second aspect of one or more embodiments of this specification, a blockchain network is provided, wherein a first node in the blockchain network includes a proposal thread and a plurality of analysis threads, and the proposal thread maintains a round-robin queue containing a plurality of slots arranged in a sequential, cyclic manner, each slot corresponding to an analysis thread, wherein:

[0010] When any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write sets into the slot and triggers the block pointer to point to the next slot adjacent to the slot.

[0011] If a batch of transactions in any slot has not been analyzed, the target analysis thread corresponding to any slot analyzes the batch of transactions according to the pre-execution read-write set and puts the analysis results into the slot.

[0012] When the proposal thread points to any slot and a batch of transactions in that slot has been analyzed, it initiates a block generation proposal for that batch of transactions; and when the block generation proposal passes consensus, it clears the transactions in that slot and triggers the proposal thread to point to the next slot adjacent to that slot.

[0013] According to a third aspect of one or more embodiments of this specification, an apparatus for generating blocks is provided, applied to a first node in a blockchain network. The first node includes a proposal thread and a plurality of analysis threads. The proposal thread maintains a rotating queue containing a plurality of slots arranged in a sequential, cyclic manner, each slot corresponding to an analysis thread. The apparatus includes:

[0014] The placement unit is used to enable the proposal thread to place a batch of transactions and their pre-execution read / write sets into any slot when the block pointer is empty, and to trigger the block pointer to point to the next slot adjacent to the slot.

[0015] The analysis unit is configured to enable the target analysis thread corresponding to any slot to analyze a batch of transactions in any slot without completing the analysis, based on the pre-execution read / write set, and to place the analysis results into any slot.

[0016] The proposal unit is configured to enable the proposal thread to initiate a block generation proposal for a batch of transactions when the proposal pointer points to any slot and a batch of transactions in that slot has been analyzed; and, if the block generation proposal passes consensus, to clear the transactions in any slot and trigger the proposal pointer to point to the next slot adjacent to any slot.

[0017] According to a fourth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0018] processor;

[0019] Memory used to store processor-executable instructions;

[0020] The processor implements the method as described in any one of the first aspects by executing the executable instructions.

[0021] According to a fifth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in any of the first aspects.

[0022] Through the above embodiments, based on the round-robin queue maintained by the proposal thread in the first node and its sequentially arranged slots, when any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write set into the slot and triggers the block pointer to point to the next slot adjacent to the slot. Further, when the target analysis thread corresponding to the slot has not completed analyzing a batch of transactions in that slot, it analyzes the batch of transactions according to the pre-execution read / write set and places the analysis results into the slot. Then, when the proposal pointer points to the slot and a batch of transactions in that slot has been analyzed, the proposal thread initiates a block generation proposal for that batch of transactions. Finally, when the block generation proposal passes consensus, the transactions in the slot are cleared, and the proposal pointer is triggered to point to the next slot adjacent to the slot.

[0023] In this scheme, based on the round-robin queue maintained by the proposal thread and its sequentially arranged slots, transactions and their pre-execution read / write sets can be placed into each slot in sequence by moving the block pointer according to the arrangement order of each slot, and each slot can be cleared in sequence. In addition, by moving the proposal pointer according to the arrangement order of each slot, block generation proposals for each batch of transactions can be initiated in sequence. This not only allows the same transaction to be packaged into a block if the proposal passes, but also ensures that the packaging order of each batch of transactions is consistent with the order in which they are placed into the slots (corresponding to the arrangement order of the corresponding slots), thereby realizing the sequential generation of each block.

[0024] As can be seen, this scheme decouples the block generation process for the same batch of transactions into two independent processes: an analysis process (for the pre-execution read / write set) completed by multiple analysis threads and a proposal process (for the batch of transactions) completed by a proposal thread. The block generation processes for different batches of transactions can also be decoupled in this way, allowing multiple analysis threads to complete the analysis process for a batch of transactions sequentially, and the proposal thread to complete the proposal process for a batch of transactions sequentially. This ultimately achieves a "pipeline-like" sequential, asynchronous, and parallel packaging of batch transactions. While ensuring that each batch of transactions is packaged sequentially to generate corresponding blocks, this scheme effectively improves the overall efficiency of the block generation process, contributing to the overall transaction execution efficiency of the blockchain network and thus increasing the network's throughput. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of a blockchain network provided in an exemplary embodiment.

[0027] Figure 2 This is a flowchart of a method for generating blocks provided in an exemplary embodiment.

[0028] Figure 3 This is a schematic diagram of the structure of a first node provided in an exemplary embodiment.

[0029] Figure 4 This is a schematic diagram illustrating the state changes of each slot in a rotating queue, provided as an exemplary embodiment.

[0030] Figure 5 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0031] Figure 6 This is a block diagram of a message broadcasting device provided in an exemplary embodiment. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0033] Figure 1 This is a schematic diagram of a blockchain network provided in an exemplary embodiment. (As shown) Figure 1 As shown, a blockchain network is a distributed network built from multiple nodes. It involves peer-to-peer (P2P) communication between any two nodes at the application layer. For example, any two nodes from n1 to n5 can communicate at the application layer via a P2P network. The blockchain network utilizes a chain-like block structure to construct a decentralized (or multi-centralized) distributed ledger, which is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Therefore, the blockchain network needs to solve the problem of consistency and correctness of the ledger data on multiple decentralized (or multi-centralized) nodes. Given this, each node in the blockchain network runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby ensuring consistent execution results for the same transactions by all loyal nodes. Transactions are packaged into blocks, and the world state is updated based on the execution results of the same transactions. The current mainstream consensus mechanisms include, but are not limited to: Proof of Work (POW), Proof of Stake (POS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

[0034] Any blockchain node in the blockchain network can contain multiple processes, each of which can perform different functions. The blockchain node can participate in blockchain transactions such as initiating transactions, synchronizing transactions, initiating proposals, packaging blocks, and executing transactions by running these processes. For example, it may include an access process for providing access services, a caching process for providing caching services, a pre-execution process for providing pre-execution services, a network process for providing network services, a consensus process for providing consensus services, a control process for providing block management services, a storage process for providing storage services, and multiple computing processes for providing computing services (executing data computing tasks related to transactions). Each process can contain at least one thread, such as a main thread and auxiliary threads.

[0035] Furthermore, the nodes in the blockchain network can form a master-slave structure during the block generation process, meaning the network can contain both master and slave nodes. It should be noted that any node, whether master or slave, can be implemented as any device, platform, equipment, or cluster of devices with computing / processing capabilities.

[0036] To address the aforementioned problems in related technologies, this specification proposes a method for generating blocks. The method involves the proposal thread of the first node maintaining a rotating queue containing multiple slots. The proposal thread and the analysis thread cooperate to trigger updates to the block formation pointer and proposal pointer of the rotating queue, thereby realizing the packaging process of different batches of transactions. Each batch of transactions is sequentially packaged to generate the corresponding block. The block generation scheme is described in detail below with reference to the accompanying drawings.

[0037] Figure 2 This is a flowchart illustrating a method for generating blocks, provided in an exemplary embodiment. The method is applied to a first node in a blockchain network. The first node, acting as the node initiating the proposal, can be any blockchain node in the blockchain network. For example, the first node can be the master node of the blockchain network, or it can be any slave node. It should be noted that whether the first node is a master node or a slave node does not affect the implementation of the embodiments described in this specification; the following description uses the first node as a master node as an example.

[0038] Furthermore, the first node can contain multiple threads, such as a proposal thread and multiple analysis threads. The proposal thread maintains a round-robin queue with multiple slots arranged sequentially, each slot corresponding to one analysis thread. The proposal thread and the multiple analysis threads can belong to the same process or different processes. When the proposal thread belongs to the same process, it can be the main thread within that process, and the multiple analysis threads can be auxiliary processes within that process. In this case, the proposal thread, in addition to initiating proposals, can also manage the round-robin queue and the various analysis threads. Similarly, the multiple analysis threads can belong to the same process to facilitate efficient management by the first node; of course, they can also belong to different processes. It is understood that these multiple analysis threads are the foundation for this scheme's ability to achieve "parallel" packaging of different blocks.

[0039] Because both the number of analysis threads and the number of slots in the rotating queue are multiple and correspond to each other, their numbers may affect the correspondence between them. For example, when the number of slots is the same as the number of analysis threads, there is a one-to-one correspondence between the slots and the analysis threads, and each slot corresponds to a different analysis thread. As another example, when the number of slots is greater than the number of analysis threads, multiple slots may correspond to the same analysis thread. Therefore, the relationship between the analysis threads and the slots satisfies a one-to-one or one-to-many relationship: any analysis thread may correspond to one or more slots, while any slot corresponds to only one analysis thread. However, it should be noted that regardless of the correspondence between slots and analysis threads, each analysis thread is only responsible for analyzing transactions placed in its own (at least one) corresponding slot, and will not analyze transactions placed in other slots.

[0040] like Figure 3 As shown, the first node contains a proposal thread and n analysis threads (i.e., analysis thread 1, analysis thread 2, ..., analysis thread n), and the round-robin queue maintained by the proposal thread contains n slots (i.e., slot 1, slot 2, ..., slot n), where n is an integer greater than 1. Clearly, at this point, the n slots correspond one-to-one with the n analysis threads. Furthermore, the proposal thread and the multiple analysis threads all belong to the same process, namely the proposal process. It should be noted that... Figure 3 The round-robin queue shown is drawn within the proposal process only to illustrate the correspondence between the proposal thread and the round-robin queue, and between the analysis thread and the slot, and does not indicate that the round-robin queue belongs to the proposal process. Of course, from outside the proposal process, the round-robin queue can also be considered to be maintained by the proposal process. Furthermore, Figure 3The first node shown also includes several other processes, such as a pre-execution process for pre-executing transactions, a caching process for caching transactions and their pre-execution results, and a consensus process for participating in inter-node consensus. The specific functions of each process can be found in the following embodiments, which will not be elaborated here.

[0041] In the embodiments of this specification, multiple slots in the rotating queue are arranged cyclically according to a preset order. In the arrangement of the slots, the first slot is sequentially connected to the last slot (or adjacent), and the slot following the next slot is the first slot. Logically, the slots form a circular space; in other words, the rotating queue is a circular queue. Figure 3 As shown, in the case of n slots, the next slot after slot n is slot 1. Figure 4 It more intuitively illustrates the arrangement of multiple slots in the rotating queue, such as Figure 4 As shown in Figure a, the circular rotating queue contains 8 slots (as shown in the sector). The slots are arranged sequentially in the order of 1, 2, ..., 8, with slot 1 being the next slot after slot 8. This order corresponds to the movement order of the block pointer (i.e., propose_pos) and the proposal pointer (group_pos). The state change process of each slot can be found in the description of the following embodiment, and will not be repeated here.

[0042] It should be noted that the block pointer and proposal pointer can be considered as two parameters of the round-robin queue. Both are used to point to various slots in the round-robin queue, and the pointed-to slots can move according to the aforementioned arrangement of slots, moving one slot forward each time. At any given time, the block pointer points to the slot where a batch of transactions (and its pre-execution read / write set) is being placed, or to the slot where a batch of transactions needs to be placed next after the current time; the proposal pointer points to the slot where a proposal is being initiated or where the initiated proposal has not yet passed consensus, or to the slot where a proposal needs to be initiated next after the current time.

[0043] Furthermore, depending on whether a transaction (and its pre-execution read / write set) is placed in the slot and the analysis status of the placed transaction, each slot has three states: empty, incomplete analysis (a batch of transactions has been placed but has not yet been analyzed by the corresponding slot), and completed analysis (a batch of transactions has been placed and has been analyzed by the corresponding slot). As the proposal thread and analysis thread process (analyze and propose) the transactions in each slot, the state of each slot sequentially transitions between the above three states, simultaneously triggering the movement of the block pointer and proposal pointer between slots, thus forming a parallel and asynchronous proposal and block generation process for multiple batches of transactions. In the above process, the current state transition of any slot is: empty → incomplete analysis → completed analysis → empty → … It can be seen that the above three states also logically constitute a circular space, and the current state of any slot jumps unidirectionally within this space.

[0044] In one embodiment, the proposal thread or the analysis thread corresponding to any slot can determine the current state of the slot in various ways. For example, it can read whether a transaction is recorded in the storage space corresponding to the slot: if no transaction is recorded, the slot is determined to be empty; conversely, if data is recorded, the data content can be further determined. If the data does not contain the analysis result of the transaction, the slot is in an incomplete analysis state; otherwise, if the data contains the analysis result of the transaction, the slot is in a completed analysis state.

[0045] In another embodiment, each slot can be configured with a status identifier, the value of which is called a status value. Based on this, different values ​​can be configured for the status to represent the current state of the slot. For example, if any slot is empty, its status value can be configured as a first value, such as "0"; if any slot is in an incomplete analysis state, its status value can be configured as a second value, such as "1"; and if any slot is in a completed analysis state, its status value can be configured as a third value, such as "2". Thus, the proposal thread or the analysis thread corresponding to any slot can determine the current state of the slot based on its specific status value at the current moment. By configuring the slot's status value, the proposal thread can use this status value to transmit the slot's state at any given time to itself or the analysis thread corresponding to the slot across time intervals, facilitating a quick and efficient determination of the state of any slot at any given time, and helping to improve the overall block generation efficiency.

[0046] The specific process of block generation will be described in detail below with reference to the accompanying drawings and several embodiments. For example... Figure 2As shown, the method for generating blocks includes steps 202 to 206. It should be noted that the method for generating blocks described in this specification can be applied to each slot in a rotating queue; the following embodiments only use one embodiment (i.e., any one of the slots) as an example for illustration.

[0047] Step 202: When any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write sets into the slot and triggers the block pointer to point to the next slot adjacent to the slot.

[0048] As mentioned earlier, the current state of a slot can be determined based on its state value. In one embodiment, if a proposal to generate a block for a batch of transactions in any slot passes consensus, the proposal thread can clear the batch of transactions in that slot (correspondingly, the slot's state changes from "analyzed complete" to "empty"), and adjust the slot's state value to the first value after clearing. Accordingly, if the state value of any slot is the first value, the proposal thread can determine that the slot is empty, i.e., determine that the slot is in an empty state.

[0049] In one embodiment, the first node may further include a pre-execution process and a caching process. For transactions initiated by various nodes in the blockchain network, the first node, after acquiring them, can have them managed by the caching process. Based on this, the pre-execution process can obtain the transactions from the caching process, pre-execute the acquired transactions, and then return the corresponding pre-execution results to the caching process for storage. The pre-execution result of any transaction may include the execution result of the transaction itself, as well as the pre-execution process or the pre-execution read / write set corresponding to the execution result. Therefore, the caching process can maintain the pre-execution read / write sets obtained by executing each transaction with the pre-execution result. Furthermore, the proposal thread can, when any slot pointed to by the block pointer is empty, obtain a batch of transactions and their pre-execution read / write sets from the caching process and place them into that slot. It is understood that the pre-execution read / write sets of this batch of transactions may include the pre-execution read / write sets of each transaction within this batch.

[0050] As the foregoing analysis shows, a batch of transactions placed in the same slot will be packaged into a single block after the block generation proposal is approved, and then executed. To this end, the proposal thread can retrieve these transactions sequentially according to their transaction numbers to ensure the continuity of the execution process for each transaction within the same batch, thereby increasing the success rate of each transaction during actual execution. It should be noted that the pre-execution process of any transaction before it is packaged into a block and its actual execution process after being packaged into a block are generally identical in terms of the data they rely on and the execution results. The only difference lies in the timing of execution and their respective roles within the blockchain network.

[0051] Each transaction that has been pre-executed in the first node can be recorded in a transaction list. If the first node includes a caching process, this transaction list can be maintained by the caching process. During the operation of the first node, pre-executed transactions can be continuously added to the transaction list in chronological order. For any two adjacent slots, assuming the proposal thread places a batch of transactions from the transaction list into the preceding slot at the first moment, and places a new batch of transactions into the following slot at the second moment after a certain period, the new batch of transactions will typically include the transactions that were added to the transaction list during that period. In addition, to improve block generation efficiency and subsequent transaction execution efficiency, any block generated in the blockchain network is usually limited in the number of transactions (i.e., the total number of transactions packaged into the block) and / or the amount of transaction data (i.e., the total data size of all transactions packaged into the block).

[0052] In response, upon determining that any slot pointed to by the block pointer is empty at the current moment, the proposal thread can further determine the current number of transactions recorded in the transaction queue. If the current number is not less than a quantity threshold, the transactions within the specified quantity threshold are grouped into a batch of transactions, and this batch of transactions and its pre-execution read / write set are placed into the specified slot. It is understood that the quantity threshold can be reasonably set based on the actual situation of the blockchain network's scale, consensus time, communication latency, and the data processing capability of the first node. This specification does not limit its specific value in the embodiments; for example, it can be 256, 500, 100, etc. This method ensures that the number of transactions contained in any generated block is the same or close, facilitating subsequent block processing.

[0053] And / or, at the current moment when it is determined that any slot pointed to by the block pointer is empty, the proposal thread can further determine the current data volume of transactions recorded in the transaction queue, and if the current data volume is not less than a data volume threshold, the transactions recorded in the transaction queue that exceed the data volume threshold are treated as a batch of transactions, and this batch of transactions and their pre-execution read / write sets are placed into the slot. Similarly, the data volume threshold can also be reasonably set according to the above actual situation. The specific value of the threshold is not limited in the embodiments of this specification. For example, it can be 4MB, 1MB, 10MB, etc. In this way, it can be ensured that the transaction data volume contained in any generated block is the same or close, which facilitates subsequent processing.

[0054] It should be noted that the number of transactions in a batch can be limited only by the aforementioned quantity threshold, or the total data volume of a batch of transactions can be limited only by the aforementioned data volume threshold, or both the aforementioned quantity threshold and data volume threshold can be used to limit a batch of transactions. Furthermore, to ensure a relatively stable block generation time (i.e., the interval between the generation times of two adjacent blocks) in the blockchain network, the proposal thread can also place a batch of transactions and its pre-execution read / write set into any of the aforementioned slots at time intervals.

[0055] For example, if the number of transactions in a batch is limited only according to the aforementioned quantity threshold, and the current number is less than the quantity threshold, the proposal thread can further determine the time interval between the current time and the time when the first transaction in the transaction queue was placed. If this time interval is not less than a first duration, then all transactions recorded in the transaction queue can be considered as a batch of transactions, and this batch of transactions and its pre-execution read-write set can be placed into any of the slots. Alternatively, the proposal thread can also further determine the time interval between the current time and the time when the previous block was packaged. If this time interval is not less than a first duration, then all transactions recorded in the transaction queue can be considered as a batch of transactions, and this batch of transactions and its pre-execution read-write set can be placed into any of the slots. Furthermore, if the number of transactions in a batch is limited only according to the aforementioned data volume threshold, and the current number is less than the data volume threshold, the proposal thread can also determine the aforementioned time interval. Then, if this time interval is not less than a first duration or a second duration, then all transactions recorded in the transaction queue can be considered as a batch of transactions, and this batch of transactions and its pre-execution read-write set can be placed into any of the slots. In this way, for the current block formation time of a batch of transactions placed in any of the slots, and the previous block formation time of a batch of transactions placed in the previous slot, the time interval between the current block formation time and the previous block formation time can approach the aforementioned first duration (or second duration). Therefore, by setting the first duration (or second duration) to be equal to or close to the expected block generation time of the blockchain network, the block generation efficiency of generating each block sequentially according to the block generation time can be achieved. For example, the first duration (or second duration) can be set to 0.5s, 0.2s, 2s, etc.

[0056] like Figure 4 As shown in Figure a, the round-robin queue (circular) contains 8 slots (sector-shaped), numbered sequentially from 1 to 8, and arranged cyclically in the order 1→2→3→4→5→6→7→8→1→2… as indicated by the arrows in the figure. Here, `propose_pos` is the block pointer, `group_pos` is the proposal pointer, and `start_point` is the starting position of the round-robin queue, i.e., the position of slot 1.

[0057] exist Figure 4At the initial moment shown in Figure a, all slots are empty, and both `propose_pos` and `group_pos` point to the start and end positions. Since slot 1, pointed to by `propose_pos`, is empty (satisfying the aforementioned condition), a batch of transactions and their pre-execution read / write sets can be placed into slot 1 in this empty state (causing slot 1 to change from an empty state to an unanalyzed state). After the placement is completed, `propose_pos` is triggered to point to the adjacent slot 2 (i.e., the next slot adjacent to slot 1). The situation after the placement and update are as follows... Figure 4 As shown in b, at this time, propose_pos points to slot 1 (in an unanalyzed state), and group_pos still points to slot 1 (in slot 1).

[0058] It should be noted that the reason for placing a batch of transactions and their pre-execution read / write sets into any slot is to facilitate the target analysis thread corresponding to that slot in obtaining and analyzing these transactions and their pre-execution read / write sets. To achieve this, these transactions and their pre-execution read / write sets can be written to a preset storage space corresponding to the slot, so that the target analysis thread can read them from that storage space; alternatively, the current storage address of these transactions and their pre-execution read / write sets can be bound to the slot, so that the target analysis thread can find and read these transactions and their pre-execution read / write sets according to the current storage address. This embodiment does not limit the specific method by which the proposing thread places these transactions and their pre-execution read / write sets into the slot.

[0059] Placing a batch of transactions and their pre-execution read-write sets into any of the slots will cause a state transition in that slot, changing it from an empty state to an incomplete analysis state. To ensure that the target analysis thread corresponding to that slot is aware of this state transition, it can be notified in several ways. As mentioned earlier, the current state of any slot can be determined based on its state value. Therefore, the proposal thread can update the state value of any slot to a second value after placing it into the slot, so that the target analysis thread determines that the batch of transactions in that slot is incomplete analysis when the state value is the second value. Alternatively, the target analysis thread can be notified by sending a message. For example, after placing a batch of transactions and their pre-execution read-write sets into any of the slots, the proposal thread can send a placement completion notification message to the target analysis thread, so that the target analysis thread determines that the batch of transactions in that slot is incomplete analysis upon receiving the placement completion notification message.

[0060] Step 204: If a batch of transactions in any slot has not been analyzed, the target analysis thread corresponding to any slot analyzes the batch of transactions according to the pre-execution read-write set and puts the analysis results into the slot.

[0061] As previously mentioned, the target analysis thread can determine that a batch of transactions in any slot has not been analyzed if the status value of any slot is the second value (or changes from the first value to the second value), or if it receives the placement completion notification message sent by the proposal thread. In this case, the target analysis thread can obtain this batch of transactions and its pre-execution read / write set, and analyze the batch of transactions based on the pre-execution read / write set.

[0062] In one embodiment, a batch of transactions placed into any slot may include multiple transactions. Obviously, the execution read / write set of this batch of transactions includes the execution read / write sets of the multiple transactions. Therefore, the target analysis thread can determine the dependencies between each transaction based on the pre-execution read / write sets of the multiple transactions. Specifically, for any two transactions among the multiple transactions, if the pre-execution process of transaction 1 requires data related to transaction 2 (such as transaction content, intermediate data of the pre-execution process, the execution result of the transaction itself, execution read / write set, etc.), then a dependency relationship exists between transaction 1 and transaction 2; specifically, transaction 1 depends on transaction 2. Of course, when the number of transactions in this batch is large, there may be multiple transactions depending on the same transaction or a single transaction depending on multiple transactions, etc. This embodiment does not limit the specific content of the dependency relationship. Based on the above dependency relationship, the proposal thread can divide the multiple transactions into at least one transaction group, wherein multiple transactions with dependencies are grouped into the same transaction group, and multiple transactions without dependencies are grouped into different transaction groups. Understandably, grouping dependent transactions into the same transaction group ensures that these dependent transactions are executed uniformly (e.g., by the same computation process), thus helping to ensure that transactions are executed in sequence and mitigating execution errors to some extent. Conversely, grouping undependent transactions into different transaction groups allows unrelated transactions to be executed concurrently, thereby improving the overall execution efficiency of the transactions within the generated block (i.e., this batch of transactions).

[0063] The pre-execution read / write set of any transaction may include a pre-execution read set and / or a pre-execution write set, whereby the pre-execution read set and pre-execution write set are used to characterize read and write operations on the state data contained in the smart contract, respectively (i.e., the pre-execution read set characterizes read operations on the state data, and the pre-execution write set characterizes write operations on the state data). Based on this, when the pre-execution read / write set of any transaction includes a pre-execution write set for any state data (i.e., indicating that a write operation on the state data needs to be performed during the execution of the transaction), the target analysis thread can determine at least one other transaction (within this batch of transactions) corresponding to all pre-execution read sets and pre-execution write sets for the state data within the pre-execution read / write set of this batch of transactions. For example, if a pre-execution read set for any state data is determined within the pre-execution read / write set of this batch of transactions, the transaction corresponding to that pre-execution read set is further determined (i.e., a read operation on the state data will be performed during the execution of this transaction, thereby generating the pre-execution read set; this transaction is another transaction distinct from the transaction mentioned above). The method for determining other transactions corresponding to the pre-execution write set is similar and will not be repeated here.

[0064] It is understood that any transaction that has no dependency on any other transaction cannot have its corresponding "other transactions" determined through the above method—this transaction can be separately classified into a transaction group (i.e., the transaction group contains only this one transaction). This transaction can satisfy one of the following conditions: the state data involved in the write operation of this transaction will not be read or written by other transactions in this batch; the state data involved in the read operation of this transaction will not be written by other transactions in this batch; the state data involved in the read operation of this transaction is only read by other transactions in this batch, etc. Of course, "any state data being read or written by any transaction" should be understood as "during the execution of this transaction by a blockchain node (specifically, a computing process within that node), a read operation or write operation will be performed on this data," this is hereby clarified.

[0065] After analyzing the batch of transactions using the above method, the target analysis thread can place the corresponding analysis results into any of the slots. Specifically, the execution results can be placed into the slot along with the batch of transactions, or to save space, only the execution results can be placed into the slot. This embodiment of the specification does not limit this.

[0066] It is understood that placing the execution result into any slot will cause a state transition of that slot, changing it from an unanalyzed state to an analyzed complete state. To ensure that the proposal thread is aware of this state transition, the target analysis thread can notify the proposal thread in various ways. As mentioned earlier, the current state of any slot can be determined based on its state value. Therefore, after placing the analysis result into any slot, the target analysis thread can update the state value of that slot to a third value, allowing the proposal thread to determine that a batch of transactions in that slot has been analyzed successfully when the state value is the third value. Alternatively, after placing the analysis result into any slot, the proposal thread can also send an analysis completion notification message for that slot, allowing the proposal thread to determine that a batch of transactions in that slot has been analyzed successfully upon receiving the analysis completion notification message.

[0067] Following the foregoing embodiments, such as Figure 4 As shown in Figure c, when the condition "a batch of transactions in slot 1 has not been analyzed" is met, the analysis thread 1 corresponding to slot 1 starts analyzing this batch of transactions in slot 1, causing slot 1 to change from an incomplete analysis state to an analyzed complete state; after the analysis is completed, the analysis results of this batch of transactions are placed into slot 1, causing slot 1 to change from an analyzed complete state to an empty state (not shown in the figure).

[0068] Step 206: When the proposal pointer points to any slot and a batch of transactions in that slot has been analyzed, the proposal thread initiates a block generation proposal for that batch of transactions; and when the block generation proposal passes consensus, the transactions in any slot are cleared, and the proposal pointer is triggered to point to the next slot adjacent to the slot.

[0069] If the proposal pointer points to any of the slots, the proposal thread can determine that a batch of transactions in that slot has been analyzed successfully, either when the state value of that slot is the third value (or changes from the second value to the third value) or when it receives the analysis completion notification message sent by the target analysis thread. At this time, the proposal thread can initiate a block generation proposal for this batch of transactions in that slot. This proposal may include the batch of transactions placed in that slot, the pre-execution read / write set of these transactions, and the analysis results obtained by the target analysis thread. Subsequently, each node in the blockchain network can participate in the consensus process for generating the block proposal. For example, the first node can achieve this through its included consensus process; the specific process can be found in relevant technical documentation and will not be elaborated here.

[0070] The block generation proposal may pass consensus or fail. If the block generation proposal passes consensus, the proposal thread can clear the transactions in any of the slots and trigger the proposal pointer to point to the next slot adjacent to that slot.

[0071] In one embodiment, for the next slot of any given slot, to ensure that the condition "the next slot pointed to by the block pointer is empty" is met, thus facilitating the proposal thread to insert a batch of transactions and their pre-execution read / write set into the next slot, the proposal thread can process this in various ways. For example, the proposal thread can also directly trigger the block pointer to point to the next slot when the block generation proposal consensus is passed. Since "the next slot pointed to by the block pointer is not empty," the above condition is not yet met. Therefore, the proposal thread can wait for the condition "the proposal pointer points to any given slot and a batch of transactions in that slot has been analyzed" to be met before starting processing according to step 206, which will not be elaborated further.

[0072] For example, the proposal thread can determine the current state of the next slot: if the next slot is empty (e.g., its state value is the first value), it indicates that the next slot can be processed. Alternatively, if the next slot is not empty at the current moment (indicating that a transaction has been analyzed or proposed in the next slot, and the slot has not yet been cleared), the proposal thread can wait for a preset number of consecutive slots, including the next slot, to be cleared before triggering the block pointer to point to the next slot. The preset number is at least 1 and at most the number of slots in the round-robin queue. This method ensures that once the block pointer points to the next slot, the condition "the next slot pointed to by the block pointer is empty" is immediately met, allowing the proposal thread to begin processing the next slot as quickly as possible. When the preset number is greater than 1, a larger interval can be reserved between the block pointer and the proposal pointer, thereby reducing the number of pauses and waits for the block pointer.

[0073] Following the aforementioned embodiment, after analysis thread 1, corresponding to slot 1, places the analysis results of this batch of transactions in slot 1 into that slot, the condition "group_pos points to slot 1 and a batch of transactions in that slot has been analyzed" is immediately met. At this time, the proposal thread can initiate a block generation proposal for this batch of transactions in slot 1. After the proposal consensus is passed, slot 1 is cleared, and group_pos is triggered to point from slot 1 to slot 2, as follows. Figure 4 As shown in c.

[0074] Continuing with the previous embodiment, assuming the proposal thread spends less time placing transactions and their pre-execution read / write sets into the slot, while waiting for the analysis thread corresponding to the slot to analyze the transactions in the slot, and to initiate a block generation proposal and wait for its consensus to pass, will take longer. This will cause `propose_pos` to move faster relative to `propose_pos`. After placing a batch of transactions and their pre-execution read / write sets into slot 2, the proposal thread can trigger `propose_pos` to point to slot 3; because slot 3 is empty at this time, the proposal thread can further place a batch of transactions and their pre-execution read / write sets into slot 3, and after placing them, trigger `propose_pos` to point to slot 4, and then place a batch of transactions and their pre-execution read / write sets into slot 4. For example... Figure 4 As shown in d, at this time, the faster-moving propose_pos points to slot 4, while the slower-moving group_pos still points to slot 2—lagging behind propose_pos by three slots.

[0075] Following the above process, the proposal thread continues to sequentially add a batch of transactions and their pre-execution read / write sets to each empty slot, triggering `propose_pos` to move forward slot by slot. Simultaneously, the proposal thread waits for the analysis thread corresponding to the slot pointed to by `group_pos` to complete its analysis in order to initiate a block generation proposal, and then waits for consensus to pass (if consensus fails, it needs to wait for a period of time before retrying). Therefore, the position of `group_pos` gradually lags behind `propose_pos`. As the position between `propose_pos` and `group_pos` gradually increases, until at a certain moment both `propose_pos` and `group_pos` point to slot 4, they "reunite." At this point, `propose_pos` exceeds `group_pos` by 8 slots (i.e., `group_pos` is "circled" by `propose_pos`), as shown below. Figure 4 As shown in e. Since the condition "the slot pointed to by propose_pos is empty" is not met, propose_pos cannot continue forward. It can start waiting for the block corresponding to slot 4 to generate a consensus proposal and then clear slot 4 (at this time, group_pos points to slot 5), as shown in the figure. Figure 4 As shown in f. At this point, the proposal thread can immediately begin placing a new batch of transactions and their pre-execution read / write sets into slot 4 and updating propose_pos to point to slot 5, or it can wait a longer time, such as when group_pos points to slot 7 or slot 8 (determined according to the aforementioned preset number) before starting to place a new batch of transactions and their pre-execution read / write sets into slot 4 and updating propose_pos to point to slot 5.

[0076] In one embodiment, if the block generation proposal passes consensus, it means that the number of nodes in the blockchain network that agree to package the transactions in any slot into a block meets the consensus condition (determined by the consensus algorithm used by the blockchain network). At this point, the proposal thread can package these transactions into a block based on the analysis results. This block can then be considered the latest block in the current blockchain ledger, meaning it is recorded in the blockchain ledger of the first node. Of course, other nodes in the blockchain network will also generate the same block and record it in their own maintained blockchain ledgers.

[0077] In one embodiment, if the block generation proposal fails to pass consensus, the proposal thread can wait for a third time interval before re-initiating a block generation proposal for this batch of transactions. For the re-initiated block generation proposal, if consensus is reached, it is processed according to step 206; otherwise, it waits for another third time interval or another duration before attempting to re-initiate the block generation proposal, until consensus is reached. Of course, to avoid entering an infinite loop in the processing logic, an upper limit can be set on the number of times a block generation proposal can be initiated, and if the upper limit is exceeded, the transactions in any slot can be forcibly cleared, and the proposal pointer can be triggered to point to the next slot adjacent to that slot.

[0078] Through the above embodiments, based on the round-robin queue maintained by the proposal thread in the first node and its sequentially arranged slots, when any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write set into the slot and triggers the block pointer to point to the next slot adjacent to the slot. Further, when the target analysis thread corresponding to the slot has not completed analyzing a batch of transactions in that slot, it analyzes the batch of transactions according to the pre-execution read / write set and places the analysis results into the slot. Then, when the proposal pointer points to the slot and a batch of transactions in that slot has been analyzed, the proposal thread initiates a block generation proposal for that batch of transactions. Finally, when the block generation proposal passes consensus, the transactions in the slot are cleared, and the proposal pointer is triggered to point to the next slot adjacent to the slot.

[0079] In this scheme, based on the round-robin queue maintained by the proposal thread and its sequentially arranged slots, transactions and their pre-execution read / write sets can be placed into each slot in sequence by moving the block pointer according to the arrangement order of each slot, and each slot can be cleared in sequence. In addition, by moving the proposal pointer according to the arrangement order of each slot, block generation proposals for each batch of transactions can be initiated in sequence. This not only allows the same transaction to be packaged into a block if the proposal passes, but also ensures that the packaging order of each batch of transactions is consistent with the order in which they are placed into the slots (corresponding to the arrangement order of the corresponding slots), thereby realizing the sequential generation of each block.

[0080] As can be seen, this scheme decouples the block generation process for the same batch of transactions into two independent processes: an analysis process (for the pre-execution read / write set) completed by multiple analysis threads and a proposal process (for the batch of transactions) completed by a proposal thread. The block generation processes for different batches of transactions can also be decoupled in this way, allowing multiple analysis threads to complete the analysis process for a batch of transactions sequentially, and the proposal thread to complete the proposal process for a batch of transactions sequentially. This ultimately achieves a "pipeline-like" sequential, asynchronous, and parallel packaging of batch transactions. While ensuring that each batch of transactions is packaged sequentially to generate corresponding blocks, this scheme effectively improves the overall efficiency of the block generation process, contributing to the overall transaction execution efficiency of the blockchain network and thus increasing the network's throughput.

[0081] Corresponding to the aforementioned message broadcasting method embodiment, this solution also proposes an embodiment of a blockchain network. The first node in this blockchain network includes a proposal thread and multiple analysis threads. The round-robin queue maintained by the proposal thread contains multiple slots arranged in a sequential, cyclical manner, with each slot corresponding to an analysis thread, wherein:

[0082] When any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write sets into the slot and triggers the block pointer to point to the next slot adjacent to the slot.

[0083] If a batch of transactions in any slot has not been analyzed, the target analysis thread corresponding to any slot analyzes the batch of transactions according to the pre-execution read-write set and puts the analysis results into the slot.

[0084] When the proposal thread points to any slot and a batch of transactions in that slot has been analyzed, it initiates a block generation proposal for that batch of transactions; and when the block generation proposal passes consensus, it clears the transactions in that slot and triggers the proposal thread to point to the next slot adjacent to that slot.

[0085] The specific process of any node generating a block can be found in the detailed description of the aforementioned method embodiments, and will not be repeated here.

[0086] Figure 5 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 5 At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, memory 508, and non-volatile memory 510, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 502 reading the corresponding computer program from the non-volatile memory 510 into memory 508 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0087] like Figure 6 As shown, Figure 6 This is a block diagram of an apparatus for generating blocks according to an exemplary embodiment provided in this specification. This apparatus can be applied to, for example... Figure 5 The device shown implements the technical solution of this specification. The device is applied to a first node in a blockchain network. The first node includes a proposal thread and multiple analysis threads. The proposal thread maintains a rotating queue containing multiple slots arranged in a sequential, cyclical manner, with each slot corresponding to an analysis thread. The device includes:

[0088] The placement unit 601 is used to enable the proposal thread to place a batch of transactions and their pre-execution read / write sets into any slot when the block pointer is empty, and to trigger the block pointer to point to the next slot adjacent to the slot.

[0089] Analysis unit 602 is used to enable the target analysis thread corresponding to any slot to analyze a batch of transactions in any slot if the analysis of such batch of transactions in any slot has not been completed, and to place the analysis results into any slot.

[0090] The proposal unit 603 is configured to enable the proposal thread to initiate a block generation proposal for a batch of transactions when the proposal pointer points to any slot and a batch of transactions in that slot has been analyzed; and, if the block generation proposal passes consensus, to clear the transactions in any slot and trigger the proposal pointer to point to the next slot adjacent to the slot.

[0091] Optional,

[0092] The placement unit 601 is specifically used to: determine that any slot is empty when the state value of any slot is the first value, wherein the state value is updated to the first value by the proposal thread after the previous clearing of the transactions in any slot.

[0093] Optionally, the device further includes:

[0094] The second value update unit 604 is used to enable the proposal thread to update the status value of any slot to a second value after placing a batch of transactions and their pre-execution read / write sets into any slot, so that the target analysis thread determines that a batch of transactions in any slot has not been analyzed in order to complete the analysis when the status value is the second value; or...

[0095] The placement notification unit 605 is used to enable the proposal thread to send a placement completion notification message to the target analysis thread after placing a batch of transactions and their pre-execution read / write sets into any slot, so that the target analysis thread can determine that a batch of transactions in any slot has not been analyzed in order to complete upon receiving the placement completion notification message.

[0096] Optionally, the device further includes:

[0097] The third value update unit 606 is used to enable the target analysis thread to update the state value of any slot to a third value after placing the analysis result into any slot, so that the proposal thread can determine that a batch of transactions in any slot has been analyzed when the state value is the third value; or...

[0098] The analysis notification unit 607 is used to enable the target analysis thread to send an analysis completion notification message for any slot to the proposal thread after placing the analysis result into any slot, so that the proposal thread can determine that a batch of transactions in any slot has been analyzed and completed upon receiving the analysis completion notification message.

[0099] Optionally, the first node also includes a pre-execution process and a cache process.

[0100] The device further includes a pre-execution unit 608, which enables the pre-execution process to obtain transactions initiated in the blockchain network from the caching process, and returns the pre-execution read-write set obtained by pre-executing the transactions to the caching process;

[0101] The placement unit 601 is specifically used to: enable the proposal thread to obtain a batch of transactions and their pre-execution read / write sets from the cache process and place them into any of the slots.

[0102] Optionally, the transaction list maintained by the first node is used to record transactions that are about to be completed, and the insertion unit 601 is specifically used for:

[0103] If the current number of transactions recorded in the transaction queue by the proposal thread is not less than a quantity threshold, then the transactions exceeding the quantity threshold recorded in the transaction queue are treated as a batch of transactions, and this batch of transactions and its pre-execution read / write set are placed into any of the slots; and / or,

[0104] If the current data volume of the transactions recorded by the proposal thread in the transaction queue is not less than the data volume threshold, the transactions with the data volume threshold recorded in the transaction queue are treated as a batch of transactions, and this batch of transactions and their pre-execution read / write set are placed into any of the slots.

[0105] Optionally, the insertion unit 601 is specifically used for:

[0106] If, when the current quantity is less than the quantity threshold and / or the current data volume is less than the data volume threshold, the proposal thread considers all transactions recorded in the transaction queue as a batch of transactions and places this batch of transactions and its pre-execution read / write set into any of the slots, provided that the time interval between the current time and the time when the first transaction in the transaction queue is placed is not less than a first duration, or the time interval between the current time and the time when the previous block is completed is not less than a second duration.

[0107] Optionally, a batch of transactions placed into any of the slots may include multiple transactions, and the analysis unit 602 is specifically used for:

[0108] The analysis thread determines the dependencies between the transactions based on the pre-execution read / write sets of the multiple transactions, and divides the multiple transactions into at least one transaction group based on the dependencies. Transaction groups with dependencies are grouped into the same transaction group, while transaction groups without dependencies are grouped into different transaction groups.

[0109] Optionally, the proposal unit 603 is specifically used for:

[0110] If the next slot is empty at the current moment, the analysis thread will trigger the block pointer to point to the next slot;

[0111] If the analysis thread is not empty at the current time, it waits for a preset number of consecutive slots, including the next slot, to be cleared before triggering the block pointer to point to the next slot.

[0112] Optional, also includes:

[0113] The transaction packaging unit 609 is used to enable the proposal thread to package the batch of transactions into the latest block in the blockchain ledger at the current moment, based on the analysis results, when the block generation proposal passes consensus.

[0114] Optional, also includes:

[0115] The re-proposal unit 610 is used to enable the proposal thread to re-initiate a block generation proposal for this batch of transactions after waiting for a third time period if the block generation proposal fails to pass consensus.

[0116] Optional,

[0117] When the number of slots is the same as the number of analysis threads, each slot corresponds to one analysis thread.

[0118] When the number of slots is greater than the number of analysis threads, there are multiple slots corresponding to the same analysis thread.

[0119] Optionally, the proposal thread and the plurality of execution threads belong to the same process, wherein the proposal thread is the main thread in the process, and the plurality of execution threads are the process itself.

[0120] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0121] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0122] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0123] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0124] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0125] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0126] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0127] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0129] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0130] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for generating blocks, applied to a first node in a blockchain network, the first node comprising a proposal thread and multiple analysis threads, wherein the proposal thread maintains a rotating queue comprising multiple slots arranged in a sequential, cyclical manner, each slot corresponding to an analysis thread, the method comprising: When any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write sets into the slot and triggers the block pointer to point to the next slot adjacent to the slot. If a batch of transactions in any slot has not been analyzed, the target analysis thread corresponding to any slot analyzes the batch of transactions according to the pre-execution read-write set and puts the analysis results into the slot. When the proposal pointer points to any of the slots and a batch of transactions in that slot has been analyzed, the proposal thread initiates a block generation proposal for that batch of transactions. Furthermore, if the block generation proposal passes consensus, the transactions in any of the slots are cleared, and the proposal pointer is triggered to point to the next slot adjacent to any of the slots.

2. The method according to claim 1, The proposal thread determines that any slot is empty, including: If the status value of any slot is the first value, it is determined that the slot is empty. The status value is updated to the first value by the proposal thread after the previous clearing of the transactions in the slot.

3. The method according to claim 1, further comprising: After placing a batch of transactions and their pre-execution read / write sets into any of the slots, the proposal thread updates the status value of any slot to a second value, so that the target analysis thread determines that a batch of transactions in any slot has not been analyzed incomplete when the status value is the second value; or... After placing a batch of transactions and their pre-execution read / write sets into any of the slots, the proposal thread sends a placement completion notification message to the target analysis thread, so that the target analysis thread can determine that a batch of transactions in any of the slots has not been analyzed in order to complete the analysis upon receiving the placement completion notification message.

4. The method according to claim 1, further comprising: After placing the analysis results into any slot, the target analysis thread updates the status value of any slot to a third value, so that the proposal thread can determine that a batch of transactions in any slot has been analyzed when the status value is the third value. or, After placing the analysis results into any of the slots, the target analysis thread sends an analysis completion notification message for any of the slots to the proposal thread, so that the proposal thread can determine that a batch of transactions in any of the slots has been analyzed and completed upon receiving the analysis completion notification message.

5. The method according to claim 1, wherein the first node further comprises a pre-execution process and a caching process. The method further includes: The pre-execution process obtains transactions initiated in the blockchain network from the caching process and returns the pre-execution read-write set obtained by pre-executing the transactions to the caching process; The proposal thread places a batch of transactions and their pre-execution read-write sets into any of the slots, including: obtaining a batch of transactions and their pre-execution read-write sets from the caching process and placing them into any of the slots.

6. The method according to claim 1, wherein the transaction list maintained by the first node is used to record transactions that have been pre-executed, and the proposal thread places a batch of transactions and their pre-execution read / write sets into any of the slots, including: If the current number of transactions recorded in the transaction list is not less than a quantity threshold, then the transactions reaching the quantity threshold recorded in the transaction list are treated as a batch of transactions, and this batch of transactions and its pre-execution read / write set are placed into any of the slots; and / or, If the current data volume of the transactions recorded in the transaction list is not less than the data volume threshold, the transactions with the data volume threshold recorded in the transaction list are regarded as a batch of transactions, and this batch of transactions and their pre-execution read-write set are placed into any of the slots.

7. The method according to claim 6, wherein the proposal thread places a batch of transactions and their pre-execution read / write sets into any of the slots, comprising: If the current quantity is less than the quantity threshold and / or the current data volume is less than the data volume threshold, and if the time interval between the current time and the time when the first transaction in the transaction list is placed is not less than the first duration, or the time interval between the current time and the time when the previous block is completed is not less than the second duration, then all transactions recorded in the transaction list are treated as a batch of transactions, and this batch of transactions and its pre-execution read / write set are placed into any of the slots.

8. The method according to claim 1, wherein a batch of transactions placed in any of the slots includes multiple transactions, and the target analysis thread analyzes this batch of transactions according to the pre-execution read / write set, including: The dependencies between the transactions are determined based on the pre-execution read / write sets of the multiple transactions, and the multiple transactions are divided into at least one transaction group based on the dependencies. Transactions with dependencies are grouped into the same transaction group, and transactions without dependencies are grouped into different transaction groups.

9. The method according to claim 1, wherein the proposal thread triggers the block pointer to point to the next slot adjacent to any of the slots, comprising: If the next slot is empty at the current moment, the block pointer is triggered to point to the next slot; If the next slot is not empty at the current moment, wait for a preset number of consecutive slots, including the next slot, to be cleared before triggering the block pointer to point to the next slot.

10. The method according to claim 1, further comprising: If the block generation proposal passes consensus, the block pointer packages these transactions into the latest block in the blockchain ledger at the current moment based on the analysis results.

11. The method according to claim 1, further comprising: If the block generation proposal fails to pass consensus, a new block generation proposal for this batch of transactions will be initiated after a third period of time.

12. The method according to claim 1, When the number of slots is the same as the number of analysis threads, each slot corresponds to one analysis thread. When the number of slots is greater than the number of analysis threads, there are multiple slots corresponding to the same analysis thread.

13. The method according to claim 1, wherein the proposal thread and the plurality of analysis threads belong to the same process, wherein, The proposal thread is the main thread in this process, and the multiple analysis threads are auxiliary threads in this process.

14. A blockchain network, wherein a first node in the blockchain network comprises a proposal thread and multiple analysis threads, the proposal thread maintaining a round-robin queue comprising multiple slots arranged in a sequential, cyclic manner, each slot corresponding to an analysis thread, wherein: When any slot pointed to by the block pointer is empty, the proposal thread places a batch of transactions and their pre-execution read / write sets into the slot and triggers the block pointer to point to the next slot adjacent to the slot. If a batch of transactions in any slot has not been analyzed, the target analysis thread corresponding to any slot analyzes the batch of transactions according to the pre-execution read-write set and puts the analysis results into the slot. When the proposal pointer points to any of the slots and a batch of transactions in that slot has been analyzed, the proposal thread initiates a block generation proposal for that batch of transactions. Furthermore, if the block generation proposal passes consensus, the transactions in any of the slots are cleared, and the proposal pointer is triggered to point to the next slot adjacent to any of the slots.

15. An apparatus for generating blocks, applied to a first node in a blockchain network, the first node comprising a proposal thread and multiple analysis threads, the proposal thread maintaining a rotating queue comprising multiple slots arranged in a sequential, cyclic manner, each slot corresponding to an analysis thread, the apparatus comprising: The placement unit is used to enable the proposal thread to place a batch of transactions and their pre-execution read / write sets into any slot when the block pointer is empty, and to trigger the block pointer to point to the next slot adjacent to the slot. The analysis unit is configured to enable the target analysis thread corresponding to any slot to analyze a batch of transactions in any slot without completing the analysis, based on the pre-execution read / write set, and to place the analysis results into any slot. The proposal unit is used to enable the proposal thread to initiate a block generation proposal for a batch of transactions when the proposal pointer points to any slot and a batch of transactions in that slot has been analyzed. Furthermore, if the block generation proposal passes consensus, the transactions in any of the slots are cleared, and the proposal pointer is triggered to point to the next slot adjacent to any of the slots.

16. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-13 by executing the executable instructions.

17. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-13.

Images