CN116074310B - Block chain consensus method based on improved entrusting right evidence of ring signature - Google Patents
Block chain consensus method based on improved entrusting right evidence of ring signature Download PDFInfo
- Publication number
- CN116074310B CN116074310B CN202211235100.3A CN202211235100A CN116074310B CN 116074310 B CN116074310 B CN 116074310B CN 202211235100 A CN202211235100 A CN 202211235100A CN 116074310 B CN116074310 B CN 116074310B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- block
- consensus
- witness
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 24
- 238000012795 verification Methods 0.000 claims description 10
- 238000012216 screening Methods 0.000 claims description 2
- 230000007246 mechanism Effects 0.000 abstract description 14
- 238000005265 energy consumption Methods 0.000 abstract description 3
- 230000008569 process Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- 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/3247—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 involving digital signatures
- H04L9/3255—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 involving digital signatures using group based signatures, e.g. ring or threshold signatures
-
- 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)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a block chain consensus method based on ring signature improved entrusting right proof, belonging to the block chain technical field, comprising the following steps: step 1, selecting a consensus node; step 2, consensus achieving step; and step 3, a malicious node punishment step. The consensus method combines a workload proving consensus mechanism, but the energy consumption is far smaller than that of the workload proving consensus mechanism, and each node does not need to be in constant competition account counting right like the workload proving consensus mechanism. And meanwhile, the ring signature is used for encrypting the identity of the block generator in the voting stage of the formula, and the witness node does not know the specific identity of the block generation node, so that the witness node cannot partnership. Anonymity and security are increased.
Description
Technical Field
The invention belongs to the field of computers and the Internet, and relates to a block chain consensus mechanism based on trust benefit certification improved by ring signature. The problems of high energy consumption and low safety of the original consensus machine are solved, and the performance of the block chain is improved.
Background
The distributed account book mainly refers to the account book of the transaction which is not stored in one place but distributed in a plurality of nodes, each node stores a complete account book, and the legitimacy of the transaction can be supervised and verified among the nodes. Blockchain distributed storage is unique in that all nodes have a complete ledger and all are not required to backup data to a characteristic central node, as in conventional distributed storage.
The chain structure, the blockchain adopts the chain table type data structure, the blocks are composed of block heads and block bodies, all the blocks form a chain type structure according to the hash value, and the blocks together form the distributed account book of the blockchain. Wherein the hash value of each block is formed by hashing the transaction data in the block to form the root of Makle tree (merck tree) and the hash value of the last block to be hashed, so that any change of the transaction data affects not only the block but also the following blocks in succession, thereby preventing the tampering of the data.
The ring signature is a simplified group signature, only ring members in the ring signature have no manager, no cooperation among the ring members is needed, the signer can independently sign by using own private key and public keys of other members in the set, and the other members in the set may not know that the signer is contained in the signature. The advantage of ring signatures is that in addition to being able to unconditionally anonymously make the former, other members in the ring cannot forge the true signer signature. The ring signature emphasizes anonymity and increases the difficulty of audit supervision.
Smart contracts are based on these trusted, non-tamperable data that can be automated to execute some predefined rules and terms. Taking insurance as an example, if everyone's information (including medical information and risk occurrence information) is said to be authentic, it is easy to make automated claims in some standardized insurance products. In the daily business of insurance companies, though transactions are not as frequent as in the banking and securities industries, there is an increase or decrease in dependence on trusted data. Therefore, the author believes that the use of blockchain technology, cutting in from the perspective of data management, can effectively help insurance companies to increase risk management capabilities. In particular, the management of insurance applicant risks and the risk supervision of insurance companies are mainly divided.
CN112003820A, a block chain consensus optimizing method based on ring signature and aggregate signature, any node in the system broadcasts transaction data to the block chain network and attaches signature; the aggregate signer obtains an aggregate signature through an aggregate signature algorithm; all accounting nodes independently monitor transaction data of the whole network and record the transaction data in a memory; the consensus master node initiates a consensus proposal to the proposal waiting for consensus, and when any consensus cluster node receives s protocols, the consensus master node generates a ring signature with an aggregation node of s protocol senders; the consensus cluster node performs transaction verification on the s proposal and broadcasts the s proposal to the whole network; after receiving the ring signature of the normal consensus cluster node and verifying, any consensus node achieves consensus and issues a new block, and the common node synchronizes account information; and after receiving the new block, any consensus node deletes the contained transaction from the memory to perform the next round of consensus. In the patent, the disadvantage of the delegation rights proving consensus mechanism is that the high centralization of rights can result in aggravation of lean-rich gap, the common node can rarely obtain the rights of block generation, and in the block chain consensus method based on the improved delegation rights proving of the ring signature, the common node can compete to become a consensus node in the consensus node selection stage. Another disadvantage of the trust benefit proving consensus mechanism is that act in collusion with cheating is easy to occur between the master nodes, in the block chain consensus method based on the improved trust benefit proving of the ring signature, anonymization processing is performed by using the ring signature in the consensus stage, identities of the other parties are not known between the commonly-known master nodes, and act in collusion with cheating is not occurring.
Disclosure of Invention
The present invention is directed to solving the above problems of the prior art. An improved delegation rights certification blockchain consensus method based on ring signatures is presented. The technical scheme of the invention is as follows:
a blockchain consensus method of improved delegated rights evidences based on ring signatures, comprising the steps of:
Step 1, selecting a consensus node; the voting node and the block generating node are used for selecting the consensus achieving step.
Step 2, consensus achieving step; for generating new blocks and validating and voting on the new blocks.
Step 3, a malicious node punishment step; for penalizing malicious nodes.
Further, the step of selecting the consensus node in step 1 specifically includes:
(1.1) broadcasting an election message by the blockchain system;
(1.2) the node calculates its own Diffvalue value; diffvalue denotes a satisfactory difficulty value calculated from the base difficulty value.
(1.3) Responding to the election message by the node;
(1.4) the system supervisor screens the election message;
(1.5) the system supervisor selecting witness and candidate.
Further, the blockchain system in step (1.1) broadcasts an election message, which specifically includes:
the blockchain system broadcasts a message < nonce, D > to each node in the entire network
After receiving the message < nonce, D >, node N i obtains the last block header PreBlockHead from the blockchain, calculates HASH (HASH (PreBlockHead), nonce) as its own Diffvalue, and sends it to the system supervisor; d represents a difficulty value set by the system, wherein the difficulty can be set smaller than the workload proof, but the difficulty value cannot be set.
Further, the node in step (1.2) calculates Diffvalue a value, specifically including:
Diffvalue＝HASH(HASH(PreBlockHead),nonce)
further, the step (1.3) of responding to the election message specifically includes:
Node N i observes the value of comparison formula Diffvalue < D, if it is false, repeats step (1.2), if it is true, sends < Diffvalue, N i > to the system supervisor.
Further, the step (1.4) of screening the election message by the system supervisor specifically includes:
after decrypting, eliminating the block with the ERROR state by the system supervisor, sorting according to the time of receiving the election message, selecting the first 201 nodes, and returning the flag bit;
the step (1.5) the system supervisor selects witness and candidate, specifically including:
The former hundred nodes are witness nodes, the right of which turn of consensus generation node is given to the former hundred nodes, then the nodes N i are distributed to a witness node set N C, and the nodes in the set N C are used as a community for consensus. Nodes 101-201 are candidate nodes, and then node N i is assigned to such nodes in the consistent node set N A as candidate nodes for witness nodes.
Further, the step 2 consensus achieving step specifically includes:
The system supervisor sends a public key set PK Set and a private key SK c Rsign of the ring signature to the block witness node;
(2.1) each witness node collecting a previous chunk to generate a current transaction and generating MEKLETREE;
(2.2) the block generator node generating a block expression;
(2.3) the block generator node broadcasting new block information;
(2.4) the witness node voting according to the new block information;
(2.5) the witness node generating voting information;
(2.6) the block generator node counts the voting information and broadcasts the result; if the new block is not agreed to enter the malicious node punishment stage.
Further, the steps (2.1) - (2.6) specifically include:
Each witness node collects the last block to generate the current transaction and generates MAKLETREE;
(2.1) ranking the expression of the first node-generated block
Block= < < NORMAL, HASH (PreBlock), mekleTreeRoot, time, D, diffvalue, >, txs >, time representing Time, txs representing the most recent transaction.
Anonymous ring signature with SK Rsign and then broadcast between block witness, NORMAL representing that the state of the block is default; if the block achieves consensus, the state of the block becomes Good; other blocks can mine new blocks behind the block, if the state of the block is ERROR, the block is not agreed, and the block is re-agreed after entering a malicious node punishment stage;
(2.2) the first ranked node encrypts the order value using the ring signature F Rsign(PKSet,SKc Rsign, order), outputs the ring signature σ c Rsign and generates a broadcast message, PK Set is the public key of the ring signature; σ c Rsign represents the ring signature of the first-ranked node.
messc＝(σc Rsign,Time,D,order,MekleTreeRoot,PKSet),
(2.3) Other witness nodes receive the broadcast message, select the validity of the signature for verification by the smallest order, F Rsign@verify(PKSet,order,σc Rsign), and prove that the broadcast message is indeed from the first-ranked node if correct. F Rsign verify represents ring signature verification.
(2.4) Each witness node comparing the received MekleTreeRoot with its own generated verification MekleTreeRoot verify, if the same, approving the ticket, if different, posting an anti-objection ticket; witness node N c i uses private keyEncrypting voting information;
(2.5) comparing the order value after the block generator receives the broadcast message, if it is the same as the self order value, using The message is decrypted and the ticket number is counted.
Count agree＝∑voteagree,countdisagree＝∑votedisagreecountagree、countdisagree represents the number of votes agreed and the number of votes not agreed, respectively.
If count agree<countdisagree indicates that most witness nodes do not agree to the generation of the region block, the node broadcasts a message;
BlockERROR<<ERROR,HASH(PreBlock),MekleTreeRoot,Time,D,Diffvalue,>,txs>
(2.6) after all the consensus nodes receive the Block ERROR, the Block generating node is regarded as a malicious node, and a malicious node punishment stage is entered;
(2.7) entering a malicious node punishment stage;
(2.8) after the malicious node punishment phase is finished, re-performing the consensus phase;
(2.9) if the new block is approved, the system administrator validates the new block.
(2.10) The block generating a node witness node set;
(2.11) the system supervisor complets the witness set and the candidate set.
Further, the step (3) of malicious node punishing stage specifically includes:
(3.1) the system supervisor terminating the consensus phase;
(3.2) the system supervisor checking for malicious operations;
(3.3) penalizing the malicious node;
(3.4) the system supervisor complets the witness set;
(3.5) the system supervisor complements the candidate set;
(3.6) restarting the consensus phase.
Further, the steps (3.1) - (3.6) specifically include the following steps:
(3.1) the system supervisor terminating the consensus phase;
(3.2) the supervisor gathers voting information for all malicious nodes and uses its public key Decrypting the message, verifying that the node did perform a malicious operation;
(3.3) broadcasting the information of the malicious node in a whole network, setting that the malicious node cannot participate in the selection of formula nodes in 7 days later, and performing fine operation on the information; so that if a malicious node is bad, it will receive an extremely serious penalty; after the nodes are regarded as bad nodes and penalized, the nodes cannot compete for the consensus nodes within 7 days and can only be used as common transaction nodes;
(3.4) if m malicious nodes exist in total, the system supervisor eliminates m disqualified nodes out of the witness node set, then selects the first m nodes of the candidate nodes, and enters the witness node set; the system supervisor reorders the witness set and returns the sequence identification to each node;
(3.5) the system supervisor performs a formula node selection stage, selects the first m nodes to enter the candidate queue, and returns T if other nodes are still common node flag bits;
(3.6) after the above operation, the system supervisor restarting the consensus phase.
The invention has the advantages and beneficial effects as follows:
the invention designs a block chain consensus mechanism based on the trust benefit evidence of ring signature improvement, which combines a workload evidence consensus mechanism, but the energy consumption is far smaller than that of the workload consensus mechanism, each node does not need to be like the workload evidence consensus mechanism, and each node needs continuous competitive accounting rights. The delegation rights prove that the disadvantage of the consensus mechanism is that the high centralization of rights can result in aggravation of lean-rich gaps, and common nodes rarely can obtain the rights of block generation.
In the original trust benefit proving consensus mechanism, the consensus nodes all know the identity of the other party, and act in collusion with cheating exists, so that act in collusion with cheating can not be carried out among the consensus nodes.
Drawings
FIG. 1 is a schematic diagram of the three stages of providing a preferred embodiment of the present invention;
FIG. 2 is a schematic diagram of consensus node selection;
FIG. 3 is a schematic diagram of a consensus phase;
FIG. 4 is a schematic diagram of malicious node penalties;
fig. 5 is an illustration of some of the symbols used in the present method.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and specifically described below with reference to the drawings in the embodiments of the present invention. The described embodiments are only a few embodiments of the present invention.
The technical scheme for solving the technical problems is as follows:
a blockchain consensus mechanism based on trust attestation of ring signature improvement comprising the steps of: the three stages of consensus node selection, consensus and malicious node punishment are related as shown in figure 1.
(1) The consensus node is selected, as shown in fig. 2, and the process is as follows:
(1.1) the blockchain system broadcasts a message < nonce, D > to each node in the entire network, nonce being a base difficulty value, D being a satisfactory difficulty value, the difficulty being smaller than the workload proof can be set, but the difficulty value cannot be set.
(1.2) After node N i receives the message < nonce, D >, it obtains the last block header PreBlockHead from the blockchain and calculates HASH (HASH (PreBlockHead), nonce) as its own Diffvalue.
(1.3) Node N i observes a value of Diffvalue < D, if the value is false, then repeat step 2. If this is true, < Diffvalue, N i > is issued to the system supervisor
(1.4) After decrypting and eliminating the block with ERROR state, the system supervisor selects the first 201 nodes according to the time sequence of receiving < Diffvalue, N i > and returns the flag bit.
(1.5) The first hundred nodes are witness nodes, and the order value order and the rank are returned as the right of which turn it has to generate new nodes. Node N i is then assigned to witness node set N C, and the nodes in set N C are consensus as a community. For example, the order rank of the node is 10, the node has the billing right of the 10 th new node after the start of the consensus and also has the voting right of the first 9 rounds of consensus, and when the node generates the new node in the 10 th round, the node exits from the witness node set as a common node. The order value order of each node in the witness node set is discontinuous, e.g., {3,7,10,19,20,35..degree}, which may prevent malicious nodes from impersonating the block generator node. Each node knows its own order and rank, but does not know the orders of the other nodes. Nodes with rank names of 101-201 are candidate nodes, then the nodes N i are distributed to a consistent node set N A to serve as candidate nodes of witness nodes, when the witness nodes are dispenalized, the candidate nodes can be recursively repaired into witness nodes, and C is returned for candidates; the other nodes are ordinary transaction nodes, and only transfers of ordinary nodes can be made, for which T is returned (the number of witness nodes and candidates can be set according to the situation, and the number is used for illustration).
(2) The consensus phase, as shown in fig. 3, is as follows:
The system administrator sends a ring signed public key set PK Set, and private key SK c Rsign to the block witness node.
(2.1) Each witness node collecting the last chunk to generate a current transaction and generating MAKLETREE.
(2.2) Ranking the expression of the first node-generated block
Block＝<<NORMAL,HASH(PreBlock),MekleTreeRoot,Time,D,Diffvalue,>,txs>，
Time represents Time and txs represents the last transaction.
This is anonymously signed with SK Rsign and then broadcast between block witnessed persons, NORMAL representing that the state of the block is default. If the block achieves consensus, the state of the block becomes Good. Other blocks will mine new blocks behind the block, if the state of the block is ERROR, it will be explained that no consensus is achieved, and the consensus is performed again after the malicious node punishment stage is entered.
(2.3) The first-ranked node encrypts its identity using the ring signature F Rsign(PKSet,SKc Rsign, order)
The ring signature σ c Rsign is output and a broadcast message is generated, PK Set is the public key set of the ring signature. order is a discontinuous, sequential value that the supervisor sets up nodes in the witness set.
messc＝(σc Rsign,Time,D,order,MekleTreeRoot,PKSet),
(2.4) Other witness nodes receiving the broadcast message, verifying the validity of the signature,
F Rsign@verify(PKSet,order,σc Rsign) if correct, prove that the broadcast message is indeed from the first ranked node, and verify that the error did not vote on it.
(2.5) Each witness node compares the received MekleTreeRoot with its own generated verification MekleTreeRoot verify. If the two types of tickets are the same, the ticket is prayed, and if the two types of tickets are different, the ticket is prayed against the ticket. Witness node N c i uses private keyEncrypting voting information
(2.6) Checking the broadcast message after the block generator receives the broadcast message, if order is the same as the order value of itself, usingDecrypting the message. The ticket number is then counted.
countagree＝∑voteagree,countdisagree＝∑votedisagree
If count agree<countdisagree indicates that most witness nodes do not agree to the generation of the region block, then the node broadcasts a message
BlockERROR＝<<ERROR,HASH(PreBlock),MekleTreeRoot,Time,D,Diffvalue,>,txs>
(2.7) After all nodes receive the Block ERROR, the Block generating node is regarded as a malicious node, and enters a malicious node punishment stage.
(2.8) After the malicious node punishment phase is finished, the consensus phase is carried out again.
(2.9) If count agree>countdisagree, submit the new block to the system administrator. And (3) verifying by the system supervisor, and after the system supervisor fails to verify, regarding the block generating node as a malicious node and entering a malicious node punishment stage. If the system supervisor verifies successfully, set its state to Good, broadcast the new block to all network nodes
Block＝<<Good,HASH(PreBlock),MekleTreeRoot,Time,D,Diffvalue,>,txs>。
The tile producer gets a new tile prize for the system. And issuing rewards to the nodes which vote on the premise that the nodes are not in the premise that the nodes which vote on the premise are malicious nodes.
(2.10) After the node generates the new node, the block generating node exits the witness node set.
(2.11) The system supervisor selects a first candidate node from the candidate set N A to enter the witness node set N C. Re-executing the consensus node selection, selecting a node to enter the candidate set N A
(3) The malicious node punishment stage, as shown in fig. 4, comprises the following steps:
(3.1) System supervisor terminating consensus phase
(3.2) The supervisor gathers voting information for all malicious nodes and uses its public keyDecrypting the message verifies that the node did perform a malicious operation.
And (3.3) broadcasting the information of the malicious node in a whole network, setting that the malicious node cannot participate in the selection of formula nodes in 7 days later, and performing fine operation on the information. So that if a malicious node is bad, it will receive an extremely serious penalty. After the nodes are regarded as bad nodes and penalized, the nodes cannot compete for the consensus nodes within 7 days and can only be used as common transaction nodes.
(3.4) If m malicious nodes exist in total, the system supervisor rejects m disqualified nodes out of the witness node set, then selects the first m nodes of the candidate nodes, and enters the witness node set. The system supervisor reorders the witness set and returns its sequential identification to each node
And (3.5) the system supervisor performs a formula node selection stage, selects the first m nodes to enter the candidate queue, and returns the T after other nodes are still common node flag bits.
(3.6) After the above operation, the system supervisor restarts the consensus phase
A blockchain is a chain data structure that sequentially links and combines data blocks in a temporal order, and cryptographically ensures that the data blocks are not tamperable and counterfeitable. Each block in the blockchain is linked to the immediately preceding block in the blockchain by including a cryptographic hash of the preceding block. Each chunk also includes a timestamp, a cryptographic hash of the chunk, and one or more transactions. The transaction that has been validated by a node of the blockchain network is hashed and forms a Merkle tree. In the Merkle tree, data at leaf nodes is hashed and for each branch of the Merkle tree, all hash values of that branch are concatenated at the root of that branch. The above process is performed for the Merkle tree up to the root node of the entire Merkle tree. The root node of the Merkle tree stores hash values representing all the data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, a quick verification may be performed by determining whether the hash value is consistent with the Merkle tree structure.
A blockchain network is a network of computing nodes that is used to manage, update, and maintain one or more blockchain structures. In this specification, a blockchain network may include a public blockchain network, a private blockchain network, or a federated blockchain network.
In a common blockchain network, the consensus process is controlled by nodes of the consensus network. For example, there may be thousands of entity collaboration processes in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network of participating entities. In some examples, most entities (nodes) must sign each block in order and add the signed block to the blockchain of the blockchain network. Examples of public blockchain networks may include specific peer-to-peer payment networks.
Public blockchain networks support public transactions. Public transactions are shared among all nodes within the public blockchain network and stored in the global blockchain. Global blockchains refer to blockchains that replicate across all nodes. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within the common blockchain network. Examples of consensus protocols include, but are not limited to: proof of work (POW), proof of rights (POS), and proof of authority (POA).
A private blockchain network is provided for a particular entity. The read-write rights of each node in the private blockchain network are tightly controlled. Thus, private blockchain networks are also commonly referred to as licensed networks, which limit who is allowed to participate in the network and the level of network participation (e.g., only in certain transaction scenarios). In private blockchain networks, various types of access control mechanisms may be used (e.g., existing participants voting for adding new entities, regulatory body control permissions, etc.).
The federated blockchain network is private between the participating entities. In a federated blockchain network, the consensus process is controlled by the authorizing node. For example, a federation consisting of several (e.g., 10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, with each entity operating at least one node in the federated blockchain network. Thus, a federated blockchain network may be considered a private network of participating entities. In some examples, each participating entity (node) must sign each chunk in order and add that chunk to the blockchain. In some examples, each chunk may be signed by a subset (e.g., at least 7 entities) of participating entities (nodes) and added to the blockchain.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. 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 apparatus that comprises the element.
The above examples should be understood as illustrative only and not limiting the scope of the invention. Various changes and modifications to the present invention may be made by one skilled in the art after reading the teachings herein, and such equivalent changes and modifications are intended to fall within the scope of the invention as defined in the appended claims.
Claims (1)
1. A blockchain consensus method for improved delegated rights evidences based on ring signatures, comprising the steps of:
step 1, selecting a consensus node; the voting node and the block generating node are used for selecting the voting node and the block generating node in the consensus achievement step;
step 2, consensus achieving step; the method comprises the steps of generating a new block, and verifying and voting the new block;
step 3, a malicious node punishment step; for penalizing malicious nodes;
the step of selecting the consensus node in the step 1 specifically comprises the following steps:
(1.1) broadcasting an election message by the blockchain system;
(1.2) node calculating Diffvalue values; diffvalue represents a satisfactory difficulty value calculated from the base difficulty value;
(1.3) responding to the election message by the node;
(1.4) the system supervisor screens the election message;
(1.5) the system supervisor selecting witness and candidate;
the block chain system broadcasting election message of step (1.1) specifically includes:
the blockchain system broadcasts a message < nonce, D > to each node in the entire network
After receiving the message < nonce, D >, node N i obtains the last block header PreBlockHead from the blockchain, calculates HASH (HASH (PreBlockHead), nonce) as its own Diffvalue, and sends it to the system supervisor;
The step (1.2) node calculates Diffvalue a value, which specifically includes:
Diffvalue＝HASH(HASH(PreBlockHead)，nonce)；
the step (1.3) of responding the election message specifically comprises the following steps:
Node N i observes the value of comparison formula Diffvalue < D, if it is false, repeats step (1.2), if it is true, sends < Diffvalue, N i > to the system supervisor;
the step (1.4) of screening the election message by the system supervisor specifically comprises the following steps:
after decrypting and eliminating the block with ERROR state, the system supervisor selects the first 201 nodes according to the time sequence of receiving the election message and returns the flag bit;
the step (1.5) the system supervisor selects witness and candidate, specifically including:
The former hundred nodes are witness nodes, rights of turn consensus generation nodes are given to the former hundred nodes, then the nodes N i are distributed to a witness node set N C, and the nodes in the set N C are used as a community for consensus; the 101-201 nodes are candidate nodes, and then the node N i is allocated to the nodes in the consistent node set N A to serve as candidate nodes of witness nodes;
the step 2 consensus achieving step specifically includes:
The system supervisor sends a public key set PK Set and a private key SK c Rsiggn of the ring signature to the block witness node;
(2.1) each witness node collecting a previous chunk to generate a current transaction and generating MAKLETREE;
(2.2) the block generator node generating a block expression;
(2.3) the block generator node broadcasting new block information;
(2.4) the witness node voting according to the new block information;
(2.5) the witness node generating voting information;
(2.6) the block generator node counts the voting information and broadcasts the result; if the new block is not agreed to enter a malicious node punishment stage;
The step (2.1) phi (2.6) specifically comprises the following steps:
Each witness node collects the last block to generate the current transaction and generates MAKLETREE;
(2.1) ranking the expression of the first node-generated block
Block＝《NORMAL，HASH(PreBlock)，MakleTreeRoot，Time，D，Diffvalue>，txs>，
Time represents Time, txs represents the last transaction;
Anonymous ring signature with SK Rsign and then broadcast between block witness, NORMAL representing that the state of the block is default; if the block achieves consensus, the state of the block becomes Good; other blocks can mine new blocks behind the block, if the state of the block is ERROR, the block is not agreed, and the block is re-agreed after entering a malicious node punishment stage;
(2.2) the first ranked node encrypts the order value using the ring signature F Rsign(PKSet,SKc Rsign, order), outputs the ring signature σ c Rsign and generates a broadcast message, PK Set is the public key of the ring signature; σ c Rsign represents the ring signature of the first-ranked node;
messc＝(σc Rsign,Time,D,order,MakleTreeRoot,PKSet)，
(2.3) other witness nodes receive the broadcast message, the validity of the signature is verified by selecting the minimum order, and F Rsign·verify(PKSet,order,σc Rsign),FRsign -verify represents ring signature verification; if the received information is correct, proving that the broadcast information is really from the node ranked first, not voting the node by the verification error, and selecting the next order for verification;
(2.4) each witness node comparing the received MakleTreeRoot with its own generated verification MakleTreeRoot verify, if the same, approving the ticket, if different, posting an anti-objection ticket; witness node N c i uses private key Encrypting voting information;
(2.5) comparing the order value after the block generator receives the broadcast message, if it is the same as the self order value, using The message is decrypted and the ticket number is counted.
countagree＝∑voteagree,countdisagree＝∑votedisagree
Count agree、countdisagree represents the number of votes agreed and the number of votes not agreed, respectively;
If count agree＜countdisagree indicates that most witness nodes do not agree to the generation of the region block, the node broadcasts a message;
BlockERROR＝《ERROR，HASH(PreBlock)，MekleTreeRoot，Time，D，Diffvalue>，txs>
(2.6) after all nodes receive the Block ERROR, the Block generating node is regarded as a malicious node, and a malicious node punishment stage is entered;
(2.7) entering a malicious node punishment stage;
(2.8) after the malicious node punishment phase is finished, re-performing the consensus phase;
(2.9) if the new block is approved, the system administrator validates the new block;
(2.10) the block generating node exiting the witness node set;
(2.11) the system supervisor complets the witness set and the candidate set;
the step (3) of malicious node punishment stage specifically comprises the following steps:
(3.1) the system supervisor terminating the consensus phase;
(3.2) the system supervisor checking for malicious operations;
(3.3) penalizing the malicious node;
(3.4) the system supervisor complets the witness set;
(3.5) the system supervisor complements the candidate set;
(3.6) restarting the consensus phase;
The steps (3.1) - (3.6) specifically comprise the following steps:
(3.1) the system supervisor terminating the consensus phase;
(3.2) the supervisor gathers voting information for all malicious nodes and uses its public key Decrypting the message, verifying that the node did perform a malicious operation;
(3.3) broadcasting the information of the malicious node in a whole network, setting that the malicious node cannot participate in the selection of formula nodes in 7 days later, and performing fine operation on the information; so that if a malicious node is bad, it will receive an extremely serious penalty; after the nodes are regarded as bad nodes and penalized, the nodes cannot compete for the consensus nodes within 7 days and can only be used as common transaction nodes;
(3.4) if m malicious nodes exist in total, the system supervisor eliminates m disqualified nodes out of the witness node set, then selects the first m nodes of the candidate nodes, and enters the witness node set; the system supervisor reorders the witness set and returns the sequence identification to each node;
(3.5) the system supervisor performs a formula node selection stage, selects the first m nodes to enter the candidate queue, and returns T if other nodes are still common node flag bits;
(3.6) after the above operation, the system supervisor restarting the consensus phase.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211235100.3A CN116074310B (en) | 2022-10-10 | 2022-10-10 | Block chain consensus method based on improved entrusting right evidence of ring signature |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211235100.3A CN116074310B (en) | 2022-10-10 | 2022-10-10 | Block chain consensus method based on improved entrusting right evidence of ring signature |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116074310A CN116074310A (en) | 2023-05-05 |
| CN116074310B true CN116074310B (en) | 2024-04-26 |
Family
ID=86173823
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211235100.3A Active CN116074310B (en) | 2022-10-10 | 2022-10-10 | Block chain consensus method based on improved entrusting right evidence of ring signature |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116074310B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111683121A (en) * | 2020-05-22 | 2020-09-18 | 哈尔滨工程大学 | Cloud data tracing source block chain consensus mechanism improvement method based on DPoS |
| CN112541821A (en) * | 2020-11-18 | 2021-03-23 | 齐鲁工业大学 | Delegation rights and interests certification consensus algorithm with dynamic trust |
| CN113395164A (en) * | 2021-04-22 | 2021-09-14 | 江苏大学 | Electronic voting method based on ring signature and block chain |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200059369A1 (en) * | 2017-05-16 | 2020-02-20 | Peking University Shenzhen Graduate School | Determining consensus by parallel proof of voting in consortium blockchain |
-
2022
- 2022-10-10 CN CN202211235100.3A patent/CN116074310B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111683121A (en) * | 2020-05-22 | 2020-09-18 | 哈尔滨工程大学 | Cloud data tracing source block chain consensus mechanism improvement method based on DPoS |
| CN112541821A (en) * | 2020-11-18 | 2021-03-23 | 齐鲁工业大学 | Delegation rights and interests certification consensus algorithm with dynamic trust |
| CN113395164A (en) * | 2021-04-22 | 2021-09-14 | 江苏大学 | Electronic voting method based on ring signature and block chain |
Non-Patent Citations (2)
| Title |
|---|
| Blockchain based land registry with delegated proof of stake （DPoS） consensus in Bangladesh;Mahbub Alam Majumdar;《IEEEXplore》;20201102;全文 * |
| 基于信任委托的区块链分层共识优化;段靓;吕鑫;刘凡;;计算机工程;20201015(第10期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116074310A (en) | 2023-05-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11669811B2 (en) | Blockchain-based digital token utilization | |
| JP7284747B2 (en) | Execution of smart contracts with distributed cooperation | |
| CN110832825B (en) | Method and node for network for increasing verification speed by tamper-proof data | |
| US11165589B2 (en) | Trusted agent blockchain oracle | |
| Zhuang et al. | Proof of reputation: A reputation-based consensus protocol for blockchain based systems | |
| US11128522B2 (en) | Changing a master node in a blockchain system | |
| CN115210741B (en) | Partially ordered blockchain | |
| Ismail et al. | Towards a blockchain deployment at uae university: Performance evaluation and blockchain taxonomy | |
| US20190019366A1 (en) | System and method of determining ballots of voters collected with the aid of electronic balloting | |
| Hellani et al. | On blockchain technology: Overview of bitcoin and future insights | |
| Yadav et al. | A comparative study on consensus mechanism with security threats and future scopes: Blockchain | |
| CN110363527A (en) | Card, monitoring and managing method and device are deposited based on block chain | |
| US11394544B2 (en) | Validation of blockchain activities based on proof of hardware | |
| US20220141020A1 (en) | Blockchain e-voting system and operating method thereof | |
| CN110278246B (en) | Certificate storage service transfer method, device and equipment for alliance chain | |
| WO2021016546A1 (en) | Unity protocol consensus | |
| US11676111B1 (en) | Apparatuses and methods for determining and processing dormant user data in a job resume immutable sequential listing | |
| CN116361823A (en) | Selective audit processing of blockchains for privacy protection | |
| Li et al. | P-cft: A privacy-preserving and crash fault tolerant consensus algorithm for permissioned blockchains | |
| CN116074310B (en) | Block chain consensus method based on improved entrusting right evidence of ring signature | |
| CN109409899B (en) | Transaction verification method, device and system | |
| Wang et al. | Enabling integrity and compliance auditing in blockchain-based gdpr-compliant data management | |
| Himanshu | An overview of blockchain technology: Architecture and consensus protocols | |
| Noreen et al. | Advanced DAG-Based Ranking (ADR) Protocol for Blockchain Scalability. | |
| Li | The Design for Distributed Ledger Based on Main-Sub Ledger Architecture |
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 |