Block chain revision method based on weighted voting

Abstract

The invention discloses a block chain revision method based on weighted voting. Any user node proposes and broadcasts a revision request; other user nodes verify the revision request # imgabs0 #, update respective candidate revision block pools, and remove expired blocks; the system selects voting committee members based on the reputation value, and calculates the weight of the voting committee members; the system selects a user node meeting a leader reputation threshold as a leader according to a reputation consensus mechanism; the leader checks the candidate revision block pool, selects candidate revision blocks according to a first-in first-out principle, and sends voting requests to the voting committee members; performing weighted voting by the voting committee members; generating a voting result; the voting committee broadcasts votes; the leader broadcasts the new block. According to the method, the decentralization of the revision authority is realized based on a consensus voting mechanism, the revision authority is dispersed to the selected committee members, the revision credibility is high, and the applicability is high.

Description

Technical Field

[0001] The present invention belongs to the field of network security technology, and specifically relates to a blockchain revision method based on weighted voting. Background Art

[0002] As a decentralized ledger, blockchain technology is widely regarded as the most disruptive innovation in the Fourth Industrial Revolution. Immutability is an important attribute of blockchain, which ensures that verified data cannot be modified once it is uploaded to the chain. However, in many real-world applications, this mandatory immutability may not be ideal and may even hinder the development of blockchain.

[0003] In practical applications, blockchain has revision requirements in data supervision, data update and data privacy. In terms of data supervision, since anyone can upload data, some malicious users may publish illegal or unhealthy content on the chain, resulting in permanent storage of bad data, polluting the blockchain, weakening its credibility, and having a negative impact on information security and social environment. In terms of data privacy, according to the "right to be forgotten" in the General Data Protection Regulation (GDPR) promulgated by the European Union in 2016, the blockchain needs to revise user privacy data when necessary and allow all network nodes to delete relevant information. In terms of data update, the immutability of the blockchain makes it impossible to update the data on the chain. The trusted revision mechanism can meet the data update needs and improve the flexibility of the system.

[0004] In recent years, researchers have proposed a variety of amendable blockchain solutions to improve the flexibility of blockchain systems and deal with the problem of harmful data insertion. In 2017, Ateniese et al. introduced a revision mechanism based on the chameleon hash function, which used a trapdoor key to calculate the hash collision value, and for the first time realized the modification of blocks without destroying the integrity of the chain. In the same year, Puddu et al. proposed the "μ chain", which allows senders to encrypt multiple versions of transactions and attach revision strategies, but it is difficult to remove bad data on the chain.

[0005] In order to delete expired data on the blockchain, in 2019, Ren et al. constructed a blockchain with deletion function based on the space proof consensus mechanism. In the same year, Ren et al. constructed a system in which block data can be modified, which can keep the signature sub-block unchanged after obtaining the consent of a certain number of users. The system has high revision efficiency and can prevent malicious modification by setting the threshold for voting for modification operations, but only supports revisions at the block granularity. Derler et al. subsequently proposed the policy-based Chameleon Hash (PCH), which controls revision permissions through the attributes of participants and realizes fine-grained revisions at the transaction level. Ashritha et al. solved the problem of false attacks in Chameleon Hash trapdoor key sharing through nonlinear secret segmentation technology, enhancing revision security.

[0006] Marsalek et al. designed a dual hash chain model to store the original data and revised data in separate chains, and verify the legitimacy of the revision through consensus voting, but the revision granularity is coarse and the calculation is complex. In a permissionless environment, Deuber et al. first constructed a voting-based amendable blockchain protocol, which relies on consensus-based voting, does not require additional trust assumptions and complex encryption tools, supports public verification, but has a long voting cycle and low efficiency. To improve the efficiency of revision, Li et al. proposed an instant revision strategy, which decouples the voting stage of revision from the underlying consensus layer by selecting honest committee members to vote. It is suitable for PoS and PoW blockchains, but still faces the challenges of committee selection and abuse of revision rights.

[0007] Although the above research has made significant progress in improving the blockchain's revision capabilities, most of the existing revisionable blockchain schemes still face some key problems. Current revision methods are mainly based on chameleon hash functions or consensus voting mechanisms, but in practice, these two types of schemes have the following shortcomings: First, revision schemes based on chameleon hash functions usually rely on trapdoor keys for operation. However, the management of trapdoor keys often relies too much on holders or trusted third parties, which leads to excessive concentration of revision authority and violates the core concept of blockchain decentralization. Second, revision schemes based on consensus voting mechanisms require the support of computing resources or cryptocurrencies, resulting in resource-rich nodes having greater influence in voting. The existing "one person, one vote" voting paradigm is not fully suitable for the current blockchain system. The revision group still has the problem of untrustworthiness, which may lead to unfair distribution of voting rights, and the revision results cannot obtain consensus from the entire network, reducing the applicability of the revision mechanism. Summary of the invention

[0008] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide a blockchain revision method based on weighted voting with decentralized revision authority, high revision credibility and strong applicability.

[0009] The technical solution adopted to solve the above technical problems is: a blockchain revision method based on weighted voting, comprising the following steps:

[0010] Step 1. Any user node proposes and broadcasts a revision request

[0011] Step 2. Other user nodes verify the revision request And update their respective candidate revision block pools to remove expired blocks;

[0012] Step 3. The system selects voting committee members based on their reputation and calculates the weights of voting committee members;

[0013] Step 4. The system selects the user node that meets the leader's reputation threshold as the leader according to the reputation consensus mechanism;

[0014] Step 5. The leader checks its candidate revision block pool, selects a candidate revision block based on the first-in-first-out principle, and sends a voting request to the voting committee members;

[0015] Step 6. Voting committee members weighted vote

[0016] Step 6.1 Voting committee members generate member keys

[0017] The system generates private and public keys based on security parameters and votes based on the weights w of the voting committee members. i And the weighted secret sharing scheme generates a private key share [sk] with a length corresponding to the weight size i ;

[0018] Step 6.2. Pre-signature Generate relevant information required for signature

[0019] Voters generate two sets of random number shares through a weighted secure multi-party computing protocol {[r] j} j∈S and {[k] j} j∈S ,

[0020]

[0021] In the formula, S is the set of voters in the voting committee, j is the voter, and F Random A subprotocol for generating random numbers in weighted secure multi-party computation;

[0022] Voters combine the secure multi-party computation sub-protocol to generate the intermediate value {[δ] j} j∈S and {[θ] j} j∈S ,

[0023] {[δ] j} j∈S :=F Mult ({[r] j} j∈S ,{[k] j} j∈S )

[0024] {[θ] j} j∈S :=F Mult ({[r] j} j∈S ,{[sk] j} j∈S )

[0025] In the formula, {[sk] j} j∈S is the private key share of voter j, and FMult is a subprotocol in the weighted secure multi-party computing protocol that uses a multiplication gate to calculate the multiplication of two shares to obtain a new secret share;

[0026] Voters reconstruct the intermediate value δ based on the set of intermediate value shares,

[0027] δ=F Open ({[δ] j} j∈S ,{[k] j} j∈S ),

[0028] Among them, F Open It is a subprotocol for reconstructing secret shares in the weighted secure multi-party computation subprotocol;

[0029] According to the base point G on the elliptic curve and the random number share set {[k] j} j∈S Get the elliptic curve point R, R = ∑ j∈ S k j ×G, output the coordinates of the elliptic curve point R (r x ,r y );

[0030] Voters get k according to the following formula -1 The share of 0 ] j and k -1 ·sk's share [σ 1 ] j ,

[0031] [σ 0 ] j =δ -1 ·[r] j

[0032] [σ 1 ] j =[r] x ·δ -1 ·[θ]

[0033] Voter retention (r x ,[σ 0 ] j ,[σ 1 ] j ) as relevant information required for signature;

[0034] Step 6.3. Generate voting results

[0035] Each voter generates a signature share [σ] locally according to the following formula: j As a request for revision of votes,

[0036]

[0037] Where H is the hash function;

[0038] The voting committee collects signature shares of all voters {[σ] j} j∈S , according to the voter's weight ω j The final signature σ is reconstructed as follows:

[0039] σ=F Open ({[σ] j} j∈S )

[0040] Calculate the cumulative weight W of all voters, W = ∑ j∈S ω j ,If the cumulative weight W ≥ weight threshold T, the signature is valid, otherwise the signature is invalid;

[0041] The signature σ is valid and the voting result is generated Indicates a revision request Approved, signature σ is invalid, indicating a revision request Rejected;

[0042] Step 7. Voting Committee broadcasts vote

[0043] The voting committee will review the amendment request The voting results are broadcast to all user nodes, and the user nodes add the voting results to the voting pool, which is a buffer that complies with the first-in-first-out rule;

[0044] Step 8. Leader broadcasts new block

[0045] The current leader checks whether the voting pool is empty. If the voting pool is not empty, it updates the block data, adds the voting results to the new data, and updates the block hash value and the newly uploaded transaction.

[0046] The leader links the updated block to the original chain to form a new chain, clears the voting pool and broadcasts the new chain. After each user node receives the voting results, it updates the block to be revised to a new block and updates the candidate block pool.

[0047] As a preferred technical solution, the revision request for,

[0048]

[0049] si =H(G(s i-1 ,d i-1 ),proof i-1 ,ort i-1 )

[0050] In the formula, is the new revision data of block i, s i is the revision request identifier of block i, G is a collision-resistant hash function, proof i is the proof generated by the reputation consensus of block i, ort i is the old state of the Merkle root value of block i, s i-1 is the revision request identifier of the previous block, d i-1 It is the data of the previous block, proof i-1 It is the proof generated by the credibility consensus of the previous block, ort i-1 It is the old state of the Merkle root value of the previous block.

[0051] As a preferred technical solution, the other user nodes verify the revision request The method is: Check Revision Request Sino-Singapore Merkle Tree Root Value Is it consistent with the Merkle tree root value of the previous block? Calculate the hash value H of the previous block i-1 , ensure H i-1 Request for Revision The hash value of the previous block is consistent; check the revision request Medium proof i Is it valid? Ensure that the proof generated by the previous block’s reputation consensus is correct; check and ensure the revision request Middle i

[0052] Consistent with the old state of the Merkle tree root value of the previous block.

[0053] As a preferred technical solution, the system selects voting committee members based on reputation and calculates the weights of voting committee members, specifically:

[0054] Step 3.1. The user node that wants to join the candidate set pledges a certain security deposit to initialize the current reputation value of the user node and initialize the accumulated reputation value to 0;

[0055] Step 3.2. The system calculates the reputation value based on the candidate's honest and continuous contribution to the blockchain;

[0056] Step 3.3. The system selects user nodes whose reputation value is not less than the reputation threshold from the candidates to form a voting committee. The weight w of the voting committee members is calculated according to the current reputation and accumulated reputation as follows: i ,

[0057]

[0058] In the formula, α is a coefficient used to increase the impact of the cumulative reputation of voting committee members on voting. is the current reputation, is the accumulated reputation, Rep i The reputation of the voting committee members.

[0059] The beneficial effects of the present invention are as follows:

[0060] (1) Decentralization of revision authority: The consensus-based voting mechanism of the present invention realizes the decentralization of revision authority and distributes revision authority to selected committee members. Committee members sign and vote on revision requests. When the cumulative votes reach the predetermined strategy, the final voting result is generated, and the leader uploads the result to the blockchain. By introducing parallel hash chain technology, a new block structure that supports revision is constructed. Each user node revises the block according to the voting results, thereby effectively dispersing revision authority and improving the degree of decentralization of the system.

[0061] (2) High credibility of revision: The present invention selects voting committee members with high credibility through a credibility consensus mechanism. The credibility is calculated by the pledge margin and cumulative performance of the user node, and the credibility is mapped to the corresponding weight. On this basis, a weight-based voting method is used to replace the traditional one-person-one-vote model to ensure that the members of the voting committee continue to make honest contributions. This mechanism is more suitable for the blockchain environment with uneven resource allocation, and effectively improves the credibility and rationality of the revision process.

[0062] (3) Strong applicability: The present invention does not require a large amount of computing resources, nor does it rely on a third-party trusted authority to manage trapdoor keys. At the same time, the user verification process has low overhead and the system is simple to implement. This solution improves the efficiency of blockchain revision and is applicable to a variety of blockchain systems, with broad application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 It is a flow chart of the blockchain revision method based on weighted voting of the present invention. DETAILED DESCRIPTION

[0064] The present invention will be further described in detail below in conjunction with the accompanying drawings and examples, but the present invention is not limited to the following embodiments.

[0065] exist Figure 1In this embodiment, a blockchain revision method based on weighted voting includes the following steps:

[0066] Step 1. Any user node proposes and broadcasts a revision request

[0067]

[0068] s i =H(G(s i-1 ,d i-1 ),proof i-1 ,ort i-1 )

[0069] In the formula, is the new revision data of block i, s i is the revision request identifier of block i, G is a collision-resistant hash function, proof i is the proof generated by the reputation consensus of block i, ort i is the old state of the Merkle root value of block i, s i-1 is the revision request identifier of the previous block, d i-1 It is the data of the previous block, proof i-1 It is the proof generated by the credibility consensus of the previous block, ort i-1 It is the old state of the Merkle root value of the previous block;

[0070] Step 2. Other user nodes verify the revision request And update their respective candidate revision block pools to remove expired blocks;

[0071] Among them, other user nodes verify the revision request The method is: Check Revision Request Sino-Singapore Merkle Tree Root Value Is it consistent with the Merkle tree root value of the previous block? Calculate the hash value H of the previous block i-1 , ensure H i-1 Request for Revision The hash value of the previous block is consistent; check the revision request Medium proof i Is it valid? Ensure that the proof generated by the previous block’s reputation consensus is correct; check and ensure the revision request Middle i Consistent with the old state of the Merkle tree root value of the previous block.

[0072] Step 3. The system selects voting committee members based on reputation and calculates the weights of voting committee members, specifically:

[0073] Step 3.1. The user node that wants to join the candidate set pledges a certain security deposit to initialize the current reputation value of the user node and initialize the accumulated reputation value to 0;

[0074] Step 3.2. The system calculates the reputation value based on the candidate's honest and continuous contribution to the blockchain;

[0075] Step 3.3. The system selects user nodes whose reputation value is not less than the reputation threshold from the candidates to form a voting committee. The weight w of the voting committee members is calculated according to the current reputation and accumulated reputation as follows: i ,

[0076]

[0077] In the formula, α is a coefficient used to increase the impact of the cumulative reputation of voting committee members on voting. is the current reputation, is the accumulated reputation, Rep i The reputation of the voting committee members.

[0078] Step 4. The system selects the user node that meets the leader's reputation threshold as the leader according to the reputation consensus mechanism;

[0079] Step 5. The leader checks its candidate revision block pool, selects a candidate revision block based on the first-in-first-out principle, and sends a voting request to the voting committee members;

[0080] Step 6. Voting committee members weighted vote

[0081] Step 6.1 Voting committee members generate member keys

[0082] The system generates private and public keys based on security parameters and votes based on the weights w of the voting committee members. i And the weighted secret sharing scheme generates a private key share [sk] with a length corresponding to the weight size i ;

[0083] Step 6.2. Pre-signature Generate relevant information required for signature

[0084] Voters generate two sets of random number shares through a weighted secure multi-party computing protocol {[r] j} j∈S and {[k] j} j∈S ,

[0085]

[0086] In the formula, S is the set of voters in the voting committee, j is the voter, and F RandomA subprotocol for generating random numbers in weighted secure multi-party computation;

[0087] Voters combine the secure multi-party computation sub-protocol to generate the intermediate value {[δ] j} j∈S and {[θ] j} j∈S ,

[0088] {[δ] j} j∈S :=F Mult ({[r] j} j∈S ,{[k] j} j∈S )

[0089] {[θ] j} j∈S :=F Mult ({[r] j} j∈S ,{[sk] j} j∈S )

[0090] In the formula, {[sk] j} j∈S is the private key share of voter j, and FMult is a subprotocol in the weighted secure multi-party computing protocol that uses a multiplication gate to calculate the multiplication of two shares to obtain a new secret share;

[0091] Voters reconstruct the intermediate value δ based on the set of intermediate value shares,

[0092] δ=F Open ({[δ] j} j∈S ,{[k] j} j∈S ),

[0093] Among them, F Open It is a subprotocol for reconstructing secret shares in the weighted secure multi-party computation subprotocol;

[0094] According to the base point G on the elliptic curve and the random number share set {[k] j} j∈S Get the elliptic curve point R, R = ∑ j∈ S k j ×G, output the coordinates of the elliptic curve point R (r x ,r y );

[0095] Voters get k according to the following formula -1 The share of 0 ] j and k-1 ·sk's share [σ 1 ] j ,

[0096] [σ 0 ] j =δ -1 ·[r] j

[0097] [σ 1 ] j =[r] x ·δ -1 ·[θ]

[0098] Voter retention (r x ,[σ 0 ] j ,[σ 1 ] j ) as relevant information required for signature;

[0099] Step 6.3. Generate voting results

[0100] Each voter generates a signature share [σ] locally according to the following formula: j As a request for revision Voting,

[0101]

[0102] Where H is the hash function;

[0103] The voting committee collects signature shares of all voters {[σ] j} j∈S , according to the voter's weight ω j The final signature σ is reconstructed as follows:

[0104] σ=F Open ({[σ] j} j∈S )

[0105] Calculate the cumulative weight W of all voters, W = ∑ j∈S ω j ,If the cumulative weight W ≥ weight threshold T, the signature is valid, otherwise the signature is invalid;

[0106] The signature σ is valid and the voting result is generated Indicates a revision request Approved, signature σ is invalid, indicating a revision request Rejected;

[0107] Step 7. Voting Committee broadcasts vote

[0108] The voting committee will review the amendment request The voting results are broadcast to all user nodes, and the user nodes add the voting results to the voting pool, which is a buffer that complies with the first-in-first-out rule;

[0109] Step 8. Leader broadcasts new block

[0110] The current leader checks whether the voting pool is empty. If the voting pool is not empty, it updates the block data, adds the voting results to the new data, and updates the block hash value and the newly uploaded transaction.

[0111] The leader links the updated block to the original chain to form a new chain, clears the voting pool and broadcasts the new chain. After each user node receives the voting results, it updates the block to be revised to a new block and updates the candidate block pool.

Claims

1. A blockchain revision method based on weighted voting, characterized in that: The following steps are involved: Step 1. Any user node proposes and broadcasts a revision request Step 2. Other user nodes verify the revision request And update their respective candidate revision block pools to remove expired blocks; Step 3. The system selects voting committee members based on their reputation and calculates the weights of voting committee members; Step 4. The system selects the user node that meets the leader's reputation threshold as the leader according to the reputation consensus mechanism; Step 5. The leader checks its candidate revision block pool, selects a candidate revision block based on the first-in-first-out principle, and sends a voting request to the voting committee members; Step 6. Voting committee members weighted vote Step 6.1 Voting committee members generate member keys The system generates private and public keys based on security parameters and votes based on the weights w of the voting committee members. i And the weighted secret sharing scheme generates a private key share [sk] with a length corresponding to the weight size i ; Step 6.

2. Pre-signature Generate relevant information required for signature Voters generate two sets of random number shares through a weighted secure multi-party computing protocol {[r] j } j∈S and {[k] j } j∈S , In the formula, S is the set of voters in the voting committee, j is the voter, and F Random A subprotocol for generating random numbers in weighted secure multi-party computation; Voters combine the secure multi-party computation sub-protocol to generate the intermediate value {[δ] j } j∈S and {[θ] j } j∈S , {[d] j } j∈S :=F Mult ({[r] j } j∈S ,{[k] j } j∈S ) {[θ] j } j∈S :=F Mult ({[r] j } j∈S ,{[sk] j } j∈S ) In the formula, {[sk] j } j∈S is the private key share of voter j, and FMult is a subprotocol in the weighted secure multi-party computing protocol that uses a multiplication gate to calculate the multiplication of two shares to obtain a new secret share; Voters reconstruct the intermediate value δ based on the set of intermediate value shares, δ=F Open ({[d] j } j∈S ,{[k] j } j∈S ), Among them, F Open It is a sub-protocol for reconstructing secret shares in the weighted secure multi-party computation sub-protocol; According to the base point G on the elliptic curve and the random number share set {[k] j } j∈S Get the elliptic curve point R, R = ∑ j∈S k j ×G, output the coordinates of the elliptic curve point R (r x ,r y ); Voters get k according to the following formula -1 The share of 0 ] j and k -1 ·sk's share [σ 1 ] j , [s 0 ] j =d -1 ·[r] j [s 1 ] j =[r] x ·d -1 ·[θ] Voter retention (r x ,[σ 0 ] j ,[σ 1 ] j ) as relevant information required for signature; Step 6.

3. Generate voting results Each voter generates a signature share [σ] locally according to the following formula: j As a request for revision Voting, Where H is the hash function; The voting committee collects signature shares of all voters {[σ] j } j∈S , according to the voter's weight ω j The final signature σ is reconstructed as follows: σ=F Open ({[s] j } j∈S ) Calculate the cumulative weight W of all voters, W = ∑ j∈S ω j ,If the cumulative weight W ≥ weight threshold T, the signature is valid, otherwise the signature is invalid; The signature σ is valid and the voting result is generated Indicates a revision request Approved, signature σ is invalid, indicating a revision request Rejected; Step 7. Voting Committee broadcasts vote The voting committee will review the amendment request The voting results are broadcast to all user nodes, and the user nodes add the voting results to the voting pool, which is a buffer that complies with the first-in-first-out rule; Step 8. Leader broadcasts new block The current leader checks whether the voting pool is empty. If the voting pool is not empty, it updates the block data, adds the voting results to the new data, and updates the block hash value and the newly uploaded transaction. The leader links the updated block to the original chain to form a new chain, clears the voting pool and broadcasts the new chain. After each user node receives the voting results, it updates the block to be revised to a new block and updates the candidate block pool.

2. The blockchain revision method based on weighted voting according to claim 1 is characterized in that: The revision request for, s i =H(G(s i-1 ,d i-1 ),proof i-1 ,ort i-1 ) In the formula, is the new revision data of block i, s i is the revision request identifier of block i, G is a collision-resistant hash function, proof i is the proof generated by the reputation consensus of block i, ort i is the old state of the Merkle root value of block i, s i-1 is the revision request identifier of the previous block, d i-1 It is the data of the previous block, proof i-1 It is the proof generated by the credibility consensus of the previous block, ort i-1 It is the old state of the Merkle root value of the previous block.

3. The blockchain revision method based on weighted voting according to claim 2 is characterized in that: The other user nodes verify the revision request The method is: Check Revision Request Sino-Singapore Merkle Tree Root Value Is it consistent with the Merkle tree root value of the previous block? Calculate the hash value H of the previous block i-1 , ensure H i-1 Request for Revision The hash value of the previous block is consistent; check the revision request Medium proof i Is it valid? Ensure that the proof generated by the previous block’s reputation consensus is correct; check and ensure the revision request Middle i Consistent with the old state of the Merkle tree root value of the previous block.

4. The blockchain revision method based on weighted voting according to claim 1 is characterized in that: The system selects voting committee members based on reputation and calculates the weights of voting committee members, specifically: Step 3.

1. The user node that wants to join the candidate set pledges a certain security deposit to initialize the current reputation value of the user node and initialize the accumulated reputation value to 0; Step 3.

2. The system calculates the reputation value based on the candidate's honest and continuous contribution to the blockchain; Step 3.

3. The system selects user nodes whose reputation value is not less than the reputation threshold from the candidates to form a voting committee. The weight w of the voting committee members is calculated according to the current reputation and accumulated reputation as follows: i , Where α is a coefficient used to increase the impact of the cumulative reputation of voting committee members on voting. is the current reputation, is the accumulated reputation, Rep i The reputation of the voting committee members.

Images