CN116707759A - Lightweight alliance chain consensus method for high concurrency scene of data flow - Google Patents
Lightweight alliance chain consensus method for high concurrency scene of data flow Download PDFInfo
- Publication number
- CN116707759A CN116707759A CN202310739437.6A CN202310739437A CN116707759A CN 116707759 A CN116707759 A CN 116707759A CN 202310739437 A CN202310739437 A CN 202310739437A CN 116707759 A CN116707759 A CN 116707759A
- Authority
- CN
- China
- Prior art keywords
- reputation
- consensus
- node
- nodes
- group
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 53
- 230000008569 process Effects 0.000 claims abstract description 24
- 230000001360 synchronised effect Effects 0.000 claims abstract description 20
- 238000012795 verification Methods 0.000 claims description 8
- 238000012790 confirmation Methods 0.000 claims description 4
- 238000004806 packaging method and process Methods 0.000 claims description 4
- 230000001960 triggered effect Effects 0.000 claims description 4
- 238000004891 communication Methods 0.000 abstract description 4
- 230000007423 decrease Effects 0.000 abstract description 4
- 230000003993 interaction Effects 0.000 abstract description 2
- 230000007246 mechanism Effects 0.000 abstract description 2
- 238000001514 detection method Methods 0.000 abstract 1
- 230000008901 benefit Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013480 data collection Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000005242 forging Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a lightweight alliance chain consensus method for a high concurrency scene of data circulation, which relates to the technical field of block chains, abandons a common reputation centralization management mechanism, adopts distributed reputation storage and management, selects fewer consensus nodes to participate in consensus according to reputation values, enables reputation to be transmitted together with data packets in a PBFT consensus process, increases and decreases the reputation values through data packet sources and line breakage detection, maintains local reputation synchronization of each node as much as possible through a majority principle, judges whether to update a consensus node group according to a certain rule before a new round of consensus, thereby reducing communication times, improving communication efficiency, and further, temporarily placing synchronous block requests of non-consensus nodes in the face of high concurrency situation when the data interaction frequency is high, thereby providing higher throughput under the condition of huge transaction request quantity, and being obviously superior to the traditional PBFT consensus algorithm in performance.
Description
Technical Field
The invention relates to the technical field of blockchains, in particular to a lightweight alliance chain consensus method for a high concurrency scene of data circulation.
Background
The data circulation scene comprises a plurality of links such as data collection, data sharing, data transaction, data delivery and the like, and a client or a server needs to perform a large amount of data interaction, so that the availability and the security of data are extremely critical to the data circulation, and therefore, the blockchain becomes a common application technology, and the alliance chain becomes one of the first choice of circulating data of all large enterprises under the condition that the public chain lacks control.
The most commonly used alliance chain algorithm is PBFT (Practical Byzantine Fault Tolerance), namely a practical Bayesian fault-tolerant algorithm, belongs to BFT type algorithms, mainly solves the problem of consistency of Bayesian error nodes in a distributed system, reduces algorithm complexity from exponential level to polynomial level on the basis of Bayesian protocol, has higher reliability and safety on the premise of ensuring system operation efficiency,
however, the PBFT algorithm still suffers from the following problems in use: in the consensus process, network bandwidth is very consumed, communication overhead is high, and performance is obviously reduced along with the increase of the number of consensus nodes; under the condition that the number of error consensus nodes is not greater than the maximum fault tolerance number, the system can still normally output blocks, but the performance can be obviously reduced, so that along with the continuous increase of the types and the number of data, the requirements of data circulation scenes on high concurrency are also higher and higher, and therefore, the performance improvement of a alliance chain is also more important.
In the prior art, some solutions exist, fewer consensus nodes are selected to perform consensus based on a reputation mechanism, but the consensus nodes adopt a centralized reputation management method, reputation data are stored in a federated server, the centralized reputation data have risks, the federated server may be down or under malicious attack, and the authenticity and the usability of the reputation value cannot be guaranteed.
Therefore, the lightweight alliance chain consensus method for the high concurrency scene of data flow is provided.
Disclosure of Invention
The invention aims to provide a lightweight alliance chain consensus method for a high concurrency scene of data circulation, which is characterized in that based on an original PBFT algorithm, a reputation value is utilized to directly select consensus nodes, the network transmission overhead of the PBFT is reduced, the throughput is improved as much as possible in the high concurrency scene of data circulation, and the reputation value is stored in a scattered manner, so that the risk brought by centralization is avoided.
In order to achieve the above purpose, the invention provides a lightweight alliance chain consensus method for a high concurrency scene of data circulation, which comprises the following steps:
step one: setting a plurality of nodes, wherein each node establishes a local reputation group, and the initial reputation values of all nodes in the local reputation group are reputation initial values;
step two: each node sorts all nodes according to the local reputation group or the public key sequence number, and a plurality of nodes in the sorting are selected as consensus nodes to form a consensus node group, wherein the maximum fault-tolerant node number is f;
step three: after receiving the client request, the alliance chain system selects a master node, and the master node packages transaction information and broadcasts the transaction information to the consensus node;
step four: the common node receives the transaction information broadcast by the main node, then verifies the transaction information, and sends verification results to all the common nodes through broadcasting, wherein the verification results comprise three stages, namely Pre-prepare, prepare, commit;
step five: after all the confirmation and packaging, the packaged blocks are uplink;
step six: the preparation node sends a synchronous block request to any consensus node, and after the consensus node receives the synchronous request, the consensus node compares the current CPU utilization rate with a threshold value, and the method is divided into the following two cases:
when the CPU utilization rate or the CPU utilization rate corresponding to the alliance chain process exceeds a threshold value, the synchronous block request is put aside, and when the CPU utilization rate is gradually reduced until the CPU utilization rate is lower than the threshold value, the synchronous block request is canceled, the synchronous block is carried out, and the step seven is entered;
when the CPU utilization rate or the CPU utilization rate corresponding to the alliance chain process is lower than a threshold value, directly synchronizing the blocks, and entering a step seven;
step seven: the consensus node sends all blocks required to the preparation node;
step eight: after receiving the blocks, the preparation node sends a reputation synchronization request to all the consensus nodes;
step nine: each consensus node sends its own local reputation set to the preparation node;
step ten: and after the completion of one round of consensus, all the consensus nodes and the preparation nodes judge whether the reputation updating condition of the consensus node group is triggered according to the reputation group stored locally.
Preferably, in the second step, the sorting mode sorts the reputation values of the local records from high to low, and when the reputation values are the same, sorts the reputation values according to the public keys, wherein the public key values are from small to large.
Preferably, in the fourth step, the specific steps in the three stages of Pre-prepare, prepare and Commit are as follows:
in the Pre-preparation stage, a master node broadcasts a preparation packet to all the consensus nodes considered by the master node in the group through threads, and generates a Sign packet, each consensus node generates the Sign packet after receiving the preparation packet, broadcasts the Sign packet, and each Sign packet is written into a local reputation group;
in the preparation stage, each consensus node broadcasts own Sign package, each consensus node collects the Sign package, when the consensus node has at least 2f+1 Sign packages in total, a reputation group is taken out from each Sign package, a new reputation group is obtained according to a majority principle, the obtained new reputation group is stored locally, a Commit package is generated, and the local new reputation group is written into each Commit package;
and in the Commit stage, each consensus node broadcasts own Commit packet, each consensus node collects the Commit packets, and when the consensus nodes have at least 2f+1 Commit packets in total, the reputation group is taken out from each Commit packet, a new reputation group is updated according to a majority principle, reputation values of all the consensus nodes and the preparation nodes +1 are obtained, and block landing is executed.
Preferably, when the Pre-preparation stage processes the preparation packet, when the preparation stage processes the Sign packet, and when the Commit stage processes the Commit packet, the current consensus node detects the connection condition of all the consensus nodes, and the reputation-1 of the consensus node with connection failure.
Preferably, in the step eight, the reputation synchronization request includes a block height d and a highest block hash block_hash.
Preferably, in the step nine, the process of preparing node synchronization reputation is as follows:
when the preparation node collects at least 2f+1 reputation groups sent by different consensus nodes, performing reputation synchronization according to a majority principle;
when the preparation node does not collect at least 2f+1 reputation groups before the next round of consensus begins, the reputation group cache is emptied and the next round of consensus is re-collected.
Preferably, in the step ten, the update condition of the reputation of the consensus node group is as follows:
resetting the reputation of all nodes to be the reputation initial value when the reputation values of all nodes reach the reputation upper limit value or fall to the reputation lower limit value;
when not all the node reputation values reach the reputation upper limit value or fall to the reputation lower limit value and nodes with reputation values smaller than the reputation threshold value exist, the consensus node group is reordered according to the reputation values, and when no nodes with reputation values smaller than the reputation threshold value exist, the consensus node group is not updated.
Therefore, the lightweight alliance chain consensus method for the high concurrency scene of data circulation, which adopts the method, has the following benefits:
(1) In the invention, each node is provided with the credit group, credit records are carried out on other nodes, and credit values are stored in a scattered way, so that risks caused by centralization are avoided.
(2) In the invention, the credit value is utilized to directly select the consensus node, thereby reducing the transmission overhead of the PBFT three-stage network and improving the throughput as much as possible under the high concurrency scene of data circulation.
The technical scheme of the invention is further described in detail through the drawings and the embodiments.
Drawings
FIG. 1 is a main steps of a lightweight alliance chain consensus method for a high concurrency scenario of data flow in the present invention when consensus is performed;
FIG. 2 is a block overall design of a lightweight federation chain consensus method for high concurrency scenarios of data traffic in accordance with the present invention;
FIG. 3 is an update condition of a consensus node group in a lightweight federation chain consensus method for a high concurrency scenario for data flow in accordance with the present invention;
FIG. 4 is a comparison of throughput of a lightweight federation chain consensus method for a high concurrency scenario for data traffic in the case of all normal nodes;
fig. 5 is a comparison of throughput of a lightweight alliance chain consensus method for a high concurrency scenario of data flow in the presence of a bayer node according to the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. The components of the embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the invention, as presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
1-2, the invention provides a lightweight alliance chain consensus method for a high concurrency scene of data circulation, which comprises the following steps:
step one: setting a plurality of nodes, wherein each node establishes a local reputation group, and the initial reputation values of all nodes in the local reputation group are reputation initial values;
step two: each node sorts all nodes according to the local reputation group or the public key sequence number in a way of sorting from high to low according to the reputation value recorded locally, when the reputation values are the same, sorting according to the public key, wherein the public key value is from small to large, and selecting a plurality of first nodes in the sorting as consensus nodes to form a consensus node group, wherein the maximum fault-tolerant node number is f;
step three: after receiving the client request, the alliance chain system selects a master node, and the master node packages transaction information and broadcasts the transaction information to all consensus nodes;
step four: the common node receives the transaction information broadcast by the main node, then verifies the transaction information, and sends verification results to all the common nodes through broadcasting, wherein the verification results comprise three stages, namely Pre-prepare, prepare, commit;
in the Pre-preparation stage, the master node broadcasts a preparation packet to all the consensus nodes considered by the master node in the group through threads, and generates a Sign packet, after each consensus node receives the preparation packet, the master node also generates a Sign packet, broadcasts the Sign packet, and writes each Sign packet into a local reputation group;
in the preparation stage, each consensus node broadcasts own Sign package, each consensus node collects the Sign package, when the consensus node has at least 2f+1 Sign packages in total, a reputation group is taken out from each Sign package, a new reputation group is obtained according to a majority principle, the obtained new reputation group is stored locally, a Commit package is generated, and the local new reputation group is written into each Commit package;
in the Commit stage, each consensus node broadcasts own Commit packet, each consensus node collects the Commit packet, when the consensus node has at least 2f+1 Commit packets in total, the reputation group is taken out from each Commit packet, the new reputation group is updated according to the majority principle, the reputation value of all the consensus nodes and the preparation nodes +1, and the block landing is executed;
when a Pre-preparation stage processes a preparation packet, when a signature packet is processed in the preparation stage, and when a Commit packet is processed in the Commit stage, the current consensus node can detect the connection condition of all the consensus nodes, and the reputation-1 of the consensus node with connection failure;
step five: after all the confirmation and packaging, the packaged blocks are uplink;
step six: the preparation node sends a synchronous block request to any consensus node, and after the consensus node receives the synchronous request, the consensus node compares the current CPU utilization rate with a threshold value, and the method is divided into the following two cases:
when the CPU utilization rate or the CPU utilization rate corresponding to the alliance chain process exceeds a threshold value, the synchronous block request is put aside, and when the CPU utilization rate is gradually reduced until the CPU utilization rate is lower than the threshold value, the synchronous block request is canceled, the synchronous block is carried out, and the step seven is entered;
when the CPU utilization rate or the CPU utilization rate corresponding to the alliance chain process is lower than a threshold value, directly synchronizing the blocks, and entering a step seven;
step seven: the consensus node sends all blocks required to the preparation node;
step eight: after receiving the blocks, the preparation node sends a reputation synchronization request to all the consensus nodes, wherein the reputation synchronization request comprises a block height d and a highest block hash block_hash;
step nine: each consensus node sends own local credit group to the preparation node, and the specific process is as follows:
when the preparation node collects at least 2f+1 reputation groups sent by different consensus nodes, performing reputation synchronization according to a majority principle, and when the preparation node does not collect at least 2f+1 reputation groups before starting next consensus, clearing a reputation group cache, and re-collecting next consensus;
step ten: and after the completion of one round of consensus, all the consensus nodes and the preparation nodes judge whether the reputation updating condition of the consensus node group is triggered according to the reputation group stored locally, wherein the condition is as follows:
resetting the reputation of all nodes to be the reputation initial value when the reputation values of all nodes reach the reputation upper limit value or fall to the reputation lower limit value;
when not all the node reputation values reach the reputation upper limit value or fall to the reputation lower limit value and nodes with reputation values smaller than the reputation threshold value exist, the consensus node group is reordered according to the reputation values, and when no nodes with reputation values smaller than the reputation threshold value exist, the consensus node group is not updated.
Examples
The invention discloses a lightweight alliance chain consensus method for a high concurrency scene of data circulation, which relates to the following three nodes:
1. consensus node: in the invention, the node participating in consensus is not completely determined, and the node judges whether the node itself should participate in consensus or not through the own local credit group, and other nodes also judge whether the node should participate in consensus or not, so that whether one node can really participate in consensus or not is a double judgment.
2. Preparing a node: refers to nodes that have the possibility of participating in consensus, but do not. The preparation node and the consensus node can exchange identities at any time in the process of reputation increase and decrease and judgment.
3. Observation node: the node does not participate in consensus, but can synchronize data on a chain in real time, if the node wants to have the possibility of participating in consensus, a transaction on the chain needs to be completed, the transaction on the chain is updated to be a preparation node, and no other way exists.
In PBFT, the consensus nodes can be divided into master nodes and duplicate nodes, where the master nodes are mainly responsible for receiving client transaction requests, packing transactions into blocks, broadcasting block messages to duplicate nodes and performing block consensus, there is one master node in each round of consensus, and in order to prevent the master nodes from forging blocks, the master nodes are switched after each round of consensus, and the duplicate nodes are responsible for block consensus, there are multiple duplicate nodes in each round of consensus, and their processing procedures are similar.
As shown in the figure, the lightweight alliance chain consensus method for a high concurrency scene of data flow is applied to a 10-node system and specifically comprises the following steps:
step one: setting 10 nodes in total, wherein 4 nodes are actual consensus nodes, 6 nodes are preparation nodes, the Bayesian-to-ascribed fault tolerance number is f=1, and at the beginning, all 10 nodes have no initial reputation, so that the nodes are initialized locally, and the initial reputation value of the 10 nodes is set to be 100;
step two: because the initial reputation of all the nodes are 100 and the reputation of all the nodes are the same, all the nodes can be sequenced according to the public keys, the first 4 nodes with the minimum public key values are judged to be consensus nodes, and all the consensus nodes are combined to form a consensus node group;
step three: after receiving a client request, the alliance chain system selects a master node from the consensus node group, the master node takes a transaction from a transaction pool, packages the transaction into blocks, encodes the blocks into a preparation packet, and waits for entering a Pre-preparation stage to broadcast;
step four: as shown in fig. 2, after receiving the transaction information broadcast by the master node, the consensus node performs verification, and sends the verification result to other consensus nodes through broadcasting, which includes three stages, pre-prepare, prepare, commit respectively;
in the Pre-preparation stage, the master node broadcasts the preparation packet to all the consensus nodes considered by the master node in the group through threads, generates a signature packet, and the consensus nodes also generate the signature packet and wait to enter the preparation stage after receiving the preparation packet. In addition to the information such as the attempt number v, the block number n, the message abstract m and the like, the node also encodes the stored reputation group and writes the reputation group into the Sign packet;
in the preparation stage, each consensus node collects Sign packets, a node collects at least 3 Sign packets and indicates that the node reaches a state capable of submitting blocks, a reputation group is taken out from each Sign packet, a new reputation group is calculated according to a majority principle, reputation values are increased and decreased according to Sign packet sources, the obtained new reputation group is stored locally, the new reputation group is encoded and then written into a Commit packet, and at the moment, the Commit packet also contains reputation groups except for information such as attempt number v, block number n, message abstract m and the like, and then the Commit packet is broadcasted;
in the Commit stage, each consensus node collects Commit packets, after a certain node collects at least 3 Commit packets, a reputation group is taken out from each Commit packet, a new reputation group is calculated according to a majority principle, reputation value increase and decrease are carried out according to the source of the Commit packets, then reputation values +1 of all consensus nodes and preparation nodes are obtained, the new reputation group is stored locally, and the latest block of a local cache is directly submitted to a database;
when a Pre-preparation stage processes a preparation packet, when a signature packet is processed in the preparation stage, and when a Commit packet is processed in the Commit stage, the current consensus node can detect the connection condition of other consensus nodes, and the reputation-1 of the consensus node with connection failure;
step five: after all the confirmation and packaging, the packaged blocks are uplink;
step six: the preparation node needs to synchronize the latest block and sends a synchronous block request to the consensus node, wherein the request comprises a required block number range, and the consensus node can occupy small communication overhead in response to the requests, so that when the consensus node group processes a large amount of transactions, in order to avoid influencing throughput in a high concurrency period, the consensus node can judge whether to respond to the synchronous block request of the non-consensus node at a certain moment by detecting the CPU utilization rate occupied by the current process in real time, if the CPU utilization rate is greater than a certain threshold value, the consensus node can be considered to perform consensus under the condition of high concurrency, the synchronous block request of the non-consensus node can be temporarily not responded, otherwise, the request block can be normally responded, and the required block is sent out;
step seven: after receiving the synchronous request, the consensus node sends all blocks required to the preparation node;
step eight: after the preparation node receives the blocks, the preparation node sends a reputation synchronization request to all the consensus nodes, wherein the reputation synchronization request comprises the following contents: the reputation synchronization request comprises a block height d and a highest block hash block_hash;
step nine: each consensus node sends the reputation group which is maintained locally to the preparation node, and the specific process is as follows:
when the preparation node collects at least 2f+1 reputation groups sent by different consensus nodes, performing reputation synchronization according to a majority principle;
when the preparation node does not collect at least 2f+1 reputation groups before the next round of consensus begins, the reputation group cache is emptied, and the next round of consensus is collected again;
step ten: as shown in fig. 3, after the completion of a round of consensus, all the consensus nodes and the preparation nodes can determine whether the reputation update condition of the consensus node group is triggered according to the locally stored reputation group, and the condition is as follows:
setting the credit upper limit value to be 200, the credit lower limit value to be 0 and the credit threshold value to be 60;
resetting all node reputation as 100 when all node reputation values reach 200 or are equal to 0;
when not all node reputation values reach 200 or are equal to 0 and there are nodes with reputation less than 60, the consensus node group is reordered according to the selected reputation value, and when there are no nodes with reputation less than 60, the consensus node group is not updated.
As shown in fig. 4-5, in the experimental process of the present invention, experiments are performed under the condition that the total number of nodes is 4, 5, 6, 7, 8, 9, and 10, the number of nodes actually participating in consensus is 4, and the number of preliminary nodes is 0, 1, 2, 3, 4, 5, and 6 respectively, compared with the conventional PBFT algorithm.
Under the condition that all nodes normally operate, as shown in fig. 4, the throughput of the traditional PBFT algorithm is obviously reduced along with the increase of the number of the nodes, namely 10688tx/s, 9092tx/s, 7833tx/s, 6681tx/s, 5439tx/s, 4740tx/s and 3356tx/s, respectively, while the throughput of the invention is basically not affected by the number of the nodes, namely 10640tx/s, 10566tx/s, 10552tx/s, 10567tx/s, 10442tx/s, 10453tx/s and 10487tx/s, respectively; in the case where there are 1 bayer pattern node, as shown in fig. 5, the throughput of the conventional PBFT algorithm decreases with increasing number of nodes, which are 5708tx/s, 5096tx/s, 4592tx/s, 4067tx/s, 3494tx/s, 3082tx/s, 2574tx/s, respectively, whereas the throughput of the present invention is substantially unaffected by the number of nodes, 5692tx/s, 9288tx/s, 9263tx/s, 9179tx/s, 9168tx/s, 9152tx/s, 9169tx/s, respectively, as low as the throughput of the conventional PBFT algorithm at 4 nodes, because there are no spare nodes available to replace the bayer pattern node for consensus.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention and not for limiting it, and although the present invention has been described in detail with reference to the preferred embodiments, it will be understood by those skilled in the art that: the technical scheme of the invention can be modified or replaced by the same, and the modified technical scheme cannot deviate from the spirit and scope of the technical scheme of the invention.
Claims (7)
1. A lightweight alliance chain consensus method for a high concurrency scene of data circulation is characterized by comprising the following steps: the method comprises the following steps:
step one: setting a plurality of nodes, wherein each node establishes a local reputation group, and the initial reputation values of all nodes in the local reputation group are reputation initial values;
step two: each node sorts all nodes according to the local reputation group or the public key sequence number, and a plurality of nodes in the sorting are selected as consensus nodes to form a consensus node group, wherein the maximum fault-tolerant node number is f;
step three: after receiving the client request, the alliance chain system selects a master node, and the master node packages transaction information and broadcasts the transaction information to the consensus node;
step four: the common node receives the transaction information broadcast by the main node, then verifies the transaction information, and sends verification results to all the common nodes through broadcasting, wherein the verification results comprise three stages, namely Pre-prepare, prepare, commit;
step five: after all the confirmation and packaging, the packaged blocks are uplink;
step six: the preparation node sends a synchronous block request to any consensus node, and after the consensus node receives the synchronous request, the consensus node compares the current CPU utilization rate with a threshold value, and the method is divided into the following two cases:
when the CPU utilization rate or the CPU utilization rate corresponding to the alliance chain process exceeds a threshold value, the synchronous block request is put aside, and when the CPU utilization rate is gradually reduced until the CPU utilization rate is lower than the threshold value, the synchronous block request is canceled, the synchronous block is carried out, and the step seven is entered;
when the CPU utilization rate or the CPU utilization rate corresponding to the alliance chain process is lower than a threshold value, directly synchronizing the blocks, and entering a step seven;
step seven: the consensus node sends all blocks required to the preparation node;
step eight: after receiving the blocks, the preparation node sends a reputation synchronization request to all the consensus nodes;
step nine: each consensus node sends its own local reputation set to the preparation node;
step ten: and after the completion of one round of consensus, all the consensus nodes and the preparation nodes judge whether the reputation updating condition of the consensus node group is triggered according to the reputation group stored locally.
2. The lightweight federation chain consensus method for high concurrency scenarios for data traffic of claim 1, wherein: in the second step, the ordering mode orders the reputation values of the local records from high to low, and when the reputation values are the same, the ordering mode orders the public keys from small to large.
3. The lightweight federation chain consensus method for high concurrency scenarios for data traffic of claim 1, wherein: in the fourth step, the specific steps in the three stages of Pre-prepare, prepare and Commit are as follows:
in the Pre-preparation stage, a master node broadcasts a preparation packet to all the consensus nodes considered by the master node in the group through threads, and generates a Sign packet, each consensus node generates the Sign packet after receiving the preparation packet, broadcasts the Sign packet, and each Sign packet is written into a local reputation group;
in the preparation stage, each consensus node broadcasts own Sign package, each consensus node collects the Sign package, when the consensus node has at least 2f+1 Sign packages in total, a reputation group is taken out from each Sign package, a new reputation group is obtained according to a majority principle, the obtained new reputation group is stored locally, a Commit package is generated, and the local new reputation group is written into each Commit package;
and in the Commit stage, each consensus node broadcasts own Commit packet, each consensus node collects the Commit packets, and when the consensus nodes have at least 2f+1 Commit packets in total, the reputation group is taken out from each Commit packet, a new reputation group is updated according to a majority principle, reputation values of all the consensus nodes and the preparation nodes +1 are obtained, and block landing is executed.
4. The lightweight federation chain consensus method for high concurrency scenarios for data traffic according to claim 3, wherein: when the Pre-preparation stage processes the preparation packet, when the preparation stage processes the Sign packet, and when the Commit stage processes the Commit packet, the current consensus node can detect the connection condition of all the consensus nodes, and the reputation-1 of the consensus node with connection failure.
5. The lightweight federation chain consensus method for high concurrency scenarios for data traffic of claim 1, wherein: in the eighth step, the reputation synchronization request includes a block height d and a highest block hash block_hash.
6. The lightweight federation chain consensus method for high concurrency scenarios for data traffic of claim 1, wherein: in the step nine, the process of preparing node synchronization reputation is as follows:
when the preparation node collects at least 2f+1 reputation groups sent by different consensus nodes, performing reputation synchronization according to a majority principle;
when the preparation node does not collect at least 2f+1 reputation groups before the next round of consensus begins, the reputation group cache is emptied and the next round of consensus is re-collected.
7. The lightweight federation chain consensus method for high concurrency scenarios for data traffic of claim 1, wherein: in the step ten, the update condition of the credit of the consensus node group is as follows:
resetting the reputation of all nodes to be the reputation initial value when the reputation values of all nodes reach the reputation upper limit value or fall to the reputation lower limit value;
when not all the node reputation values reach the reputation upper limit value or fall to the reputation lower limit value and nodes with reputation values smaller than the reputation threshold value exist, the consensus node group is reordered according to the reputation values, and when no nodes with reputation values smaller than the reputation threshold value exist, the consensus node group is not updated.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310739437.6A CN116707759B (en) | 2023-06-20 | 2023-06-20 | Lightweight alliance chain consensus method for high concurrency scene of data flow |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310739437.6A CN116707759B (en) | 2023-06-20 | 2023-06-20 | Lightweight alliance chain consensus method for high concurrency scene of data flow |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116707759A true CN116707759A (en) | 2023-09-05 |
| CN116707759B CN116707759B (en) | 2024-02-20 |
Family
ID=87837210
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310739437.6A Active CN116707759B (en) | 2023-06-20 | 2023-06-20 | Lightweight alliance chain consensus method for high concurrency scene of data flow |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116707759B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117527834A (en) * | 2024-01-04 | 2024-02-06 | 成都理工大学 | Improved PBFT consensus method based on reputation scoring mechanism |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200162261A1 (en) * | 2018-11-18 | 2020-05-21 | Ramachandran Iyer | System and method of blockchain consensus mechanism with custom hardware based on geographic distribution, density, node asset and reputation |
| CN113660125A (en) * | 2021-08-18 | 2021-11-16 | 中国科学技术大学 | Consensus method and device based on random credible committee |
| CN114048517A (en) * | 2022-01-14 | 2022-02-15 | 北京大学深圳研究生院 | Dual channel consensus system and method for blockchains, computer readable storage medium |
| WO2022095780A1 (en) * | 2020-11-06 | 2022-05-12 | 深圳前海微众银行股份有限公司 | Bft-based blockchain consensus method and device |
| CN115277722A (en) * | 2022-07-27 | 2022-11-01 | 长安大学 | DR-PBFT improved algorithm based on credit value model |
| CN115412374A (en) * | 2022-11-01 | 2022-11-29 | 国网浙江省电力有限公司金华供电公司 | Safe data sharing method based on credit consensus mechanism |
-
2023
- 2023-06-20 CN CN202310739437.6A patent/CN116707759B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200162261A1 (en) * | 2018-11-18 | 2020-05-21 | Ramachandran Iyer | System and method of blockchain consensus mechanism with custom hardware based on geographic distribution, density, node asset and reputation |
| WO2022095780A1 (en) * | 2020-11-06 | 2022-05-12 | 深圳前海微众银行股份有限公司 | Bft-based blockchain consensus method and device |
| CN113660125A (en) * | 2021-08-18 | 2021-11-16 | 中国科学技术大学 | Consensus method and device based on random credible committee |
| CN114048517A (en) * | 2022-01-14 | 2022-02-15 | 北京大学深圳研究生院 | Dual channel consensus system and method for blockchains, computer readable storage medium |
| CN115277722A (en) * | 2022-07-27 | 2022-11-01 | 长安大学 | DR-PBFT improved algorithm based on credit value model |
| CN115412374A (en) * | 2022-11-01 | 2022-11-29 | 国网浙江省电力有限公司金华供电公司 | Safe data sharing method based on credit consensus mechanism |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117527834A (en) * | 2024-01-04 | 2024-02-06 | 成都理工大学 | Improved PBFT consensus method based on reputation scoring mechanism |
| CN117527834B (en) * | 2024-01-04 | 2024-03-26 | 成都理工大学 | Improved PBFT consensus method based on reputation scoring mechanism |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116707759B (en) | 2024-02-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111131209B (en) | Improved efficient consensus method, system, computer device and storage medium | |
| CN111355810A (en) | Improved PBFT consensus method based on credit and voting mechanism | |
| CN114218612B (en) | Consensus method suitable for alliance chain high-frequency transaction scene | |
| CN116707759B (en) | Lightweight alliance chain consensus method for high concurrency scene of data flow | |
| CN112511590A (en) | Efficient storage reconfiguration method for block chain fragmentation | |
| CN109189751A (en) | Method of data synchronization and terminal device based on block chain | |
| CN113655969B (en) | Data balanced storage method based on streaming distributed storage system | |
| CN111414420A (en) | Improved PBFT block chain consensus method | |
| CN112929186B (en) | Alliance chain consensus optimization method based on communication mode structure | |
| CN114338040B (en) | Block chain node grouping multi-chain three-time consensus method | |
| CN116633942A (en) | Bayesian-busy fault tolerance consensus method for high-speed response client | |
| CN115665170A (en) | Block chain consensus method based on reputation and node compression mechanism | |
| CN115426353A (en) | Method for constructing federated learning architecture integrating block chain state fragmentation and credit mechanism | |
| CN114760135A (en) | Optimization method of block chain fault-tolerant consensus scheme | |
| CN112866025B (en) | Intelligent contract fragmentation processing method | |
| CN113377869A (en) | Block chain shared information balanced storage method | |
| CN115733841A (en) | Block chain dynamic fragmentation expansion method based on image flow segmentation | |
| Li et al. | EBFT: A hierarchical and group-based byzantine fault tolerant consensus algorithm | |
| CN113746859B (en) | High-network-performance and high-security VaPBFT block chain consensus method | |
| CN112398640A (en) | Optimized block chain consensus algorithm | |
| CN113518126A (en) | Cross fault-tolerant method for alliance chain | |
| CN115102899B (en) | Block link point tree form fragmentation method based on load balancing | |
| Kang et al. | Blockchain-based High-reliability Recovery and Verification Mechanism for Power Data Storage Nodes | |
| CN116633699B (en) | Product anti-counterfeiting traceability information trusted processing method and system based on block chain | |
| CN117407467B (en) | Block chain code storage system combining bloom filter and DHT |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |