CN112822239A - Block chain consensus method, block chain consensus device, electronic equipment and storage medium - Google Patents
Block chain consensus method, block chain consensus device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN112822239A CN112822239A CN202011613735.3A CN202011613735A CN112822239A CN 112822239 A CN112822239 A CN 112822239A CN 202011613735 A CN202011613735 A CN 202011613735A CN 112822239 A CN112822239 A CN 112822239A
- Authority
- CN
- China
- Prior art keywords
- node
- candidate node
- candidate
- ticket
- coefficient
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000012163 sequencing technique Methods 0.000 claims abstract description 7
- 230000006399 behavior Effects 0.000 claims description 110
- 238000004590 computer program Methods 0.000 claims description 7
- 238000004364 calculation method Methods 0.000 claims description 4
- 230000008569 process Effects 0.000 abstract description 30
- 238000004422 calculation algorithm Methods 0.000 abstract description 26
- 238000010586 diagram Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 230000000694 effects Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000003321 amplification Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000003199 nucleic acid amplification method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/46—Secure multiparty computation, e.g. millionaire problem
- H04L2209/463—Electronic voting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a block chain consensus method, a block chain consensus device, electronic equipment and a storage medium, which are used for solving the problem of poor stability of a cluster in a process of running a Raft consensus algorithm to achieve consensus. The method comprises the following steps: receiving a ticket pulling request of a plurality of candidate nodes in a block chain, wherein the ticket pulling request comprises a node identifier; acquiring historical behavior data of each candidate node corresponding to the node identification, and calculating ticket weight coefficients of each candidate node according to the historical behavior data of each candidate node to obtain a plurality of ticket weight coefficients; sequencing the ticket weight coefficients according to the sequence from big to small to obtain a plurality of sequenced ticket weight coefficients; and sending a voting signal to each candidate node in the candidate nodes in sequence according to the sequence of the sequenced plurality of ticket weight coefficients, so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value.
Description
Technical Field
The present application relates to the field of block chain and consensus mechanism technologies, and in particular, to a block chain consensus method, apparatus, electronic device, and storage medium.
Background
A Block Chain (Block Chain) is a series of text records cryptographically connected in series and protecting content, where the series of text records is also referred to as a Block; each block comprises a cryptographic hash of a previous block, a corresponding time stamp and transaction data, wherein the transaction data is represented by a hash value calculated by a merkel tree algorithm, and the design is such that the block content has the characteristic of being difficult to tamper; the use of distributed accounts concatenated with blockchain techniques allows both parties to efficiently record transactions and to permanently validate such transactions.
Consensus mechanisms (consensus), which are commonly found in the field of block chaining, are known as mechanisms of consensus; commonly used consensus algorithms include: raft consensus algorithm, Proof of Work (Proof-of-Work), Proof of rights and interests (Proof-of-stick), Proof of equity authorization (released-Proof-of-stick), and Proof of Capacity (Proof-of-space or Proof-of-Capacity), among others.
The left is a Distributed Consensus (Distributed Consensus) algorithm, which maintains the consistency of data in a cluster by a few majority-compliant elections. In a Raft cluster (Raft cluster) of servers, each server may be one of these three identities: leader, follower, or candidate.
Currently, in the process of running the Raft consensus algorithm to achieve consensus at all the block link points in the cluster, the follower nodes in the block chain directly return their votes (replies with the vote) as long as receiving the vote request (votes vote) sent by the candidate node. If the candidate node receives the votes of most nodes (for example, the number is N/2+1, N represents the number of nodes participating in consensus in the cluster), the candidate node becomes the leader node; however, in the process of cluster consensus, it is found that some nodes have malicious behaviors, which include: the behavior that all the election nodes frequently initiate election activities leads to the fact that the whole cluster cannot achieve consensus, or the behavior that after the candidate nodes become leader nodes, synchronous data is not issued leads to the fact that the whole cluster cannot normally operate. Therefore, the cluster has poor stability in the process of running the Raft consensus algorithm to achieve consensus.
Disclosure of Invention
An object of the embodiments of the present application is to provide a block chain consensus method, an apparatus, an electronic device, and a storage medium, which are used to solve the problem of poor stability of a cluster in a process of running a Raft consensus algorithm to achieve consensus.
The embodiment of the application provides a block chain consensus method, which is applied to all nodes participating in election in a block chain, and comprises the following steps: receiving a ticket pulling request of a plurality of candidate nodes in a block chain, wherein the ticket pulling request comprises a node identifier; acquiring historical behavior data of each candidate node corresponding to the node identification, and calculating ticket weight coefficients of each candidate node according to the historical behavior data of each candidate node to obtain a plurality of ticket weight coefficients; sequencing the ticket weight coefficients according to the sequence from big to small to obtain a plurality of sequenced ticket weight coefficients; and sending a voting signal to each candidate node in the candidate nodes in sequence according to the sequence of the sequenced plurality of ticket weight coefficients, so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value. In the implementation process, when voting is performed on all the participating election nodes in the block chain, the vote weight coefficient of each candidate node is calculated according to the historical behavior data of each candidate node, and then the voting signals are sequentially sent to each candidate node in the plurality of candidate nodes according to the descending order of the vote weight coefficients, so that the historical behavior information of the candidate nodes is fully utilized by all the participating election nodes in the block chain during voting, so that the nodes without malicious behaviors are preferentially voted, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Optionally, in this embodiment of the present application, calculating a ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node includes: judging whether the latest continuous election times of the candidate node in the historical behavior data are smaller than a preset threshold value or not; if yes, calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node. In the implementation process, the vote weight coefficient of each candidate node is calculated according to the historical behavior data of each candidate node only when the number of the latest continuous elections of the candidate node in the historical behavior data is smaller than the preset threshold, and voting is performed according to the vote weight coefficient, so that the problem that the node with malicious behavior is voted preferentially is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Optionally, in this embodiment of the present application, calculating a ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node includes: obtaining and counting historical behavior data of each candidate node, wherein the historical behavior data comprises: a node stability coefficient, a service participation time length coefficient and a data feedback timeliness coefficient; and carrying out weighted summation on the stability coefficient, the service duration coefficient and the feedback timeliness coefficient to obtain a ticket weight coefficient of each node. In the implementation process, the ticket weight coefficient of each node is determined through three dimensions of the stability coefficient, the service duration coefficient and the feedback timeliness coefficient, so that the problem that the node with malicious behavior is preferentially voted is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Optionally, in this embodiment of the present application, after determining whether the number of the latest consecutive elections of the candidate node in the historical behavior data is less than a preset threshold, the method further includes: and if the latest continuous election times of the candidate node in the historical behavior data are larger than or equal to a preset threshold value, setting the ticket weight coefficient of the candidate node to be zero. In the implementation process, if the number of the latest continuous elections of the candidate node in the historical behavior data is greater than or equal to the preset threshold, the ticket weight coefficient of the candidate node is set to be zero, so that the problem that the node with malicious behavior is voted preferentially is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
The embodiment of the present application further provides a device for block chain consensus, which is applied to all nodes participating in election in a block chain, and includes: the system comprises a drawing request receiving module, a drawing request receiving module and a drawing request processing module, wherein the drawing request receiving module is used for receiving drawing requests of a plurality of candidate nodes in a block chain, and the drawing requests comprise node identifiers; the behavior data acquisition module is used for acquiring historical behavior data of each candidate node corresponding to the node identification, calculating ticket weight coefficients of each candidate node according to the historical behavior data of each candidate node, and acquiring a plurality of ticket weight coefficients; the ticket weight coefficient sorting module is used for sorting the ticket weight coefficients according to the descending order to obtain a plurality of sorted ticket weight coefficients; and the voting signal sending module is used for sequentially sending a voting signal to each candidate node in the candidate nodes according to the sequence of the sequenced plurality of vote weight coefficients so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value. In the implementation process, when voting is performed on all the participating election nodes in the block chain, the vote weight coefficient of each candidate node is calculated according to the historical behavior data of each candidate node, and then the voting signals are sequentially sent to each candidate node in the plurality of candidate nodes according to the descending order of the vote weight coefficients, so that the historical behavior information of the candidate nodes is fully utilized by all the participating election nodes in the block chain during voting, so that the nodes without malicious behaviors are preferentially voted, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Optionally, in an embodiment of the present application, the historical behavior obtaining module includes: the election frequency judging module is used for judging whether the latest continuous election frequency of the candidate node in the historical behavior data is smaller than a preset threshold value or not; and the ticket weight coefficient calculation module is used for calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node if the number of the latest continuous elections of the candidate node in the historical behavior data is less than a preset threshold value. In the implementation process, the vote weight coefficient of each candidate node is calculated according to the historical behavior data of each candidate node only when the number of the latest continuous elections of the candidate node in the historical behavior data is smaller than the preset threshold, and voting is performed according to the vote weight coefficient, so that the problem that the node with malicious behavior is voted preferentially is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Optionally, in an embodiment of the present application, the ticket weight coefficient calculating module includes: the behavior data statistics module is used for acquiring and counting historical behavior data of each candidate node, and the historical behavior data comprises: a node stability coefficient, a service participation time length coefficient and a data feedback timeliness coefficient; and the coefficient weighting and summing module is used for weighting and summing the stability coefficient, the service time length coefficient and the feedback timeliness coefficient to obtain the ticket weight coefficient of each node. In the implementation process, the ticket weight coefficient of each node is determined through three dimensions of the stability coefficient, the service duration coefficient and the feedback timeliness coefficient, so that the problem that the node with malicious behavior is preferentially voted is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Optionally, in this embodiment of the present application, the historical behavior obtaining module further includes: and the ticket weight coefficient setting module is used for setting the ticket weight coefficient of the candidate node to be zero if the number of the latest continuous elections of the candidate node in the historical behavior data is greater than or equal to a preset threshold value. In the implementation process, if the number of the latest continuous elections of the candidate node in the historical behavior data is greater than or equal to the preset threshold, the ticket weight coefficient of the candidate node is set to be zero, so that the problem that the node with malicious behavior is voted preferentially is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
An embodiment of the present application further provides an electronic device, including: a processor and a memory, the memory storing processor-executable machine-readable instructions, the machine-readable instructions when executed by the processor performing the method as described above.
Embodiments of the present application also provide a storage medium having a computer program stored thereon, where the computer program is executed by a processor to perform the method as described above.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.
Fig. 1 is a schematic flow chart of a block chain consensus method according to an embodiment of the present disclosure;
FIG. 2 is a schematic flow chart illustrating interaction between a candidate node and a follower node according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a blockchain consensus apparatus according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.
Detailed Description
The technical solution in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.
Before introducing the block chain consensus method provided in the embodiments of the present application, some concepts related to the embodiments of the present application are introduced:
a node, also referred to as a blockchain node or a consensus node, refers to an electronic device participating in consensus using a Raft consensus algorithm in a blockchain cluster, where the electronic device may be a server or a terminal device, and the node may be referred to as a follower (follower) node, a candidate (candidate) node or a leader (leader) node according to the current state of the node.
The Transport Layer Security (TLS) protocol is a Security protocol, and aims to provide Security and data integrity guarantee for internet communication; the TLS protocol adopts a master-slave mode architecture model and is used for establishing a safe connection line between two application programs through a network so as to prevent eavesdropping and tampering during data exchange; the advantages of the TLS protocol are no coupling with higher layer application layer protocols (such as HTTP and FTP); the application layer protocol can transparently run on the TLS protocol, and the TLS protocol carries out negotiation and authentication required for creating an encrypted channel; data transmitted by the application layer protocol is encrypted when passing through the TLS protocol, so that the communication privacy is ensured.
A Secure Sockets Layer (SSL), which is a security protocol and aims to provide security and data integrity guarantee for internet communication; the SSL comprises a Record Layer (Record Layer) and a transport Layer, and the Record Layer protocol determines the packaging format of the data of the transport Layer; the transport layer security protocol uses X.509 authentication, then uses asymmetric encryption algorithm to authenticate the identity of a communication party, and then exchanges a symmetric key as a Session key; the session key is used for encrypting data exchanged by two communication parties, so that the confidentiality and the reliability of communication between two applications are ensured, and the communication between the client and the server application is not intercepted by an attacker.
A server refers to a device that provides computing services over a network, such as: x86 server and non-x 86 server, non-x 86 server includes: mainframe, minicomputer, and UNIX server. Certainly, in a specific implementation process, the server may specifically select a mainframe or a minicomputer, where the mainframe refers to a dedicated processor that mainly supports a closed and dedicated device for providing Computing service of a UNIX operating system, and that uses Reduced Instruction Set Computing (RISC), single-length fixed-point Instruction average execution speed (MIPS), and the like; a mainframe, also known as a mainframe, refers to a device that provides computing services using a dedicated set of processor instructions, an operating system, and application software.
It should be noted that the block chain consensus method provided in the embodiments of the present application may be executed by an electronic device, where the electronic device refers to a device terminal having a function of executing a computer program or the server described above, and the device terminal includes, for example: a smart phone, a Personal Computer (PC), a tablet computer, a Personal Digital Assistant (PDA), a Mobile Internet Device (MID), a network switch or a network router, and the like.
Before introducing the blockchain consensus method provided in the embodiment of the present application, an application scenario applicable to the blockchain consensus method is introduced, where the application scenario includes but is not limited to: the block chain consensus method is used for solving the problem that the stability of the block chain node cluster is poor in the process of achieving consensus, improving the stability of the block chain node cluster and the like.
Please refer to fig. 1, which is a schematic flow chart of a block chain consensus method according to an embodiment of the present application; the block chain consensus method can be applied to all participatory election nodes in a block chain, namely can be executed by the block chain nodes, and the main idea of the method is that when all participatory election nodes in the block chain vote, a vote weight coefficient of each candidate node is calculated according to historical behavior data of each candidate node, and then a voting signal is sent to each candidate node in a plurality of candidate nodes in sequence according to the sequence of the vote weight coefficients from large to small, so that all participatory election nodes in the block chain fully utilize the historical behavior information of the candidate nodes during voting, and therefore the nodes without malicious behaviors are voted preferentially, and the stability of a cluster in the process of running a Raft consensus algorithm to achieve consensus is effectively improved; the block chain consensus method may include:
step S110: receiving a ticket pulling request of a plurality of candidate nodes in the block chain, wherein the ticket pulling request comprises a node identifier.
It can be understood that when the algorithm starts, the leader node crashes or is disconnected (i.e. cannot communicate with other blockchain nodes), the whole blockchain cluster needs to elect a new leader node at this time, i.e. when the cluster enters a new term (term), the process of electing a new leader node from the blockchain nodes that communicate with each other in the cluster can be called leader election or leader election.
The embodiment of the step S110 includes: when the cluster enters a new term (term), candidate nodes in the block chain add one to the term number (term counter), declare an election, cast one ticket and send ticket pulling requests to other block chain nodes, then send ticket pulling requests (requestvotes) to other block chain nodes through a TLS protocol or an SSL protocol, and all participating election nodes receive the ticket pulling requests of a plurality of candidate nodes in the block chain, wherein the ticket pulling requests comprise node identifications.
After step S110, step S120 is performed: and acquiring historical behavior data of each candidate node corresponding to the node identification, and calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node to obtain a plurality of ticket weight coefficients.
Historical behavior data, which refers to behavior data of each blockchain node in a blockchain cluster collected by the blockchain node within a past period of time; the behavior data here includes: the node identification of the blockchain node, the time when the candidate node initiates election activity, the time when the leader node issues synchronous data and the like; the information such as time or time can be recorded and stored in a time stamp manner. The historical behavior data may specifically be stored in a relational database, a non-relational database, or a file system.
The specific collection mode of the historical behavior data is as follows: when the block link node is used as a leader node, the feedback timeliness data of each node can be recorded, the data of the length of the time for each node to participate in service can be calculated and updated, and each node is used as a candidate node to initiate election activity. Another example is: when the block chain node is used as a follower node, the stability data of each node can be collected, the length data of the time for each node to participate in service can be calculated and updated, and each node is used as a candidate node to initiate election activity; the stability data refers to data that is not responsible for acting as a leader node (e.g., synchronization data is not issued), and data that is not responsible for acting as a follower node (e.g., election is not initiated).
The above-mentioned embodiment of calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node in step S120 may include:
step S121: and judging whether the latest continuous election times of the candidate node in the historical behavior data are smaller than a preset threshold value.
The embodiment of step S121 described above is, for example: acquiring pre-collected and stored historical behavior data from a relational database, a non-relational database or a file system, and judging whether the latest continuous election times of candidate nodes in the historical behavior data are smaller than a preset threshold value or not; and inquiring the latest election data of the candidate node from the historical behavior data, determining whether the latest elections of the candidate node are continuous or not according to the latest election data, and determining whether the latest continuous election times are smaller than a preset threshold or not, if so, determining that the latest continuous election times of the candidate node are smaller than the preset threshold, and otherwise, determining that the latest continuous election times of the candidate node are larger than or equal to the preset threshold. The preset threshold value here may be set according to specific situations, for example, the preset threshold value is set to 3 times, 5 times, or 9 times, etc.
Step S122: and if the latest continuous election times of the candidate nodes in the historical behavior data are smaller than a preset threshold value, calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node.
The embodiment of step S122 is, for example: if the latest continuous election times of the candidate nodes in the historical behavior data are smaller than a preset threshold value, calculating a ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node; the embodiment of calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node may include: obtaining and counting historical behavior data of each candidate node, wherein the historical behavior data comprises: a node stability coefficient, a participating service time length coefficient, and a data feedback timeliness coefficient. According to a formula V, weighting and summing the stability coefficient, the service duration coefficient and the feedback timeliness coefficient to obtain a ticket weight coefficient of each node; where V denotes a ticket weight coefficient of each node, S denotes a node stability coefficient of the node, a denotes a weight of the node stability coefficient when calculating the ticket weight coefficient, T denotes a participating service time length coefficient of the node, b denotes a weight of the participating service time length coefficient when calculating the ticket weight coefficient, R denotes a data feedback timeliness coefficient of the node, and c denotes a weight of the data feedback timeliness coefficient when calculating the ticket weight coefficient, and the above a, b, and c may be set as the case may be, for example, a, b, and c are set to 40%, 30%, and 30%, respectively.
The node stability coefficient may be specifically calculated according to a formula S- (∑ Ln × 10+ ∑ Fm) × 100, thereby obtaining a node stability coefficient of each node; where S represents a node stability coefficient of the node, Σ Ln represents a sum of tenure numbers that are not responsible (e.g., synchronization data is not issued) when the node is a leader node, Σ Fm represents a sum of tenure numbers that are not responsible (e.g., election is not initiated) when the node is a follower node, where tenure numbers refer to ordinal numbers in the election process, and thus, tenure numbers herein are also referred to as election ordinal numbers, 10 represents a severity factor that is not responsible as a leader node, and 100 represents a magnification factor of data.
The participating service time length coefficient may be specifically calculated according to a formula T ═ T2-T1 × 100, and a participating service time length coefficient of each node is obtained; where T represents the node participation service time length coefficient, T2 represents the timestamp value of the current time, T1 represents the timestamp value of the node joining the block chain cluster, and 100 represents the amplification factor of the data.
The data feedback timeliness coefficient may be specifically calculated according to a formula R ═ Σ n × 100, and the data feedback timeliness coefficient of each node is obtained; wherein, R represents a data feedback timeliness coefficient of the node, 100 represents a magnification of the data, and n represents a number of times that a time length from receiving the data by the node to feeding back to the leader node is ahead of all nodes in the cluster, where the time length from receiving the data to feeding back to the leader node is specifically, for example: assuming that the node is a leader node, calculating the time length from the time when the node is sent to a follower node to the time when the voting signal of the follower node is received; the front row of all nodes in the cluster is specifically as follows: the time length used by all follower nodes for feeding back data is collected, the first half of the time length used by a target follower node for feeding back data of all follower nodes can be judged, namely all the time lengths are sorted from big to small, if the first half of the time length of the target follower node is in the target follower node, the time length used by the target follower node is determined to be in the front row of all the nodes of the cluster, and if not, the time length used by the target follower node is determined not to be in the front row of all the nodes of the cluster.
In the implementation process, the vote weight coefficient of each candidate node is calculated according to the historical behavior data of each candidate node only when the number of the latest continuous elections of the candidate node in the historical behavior data is smaller than the preset threshold, and voting is performed according to the vote weight coefficient, so that the problem that the node with malicious behavior is voted preferentially is solved, and the stability of the cluster in the process of running the Raft consensus algorithm to achieve consensus is effectively improved.
Step S123: and if the latest continuous election times of the candidate node in the historical behavior data are larger than or equal to a preset threshold value, setting the ticket weight coefficient of the candidate node to be zero.
The embodiment of step S123 described above is, for example: it can be understood that if the candidate node has recently initiated the election for a number of times greater than or equal to the preset threshold, which indicates that the candidate node has maliciously frequently initiated the election, the weight coefficient of the candidate node may be directly set to zero in the case that it is confirmed that the number of the most recent consecutive elections of the candidate node in the historical behavior data is greater than or equal to the preset threshold; the preset threshold value here may be set according to specific situations, for example, the preset threshold value is set to 3 times, 5 times, or 9 times, etc.
After step S120, step S130 is performed: and sequencing the ticket weight coefficients according to the sequence from big to small to obtain a plurality of sequenced ticket weight coefficients.
The embodiment of step S130 described above is, for example: sequencing the ticket weight coefficients in a descending order by using a sequencing algorithm to obtain a plurality of sequenced ticket weight coefficients; the Sorting algorithm (Sorting algorithm) is an algorithm that can arrange a string of data according to a specific Sorting method; ranking algorithms that may be used include: bubble Sort (Bubble Sort), Selection Sort (Selection Sort), Insertion Sort (Insertion Sort), Hill Sort (Shell Sort), Merge Sort (Merge Sort), Quick Sort (Quick Sort), Heap Sort (Heap Sort), and so forth.
After step S130, step S140 is performed: and sending a voting signal to each candidate node in the candidate nodes in sequence according to the sequence of the sequenced plurality of ticket weight coefficients, so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value.
The embodiment of step S140 described above is, for example: sequentially sending a voting signal to each candidate node in the plurality of candidate nodes according to the sequence of the sequenced plurality of ticket weight coefficients, so that the candidate node is used as a leader node to send a leader signal to all nodes in the block chain after the obtained voting signal is greater than or equal to a preset value (namely, the candidate node is a leader node); the predetermined value is about half of the number of nodes in the blockchain cluster, and is usually N/2+1, where N represents the number of all nodes in the blockchain cluster.
In the implementation process, when voting is performed on all the participating election nodes in the block chain, the vote weight coefficient of each candidate node is calculated according to the historical behavior data of each candidate node, and then the voting signals are sequentially sent to each candidate node in the candidate nodes according to the sequence from large to small of the vote weight coefficients, so that the historical behavior information of the candidate nodes is fully utilized by all the participating election nodes in the block chain during voting, and therefore the nodes without malicious behaviors are preferentially voted.
Please refer to fig. 2, which is a schematic flow chart illustrating the interaction between a candidate node and a follower node according to an embodiment of the present application; the specific process of interaction between the candidate node and the follower node may include:
step S210: the candidate node of the blockchain sends a ticket pulling request to the follower node.
The embodiment of step S210 described above is, for example: when a block chain cluster enters a new tenure (term), a candidate node of the block chain sends a ticket pulling request to a follower node through a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP), wherein the ticket pulling request comprises a node identifier of the candidate node.
Step S220: and the follower node receives the ticket pulling request of the candidate node, evaluates the behavior data of the candidate node according to the ticket pulling request and sends a voting signal to the candidate node.
The embodiment of step S220 described above is, for example: the follower node receives a ticket pulling request of the candidate node, acquires historical behavior data of each candidate node corresponding to the node identification according to the node identification of the candidate node in the ticket pulling request, calculates a ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node, and acquires a plurality of ticket weight coefficients; then, sequencing the ticket weight coefficients according to a descending order to obtain a plurality of sequenced ticket weight coefficients; and finally, sending voting signals to the candidate nodes in sequence according to the sequence of the sequenced plurality of ticket weight coefficients.
Step S230: and the candidate node receives the voting signal sent by the follower node, and if the received voting signal is greater than or equal to a preset value, the candidate node sends a leader signal to all nodes in the block chain.
The embodiment of the step S230 is, for example: the candidate node receives the voting signals sent by the follower node, judges whether the received voting signals are larger than or equal to a preset numerical value or not, and sends leader signals to all nodes in the block chain if the received voting signals are larger than or equal to the preset numerical value; the preset value is about half of the number of nodes in the blockchain cluster, and usually N/2+1 is adopted, where N represents the number of all nodes in the blockchain cluster.
Please refer to fig. 3, which is a schematic structural diagram of a block chain consensus device according to an embodiment of the present application; the embodiment of the present application provides a block chain consensus device 300, which is applied to all participating election nodes in a block chain, and includes:
the drawing request receiving module 310 is configured to receive drawing requests of multiple candidate nodes in a block chain, where the drawing requests include node identifiers.
The behavior data obtaining module 320 is configured to obtain historical behavior data of each candidate node corresponding to the node identifier, and calculate a ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node, so as to obtain a plurality of ticket weight coefficients.
The ticket weight coefficient sorting module 330 is configured to sort the plurality of ticket weight coefficients according to a descending order, so as to obtain a plurality of sorted ticket weight coefficients.
The voting signal sending module 340 is configured to send a voting signal to each candidate node in the plurality of candidate nodes in sequence according to the sequence of the sorted plurality of vote weight coefficients, so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value.
Optionally, in an embodiment of the present application, the historical behavior obtaining module includes:
and the election frequency judging module is used for judging whether the latest continuous election frequency of the candidate node in the historical behavior data is smaller than a preset threshold value.
And the ticket weight coefficient calculation module is used for calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node if the number of the latest continuous elections of the candidate node in the historical behavior data is less than a preset threshold value.
Optionally, in an embodiment of the present application, the ticket weight coefficient calculating module includes:
the behavior data statistics module is used for acquiring and counting historical behavior data of each candidate node, and the historical behavior data comprises: a node stability coefficient, a participating service time length coefficient, and a data feedback timeliness coefficient.
And the coefficient weighting and summing module is used for weighting and summing the stability coefficient, the service time length coefficient and the feedback timeliness coefficient to obtain the ticket weight coefficient of each node.
Optionally, in this embodiment of the present application, the historical behavior obtaining module further includes:
and the ticket weight coefficient setting module is used for setting the ticket weight coefficient of the candidate node to be zero if the number of the latest continuous elections of the candidate node in the historical behavior data is greater than or equal to a preset threshold value.
It should be understood that the apparatus corresponds to the above-mentioned embodiment of the blockchain consensus method, and can perform the steps related to the above-mentioned embodiment of the method, and the specific functions of the apparatus can be referred to the above description, and the detailed description is appropriately omitted herein to avoid redundancy. The device includes at least one software function that can be stored in memory in the form of software or firmware (firmware) or solidified in the Operating System (OS) of the device.
Please refer to fig. 4 for a schematic structural diagram of an electronic device according to an embodiment of the present application. An electronic device 400 provided in an embodiment of the present application includes: a processor 410 and a memory 420, the memory 420 storing machine-readable instructions executable by the processor 410, the machine-readable instructions when executed by the processor 410 performing the method as above.
The embodiment of the present application also provides a storage medium 430, where the storage medium 430 stores a computer program, and the computer program is executed by the processor 410 to perform the method as above.
The storage medium 430 may be implemented by any type of volatile or nonvolatile storage device or combination thereof, such as a Static Random Access Memory (SRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), an Erasable Programmable Read-Only Memory (EPROM), a Programmable Read-Only Memory (PROM), a Read-Only Memory (ROM), a magnetic Memory, a flash Memory, a magnetic disk, or an optical disk.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, functional modules of the embodiments in the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
The above description is only an alternative embodiment of the embodiments of the present application, but the scope of the embodiments of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the embodiments of the present application, and all the changes or substitutions should be covered by the scope of the embodiments of the present application.
Claims (10)
1. A method for block chain consensus, applied to all participating election nodes in a block chain, comprising:
receiving a ticket pulling request of a plurality of candidate nodes in the block chain, wherein the ticket pulling request comprises a node identifier;
acquiring historical behavior data of each candidate node corresponding to the node identification, and calculating ticket weight coefficients of each candidate node according to the historical behavior data of each candidate node to obtain a plurality of ticket weight coefficients;
sequencing the ticket weight coefficients according to the sequence from big to small to obtain a plurality of sequenced ticket weight coefficients;
and sending a voting signal to each candidate node in the candidate nodes in sequence according to the sequence of the sequenced plurality of vote weight coefficients, so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value.
2. The method of claim 1, wherein the calculating the weight coefficient of each candidate node according to the historical behavior data of each candidate node comprises:
judging whether the latest continuous election times of the candidate node in the historical behavior data are smaller than a preset threshold value or not;
if yes, calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node.
3. The method of claim 2, wherein the calculating the weight-of-ticket coefficient for each candidate node from the historical behavior data for each candidate node comprises:
obtaining and counting historical behavior data of each candidate node, wherein the historical behavior data comprises: a node stability coefficient, a service participation time length coefficient and a data feedback timeliness coefficient;
and carrying out weighted summation on the stability coefficient, the service duration coefficient and the feedback timeliness coefficient to obtain a ticket weight coefficient of each node.
4. The method of claim 2, wherein after determining whether the number of most recent consecutive elections of the candidate node in the historical behavior data is less than a preset threshold, further comprising:
and if the number of the latest continuous elections of the candidate node in the historical behavior data is greater than or equal to a preset threshold value, setting the ticket weight coefficient of the candidate node to be zero.
5. A device for block chain consensus, applied to all participating election nodes in a block chain, comprising:
a drawing request receiving module, configured to receive drawing requests of multiple candidate nodes in the block chain, where the drawing requests include node identifiers;
the behavior data acquisition module is used for acquiring historical behavior data of each candidate node corresponding to the node identification, calculating ticket weight coefficients of each candidate node according to the historical behavior data of each candidate node, and acquiring a plurality of ticket weight coefficients;
the ticket weight coefficient sorting module is used for sorting the ticket weight coefficients according to a descending order to obtain a plurality of sorted ticket weight coefficients;
and the voting signal sending module is used for sequentially sending a voting signal to each candidate node in the candidate nodes according to the sequence of the sequenced plurality of vote weight coefficients so that the candidate nodes send leader signals to all nodes in the block chain after the obtained voting signals are greater than or equal to a preset value.
6. The apparatus of claim 5, wherein the historical behavior acquisition module comprises:
the election frequency judging module is used for judging whether the latest continuous election frequency of the candidate node in the historical behavior data is smaller than a preset threshold value or not;
and the ticket weight coefficient calculation module is used for calculating the ticket weight coefficient of each candidate node according to the historical behavior data of each candidate node if the number of the latest continuous elections of the candidate node in the historical behavior data is less than a preset threshold value.
7. The apparatus of claim 5, wherein the ticket weight coefficient calculation module comprises:
a behavior data statistics module, configured to obtain and count historical behavior data of each candidate node, where the historical behavior data includes: a node stability coefficient, a service participation time length coefficient and a data feedback timeliness coefficient;
and the coefficient weighted summation module is used for carrying out weighted summation on the stability coefficient, the service duration coefficient and the feedback timeliness coefficient to obtain the ticket weight coefficient of each node.
8. The apparatus of claim 5, wherein the historical behavior acquisition module further comprises:
and the ticket weight coefficient setting module is used for setting the ticket weight coefficient of the candidate node to be zero if the number of the latest continuous elections of the candidate node in the historical behavior data is greater than or equal to a preset threshold value.
9. An electronic device, comprising: a processor and a memory, the memory storing machine-readable instructions executable by the processor, the machine-readable instructions, when executed by the processor, performing the method of any of claims 1 to 4.
10. A storage medium, having stored thereon a computer program which, when executed by a processor, performs the method of any one of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011613735.3A CN112822239A (en) | 2020-12-30 | 2020-12-30 | Block chain consensus method, block chain consensus device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011613735.3A CN112822239A (en) | 2020-12-30 | 2020-12-30 | Block chain consensus method, block chain consensus device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112822239A true CN112822239A (en) | 2021-05-18 |
Family
ID=75855452
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011613735.3A Pending CN112822239A (en) | 2020-12-30 | 2020-12-30 | Block chain consensus method, block chain consensus device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112822239A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113298404A (en) * | 2021-06-03 | 2021-08-24 | 光大科技有限公司 | Method and device for determining workload of federal learning participator |
| CN113609214A (en) * | 2021-07-06 | 2021-11-05 | 佛山市禅城区政务服务数据管理局 | Data feedback method and system based on block chain |
| CN113947491A (en) * | 2021-11-11 | 2022-01-18 | 昆明电力交易中心有限责任公司 | Leader node determination method, device, equipment and medium based on power block chain |
| CN114189421A (en) * | 2022-02-17 | 2022-03-15 | 江西农业大学 | Leader node election method, system, storage medium and equipment |
| CN114338695A (en) * | 2022-03-10 | 2022-04-12 | 深圳艾灵网络有限公司 | Leader election method, device, equipment and storage medium based on multiple copies |
| CN114465866A (en) * | 2022-01-21 | 2022-05-10 | 北京航空航天大学 | Block chain generation method and device, storage medium and electronic equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108377206A (en) * | 2018-03-12 | 2018-08-07 | 众安信息技术服务有限公司 | Method, apparatus and computer readable storage medium for configuring common recognition algorithm |
| CN109714404A (en) * | 2018-12-12 | 2019-05-03 | 中国联合网络通信集团有限公司 | Block chain common recognition method and device based on Raft algorithm |
| CN111130875A (en) * | 2019-12-20 | 2020-05-08 | 上海优扬新媒信息技术有限公司 | Block chain consensus method, device, equipment and storage medium |
| WO2020143183A1 (en) * | 2019-01-11 | 2020-07-16 | 平安科技（深圳）有限公司 | Blockchain consensus method based on delegated proof of stake, and related device |
| CN111432014A (en) * | 2020-03-30 | 2020-07-17 | 上海玳鸽信息技术有限公司 | Method and device for selecting main node in block chain consensus algorithm |
| KR20200087913A (en) * | 2019-01-11 | 2020-07-22 | 서강대학교산학협력단 | System and method for providing secret electronic voting service based on blockchain |
-
2020
- 2020-12-30 CN CN202011613735.3A patent/CN112822239A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108377206A (en) * | 2018-03-12 | 2018-08-07 | 众安信息技术服务有限公司 | Method, apparatus and computer readable storage medium for configuring common recognition algorithm |
| CN109714404A (en) * | 2018-12-12 | 2019-05-03 | 中国联合网络通信集团有限公司 | Block chain common recognition method and device based on Raft algorithm |
| WO2020143183A1 (en) * | 2019-01-11 | 2020-07-16 | 平安科技（深圳）有限公司 | Blockchain consensus method based on delegated proof of stake, and related device |
| KR20200087913A (en) * | 2019-01-11 | 2020-07-22 | 서강대학교산학협력단 | System and method for providing secret electronic voting service based on blockchain |
| CN111130875A (en) * | 2019-12-20 | 2020-05-08 | 上海优扬新媒信息技术有限公司 | Block chain consensus method, device, equipment and storage medium |
| CN111432014A (en) * | 2020-03-30 | 2020-07-17 | 上海玳鸽信息技术有限公司 | Method and device for selecting main node in block chain consensus algorithm |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113298404A (en) * | 2021-06-03 | 2021-08-24 | 光大科技有限公司 | Method and device for determining workload of federal learning participator |
| CN113609214A (en) * | 2021-07-06 | 2021-11-05 | 佛山市禅城区政务服务数据管理局 | Data feedback method and system based on block chain |
| CN113947491A (en) * | 2021-11-11 | 2022-01-18 | 昆明电力交易中心有限责任公司 | Leader node determination method, device, equipment and medium based on power block chain |
| CN114465866A (en) * | 2022-01-21 | 2022-05-10 | 北京航空航天大学 | Block chain generation method and device, storage medium and electronic equipment |
| CN114465866B (en) * | 2022-01-21 | 2023-08-15 | 北京航空航天大学 | DPoS method based on trust degree and PBFT |
| CN114189421A (en) * | 2022-02-17 | 2022-03-15 | 江西农业大学 | Leader node election method, system, storage medium and equipment |
| CN114338695A (en) * | 2022-03-10 | 2022-04-12 | 深圳艾灵网络有限公司 | Leader election method, device, equipment and storage medium based on multiple copies |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112822239A (en) | Block chain consensus method, block chain consensus device, electronic equipment and storage medium | |
| US11949691B2 (en) | Malicious peer identification | |
| CN111427957B (en) | Block chain voting information verification method, device, equipment and storage medium | |
| EP3545665B1 (en) | System and method for detecting replay attack | |
| US20210091957A1 (en) | Consensus protocol for blockchain dag structure | |
| CN111556120B (en) | Data processing method and device based on block chain, storage medium and equipment | |
| US20210117385A1 (en) | Database snapshot for managing state synchronization | |
| CN110602217B (en) | Block chain-based alliance management method, device, equipment and storage medium | |
| CN111476572B (en) | Block chain-based data processing method, device, storage medium and equipment | |
| CN110599142A (en) | Data storage method and device, computer equipment and storage medium | |
| CN114978635A (en) | Cross-domain authentication method and device, and user registration method and device | |
| CN112822267A (en) | Data processing method and device based on block chain | |
| JP2022518960A (en) | Network transaction verification method based on multiple nodes and its system and storage medium | |
| CN110737915A (en) | Anti-quantum-computation anonymous identity recognition method and system based on alliance chain and implicit certificate | |
| CN111984295B (en) | Block chain software whole-network updating method, storage medium and electronic equipment | |
| CN111444204B (en) | Synchronous processing method, device, equipment and medium | |
| KR20220074971A (en) | Blockchain-based data processing method, apparatus and device, and readable storage medium | |
| US20230208640A1 (en) | Selective audit process for privacy-preserving blockchain | |
| CN112417052B (en) | Data synchronization method, device, equipment and storage medium in block chain network | |
| CN112200680B (en) | Block link point management method, device, computer and readable storage medium | |
| CN111865595A (en) | Block chain consensus method and device | |
| CN115455460A (en) | Data storage method, device, equipment and medium based on block chain | |
| CN108882230B (en) | Call record management method, device and system | |
| CN115794947A (en) | Data synchronization method and device, storage medium and electronic equipment | |
| CN117221337A (en) | Block chain consensus method, device, medium and electronic 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 | ||
| AD01 | Patent right deemed abandoned |
Effective date of abandoning: 20240105 |
|
| AD01 | Patent right deemed abandoned |