CN108492103B - Joint block chain consensus method - Google Patents
Joint block chain consensus method Download PDFInfo
- Publication number
- CN108492103B CN108492103B CN201810122889.9A CN201810122889A CN108492103B CN 108492103 B CN108492103 B CN 108492103B CN 201810122889 A CN201810122889 A CN 201810122889A CN 108492103 B CN108492103 B CN 108492103B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- transaction
- consensus
- new block
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Abstract
A union block chain consensus method is applied to a union block chain of a block chain, a node credit model is constructed according to the behavior of nodes in the consensus process on the basis of a classical PBFT algorithm, the trust value of the nodes is calculated, the trust value is used as the speaking right of the nodes in the consensus process and is fused into the consensus method, and finally the consensus method fused with the credit model is formed. In the process of consensus of the nodes, the speaking right of the nodes is distinguished, so that the requirements of real scenes are met, malicious nodes are identified and removed, the continuous reliability of the system is improved, and the consensus time delay is reduced.
Description
Technical Field
The invention relates to the technical field of information, in particular to a block chain consensus method of a block chain alliance.
Background
With the development of information technology, the block chain technology has become a technology of great interest due to its advantages such as openness, non-tamper property, and decentralization. The blockchain technique is a completely new distributed infrastructure and distributed computing paradigm that utilizes blockchain data structures to verify and store data, utilizes distributed consensus algorithms to generate and update data, cryptographically secures data transmission and access, and utilizes intelligent contracts composed of automated script code to program and manipulate data. Blockchains can be classified into "public chains", "private chains", and "federation chains" according to access and management rights. On the public chain, all people can access and acquire data. Private chains are operated by individuals or independent companies, and no outside world is expected to participate in the chain. The alliance chain is only opened for alliance members and only participated in by the alliance members, and the read-write authority and the authority of participants on the alliance block chain are set according to alliance rules.
In a blockchain system, each node holds one ledger. Due to network delay, the sequence of messages arriving at each node is different, so a consensus mechanism is designed to achieve consistency and correctness of data on different accounts. This requires the use of existing consistency algorithms in distributed systems, the determination of the mechanism for selecting accounting nodes in the network, and the guarantee of correct and consistent consensus of the ledger data in the whole network. The conventional distributed consistency algorithm is commonly provided with Paxos and Raft, but in a alliance chain, nodes in the system can be benefit pair cubes, and the nodes are completely motivated to try to do harm under the condition that the nodes are not beneficial to themselves, so that the consistency of the system is damaged. Therefore, the consensus algorithm of the federation chain must be tolerant of byzantine nodes, so non-byzantine fault-tolerant algorithms such as Paxos or Raft cannot be used.
The early block chain adopts a PoW (proof of work) mechanism highly dependent on the calculation power of the node to ensure the consistency of distributed accounting of the bitcoin network, the PoW mechanism lays a foundation for a consensus mechanism of the block chain, a random number meeting the requirement is calculated through Hash operation, namely the accounting right of this time is obtained, the PoW has the advantages of complete decentralization and free access of the node, but the PoW mechanism needs to consume a large amount of calculation power to cause a large amount of resource waste, the period of consensus is long, and final certainty is not realized. And then, a PoS (proof of stick) mechanism appears, and the ore excavation difficulty is proportionally reduced according to the proportion and time of the token occupied by each node, so that the speed of finding the random number is accelerated. The PoS mechanism reduces the time to reach consensus to some extent, but still requires mining, essentially without the problem of changing PoW.
At present, a consensus algorithm of a federation chain generally adopts a PBFT algorithm (Practical Byzantine failure Tolerance Practical Byzantine Fault-tolerant algorithm) and an improved algorithm thereof, and the PBFT algorithm has low energy consumption, high throughput and final certainty. The PBFT algorithm is the first widely used byzantine fault-tolerant algorithm, and in the PBFT algorithm, at most 1/3 byzantine nodes can be tolerated, which does not exceed the total number of nodes in the system, i.e., if there are normal nodes exceeding 2/3, the whole system can work normally.
Disclosure of Invention
Considering that the following problems generally exist when the current PBFT-like algorithm is applied to a block chain: in the consensus process, all nodes are completely equal, no distinction is made between reliability and reliability, the speaking rights of all nodes are not different, and the nodes do not accord with a real scene; the wrong node can not be found and removed by other nodes in the consensus phase. The application provides a federation block chain consensus method, which solves the problems in the prior art, introduces a credit model in the PBFT consensus process, constructs the credit model according to the credit values of the nodes reflected by the past behaviors of the nodes by the credit model, and the information can help to evaluate the credibility of the nodes. The consensus method is a method for constructing a credit model by calculating node credibility according to node historical voting behaviors by adopting a block chain of a union, and provides a consensus method for fusing the credit model based on a PBFT algorithm.
According to a first aspect, an embodiment provides an federated blockchain consensus method, including:
when a transaction occurs in the federation blockchain network that is signed and initiated by a node private key and broadcast to the entire network, in response to the transaction: if the copy node receives the transaction, performing flooding forwarding; if the main node receives the transaction, the validity of the transaction is verified, and if the transaction is illegal, the transaction is discarded; if the transaction is legal, recording the transaction into a transaction field of a block data structure of the transaction, constructing a new block, and broadcasting a pre-preparation message and the new block to other nodes;
after any node receives the new block, checking the authenticity of the new block, if true, sending voting information for preparing a confirmation message to other nodes, and if false, sending voting information for preparing a rejection message to other nodes; collecting and storing voting information from other nodes;
for any node in the alliance blockchain network, counting the number of nodes of which the node receives the preparation confirmation message and the speaking right of the nodes, and when the preparation confirmation message of more than a first number of nodes is received and the speaking right of the nodes is more than a first value, sending a submission confirmation message and the collected and stored voting information from other nodes to other nodes;
for any node in the alliance block chain network, counting the number of submitted confirmation messages of the node and the speaking rights of the nodes received by the node, writing the new block into a block chain of the node when the submitted confirmation messages of the nodes with the number larger than the second number are received and the speaking rights of the nodes are larger than a second value, and broadcasting the new block in the alliance block chain network to finish the consensus of the theory;
each node also receives the collected and stored voting information sent by other nodes, and before beginning the consensus, each node calculates and updates the speaking right of other nodes according to the received collected and stored voting information sent by other nodes and the voting information collected and stored by the node.
Further, the master node verifies the validity of the transaction, including:
the main node judges whether the transaction conforms to a transaction writing composition rule, judges whether the transaction exists in a block chain of the main node, and judges whether a script of the transaction is executed correctly;
when the judgment result is that the transaction does not accord with the transaction writing composition rule, or the transaction exists in the block chain, or the script of the transaction is not executed correctly, the main node verifies that the transaction result is illegal, otherwise, the verification result is legal;
the node checks the authenticity of the received new block, including:
the node judges whether the received new block points to the latest block of the block chain of the node;
if the received new block does not point to the latest block of the block chain of the node, judging whether the new block already exists in the list of the block chain of the node, if so, checking that the new block is false, if not, writing the new block into the list of the block chain of the node, synchronizing, and judging whether the received new block points to the latest block of the block chain of the node again after synchronization is finished;
if the received new block is the latest block of the block chain pointing to the node, whether the transactions in the new block are all legal transactions is judged, if yes, the verification result is that the new block is true, otherwise, the verification result is that the new block is false.
Further, each node calculates and updates the speaking right of other nodes, including:
each node judges the states of the voting information of other nodes according to the received voting information collected and stored by other nodes and the voting information collected and stored by the node so as to calculate the credit values of other nodes; wherein the judging the states of the voting information of other nodes comprises: judging whether other nodes send different voting information to different nodes or not, and whether the voting information of other nodes is the same as the result of whether consensus is finally achieved or not; when the judging node sends different voting information to other nodes, setting the credit value of the node to be 0; otherwise, when the voting information sent by the judging node to other nodes is different from the result of whether the consensus is finally achieved, the credit value of the node is reduced, and when the voting information sent by the judging node to other nodes is the same as the result of whether the consensus is finally achieved, the credit value of the node is improved.
Based on the reputation value of the node, the utterance right of the node is calculated.
And further, each node identifies whether other nodes are wrong nodes according to the received collected and stored voting information sent by other nodes and the received voting information collected and stored by the node, and identifies the node as a wrong node when judging that one node sends different voting information to other nodes or judging that the collected and stored voting information sent by one node to other nodes is modified information, and the node is removed from the block chain network of the alliance.
According to a second aspect, an embodiment provides a computer-readable storage medium comprising a program executable by a processor to implement the method according to the first aspect described above.
According to the federation block chain consensus method of the embodiment, because the voting information of the nodes on the historical blocks is analyzed, the reliability of the nodes is calculated, and the reliability of the nodes is combined with the reliability of the nodes, the speaking rights of different nodes in the consensus process are distinguished, so that the speaking rights accord with the requirements of a real scene, malicious nodes can be found and removed according to the credit values of the nodes, and the efficiency and the continuous reliability of the consensus method are improved.
Drawings
FIG. 1 is a flow diagram of a typical PBFT normal execution;
FIG. 2 is a flow diagram of a federation blockchain consensus method of an embodiment;
FIG. 3 is a flow diagram of a federation blockchain consensus method of another embodiment;
FIG. 4 is a diagram of computing node reputations in one embodiment;
FIG. 5 is a diagram illustrating the speaking rights of a compute node in one embodiment.
Detailed Description
The present invention will be described in further detail with reference to the following detailed description and accompanying drawings. Wherein like elements in different embodiments are numbered with like associated elements. In the following description, numerous details are set forth in order to provide a better understanding of the present application. However, those skilled in the art will readily recognize that some of the features may be omitted or replaced with other elements, materials, methods in different instances. In some instances, certain operations related to the present application have not been shown or described in detail in order to avoid obscuring the core of the present application from excessive description, and it is not necessary for those skilled in the art to describe these operations in detail, so that they may be fully understood from the description in the specification and the general knowledge in the art.
Furthermore, the features, operations, or characteristics described in the specification may be combined in any suitable manner to form various embodiments. Also, the various steps or actions in the method descriptions may be transposed or transposed in order, as will be apparent to one of ordinary skill in the art. Thus, the various sequences in the specification and drawings are for the purpose of describing certain embodiments only and are not intended to imply a required sequence unless otherwise indicated where such sequence must be followed.
The numbering of the components as such, e.g., "first", "second", etc., is used herein only to distinguish the objects as described, and does not have any sequential or technical meaning. The term "connected" and "coupled" when used in this application, unless otherwise indicated, includes both direct and indirect connections (couplings).
Please refer to fig. 1, which is a flow chart of the normal execution of the classical PBFT; the PBFT employs a three-phase protocol to broadcast requests to replicas: pre-prepare, commit.
The pre-prepare and prepare phases are used to send requests sent in the same view to determine the sequence, i.e., the order, which is recognized by each replenics node and executed in accordance with the sequence, although there may be bytation node malicious operations, which we will next give an example of this, and how the three-phase protocol handles this. Suppose we now have a distributed network of four nodes, as shown in figure 1. It is clear in advance that in this network:
1. it is possible that the four nodes are lambkin nodes or correct nodes and legal nodes;
2. the main node is a bad node or an error node, and the other three backup nodes are lambkin nodes;
3. the main node is a lambkin node, one of the three backup nodes is a bad node, and the rest nodes are lambkin nodes;
no matter which of the three situations occurs, the three-stage protocol can ensure the healthy and legal operation of the distributed network. The bad nodes can not be taken advantage of, thereby avoiding the occurrence of damage.
The prepare phase and the commit phase are used to ensure that the requests that have reached the commit state remain unchanged in the new view even after the view change occurs, for example, in view 0, three requests including the master node, the replica node and the replica node 2 enter the commit phase in sequence, and if there is no bad node, the four replicas are about to execute three requests in sequence and return the requests to the Client. However, at this time, the master node problem causes the occurrence of view change, the master node becomes the slave node 1, and in a new view, the original sequences of three requests, namely the master node, the slave node 1 and the slave node 2, are reserved and counted. Those requests that are in the pre-prepare and prepare phases will be discarded and not counted in the new view after the view change occurs.
In the PRE-PREPARE phase, the primary node receives a request from the Client and assigns a number to the request, and then broadcasts a PRE-PREPARE message to the backup node, wherein the PRE-PREPARE message comprises the number of the request, the view in which the request is located and a digest of the PRE-PREPARE message. Until the information reaches each backup node, next, the backup nodes receiving the information do not agree with the number n allocated to the request by the primary node, that is, whether the accept is the PRE-PREPARE information, and if a backup node accepts the PRE-PREPARE, the backup node enters the following PREPARE phase.
In the PREPARE phase, after a backup node enters the PREPARE phase of the backup node, a piece of PREPARE information is broadcasted to the main node and the other two backup nodes until the PREPARE information reaches the three nodes. Meanwhile, the backup node also receives PREPARE information from the other two backup nodes respectively. When the backup node starts to comprehensively compare the PREPARE information from the other two backup nodes with the PREPARE information of the backup node, if the backup node finds that the other two nodes both agree with the number assigned by the master node and, looking at the backup node, also agree with the assignment of the master node, we say that the state of the request on the replica is prepended, and the replica has a certificate called prepended certificate. Then replica 1 considers that the number of attempts is not enough for all network approval, so in the new view, the number n of the request m will be invalidated, and the proposal needs to be reinitiated. The following commit stage is available.
The COMMIT stage, which follows the prepare stage, when a replica node finds a quorum grant number assignment, it broadcasts a COMMIT message to all other nodes telling them that it has a prepared certificate. At the same time it will receive the COMMIT information from other nodes, and if it receives 2f +1 COMMIT (including one itself, the COMMIT from different nodes carry the same number n and view v), we say that this node has a certificate called committed certificate, requesting that the committed state is reached at this node. At this point, we can conclude that the request has reached the prepended state in a quorum by just this node, i.e., that the nodes of a quorum have agreed to the assignment of number n. When the request m reaches the committed state, the request is executed by the node.
In the embodiment of the invention, a union block chain consensus method is provided, wherein the trust value of a node is calculated by using node voting information; considering differences among the nodes of the block chain, and the credibility and reliability among the nodes are different, and using the node trust value as the speaking right of the node when voting in the consensus process; meanwhile, in the process of identifying the new block, the speaking right support obtained by the block is considered, and the node number support obtained by the block chain is also considered.
The first embodiment is as follows:
in the existing blockchain technology, data in a blockchain is commonly maintained by each blockchain node (hereinafter referred to as a node) in the blockchain network. When a node receives a service request, it generally needs to go through three links, namely caching, consensus and storage, to store service data corresponding to the service request into a block, and uplink the block to a block chain corresponding to the node. When a plurality of nodes in the blockchain network store the service data in the blockchain data of the respective node, the service data can be regarded as being stored in the blockchain data commonly maintained by the nodes.
Consensus is an indispensable link, and various mechanisms adopted at present include a workload certification (POW) mechanism, a byzantine fault tolerance (PBFT) mechanism, a rights and interests certification and the like. The workload proving mechanism is explained here as an example.
Specifically, first, a node may receive a service request sent by a user, where the service request includes service data, where the service request may be directly input to the node by the user, or may receive a service request broadcast by another node in a block chain network. How the node receives the service request in particular does not have an impact on the execution of the service.
Then, the node may determine corresponding service data according to the service request. The process of determining the corresponding service data by the node according to the service request may be referred to as that the node accepts the service request, and how to determine the service data may be different according to different specific situations. The service data carried in the service request already contains the content that the service needs to execute. For example, for a transaction service request, the transaction service request carries information such as a payer address, a payer balance, a payment amount, a payee address, and the like, and a node receiving the service request may directly determine the service data according to the service request. For another example, the service request may also include service data such as an instruction for the intelligent contract. Thus, when the node accepts the service request, it may need to perform service processing according to the service data according to the difference of the service data in the service request, and obtain the result of the service processing. Of course, the node may also use the service data carried in the service request and the result of performing the service processing as the service data corresponding to the service request. The specific content of the service data may be different according to the configuration of the blockchain, and as long as the data corresponding to the service request needs to be stored in the blockchain data, the data may be regarded as the service data.
The nodes in the blockchain network may be divided into an accepting node and a non-accepting node for a service request, where the accepting node is a node that receives the service request sent by a user or other device, and the non-accepting node is a node that obtains the service request from another node by a broadcast method.
When the determined service data is not stored in the block chain data which has been subjected to consensus, the service data is the service data to be consensus and can be stored in the cache of the node.
Then, after the node determines the service data to be identified, the node may broadcast the service data to be identified to other nodes in the blockchain network, that is, synchronize to other nodes in the blockchain network. In this way, each node in the blockchain network can receive the service data to be identified sent by broadcasting. When performing subsequent consensus, each node in the block chain network may perform consensus on the service data to be consensus.
Finally, each node in the block chain network may determine a node initiating consensus according to the consensus mechanism of the block chain, and the node initiating consensus selects service data for consensus from the service data to be consensus stored in the node. And each node in the blockchain network can perform consensus on the service data for consensus selected by the node initiating consensus according to the consensus mechanism of the blockchain.
When performing consensus on each to-be-consensus service data sent by the node initiating consensus, each node in the blockchain network can judge whether each received to-be-consensus service data is also stored in the to-be-consensus list in the node cache, if so, determine that each received to-be-consensus service consensus passes, store a new block recording each to-be-consensus service data in blockchain data maintained by the node, and if not, store the new block not.
Referring to fig. 2 and 3, an embodiment of the present invention provides an affiliate block chain consensus method, which may include steps S101 to S109, which are described in detail below.
Step S101: when a transaction occurs in the federation blockchain network that is signed and initiated by a node private key and broadcast to the entire network, in response to the transaction: if the copy node receives the transaction, performing flooding forwarding; if the main node receives the transaction, the validity of the transaction is verified, and if the transaction is illegal, the transaction is discarded; if it is legal, the transaction is recorded in the transaction field of its block data structure, a new block is constructed, and a prepare message is broadcast to other nodes together with the new block. In one embodiment, the master node constructs a new block and sends the new block to other nodes, including: the master node constructs and transmits a new block within a preset time, wherein the new block is written into the received transaction by the master node.
One of the systems is used as a transaction initiator to initiate a transaction, and the private key is used for signing to confirm the identity of the transaction initiator.
Since the consensus nodes in the blockchain network are divided into the main node and the replica node, the number of the main node is determined by the following formula:
p＝(c+h)％N
wherein c is the view number, h is the current block height, and N is the number of the common node.
In one embodiment, the master node verifies the validity of the transaction, comprising:
the main node judges whether the transaction conforms to a transaction writing composition rule, judges whether the transaction exists in a block chain of the main node, and judges whether a script of the transaction is executed correctly;
and when the judgment result is that the transaction does not accord with the transaction writing composition rule, or the transaction exists in the block chain, or the script of the transaction is not correctly executed, the main node verifies that the transaction result is illegal, otherwise, the verification result is legal.
Step S103: after any node receives the new block, checking the authenticity of the new block, if true, sending voting information for preparing a confirmation message to other nodes, and if false, sending voting information for preparing a rejection message to other nodes; and collecting and storing voting information from other nodes, for example using a bitmap.
In one embodiment, the node checks the authenticity of the received new chunk, comprising:
the node judges whether the received new block points to the latest block of the block chain of the node;
if the received new block does not point to the latest block of the block chain of the node, judging whether the new block already exists in the list of the block chain of the node, if so, checking that the new block is false, if not, writing the new block into the list of the block chain of the node, synchronizing, and judging whether the received new block points to the latest block of the block chain of the node again after synchronization is finished;
if the received new block is the latest block of the block chain pointing to the node, whether the transactions in the new block are all legal transactions is judged, if yes, the verification result is that the new block is true, otherwise, the verification result is that the new block is false.
In one embodiment, the method for league blockchain consensus of the present invention further comprises the steps of: after any node receives the new block, the node also doubts whether the main node sending the new block is an error node, and when the node doubts the error node, the node initiates and broadcasts or broadcasts a view change message by a randomly selected node; when other nodes receive the view change message, the other nodes broadcast a confirmation message; the step of determining whether the master node that is suspected of sending the new block is a wrong node comprises: when the transaction contained in the new block sent by the main node is judged to be a false transaction or the main node does not send the new block within the preset time, the main node is suspected to be an error node; any node, which counts how many nodes the node receives the confirmation message and the speaking right of the nodes, when receiving the confirmation message of more than the third number of nodes and the speaking right of the nodes is more than the third value, the node changes to the new view, for example, when receiving the confirmation message of more than 1/2 common identification nodes and the speaking right of the nodes is more than 2/3 total speaking right, the node changes to the new view.
Step S105: for any node in the alliance blockchain network, counting the number of nodes of which the node receives the preparation confirmation message and the speaking right of the nodes, and when the preparation confirmation message of more than a first number of nodes is received and the speaking right of the nodes is more than a first value, sending a submission confirmation message and the collected and stored voting information from other nodes to other nodes; for example, when a preparation confirmation message is received for a number of consensus nodes greater than 1/2 for the full network and the speaking right of these nodes is greater than the speaking right of the full network 2/3, then a commit confirmation message is sent to the other nodes along with the voting information from the other nodes it collected and stored at step S103.
Step S107: for any node in the federation blockchain network, the node counts how many nodes receive the submission confirmation messages and the speaking rights of the nodes, and when the submission confirmation messages of more than a second number of nodes are received and the speaking rights of the nodes are more than a second value, for example, when the submission confirmation messages of more than 1/2 total-number consensus nodes are received and the speaking rights of the nodes are more than 2/3 total-the new block is written into the blockchain of the node, and the new block is broadcasted in the federation blockchain network to complete the consensus.
Step S109: each node also receives the collected and stored voting information sent by other nodes, and before beginning the consensus, each node calculates and updates the speaking right of other nodes according to the received collected and stored voting information sent by other nodes and the voting information collected and stored by the node.
In one embodiment, each node calculates and updates the speaking right of other nodes, including: each node judges the states of the voting information of other nodes according to the received voting information collected and stored by other nodes and the voting information collected and stored by the node so as to calculate the credit values of other nodes; wherein the judging the states of the voting information of other nodes comprises: judging whether other nodes send different voting information to different nodes or not, and whether the voting information of other nodes is the same as the result of whether consensus is finally achieved or not; when the judging node sends different voting information to other nodes, setting the credit value of the node to be 0; otherwise, when the voting information sent by the judging node to other nodes is different from the result of whether the consensus is finally achieved, the credit value of the node is reduced, and when the voting information sent by the judging node to other nodes is the same as the result of whether the consensus is finally achieved, the credit value of the node is improved. The utterance weights for the nodes are then calculated based on the reputation values of the nodes.
In one embodiment, computing the reputation value of a node comprises the following:
wherein R isi(t) represents the credit value of the node with the number i after t times of consensus, x is more than 0 and less than 1, y is more than 0 and less than 0.05, and Ri(0) Is a predetermined value, for example, 0.6. For example, if the voting message is a preparation confirmation message in the consensus process of the present invention and the final result is consensus achieved, the voting message is the same as the final result, and if the final result is no consensus achieved, the voting message is different from the final result; similarly, in the consensus process of the present invention, the voting message of a certain node is a prepare rejection message, and the final result is consensus achieved, the voting message is different from the final result, and if the final result is no consensus achieved, the voting message is the same as the final result. It can be seen that the initial values of the reputation values of all nodes can be set to 0.6, and when the voting message of a node is lost or is different from the final result, the reputation value of the node will be reduced; if the nodes send different messages to different nodes, the credit value of the nodes is directly 0 and the network is removed. When the voting information of the nodes is the same as the final result, the credit score of the nodes is slowly increased, when y is larger, the credit score of the nodes is increased quickly, and when y is smaller, the credit score of the nodes is increased slowly.
In one embodiment, when the node reputation value is less than a preset reputation threshold value, for example, 0.5, it is determined as a wrong node and the federation blockchain network is rejected.
The reputation value of a node can be calculated by the above formula, and then calculating the speaking right of the node can include the following ways:
wherein R isi(t) represents the reputation value of the node numbered i after t consensus, Di(t) the speaking right of the node with the number i in the t round is represented, and P (i) the reliability of the node with the number i is represented and is a preset value; a is a value of size 1, b is a value smaller than 1 and greater than 0, and p (i) represents the reliability of the node itself, numbered i.
Therefore, in an embodiment, each node may further identify whether another node is an error node according to the received collected and stored voting information sent by another node and the voting information collected and stored by the node, and when it is determined that one node sends different voting information to another node or it is determined that the collected and stored voting information sent by one node to another node is modified information, the node is identified as an error node, and the node is removed from the block chain network. This will be explained in detail below.
The above-described models of reputation values and speaking rights require a mechanism for identifying the wrong node, which is a more complex process because the wrong node may lie from time to time and may appear normal for a long period of time until it decides to start an attack. In addition, the error node may send out inconsistent information at any stage in the consensus process, or may generate inconsistent behavior at only one stage.
The PBFT algorithm has three phases and the identification of the wrong node only occurs in the third phase. There may be two types of spoofing for a wrong node: (1) in the second stage, different voting information is sent to different nodes, and the cheating mode may cause that consensus cannot be achieved; (2) in the third phase, modified content is sent, and this deception could result in the correct node being mistaken for the wrong node. Therefore, a faulty node may have four manifestations, with or without selective spoofing in the second and third phases, respectively.
| Scene | 1 | 2 | 3 | 4 |
| Stage two | Is normal | Is normal | Spoofing | Spoofing |
| Stage three | Is normal | Spoofing | Is normal | Spoofing |
Therefore, in one consensus process, the following three cases need to be considered:
(1) the error node is only deceived in the second stage, and no node is deceived in the third stage. In this case, the error node sends different voting information to different nodes in the second phase, but all nodes (including the error node) send the correct voting information in the third phase, i.e. case three in the table above. In this case, the cheating behavior of the node can be easily discovered, because the voting information of each node received in the third stage is correct, and the cheating wrong node can be found out only according to the voting information of each node obtained in the third stage.
(2) The wrong node is not spoofed in the second phase, but spoofing occurs in the third phase. In this case, the voting information of the error node in the second phase is consistent, but the error node issues the collected voting information modified in the third phase, i.e. case two in the table above. In this case, the cheating behavior of the node can be easily discovered, because the voting information of one node has its own private key signature, and when other nodes receive the message, the voting information of the node can be verified through the public key of the node. Therefore, the node performing the fraud in the third stage can be discovered quickly.
(3) The error node has error behavior in both the second phase and the third phase, i.e., case four in the table above. As long as there are correct nodes in the network that are working beyond 2/3 speaking rights, these nodes can agree on phase two and phase three. Since the node performing fraud in the third stage can be discovered by means of public key verification, information of all nodes performing fraud in the third stage is removed, and at this time, a wrong node performing fraud in the second stage can be found out by means of the first case.
If deception occurs, the node is judged to be a wrong node, and if the deception occurs, the node is also judged to be a wrong node, so that the wrong node can be removed from the network, and the reputation value of each node is calculated and updated according to the formula.
The speaking right of the node is jointly determined by the reputation value of the node and the last round of consensus and the reliability of the node, and the calculation of the speaking right is also completed in the step.
By Di(t) the speaking right of the node with the number i in the t round, P (i) the reliability of the node, Di(1) P (i), then:
the higher the reputation value of a node is, the higher the speaking right thereof is correspondingly; the stronger the reliability of the node itself, the higher the speaking right; and, if a node works correctly in the previous round of consensus process, the next round of consensus is more likely to work correctly, so the speaking right rises accordingly.
Therefore, in the consensus method fusing the reputation models, the speaking right between the nodes is distinguished, and the speaking right of the nodes in the consensus process can be calculated according to the reliability of the nodes and the behaviors of the nodes in the prior consensus process. Meanwhile, the method provided by the invention can find and remove the wrong node and enhance the continuous stability of the system.
In summary, the application provides a consensus method for fusing reputation models in a federation block chain, which calculates the credibility of nodes according to the voting behavior of the nodes in the consensus process, and gives the speaking right of the nodes in the consensus process by combining the reliability of the nodes. The method meets the requirements of a real scene, improves the success rate of consensus and reduces the time delay of consensus.
Those skilled in the art will appreciate that all or part of the steps of the various methods in the above embodiments may be performed by a program stored in a server in the federation blockchain for accounting consensus and applied to the corresponding blockchain service.
Those skilled in the art will appreciate that all or part of the functions of the various methods in the above embodiments may be implemented by hardware, or may be implemented by computer programs. When all or part of the functions of the above embodiments are implemented by a computer program, the program may be stored in a computer-readable storage medium, and the storage medium may include: a read only memory, a random access memory, a magnetic disk, an optical disk, a hard disk, etc., and the program is executed by a computer to realize the above functions. For example, the program may be stored in a memory of the device, and when the program in the memory is executed by the processor, all or part of the functions described above may be implemented. In addition, when all or part of the functions in the above embodiments are implemented by a computer program, the program may be stored in a storage medium such as a server, another computer, a magnetic disk, an optical disk, a flash disk, or a removable hard disk, and may be downloaded or copied to a memory of a local device, or may be version-updated in a system of the local device, and when the program in the memory is executed by a processor, all or part of the functions in the above embodiments may be implemented.
The present invention has been described in terms of specific examples, which are provided to aid understanding of the invention and are not intended to be limiting. For a person skilled in the art to which the invention pertains, several simple deductions, modifications or substitutions may be made according to the idea of the invention.
Claims (10)
1. An alliance block chain consensus method is characterized by comprising the following steps:
when a transaction occurs in the federation blockchain network that is signed and initiated by a node private key and broadcast to the entire network, in response to the transaction: if the copy node receives the transaction, performing flooding forwarding; if the main node receives the transaction, the validity of the transaction is verified, and if the transaction is illegal, the transaction is discarded; if the transaction is legal, recording the transaction into a transaction field of a block data structure of the transaction, constructing a new block, and broadcasting a pre-preparation message and the new block to other nodes;
after any node receives the new block, checking the authenticity of the new block, if true, sending voting information for preparing a confirmation message to other nodes, and if false, sending voting information for preparing a rejection message to other nodes; collecting and storing voting information from other nodes;
for any node in the alliance blockchain network, counting the number of nodes of which the node receives the preparation confirmation message and the speaking right of the nodes, and when the preparation confirmation message of more than a first number of nodes is received and the speaking right of the nodes is more than a first value, sending a submission confirmation message and the collected and stored voting information from other nodes to other nodes;
for any node in the alliance block chain network, counting the number of submitted confirmation messages of the node and the speaking rights of the nodes received by the node, writing the new block into a block chain of the node when the submitted confirmation messages of the nodes with the number larger than the second number are received and the speaking rights of the nodes are larger than a second value, and broadcasting the new block in the alliance block chain network to finish the consensus of the theory;
each node also receives the collected and stored voting information sent by other nodes, and before beginning the consensus, each node calculates and updates the speaking right of other nodes according to the received collected and stored voting information sent by other nodes and the voting information collected and stored by the node.
2. The method of federation blockchain consensus of claim 1,
the master node verifies the validity of the transaction, including:
the main node judges whether the transaction conforms to a transaction writing composition rule, judges whether the transaction exists in a block chain of the main node, and judges whether a script of the transaction is executed correctly;
when the judgment result is that the transaction does not accord with the transaction writing composition rule, or the transaction exists in the block chain, or the script of the transaction is not executed correctly, the main node verifies that the transaction result is illegal, otherwise, the verification result is legal;
the node checks the authenticity of the received new block, including:
the node judges whether the received new block points to the latest block of the block chain of the node;
if the received new block does not point to the latest block of the block chain of the node, judging whether the new block already exists in the list of the block chain of the node, if so, checking that the new block is false, if not, writing the new block into the list of the block chain of the node, synchronizing, and judging whether the received new block points to the latest block of the block chain of the node again after synchronization is finished;
if the received new block is the latest block of the block chain pointing to the node, whether the transactions in the new block are all legal transactions is judged, if yes, the verification result is that the new block is true, otherwise, the verification result is that the new block is false.
3. A method for federation blockchain consensus as in claim 1, wherein a master node constructs a new block and sends the new block to other nodes, comprising: the master node constructs and transmits a new block within a preset time, wherein the new block is written into the received transaction by the master node.
4. The federated blockchain consensus method of claim 1, further comprising:
after receiving the new block, the any node also doubts whether a main node sending the new block is an error node, and when the node doubts the error node, the node initiates and broadcasts or broadcasts a view change message by a randomly selected node; when other nodes receive the view change message, the other nodes broadcast a confirmation message; the step of determining whether the master node that is suspected of sending the new block is a wrong node comprises: when the transaction contained in the new block sent by the main node is judged to be a false transaction or the main node does not send the new block within the preset time, the main node is suspected to be an error node;
and any node counts the confirmation messages of how many nodes are received by the node and the speaking rights of the nodes, and when the confirmation messages of more than a third number of nodes are received and the speaking rights of the nodes are more than a third value, the node is changed to a new view.
5. The method of claim 1, wherein each node calculates and updates the speaking rights of other nodes, comprising:
each node judges the states of the voting information of other nodes according to the received voting information collected and stored by other nodes and the voting information collected and stored by the node so as to calculate the credit values of other nodes; wherein the judging the states of the voting information of other nodes comprises: judging whether other nodes send different voting information to different nodes or not, and whether the voting information of other nodes is the same as the result of whether consensus is finally achieved or not; when the judging node sends different voting information to other nodes, setting the credit value of the node to be 0; otherwise, when the voting information sent by the judging node to other nodes is different from the result of whether the consensus is finally achieved, the credit value of the node is reduced, and when the voting information sent by the judging node to other nodes is the same as the result of whether the consensus is finally achieved, the credit value of the node is improved;
based on the reputation value of the node, the utterance right of the node is calculated.
6. The federation blockchain consensus method of claim 5, wherein calculating a reputation value for a node comprises:
wherein R isi(t) represents the credit value of the node with the number i after t times of consensus, x is more than 0 and less than 1, y is more than 0 and less than 0.05, and Ri(0) Is a predetermined value.
7. The method of claim 5 or 6, wherein when the node reputation value is smaller than a preset reputation threshold, it is determined as a wrong node and the federation blockchain network is rejected.
8. A federation blockchain consensus method as claimed in claim 5 or 6, wherein computing the speaking rights of a node comprises the following:
wherein R isi(t) represents the reputation value of the node numbered i after t consensus, Di(t) the speaking right of the node with the number i in the t round is represented, and P (i) the reliability of the node with the number i is represented and is a preset value; a is a value of size 1, b is a value smaller than 1 and greater than 0, and p (i) represents the reliability of the node itself, numbered i.
9. The method as claimed in claim 1, further comprising the step of each node identifying whether the other node is a wrong node according to the received collected and stored voting information sent by the other node and the voting information collected and stored by the node, and identifying the node as a wrong node when it is determined that a node sends different voting information to the other node or the collected and stored voting information sent by a node to the other node is modified, and the node is removed from the block chain network.
10. A computer-readable storage medium, characterized by comprising a program executable by a processor to implement the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810122889.9A CN108492103B (en) | 2018-02-07 | 2018-02-07 | Joint block chain consensus method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810122889.9A CN108492103B (en) | 2018-02-07 | 2018-02-07 | Joint block chain consensus method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108492103A CN108492103A (en) | 2018-09-04 |
| CN108492103B true CN108492103B (en) | 2021-04-27 |
Family
ID=63344644
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810122889.9A Active CN108492103B (en) | 2018-02-07 | 2018-02-07 | Joint block chain consensus method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108492103B (en) |
Families Citing this family (81)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108600161A (en) * | 2018-03-12 | 2018-09-28 | 成都零光量子科技有限公司 | A kind of fair efficient block chain common recognition method |
| CN110730959A (en) * | 2018-04-21 | 2020-01-24 | 因特比有限公司 | Method and system for performing actions requested by blockchain |
| CN109447795B (en) * | 2018-09-11 | 2021-06-04 | 中国人民解放军国防科技大学 | Byzantine consensus method supporting rapid achievement of final confirmation |
| CN109670930A (en) * | 2018-09-13 | 2019-04-23 | 深圳壹账通智能科技有限公司 | Rogue device recognition methods, device, equipment and computer readable storage medium |
| CN109309671A (en) * | 2018-09-14 | 2019-02-05 | 爱立信(中国)通信有限公司 | A kind of communications device data management method and device based on block chain |
| CN109274674B (en) * | 2018-09-27 | 2021-03-23 | 福建福链科技有限公司 | Block chain heterogeneous consensus method with high security and terminal |
| CN109697606A (en) * | 2018-09-30 | 2019-04-30 | 贝克链区块链技术有限公司 | The distributed network and the ecosystem of common recognition agreement are proved based on innovative prestige |
| CN109389502B (en) * | 2018-10-08 | 2019-12-06 | 莆田市烛火信息技术有限公司 | consensus method of block chains depending on related chain computing power |
| CN109509092A (en) * | 2018-10-16 | 2019-03-22 | 中国传媒大学 | Data trade motivational techniques and system based on alliance's chain |
| CN109359860A (en) * | 2018-10-16 | 2019-02-19 | 湘潭大学 | A kind of access method of the steel creation data based on intelligent contract |
| CN109586949B (en) * | 2018-10-17 | 2021-04-09 | 北京新唐思创教育科技有限公司 | Block generation method and computer storage medium |
| CN109413178B (en) * | 2018-10-21 | 2021-03-05 | 浙江数值跳跃网络科技有限公司 | Block chain data receiving and recording method and data receiving and recording system based on Internet of things |
| WO2020082213A1 (en) * | 2018-10-22 | 2020-04-30 | 深圳市哈希树科技有限公司 | Network expandability blockchain implementation method |
| CN109450996A (en) * | 2018-10-25 | 2019-03-08 | 国信优易数据有限公司 | A kind of data cochain management method, device, equipment and block catenary system |
| CN109377229B (en) * | 2018-11-23 | 2021-03-02 | 全链通有限公司 | Transaction consensus method, node and block chain system |
| WO2020113545A1 (en) * | 2018-12-07 | 2020-06-11 | 北京大学深圳研究生院 | Method for generating and managing multimodal identified network on the basis of consortium blockchain voting consensus algorithm |
| CN109767199B (en) * | 2018-12-10 | 2023-06-16 | 西安电子科技大学 | PBFT consensus system and method based on reputation and blockchain data processing system |
| CN109784916A (en) * | 2018-12-12 | 2019-05-21 | 广东工业大学 | A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain |
| CN109754163A (en) * | 2018-12-18 | 2019-05-14 | 上海众源网络有限公司 | A kind of content scores method, apparatus and electronic equipment |
| CN109727029A (en) * | 2018-12-18 | 2019-05-07 | 杭州茂财网络技术有限公司 | A kind of alliance's chain common recognition method and system |
| CN111478785B (en) * | 2019-01-24 | 2021-11-02 | 北京京东尚科信息技术有限公司 | Consensus method in block chain network, node and storage medium |
| CN109918261B (en) * | 2019-01-25 | 2022-11-22 | 中国联合网络通信集团有限公司 | Fault monitoring method, device, equipment and computer readable storage medium |
| CN109859047A (en) * | 2019-01-31 | 2019-06-07 | 北京瑞卓喜投科技发展有限公司 | A kind of block chain update method and block chain more new system |
| CN109886681B (en) * | 2019-01-31 | 2021-06-18 | 北京瑞卓喜投科技发展有限公司 | Block chain consensus method and system |
| CN111512332B (en) * | 2019-02-20 | 2022-12-09 | 北京大学深圳研究生院 | Topological construction method and system for meeting partition tolerance under alliance chain consensus |
| CN109995536A (en) * | 2019-03-15 | 2019-07-09 | 广州杰赛科技股份有限公司 | A kind of block chain common recognition method, apparatus and readable storage medium storing program for executing |
| CN109951474B (en) * | 2019-03-15 | 2021-07-30 | 杭州云象网络技术有限公司 | Method for realizing block chain common identification block |
| US10938750B2 (en) | 2019-03-18 | 2021-03-02 | Advanced New Technologies Co., Ltd. | Consensus system downtime recovery |
| KR102365793B1 (en) * | 2019-03-18 | 2022-02-21 | 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. | Consensus system downtime recovery |
| KR102230829B1 (en) | 2019-03-18 | 2021-03-23 | 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. | Consensus system downtime recovery |
| CN110086780B (en) * | 2019-03-26 | 2021-11-02 | 北京百度网讯科技有限公司 | Method and device for processing tampered transaction based on Ether house and storage medium |
| CN110034959A (en) * | 2019-04-04 | 2019-07-19 | 郑州师范学院 | Trusted node measure in a kind of block chain ballot scene |
| CN109885264B (en) * | 2019-04-16 | 2019-12-06 | 北京艾摩瑞策科技有限公司 | Logic slicing method and system for block chain link points |
| CN110049051B (en) * | 2019-04-22 | 2020-08-11 | 成都四方伟业软件股份有限公司 | Request verification method, device, storage medium and alliance chain verification system |
| CN110059981B (en) * | 2019-04-29 | 2021-06-04 | 威富通科技有限公司 | Trust degree evaluation method and device and terminal equipment |
| CN110191116B (en) * | 2019-05-24 | 2021-10-26 | 北京清红微谷技术开发有限责任公司 | Malicious node isolation method and system, computing power verification terminal and P2P network |
| CN110222532A (en) * | 2019-06-06 | 2019-09-10 | 杭州趣链科技有限公司 | A kind of subregion common recognition method for realizing the secret protection of alliance's chain based on NameSpace |
| CN110245951B (en) * | 2019-06-19 | 2021-04-20 | 西南交通大学 | Tree structure based alliance chain master-slave multi-chain consensus method |
| CN110289966B (en) * | 2019-06-19 | 2021-08-03 | 西南交通大学 | Byzantine fault tolerance-based anti-adaptive attack union chain consensus method |
| CN110335156A (en) * | 2019-07-09 | 2019-10-15 | 广东投盟科技有限公司 | The regular maintaining method and its system of block chain |
| US11334561B2 (en) | 2019-07-24 | 2022-05-17 | Vmware, Inc. | Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision |
| US11341122B2 (en) | 2019-07-24 | 2022-05-24 | Vmware, Inc. | Byzantine fault tolerance that supports heterogeneous clients |
| CN110493198A (en) * | 2019-07-26 | 2019-11-22 | 北京工业大学 | A method of it is attacked based on Sybil in PBFT algorithm defence block chain is improved |
| CN110535836B (en) * | 2019-08-12 | 2021-10-29 | 安徽师范大学 | Trust block chain consensus method based on role classification |
| CN110519246B (en) * | 2019-08-15 | 2021-09-28 | 安徽师范大学 | Trust degree calculation method based on trust block chain node |
| CN110598060A (en) * | 2019-09-18 | 2019-12-20 | 广东卓启投资有限责任公司 | Block chain rapid consensus method and device, computer equipment and storage medium |
| CN113709122B (en) * | 2019-09-24 | 2023-08-22 | 支付宝(杭州)信息技术有限公司 | Service verification method of alliance chain and alliance chain system |
| CN110704533B (en) * | 2019-09-24 | 2021-06-18 | 东北大学 | False news monitoring method based on block chain and voting mechanism |
| CN110673914B (en) * | 2019-09-24 | 2021-06-29 | 支付宝(杭州)信息技术有限公司 | View switching method for block chain consensus and block chain system |
| CN111026569B (en) * | 2019-10-25 | 2023-09-15 | 贵阳信息技术研究院（中科院软件所贵阳分部） | Method for repairing specified block data in alliance chain |
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
| CN111131209B (en) * | 2019-12-16 | 2022-06-28 | 国网重庆市电力公司客户服务中心 | Improved efficient consensus method, system, computer device and storage medium |
| CN111327490B (en) * | 2020-01-20 | 2021-01-29 | 腾讯科技（深圳）有限公司 | Byzantine fault-tolerant detection method of block chain and related device |
| CN111371877B (en) * | 2020-02-28 | 2022-02-18 | 桂林电子科技大学 | Consensus method of heterogeneous alliance chain |
| CN111629022B (en) * | 2020-03-20 | 2022-05-20 | 恒宝股份有限公司 | Practical Byzantine fault-tolerant node setting method |
| CN111464633B (en) * | 2020-03-31 | 2023-03-21 | 成都质数斯达克科技有限公司 | Consensus method and system for transaction information of block chain |
| CN111464539B (en) * | 2020-03-31 | 2022-11-04 | 中国联合网络通信集团有限公司 | Block chain accounting method and accounting node |
| CN111556133B (en) * | 2020-04-26 | 2023-03-14 | 布比（北京）网络技术有限公司 | Block chain consensus method and system, computer storage medium and electronic equipment |
| CN111510502A (en) * | 2020-04-28 | 2020-08-07 | 吉林科创电力有限公司 | PBFT consensus propagation optimization method based on dynamic reputation value |
| CN113709197B (en) * | 2020-05-21 | 2024-02-23 | 顺丰科技有限公司 | Alliance block chain organization system and block chain system |
| CN111770103B (en) * | 2020-06-30 | 2021-12-14 | 中国科学技术大学 | Network node security attribute evaluation method based on block chain consensus result feedback |
| CN111865608B (en) * | 2020-07-02 | 2022-08-26 | 南京邮电大学 | Consensus mechanism operation method applied to alliance chain |
| CN111988321B (en) * | 2020-08-24 | 2022-02-11 | 桂林电子科技大学 | Alliance chain abnormity detection system based on machine learning and detection method thereof |
| CN112118117A (en) * | 2020-08-27 | 2020-12-22 | 紫光云(南京)数字技术有限公司 | Block chain consensus method based on Paxos algorithm |
| CN112422621A (en) * | 2020-09-28 | 2021-02-26 | 国网信息通信产业集团有限公司北京分公司 | Multi-station fusion power data consensus method and device based on PBFT block chain technology |
| CN112351117A (en) * | 2020-11-25 | 2021-02-09 | 北京邮电大学 | Domain name management method and device, electronic equipment and storage medium |
| CN112669135B (en) * | 2020-11-30 | 2024-03-08 | 泰康保险集团股份有限公司 | Data acquisition method and device, computer equipment and computer readable storage medium |
| CN112822267B (en) * | 2021-01-05 | 2022-08-26 | 支付宝(杭州)信息技术有限公司 | Data processing method and device based on block chain |
| CN112835854A (en) * | 2021-02-01 | 2021-05-25 | 北京百度网讯科技有限公司 | File storage method and device, electronic equipment and storage medium |
| CN113379428B (en) * | 2021-05-10 | 2023-07-07 | 贵州大学 | Bottled wine circulation tracing method and system |
| CN113326240B (en) * | 2021-06-22 | 2023-05-30 | 哈尔滨工程大学 | Data sharing method of energy consumption sensitive terminal node in edge network |
| CN114172680B (en) * | 2021-08-16 | 2023-01-20 | 北京天德科技有限公司 | Operation method of block chain system based on node reputation mechanism |
| CN113676541B (en) * | 2021-08-23 | 2023-06-27 | 南昌航空大学 | Improved PBFT consensus method |
| CN113746637B (en) * | 2021-09-03 | 2024-02-27 | 华东师范大学 | SEGBFT consensus algorithm applicable to alliance chains and high in expandability |
| CN113923275B (en) * | 2021-10-11 | 2023-11-28 | 卓尔智联(武汉)研究院有限公司 | Block chain negotiation method, electronic device and computer readable storage medium |
| CN114625497B (en) * | 2021-12-28 | 2023-04-07 | 杭州电子科技大学 | Credible service combination method based on cooperative sensing |
| CN114048517B (en) * | 2022-01-14 | 2022-05-20 | 北京大学深圳研究生院 | Dual channel consensus system and method for blockchains, computer readable storage medium |
| CN114338053B (en) * | 2022-03-16 | 2022-05-13 | 成都信息工程大学 | Dynamic reputation-based block chain consensus method and system |
| CN115277722B (en) * | 2022-07-27 | 2023-08-22 | 长安大学 | DR-PBFT (digital binary-representation-binary-representation) improvement method based on reputation value model |
| CN115334038B (en) * | 2022-08-20 | 2024-03-26 | 信通院(江西)科技创新研究院有限公司 | APPID application management method and system based on blockchain |
| CN115473643B (en) * | 2022-08-29 | 2024-06-25 | 安徽师范大学 | Trusted efficiency consensus system and method suitable for alliance chains |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6671821B1 (en) * | 1999-11-22 | 2003-12-30 | Massachusetts Institute Of Technology | Byzantine fault tolerance |
| CN106445711A (en) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | Byzantine-fault-tolerant consensus method applied to block chain |
| CN106453286A (en) * | 2016-09-27 | 2017-02-22 | 北京天德科技有限公司 | Reputation method and system based on block chain |
| CN106656974A (en) * | 2016-10-17 | 2017-05-10 | 江苏通付盾科技有限公司 | Block chain grouping consensus method and system |
| CN106651332A (en) * | 2016-12-29 | 2017-05-10 | 先锋支付有限公司 | Block chain and method for generating new block in block chain |
| CN107045518A (en) * | 2016-10-18 | 2017-08-15 | 北京天德科技有限公司 | A kind of extension design method of block chain |
| CN107395403A (en) * | 2017-07-07 | 2017-11-24 | 北京区块链云科技有限公司 | A kind of fiduciary block chain common recognition method suitable for extensive ecommerce |
-
2018
- 2018-02-07 CN CN201810122889.9A patent/CN108492103B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6671821B1 (en) * | 1999-11-22 | 2003-12-30 | Massachusetts Institute Of Technology | Byzantine fault tolerance |
| CN106445711A (en) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | Byzantine-fault-tolerant consensus method applied to block chain |
| CN106453286A (en) * | 2016-09-27 | 2017-02-22 | 北京天德科技有限公司 | Reputation method and system based on block chain |
| CN106656974A (en) * | 2016-10-17 | 2017-05-10 | 江苏通付盾科技有限公司 | Block chain grouping consensus method and system |
| CN107045518A (en) * | 2016-10-18 | 2017-08-15 | 北京天德科技有限公司 | A kind of extension design method of block chain |
| CN106651332A (en) * | 2016-12-29 | 2017-05-10 | 先锋支付有限公司 | Block chain and method for generating new block in block chain |
| CN107395403A (en) * | 2017-07-07 | 2017-11-24 | 北京区块链云科技有限公司 | A kind of fiduciary block chain common recognition method suitable for extensive ecommerce |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108492103A (en) | 2018-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108492103B (en) | Joint block chain consensus method | |
| US11177939B2 (en) | Blockchain system including a distributed network of a plurality of nodes and a method for achieving an agreement between the plurality of nodes executed by processors of the block chain system | |
| EP3610436B1 (en) | Rapid distributed consensus on blockchain | |
| CN108717630B (en) | Block output method and implementation system thereof | |
| EP3545665B1 (en) | System and method for detecting replay attack | |
| JP7319961B2 (en) | Computer-implemented systems and methods related to binary blockchains forming a pair of coupled blockchains | |
| CN110771127B (en) | Method and system for consistent distributed memory pools in a blockchain network | |
| CN110351133A (en) | Method and device for the host node hand-off process in block catenary system | |
| CN111199481A (en) | Distributed transaction network based on asynchronous directed acyclic graph | |
| CN112883114A (en) | Transaction processing method and device applied to block chain | |
| TW202145759A (en) | High throughput blockchain consensus systems, computer-implemented methods and non-transitory computer readable medium with low finalization time | |
| CN111682942B (en) | Binary weighted Byzantine fault-tolerant consensus method applied to license chain | |
| Sun et al. | RTChain: A reputation system with transaction and consensus incentives for e-commerce blockchain | |
| US12124433B2 (en) | Graphic-blockchain-orientated hybrid consensus implementation apparatus and implementation method thereof | |
| CN111010284B (en) | Processing method of block to be identified, related device and block chain system | |
| US20220278854A1 (en) | Unity Protocol Consensus | |
| KR20200083145A (en) | Fault tolerance consensus method for eliminating interference factors in blockchain networks | |
| CN113837758A (en) | Consensus method and device for block chain system | |
| CN111582843A (en) | Block chain privacy transaction method based on aggregated signature | |
| CN111258986A (en) | Rollback method of block chain | |
| CN109886695A (en) | Information sharing method and device and electronic equipment between different blocks chain | |
| CN110545261A (en) | Consensus algorithm applied to block chain network | |
| CN111787034B (en) | Block generation method, synchronization method, device, blockchain system and storage medium | |
| CN114154969B (en) | Large-scale trading and settlement method based on block chain | |
| CN111865595A (en) | Block chain consensus method and device |
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 |