HK1246533B - Blockchain consensus method, device and system - Google Patents

Description

A blockchain consensus method, device and system

Technical Field

The present application relates to the field of computer software technology, and in particular to a blockchain consensus method, device, and system.

Background Art

Blockchain, a distributed database technology originally designed for Bitcoin, is particularly well-suited for storing sequentially verifiable data within the system. It also utilizes consensus algorithms to ensure that data cannot be tampered with or forged. Consensus algorithms require the participation of nodes within a blockchain, reaching consensus through a collaborative computation. For example, upon receiving business data, a ledger node broadcasts it to other participating nodes, who then reach consensus on whether it holds the right to record the data. If the consensus is that the node holds the right to record the data, it stores the data in its corresponding blockchain. Therefore, in blockchain technology, the consensus algorithm serves as the constitution of the blockchain's programs or nodes, ensuring that all nodes can collaborate and agree upon any situation.

Practical Byzantine Fault Tolerance (PBFT) is a commonly used consensus algorithm in blockchains. PBFT offers a certain degree of fault tolerance while ensuring liveness and security, leading to its widespread use. In PBFT, one node is the master node, and the remaining nodes are backup nodes. The master node is responsible for sorting received service requests and then broadcasting them to the backup nodes based on the sorting results. The PBFT algorithm typically consists of three phases: pre-prepare, prepare, and commit. The pre-prepare and prepare phases are used to determine the order of service requests.

However, the master node may make mistakes when sorting service requests. For example, it may assign the same sequence number to different service requests, or not assign sequence numbers to some service requests, or assign discontinuous sequence numbers to adjacent service requests, etc. Therefore, the backup node needs to verify the order of service requests when receiving ordered service requests.

This shows that the PBFT algorithm has done a lot of design and calculation to ensure order. Research has found that many consensus algorithms currently in use (such as proof-of-work and proof-of-stake) require extensive design and calculation for order during consensus, consuming a large amount of system resources.

However, in real-world applications, a large number of business requests require no order. These are business requests that the server does not necessarily process in the order in which they were received. For example, charitable donation transactions and crowdfunding transactions with unlimited amounts have no impact on the processing of the transaction. Therefore, these business requests are referred to as business requests with no order requirements (abbreviated as "business requests with no order requirements"). When processing these business requests in a blockchain, using current consensus algorithms results in relatively low efficiency, which also affects the throughput of blockchain consensus.

Summary of the Invention

In view of this, the embodiments of the present application provide a blockchain consensus method, device and system for solving the problem of low processing efficiency in the prior art of using consensus algorithms to process business requests with disordered requirements.

In the first aspect, a blockchain consensus method is proposed in the embodiments of the present application, including:

Obtain business data to be agreed upon;

According to a preset allocation rule, the business data to be agreed upon is allocated to at least one consensus unit in the consensus unit set, and the consensus unit is used to perform consensus processing on the allocated business data to be agreed upon.

In the embodiment of the present application, a blockchain consensus method is also proposed, including:

Obtain at least one piece of business data to be agreed upon;

According to a preset allocation rule, the business data to be agreed upon is allocated in parallel to at least one consensus unit in the consensus unit set, and the consensus unit is used to perform consensus processing on the allocated business data to be agreed upon.

In the embodiment of the present application, a data storage method based on blockchain is also proposed, including:

Receive consensus results sent by different consensus units;

According to the timestamp of the consensus result, the consensus result is stored in a block in the blockchain.

In a second aspect, a blockchain consensus system is also proposed in an embodiment of the present application. The consensus system includes: an allocation unit and a consensus unit set including a consensus unit, wherein:

The allocation unit obtains the business data to be agreed upon, and allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule;

The consensus units included in the consensus set perform consensus processing on the allocated business data to be agreed upon.

In a third aspect, the present application also provides a blockchain consensus device, including:

Acquisition unit, obtains the business data to be agreed upon;

The processing unit allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, and the consensus unit is used to perform consensus processing on the allocated business data to be agreed upon.

The present application also provides a blockchain consensus device, including:

An acquisition unit, which acquires at least one piece of business data to be agreed upon;

The processing unit distributes the business data to be agreed upon to at least one consensus unit in the consensus unit set in parallel according to a preset distribution rule, and the consensus unit is used to perform consensus processing on the distributed business data to be agreed upon.

The present application also provides a blockchain-based data storage device, including:

Receiving unit, receiving consensus results sent by different consensus units;

A storage unit stores the consensus result in a block in the blockchain according to a timestamp of the consensus result.

At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

This application designs the consensus algorithm as an independent consensus unit. This consensus unit is different from the traditional blockchain consensus. These consensus units form a consensus unit set. When the business data to be agreed upon is obtained, the business data can be allocated to the consensus units in the consensus unit set according to the set allocation rules, so that the consensus units can process the business data in consensus in parallel. In this way, for business requests with disordered requirements, consensus processing can be performed in parallel through multiple consensus units, simplifying the order processing of the existing consensus algorithm, improving the processing efficiency and processing throughput of disordered business requests, and improving the operating performance of the blockchain network.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG1 is a flow chart of a blockchain consensus method provided in an embodiment of the present application;

FIG2 is a flow chart of a blockchain consensus method provided in an embodiment of the present application;

FIG3 is a flow chart of a blockchain consensus method provided in an embodiment of the present application;

FIG4 is a flow chart of a data storage method based on blockchain provided in an embodiment of the present application;

FIG5 is a schematic diagram of the structure of a blockchain consensus system provided by an embodiment of the present application;

FIG6 is a schematic diagram of a blockchain consensus device provided in an embodiment of the present application;

FIG7 is a schematic diagram of a blockchain consensus device provided in an embodiment of the present application;

FIG8 is a schematic structural diagram of a blockchain-based data storage device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

The following examples describe the schemes described in this application in detail.

Figure 1 is a flowchart of a blockchain consensus method provided by an embodiment of the present application. From a program perspective, the execution entity of this process can be an application (APP) or a personal computer (PC) program. From a device perspective, the execution entity of this process can include, but is not limited to, the following devices: personal computers, large and medium-sized computers, computer clusters, mobile phones, tablet computers, smart wearable devices, and vehicle computers.

The process in Figure 1 may include the following steps:

S101: Obtain business data to be agreed upon.

In an embodiment of the present application, if the execution subject of the embodiment of the present application is a blockchain node in a blockchain network (hereinafter referred to as a node), then the node can receive a business request to be processed, obtain business data from the business request, and store the business data. The business data to be agreed upon recorded in step S101 can be stored business data. The business request here can be a business request sent by a client, such as an accounting request, or a request to execute another state machine operation; it can also be a business request sent by other devices, which is not specifically limited here.

It should be noted that the business data to be agreed upon recorded in the embodiments of the present application may refer to one business data, that is, when one business data is obtained, subsequent operations are triggered; it may also refer to the acquisition of multiple business data to be agreed upon, that is, when multiple business data are obtained, subsequent operations are triggered; it may also refer to the acquisition of business data generated within a set time period, that is, the acquisition of business data generated within a set time period, and when the set time period arrives, subsequent operations are triggered. There is no limit on the number of business data obtained here.

Here, "business data" includes unordered business data, meaning that the time factor of the business data is not considered when processing the received business data. For example, if the received business request is a donation request, then the business data to be agreed upon is the business data to be agreed upon. Therefore, for the business data related to donations, it does not matter to the sender which business data is processed first or later. In other words, the time factor of the sender sending the donation request is ignored. Therefore, this type of business request is also called an unordered business request.

S102: Allocate the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule.

The consensus unit is used to perform consensus processing on the allocated business data to be agreed upon.

In blockchain technology, consensus algorithms are required to process acquired business data. Consensus algorithms are implemented by the various voting nodes involved in the consensus process, i.e., they jointly calculate the algorithm that ultimately reaches a consensus.

The consensus unit set described in the embodiments of this application includes consensus units, each of which can provide independent consensus services. In other words, the consensus algorithms used by different consensus units can be the same or different.

It should be noted that the number of consensus units included in the consensus unit set is not limited in the embodiments of the present application. The number of voting nodes included in different consensus units can be the same or different. For example: if the consensus algorithm is the PBFT algorithm, then the voting nodes in the consensus unit include one master node and four slave nodes; if the consensus algorithm is the proof-of-work mechanism, then the consensus unit includes at least one voting node. Therefore, the number of voting nodes in the consensus unit is not limited in the embodiments of the present application and can be determined according to the actual requirements of the consensus algorithm.

In this way, for the business data to be agreed upon, the solution provided in the embodiment of the present application can be used to perform consensus processing on different business data in a concurrent processing manner, that is, different business data are concurrently assigned to different consensus units, and the consensus units independently perform consensus processing on the received business data.

The following describes in detail how to allocate the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule.

First way:

According to the number of the received business data to be agreed upon, a consensus unit matching the number is determined from the consensus unit set in a random manner;

Concurrently assigning the business data to be agreed upon to the determined consensus units respectively.

Specifically, when the number of business data to be agreed upon is 1, a consensus unit is randomly determined from the consensus unit set, and the business data to be agreed upon is assigned to the determined consensus unit, and the consensus unit performs consensus processing on the business data to be agreed upon.

When the number of business data to be agreed upon is greater than 1, the number of consensus units can be randomly determined from the consensus unit set according to the number of business data to be agreed upon, and the business data to be agreed upon can be assigned to the determined different consensus units in turn.

For example: the acquired business data to be agreed upon includes business data 1 to be agreed upon, business data 2 to be agreed upon, and business data 3 to be agreed upon. Assuming that the consensus unit set includes consensus unit 1, consensus unit 2, consensus unit 3, consensus unit 4, and consensus unit 5, then it is necessary to randomly determine 3 consensus units from the consensus unit set. Assuming that the randomly determined consensus units are consensus unit 2, consensus unit 4, and consensus unit 5, at this time, business data 1 to be agreed upon, business data 2 to be agreed upon, and business data 3 to be agreed upon are assigned to different determined consensus units in turn in a random manner. For example: business data 1 to be agreed upon is assigned to consensus unit 5; business data 2 to be agreed upon is assigned to consensus unit 4; and business data 3 to be agreed upon is assigned to consensus unit 2.

Consensus allocation in the embodiments of this application has no order requirements, so it can be allocated randomly. Furthermore, "randomly allocating business data 1 to be agreed upon, business data 2 to be agreed upon, and business data 3 to be agreed upon to different consensus units" can be implemented using a parallel distribution method. A random allocation method is used. That is, after obtaining a piece of business data to be agreed upon, any consensus unit may become the consensus unit for the consensus service that processes the business data to be agreed upon. This random allocation method can reduce the resources used by the system during allocation.

The "random method" described here can be implemented through a random algorithm or other methods, and is not specifically limited here.

Second way:

In a polling manner, a consensus unit requiring consensus service is determined from the consensus unit set; and the business data to be agreed upon is allocated to the determined consensus unit.

Specifically, when the business data to be agreed upon is obtained, a polling method is adopted to send a query message to each consensus unit in the consensus unit set to determine whether the consensus unit needs a consensus service object (i.e., a business request). When it is determined that the consensus unit needs a consensus service object, the business data to be agreed upon is sent to the consensus unit.

When the number of business data to be agreed upon is 1, a query message is sent to each consensus unit in the consensus unit set in turn. When the received response message indicates that a consensus service object is required, the business data to be agreed upon is sent to the consensus unit that returns the response message.

When the number of business data to be agreed upon is greater than 1, query messages can be sent concurrently to each consensus unit in the consensus unit set. When a response message is received, the number of consensus units indicating that a consensus service object is needed in the received response message is determined. If the number of consensus units is greater than the number of business requests, a consensus unit can be randomly selected from the consensus units indicating that a consensus service object is needed in the received response message in the first way, and the business data to be agreed upon can be sent concurrently to the randomly selected consensus units respectively; if the number of consensus units is not greater than the number of business requests, the business data to be agreed upon can be randomly assigned to the consensus units indicating that a consensus service object is needed in the received response message, and the business data to be agreed upon that has not yet been assigned will continue to wait.

For example, if three consensus units are determined to need consensus service objects through polling, and the number of business data to be agreed upon is four, then three are randomly selected from the four acquired business data to be agreed upon, and the three randomly selected business data to be agreed upon are sent to the consensus units that need consensus service objects respectively. The one business data to be agreed upon that has not yet been assigned is in a waiting state.

Assuming that the number of business data to be agreed upon is 2, then 2 are randomly selected from the consensus units that determine the consensus service objects, and the 2 business data to be agreed upon are sent in parallel to the randomly selected consensus units, so that the consensus units perform consensus processing on the received business data to be agreed upon.

The third way:

Determine the load capacity of each consensus unit in the consensus unit set;

According to the load balancing rule, the business data to be agreed upon is distributed to at least one consensus unit in the consensus unit set.

Specifically, when the business data to be agreed upon is obtained, in order to ensure the load balance of each consensus unit in the entire consensus unit set, the load capacity of each consensus unit in the consensus unit set can be determined (the load capacity here can refer to the load situation of the current consensus unit, which is different from the total load capacity of the consensus unit). Then, according to the load capacity of each consensus unit, the amount of current idle resources of each consensus unit can be determined. In an embodiment of the present application, the business data to be agreed upon can be allocated to the consensus unit in the consensus unit set whose load capacity is less than the set condition. That is, the business data to be agreed upon is allocated to the consensus unit in the consensus unit set whose idle resources are greater than the set threshold.

It should be noted that in the second method recorded above, when the number of consensus units requiring consensus service objects is greater than the number of business requests, in addition to using a random method to determine the consensus unit, the load balancing method recorded in the third method can also be used to determine the consensus unit, which will not be described in detail here.

Preferably, in an embodiment of the present application, when the acquired business data to be agreed upon cannot be allocated to the consensus unit all at once, some business requests need to be in a waiting state for allocation. Then, the business requests in the waiting state for allocation can still determine the consensus unit using the three methods recorded above.

For example, if the consensus unit set contains three consensus units, then the consensus unit set can concurrently process three business data to be agreed upon that are obtained at the same time point. If four business data to be agreed upon are obtained (i.e., greater than 3): business data to be agreed upon 1, business data to be agreed upon 2, business data to be agreed upon 3, and business data to be agreed upon 4, then assuming that business data to be agreed upon 1, business data to be agreed upon 2, and business data to be agreed upon 3 are allocated to the three consensus units in the consensus unit set in parallel, then business data to be agreed upon 4 will be in a waiting state. Once it is detected that a consensus unit in the consensus unit set is idle, business data to be agreed upon 4 can be allocated to that consensus unit.

Preferably, in an embodiment of the present application, determining a consensus unit from a consensus unit set includes:

Determine a working state of each consensus unit in the consensus unit set, where the working state includes at least one of a normal state and an abnormal state;

A consensus unit is determined from consensus units whose working status is a normal state.

In order to ensure that the determined consensus unit can successfully connect to the obtained business data to be agreed upon for consensus processing, the working status of the consensus units in the consensus unit set can also be monitored. In this way, when selecting a consensus unit, it is possible to avoid selecting a consensus unit with an abnormal working status, thereby effectively improving the processing efficiency of business requests.

In addition, it is also possible to configure switch controls for the consensus units in the consensus unit set. In this way, when the processing volume of business requests in the blockchain network is small, some of the consensus units in the consensus unit set can be turned off, which saves system resources and improves the utilization rate of system resources. Preferably, by controlling the switch status of each consensus unit, the blockchain of the embodiment of the present application can improve the availability of the system when facing problems such as downtime and network disconnection. For example, when a consensus unit experiences a node downtime or network disconnection, the low system availability defect of the existing method can be avoided by turning off the consensus unit.

S103: The consensus unit performs consensus processing on the allocated business data to be agreed upon.

In the embodiment of the present application, the consensus algorithm adopted by the consensus unit is not specifically limited, and any consensus algorithm can be adopted, including the mainstream PBFT algorithm.

It should be understood by those skilled in the art that there is no order requirement for allocating the business data to be agreed upon in the embodiments of the present application. By designing the consensus algorithm as an independent consensus unit in the embodiments of the present application, this consensus unit is different from the traditional blockchain consensus. These consensus units form a consensus unit set. When the business data to be agreed upon is obtained, the business data can be allocated to the consensus units in the consensus unit set according to the set allocation rules, so that the consensus unit can process the business data in consensus. In this way, for business requests with disordered requirements, consensus processing can be performed in parallel by multiple consensus units, simplifying the order processing of the existing consensus algorithm, improving the processing efficiency and processing throughput of disordered business requests, and improving the operating performance of the blockchain network.

Preferably, the business requests mentioned in the implementation method of the present application include business requests with no order requirements. The so-called business requests with no order requirements include, but are not limited to, charitable donation transaction business and crowdfunding transaction business with no upper limit. For charitable donation transaction business, from the perspective of millisecond accuracy, who donates first and who donates later has no effect on the business. The crowdfunding transaction business with no upper limit also has the same nature, so we regard this type of business request as a request without order requirements. In the embodiment of the present application, for such business requests with no order requirements, a concurrent consensus method can be used to improve the operating efficiency of the consensus processing. Due to the use of this concurrent consensus method, the throughput of the entire blockchain system is greatly improved, especially the consensus algorithm module is no longer the bottleneck of the entire blockchain system.

Based on the same inventive concept, FIG2 is a flow chart of a blockchain consensus method provided in an embodiment of the present application. The method can be as follows.

S201: Obtain business data to be agreed upon.

The method here is the same or similar to step S101 described in Example 1, and will not be described here one by one.

S202: Determine the amount of resources required to process the business data to be agreed upon, and the amount of idle resources of each consensus unit in the consensus unit set.

In an embodiment of the present application, when business data to be agreed upon is obtained, resources required to process the business data to be agreed upon may be determined.

In addition, the current amount of free resources of each consensus unit in the consensus unit set can be determined by query.

S203: Compare the idle resource amount of each consensus unit with the resources required for processing the business data to be agreed upon, and determine the number of consensus units whose idle resource amount is greater than the resource amount required for processing the business data to be agreed upon.

S204: Determine whether the number is greater than a set value. If so, execute S205; otherwise, execute S206.

It should be noted that the set values recorded in the embodiments of the present application can be determined according to needs or based on experimental data, and are not specifically limited here.

S205: In a round-robin manner, a consensus unit requiring consensus service is determined from consensus units whose idle resources are greater than the resources required for processing the business data to be agreed upon, and the business data to be agreed upon is allocated to the determined consensus unit.

The method of determining the consensus unit that needs the consensus service by polling here can refer to the second method in step S102 in Example 1, and will not be described here one by one.

In the embodiments of the present application, a polling mechanism is used to distribute the business data to be agreed upon. The so-called polling distribution mechanism is that the adapter or distribution unit responsible for distribution periodically issues inquiries, sequentially asking each consensus unit whether it needs a consensus service object. If it does, it will provide the service, that is, allocate the business data to be agreed upon. After the service is completed, it will ask the next consensus unit again, and then repeat the cycle.

S206: According to the load balancing rule, a consensus unit having a load capacity less than a set condition is determined from the consensus units having idle resources greater than the resources required for processing the business data to be agreed upon, and the business data to be agreed upon is allocated to the determined consensus unit.

The method of determining the consensus unit using the load balancing rule here can refer to the third method in step S102 in Example 1, and will not be explained here one by one.

For example, if at a certain point in time there are five business data items awaiting consensus, and the number of consensus units currently capable of participating in the consensus service is three, then the load of the business requests exceeds the processing capacity of the independent consensus units. The reason for comparing the load of the business data awaiting consensus and the processing capacity of the independent consensus units is to provide a reference for the next step of consensus allocation, so as to maximize the utilization of each independent consensus unit and improve the number of consensus processes per unit time, that is, the throughput.

Preferably, the load balancing distribution method adopted in the embodiments of the present application includes but is not limited to software or hardware balancing methods, such as DNS load balancing, gateway load balancing or load balancer, etc., which will not be described in detail here. Using load balancing for distribution can avoid a large number of business requests being concentrated in a single consensus unit while other individual consensus units are idle.

Compared with the load balancing distribution method, the polling distribution method is relatively easier to operate, but in terms of efficiency, the load balancing distribution method is relatively higher.

Based on the same inventive concept, FIG3 is a flow chart of a blockchain consensus method provided by an embodiment of the present application. The method can also be as follows.

S301: Obtain at least one piece of business data to be agreed upon.

S302: Group the at least one business data to be agreed upon to obtain at least one business data group.

In the embodiment of the present application, since the business data to be agreed upon is business data with disordered requirements, the acquired business data to be agreed upon can be grouped, which can speed up the processing efficiency of the business data.

S303: Allocate the business data group to different consensus units in the consensus unit set in parallel according to a preset allocation rule.

The consensus unit is used to perform consensus processing on the allocated business data to be agreed upon.

Based on the same inventive concept, FIG4 is a flow chart of a blockchain-based data storage method provided in an embodiment of the present application. The method can be as follows.

S401: Receive consensus results sent by different consensus units.

In an embodiment of the present application, the consensus unit may have data storage capabilities, so when a consensus result is obtained, the consensus result can be stored; or it may not have data storage capabilities, so different consensus units can send the obtained consensus results to a public node, and the public node will complete the storage.

S402: According to the timestamp of the consensus result, the consensus result is stored in a block in the blockchain.

Specifically, according to the generation time of the consensus result, different consensus results are stored in blocks in the blockchain in sequence;

Alternatively, different consensus results are stored in blocks in the blockchain in sequence according to the time when the consensus results are received.

In an embodiment of the present application, when storing the consensus result in a block in the blockchain, a storage node may be selected randomly, or the consensus result may be stored in a block of a node corresponding to the consensus unit that generated the consensus result based on the correspondence between the consensus unit and the storage node. This is not specifically limited in the embodiment of the present application, i.e., a consensus unit may store the consensus result generated by the consensus unit itself, the consensus result generated by other consensus units, or not store the consensus result, with an independent storage node storing the consensus result.

Preferably, in addition to setting on/off control for each consensus unit, on/off control can also be set for storage nodes. This on/off control greatly improves the availability of the entire blockchain system in the face of problems such as storage node failure, network disconnection, and the addition of new nodes and the removal of old nodes.

Based on the same inventive concept, FIG5 is a schematic diagram of the structure of a blockchain consensus system provided by an embodiment of the present application. The consensus system includes: an allocation unit 501, a consensus unit set 502 including a consensus unit 5021, wherein:

The allocation unit 501 obtains the business data to be agreed upon, and allocates the business data to be agreed upon to at least one consensus unit 5021 in the consensus unit set 502 according to a preset allocation rule;

The consensus unit 5021 included in the consensus set 502 performs consensus processing on the allocated business data to be agreed upon.

In another embodiment of the present application, the consensus system further includes: a storage node 503, wherein:

The storage node 503 receives the consensus results sent by different consensus units and stores the consensus results in sequence according to the timestamps of the consensus results.

In another embodiment of the present application, the allocating unit 501 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

According to the number of the received business data to be agreed upon, a consensus unit matching the number is determined from the consensus unit set in a random manner;

Concurrently assigning the business data to be agreed upon to the determined consensus units respectively.

In another embodiment of the present application, the allocating unit 501 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

Determine the consensus unit that needs consensus service from the consensus unit set in a polling manner;

Allocate the business data to be agreed upon to the determined consensus unit.

In another embodiment of the present application, the allocating unit 501 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

Determine the load capacity of each consensus unit in the consensus unit set;

According to the load balancing rule, the business data to be agreed upon is distributed to at least one consensus unit in the consensus unit set.

In another embodiment of the present application, the distribution unit 501 distributes the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a load balancing rule, including:

The business data to be agreed upon is allocated to the consensus unit in the consensus unit set whose load capacity is less than the set condition.

In another embodiment of the present application, the allocation unit 501 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

Determine the amount of resources required to process the business data to be agreed upon, and the amount of idle resources of each consensus unit in the consensus unit set;

When the number of consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon is greater than a set value, the consensus units that need consensus services are determined from the consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon in a round-robin manner, and the business data to be agreed upon is allocated to the determined consensus units;

When the number of consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon is less than a set value, according to the load balancing rules, the consensus units whose load capacity is less than the set condition are determined from the consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon, and the business data to be agreed upon is allocated to the determined consensus units.

In another embodiment of the present application, the allocating unit 501 determines the consensus unit from the consensus unit set, including:

Determine a working state of each consensus unit in the consensus unit set, where the working state includes at least one of a normal state and an abnormal state;

A consensus unit is determined from consensus units whose working status is a normal state.

In another embodiment of the present application, the business data to be agreed upon includes business data with no order requirements.

In another embodiment of the present application, the storage node 503 receives consensus results sent by different consensus units; and stores the consensus results in blocks in the blockchain according to the timestamp of the consensus results.

In another embodiment of the present application, the storage node 503 stores the consensus result in a block in the blockchain, including:

The consensus result is stored in the block of the node corresponding to the consensus unit that generated the consensus result.

Based on the same inventive concept, FIG6 is a schematic diagram of the structure of a blockchain consensus device provided by an embodiment of the present application. The consensus device includes: an acquisition unit 601 and a processing unit 602, wherein:

Acquisition unit 601, acquires the business data to be agreed upon;

The processing unit 602 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, and the consensus unit is used to perform consensus processing on the allocated business data to be agreed upon.

In another embodiment of the present application, the processing unit 602 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

According to the number of the received business data to be agreed upon, a consensus unit matching the number is determined from the consensus unit set in a random manner;

Concurrently assigning the business data to be agreed upon to the determined consensus units respectively.

In another embodiment of the present application, the processing unit 602 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

Determine the consensus unit that needs consensus service from the consensus unit set in a polling manner;

Allocate the business data to be agreed upon to the determined consensus unit.

In another embodiment of the present application, the processing unit 602 allocates the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

Determine the load capacity of each consensus unit in the consensus unit set;

According to the load balancing rule, the business data to be agreed upon is distributed to at least one consensus unit in the consensus unit set.

In another embodiment of the present application, the processing unit 602 distributes the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a load balancing rule, including:

The business data to be agreed upon is allocated to the consensus unit in the consensus unit set whose load capacity is less than the set condition.

In another embodiment of the present application, the processing unit 602 distributes the business data to be agreed upon to at least one consensus unit in the consensus unit set according to a preset allocation rule, including:

Determine the amount of resources required to process the business data to be agreed upon, and the amount of idle resources of each consensus unit in the consensus unit set;

When the number of consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon is greater than a set value, the consensus units that need consensus services are determined from the consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon in a round-robin manner, and the business data to be agreed upon is allocated to the determined consensus units;

When the number of consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon is less than a set value, according to the load balancing rules, the consensus units whose load capacity is less than the set condition are determined from the consensus units whose idle resources are greater than the resources required to process the business data to be agreed upon, and the business data to be agreed upon is allocated to the determined consensus units.

In another embodiment of the present application, the processing unit 602 determines the consensus unit from the consensus unit set, including:

Determine a working state of each consensus unit in the consensus unit set, where the working state includes at least one of a normal state and an abnormal state;

A consensus unit is determined from consensus units whose working status is a normal state.

In another embodiment of the present application, the business data to be agreed upon includes business data with no order requirements.

It should be noted that the consensus device provided in the embodiment of the present application can be implemented by software or hardware, and no specific limitation is made here.

Based on the same inventive concept, FIG7 is a schematic diagram of the structure of a blockchain consensus device provided by an embodiment of the present application. The consensus device includes: an acquisition unit 701 and a processing unit 702, wherein:

An acquisition unit, which acquires at least one piece of business data to be agreed upon;

The processing unit distributes the business data to be agreed upon to at least one consensus unit in the consensus unit set in parallel according to a preset distribution rule, and the consensus unit is used to perform consensus processing on the distributed business data to be agreed upon.

In another embodiment of the present application, the processing unit 702 distributes the business data to be agreed upon to at least one consensus unit in the consensus unit set in parallel according to a preset distribution rule, including:

Grouping the at least one business data to be agreed upon to obtain at least one business data group;

According to a preset allocation rule, the business data group is allocated to different consensus units in the consensus unit set in parallel.

Based on the same inventive concept, FIG8 is a schematic diagram of the structure of a blockchain-based data storage device provided in an embodiment of the present application. The storage device includes: a receiving unit 801 and a storage unit 802, wherein:

Receiving unit 801, receiving consensus results sent by different consensus units;

The storage unit 802 stores the consensus result in a block in the blockchain according to the timestamp of the consensus result.

In another embodiment of the application, the storage unit 802 stores the consensus result in a block in the blockchain, including:

The consensus result is stored in the block of the node corresponding to the consensus unit that generated the consensus result.

It should be noted that the consensus device provided in the embodiment of the present application can be implemented by software or hardware, which is not specifically limited here. The consensus device designs the consensus algorithm as an independent consensus unit. This consensus unit is different from the traditional blockchain consensus. These consensus units form a consensus unit set. When the business data to be agreed upon is obtained, the business data can be allocated to the consensus units in the consensus unit set according to the set allocation rules, so that the consensus unit can process the business data in consensus. In this way, for business requests with disordered requirements, consensus processing can be performed in parallel by multiple consensus units, simplifying the order processing of the existing consensus algorithm, improving the processing efficiency and processing throughput of disordered business requests, and improving the operating performance of the blockchain network.

The devices and methods provided in the embodiments of the present application correspond one to one, and therefore, the devices also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding devices will not be repeated here.

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 through their own programming, 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 ones 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.

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 pure computer-readable program code, 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 implementing the method and structures within the hardware component.

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

For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention 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.

The present invention is described with reference to the flowcharts and/or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of the processes and/or boxes 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 boxes in the block diagram.

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 manufactured 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.

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.

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

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.

Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The 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 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 computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

The present application 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, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims (26)

1. A blockchain consensus method, characterized in that it includes: Obtain business data awaiting consensus; According to the preset allocation rules, the business data to be reached is allocated to at least one consensus unit in the consensus unit set. The consensus unit is used to perform consensus processing on the allocated business data to be reached. The consensus unit is used to provide independent consensus services. The consensus unit includes voting nodes. The consensus processing is completed by the participation of each voting node that participates in the consensus. 2. The method as described in claim 1, characterized in that, according to a preset allocation rule, the business data to be reached for consensus is allocated to at least one consensus unit in the consensus unit set, comprising: Based on the number of business data to be reached for consensus, consensus units matching the number are randomly selected from the consensus unit set. The business data to be reached for consensus is concurrently assigned to the determined consensus units. 3. The method as described in claim 1, characterized in that, according to a preset allocation rule, the business data to be reached for consensus is allocated to at least one consensus unit in the consensus unit set, comprising: The consensus units that require consensus services are determined from the set of consensus units using a polling method. The business data to be reached for consensus is assigned to the determined consensus unit. 4. The method as described in claim 1, characterized in that, according to a preset allocation rule, the business data to be reached for consensus is allocated to at least one consensus unit in the consensus unit set, comprising: Determine the load capacity of each consensus unit in the consensus unit set; According to the load balancing rules, the business data to be reached for consensus is allocated to at least one consensus unit in the consensus unit set. 5. The method as described in claim 4, characterized in that, according to load balancing rules, allocating the service data to be reached for consensus to at least one consensus unit in the consensus unit set includes: The business data to be reached for consensus is assigned to consensus units in the consensus unit set whose load capacity is less than the set conditions. 6. The method as described in claim 1, characterized in that, according to a preset allocation rule, assigning the business data to be reached for consensus to at least one consensus unit in the consensus unit set includes: Determine the amount of resources required to process the business data to be reached in consensus, as well as the amount of idle resources of each consensus unit in the consensus unit set; When the number of consensus units whose idle resources exceed the resources required to process the business data to be reached exceeds a set value, consensus units that need consensus services are determined from the consensus units whose idle resources exceed the resources required to process the business data to be reached, and the business data to be reached is allocated to the determined consensus units in a round-robin manner. When the number of consensus units whose idle resources exceed the resources required to process the business data to be reached for consensus is less than a set value, according to the load balancing rules, consensus units whose load capacity is less than the set condition are determined from the consensus units whose idle resources exceed the resources required to process the business data to be reached for consensus, and the business data to be reached for consensus is allocated to the determined consensus units. 7. The method according to any one of claims 1 to 6, characterized in that determining the consensus unit from the consensus unit set comprises: Determine the working state of each consensus unit in the consensus unit set, wherein the working state includes at least one of normal state and abnormal state; Consensus units are determined from those in a normal working state. 8. The method according to any one of claims 1 to 6, wherein the business data to be consensused includes business data with unordered requirements. 9. A blockchain consensus method, characterized in that it includes: Obtain at least one piece of business data that needs to be reached through consensus; According to a preset allocation rule, the business data to be reached for consensus is allocated in parallel to at least one consensus unit in the consensus unit set. The consensus unit is used to perform consensus processing on the allocated business data to be reached for consensus. The consensus unit is used to provide independent consensus services. The consensus unit includes voting nodes, and the consensus processing is completed by each voting node participating in the consensus. 10. The method as described in claim 9, characterized in that, according to a preset allocation rule, the business data to be reached for consensus is allocated in parallel to at least one consensus unit in the consensus unit set, comprising: The at least one business data to be reached for consensus is grouped to obtain at least one business data group; According to the preset allocation rules, the business data group is allocated in parallel to different consensus units in the consensus unit set. 11. A data storage method based on blockchain, characterized in that it includes: Receive consensus results sent by different consensus units, wherein the consensus unit is any one of claims 1 to 8; Based on the timestamp of the consensus result, the consensus result is stored in a block in the blockchain. 12. The method as described in claim 11, characterized in that storing the consensus result into a block in the blockchain comprises: The consensus result is stored in the block of the node corresponding to the consensus unit that generated the consensus result. 13. A blockchain consensus system, characterized in that the consensus system comprises: allocation units and a consensus unit set containing consensus units, wherein: The allocation unit acquires the business data to be reached in consensus and allocates the business data to be reached in consensus to at least one consensus unit in the consensus unit set according to a preset allocation rule. The consensus set includes consensus units that perform consensus processing on the allocated business data to be reached. Each consensus unit provides an independent consensus service and includes voting nodes. The consensus processing is completed by the participation of each voting node that participates in the consensus process. 14. The consensus system as described in claim 13, wherein the consensus system further comprises: a storage node, wherein: The storage node receives consensus results sent by different consensus units and stores the consensus results sequentially according to their timestamps. 15. A blockchain consensus device, characterized in that it comprises: The acquisition unit acquires the business data to be agreed upon. The processing unit allocates the business data to be reached for consensus to at least one consensus unit in the consensus unit set according to a preset allocation rule. The consensus unit is used to perform consensus processing on the allocated business data to be reached for consensus. The consensus unit is used to provide independent consensus services. The consensus unit includes voting nodes, and the consensus processing is completed by the participation of each voting node that participates in the consensus. 16. The device as described in claim 15, wherein the processing unit allocates the service data to be reached for consensus to at least one consensus unit in the consensus unit set according to a preset allocation rule, comprising: Based on the number of service data to be consensus received, a consensus unit matching the number is randomly selected from the consensus unit set; The business data to be reached for consensus is concurrently assigned to the determined consensus units. 17. The device as described in claim 15, wherein the processing unit allocates the service data to be reached for consensus to at least one consensus unit in the consensus unit set according to a preset allocation rule, comprising: The consensus units that require consensus services are determined from the set of consensus units using a polling method. The business data to be reached for consensus is assigned to the determined consensus unit. 18. The device as described in claim 15, wherein the processing unit allocates the service data to be reached for consensus to at least one consensus unit in the consensus unit set according to a preset allocation rule, comprising: Determine the load capacity of each consensus unit in the consensus unit set; According to the load balancing rules, the business data to be reached for consensus is allocated to at least one consensus unit in the consensus unit set. 19. The device as claimed in claim 18, wherein the processing unit allocates the service data to be reached for consensus to at least one consensus unit in the consensus unit set according to load balancing rules, comprising: The business data to be reached for consensus is assigned to consensus units in the consensus unit set whose load capacity is less than the set conditions. 20. The device as described in claim 15, wherein the processing unit assigns the service data to be reached for consensus to at least one consensus unit in the consensus unit set according to a preset allocation rule, comprising: Determine the amount of resources required to process the business data to be reached in consensus, as well as the amount of idle resources of each consensus unit in the consensus unit set; When the number of consensus units whose idle resources exceed the resources required to process the business data to be reached exceeds a set value, consensus units that need consensus services are determined from the consensus units whose idle resources exceed the resources required to process the business data to be reached, and the business data to be reached is allocated to the determined consensus units in a round-robin manner. When the number of consensus units whose idle resources exceed the resources required to process the business data to be reached for consensus is less than a set value, according to the load balancing rules, consensus units whose load capacity is less than the set condition are determined from the consensus units whose idle resources exceed the resources required to process the business data to be reached for consensus, and the business data to be reached for consensus is allocated to the determined consensus units. 21. The apparatus according to any one of claims 15 to 20, wherein the processing unit determines a consensus unit from the consensus unit set, comprising: Determine the working state of each consensus unit in the consensus unit set, wherein the working state includes at least one of normal state and abnormal state; Consensus units are determined from those in a normal working state. 22. The device according to any one of claims 15 to 20, wherein the service data to be consensused includes service data with unordered requirements. 23. A blockchain consensus device, characterized in that it comprises: The acquisition unit acquires at least one piece of business data pending consensus. The processing unit, according to a preset allocation rule, allocates the business data to be reached for consensus to at least one consensus unit in the consensus unit set in parallel. The consensus unit is used to perform consensus processing on the allocated business data to be reached for consensus. The consensus unit is used to provide independent consensus services. The consensus unit includes voting nodes, and the consensus processing is completed by each voting node participating in the consensus. 24. The device as described in claim 23, characterized in that the processing unit, according to a preset allocation rule, allocates the service data to be reached for consensus to at least one consensus unit in the consensus unit set in parallel, including: The at least one business data to be reached for consensus is grouped to obtain at least one business data group; According to the preset allocation rules, the business data group is allocated in parallel to different consensus units in the consensus unit set. 25. A blockchain-based data storage device, characterized in that it comprises: The receiving unit receives consensus results sent by different consensus units; A storage unit stores the consensus result into a block in the blockchain according to the timestamp of the consensus result, wherein the consensus unit is any one of claims 1 to 8. 26. The device of claim 25, wherein the storage unit stores the consensus result into a block in the blockchain, comprising: The consensus result is stored in the block of the node corresponding to the consensus unit that generated the consensus result.