CN113630455B - Raft consensus method applicable to Internet of things - Google Patents

Raft consensus method applicable to Internet of things Download PDF

Info

Publication number
CN113630455B
CN113630455B CN202110882162.2A CN202110882162A CN113630455B CN 113630455 B CN113630455 B CN 113630455B CN 202110882162 A CN202110882162 A CN 202110882162A CN 113630455 B CN113630455 B CN 113630455B
Authority
CN
China
Prior art keywords
internet
things
random number
node
consensus
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
Application number
CN202110882162.2A
Other languages
Chinese (zh)
Other versions
CN113630455A (en
Inventor
王绪繁
柯晓凡
陶俭
陈竞翔
黄杰
周子岩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huaneng Energy Transportation Industry Holding Co ltd
Shanghai Huaneng E Commerce Co ltd
Original Assignee
Huaneng Energy Transportation Industry Holding Co ltd
Shanghai Huaneng E Commerce Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huaneng Energy Transportation Industry Holding Co ltd, Shanghai Huaneng E Commerce Co ltd filed Critical Huaneng Energy Transportation Industry Holding Co ltd
Priority to CN202110882162.2A priority Critical patent/CN113630455B/en
Publication of CN113630455A publication Critical patent/CN113630455A/en
Application granted granted Critical
Publication of CN113630455B publication Critical patent/CN113630455B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention discloses a Raft consensus method applicable to the Internet of things, which comprises the steps of collecting Internet of things data in a distributed physical network in real time through Internet of things collection equipment, and caching the Internet of things data in an Internet of things gateway; packaging the data of the Internet of things within the time of 60s + K/N, and counting the packaged data flow; calculating a random number Nonce value based on a random number function of a linear congruence algorithm and a Hash algorithm; dynamically adjusting the selection master difficulty according to the data flow parameters, determining a target value, and judging whether the Nonce value meets the target value; designing a timer and starting a consensus selection main process, selecting a consensus main node according to a random number Nonce value meeting a target value, and copying an RAFT log; the invention realizes the dynamic election of the main node according to the dynamic change of the data volume received by the node receiving and collecting equipment, and has the advantages of safety, reliability and low operation and maintenance cost.

Description

Raft consensus method applicable to Internet of things
Technical Field
The invention relates to the technical field of consensus mechanisms, in particular to a Raft consensus method applicable to the Internet of things.
Background
The RAFT consensus algorithm is an algorithm for realizing distributed consensus, mainly used for managing consistency of log replication, and is adopted by many distributed systems because of easier comprehension and high consensus efficiency.
However, because the traditional RAFT consensus algorithm adopts a mode of multiple communication voting, higher requirements are put forward on the communication efficiency of a distributed system which usually adopts a P2P network, and meanwhile, the RAFT consensus algorithm based on the voting is very high in randomness, guarantees certain security, but is too high in centralization degree, and cannot be applied to a weak trust environment. The problem that the requirement on the communication environment is too high and the method is not suitable for the weak trust environment is solved, so that the traditional RAFT consensus algorithm cannot be coupled with the application scene of the Internet of things.
Disclosure of Invention
This section is for the purpose of summarizing some aspects of embodiments of the invention and to briefly introduce some preferred embodiments. In this section, as well as in the abstract and the title of the invention of this application, simplifications or omissions may be made to avoid obscuring the purpose of the section, the abstract and the title, and such simplifications or omissions are not intended to limit the scope of the invention.
The present invention has been made in view of the above-mentioned conventional problems.
Therefore, the invention provides a Raft consensus method applicable to the Internet of things, and the problem of the coupling of the consensus algorithm and the application scene of the Internet of things can be solved.
In order to solve the technical problems, the invention provides the following technical scheme: the method comprises the steps that Internet of things data in a distributed physical network are collected in real time through Internet of things collection equipment, and the Internet of things data are cached in an Internet of things gateway; packaging the Internet of things data in the Internet of things gateway within 60s + K/N, and counting the packaged data traffic; calculating a random number Nonce value based on a random number function of a linear congruence algorithm and an SHA-256 algorithm; dynamically adjusting the selection difficulty according to the data flow parameters to further determine a target value and judge whether the Nonce value meets the target value; if the target value is met, keeping the proof of meeting; otherwise, updating the random number Nonce value, and continuously judging whether the updated random number Nonce value meets the target value; designing a timer and starting a consensus selection main process, selecting a consensus main node according to a random number Nonce value meeting a target value, and copying an RAFT log; and K is a constant, and N is the size of the data traffic received by each node in unit time.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: the calculating the Nonce value includes that the expression of the Nonce function based on the linear congruence algorithm is:
(Ni+1)＝(a*Ni+b)Mod M
wherein, i is 0, 1,.., M-1; m is a current timestamp; n is the random number Nonce value, a is a large prime number, and b is a constant.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: the design timer comprises that the timers comprise a heartbeat timer, an optional master timer and an emergency optional master timer; setting the time of the heartbeat timer to be 150ms to 300 ms; setting the time of the master timer to be 60s + K/N; and setting the time of the emergency master timer to be K/N.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: the master selection difficulty dynamic adjustment comprises designing a difficulty dynamic adjustment function, and dynamically adjusting the master selection difficulty through the difficulty dynamic adjustment function, wherein the difficulty dynamic adjustment function is as follows:
Figure BDA0003192438350000021
wherein D (H) is the difficulty of the block;
Figure BDA0003192438350000022
is the previous zoneThe difficulty of the block;
Figure BDA0003192438350000023
a block difficulty function is adjusted for self-adaptation; hiIs the current block number.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: the adaptively adjusting the block out difficulty function includes,
Figure BDA0003192438350000024
Figure BDA0003192438350000025
wherein, x is the unit of adjustment,
Figure BDA0003192438350000026
is the adjusted coefficient; the lower bound of the self-adaptive adjusting block outlet difficulty function is D0The upper bound is-99; p (H)HSIs the parent block timestamp.
As a preferred scheme of the Raft consensus method applicable to the Internet of things, the method comprises the following steps: the judgment comprises the following judgment conditions:
Hash(Rand(h，n))≤N/D(H)
wherein h and n are input, namely a block Header hash value and a Nonce value in a Header; n is the flow value received by the node, and N/D (H) is the target value.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: the method also comprises the steps of performing the common identification selection when the Leader node is not down and starting the common identification selection main flow when the Leader node is down because the network environment is unreliable.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: the RAFT log replication comprises the steps that a Client side submits an instruction to a Leader node, and after the Leader node receives the instruction, the instruction is written into a local log; the Leader node copies the instruction to other nodes concurrently and waits for the other nodes to write the instruction into the local log; and submitting the instructions to a state machine by the Leader node until all the instructions are written into the local log, and then returning an execution result to the Client by the state machine.
As a preferred scheme of the Raft consensus method applicable to the internet of things, the method comprises the following steps: selecting the consensus master node comprises using a first random number Nonce value that meets a target value as the consensus master node.
The invention has the beneficial effects that: the method is based on the simple log replication process of the traditional Raft consensus algorithm, reduces the complicated communication links of messages, realizes the dynamic election of the main node according to the dynamic change of the data volume received by the node receiving and collecting equipment, and is safe, reliable and low in operation and maintenance cost.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise. Wherein:
fig. 1 is a schematic flowchart of a Raft consensus method applicable to the internet of things according to a first embodiment of the present invention;
fig. 2 is a schematic diagram illustrating a term concept of a Raft consensus method applicable to the internet of things according to a first embodiment of the present invention;
fig. 3 is a schematic diagram illustrating a transaction request submission according to a Raft consensus method applied to the internet of things according to a first embodiment of the present invention;
fig. 4 is a schematic transaction broadcast diagram of a Raft consensus method applied to the internet of things according to a first embodiment of the present invention;
fig. 5 is a schematic diagram of transaction synchronization of a Raft consensus method applied to the internet of things according to a first embodiment of the present invention;
fig. 6 is a schematic diagram of test data of a conventional Raft consensus method applicable to the Raft consensus method of the internet of things according to the second embodiment of the present invention.
Fig. 7 is a schematic diagram of test data of the method for the Raft consensus method for the internet of things according to the second embodiment of the present invention.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, specific embodiments accompanied with figures are described in detail below, and it is apparent that the described embodiments are a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be obtained by a person skilled in the art without making creative efforts based on the embodiments of the present invention, shall fall within the protection scope of the present invention.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, but the present invention may be practiced in other ways than those specifically described and will be readily apparent to those of ordinary skill in the art without departing from the spirit of the present invention, and therefore the present invention is not limited to the specific embodiments disclosed below.
Furthermore, reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one implementation of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments.
The present invention will be described in detail with reference to the drawings, wherein the cross-sectional views illustrating the structure of the device are not enlarged partially in general scale for convenience of illustration, and the drawings are only exemplary and should not be construed as limiting the scope of the present invention. In addition, the three-dimensional dimensions of length, width and depth should be included in the actual fabrication.
Meanwhile, in the description of the present invention, it should be noted that the terms "upper, lower, inner and outer" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, and are only for convenience of describing the present invention and simplifying the description, but do not indicate or imply that the referred device or element must have a specific orientation, be constructed in a specific orientation and operate, and thus, cannot be construed as limiting the present invention. Furthermore, the terms first, second, or third are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
The terms "mounted, connected and connected" in the present invention are to be understood broadly, unless otherwise explicitly specified or limited, for example: can be fixedly connected, detachably connected or integrally connected; they may be mechanically, electrically, or directly connected, or indirectly connected through intervening media, or may be interconnected between two elements. The specific meanings of the above terms in the present invention can be understood in specific cases to those skilled in the art.
Example 1
Referring to fig. 1 to 5, a first embodiment of the present invention provides a method for recognizing a Raft applicable to an internet of things, including:
s1: the method comprises the steps of collecting Internet of things data in a distributed physical network in real time through Internet of things collection equipment, and caching the Internet of things data in an Internet of things gateway.
S2: and packaging the Internet of things data in the Internet of things gateway within 60s + K/N, and counting the packaged data traffic.
It should be noted that K is a constant and can be set as required; n, the size of the data traffic received by each node in unit time.
S3: and calculating a random number Nonce value based on a random number function of a linear congruence algorithm and the SHA-256 algorithm.
And combining the data timestamp, the hash value of the parent block, the hash value of the current block, the difficulty of the parent block and the flow value with a random number function of a linear congruence algorithm and an SHA-256 algorithm to obtain a random number Nonce value.
Specifically, the expression of the random number function rand () based on the linear congruence algorithm is as follows:
(Ni+1)＝(a*Ni+b)Mod M
wherein, i is 0, 1,.., M-1; m is a current timestamp; n is a random number Nonce, a is a constant and is a large prime number, and b is a constant.
S4: and dynamically adjusting the selection master difficulty according to the data flow parameters to further determine a target value and judge whether the random number Nonce value meets the target value.
Designing a difficulty dynamic adjusting function, and dynamically adjusting the selection difficulty through the difficulty dynamic adjusting function, wherein the difficulty dynamic adjusting function is as follows:
Figure BDA0003192438350000051
wherein D (H) is the difficulty of the block;
Figure BDA0003192438350000052
the difficulty of the previous block; hiIs the current block number;
Figure BDA0003192438350000053
for adaptive adjustment of the block difficulty function, the expressions are respectively as follows:
Figure BDA0003192438350000061
Figure BDA0003192438350000062
wherein χ is the unit of adjustment,
Figure BDA0003192438350000063
is the adjusted coefficient;
Figure BDA0003192438350000064
a parent block timestamp; self-adaptive adjusting block outlet difficultyThe lower bound of the degree function is D0The upper bound is-99 to cope with hacking or other presently unexpected black swan events.
Further, whether the random number Nonce value meets the target value is determined by the following formula:
Hash(Rand(h，n))≤N/D(H)
wherein h and n are input, namely a block Header hash value and a Nonce value in a Header; n is a flow value received by the node; N/D (H) is a target value; in the case where h and n are determined, the larger D (H), the greater the degree of excavation difficulty; meanwhile, the larger N is, the larger the value on the right side of the formula is, the smaller the overall difficulty is;
if the random number Nonce value meets the target value, the random number Nonce value is reserved; otherwise, updating the random number Nonce value, and continuously judging whether the updated random number Nonce value meets the target value.
And if the updated random number Nonce value meets the target value, stopping updating the random number Nonce value.
S5: designing a timer and starting a consensus selection main process, selecting a consensus main node according to a random number Nonce value meeting a target value, and copying an RAFT log.
It should be noted that the method decomposes time into terms of any length, as shown in fig. 2, and defines three states for a distributed network node: follower, Candidate, Leader, states are interconverted.
terms has a continuous monotonically increasing number, each term starts with election, at which stage each Candidate attempts to become a Leader node; if a Candidate election succeeds, it honors Leader responsibilities for the term remaining period; in some cases, a Leader node case may be selected, where a new term starts immediately; the method ensures that only one Leader node can exist in any term; term is used as a logical clock in this consensus, servers can use term to determine some outdated information: such as outdated Leader nodes; in addition, each server stores the current term number, which monotonically increases over time; the term number may change on any server communication: if the current term number of a certain server node is smaller than that of other servers, the server must update the term number of the server node to keep consistent; if one Candidate or Leader node finds that its term is expired, it is demoted to Follower; if a server node receives an outdated request (with an outdated term number), it rejects the request.
The design timer comprises a heartbeat timer, a selection timer and an emergency selection timer; each node (Follower, Candidate, Leader) has a timer; the heartbeat timer is used for verifying whether the working state of the Leader node is normal or not by the Follower node, and the time of the heartbeat timer is set to be 150ms to 300 ms; the election timer is used for enabling the Follower node to send election competition messages according to the timer in the election stage, and the time of the election timer is set to be 60s + K/N; when the fault such as downtime occurs to the Leader node, each node starts the emergency main selection timer after the countdown of the heartbeat timer is finished, and the time of the emergency main selection timer is set to be K/N.
Further, a consensus selection main process is started:
specifically, (1) if the network environment is unreliable, the common identification selection is performed under the condition that the loader node is down:
if the Leader node goes down, other Followerers in the network cannot receive heartbeat information sent by the Leader node; and after the countdown of the heartbeat timer is finished, starting an emergency main selection timer through a Follower node, after the countdown of the emergency main selection timer is finished, sending a main selection message by a node which needs to be selected as a main node in an competitive way, changing the node state into Candidate, and starting a consensus main selection process.
(2) If the Leader node is not down, selecting the main node:
firstly, the initial state of each network node is a Follower, after the countdown of each node selection timer is finished, the node state after the countdown is finished is changed into a Candidate, then election is started, messages in the network are collected and packaged, meanwhile, calculation and judgment are carried out according to S4, and if the random number Nonce value meets a target value, the packaged Internet of things data and the random number Nonce value are sent to other nodes.
Verifying the judgment result of the step S4 by other nodes in the network, changing the state of the node from Candidate to Leader if the verification is passed, simultaneously allocating a new term to the Leader node, sending a heartbeat message to all Follows after each short time to keep the states of all the nodes, and resetting the heartbeat timer after the Follows receive the heartbeat message of the Leader node;
setting the master selection timer to be 60s + K/N, finishing countdown of the Follower node master selection timer in the network after about 1 minute, and then initiating a new round of master selection activities, wherein the following activity flows are as follows: and after the countdown of each node selection timer is finished, the node state after the countdown is finished is changed into Candidate, election is started, and data of the Internet of things in the network are collected and packaged.
Further, the node which firstly finds the random number meeting the set difficulty is selected as the consensus master node.
Still further, RAFT log replication is performed, which comprises the steps of:
(1) submitting an instruction (such as SET 5) to a Leader node through a Client, and writing the instruction into a local log after the Leader node receives the instruction; this instruction is in the "uncoordinated" State and the State Machine (State Machine) will not execute the instruction, as shown in fig. 3.
(2) The Leader node copies the instruction (SET 5) to other nodes concurrently and waits for the other nodes to write the instruction into the log; if some nodes fail to write or are slow at the moment, the Leader node will retry all the time until all the nodes write the instructions into the local log; the Leader node then submits the instruction to the state machine (i.e., the instruction is executed by the state machine) and returns the result to the Client, as shown in fig. 4.
After the Leader node submits the instruction, the next heartbeat packet contains a message for informing other nodes of submitting the instruction, the other nodes apply the instruction to the state machine after receiving the message of the Leader node, and finally, the log of each node keeps consistency; the Leader node records the maximum log index that has been committed, and then the subsequent heartbeat and log replication requests (application Entries) carry the maximum log index, so that other nodes know which instructions have been committed, and can enable a State Machine (State Machine) to execute the instructions in the log, so that the State Machine data of all nodes are kept consistent, as shown in fig. 5.
Example 2
In order to verify and explain the technical effect adopted in the method, the embodiment selects the traditional Raft consensus algorithm and adopts the method to perform comparison test, and compares the test results by means of scientific demonstration to verify the real effect of the method.
The traditional technical scheme is as follows: the traditional RAFT consensus algorithm has the defects of low safety, serious centralization, complex communication flow and the like by voting for election of a main node through simple multiple communications.
In order to verify that the method has the advantages of higher safety and low operation and maintenance cost compared with the traditional method, in the embodiment, the consensus efficiency of the main node is selected through simple repeated communication voting by adopting the traditional RAFT consensus algorithm, and the consensus efficiency of the main node is measured and compared in real time by adding the flow parameter into the distributed system and performing verification calculation respectively.
And (3) testing environment: a distributed system is simulated on a simulation platform, a peer-to-peer network with 10 nodes is used as a test sample, and test result data are obtained by utilizing multiple communication votes of a traditional method respectively. By adopting the method, the flow parameter acquisition and consensus verification calculation are started to realize the simulation test of the method, and the simulation data is obtained according to the experimental result. In each method, 5 groups of data are tested, the consensus efficiency time and the consensus accuracy of each group of data are calculated and obtained, and the results are compared with the actual consensus efficiency time and the consensus accuracy input by simulation, and are shown in fig. 6 and 7.
It can be seen from the figure that the actual consensus efficiency time of the method is less than that of the traditional Raft consensus algorithm, and the consensus accuracy is higher.
It should be noted that the above-mentioned embodiments are only for illustrating the technical solutions of the present invention and not for limiting, and although the present invention has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that modifications or equivalent substitutions may be made on the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, which should be covered by the claims of the present invention.

Claims (6)

1. A Raft consensus method applicable to the Internet of things is characterized in that: comprises the steps of (a) preparing a mixture of a plurality of raw materials,
the method comprises the steps that internet of things data in a distributed network are collected in real time through internet of things collection equipment, and the internet of things data are cached in an internet of things gateway;
packaging the Internet of things data in the Internet of things gateway within 60s + K/N, and counting the packaged data traffic; k is a constant, and N is the size of data traffic received by each node in unit time;
calculating a random number Nonce value based on a random number function of a linear congruence algorithm and an SHA-256 algorithm;
dynamically adjusting the selection difficulty according to the data flow parameters to further determine a target value and judge whether the Nonce value meets the target value;
if the random number Nonce value meets the target value, reserving the random number Nonce value; otherwise, updating the random number Nonce value, and continuously judging whether the updated random number Nonce value meets the target value;
designing a timer and starting a consensus selection main process, selecting a consensus main node according to a random number Nonce value meeting a target value, and copying an RAFT log;
wherein the dynamic adjustment of the election difficulty comprises,
designing a difficulty dynamic adjusting function, and dynamically adjusting the selection master difficulty through the difficulty dynamic adjusting function, wherein the difficulty dynamic adjusting function is as follows:
Figure FDA0003606550410000011
wherein D is01, d (h) is the difficulty of the block;
Figure FDA0003606550410000012
the difficulty of the previous block;
Figure FDA0003606550410000013
a block difficulty function is adjusted for self-adaptation; hiIs the current block number;
the adaptively adjusting the block out difficulty function includes,
Figure FDA0003606550410000014
Figure FDA0003606550410000015
wherein χ is the unit of adjustment,
Figure FDA0003606550410000016
is the adjusted coefficient; the lower bound of the self-adaptive adjusting block outlet difficulty function is D0The upper bound is-99; hs is the time when the current block is generated,
Figure FDA0003606550410000017
a parent block timestamp;
the judgment conditions are as follows:
Hash(Rand(h，n))≤N/D(H)
wherein h and n are input, namely a block Header hash value and a Nonce value in a Header; n is a flow value received by the node; N/D (H) is the target value.
2. The Raft consensus method applicable to the internet of things of claim 1, wherein: the calculating of the random number Nonce value may include,
the expression of the random number function based on the linear congruence algorithm is as follows:
(Ni+1)＝(a*Ni+b)Mod M
wherein i is 0, 1, …, M-1; m is a current timestamp; n is the random number Nonce value, a is a large prime number, and b is a constant.
3. The Raft consensus method applicable to the internet of things of claim 2, wherein: the design timer includes a timer that is configured to,
the timers comprise a heartbeat timer, a master selection timer and an emergency master selection timer;
setting the time of the heartbeat timer to be 150ms to 300 ms; setting the time of the master timer to be 60s + K/N; and setting the time of the emergency master timer to be K/N.
4. A Raft consensus method applicable to the Internet of things as claimed in claim 3, wherein: also comprises the following steps of (1) preparing,
the common identification selection can be performed under the condition that the Leader node is not down, and the common identification selection main flow is started under the condition that the network environment is unreliable and the Leader node is down.
5. The Raft consensus method applicable to the Internet of things as claimed in claim 4, wherein: the RAFT log replication includes the steps of,
submitting an instruction to the Leader node through a Client side, and writing the instruction into a local log after the Leader node receives the instruction;
the Leader node copies the instruction to other nodes concurrently and waits for the other nodes to write the instruction into the local log;
and until all the instructions are written into the local log, the Leader node submits the instructions to a state machine, and then the state machine returns the execution result to the Client.
6. The Raft consensus method applicable to the Internet of things as claimed in claim 5, wherein: selecting the consensus master node comprises selecting the consensus master node,
and taking the node which generates the first random number Nonce value meeting the requirement of the target value as the consensus main node.
CN202110882162.2A 2021-08-02 2021-08-02 Raft consensus method applicable to Internet of things Active CN113630455B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110882162.2A CN113630455B (en) 2021-08-02 2021-08-02 Raft consensus method applicable to Internet of things

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110882162.2A CN113630455B (en) 2021-08-02 2021-08-02 Raft consensus method applicable to Internet of things

Publications (2)

Publication Number Publication Date
CN113630455A CN113630455A (en) 2021-11-09
CN113630455B true CN113630455B (en) 2022-06-21

Family

ID=78382230

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110882162.2A Active CN113630455B (en) 2021-08-02 2021-08-02 Raft consensus method applicable to Internet of things

Country Status (1)

Country Link
CN (1) CN113630455B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114726856A (en) * 2022-02-28 2022-07-08 重庆市先进区块链研究院 Self-adaptive master selection method based on Raft
CN115051985B (en) * 2022-04-01 2024-01-12 深圳瑞泰信资讯有限公司 Data consensus method of Bayesian-preemption fault-tolerant consensus protocol based on dynamic nodes
CN115842767B (en) * 2022-09-07 2024-04-23 湖北工业大学 Internet of things equipment cluster cooperation method and system based on consensus algorithm

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111078787A (en) * 2019-11-11 2020-04-28 重庆邮电大学 Block chain consensus method based on random number mapping
CN111953490A (en) * 2020-08-31 2020-11-17 上海雷龙信息科技有限公司 Digital signature method and system based on block chain technology
CN112527647A (en) * 2020-12-15 2021-03-19 浙江大学 NS-3-based Raft consensus algorithm test system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11362808B2 (en) * 2019-12-06 2022-06-14 Sasken Technologies Ltd Method and system for consensus in a permissioned blockchain
CN112788137A (en) * 2021-01-06 2021-05-11 平衡机器科技(深圳)有限公司 Alliance chain consensus method based on RAFT algorithm

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111078787A (en) * 2019-11-11 2020-04-28 重庆邮电大学 Block chain consensus method based on random number mapping
CN111953490A (en) * 2020-08-31 2020-11-17 上海雷龙信息科技有限公司 Digital signature method and system based on block chain technology
CN112527647A (en) * 2020-12-15 2021-03-19 浙江大学 NS-3-based Raft consensus algorithm test system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
面向物联网的联盟链高效共识机制研究;任英琦;《中国优秀硕士学位论文全文数据库信息科技辑》;20210415;全文 *

Also Published As

Publication number Publication date
CN113630455A (en) 2021-11-09

Similar Documents

Publication Publication Date Title
CN113630455B (en) Raft consensus method applicable to Internet of things
CN112039964B (en) Node reputation consensus method based on block chain
Yun et al. DQN-based optimization framework for secure sharded blockchain systems
US9529923B1 (en) Methods and apparatus for a distributed database within a network
US9390154B1 (en) Methods and apparatus for a distributed database within a network
Yu et al. Proof-of-QoS: QoS based blockchain consensus protocol
CN110945548A (en) Computer-implemented system and method for managing large distributed storage pools in a blockchain network
US20240111782A1 (en) Methods and apparatus for a distributed database within a network
CN112632013A (en) Data security credible sharing method and device based on federal learning
CN106899681A (en) The method and server of a kind of information pushing
KR102337760B1 (en) Apparatus and method for adaptively managing sharded blockchain network based on Deep Q Network
Yuan et al. Efficient Byzantine consensus mechanism based on reputation in IoT blockchain
Zhao et al. Evaluating DAG-based blockchains for IoT
CN106878382A (en) Dynamically change the method and device of cluster scale in a kind of distributed arbitration program cluster
CN113259179A (en) Byzantine fault-tolerant consensus method and system based on node scoring
WO2018224925A1 (en) Distributed storage network
CN113992526A (en) Credibility calculation-based alliance chain cross-chain data fusion method
Masood et al. Consensus algorithms in distributed ledger technology for open environment
CN115865943A (en) Self-adaptive dynamic cross-chain consensus mechanism selection method
Gao et al. Improved byzantine fault-tolerant algorithm based on alliance chain
Georgiou et al. Implementing three exchange read operations for distributed atomic storage
Byrenheid et al. Attack resistant leader election in social overlay networks by leveraging local voting
CN115834512A (en) Data sharing method, system, electronic equipment and storage medium
Truong et al. BFLMeta: Blockchain-Empowered Metaverse with Byzantine-Robust Federated Learning
Ren et al. Improved PBFT consensus algorithm based on node role division

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