CN115276999A - Self-adaptive switching efficient fault-tolerant consensus method based on trust model - Google Patents
Self-adaptive switching efficient fault-tolerant consensus method based on trust model Download PDFInfo
- Publication number
- CN115276999A CN115276999A CN202210650990.8A CN202210650990A CN115276999A CN 115276999 A CN115276999 A CN 115276999A CN 202210650990 A CN202210650990 A CN 202210650990A CN 115276999 A CN115276999 A CN 115276999A
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- nodes
- trust
- algorithm
- 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 25
- 230000003044 adaptive effect Effects 0.000 claims abstract description 7
- 238000010187 selection method Methods 0.000 claims abstract description 4
- 238000012795 verification Methods 0.000 claims description 6
- 230000010076 replication Effects 0.000 claims description 4
- 230000003362 replicative effect Effects 0.000 claims description 3
- 230000003542 behavioural effect Effects 0.000 claims description 2
- 238000011156 evaluation Methods 0.000 claims description 2
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000013210 evaluation model Methods 0.000 description 1
Images
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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention relates to the technical field of block chains, in particular to a trust model-based adaptive switching efficient fault-tolerant consensus method. The method comprises the steps of optimizing a Raft and PBFT consensus algorithm, and then providing a consensus switching mechanism to guarantee the Byzantine fault tolerance and the high efficiency of the consensus algorithm. And finally, aiming at the consensus switching mechanism, a trust model and self-adaptive main node selection method is provided so as to ensure the stability and the safety of the block chain system in the consensus switching process.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to a trust model-based adaptive switching efficient fault-tolerant consensus method.
Background
The block chain is a novel distributed system which combines computer technologies such as distributed data storage, point-to-point transmission, encryption algorithm, consensus mechanism and the like, and has the advantages that decentralization is achieved, the block chain technology utilizes data encryption, distributed consensus, timestamp and other technologies, so that point-to-point transaction does not need a credible third party endorsement any more, and therefore the problems that cost is difficult to reduce, data is easy to leak, data storage safety is poor and the like due to centralized storage of the data can be solved greatly.
The consensus mechanism is the core mechanism for guaranteeing the consistency of the blockchain system, and refers to how a series of nodes in the distributed system agree on a certain decision. A safe and stable consensus algorithm can ensure that all nodes in the distributed system operate like a node entity, and is a basic guarantee for keeping data in a block chain consistent.
The existing Consensus Algorithm can be divided into a Byzantine Fault-tolerant Consensus Algorithm and a non-Byzantine Fault-tolerant Consensus Algorithm according to whether a Byzantine error can be tolerated or not, and the most mainstream Consensus algorithms In the two categories are the PBFT Consensus Algorithm provided In Practical Byzantine Fault Tolerance and the Raft Consensus Algorithm provided In In Search of an Understandable Consensus Algorithm.
The PBFT consensus algorithm can solve Byzantine errors of nodes in a block chain system in a consensus process, but the algorithm complexity is high, the load pressure of a main node is high, and the algorithm efficiency is difficult to improve. The Raft consensus algorithm, while operating more efficiently than the PBFT consensus algorithm, is not resistant to byzantine attacks in the block-chain system. Besides the two consensus algorithms, none of the existing mainstream consensus algorithms can give consideration to both Byzantine fault tolerance and high efficiency.
Disclosure of Invention
In order to solve the problems, the invention provides a high-efficiency fault-tolerant consensus method based on a trust model and adopting self-adaption switching.
The technical scheme of the invention is as follows:
a trust model-based adaptive switching efficient fault-tolerant consensus method comprises the following steps:
step (1) client-side block mappingChain system initiates transaction request<REQUEST,TX,σc>To the master node, a Raft consensus algorithm is run in the blockchain system at this time, wherein TX is the transaction requested to be executed by the client, sigmacThe client is signed.
And (2) after receiving the transaction request, the master node firstly sends a message for adding a new log entry to all the slave nodes, and each slave node feeds back a message of successful replication to the master node after receiving the message and successfully replicating.
Step (3) the master node collects and counts feedback information, and when more than half of slave nodes successfully copy the feedback information of the log entries, namely the consensus is successful, the Raft consensus algorithm is continuously operated in the block chain system; and if the feedback message does not reach half, entering a consistency check stage.
Step (4) entering a consistency check stage, sending verification messages to all nodes to check whether the latest logs of each node are the same or not, and if yes, continuing to run a Raft consensus algorithm; if the two nodes are not consistent, the main node sends a consensus switching notification to all the nodes, the block chain system enters a self-adaptive consensus switching stage based on a trust model, and the block chain system is switched from a Raft consensus algorithm to a PBFT consensus algorithm.
Step (5) entering a self-adaptive consensus switching stage based on a trust model, and classifying all nodes by the system according to the trust model: the nodes are respectively classified into a high trust value group and a low trust value group according to the trust value, and the PBFT consensus algorithm only runs among the nodes in the high trust value group; the nodes of the low trust value group only send data and do not participate in consensus.
And (6) after the nodes are grouped, the nodes in the high-trust group mutually send 'main node election' information, and a main node election stage is started, wherein the main node election method abandons a method of replacing a main node by using view conversion in the traditional PBFT and adopts a safer self-adaptive main node selection method to select the main node.
And (7) after the master node is selected, the rest nodes in the high trust value group are slave nodes. At this point, the consensus algorithm in the block chain system is switched from the Raft consensus algorithm to the PBFT consensus algorithm. All nodes send verification message requests to achieve consensus; after all nodes perform a complete round of PBFT consensus, the block chain system updates the credit values of all nodes according to the trust model and reclassifies the nodes. Subsequently, step (6) is performed in the new high trust group to reselect the master node, which ensures that the node with good performance in the consensus can be replaced by the master node for consensus.
And (8) after multiple rounds of PBFT consensus, taking a rogue node or a node with poor performance into the block chain system, wherein the node is not a main node and participates in the consensus or is eliminated, and the main node in the PBFT consensus triggers the consensus to be switched back to the Raft consensus. The self-adaptive main node selection algorithm ensures that the main node has high credit value in the PBFT consensus, namely, a good node is shown, so after the PBFT consensus algorithm is switched back, the main node can be directly used as the main node in the Raft consensus algorithm, and the rest nodes are slave nodes to continuously operate the Raft consensus algorithm.
Further, for the step (5), the specific implementation process is as follows:
(1) Trust model:
consensus behavioral trust Tcons: according to the behavior and the performance of each round of the node in the consensus process, the node is subjected to trust evaluation at the end of each round, and the node is divided into three states: benign status, downtime status, and doing malicious status;
the benign state refers to a round of consensus, if node i is the master node: the node i generates a valid block and can correctly reach the agreement; if node i is a slave node: node i broadcasts the same message and keeps consistent with most nodes;
the downtime state refers to that in one round of consensus, if a node i is a main node: the node i does not generate a new block; if node i is a slave node: node i cannot broadcast the message due to crash;
the malicious state means that if the node i is the master node in a round of consensus: the node i generates an invalid block in the round of consensus; if node i is a slave node: the information broadcast by the node i is different from each other, or the information broadcast by the node i is different from most nodes;
the consensus behavior trust of the node i in the t-th round is calculated as follows:
if the node i is the master node:
if node i is a slave node:
wherein xpAnd xbRepresenting the speed of the master and slave node respectively at which the trust values decrease, 0<xp<xb<1；ypAnd ybRepresenting the rate of rise of the trust values of the master node and the slave node, 0<yb<yp<0.03。
In the step (6), the specific implementation process of the self-adaptive master node selection is as follows:
and a self-adaptive main node selection mechanism is adopted to select the main node, so that the nodes with good performance in the process of consensus are ensured to be selected as the main node with higher probability, and the condition that the time zone block chain is easy to attack when the malicious node becomes the main node is reduced. The probability of the benign node i being selected as the master node in round t consensus is calculated by the following formula:
where N is the number of consensus nodes and α >1 is a probability factor, calculated by the following formula:
wherein
And
the average credit values of the t-th round consensus and the t-1 th round consensus node are respectively.
To ensure unpredictability of the master node election process, a distribution in the interval [0,1 ] should be generated]The random number RNum above; generating by hashing the block header of the latest block through SHA256 algorithm
If the node i is selected as a new consensus master node, the following conditions need to be satisfied:
the method has the advantages that under the scene that the data sharing of the Internet of things and the like have double requirements on the high efficiency and the Byzantine fault tolerance of the consensus algorithm, the consensus algorithm can be safely and efficiently switched between the Raft algorithm and the PBFT algorithm, the stability of the system is guaranteed, and meanwhile the high efficiency and the Byzantine fault tolerance of the algorithm can be considered. In addition, the invention designs a credit evaluation model and a self-adaptive main node selection mechanism, and by evaluating the credit value of the nodes, the nodes with good performance are ensured to become the main nodes with higher probability in the algorithm switching process, and the possibility of the block chain being attacked is reduced.
Drawings
FIG. 1 is an overall flow chart of the present invention.
Detailed Description
The following further describes a specific embodiment of the present invention with reference to the drawings and technical solutions.
A flow chart of an embodiment of the present invention is shown in fig. 1.
(1) A Raft consensus stage: the client initiates a transaction request to the blockchain system<REQUEST,TX,σc>Giving the master node, and running a Raft consensus algorithm in the blockchain system at the moment, wherein TX is a transaction requested to be executed by the client, sigmacThe client is signed.
After receiving the transaction request, the master node firstly sends a message of adding a new log entry < appendix entriesrc, term, leader ID, prevIndex, preTerm, entris [ ], commit > to the slave node, wherein Leader ID represents the ID of Leader; prevIndex represents the index of the latest log in the node, and preTerm represents the expiration of the latest log in the node; and entris [ ] represents a log entry, commit represents the latest submitted log in the Leader, and each slave node feeds back a message of successful replication to the master node after receiving the message and successfully replicating.
After receiving the message, the slave node feeds back a message < Success, index, followerId, uniqueNum > of successful replication to the master node, wherein the followerId represents a sender of the feedback message; uniqueNum represents a unique field; and the Leader collects feedback messages and counts, and when the slave nodes are over half successfully copied with the log entries, the consensus is successful.
The master node collects and counts feedback information, and when more than half of slave nodes successfully copy the feedback information of the log entries, namely the consensus is successful, the block chain system continues to run the Raft consensus algorithm; if the feedback message does not reach half, entering the consistency check stage,
(2) And (3) consistency checking: entering a consistency check stage, sending verification messages to all nodes to check whether the latest logs of each node are the same or not, and if yes, continuing to run a Raft consensus algorithm; if the two nodes are not consistent, the main node sends a consensus switching notification to all the nodes, the block chain system enters a self-adaptive consensus switching stage based on a trust model, and the block chain system is switched from a Raft consensus algorithm to a PBFT consensus algorithm.
(3) Consensus switching phase (from Raft to PBFT): first, the system will initialize a credit value for all nodes to determine the node's status and credit in consensus. During initialization, if the detection module detects that the node sends an error or inconsistent message in the RAFT consensus, the node is reset. Since the node was once a malicious node, the possibility of continuing malicious behavior still exists. The credit value for this node is initialized to 0.2. The credit values of the other nodes are initialized to 0.5. Will act as a dislikeNodes and others
Put the individual nodes into a low set of trust values and all nodes send messages to each other to confirm the conversion to PBFT.
After the nodes are respectively classified into a high trust value group and a low trust value group according to the trust value, the PBFT consensus algorithm only runs among the nodes in the high trust value group; the nodes of the low trust value group only send data and do not participate in consensus. . The consensus mechanism does not switch to RAFT until the credit value of the node exceeds a threshold.
(4) PBFT consensus phase: the nodes in the high trust group mutually send 'main node election' information, and enter a main node election stage, the main node election method abandons a method of replacing the main node by view conversion in the traditional PBFT, and a safer self-adaptive main node selection method is adopted to select the main node.
After the master node is selected, the remaining nodes in the high set of trust values are slave nodes. The PBFT consensus starts running in the set of high trust values. All nodes mutually send verification message requests to achieve consensus; after all nodes perform a complete round of PBFT consensus, the block chain system updates the credit values of all nodes according to the trust model and reclassifies the nodes. Then, the main node is reselected from the new high trust group, and the node with good performance in the consensus can be replaced by the main node for consensus;
(5) Consensus switching state (from PBFT to Raft): after multiple rounds of PBFT consensus, nodes which are bad or have poor performance participate in consensus or are eliminated in the block chain system, and at the moment, a main node in the PBFT consensus triggers the consensus to be switched back to the Raft consensus. The self-adaptive main node selection algorithm ensures that the main node has high credit value in the PBFT consensus, namely, a node with good performance is ensured, so after the PBFT consensus algorithm is switched back, the main node can be directly used as the main node in the Raft consensus algorithm, the other nodes are slave nodes, and the Raft consensus algorithm is continuously operated.
Claims (3)
1. A trust model-based adaptive switching efficient fault-tolerant consensus method is characterized by comprising the following steps:
step (1) the client initiates a transaction request to the blockchain system<REQUEST,TX,σc>Giving the master node, and running a Raft consensus algorithm in the blockchain system at the moment, wherein TX is a transaction requested to be executed by the client, sigmacSigning the client;
after receiving the transaction request, the master node firstly sends a message for adding a new log entry to all slave nodes, and each slave node feeds back a message of successful replication to the master node after receiving the message and successfully replicating;
step (3) the master node collects and counts feedback information, and when more than half of slave nodes successfully copy the feedback information of the log entries, namely the consensus is successful, the Raft consensus algorithm is continuously operated in the block chain system; if the feedback information does not reach half, entering a consistency check stage;
step (4) entering a consistency check stage, sending verification messages to all nodes to check whether the latest logs of each node are the same or not, and if yes, continuing to run a Raft consensus algorithm; if the two nodes are not consistent, the main node sends a consensus switching notification to all the nodes, the block chain system enters a self-adaptive consensus switching stage based on a trust model, and the block chain system is switched from a Raft consensus algorithm to a PBFT consensus algorithm;
step (5) entering a self-adaptive consensus switching stage based on a trust model, and classifying all nodes by the system according to the trust model: the nodes are respectively classified into a high trust value group and a low trust value group according to the trust value, and the PBFT consensus algorithm only runs among the nodes in the high trust value group; the nodes of the low trust value group only send data and do not participate in consensus;
after the node grouping in the step (6) is completed, the nodes in the high trust group mutually send 'main node election' information, enter a main node election stage, and adopt a self-adaptive main node selection method to select the main node;
after the master node is selected, the rest nodes in the high trust value group are slave nodes; at this moment, the consensus algorithm in the block chain system is switched from the Raft consensus algorithm to the PBFT consensus algorithm; all nodes send verification message requests to achieve consensus; after all nodes are subjected to a round of complete PBFT consensus, the block chain system updates the credit values of all nodes according to the trust model and reclassifies the nodes; then, the step (6) is executed in the new high-trust group to reselect the main node, so that the node with good performance in the consensus can be replaced by the main node for consensus;
after multiple rounds of PBFT consensus, taking a malicious node or a node with poor performance into the block chain system, wherein the non-main node participates in the consensus or is removed, and the main node in the PBFT consensus triggers the consensus to be switched back to the Raft consensus; the self-adaptive main node selection algorithm ensures that the main node has high credit value in the PBFT consensus, namely, a node with good performance is obtained, so after the PBFT consensus algorithm is switched back, the main node can be directly used as the main node in the Raft consensus algorithm, the rest nodes are slave nodes, and the Raft consensus algorithm is continuously operated.
2. The efficient fault-tolerant consensus method based on adaptive handover of trust model according to claim 1, wherein the step (5) is implemented as follows:
(1) The trust model is as follows:
consensus behavioral trust Tcons: according to the behavior and the performance of each round of the node in the consensus process, the node is subjected to trust evaluation at the end of each round, and the node is divided into three states: benign status, downtime status, and doing malicious status;
the benign state refers to a round of consensus, if node i is the master node: the node i generates a valid block and can correctly reach the agreement; if node i is a slave node: node i broadcasts the same message and keeps consistent with most nodes;
the downtime state refers to that in one round of consensus, if a node i is a main node: the node i does not generate a new block; if node i is a slave node: node i cannot broadcast the message due to crash;
the malicious state means that if the node i is the master node in a round of consensus: the node i generates an invalid block in the round of consensus; if node i is a slave node: the information broadcast by the node i is different from each other, or the information broadcast by the node i is different from most nodes;
the consensus behavior trust of the node i in the t-th round is calculated as follows:
if the node i is the master node:
if node i is a slave node:
wherein xpAnd xbRepresenting the speed of the master and slave node respectively at which the trust values decrease, 0<xp<xb<1；ypAnd ybRepresenting the rate of rise of the trust values of the master node and the slave node, 0<yb<yp<0.03。
3. The efficient fault-tolerant consensus method for adaptive handover based on trust model according to claim 1 or 2, wherein in the step (6), the adaptive master node is selected according to the following steps:
the probability of the benign node i being selected as the master node in round t consensus is calculated by the following formula:
where N is the number of consensus nodes and α >1 is a probability factor, calculated by the following formula:
wherein
And
average credit values of the t-th round consensus and the t-1 th round consensus node are respectively obtained;
to ensure unpredictability of the master node election process, a distribution in the interval [0,1 ] is generated]The random number RNum above; generating by hashing the block header of the latest block through SHA256 algorithm
If the node i is selected as a new consensus master node, the following conditions need to be satisfied:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210650990.8A CN115276999B (en) | 2022-06-10 | 2022-06-10 | Self-adaptive switching efficient fault-tolerant consensus method based on trust model |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210650990.8A CN115276999B (en) | 2022-06-10 | 2022-06-10 | Self-adaptive switching efficient fault-tolerant consensus method based on trust model |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115276999A true CN115276999A (en) | 2022-11-01 |
| CN115276999B CN115276999B (en) | 2024-03-22 |
Family
ID=83760505
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210650990.8A Active CN115276999B (en) | 2022-06-10 | 2022-06-10 | Self-adaptive switching efficient fault-tolerant consensus method based on trust model |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115276999B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116015674A (en) * | 2022-12-16 | 2023-04-25 | 西安电子科技大学 | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106789095A (en) * | 2017-03-30 | 2017-05-31 | 腾讯科技（深圳）有限公司 | Distributed system and message treatment method |
| CN109993004A (en) * | 2019-04-10 | 2019-07-09 | 广州蚁比特区块链科技有限公司 | Block chain autonomy method and system based on credit mechanism |
| CN110365695A (en) * | 2019-07-24 | 2019-10-22 | 中国工商银行股份有限公司 | The block chain data interactive method and device of changeable common recognition algorithm |
| CN110677485A (en) * | 2019-09-30 | 2020-01-10 | 大连理工大学 | Dynamic layered Byzantine fault-tolerant consensus method based on credit |
| CN113222690A (en) * | 2021-04-27 | 2021-08-06 | 铭数科技(青岛)有限公司 | Block chain consensus method applied to regional energy Internet |
| CN113343311A (en) * | 2021-06-04 | 2021-09-03 | 北京邮电大学 | Block chain consensus method and system based on reputation model and digital signature mechanism |
-
2022
- 2022-06-10 CN CN202210650990.8A patent/CN115276999B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106789095A (en) * | 2017-03-30 | 2017-05-31 | 腾讯科技（深圳）有限公司 | Distributed system and message treatment method |
| CN109993004A (en) * | 2019-04-10 | 2019-07-09 | 广州蚁比特区块链科技有限公司 | Block chain autonomy method and system based on credit mechanism |
| CN110365695A (en) * | 2019-07-24 | 2019-10-22 | 中国工商银行股份有限公司 | The block chain data interactive method and device of changeable common recognition algorithm |
| CN110677485A (en) * | 2019-09-30 | 2020-01-10 | 大连理工大学 | Dynamic layered Byzantine fault-tolerant consensus method based on credit |
| CN113222690A (en) * | 2021-04-27 | 2021-08-06 | 铭数科技(青岛)有限公司 | Block chain consensus method applied to regional energy Internet |
| CN113343311A (en) * | 2021-06-04 | 2021-09-03 | 北京邮电大学 | Block chain consensus method and system based on reputation model and digital signature mechanism |
Non-Patent Citations (2)
| Title |
|---|
| JINTIAN FU等: "BCT: An Efficient and Fault Tolerance Blockchain Consensus Transform Mechanism for IoT", 《IEEE INTERNET OF THINGS JOURNAL》, vol. 10, no. 14, 28 October 2021 (2021-10-28), XP011944548, DOI: 10.1109/JIOT.2021.3123626 * |
| 刘克猛: "面向区块链的实用拜占庭容错算法优化研究", 《中国优秀硕士学位论文 信息科技辑》, vol. 2022, no. 01, 15 January 2022 (2022-01-15) * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116015674A (en) * | 2022-12-16 | 2023-04-25 | 西安电子科技大学 | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115276999B (en) | 2024-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110784346B (en) | Reputation value-based PBFT consensus system and method | |
| CN112532581A (en) | Improved PBFT consensus method based on consensus participation and transaction activity | |
| CN111355810A (en) | Improved PBFT consensus method based on credit and voting mechanism | |
| CN112217683B (en) | Cross-heterogeneous chain data reachability processing method, system, medium, equipment and terminal | |
| CN113570357B (en) | Dynamic layered efficient PBFT algorithm | |
| CN115665170B (en) | Block chain consensus method based on reputation and node compression mechanism | |
| CN114218612B (en) | Consensus method suitable for alliance chain high-frequency transaction scene | |
| Jalalzai et al. | Window based BFT blockchain consensus | |
| CN111414420B (en) | Improved PBFT block chain consensus method | |
| CN114048517A (en) | Dual channel consensus system and method for blockchains, computer readable storage medium | |
| CN116094721A (en) | Clustering-based extensible shard consensus algorithm | |
| CN115276999A (en) | Self-adaptive switching efficient fault-tolerant consensus method based on trust model | |
| CN117527834A (en) | Improved PBFT consensus method based on reputation scoring mechanism | |
| CN114760135B (en) | Optimization method of block chain fault-tolerant consensus scheme | |
| CN113781218A (en) | Grouping PBFT consensus algorithm based on feature trust | |
| He et al. | An improvement of consensus fault tolerant algorithm applied to alliance chain | |
| CN116633942A (en) | Bayesian-busy fault tolerance consensus method for high-speed response client | |
| CN117176736A (en) | Block transmission method based on neighbor node clustering | |
| Zhou et al. | Vg-raft: An improved byzantine fault tolerant algorithm based on raft algorithm | |
| CN116170155A (en) | PBFT (physical bit stream) improvement-based alliance block chain consensus method | |
| CN115378788B (en) | Block chain performance self-adaptive optimization method based on hierarchical consensus and reinforcement learning | |
| Tang et al. | Excellent practical byzantine fault tolerance | |
| CN114499874B (en) | Bayesian-busy-family fault-tolerant consensus optimization method applied to industrial Internet | |
| CN113901144B (en) | Query method, device and storage medium under non-whole network consensus block chain | |
| CN116389040A (en) | Reputation-based blockchain consensus method, device and computer equipment |
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 |