CN117579632A - Block consensus method, device, electronic equipment and storage medium - Google Patents

Block consensus method, device, electronic equipment and storage medium Download PDF

Info

Publication number
CN117579632A
CN117579632A CN202311542248.6A CN202311542248A CN117579632A CN 117579632 A CN117579632 A CN 117579632A CN 202311542248 A CN202311542248 A CN 202311542248A CN 117579632 A CN117579632 A CN 117579632A
Authority
CN
China
Prior art keywords
block
view
current
node
voting
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
Application number
CN202311542248.6A
Other languages
Chinese (zh)
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.)
Shanghai Lingshuzhonghe Information Technology Co ltd
Original Assignee
Shanghai Lingshuzhonghe Information 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 Shanghai Lingshuzhonghe Information Technology Co ltd filed Critical Shanghai Lingshuzhonghe Information Technology Co ltd
Priority to CN202311542248.6A priority Critical patent/CN117579632A/en
Publication of CN117579632A publication Critical patent/CN117579632A/en
Pending legal-status Critical Current

Links

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
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • Y—GENERAL 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
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The application discloses a block consensus method, a block consensus device, electronic equipment and a storage medium. The method specifically comprises the following steps: according to the increasing order of the views, the current master node in the current view acquires voting information of each verifier node in the previous view; if the voting information of the previous view acquired by the current master node exceeds a preset threshold, acquiring a block with the highest view number from each voting information; generating a current block according to the hash value of the block with the highest view number, current transaction information in the current view and the current view number; when the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number, the block is confirmed as a submittable block; the current blobs are proposed to each verifier node in the current view, and the verifier nodes of each current view are instructed to write the submittable blobs to the blockchain ledger. The technical scheme improves the overall consensus efficiency of the block chain.

Description

Block consensus method, device, electronic equipment and storage medium
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a block consensus method, a device, an electronic device, and a storage medium.
Background
With the great development of computer technology and big data technology, more and more online transactions and online data have security problems, and online transactions need to be guaranteed by a platform with decentralised data being difficult to tamper with, so that a blockchain technology is generated. The consensus is one of key technologies of the block chain, and only if the consensus is effectively achieved among all nodes in the block chain, the synchronization of the block chain and the safety of information can be ensured.
Currently, there are two general methods of block chain consensus, namely, a bayer fault-tolerant consensus and a breakdown fault-tolerant consensus (also called a non-bayer fault-tolerant consensus). The Bayesian fault-tolerant type consensus can support the Bayesian node error, but the network and time cost is high and the efficiency is low; crashed fault-tolerant class consensus is less network and time overhead, but cannot support Bayesian class errors. Although the crashed fault-tolerant type consensus cannot support the Bayesian error, in some alliance chain scenarios, the trust degree of each participant is high, and the crashed fault-tolerant type consensus is applicable. The technical characteristics of breakdown fault tolerance type consensus and block chains are fused, so that higher consensus efficiency can be obtained.
Disclosure of Invention
The application provides a block consensus method, a block consensus device, electronic equipment and a storage medium, so as to improve the block consensus efficiency.
According to a first aspect of the present application, there is provided a block consensus method applied to a current master node, the method comprising:
according to the increasing order of the views, the current master node in the current view acquires voting information of each verifier node in the previous view;
if the voting information of the previous view acquired by the current master node exceeds a preset threshold, acquiring a block with the highest view number from each voting information;
generating a current block according to the hash value of the block with the highest view number, current transaction information in the current view and the current view number;
when the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number, the block is confirmed as a submittable block;
the current blobs are proposed to each verifier node in the current view, and the verifier nodes of each current view are instructed to write the submittable blobs to the blockchain ledger.
According to a second aspect of the present application, there is provided a block consensus method applied in at least one verifier node, the method comprising:
Acquiring indication information of a block proposed by a main node of a current view and a submittable block;
if the indication information of the block proposed by the main node and the block which can be submitted in the current view is obtained in the first preset time, the confirmation information is normally received;
when the confirmation information is received normally, the proposed block is stored locally;
voting the block proposed by the main node of the current view to generate a voting message of the block;
and feeding back voting messages of the blocks to the master node of the next view, so that the master node of the next view determines whether the blocks are submittable blocks according to the voting messages.
According to a third aspect of the present application, there is provided a block consensus apparatus for use with a current master node, the apparatus comprising:
the voting verification module is used for acquiring voting information of each verifier node in the previous view by the current main node in the current view according to the increasing sequence of the views;
the block acquisition module is used for acquiring a block with the highest view number from each voting message when the voting message of the previous view acquired by the current master node exceeds a preset threshold;
the block generation module is used for generating a current block according to the hash value of the block with the highest view number, the current transaction information in the current view and the current view number;
The block confirming module is used for confirming the block as a submittable block when the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number;
and the block uplink module is used for proposing the current block to each verifier node in the current view and instructing the verifier node of each current view to write the submittable block into the blockchain ledger.
According to a fourth aspect of the present application, there is provided a block consensus apparatus for use in at least one verifier node, the apparatus comprising:
the indication information acquisition module is used for acquiring indication information of the block proposed by the main node of the current view and the block which can be submitted;
the information receiving judging module is used for confirming that the information is normally received if the indication information of the block proposed by the main node and the block which can be submitted in the current view is obtained in the first preset time;
the block local storage module is used for locally storing the proposed block when the confirmation information is received normally;
the voting message generation module is used for voting the block proposed by the main node of the current view to generate a voting message of the block;
and the voting information feedback module is used for feeding back voting information of the blocks to the master node of the next view so that the master node of the next view can determine whether the blocks are submittable blocks according to the voting information.
According to a fifth aspect of the present application, there is provided an electronic device comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the block consensus method according to an embodiment of the first aspect of the present application; and/or executing the block consensus method according to the embodiment of the second aspect of the present application.
According to a sixth aspect of the present application, there is provided a computer readable storage medium storing computer instructions for causing a processor to implement the block consensus method according to an embodiment of the first aspect of the present application when executed; and/or executing the block consensus method according to the embodiment of the second aspect of the present application.
According to the technical scheme, the current master node obtains the voting message of the previous view under the current view, the current master node is used as an assembler of the block, judges whether the block can be submitted according to the view number corresponding to the block included in the voting message, shares the current block which can be submitted to all verifier nodes, and can confirm that a certain block can reach consensus among all verifier nodes only through one round of communication on the basis of inheriting the previous round of voting message, so that the current block which can be submitted is uplink, the defect that the consensus communication is needed to reach twice for the certain block in the prior art, the consensus efficiency is slow is overcome, and the overall consensus efficiency of a block chain is further improved.
It should be understood that the description of this section is not intended to identify key or critical features of the embodiments of the application or to delineate the scope of the application. Other features of the present application will become apparent from the description that follows.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed 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 application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a flowchart of a block consensus method according to a first embodiment of the present application;
fig. 2 is a flowchart of a block consensus method according to a second embodiment of the present application;
FIG. 3 is a schematic diagram of a block consensus applicable to the third embodiment of the present application;
fig. 4 is a schematic structural diagram of a block consensus device according to a fourth embodiment of the present application;
fig. 5 is a schematic structural diagram of a block consensus device according to a fifth embodiment of the present application;
fig. 6 is a schematic structural diagram of an electronic device implementing a block consensus method according to an embodiment of the present application.
Detailed Description
In order to make the present application solution better understood by those skilled in the art, the following description will be made in detail and with reference to the accompanying drawings in the embodiments of the present application, it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, shall fall within the scope of the present application.
It should be noted that the terms "first," "second," and the like in the description and claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
Prior art schemes for block consensus will be briefly described before proceeding with an explanation of the embodiments of the present application: currently, when the block is commonly known, the node X serves as a master node, generates and proposes a block a, and sends the proposed block a to other nodes, i.e. verifier nodes, for voting, i.e. whether the block a is approved to pass. In the crash error model, at least one round of voting is required to agree on a block, and if all verifier nodes agree that the transaction a passes during one round of voting, the transaction a is approved by all nodes, and the block a can be directly written into the blockchain ledger. The master node X first communicates with the verifier node a round, sending proposed block a, which the verifier node cannot commit at this time, because it is not clear whether other verifier nodes would commit block a. After receiving replies from most verifier nodes, the master node communicates with the verifier nodes again, informs the verifier nodes that the block A just proposed by the master node has been approved by most verifier nodes, and can be submitted to the blockchain ledger, and the round of consensus is ended.
Of course, in the voting process, there are many times when the vote cannot pass completely, and there are some verifier nodes that do not recognize the block and transaction proposed by the master node, or that do not receive the vote reply from the verifier node because of a network error. At this point, a further round of voting is required. Each round of voting corresponds to a view: the voting of all nodes for the first time in the course of the round of consensus is not agreed as view 0 (the view 0 is the end of the round of consensus if the consensus is agreed, and the block chain account book is written); the voting process will be performed again as view 1. In view 0, node X as the master node proposal a is not voted for, and in view 1, it is converted to node Y as the master node to proposal the transaction. The master node Y in view 1 first needs to communicate with each verifier node in view 0 to obtain the voting result, a process commonly referred to as a view conversion protocol. At this point, there are two cases, the first, in view 0, most of the nodes agree on transaction a, then in view 2 node Y must propose again block a and deliver it to all verifier nodes for voting; second, in view 0, no majority of nodes agree on block a, then in view 1, node Y may propose a new transaction B and deliver it to all verifier nodes for voting to determine if block B can agree on the current round of voting. If the consensus is still not able to be reached in view 1, the system is switched to view 2, and the other nodes accept the main node identity proposal transaction, and so on until all the nodes can reach the consensus. However, the block consensus method is complex and lengthy, and requires a large amount of communication between nodes, resulting in long consensus time and low efficiency of block consensus.
Example 1
Fig. 1 is a flowchart of a block consensus method according to an embodiment of the present application, where the block consensus method may be applicable to a situation where each block in a block chain achieves consensus, and the method may be performed by a block consensus device, where the block consensus device may be implemented in a form of hardware and/or software, and the block consensus method may be applied to a current master node, and the block consensus device may be configured in an electronic device. As shown in fig. 1, the method includes:
s110, according to the increasing order of the views, the current master node in the current view acquires the voting information of each verifier node in the previous view.
Wherein, since the generation of blocks is sequential, block 0, block 1, block 2 … …, and so on are generated according to the order in which the nodes sequentially propose blocks. The views have unique view numbers, the view numbers are sequentially increased, each view has a unique master node, and each node can determine the current master node according to the current view number and a preset rule. The master node may make a proposal for the block at the current view, the previous view may be the view corresponding to the previous master node, and the verifier node may be any other node than the master node. The voting messages may be votes of approval or approval by the respective verifier nodes for the proposal of the master node, which may be sent to the master node for orchestration within one view. It will be appreciated that the master node in the previous view belongs to the verifier node in the current view and, as such, the current master node belongs to the verifier node in the previous view. And, the source of the voting message, such as from which verifier node, from which round of voting, i.e. marking the votes from which view, can be marked in the voting message, and distinguished by recording the view numbers for subsequent confirmation of the number of votes proposed.
And S120, if the voting message of the previous view acquired by the current master node exceeds a preset threshold, acquiring a block with the highest view number from each voting message.
It should be noted that, when the current master node acquires the voting information of the previous view, there is a preset threshold value to detect whether all normal voting information is collected (because there is a certain error information and data needs to be removed). And determining the block with the highest view number in the voting messages after the received voting messages reach the preset threshold value.
S130, generating a current block according to the hash value of the block with the highest view number, current transaction information in the current view and the current view number.
The current transaction information may be transaction content that the current master node wants to include in the block to be proposed, and will also become the content that the block is voted for. And generating the block which needs to be proposed by the current master node by assembling the hash value of the block with the highest view number, the current transaction information and the current view number. The content of the current block includes the hash value of the highest-view block in the previous view, which is equivalent to the current block pointing to the highest-view block in the previous view, and the highest-view block in the previous view is called the preamble block of the current block. The assembling block is performed in the current master node, and the method for assembling a block is not limited in this embodiment.
And S140, when the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number, the block is confirmed as a submittable block.
The decision to commit a block is based on whether all blocks in the voting message in the previous view acquired by the current master node are the same, i.e., whether there are verifier nodes in the previous view that have exceeded a certain threshold that commit the proposed block. And submitting the block under the condition that the obtained voting message comprises the same block and the view numbers belong to the previous view. This identified committed block is referred to as a committed block, it being understood that the committed block is the leading block of the currently assembled proposed block.
S150, proposing the current blocks to each verifier node in the current view, and instructing the verifier nodes of each current view to write the submittable blocks into the blockchain ledger.
After the current block is assembled by the current master node in the current view, the current block is shared to all current verifier nodes, namely the current block is proposed. And the current master node in the current view shares the submittable block confirmed in the previous step with the current verifier node, and informs all the verifier nodes to write the submittable block into the blockchain ledger book, thereby completing the uplink process of the submittable block.
According to the technical scheme, the current master node obtains the voting message of the previous view under the current view, and is used as an assembler of the block, the current master node judges whether the block can be submitted according to the view number corresponding to the block included in the voting message, and simultaneously shares the block which can be submitted and the newly proposed block to all verifier nodes, so that the defects that in the prior art, two times of communication is required to be carried out on a certain block consensus, and the consensus efficiency is slow are overcome, and the overall block chain consensus efficiency is improved.
Example two
Fig. 2 is a flowchart of a block consensus method provided in a second embodiment of the present application, where the method may be applied to a situation where each block in a block chain achieves consensus, and the method may be performed by a block consensus device, where the block consensus device may be implemented in a form of hardware and/or software, and the block consensus method may be applied to at least one verifier node, and the block consensus device may be configured in an electronic device. As shown in fig. 2, the method includes:
s210, acquiring indication information of the block proposed by the master node of the current view and the submittable block.
The proposed block is a block assembled by the current master node, and the submittable block is a block confirmed by the current master node and voted for consensus by each verifier node.
S220, if the indication information of the block proposed by the main node and the block which can be submitted in the current view is obtained in the first preset time, the confirmation information is received normally.
The first preset time may be used to confirm whether the current verifier node normally receives a message from the current master node. The first preset time may be implemented by a timer, and of course, the first preset time may be set by a related technician according to an actual situation or a manual experience, which is not limited in the embodiment of the present application.
And S230, when the confirmation information is received normally, the proposed block is stored locally.
After each verifier node acknowledges receipt of indication information of the proposed block and the submittable block sent by the current master node, the proposed block is stored locally.
S240, voting is carried out on the block proposed by the main node of the current view, and a voting message of the block is generated.
Each verifier node votes for the obtained block proposed by the current master node, and generates a voting message, i.e. a voting message under the current view.
S250, feeding back voting information of the blocks to the master node of the next view, so that the master node of the next view determines whether the blocks are submittable blocks according to the voting information.
After the current round of voting of the current view is finished, all voting messages of the current view are sent to the next master node of the next view, so that the master node of the next view judges whether the proposed current block achieves consensus among all nodes according to the voting messages, and if the current block achieves consensus, the current block can be confirmed to be a submittable block and can be uplink.
In an alternative embodiment, the method may further comprise: each verifier node writes the submittable blocks into the blockchain ledger according to the indication information of the submittable blocks.
After all verifier nodes in each view acquire indication information of the submittable block sent by the master node corresponding to the view, the submittable block can be uplink, namely written into a blockchain account book of the node.
In an alternative embodiment, the method may further comprise: judging whether the preamble block of the submittable block is already stored locally; if the preamble block is not stored locally, the preamble block is requested from the master node or other verifier node of the current view to write the preamble block into the blockchain ledger.
The preamble block may be a block that any node in the blockchain has already been uplink before the submittable block is uplink, and since the uplink of the block is time-ordered, the block that is uplink before the submittable block may be referred to as the preamble block. It can be understood that the blockchain is an untampered account book, if the omission occurs in the account book and the complete supplement should be timely performed, it can be thought that if the submittable block finds that the preamble block is missing before the uplink, the information of the preamble block can be obtained from other nodes (including the current master node and other verifier nodes), and the missing preamble block is completely supplemented at the current node, and then the submittable block is uplink.
In an alternative embodiment, the method may further comprise: if the indication information of the block proposed by the main node of the current view and the block which can be submitted is not obtained in the first preset time, the receiving of the confirmation information is overtime; and after the receiving time of the confirmation information is overtime, feeding back the locally stored block to the master node of the next view.
If the current block issued by the current master node to all verifier nodes and the submittable indication information are not received within the first preset time, it can be determined that a transmission problem occurs between the nodes, and information transmitted between the nodes cannot be received within a reasonable time. Then after the information reception times out, the block already stored locally in the node in the current verifier node can be directly sent to the next master node, so as to enter the consensus link of the next view.
In an alternative embodiment, the method may further comprise: after feeding back the locally stored block to the master node of the next view, confirming whether indication information of the block proposed by the master node of the next view and the block which can be submitted is received within a second preset time; if the indication information of the block proposed by the master node and the block which can be submitted in the next view is not received in the second preset time, the receiving of the confirmation information is overtime; if the indication information of the block proposed by the master node and the block which can be submitted in the next view is received within the second preset time, the confirmation information is received normally, and the time for receiving the indication information of the block proposed by the master node and the block which can be submitted is adjusted to be the initial preset time.
The second preset time may be a verification time after the verifier node of the current view sends the local block to the master node of the next view, and it is understood that the second preset time is for a consensus link in the next view, which is equivalent to other consensus processes performed after the consensus process of the current view has ended. Of course, the second preset time may be set by a related technician according to actual situations or manual experiences, and may be set accordingly according to the length of the first preset time, for example, the second preset time may be a multiple of the first preset time.
If the indication information of the block proposed by the master node and the submittable block of the next view is not received within the second preset time, the information reception timeout can be confirmed. If the indication information of the block proposed by the next master node and the submittable block is received within the second preset time, it can be understood that the information is received normally. That is, even if the information sent from the current verifier node to the next master node is overtime in the middle of the previous front-back view, after the information is normally received, it can be understood that a correct and effective interaction occurs, and then the overtime duration can be restored to the default time, that is, the initial preset time. Of course, the initial preset time may be the same as or different from the first preset time.
According to the technical scheme, the current proposed block assembled by the master node is voted in each verifier node, meanwhile, the block chain is helped to determine the current submittable block, communication is only carried out once in one view, the prior art is simplified, and the block consensus efficiency is improved.
Example III
Fig. 3 is a schematic diagram of a block consensus applicable to the embodiment of the present application, which is a preferred embodiment of a block consensus provided on the basis of the foregoing embodiments, specifically as follows:
first, the basic data structure occurring in the block consensus process is described as follows:
1. a block (block), the simplified block mainly comprising at least three parts of content: (at least one) transaction (denoted txs), view number (viewnnumber) and hash (hash). The hash points to the parent block of the current block, and the parent is used for representing, so a block can be represented by b= (txs, view number, parent). The chunk is generated by the master node (leader) and sent to all verifier nodes via a proposal message (propose).
2. The view numbers are represented using a viewNumber,
3. the highest block of the view number known by the verifier node is denoted as highBlock, and is the highest block of the view number known by the verifier node from the proxose message, and after each time the verifier node receives the proxose message sent by the master node, the verifier node updates and stores highBlock locally.
4. com point: pointers to committed blocks.
For messages sent between nodes to each other, there are several types of messages:
1. vote (view, block): for voting a block (or node), view is a view, and block is a block of votes.
2. Propose (block, componentpointer): for proposing a block, similarly, a block is a proposed block, and a commit pointer indicates a pointer to a block that can be committed.
The following flow is intended to introduce the flow of the master node and verifier nodes in view v. As described in the foregoing, the current master node becomes the verifier node in the voting process of the next view after proposing a block.
In the current master node, firstly collecting the vot messages (i.e. voting messages) sent by the verifier node in the v-th view until n-f volte messages are collected, wherein n is the total number of nodes, and f is the number of error nodes. And finding out the message with the highest viewNumber from the set M of n-f vot messages, and updating the highBlock of the master node by using the block in the message.
Next, the current block b= [ txs, v, hash (highBlock) ] is assembled, wherein txs is the transaction that the current master node wants to include, highBlock is the updated value, hash is the hash value of highBlock, and v is the current view number. If the blocks in each message in set M are identical and the view corresponding to each block is v-1, then the componentpointer may be pointed to the highBlock, meaning that the highBlock may be committed to write to the blockchain ledger.
The current master node then sends a block to all verifier nodes and proceeds to the next view v+1.
For each verifier node, after receiving the response message, the view number local to the verifier node is updated to switch the view to the next view. Updating the verifier node's own highBlock using the block in the block (commit pointer) message; the verifier node's own componentpointer is updated with the componentpointer in the Propore message. And checking whether the preamble block of the block pointed to by the updated componentpointer exists locally, if not, filling all the missing preamble blocks according to the increasing order of the view. And sequentially submitting all blocks at the current verifier node according to the blocks submitted and executed for the last time.
Voting on the block in the pro-ose message, sending the voting message vote (view, block) to the current master node and entering the next view v+1.
In the above steps, both the master node and the verifier node have timeout mechanisms, and if no corresponding message is received within a preset time, the message is considered to be transmitted overtime, and if the transmission time is overtime, the local view number is increased by 1, i.e. view number=v+1, and then volte (v+1, highblock) is sent to the master node of view v+1. Of course, for the processing of timeout, the timeout duration may be prolonged by a set factor, for example, 1.5 times the original duration: after the first timeout occurs, the timeout period of the node is set to t=1.5t, i.e. the timeout period is increased by 1.5 times. The time-out period is changed to 1.5 times of the original time-out period in order to gradually lengthen the time-out event. When a normal interaction occurs, the timeout is restored to the default value.
Example IV
Fig. 4 is a schematic structural diagram of a block consensus device according to a fourth embodiment of the present application, where the device may be used for a current master node. As shown in fig. 4, the apparatus 400 includes:
a voting verification module 410, configured to obtain, by a current master node in a current view, a voting message of each verifier node in a previous view according to an increasing order of the views;
the block obtaining module 420 is configured to obtain, from each voting message, a block with a highest view number if the voting message of the previous view obtained by the current master node exceeds a preset threshold;
the block generating module 430 is configured to generate a current block according to the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number;
a block confirmation module 440, configured to confirm the block as a submittable block when the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number;
the blockchain up module 450 is configured to propose a current block to each verifier node in the current view, and instruct each verifier node in the current view to write a submittable block to the blockchain ledger.
According to the technical scheme, the current master node obtains the voting message of the previous view under the current view, and is used as an assembler of the block, the current master node judges whether the block can be submitted according to the view number corresponding to the block included in the voting message, and shares the current block which can be submitted to all verifier nodes, and the current block can be confirmed to reach consensus at each verifier node only through one round of communication in the current view, so that the overall consensus efficiency of the block chain is improved.
The block consensus device provided by the embodiment of the application can execute the block consensus method provided by any embodiment of the application, and has the corresponding functional modules and beneficial effects of executing the block consensus methods.
Example five
Fig. 5 is a schematic structural diagram of a block consensus device according to a fifth embodiment of the present application, which may be applied to at least one verifier node. As shown in fig. 5, the apparatus 500 includes:
an indication information obtaining module 510, configured to obtain indication information of a block proposed by a master node of a current view and a submittable block;
the information receiving determining module 520 is configured to confirm that the information is received normally if the indication information of the block proposed by the master node and the block that can be submitted in the current view is obtained within the first preset time;
a block local storage module 530, configured to locally store the proposed block when the acknowledgement message is received normally;
a voting message generating module 540, configured to vote on a block proposed by the master node of the current view, and generate a voting message of the block;
the voting information feedback module 550 is configured to feed back the voting message of the block to the master node of the next view, so that the master node of the next view determines whether the block is a submittable block according to each voting message.
According to the technical scheme, the current block assembled by the main node is voted in each verifier node, so that the block chain is helped to determine whether the current block can be commonly known and then be uplink, and the block commonly known efficiency is improved.
In an alternative embodiment, the apparatus 500 may further include:
and the account book writing module is used for writing the submittable blocks into the blockchain account book by each verifier node according to the indication information of the submittable blocks.
In an alternative embodiment, the apparatus 500 may further include:
the storage judging module is used for judging whether the preamble block of the submittable block is already stored locally;
and the node request module is used for requesting the preamble block from a master node or other verifier nodes of the current view if the preamble block is not stored locally so as to write the preamble block into the blockchain ledger.
In an alternative embodiment, the apparatus 500 may further include:
the overtime judging module is used for confirming that the information receiving overtime if the indication information of the block proposed by the main node of the current view and the block which can be submitted is not acquired in the first preset time;
and the voting feedback module is used for feeding back the locally stored block to the master node of the next view after the receiving of the confirmation information is overtime.
In an alternative embodiment, the apparatus 500 may further include:
the indication information confirming module is used for confirming whether indication information of a block proposed by the master node of the next view and a submittable block is received within a second preset time after the locally stored block is fed back to the master node of the next view;
if the indication information of the block proposed by the master node and the block which can be submitted in the next view is not received in the second preset time, the receiving of the confirmation information is overtime;
if the indication information of the block proposed by the master node and the block which can be submitted in the next view is received within the second preset time, the confirmation information is received normally, and the time for receiving the indication information of the block proposed by the master node and the block which can be submitted is adjusted to be the initial preset time.
The block consensus device provided by the embodiment of the application can execute the block consensus method provided by any embodiment of the application, and has the corresponding functional modules and beneficial effects of executing the block consensus methods.
Example six
Fig. 6 shows a schematic diagram of the structure of an electronic device 10 that may be used to implement embodiments of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Electronic equipment may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the application described and/or claimed herein.
As shown in fig. 6, the electronic device 10 includes at least one processor 11, and a memory, such as a Read Only Memory (ROM) 12, a Random Access Memory (RAM) 13, etc., communicatively connected to the at least one processor 11, in which the memory stores a computer program executable by the at least one processor, and the processor 11 may perform various appropriate actions and processes according to the computer program stored in the Read Only Memory (ROM) 12 or the computer program loaded from the storage unit 18 into the Random Access Memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 may also be stored. The processor 11, the ROM 12 and the RAM 13 are connected to each other via a bus 14. An input/output (I/O) interface 15 is also connected to bus 14.
Various components in the electronic device 10 are connected to the I/O interface 15, including: an input unit 16 such as a keyboard, a mouse, etc.; an output unit 17 such as various types of displays, speakers, and the like; a storage unit 18 such as a magnetic disk, an optical disk, or the like; and a communication unit 19 such as a network card, modem, wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.
The processor 11 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various processors running machine learning model algorithms, digital Signal Processors (DSPs), and any suitable processor, controller, microcontroller, etc. The processor 11 performs the various methods and processes described above, such as the block consensus method.
In some embodiments, the block consensus method may be implemented as a computer program tangibly embodied on a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 10 via the ROM 12 and/or the communication unit 19. One or more of the steps of the block consensus method described above may be performed when the computer program is loaded into RAM 13 and executed by processor 11. Alternatively, in other embodiments, the processor 11 may be configured to perform the block consensus method in any other suitable way (e.g., by means of firmware).
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.
A computer program for carrying out the methods of the present application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be implemented. The computer program may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this application, a computer-readable storage medium may be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer readable storage medium may be a machine readable signal medium. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) through which a user can provide input to the electronic device. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), blockchain networks, and the internet.
The computing system may include clients and servers. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical hosts and VPS service are overcome.
It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present application may be performed in parallel, sequentially, or in a different order, so long as the desired results of the technical solutions of the present application are achieved, and the present application is not limited herein.
The above embodiments do not limit the scope of the application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application are intended to be included within the scope of the present application.

Claims (10)

1. A block consensus method applied to a current master node, the method comprising:
according to the increasing order of the views, the current master node in the current view acquires voting information of each verifier node in the previous view;
if the voting message of the previous view acquired by the current master node exceeds a preset threshold, acquiring a block with the highest view number from each voting message;
generating a current block according to the hash value of the block with the highest view number, current transaction information in the current view and the current view number;
When the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number, the block is confirmed as a submittable block;
the current blobs are proposed to each verifier node in the current view, and the verifier nodes of each current view are instructed to write the submittable blobs to a blockchain ledger.
2. A block consensus method, for use in at least one verifier node, the method comprising:
acquiring indication information of a block proposed by a main node of a current view and a submittable block;
if the indication information of the block proposed by the main node and the block which can be submitted in the current view is obtained in the first preset time, the confirmation information is normally received;
when the confirmation information is received normally, the proposed block is stored locally;
voting a block proposed by a main node of the current view, and generating a voting message of the block;
and feeding back voting messages of the blocks to the master node of the next view, so that the master node of the next view determines whether the blocks are submittable blocks according to each voting message.
3. The method according to claim 2, wherein the method further comprises: and each verifier node writes the submittable block into a blockchain ledger according to the indication information of the submittable block.
4. A method according to claim 3, characterized in that the method further comprises:
judging whether the preamble block of the submittable block is already stored locally;
and if the preamble block is not stored locally, requesting the preamble block from a master node or other verifier nodes of the current view so as to write the preamble block into a blockchain ledger.
5. The method according to claim 2, wherein the method further comprises:
if the indication information of the block proposed by the main node of the current view and the block which can be submitted is not obtained in the first preset time, the receiving of the confirmation information is overtime;
and after the receiving time of the confirmation information is overtime, feeding back the locally stored block to the master node of the next view.
6. The method of claim 5, wherein the method further comprises: after feeding back the locally stored block to the master node of the next view, confirming whether indication information of the block proposed by the master node of the next view and the block which can be submitted is received within a second preset time;
if the indication information of the block proposed by the master node and the block which can be submitted in the next view is not received in the second preset time, the receiving of the confirmation information is overtime;
If the indication information of the block proposed by the master node and the block which can be submitted in the next view is received within the second preset time, the confirmation information is received normally, and the time for receiving the indication information of the block proposed by the master node and the block which can be submitted is adjusted to be the initial preset time.
7. A block consensus apparatus for a current master node, the apparatus comprising:
the voting verification module is used for acquiring voting information of each verifier node in the previous view by the current main node in the current view according to the increasing sequence of the views;
the block acquisition module is used for acquiring a block with the highest view number from each voting message when the voting message of the previous view acquired by the current master node exceeds a preset threshold;
the block generation module is used for generating a current block according to the hash value of the block with the highest view number, the current transaction information in the current view and the current view number;
the block confirming module is used for confirming the block as a submittable block when the blocks included in each voting message of the previous view are identical and the view number in the block is the previous view number;
and the block uplink module is used for proposing the current block to each verifier node in the current view and instructing the verifier node of each current view to write the submittable block into a blockchain ledger.
8. A block consensus apparatus for use in at least one verifier node, the apparatus comprising:
the indication information acquisition module is used for acquiring indication information of the block proposed by the main node of the current view and the block which can be submitted;
the information receiving judging module is used for confirming that the information is normally received if the indication information of the block proposed by the main node and the block which can be submitted in the current view is obtained in the first preset time;
the block local storage module is used for locally storing the proposed block when the confirmation information is received normally;
the voting message generation module is used for voting the block proposed by the main node of the current view and generating a voting message of the block;
and the voting information feedback module is used for feeding back the voting information of the block to the master node of the next view so that the master node of the next view can determine whether the block is a submittable block according to each voting information.
9. An electronic device, the electronic device comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the block consensus method of claim 1; and/or performing the block consensus method according to any of the claims 2-6.
10. A computer readable storage medium storing computer instructions for causing a processor to implement the block consensus method according to claim 1 when executed; and/or implementing the block consensus method according to any of the claims 2-6.
CN202311542248.6A 2023-11-17 2023-11-17 Block consensus method, device, electronic equipment and storage medium Pending CN117579632A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311542248.6A CN117579632A (en) 2023-11-17 2023-11-17 Block consensus method, device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311542248.6A CN117579632A (en) 2023-11-17 2023-11-17 Block consensus method, device, electronic equipment and storage medium

Publications (1)

Publication Number Publication Date
CN117579632A true CN117579632A (en) 2024-02-20

Family

ID=89860078

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311542248.6A Pending CN117579632A (en) 2023-11-17 2023-11-17 Block consensus method, device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN117579632A (en)

Similar Documents

Publication Publication Date Title
CN109951331B (en) Method, device and computing cluster for sending information
CN107277083B (en) Data interaction processing method, device and system
US11200123B2 (en) Consensus process recovery method and related node
CN110581887B (en) Data processing method, device, block chain node and storage medium
CN114357495B (en) Prediction machine under-chain aggregation method, device, equipment and medium based on block chain
CN112738294B (en) Domain name resolution method and device based on block chain, electronic equipment and storage medium
CN114328132A (en) Method, device, equipment and medium for monitoring state of external data source
CN113193947A (en) Method, apparatus, medium, and program product for implementing distributed global ordering
CN113420323B (en) Data sharing method and terminal equipment
CN116719639A (en) Link dynamic adjustment and data processing method, device, computer equipment and medium
CN115952561A (en) Data processing method, device, equipment and medium applied to rail transit system
CN117579632A (en) Block consensus method, device, electronic equipment and storage medium
CN111367934A (en) Data consistency checking method, device, server and medium
CN116431313A (en) Scheduling method, device, equipment and medium for polling task
CN116528177A (en) Short message sending method and device, electronic equipment and storage medium
CN113641688B (en) Node updating method, related device and computer program product
CN116319277A (en) Method and system for selecting main materials by using Raft in heterogeneous environment
CN111666132B (en) Distributed transaction implementation method, device, computer system and readable storage medium
US20210240698A1 (en) Asynchronous remote calls with undo data structures
CN111752911A (en) Data transmission method, system, terminal and storage medium based on Flume
CN116016265B (en) Message all-link monitoring method, device, system, equipment and storage medium
CN114202947B (en) Internet of vehicles data transmission method and device and automatic driving vehicle
CN116974825A (en) Backup method, device, equipment and storage medium
CN115599869B (en) Data acquisition method and device, electronic equipment and storage medium
CN108108243B (en) Resource sharing system and method

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