CN116032940B - Block chain witness consensus method, device, equipment and medium based on downtime tolerance - Google Patents

Block chain witness consensus method, device, equipment and medium based on downtime tolerance Download PDF

Info

Publication number
CN116032940B
CN116032940B CN202310132976.3A CN202310132976A CN116032940B CN 116032940 B CN116032940 B CN 116032940B CN 202310132976 A CN202310132976 A CN 202310132976A CN 116032940 B CN116032940 B CN 116032940B
Authority
CN
China
Prior art keywords
block
voting
witness
node
height
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
CN202310132976.3A
Other languages
Chinese (zh)
Other versions
CN116032940A (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.)
Anhui Zhongke Lattice Technology Co ltd
Original Assignee
Anhui Zhongke Lattice Technology 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 Anhui Zhongke Lattice Technology Co ltd filed Critical Anhui Zhongke Lattice Technology Co ltd
Priority to CN202310132976.3A priority Critical patent/CN116032940B/en
Publication of CN116032940A publication Critical patent/CN116032940A/en
Application granted granted Critical
Publication of CN116032940B publication Critical patent/CN116032940B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/30Computing systems specially adapted for manufacturing

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention relates to the technical field of blockchains, and discloses a blockchain witness consensus method, device, equipment and medium based on downtime tolerance, wherein the method comprises the following steps: after receiving the blocks broadcasted by the packaging nodes, voting the blocks at each height by the witness nodes to obtain the node voting quantity at the current height; when the node voting number under the current height reaches a preset threshold value, constructing a voting tree according to the node voting number and the blocks under the current height; determining a target ancestor block according to the voting tree; recursion the parent blocks at the current height according to rules according to the target ancestor blocks for the next round of consensus blocks; through the mode, according to the bifurcation of the packing nodes at the same height, the bifurcation is consistent, so that the target main chain is determined, meanwhile, the father block on the target main chain is confirmed, and the block is discharged after the father block, so that the problem of downtime tolerance can be effectively solved, the communication complexity is reduced during downtime, and the broadcasting speed of the block is improved.

Description

Block chain witness consensus method, device, equipment and medium based on downtime tolerance
Technical Field
The invention relates to the technical field of blockchains, in particular to a blockchain witness consensus method, device, equipment and medium based on downtime tolerance.
Background
With the continuous development of blockchain technology, the blockchain brings convenience to the work and life of people, for example, when the fault tolerance rate of downtime possibly existing in the blockchain nodes is 3f+1, the conventional witness consensus algorithm is used for solving the problem of chain bifurcation when f proportional nodes (namely 2f+1 effective voting nodes) are allowed to be in fault downtime, and determining that a main chain, for example, paxos, raft and PBFT, often have main selection processes, the main nodes are used for pushing state changes, and when the conventional witness consensus algorithm is used, the condition of downtime occurs, so that new main nodes need to be reelected, but the information complexity in the election process is higher, the view switching is complex, and the speed of broadcasting in the blocks is slower.
The foregoing is provided merely for the purpose of facilitating understanding of the technical solutions of the present invention and is not intended to represent an admission that the foregoing is prior art.
Disclosure of Invention
The invention mainly aims to provide a block chain witness consensus method, device, equipment and medium based on downtime tolerance, and aims to solve the technical problems of high communication complexity and low block broadcasting speed of a consensus algorithm in the prior art when downtime occurs.
In order to achieve the above purpose, the invention provides a block chain witness consensus method based on downtime tolerance, which comprises the following steps:
after receiving the blocks broadcasted by the packaging nodes, voting the blocks at each height by the witness nodes to obtain the node voting quantity at the current height;
when the node voting number under the current height is a preset threshold value, constructing a voting tree according to the node voting number under the current height and the block;
determining a target ancestor block according to the voting tree;
and recursively obtaining a parent block at the current height according to the target ancestor block according to rules for the next round of consensus blocks.
Optionally, after receiving the blocks broadcasted by the packaging node, the witness node votes the blocks under each height, and before obtaining the number of node votes under the current height, the method further includes:
when downtime occurs, qualified packaging nodes with the same height are obtained;
judging whether the packing node starts packing transaction or not;
after the packing node starts the packing transaction, a corresponding block is obtained;
the block is broadcast to a number of witness nodes throughout the network.
Optionally, after receiving the blocks broadcasted by the packaging node, voting the blocks at each height by the witness node to obtain the node voting number at the current height, including:
after receiving the block broadcast by the packing node, extracting a first block received by the witness node;
voting a first block at each height by the witness node;
and counting the votes of the first block to obtain the node voting number under the current height.
Optionally, after receiving the blocks broadcasted by the packaging node, the witness node votes on the blocks under each height to obtain the number of node votes under the current height, and then the method further includes:
and counting the block votes under the current height by the witness node when the number of the node votes under the current height does not reach a preset threshold.
Optionally, the determining the target ancestor block according to the voting tree includes:
obtaining the voting number of each sub-block under the current height according to the voting tree;
starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree to obtain the voting number of the ancestor block under each height;
and determining the target ancestor block when the voting number of the ancestor block under a certain height in the heights is larger than a preset threshold for the first time.
Optionally, after the voting numbers of the sub-blocks at the current height are started and accumulated upwards based on the branch structure of the voting tree, the method further includes:
and returning to the step of starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree when the voting number of the ancestor block under each height does not reach the preset threshold.
Optionally, recursively finding a parent block at the current height according to the target ancestor block according to a rule for a next round of consensus blocks, including:
determining a parent block for a next round of consensus blocks in the current height from the target ancestor block recursively downward in height;
and then the block is exported after the next round of parent block.
In addition, in order to achieve the above purpose, the invention also provides a block chain witness consensus device based on downtime tolerance, the block chain witness consensus device based on downtime tolerance comprises:
the voting module is used for voting the blocks at each height by the witness node after receiving the blocks broadcast by the packaging nodes, so as to obtain the node voting quantity at the current height;
the construction module is used for constructing a voting tree according to the node voting number under the current height and the block when the node voting number under the current height is a preset threshold value;
the determining module is used for determining a target ancestor block according to the voting tree;
and the recursion module is used for recursively obtaining a parent block at the current height according to the target ancestor block according to rules and then using the parent block for the next round of consensus blocks.
In addition, in order to achieve the above purpose, the invention further provides a block chain witness consensus device based on downtime tolerance, the block chain witness consensus device based on downtime tolerance comprises: the system comprises a memory, a processor and a downtime-tolerant based blockchain witness consensus program stored on the memory and executable on the processor, wherein the downtime-tolerant based blockchain witness consensus program is configured to implement the downtime-tolerant based blockchain witness consensus method.
In addition, in order to achieve the above object, the present invention further provides a storage medium, on which a block chain witness consensus program based on downtime tolerance is stored, where the block chain witness consensus program based on downtime tolerance implements the block chain witness consensus method based on downtime tolerance as described above when executed by a processor.
According to the block chain witness consensus method based on downtime tolerance, after receiving blocks broadcast by package nodes, voting is carried out on the blocks at each height by witness nodes, so that the node voting number at the current height is obtained; when the node voting number under the current height reaches a preset threshold, constructing a voting tree according to the node voting number under the current height and the block; determining a target ancestor block according to the voting tree; recursion the parent blocks at the current height according to rules according to the target ancestor blocks for the next round of consensus blocks; through the mode, according to the bifurcation of the packing nodes at the same height, the bifurcation is consistent, so that the target main chain is determined, meanwhile, the father block on the target main chain is confirmed, and the block is discharged after the father block, so that the problem of downtime tolerance can be effectively solved, the communication complexity is reduced during downtime, and the broadcasting speed of the block is improved.
Drawings
FIG. 1 is a schematic diagram of a block chain witness consensus device based on downtime tolerance for a hardware operating environment according to an embodiment of the present invention;
FIG. 2 is a flowchart of a first embodiment of a blockchain witness consensus method based on downtime tolerance according to the present invention;
FIG. 3 is a schematic diagram of a voting tree structure according to an embodiment of a blockchain witness consensus method based on downtime tolerance according to the present invention;
FIG. 4 is a flowchart of a second embodiment of a blockchain witness consensus method based on downtime tolerance according to the present invention;
fig. 5 is a schematic diagram of a functional module of a first embodiment of a blockchain witness consensus device based on downtime tolerance according to the present invention.
The achievement of the objects, functional features and advantages of the present invention will be further described with reference to the accompanying drawings, in conjunction with the embodiments.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
Referring to fig. 1, fig. 1 is a schematic structural diagram of a blockchain witness consensus device based on downtime tolerance in a hardware operating environment according to an embodiment of the present invention.
As shown in fig. 1, the blockchain witness consensus device based on downtime tolerance may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a Wireless interface (e.g., a Wireless-Fidelity (Wi-Fi) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) Memory or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.
Those skilled in the art will appreciate that the architecture shown in fig. 1 does not constitute a limitation of a blockchain witness consensus device based on downtime tolerance, and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.
As shown in FIG. 1, an operating system, a network communication module, a user interface module, and a blockchain witness consensus program based on downtime tolerance may be included in memory 1005 as one storage medium.
In the blockchain witness consensus device based on downtime tolerance shown in fig. 1, the network interface 1004 is mainly used for data communication with a network integration platform workstation; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 in the block chain witness consensus device based on the downtime tolerance can be arranged in the block chain witness consensus device based on the downtime tolerance, and the block chain witness consensus device based on the downtime tolerance calls the block chain witness consensus program based on the downtime tolerance and stored in the memory 1005 through the processor 1001, and executes the block chain witness consensus method based on the downtime tolerance.
Based on the hardware structure, the embodiment of the block chain witness consensus method based on downtime tolerance is provided.
Referring to fig. 2, fig. 2 is a flowchart illustrating a first embodiment of a block chain witness consensus method based on downtime tolerance according to the present invention.
In a first embodiment, the downtime tolerance-based blockchain witness consensus method includes the steps of:
step S10, after receiving the blocks broadcasted by the packaging nodes, voting is carried out on the blocks at each height by the witness nodes, and the node voting quantity at the current height is obtained.
It should be noted that, the execution body of the embodiment is a blockchain witness consensus device based on downtime tolerance, and may be other devices that can implement the same or similar functions, for example, a blockchain witness consensus mechanism, which is not limited in this embodiment, and in this embodiment, the blockchain witness consensus mechanism is taken as an example for illustration.
It should be understood that the number of node votes at the current altitude refers to the number of votes performed on the blocks at each altitude, after the packing node generates the blocks in the packing transaction, the blocks are broadcasted, and the witness node performs voting broadcasting and voting on the blocks at each altitude after receiving the blocks broadcasted by the packing node, so as to obtain the number of node votes at the current altitude, and it should be emphasized that all witness nodes can vote only once at the same altitude, and only after (2f+1) votes at the previous altitude are received, the votes may be performed at the current altitude. If the witness node votes twice at the same altitude, it may be noted as bad.
Further, step S10 includes: after receiving the block broadcast by the packing node, extracting a first block received by the witness node; voting a first block at each height by the witness node; and counting the votes of the first block to obtain the node voting number under the current height.
It can be understood that, since each witness node signs and votes only the first received block, that is, the first block, after the block broadcast by the packing node is received, the first block is extracted from the blocks broadcast by the packing node, then the witness node votes the first block at each height, counts the number of node votes at the current height, and when downtime occurs, the blocks at the same height allow a plurality of qualified packing nodes to appear, resulting in bifurcation, and at the moment, the packing nodes of the packing transaction are all qualified.
Further, after step S10, the method further includes: and counting the block votes under the current height by the witness node when the number of the node votes under the current height does not reach a preset threshold.
It will be appreciated that re-voting the votes for the block at the current elevation is required when it is determined that the number of node votes at the current elevation has not reached the preset threshold.
And S20, when the node voting number under the current height reaches a preset threshold, constructing a voting tree according to the node voting number under the current height and the block.
It may be understood that, when the number of node votes at the current height is obtained, it is determined whether the number of node votes at the current height reaches a preset threshold, if yes, the number of node votes at the current height is traversed to construct a voting tree, where the preset threshold may be 2f+1, and referring to fig. 3, fig. 3 is a schematic diagram of a voting tree structure, specifically: the height comprises h, h-1, h-2 and h-3, h is the current height, h-1, h-2 and h-3 are numbers smaller than h, namely in the voting tree, the number is equal to h at the bottommost layer, the ancestor block of a certain height h-t is at the upper t heights of the h layer, wherein B3-X is a father node of B4-X, each block in the voting tree is a node, the nodes comprise the corresponding block, the voting set and all child nodes of the next height, for example, after (2f+1) votes under the current height h are received, the voting tree is traversed, and the voting tree is constructed.
Step S30, determining a target ancestor block according to the voting tree.
Further, step S30 includes: obtaining the voting number of each sub-block under the current height according to the voting tree; starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree to obtain the voting number of the ancestor block under each height; and determining the target ancestor block when the voting number of the ancestor block under a certain height in the heights is larger than a preset threshold for the first time.
It can be understood that, firstly, the number of votes of each sub-block at the current height is accumulated upwards based on the branch structure of the voting tree to form the number of votes of the leaf nodes of the voting tree, then the voting tree is traversed to the next height (h-1 height), then whether the number of votes of the next height (h-1 height) is the preset number of votes is judged, if yes, recursion is ended, B2-2 is confirmed as the first block meeting 2f+1, and meanwhile, the target ancestor block B1-1 is confirmed, and the confirmation process needs to meet a confirmation rule, specifically: if a node receives 2f+1 votes for a branch, i.e., the branch is validated, then all subsequent blocks continue from the branch, the target ancestor block that is the branch will be validated, and no other blocks at the target ancestor block height will be validated. The earliest ancestor block under the branch, and all of its undetermined ancestor blocks, are thus identified as target ancestor blocks.
Further, after the voting numbers of the sub-blocks at the current height are started and accumulated upwards based on the branch structure of the voting tree, the method further includes: and returning to the step of starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree when the voting number of the ancestor block under each height does not reach the preset threshold.
It will be appreciated that when it is determined that the number of votes for an ancestor block at each height does not reach the preset threshold, then it is necessary to restart with the number of votes for each sub-block at the current height and accumulate the number of votes upwardly based on the branching structure of the voting tree.
Step S40, recursively finding out the parent blocks at the current height according to the rules according to the target ancestor blocks for the next round of consensus blocks.
It will be appreciated that when the branches at the same height and different from each other according to the packing node are consistent, the target main chain is determined, then the parent block on the target main chain is determined, and the blocks are removed from the parent block in the next round, and the determination of the target main chain is completed by the recursion module, and the determination of the parent block on the main chain is completed by the determination module, and the recursion module completes recursion of the parent block according to the target ancestor block.
With continued reference to FIG. 3, the determined target backbone may be B1-B2-B3-B4-4, with witness histories including, but not limited to, security analysis and specific witness processes, where security analysis refers to nodes in the network that may be down due to network disruption, network fragmentation, but whose node nature is still a honest node, and no dislike outside of the constraint range. Even in an asynchronous network environment, the consensus is completed when the final transmission of the message arrives, namely if more than f nodes cannot achieve communication with the node, the consensus of the node is stopped or the consensus speed is reduced only, and the safety of the consensus is not affected.
Further, step S40 includes: recursion downwards from the target ancestor block according to the height, determining a parent block for the next round of consensus blocks at the current height; and then the block is exported after the next round of parent block.
It should be appreciated that after the target ancestor block is determined, recursion is performed downward from the target ancestor block, the block that votes the most in the descendant nodes in the next height is continuously selected until the block at the current height, the block at the current height is selected as the parent block, and then the block is ejected from the parent block in the next round.
In the embodiment, after receiving a block broadcast by a packaging node, voting is performed on the block at each height by a witness node to obtain the node voting number at the current height; when the node voting number under the current height reaches a preset threshold, constructing a voting tree according to the node voting number under the current height and the block; determining a target ancestor block according to the voting tree; recursion the parent blocks at the current height according to rules according to the target ancestor blocks for the next round of consensus blocks; through the mode, according to the bifurcation of the packing nodes at the same height, the bifurcation is consistent, so that the target main chain is determined, meanwhile, the father block on the target main chain is confirmed, and the block is discharged after the father block, so that the problem of downtime tolerance can be effectively solved, the communication complexity is reduced during downtime, and the broadcasting speed of the block is improved.
In an embodiment, as shown in fig. 4, a second embodiment of the blockchain witness consensus method based on downtime tolerance is provided based on the first embodiment, and before step S10, the method further includes:
and S001, when downtime occurs, acquiring qualified packaging nodes which appear at the same height.
It should be understood that the packing node refers to a qualified packing node that appears in the same block when a downtime occurs, and that multiple qualified packing nodes are allowed to appear in the same height when a downtime occurs, which may cause bifurcation to occur.
Step S002, determining whether the packaging node starts a packaging transaction.
Step S003, after the packing node starts the packing transaction, a corresponding block is obtained.
It should be understood that after obtaining the plurality of qualified packing nodes, it is further required to determine whether the packing nodes start packing the transaction, and if so, obtain the block corresponding to the transaction.
Step S004, broadcasting the block to a plurality of witness nodes in the whole network.
It will be appreciated that after the transaction is packed into corresponding chunks, the chunks are broadcast to a number of witness nodes throughout the network, which may be 3f+1.
In the embodiment, when downtime occurs, qualified packaging nodes at the same height are obtained; judging whether the packing node starts packing transaction or not; after the packing node starts the packing transaction, a corresponding block is obtained; broadcasting the block to a plurality of witness nodes of the whole network; through the mode, after the qualified packing nodes which are in downtime and appear in the same block start to pack the transaction, the block corresponding to the transaction is obtained, and then the block is broadcasted to a plurality of witness nodes of the whole network, so that the efficiency of broadcasting the block can be effectively improved.
In addition, the embodiment of the invention also provides a storage medium, wherein the storage medium is stored with a block chain witness consensus program based on downtime tolerance, and the block chain witness consensus program based on downtime tolerance realizes the steps of the block chain witness consensus method based on downtime tolerance when being executed by a processor.
Because the storage medium adopts all the technical schemes of all the embodiments, the storage medium has at least all the beneficial effects brought by the technical schemes of the embodiments, and the description is omitted here.
In addition, referring to fig. 5, an embodiment of the present invention further provides a blockchain witness consensus device based on downtime tolerance, where the blockchain witness consensus device based on downtime tolerance includes:
and the voting module 10 is used for voting the blocks at each height by the witness node after receiving the blocks broadcast by the packaging nodes, so as to obtain the node voting quantity at the current height.
And the construction module 20 is configured to construct a voting tree according to the number of node votes at the current height and the block when the number of node votes at the current height is a preset threshold.
A determining module 30 for determining a target ancestor block from the voting tree.
A recursion module 40, configured to recursively obtain a parent block at the current height according to the target ancestor block according to a rule, for a next round of consensus blocks.
In the embodiment, after receiving a block broadcast by a packaging node, voting is performed on the block at each height by a witness node to obtain the node voting number at the current height; when the node voting number under the current height reaches a preset threshold, constructing a voting tree according to the node voting number under the current height and the block; determining a target ancestor block according to the voting tree; recursion the parent blocks at the current height according to rules according to the target ancestor blocks for the next round of consensus blocks; through the mode, according to the bifurcation of the packing nodes at the same height, the bifurcation is consistent, so that the target main chain is determined, meanwhile, the father block on the target main chain is confirmed, and the block is discharged after the father block, so that the problem of downtime tolerance can be effectively solved, the communication complexity is reduced during downtime, and the broadcasting speed of the block is improved.
It should be noted that the above-described working procedure is merely illustrative, and does not limit the scope of the present invention, and in practical application, a person skilled in the art may select part or all of them according to actual needs to achieve the purpose of the embodiment, which is not limited herein.
In addition, technical details not described in detail in the present embodiment may refer to the blockchain witness consensus method based on downtime tolerance provided in any embodiment of the present invention, which is not described herein.
Furthermore, it should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. Read Only Memory)/RAM, magnetic disk, optical disk) and including several instructions for causing a terminal device (which may be a mobile phone, a computer, an integrated platform workstation, or a network device, etc.) to perform the method according to the embodiments of the present invention.
The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.

Claims (9)

1. The block chain witness consensus method based on downtime tolerance is characterized by comprising the following steps of:
after receiving the blocks broadcasted by the packaging nodes, voting the blocks at each height by the witness nodes to obtain the node voting quantity at the current height;
when the node voting number under the current height reaches a preset threshold, constructing a voting tree according to the node voting number under the current height and the block;
determining a target ancestor block according to the voting tree;
recursion the parent blocks at the current height according to rules according to the target ancestor blocks for the next round of consensus blocks;
the determining a target ancestor block according to the voting tree comprises:
obtaining the voting number of each sub-block under the current height according to the voting tree;
starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree to obtain the voting number of the ancestor block under each height;
and determining the target ancestor block when the voting number of the ancestor block under a certain height in the heights is larger than a preset threshold for the first time.
2. The block chain witness consensus method based on downtime tolerance of claim 1, wherein after receiving a block broadcast by a packaging node, voting the block at each height by a witness node, and before obtaining the node voting number at the current height, further comprising:
when downtime occurs, qualified packaging nodes with the same height are obtained;
judging whether the packing node starts packing transaction or not;
after the packing node starts the packing transaction, a corresponding block is obtained;
the block is broadcast to a number of witness nodes throughout the network.
3. The block chain witness consensus method based on downtime tolerance of claim 1, wherein after receiving a block broadcast by a packaging node, voting the block at each height by a witness node to obtain a node voting number at the current height, comprising:
after receiving the block broadcast by the packing node, extracting a first block received by the witness node;
voting a first block at each height by the witness node;
and counting the votes of the first block to obtain the node voting number under the current height.
4. The block chain witness consensus method based on downtime tolerance of claim 1, wherein after receiving a block broadcast by a packaging node, voting the block at each height by a witness node to obtain a node voting number at a current height, further comprising:
and counting the block votes under the current height by the witness node when the number of the node votes under the current height does not reach a preset threshold.
5. The block chain witness consensus method based on downtime tolerance of claim 1, wherein after starting with the number of votes of each sub-block at the current height and accumulating up based on the branching structure of the voting tree, obtaining the number of votes of an ancestor block at each height, further comprising:
and returning to the step of starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree when the voting number of the ancestor block under each height does not reach the preset threshold.
6. The downtime tolerance-based blockchain witness consensus method of claim 1, wherein the recursively developing parent blocks at a current elevation according to rules from the target ancestor blocks for a next round of consensus blocks, comprising:
recursion downwards from the target ancestor block according to the height, determining a parent block for the next round of consensus blocks at the current height;
and then the block is exported after the next round of parent block.
7. The utility model provides a block chain witness consensus device based on downtime tolerance, its characterized in that, block chain witness consensus device based on downtime tolerance includes:
the voting module is used for voting the blocks at each height by the witness node after receiving the blocks broadcast by the packaging nodes, so as to obtain the node voting quantity at the current height;
the construction module is used for constructing a voting tree according to the node voting number under the current height and the block when the node voting number under the current height is a preset threshold value;
the determining module is used for determining a target ancestor block according to the voting tree;
a recursion module for recursively finding out the parent blocks at the current height according to the rules according to the target ancestor blocks, and for identifying the blocks in the next round;
the determining a target ancestor block according to the voting tree comprises:
obtaining the voting number of each sub-block under the current height according to the voting tree;
starting with the voting number of each sub-block under the current height and accumulating upwards based on the branch structure of the voting tree to obtain the voting number of the ancestor block under each height;
and determining the target ancestor block when the voting number of the ancestor block under a certain height in the heights is larger than a preset threshold for the first time.
8. The utility model provides a block chain witness consensus equipment based on downtime tolerance, its characterized in that, block chain witness consensus equipment based on downtime tolerance includes: memory, a processor, and a downtime-tolerant based blockchain witness consensus program stored on the memory and executable on the processor, the downtime-tolerant based blockchain witness consensus program configured to implement the downtime-tolerant based blockchain witness consensus method of any one of claims 1 to 6.
9. A storage medium having stored thereon a downtime-tolerant blockchain witness consensus program that when executed by a processor implements the downtime-tolerant blockchain witness consensus method according to any one of claims 1 to 6.
CN202310132976.3A 2023-02-20 2023-02-20 Block chain witness consensus method, device, equipment and medium based on downtime tolerance Active CN116032940B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310132976.3A CN116032940B (en) 2023-02-20 2023-02-20 Block chain witness consensus method, device, equipment and medium based on downtime tolerance

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310132976.3A CN116032940B (en) 2023-02-20 2023-02-20 Block chain witness consensus method, device, equipment and medium based on downtime tolerance

Publications (2)

Publication Number Publication Date
CN116032940A CN116032940A (en) 2023-04-28
CN116032940B true CN116032940B (en) 2023-06-06

Family

ID=86074047

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310132976.3A Active CN116032940B (en) 2023-02-20 2023-02-20 Block chain witness consensus method, device, equipment and medium based on downtime tolerance

Country Status (1)

Country Link
CN (1) CN116032940B (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110298754A (en) * 2019-06-21 2019-10-01 杭州云象网络技术有限公司 A kind of common recognition method applied to block chain
CN110851537A (en) * 2019-11-28 2020-02-28 蒋勇 Consensus method based on block chain fragmentation technology
CN112187490A (en) * 2019-07-01 2021-01-05 深圳法大大网络科技有限公司 Byzantine fault-tolerant consensus method and system
WO2021017421A1 (en) * 2019-07-31 2021-02-04 创新先进技术有限公司 Blockchain state data recovery method and device, and electronic device
CN112527908A (en) * 2020-12-22 2021-03-19 深圳壹账通智能科技有限公司 Block chain network construction method, node adding method, medium and equipment
CN114090693A (en) * 2022-01-18 2022-02-25 安徽中科晶格技术有限公司 Byzantine fault-tolerant-based block chain witness consensus method, system, equipment and storage medium

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11202001989WA (en) * 2019-07-11 2020-04-29 Alibaba Group Holding Ltd Shared blockchain data storage
US11113677B1 (en) * 2020-01-14 2021-09-07 Hiro Systems Pbc Data processing using proof-of-transfer

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110298754A (en) * 2019-06-21 2019-10-01 杭州云象网络技术有限公司 A kind of common recognition method applied to block chain
CN112187490A (en) * 2019-07-01 2021-01-05 深圳法大大网络科技有限公司 Byzantine fault-tolerant consensus method and system
WO2021017421A1 (en) * 2019-07-31 2021-02-04 创新先进技术有限公司 Blockchain state data recovery method and device, and electronic device
CN110851537A (en) * 2019-11-28 2020-02-28 蒋勇 Consensus method based on block chain fragmentation technology
CN112527908A (en) * 2020-12-22 2021-03-19 深圳壹账通智能科技有限公司 Block chain network construction method, node adding method, medium and equipment
CN114090693A (en) * 2022-01-18 2022-02-25 安徽中科晶格技术有限公司 Byzantine fault-tolerant-based block chain witness consensus method, system, equipment and storage medium

Also Published As

Publication number Publication date
CN116032940A (en) 2023-04-28

Similar Documents

Publication Publication Date Title
CN110472107B (en) Multi-mode knowledge graph construction method, device, server and storage medium
CN110445653A (en) Network state prediction technique, device, equipment and medium
CN108805565B (en) Block chain based commitment presence proving method, device and readable storage medium
CN108647329B (en) User behavior data processing method and device and computer readable storage medium
CN111343127B (en) Method, device, medium and equipment for improving crawler recognition recall rate
CN111681049B (en) Processing method of user behavior, storage medium and related equipment
CN117422031B (en) Method and device for generating and simplifying test vector of ATPG (automatic Teller machine) system
CN111242784A (en) Block pre-packing method, block node, device and storage medium
CN107222511A (en) Detection method and device, computer installation and the readable storage medium storing program for executing of Malware
Ngampruetikorn et al. Bias, belief, and consensus: Collective opinion formation on fluctuating networks
CN107657286A (en) A kind of advertisement recognition method and computer-readable recording medium
CN116032940B (en) Block chain witness consensus method, device, equipment and medium based on downtime tolerance
CN111182332B (en) Video processing method, device, server and storage medium
CN108614843A (en) The appraisal procedure and device of web site contents
CN111260419A (en) Method and device for acquiring user attribute, computer equipment and storage medium
CN112650931B (en) Content recommendation method
US7752149B2 (en) Method and apparatus for determining the variable dependency
CN115640518A (en) Training of user recognition model, user recognition method and device
CN117331679A (en) Data reasoning method, device, equipment and storage medium
CN109740829A (en) Foodstuff transportation method, equipment, storage medium and device based on ant group algorithm
CN112396100A (en) Fine-grained classification model optimization method, system and related device
CN116644229B (en) Recommendation information excessive entertaining prediction method, device and server
CN114626340B (en) Behavior feature extraction method based on mobile phone signaling and related device
CN118573453B (en) Parameter verification and service fusing system and method of API gateway
CN103150471B (en) A kind of dialing rule matching process and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant