Consensus method in blockchain system, blockchain node, and blockchain system

Abstract

A consensus method in a blockchain system, a blockchain node, and a blockchain system. The blockchain system comprises a first node and a plurality of second nodes. The method comprises: the first node acquiring a first transaction from a transaction pool, broadcasting the first transaction in the blockchain system, generating a consensus proposal in parallel along with the broadcasting of the first transaction, wherein the consensus proposal comprises a transaction identifier of the first transaction, and sending the consensus proposal to other blockchain nodes; after receiving the consensus proposal, each second node determining whether the first transaction is received; and when it is determined that the first transaction is received, participating in the consensus of the consensus proposal.

Description

Consensus methods, blockchain nodes, and blockchain systems in blockchain systems

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on October 31, 2023, with application number 202311436051.4 and application name “Consensus Method, Blockchain Node and Blockchain System in Blockchain System”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a consensus method, blockchain nodes, and blockchain system in a blockchain system. Background Art

[0003] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

[0004] Summary of the Invention

[0005] The present invention aims to provide a consensus method in a blockchain system to improve the consensus efficiency in the blockchain system while ensuring transaction availability.

[0006] A first aspect of this specification provides a consensus method in a blockchain system, wherein the blockchain system includes a first node and multiple second nodes, and the method includes:

[0007] The first node obtains a first transaction from a transaction pool, broadcasts the first transaction in the blockchain system, generates a consensus proposal in parallel with broadcasting the first transaction, the consensus proposal including a transaction identifier of the first transaction, and sends the consensus proposal to other blockchain nodes;

[0008] After receiving the consensus proposal, the second node determines whether the first transaction is received; if it is determined that the first transaction is received, the second node participates in the consensus on the consensus proposal.

[0009] A second aspect of this specification provides a consensus method in a blockchain system, which is executed by a first node and includes:

[0010] Get the first transaction from the transaction pool;

[0011] Broadcasting the first transaction in the blockchain system;

[0012] In parallel with broadcasting the first transaction, a consensus proposal is generated, the consensus proposal including the transaction identifier of the first transaction, and the consensus proposal is sent to other blockchain nodes.

[0013] A third aspect of this specification provides a consensus method in a blockchain system, which is executed by a second node and includes:

[0014] receiving a consensus proposal from the first node, wherein the consensus proposal includes a transaction identifier of the first transaction;

[0015] determining whether the first transaction is received;

[0016] When it is determined that the first transaction is received, participating in consensus on the consensus proposal.

[0017] A fourth aspect of this specification provides a blockchain system, including a first node and multiple second nodes,

[0018] The first node is configured to obtain a first transaction from a transaction pool, broadcast the first transaction in the blockchain system, generate a consensus proposal in parallel with broadcasting the first transaction, the consensus proposal including a transaction identifier of the first transaction, and send the consensus proposal to other blockchain nodes;

[0019] The second node is configured to, after receiving the consensus proposal, determine whether the first transaction is received; and if it is determined that the first transaction is received, participate in consensus on the consensus proposal.

[0020] A fifth aspect of this specification provides a first node in a blockchain system, including:

[0021] An acquisition unit, configured to acquire a first transaction from a transaction pool;

[0022] a broadcasting unit, configured to broadcast the first transaction in the blockchain system;

[0023] A consensus unit is configured to generate a consensus proposal in parallel with broadcasting the first transaction, the consensus proposal including the transaction identifier of the first transaction, and send the consensus proposal to other blockchain nodes.

[0024] A sixth aspect of this specification provides a second node in a blockchain system, including:

[0025] a receiving unit, configured to receive a consensus proposal from a first node, wherein the consensus proposal includes a transaction identifier of the first transaction;

[0026] a determining unit, configured to determine whether the first transaction is received;

[0027] The consensus unit is configured to participate in consensus on the consensus proposal when it is determined that the first transaction has been received.

[0028] A seventh aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the second aspect or the third aspect.

[0029] In an eighth aspect, this specification provides a computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the second aspect or the third aspect is implemented.

[0030] In the solution provided in the embodiments of this specification, transaction broadcast and transaction verification are combined into the consensus algorithm, and transaction broadcast and consensus are performed in parallel, thereby completing consensus on transactions with low latency while ensuring the availability of transactions, thereby improving the transaction on-chain efficiency of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0032] FIG1 is a diagram of a blockchain architecture in one embodiment;

[0033] Figure 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0034] FIG3 is a schematic diagram of a consensus method in related art;

[0035] FIG4 is a flow chart of a consensus method in a blockchain system according to an embodiment of this specification;

[0036] FIG5 is a flow chart of a consensus method in an embodiment of this specification;

[0037] FIG6 is a schematic diagram of a pipelined block processing process in one embodiment;

[0038] FIG7 is an architectural diagram of a first node in a blockchain system according to an embodiment of this specification;

[0039] FIG8 is an architectural diagram of a second node in a blockchain system according to an embodiment of this specification. DETAILED DESCRIPTION

[0040] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0041] Figure 1 illustrates the architecture of a blockchain system in one embodiment. As shown in Figure 1 , the blockchain system includes N nodes, with nodes 1 through 8 schematically illustrated. The lines connecting the nodes schematically represent connections between them, such as TCP connections, for example, for transmitting data between nodes. These nodes can store the full ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain system can generate the same state by executing the same transactions, and each node in the blockchain system can store the same state database.

[0042] A transaction in the blockchain world refers to a unit of work executed and recorded within a blockchain system. A transaction typically includes a sender (From), a recipient (To), and a data field (Data). For example, in a transfer transaction, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0043] One of the decentralized features that distinguishes blockchain technology from traditional technologies is that it maintains ledgers on individual nodes, or distributed ledgers, rather than traditional centralized ledgers. For a blockchain system to be a decentralized, trustworthy system with an impenetrable, public, and tamper-proof data record, it must ensure that distributed data records are secure, unambiguous, and irreversible in the shortest possible time. To maintain ledger consistency across all nodes in different blockchain networks, consensus algorithms, or mechanisms, are often employed. Consensus mechanisms are the mechanisms by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Currently, mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT). In various consensus algorithms, consensus on a consensus proposal is typically achieved after a predetermined number of nodes reach agreement on the data to be agreed upon (i.e., a consensus proposal). Specifically, in the PBFT algorithm, if at most f nodes fail, a total of at least 3f+1 nodes can guarantee safety and liveness in the system.

[0044] Figure 2 illustrates the consensus process in the PBFT consensus algorithm. This diagram uses four consensus nodes (nodes 0 through 3) as an example, where f = 1. The numbers 0 through 3 on the left side of the diagram represent nodes 0 through 3, respectively. During the r-1 round of consensus, node 0, acting as the master node, collects a certain number of transactions to be agreed upon and initiates the pre-preparation process (referred to as the PP phase). Specifically, it generates a consensus proposal, which includes multiple transactions and their order. This proposal is then sent to each slave node (nodes 1 through 3), which then proceeds to the preparation process (referred to as the P phase). During the P phase, each slave node sends confirmation of its consensus proposal to the other nodes. After receiving confirmation of the consensus proposal from at least 2f (i.e., two) other nodes, nodes 0, 1, 2, and 3 proceed to the commit process (referred to as the C phase). In phase C, each node can send confirmation information of the consensus proposal in the submission phase to other nodes. After receiving confirmation information from at least 2f (i.e., 2) other nodes in the submission phase, nodes 0, 1, 2, and 3 can determine that the consensus is successful.

[0045] The PP phase, the P phase, and the C phase are generally collectively referred to as the three phases of PBFT. Under normal circumstances, the three-phase process of round r-1 of PBFT is completed, and consensus on the transaction data for the block corresponding to round r-1 of PBFT consensus is reached. This also generates information such as the block number. Consequently, each consensus node can execute these transactions sequentially based on the agreed-upon transaction data, following the agreed-upon transaction order and content, and thus generate the world state and receipt.

[0046] In the consensus algorithm shown in Figure 2, the consensus proposal includes the original transaction text (i.e., transaction body) of multiple transactions. This requires the computation of a large amount of data for signing and verifying the transaction signatures during consensus, resulting in low consensus efficiency. Therefore, related technologies decouple consensus and transaction propagation. In this architecture where consensus and transaction propagation are separated, it is necessary to verify that a majority of nodes have received multiple transactions, i.e., verify transaction availability, to ensure the correct completion of consensus.

[0047] Figure 3 is a schematic diagram of a consensus method in the related art. As shown in Figure 3, taking nodes 0-3 as an example in a blockchain, node 0 can first obtain multiple transactions from the transaction pool and send these transactions to nodes 1-3. After receiving the multiple transactions, nodes 1-3 verify the multiple transactions. This verification includes using the public key of the transaction sending account (i.e., the account in the "from" field) to verify the transaction signature. Specifically, the transaction signature is decrypted using the public key to obtain the transaction hash value h1, and the transaction hash value h2 is calculated. If the hash value h1 equals the hash value h2, the transaction signature verification is successful. After verification, nodes 1-3 persistently store the multiple transactions, sign the hash values ​​of the multiple transactions, and return the signature to node 0. After receiving at least two signatures, node 0 determines that the transaction availability verification has passed. If the transaction availability verification passes, node 0 generates a consensus proposal that includes a list of the hash values ​​of the multiple transactions. Node 0 sends this consensus proposal to nodes 1-3 to initiate consensus on the consensus proposal. Taking the PBFT algorithm as an example, as shown in Figure 2, the consensus process includes three stages: pre-preparation (PP), preparation (P), and submission (C). It is understood that the embodiments of this specification are not limited to the PBFT algorithm, but can be similarly applied to other consensus algorithms, such as the aforementioned POW and POS algorithms.

[0048] However, in the consensus method shown in Figure 3, transaction broadcast and transaction consensus are performed serially, that is, transaction broadcast is performed first in the blockchain system, and the consensus algorithm is executed to reach consensus on the transaction only after the transaction availability is verified. This results in a longer transaction time on the chain and a poor user experience.

[0049] The embodiments of this specification provide a consensus solution in a blockchain system. By incorporating transaction broadcasting into the consensus algorithm, transaction availability can be verified and consensus on transactions can be reached in parallel, thereby improving the efficiency of transaction on-chain in the blockchain system.

[0050] FIG4 is a flow chart of a consensus method in a blockchain system according to an embodiment of this specification.

[0051] As shown in FIG4 , in step S410 , node 0 obtains a transaction from the transaction pool.

[0052] Node 0 is, for example, the node that proposes the consensus. A blockchain system can have either a master consensus or a masterless consensus structure. In a master consensus structure, node 0 is the master node in the blockchain system. In a masterless consensus structure, node 0 can be any node in the blockchain system.

[0053] Node 0 connects to user devices to receive transactions from them. After receiving a transaction, Node 0 verifies the transaction signature similarly to the previous step. If verification passes, the transaction is placed in the transaction pool for on-chain upload. After completing the on-chain processing of each block, Node 0 retrieves several transactions from the transaction pool as transactions for the next block. Depending on the needs of different services, a block can include one or more transactions.

[0054] In step S420, node 0 generates a consensus proposal based on the acquired transactions. In step S440, node 0 sends the consensus proposal corresponding to the transactions to other nodes in the blockchain system. Simultaneously with step S420, in step S430, node 0 sends the transactions acquired from the transaction pool to other nodes in the blockchain system (node ​​1 is shown as an example in FIG2 ).

[0055] Specifically, in step S420, node 0 may include the transaction identifiers of each of the acquired transactions and the order in which they are arranged in its consensus proposal. This transaction identifier may be, for example, a hash value of the transaction. In other words, the consensus proposal does not need to include the transaction body. In step S440, after generating the consensus proposal, node 0 may send it to the other nodes. In step S430, node 0 broadcasts the transactions to the other nodes in parallel with step S420.

[0056] In one embodiment, node 0 also persists the transactions in parallel with step S420 and step S430 , ie, stores the transactions in a persistent storage medium (eg, a hard disk) to further ensure the availability of the transactions.

[0057] Figure 5 is a flow chart of the consensus method in one embodiment of this specification. As shown in Figure 5, during the PP phase, Node 0 broadcasts transactions and sends consensus proposals to Nodes 1-3 in parallel. The dashed arrows in the PP phase, for example, represent the broadcast of several transactions, and the solid arrows represent the sending of consensus proposals. Nodes 1-3 may first receive the consensus proposal and then receive several transactions, or they may first receive several transactions and then receive the consensus proposal (not shown in Figure 5).

[0058] In one embodiment, a service-oriented architecture can be provided for blockchain nodes. Specifically, multiple threads can be set up in a node. Different threads can provide different services. For example, a control thread, a transaction broadcast thread, and a transaction pool thread can be set up in node 0. The control thread can provide consensus services, scheduling services, etc. The transaction broadcast thread can be responsible for broadcasting transactions, and the transaction pool thread can be used to retrieve transactions from the transaction pool and persist transactions. These multiple threads can be threads under the same process or threads under different processes. In the case where the multiple threads belong to multiple processes, the multiple processes can be set up in a single computing device or in different computing devices.

[0059] Under a service-oriented architecture, blockchain nodes can process multiple blocks simultaneously in a pipelined manner. Figure 6 is a schematic diagram of the pipelined block processing process in one embodiment. As shown in Figure 6, the processing of each block can include three stages. In the first stage, the control thread and the transaction broadcast thread can operate in parallel, with the control thread performing consensus on the block and the transaction broadcast thread broadcasting the multiple transactions in the block. In the second stage, the execution thread can execute the transactions. In the third stage, the storage thread can persist the block data. By processing multiple blocks simultaneously in a pipelined manner, the total time it takes to upload these multiple blocks to the blockchain can be shortened, improving blockchain processing efficiency.

[0060] Taking the above multiple threads belonging to different processes as an example, in the first stage of processing block N, specifically, after obtaining several transactions from the transaction pool, the transaction pool thread can perform the following operations in parallel:

[0061] Put several transactions into a persistent queue;

[0062] Send several transactions to the transaction broadcast thread;

[0063] Send the hash values ​​of several transactions to the control thread.

[0064] After receiving several transactions, the transaction broadcast thread places them in a pending broadcast queue. The transaction broadcast thread can place these transactions as items in the pending broadcast queue. The transaction broadcast thread continuously retrieves items from the pending broadcast queue to broadcast transactions. When the transaction broadcast thread retrieves an item from the pending broadcast queue, it sends the transaction as the broadcast content to other nodes.

[0065] After receiving the hash values ​​of several transactions, the control thread generates a consensus proposal based on the hash values ​​of these transactions and places the consensus proposal in the proposal queue. The control thread continuously retrieves items from the proposal queue and sends them to other nodes. When the control thread obtains the consensus proposal corresponding to the transactions from the proposal queue, it sends the consensus proposal to the other nodes.

[0066] In addition, the transaction pool thread continuously obtains the queued items from the persistence queue for persistence. When the transaction pool thread obtains the transactions from the persistence queue, it stores the transactions in a persistent medium to ensure the availability of the transactions when subsequent transactions are executed.

[0067] In step S450 , node 1 determines whether the transaction involved in the consensus proposal has been received based on the consensus proposal.

[0068] Referring to Figure 5, Node 0 sends a consensus proposal and several transactions to Nodes 1-3 in the PP phase. Nodes 1-3 can perform the same steps to participate in the consensus on the consensus proposal. The following description uses Node 1 as an example.

[0069] In the PP phase, after receiving the consensus proposal, node 1 determines whether the local has received the transactions according to the hash values ​​of the transactions included in the consensus proposal. Specifically, node 1 determines whether the local has received the transactions corresponding to the hash values ​​included in the consensus proposal. After node 1 determines that the local has received the transactions according to the consensus proposal, it can execute step S460. In one embodiment, node 1 can execute step S460 after determining that the local has received the transactions and completing the persistence of the transactions.

[0070] Node 2 and Node 3 may perform the same operations as Node 1. Assuming that Node 3 has not received the multiple transactions, or at least one of the multiple transactions, locally based on the consensus proposal, Node 3 may pull the unreceived transactions from other nodes (e.g., Node 1) that have received the multiple transactions, or at least one of the multiple transactions, and then execute step S460. Node 3 may determine which nodes have received the multiple transactions, or at least one of the multiple transactions, based on confirmations of the consensus proposal received from other nodes during the consensus P phase.

[0071] In step S460, consensus on the consensus proposal is reached in the blockchain system.

[0072] Specifically, referring to Figure 5, after confirming receipt of the transactions, Nodes 1-3 enter the P phase of the consensus algorithm to participate in the consensus on the consensus proposal. That is, they sign the consensus proposal and send the signature to the other nodes in the blockchain system (i.e., Nodes 0, 2, and 3). In other words, by adding a transaction check before entering the P phase in the consensus algorithm, the availability of transactions during the consensus process can be guaranteed.

[0073] Each node in the blockchain system (node ​​0-node 3) determines that it has received signatures from at least two other nodes (i.e., 2f, where f = 1) before entering phase C. This involves signing the consensus proposal, obtaining a phase C signature, and sending the phase C signature to the other nodes in the blockchain system. Consensus is reached when each node in the blockchain system receives signatures from at least two other nodes in phase C.

[0074] In another embodiment, after reaching a consensus on block N, each node detects whether the local block includes all transactions in block N, and only starts executing each transaction in block N when it is determined that the local block includes all transactions in block N.

[0075] Assume that nodes 0, 1, and 3 in the consensus process have reached consensus, and node 2 has not participated in the consensus process because it has not received all the transactions in block N. Node 2 can confirm that consensus has been reached after receiving confirmation from all three nodes in the CC phase. After confirming that consensus has been reached, node 2 checks whether its local block contains all the transactions in block N. If it determines that its local block does not contain all the transactions in block N, it pulls several transactions in block N that it has not received from other nodes that have participated in the consensus process. After confirming that its local block contains all the transactions in block N, it begins executing each transaction in block N.

[0076] In the consensus solution provided in the embodiments of this specification, transaction broadcast and transaction verification are combined into the consensus algorithm, and transaction broadcast and consensus are performed in parallel, thereby completing consensus on transactions with low latency while ensuring the availability of transactions, thereby improving the transaction on-chain efficiency of the blockchain system.

[0077] FIG7 is an architecture diagram of a first node in a blockchain system according to an embodiment of this specification. The first node is configured to execute the method shown in FIG4 , including:

[0078] An acquisition unit 71 is configured to acquire a first transaction from a transaction pool;

[0079] a broadcasting unit 72, configured to broadcast the first transaction in the blockchain system;

[0080] The consensus unit 73 is configured to generate a consensus proposal in parallel with broadcasting the first transaction, wherein the consensus proposal includes the transaction identifier of the first transaction, and send the consensus proposal to other blockchain nodes.

[0081] FIG8 is an architecture diagram of a second node in a blockchain system according to an embodiment of this specification. The second node is configured to execute the method shown in FIG4 , including:

[0082] A receiving unit 81 is configured to receive a consensus proposal from a first node, wherein the consensus proposal includes a transaction identifier of the first transaction;

[0083] a determining unit 82, configured to determine whether the first transaction is received;

[0084] The consensus unit 83 is configured to participate in consensus on the consensus proposal when it is determined that the first transaction has been received.

[0085] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method shown in FIG. 4 .

[0086] An embodiment of this specification further provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method shown in FIG4 is implemented.

[0087] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0088] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0089] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0090] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0091] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0092] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0093] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0094] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

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

[0096] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0097] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0098] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. 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 magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0099] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0100] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0101] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A consensus method in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes, the method comprising: The first node obtains a first transaction from a transaction pool, broadcasts the first transaction in a blockchain system, generates a consensus proposal in parallel with broadcasting the first transaction, the consensus proposal includes a transaction identifier of the first transaction, and sends the consensus proposal to other blockchain nodes; After receiving the consensus proposal, the second node determines whether the first transaction is received; In a case where it is determined that the first transaction is received, participating in consensus on the consensus proposal.

2. The method according to claim 1, further comprising: The first node persistently stores the first transaction in parallel with broadcasting the first transaction.

3. According to the method of claim 1, when the second node determines that the first transaction is received, participating in the consensus on the consensus proposal comprises: After determining to persistently store the first transaction, the second node participates in consensus on the consensus proposal.

4. The method according to claim 1, further comprising: When determining that the first transaction has not been received, the second node pulls the first transaction from the first node or other nodes that have received the first transaction according to the consensus proposal, and after completing the pulling of the first transaction, participates in the consensus on the consensus proposal.

5. The method according to claim 1, further comprising: When it is determined that the first transaction has not been received, the second node detects whether the first transaction has been received locally according to the consensus proposal after determining that consensus on the consensus proposal has been reached in the blockchain system. When it is determined that the first transaction has not been received, the second node pulls the first transaction from the first node or other nodes participating in the consensus according to the consensus proposal, and executes the first transaction after completing the pulling of the first transaction.

6. According to the method of claim 2, the first node obtaining the first transaction from the transaction pool comprises: The first node obtains a plurality of first transactions from a transaction pool, and the consensus proposal includes transaction identifiers of the plurality of first transactions and an arrangement order of the plurality of first transactions.

7. According to the method of claim 2, the first node includes a first thread, a second thread and a third thread, and the first node obtains the first transaction from the transaction pool comprising: The first thread obtains a first transaction from the transaction pool, sends the first transaction to a second thread to put the first transaction into a first queue, sends an identifier of the first transaction to a third thread to write the identifier of the first transaction into a second queue, The first node broadcasting the first transaction in the blockchain system includes: the second thread broadcasting the first transaction from the first The queue obtains the first transaction, and broadcasts the first transaction in the blockchain system; The first node generating a consensus proposal in parallel with broadcasting the first transaction includes: the third thread obtaining an identifier of the first transaction from the second queue, and generating a consensus proposal based on the identifier of the first transaction.

8. The method according to claim 7, further comprising: The first thread puts the first transaction into a third queue, The first node persistently storing the first transaction in parallel with broadcasting the first transaction includes: the first thread obtains the first transaction from the third queue and persistently stores the first transaction.

9. A consensus method in a blockchain system, performed by a first node, comprising: Get the first transaction from the transaction pool; Broadcasting the first transaction in the blockchain system; A consensus proposal is generated in parallel with broadcasting the first transaction, the consensus proposal including a transaction identifier of the first transaction, and the consensus proposal is sent to other blockchain nodes.

10. A consensus method in a blockchain system, performed by a second node, comprising: receiving a consensus proposal from a first node, wherein the consensus proposal includes a transaction identifier of the first transaction; determining whether the first transaction is received; In a case where it is determined that the first transaction is received, participating in consensus on the consensus proposal.

11. A blockchain system, comprising a first node and a plurality of second nodes, The first node is used to obtain a first transaction from a transaction pool, broadcast the first transaction in a blockchain system, generate a consensus proposal in parallel with broadcasting the first transaction, the consensus proposal includes a transaction identifier of the first transaction, and send the consensus proposal to other blockchain nodes; The second node is used to determine whether the first transaction is received after receiving the consensus proposal; In a case where it is determined that the first transaction is received, participating in consensus on the consensus proposal.

12. A first node in a blockchain system, comprising: An acquisition unit, used for acquiring a first transaction from a transaction pool; A broadcasting unit, configured to broadcast the first transaction in the blockchain system; A consensus unit is used to generate a consensus proposal in parallel with broadcasting the first transaction, wherein the consensus proposal includes a transaction identifier of the first transaction, and send the consensus proposal to other blockchain nodes.

13. A second node in a blockchain system, comprising: A receiving unit, configured to receive a consensus proposal from a first node, wherein the consensus proposal includes a transaction identifier of the first transaction; a determining unit, configured to determine whether the first transaction is received; The consensus unit is used to participate in the consensus on the consensus proposal when it is determined that the first transaction is received.

14. A blockchain node, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in claim 9 or 10 is implemented.

Images