CN113746635A - Method and device for improving PBFT (provider-based data transfer) consensus expandability, computing equipment and storage medium - Google Patents

Abstract

The invention discloses a method, a device, computing equipment and a storage medium for improving PBFT consensus expandability. The method comprises the steps of introducing a consensus coordinator, selecting a main node to execute a PBFT-based consistency algorithm, and communicating the main node with the consensus coordinator; the consensus coordinator collects transactions from the transaction pool of each node, classifies the transactions according to the equality of the collected transactions, and decides whether to execute a consistency algorithm. The invention aims to provide good service for a system after a plurality of nodes are added into the system.

Description

Method, device, computing device and storage medium for improving scalability of PBFT consensus

technical field

The invention relates to the technical field of blockchain consensus, in particular to the scalability of a PBFT consensus algorithm in a consortium chain applied to scenarios such as blockchain traceability, that is, the performance under network node expansion. Specifically, it is a method, apparatus, computing device and storage medium for improving the scalability of PBFT consensus.

Background technique

At present, blockchain technology has been applied to different fields such as business and finance, and plays an important role in scenarios such as traceability. The alliance chain is initiated by some institutions. In practical applications, the alliance chain is mainly the PBFT algorithm. Compared with the traditional public chain algorithm, each node of the PBFT algorithm consensus is composed of business participants or supervisors. The algorithm does not require mining and monetary incentives, and the security and stability are guaranteed by business stakeholders. Therefore, it is more suitable for the actual production environment.

However, the application of the technology is limited due to scalability issues. While there are various factors related to scalability, such as network bandwidth and encryption algorithms, the consensus algorithm is a key factor that significantly affects the problem, ensuring that participants maintain the same data in a distributed environment.

Among the consensus algorithms of blockchain, the consensus algorithm based on Byzantine Fault Tolerance (BFT) has been widely used. PBFT (Practical Byzantine Fault Tolerance) is a popular and representative example. In a BFT-based consensus algorithm, as the number of participants increases, the number of network communications between participants increases exponentially. This is because BFT-based consensus algorithms require all participants to participate in the completion of each transaction, which consists of different steps.

The core three phases of the BFT-based consensus algorithm are the pre-prepare phase (pre-preparation phase), the prepare phase (preparation phase), and the commit phase (commit phase). C in Figure 1 represents the client, N0 to N3 represent nodes numbered 0 to 3, and N0 is the master node. The crossed N3 means that it may be a faulty node or a problem node, and the behavior here is that it does not respond to requests from other nodes. In the process of node communication, there is one single-point full broadcast and two full-point full broadcasts. When the number of nodes increases, the number of communications increases exponentially, and the network consumption during the consensus process is large, which is likely to cause network congestion and affect the correct execution of requests.

As the number of nodes increases, its performance and scalability inevitably decrease. This is because all participants should join the consensus process, and the consensus process completes more and more slowly.

The shortcomings of the PBFT algorithm are also evident in applications:

(1) After the algorithm receives the client request, it needs to go through three stages of pre-preparation, preparation and confirmation to reach a consensus. Each stage needs to broadcast the entire network nodes, which will bring huge transmission consumption. As the number of nodes increases, this consumption will increase rapidly. When n nodes reach a state consensus, the communication complexity of the algorithm reaches O(n ² ). Some experiments show that in the test on the Hyperledger Fabric platform, when the number of nodes exceeds 16, the performance of the algorithm will drop sharply.

(2) The master node selection strategy in the PBFT algorithm is relatively simple. When the master node is a Byzantine node, view switching will occur, increasing the overhead of the view switching protocol, and selecting a new master node according to the new view. This operation will bring a lot of time overhead,

(3) Consensus nodes in the blockchain system can be unstable. At any time, nodes will join in and some nodes will exit the system. After the node changes, the selection strategy of the master node and whether to switch views are also issues that need to be considered. The PBFT algorithm does not have a perfect node joining and exiting mechanism. When a node joins and leaves, the entire network needs to be restarted, which is expensive. If the nodes in the system are replaced frequently, this will greatly reduce the availability of the system.

SUMMARY OF THE INVENTION

In order to overcome the above-mentioned deficiencies of the prior art, the present invention provides a method, device, computing device and storage medium for improving the scalability of PBFT consensus, so that the system can still provide good services after many nodes join the system.

According to an aspect of the present specification, a method for improving the scalability of PBFT consensus is provided, which introduces a consensus coordinator, and the method includes:

selecting a master node that communicates with the consensus coordinator to execute the PBFT-based consensus algorithm;

The consensus coordinator collects transactions from the transaction pool of each node, classifies the transactions according to the equality of the collected transactions, and decides whether to execute the consensus algorithm; wherein,

When all transactions are equal, the consensus coordinator requests the master node to perform block generation;

When some transactions are not equal, the consensus coordinator divides the transactions into ordinary transactions and faulty transactions, and requests the master node to execute the PBFT-based consensus algorithm only on the faulty transactions to generate agreed transactions; Notify the consensus coordinator; the consensus coordinator packages all ordinary and agreed transactions in chronological order, and requests all nodes to perform block generation on the packaged transactions.

In the above technical solution, the consensus algorithm based on PBFT is implemented by introducing a consensus coordinator and classifying transaction conditions; transactions are divided into identical transactions and non-identical transactions, and non-identical transactions are divided into ordinary transactions and faulty transactions. Execute the consensus algorithm for problematic transactions, and execute the classic PBFT algorithm when the consensus is not reached; this can save the system overhead caused by the node changing view switching and achieve scalability.

As a further technical solution, among all participating nodes, a master node is selected by means of a verifiable random function VRF; when the VRF random number is less than or equal to a previous node Node _i , this number i node Node _i is selected as The master node, after signing the node number Node _i and the seed seed with the node signature private key sk as input, generates a VRF public key and notifies the consensus coordinator.

As a further technical solution, once the consensus coordinator is notified of the selection of the master node by the master node, it collects all transactions from the transaction pool of each node.

As a further technical solution, the consensus coordinator checks the validity of the selected master node by generating a random number random using the published seed and Node _i ; if the generated random number is equal to the Node _i received from the master node, Then the consensus coordinator requests all nodes to send all the transactions accumulated in the transaction pool of each node between the previous time time _p and the current time time _c ; if the generated random number is not equal to the Node _i received from the master node, the consensus The coordinator terminates all coordination steps in this round and waits for the next idle state.

According to an aspect of the present specification, an apparatus for improving the scalability of PBFT consensus is provided, including:

a selection module for selecting a master node from all blockchain nodes to execute the BFT-based consensus algorithm, the master node communicating with the consensus coordinator;

The consensus coordinator is used to collect transactions from the transaction pool of each node, classify the transactions according to the equality of the collected transactions, and decide whether to execute the consensus algorithm; wherein,

When all transactions are equal, the consensus coordinator requests the master node to perform block generation;

When some transactions are not equal, the consensus coordinator divides the transactions into ordinary transactions and faulty transactions, and requests the master node to execute the PBFT-based consensus algorithm only on the faulty transactions to generate agreed transactions; Notify the consensus coordinator; the consensus coordinator packages all ordinary and agreed transactions in chronological order, and requests all nodes to perform block generation on the packaged transactions.

In the above technical solution, the consensus coordinator is introduced to control the conditional execution of the PBFT-based consensus algorithm after equivalent classification of transactions of all nodes; this technical solution needs to check the equality of transactions and execute the consensus algorithm for faulty transactions. , although the consensus time of PBFT has increased, when the number of blockchain nodes increases, the growth rate of the total running delay is greatly slowed down compared with the traditional PBFT method.

As a further technical solution, the selection module is also used to select a master node among all participating nodes by means of a verifiable random function VRF; when the VRF random number is less than or equal to a previous node Node _i , this The number i node Node _i is selected as the master node, and after signing the node number Node _i and the seed seed with the node signature private key sk as the input, a VRF public key is generated and notified to the consensus coordinator.

As a further technical solution, the consensus coordinator is further configured to sort all public transactions and agreed transactions in chronological order, and request the master node to generate a new block containing all processed transactions.

According to one aspect of the present specification, there is provided a computing device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the method when the processor executes the computer program.

According to an aspect of the present specification, there is provided a computer-readable storage medium storing a computer program for executing the method.

Compared with the prior art, the beneficial effects of the present invention are:

(1) The present invention provides a method for improving the scalability of the PBFT consensus algorithm, that is, in the case of an increase in nodes, the conditional PBFT consensus algorithm is executed through transaction classification, rather than relying solely on the use of PBFT. Compared with the increase of nodes in the traditional method, all node algorithms in PBFT participate in the negotiation process and the number of communications increases, and all transactions execute the consensus procedure, resulting in an increase in the running time of PBFT. The present invention checks the equality of transactions and only executes the consensus algorithm for faulty transactions. Although an additional stage is introduced, the increase in total running time does not increase sharply with the single PBFT method when the number of blockchain nodes increases.

(2) The present invention introduces verifiable random function technology (VRF), so that each consensus node is only known by itself after being selected, but can also provide proofs for other nodes to verify. In the process of master node election, each node in the network only knows whether it is selected and cannot know who is selected by other nodes. The introduction of VRF technology makes the election process unpredictable and unmaneuverable. Only after the election is over, other nodes in the network can know the selected node, which prevents the election process from being manipulated and makes the election process more fair and secure.

(3) The present invention provides a system that, by introducing a consensus coordinator, controls the conditional execution of the PBFT-based consensus algorithm after equivalent classification of transactions of all nodes; after the node changes, the system fails to reach a consensus after the node changes. In the case of switching to the classic PBFT algorithm, the system can select the appropriate transaction to participate in the consensus according to the actual situation of the node, and realize the configurability of the consensus algorithm.

Description of drawings

Figure 1 is a schematic diagram of the PBFT protocol.

FIG. 2 is a flowchart of a method for improving the scalability of a PBFT consensus according to an embodiment of the present invention.

FIG. 3 is a schematic working diagram of a consensus coordination module and a PBFT module according to an embodiment of the present invention.

Detailed ways

The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present invention.

The nodes referred to in the embodiments of this application can be understood as abstract machines that respond to specific external trigger conditions and perform state transitions according to certain rules. Internet-connected devices.

As shown in Figure 2, this specification provides a method for improving the scalability of PBFT consensus, introducing a consensus coordinator, and the method includes:

Step 1, select the master node among all participating nodes.

The chosen masternodes play the role of interacting with the consensus coordinator. A master node is elected among all participating nodes by means of a Verifiable Random Function (VRF). The election step runs every t rule time. Election of a masternode starts with a seed, which is a hash of the previous block. Because consensus was reached in the previous round, the hash of the previous block is the same among all nodes.

Each node has a private key SK, and its verification public key VK is public. When the VRF random number is less than or equal to a previous node Node _i , this number i node Node _i is selected as the master node, and the node number Node _i and the seed seed are signed with the node signature private key SK as the input, and the VRF public key is generated. And notify the consensus coordinator.

Step 2, the consensus coordinator collects all transactions that exist in each node's transaction pool.

Once the consensus coordinator is notified of the election of a master node by the master node, it collects all transactions from each node's transaction pool. The consensus coordinator checks the validity of the selected master node by generating a random number random using the published seed and Node _i . If the generated random number is equal to Node _i received from the master node, the consensus coordinator requests all nodes to send all transactions accumulated in each node's transaction pool between the previous time time _p and the current time time _c . When the generated random number is not equal to the Node _i received from the master node, the consensus coordinator terminates all coordination steps in this round and waits for the next idle state.

Step 3, the consensus coordinator checks whether the transactions collected by each node are the same as all the transactions of other nodes.

In this step, the consensus algorithm of PBFT is executed in two cases according to each transaction collected by the node. First, the consensus coordinator checks that the transactions collected from each node are the same as all transactions from other nodes. When all transactions are equal, the Process Equal Transactions step is performed, and then the third step is terminated. When all transactions are not identical, the transactions are first divided into normal transactions and faulty transactions. For faulty transactions, the consensus coordinator requests the master node to execute the consensus algorithm and generate the agreed transaction. Finally, the consensus coordinator packages normal and agreed transactions in chronological order, and requests the controllers of all nodes to perform block generation on the packaged transactions. The detailed process is as follows:

1. Transactions from each node are equal to other nodes

The consensus coordinator performs this step if the transactions from each node are equal to all transactions from other nodes. To check the equality of transactions, first convert a set of transactions from each node into a hash function and then compare them for equality. If all transactions are the same, their hashes must be the same.

If all transactions are the same, the consensus coordinator requests the master node NodePrime to confirm the transaction Txs, and the master node responds to the confirmation request of the consensus coordinator transaction.

When the master node recognizes all nodes' transactions as equal, the consensus coordinator requests all nodes of the blockchain network to generate a new block. All nodes receive requests and delegate them to the PBFT consensus module to generate new blocks. The time _p of all nodes is updated with the current time _c , which is used to set the start time period of the next round. If the master node does not confirm the transaction, the current round of consensus is terminated, and time _p maintains the start time period of the previous round.

2. Transactions from each node are not equal to other nodes

(1) Transaction classification: In this step, the consensus coordinator classifies all transactions from each node into normal transactions and faulty transactions, and the classification outputs are stored in lists List _comm and List _tr .

(2) Execute the consensus algorithm: The consensus coordinator requests the master node to execute the consensus algorithm only on the faulty transaction, and we call the List _agg in which the consensus (acquired transaction) is reached as the agreed transaction. Because some transactions cannot be reached in the consensus algorithm, all transactions in the list of faulty transactions List _tr are not in List _agg .

(3) Sort all transactions: In this step, the consensus coordinator packs and sorts them into a SortedList according to the common transaction list List _comm and the agreed transaction list List _agg . Then, the consensus coordinator requests the master node to confirm the packaged transaction SortedList. If the identity of the master node is legal and the transaction is confirmed, the consensus coordinator requests the controllers of all nodes to perform block generation on the packaged transaction SortedList. After a new block is generated, the time _p of all nodes is updated to the current time time _c .

Step 4, all nodes perform block generation on the packaged transaction.

This step is to generate a new block for the blockchain platform, and the consensus coordinator will not interfere with this last step. Before the block is generated, the master node must broadcast it together with the certificate (VRF proof), and other nodes can determine the legitimacy of their identity through the calculation of the certificate (VRF proof). This can reduce the possibility of multiple consensus nodes conspiring to do evil and improve the security of the system. If the masternode identity is legitimate and the transaction is confirmed, all nodes create a new block containing the specified transaction and the hash of the previous block.

The controller used to request the PBFT module to generate new blocks and access the transaction pool is developed for blockchain platforms, and this method can be applied to various BFT-based consensus algorithms.

This specification also provides a device for improving the scalability of the PBFT consensus. By introducing a consensus coordinator, after the transactions of all nodes are equivalently classified, the conditional execution of the PBFT-based consensus algorithm is controlled.

In some embodiments, the working diagram of the consensus coordination module and the traditional PBFT module is shown in FIG. 3 .

The right part of Figure 3 is the PBFT module, which represents the traditional PBFT algorithm. It consists of a masternode that controls the consensus process and other general-purpose nodes of a BFT-like blockchain platform. Each node has a BFT module that controls the negotiation process, generates new blocks and a transaction pool to maintain unconfirmed transactions. The PBFT module periodically accesses transactions in the transaction pool and executes a PBFT-based consensus algorithm. Once all nodes have reached consensus on the transaction, the PBFT module generates a new block after the accumulated transactions have reached consensus.

The left part of Figure 3 is the consensus coordination module. A consensus coordinator is designed in this module, which is based on the consensus algorithm of PBFT, and controls each node to execute according to the consensus algorithm conditions of PBFT according to the equivalence of transactions.

In the scenario of blockchain traceability, consensus nodes have no motive for subjective maliciousness. Usually, Byzantine nodes will appear only when the network is down or the communication is interrupted, and the probability of this happening is extremely low, so it is not necessary to perform three-stage broadcasting every time to reach a consensus.

In some embodiments, the core idea is to introduce a consensus coordinator to control the conditional execution of the PBFT-based consensus algorithm after equivalence classification of transactions of all nodes. Transactions are divided into identical transactions and non-identical transactions. In addition, non-identical transactions are divided into ordinary transactions and faulty transactions. On this basis, the consensus algorithm is only executed for the transactions in question, and the classic PBFT algorithm is executed when the consensus is not reached. In this way, the system overhead caused by the node changing view switching can be saved. This PBFT-based consensus algorithm can achieve scalability.

In some embodiments, first, a master node is selected among all blockchain nodes to execute the BFT-based consensus algorithm and communicate with the consensus coordinator. The consensus coordinator then collects transactions from each node's transaction pool. In the third step, the coordinator classifies the transactions based on the equality of the collected transactions and decides whether to execute the consensus algorithm or not. When all transactions are equal, the coordinator lets the master node perform block generation without executing the consensus algorithm, which is done synchronously in the blockchain network. When some transactions are not equal, the coordinator divides the transactions into normal transactions and faulty transactions, and requests the master node to execute the BFT-based consensus algorithm only for faulty transactions. The master node notifies the coordinator of the consensus transaction. Finally, the coordinator sorts all ordinary and agreed transactions in chronological order, and requests the master node to execute the consensus algorithm to generate a new block.

In this example, the equality of transactions is checked first, and the consensus algorithm is only executed for the faulty transactions. Although the time taken for PBFT consensus increases, when the number of blockchain nodes increases, the growth rate of the total running time is higher than that of traditional PBFT. method is greatly slowed down.

The present specification also provides a computing device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the method when executing the computer program.

The present specification also provides a computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method.

A processor may be implemented in any suitable manner, for example, a processor may take the form of, for example, a microprocessor and a computer-readable medium storing computer-readable program code (eg, software or firmware) executable by the microprocessor, logic gates, switches , application specific integrated circuits, programmable logic controllers and embedded microcontrollers, examples of processors include but are not limited to the following microcontrollers: Intel E-2274G, Intel i7-1060G7, Intel i5-1035G4, Intel M5-6Y54 , AMD Epyc 7251, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to implementing the processor in the form of pure computer-readable program code, the processor can be implemented in logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded devices by logically programming method steps. The same function can be realized in the form of a microcontroller, etc. Therefore, such a processor can be regarded as a hardware component, and the devices included therein for implementing various functions can also be regarded as a structure within the hardware component. Or even, the means for implementing various functions can be regarded as both a software module implementing a method and a structure within a hardware component.

The platforms, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, 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.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, platforms (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block in the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce Means for implementing the functions specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

This specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions The apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in the flow or blocks of the flowcharts and/or the block or blocks of the block diagrams. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, 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 tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements, but also Other elements not expressly listed, or which are inherent to such a process, method, article of manufacture, or apparatus are also included. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that it can still be Modifications are made to the technical solutions described in the foregoing embodiments, or some or all of the technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present invention.

Claims (9)

1. A method for improving PBFT consensus scalability, wherein a consensus coordinator is introduced, the method comprising:

selecting a master node to execute a PBFT-based coherency algorithm, the master node in communication with a consensus coordinator;

the consensus coordinator collects transactions from the transaction pool of each node, classifies the transactions according to the equality of the collected transactions, and determines whether to execute a consistency algorithm; wherein,

when all transactions are equal, the consensus coordinator requests the master node to perform block generation;

when some transactions are not equal, the consensus coordinator divides the transactions into common transactions and fault transactions, and requests the main node to execute a consistency algorithm based on PBFT only on the fault transactions to generate appointed transactions; the master node informs the consensus coordinator of the transaction after consensus; the consensus coordinator packages all common transactions and appointment transactions in time order and requests all nodes to perform block generation on the packaged transactions.

2. The method for improving PBFT consensus scalability according to claim 1, wherein among all participating nodes, one master node is selected by way of verifiable random function VRF; when the VRF random number is less than or equal to the previous Node_iIn case of this number i Node_iSelected as the main Node, and takes the Node signature private key sk as the input to the Node number Node_iAnd generating a VRF public key and informing the consensus coordinator after the seed signature.

3. The method for improving PBFT consensus scalability according to claim 1, wherein said consensus coordinator collects all transactions from each node's transaction pool once notified by the master node's selection master node.

4. The method of improving PBFT consensus scalability according to claim 3, wherein said consensus coordinator uses published seed and Node_iGenerating a random number random to check the validity of the selected master node; if the generated random number is equal to the Node received from the master Node_iThe consensus coordinator requests all nodes to send the previous time_pTime to current time_cAll transactions accumulated in each node transaction pool; if the generated random number is not equal to the Node received from the master Node_iIf the consensus coordinator terminates the current roundAll coordination steps wait for the next idle state.

5. An apparatus for improving scalability of PBFT consensus, comprising:

a selection module for selecting a master node from all block link points to execute a BFT based consistency algorithm, the master node in communication with a consensus coordinator;

the consensus coordinator is used for collecting transactions from the transaction pool of each node, classifying the transactions according to the equality of the collected transactions and determining whether to execute a consistency algorithm; wherein,

when all transactions are equal, the consensus coordinator requests the master node to perform block generation;

when some transactions are not equal, the consensus coordinator divides the transactions into common transactions and fault transactions, and requests the main node to execute a consistency algorithm based on PBFT only on the fault transactions to generate appointed transactions; the master node informs the consensus coordinator of the transaction after consensus; the consensus coordinator packages all common transactions and appointment transactions in time order and requests all nodes to perform block generation on the packaged transactions.

6. The apparatus for improving PBFT consensus scalability according to claim 5, wherein the selecting module is further configured to select a master node among all participating nodes by way of a verifiable random function VRF; when the VRF random number is less than or equal to the previous Node_iIn case of this number i Node_iSelected as the main Node, and takes the Node signature private key sk as the input to the Node number Node_iAnd generating a VRF public key and informing the consensus coordinator after the seed signature.

7. The apparatus of claim 5, wherein the consensus coordinator is further configured to order all common transactions and appointment transactions in a chronological order and request the master node to generate a new block containing all processed transactions.

8. A computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 4 when executing the computer program.

9. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program for executing the method of any one of claims 1 to 4.

Images