A blockchain committee election method based on multi-party private set computation
By employing multi-party privacy aggregation computation and smart contract verification, the problems of privacy leakage, high communication and storage overhead, and insufficient fairness in blockchain committee elections are solved, achieving an efficient and secure committee election process and ensuring that the results are transparent, verifiable, and tamper-proof.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIHANG UNIV
- Filing Date
- 2025-07-18
- Publication Date
- 2026-07-24
AI Technical Summary
Existing blockchain committee election mechanisms suffer from privacy breaches, high communication and storage overhead, and insufficient committee fairness, which affect the fairness and transparency of the election and make it difficult to meet the scalability requirements of large-scale systems.
Employing multi-party privacy set computation technology, combined with verifiable random function (VRF), Bloom filter, Pedersen commitment, and zk-SNARK circuit, the system ensures the privacy and transparency of the voting process through zero-knowledge proofs, reduces communication and storage overhead, and verifies the fairness of the election results through smart contracts.
It enables efficient and secure committee elections on a large-scale blockchain platform, ensuring privacy of candidate nominations and voting preferences, reducing communication and storage overhead, improving the transparency and trustworthiness of elections, and ensuring the immutability and verifiability of results.
Smart Images

Figure CN120729608B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of blockchain technology, specifically to a blockchain committee election method based on multi-party privacy set computation. Background Technology
[0002] In recent years, with the continuous development and maturation of blockchain technology, an increasing number of blockchain platforms have adopted Committee-Based Consensus (CBC) mechanisms to address the scalability issues faced by traditional consensus mechanisms, such as Binance (BSC), Cosmos, EOS, TRON, and Algorand. The core idea is to improve consensus efficiency by electing a committee composed of a small number of nodes to be responsible for recording and verifying the blockchain. Compared to traditional single-leader consensus mechanisms, such as Proof-of-Work (PoW) or Proof-of-Stake (PoS), this method shows significant advantages in improving throughput, reducing latency, and enhancing efficiency. However, while a smaller committee can improve efficiency, it also brings the risk of reduced decentralization and malicious node attacks, thus threatening the security of the blockchain. Therefore, the voting mechanism for electing committee members is particularly crucial. The election process must ensure that honest nodes have a sufficient probability of being elected to improve security, while also preventing candidates or voters from being targeted or manipulated by external parties, in order to maintain the system's decentralization and trust foundation. Approval voting allows voters to approve multiple candidates, rather than just choosing one. This helps elect trustworthy committee members, ensuring the security and effectiveness of the system. Due to its simplicity and efficiency, the approval voting mechanism has become a common method in many existing blockchain committee election schemes. For example, EOS and Telos use approval voting to elect block producers, ensuring the decentralization and transparency of the blockchain. The existing technology has the following drawbacks: (1) Lack of privacy protection Existing committee election mechanisms often lack effective privacy protection measures, making them vulnerable to exposing voting preferences and nomination sources. Specifically, while approval voting mechanisms allow voters to cast ballots for multiple candidates, the voting results remain susceptible to exposure. For example, in EOS's approval voting mechanism, the voting preferences of candidates and their supporters could be leaked, making voters targets for external attacks, manipulation, or profit-driven actions, thus affecting the fairness and transparency of the election. The risk of privacy breaches seriously impacts the fairness and transparency of elections and exposes election participants to greater security vulnerabilities.
[0003] (2) High communication and storage overhead As the scale of blockchain nodes increases, existing committee election mechanisms, especially approval voting mechanisms, may incur significant communication and storage overhead. In approval voting mechanisms, voters can cast ballots for multiple candidates, resulting in a large amount of voting data needing to be transmitted and stored between nodes. Particularly when there are many candidates, the cost of transmitting and storing voting data increases dramatically, affecting election response speed and making it difficult to meet the scalability requirements of large-scale systems.
[0004] (3) The committee lacks fairness. Because random selection mechanisms lack a voting-based selection process, randomly chosen members may not represent the will of the majority of users, affecting the fairness of the committee. The lack of user choice in selecting candidates means that the committee cannot decide whether to elect them based on their abilities or qualifications, potentially leading to inefficient decision-making and an unreasonable committee composition. In a single-vote system, each voter can only vote for one candidate, often resulting in some voters' opinions not being fully expressed, and the election results potentially being overly concentrated on a few candidates. Furthermore, single-vote systems are susceptible to voter splitting; if there are too many candidates, votes may be dispersed, preventing highly capable candidates from being elected and affecting the committee's effectiveness and fairness. Summary of the Invention
[0005] To address the shortcomings of existing technologies, this invention provides a blockchain committee election method based on multi-party privacy set computation, which has advantages such as ensuring security and effectiveness, and solves the aforementioned technical problems.
[0006] To achieve the above objectives, the present invention provides the following technical solution: a blockchain committee election method based on multi-party privacy set computation, comprising the following steps: S1: Initialization, publishing global election parameters on the blockchain; S2: Obtain the validator set and use a verifiable random function (VRF) to randomly select the number of participants from the validator set. Converging into candidate set ; S3: From candidate set Each voter generates their corresponding vote list, which is then processed by a Bloom filter to generate a zero-knowledge proof range. For each voter in the candidate set, a 2-out-of-2 addition secret sharing operation is performed on each bit of the Bloom vector. A verifiable random function (VRF) is then called again to perform a second random allocation for each voter, and two aggregate voters are generated by sorting the lowest two bits of the output. and Each voter will allocate their two sets of shares. and Send to each and ; S4: Aggregator Voters and Each share is homomorphically added digit by digit, and each party generates a Pedersen commitment for the accumulated result and exchanges them to generate the final vote count. The system retrieves the counts for each candidate at each position, takes the minimum value as its valid vote count, and calls a pre-deployed zk-SNARK circuit to generate a zero-knowledge proof. Perform verification and output a list of committee members. ; S5: Compile the list of committee members Submitted to the smart contract, which then processes the list of committee members. Verification is performed. A smart contract is an automated program that runs on a blockchain and can automatically execute and verify transactions or operations according to preset rules. Smart contracts can automatically and transparently execute and verify the submission and verification process of committee member lists, ensuring the fairness and transparency of the entire election and verification process.
[0007] As a preferred technical solution of the present invention, the publication of global election parameters on the blockchain in S1 specifically includes: the final committee size. Expected intermediate-sized candidate set Validator's maximum approval vote threshold Bloom filter tolerance Safety parameters The general-purpose circuit CRS corresponding to the zero-knowledge proof system and the VRF parameters synchronously published by the on-chain contract. , and It is a group Generators in and It is a hash function, Pedersen promise generator. and It is a generator in Pedersen commitments, used to construct commitments and ensure their binding and privacy.
[0008] The initialization phase also needs to determine the start and end heights of the epoch for this election, the vote submission time window, the dispute period for the vote results, and the storage format of the Merkle-Root.
[0009] As a preferred embodiment of the present invention, the specific steps of S2 are as follows: S2.1: The One verifier Verifier's private key Current timestamp seed and public context context Input to local call to verify random function In Chinese, the specific expression is as follows: in, Represents a verifiable random function The evaluation algorithm in the generation process is used to generate a pseudo-random output when an input message is provided, while also providing proof that the output was computed by the given input and private key, without revealing any other information about the input. This indicates pseudo-random output. The proof value corresponding to VRF, Indicates the return value of the output; S2.2: Based on candidate set Total number of validators N Proportional calculation threshold The specific expression is as follows: in, S2.3: If < Then the verifier Advancement Candidates and put As an on-chain transaction recorded on-chain, and redirected to S2.4, if ≥ Then the verifier No advancement candidate set ; S2.4: Except for the first One verifier Other validators will be the first One verifier public key pass Function verification proof The correctness, if Then the verifier Join the local medium-sized candidate list; in, express function, Indicates the first One verifier public key, express, Indicates the return value of the output; S2.5: For the set of validators After iterating through all validators, the total number is obtained. Expected intermediate-sized candidate set ; in, They represent 1 to n validators respectively. This represents 1 to m candidates.
[0010] As a preferred embodiment of the present invention, the specific execution steps of S3 are as follows: S3.1: Candidate Set The Middle individual voters The list of approved voters must be submitted in accordance with the voting approval rules. Submit in encrypted form; S3.2: Section individual voters Generate a local file with a length of Bloom filter Then select An independent hash function The approved voting list Each candidate index in the database is mapped to of All bits are set to 1; The Bloom filter Number of digits See the following expression for how to obtain it: in, This indicates the approval threshold for voting, meaning the maximum number of votes a single voter can approve. Each candidate votes. This indicates the tolerance of the Bloom filter; The number of hash functions See the following expression for how to obtain it: in, Represents the logarithmic function with the natural logarithm as the base; S3.3: Section individual voters Attach the Bulletproof-Range zero-knowledge proof range when sending the approval vote message. and declare it within the circuit. To prove that the number of its voters does not exceed the threshold ,and The circuit is used to define and enforce various constraints related to zero-knowledge proofs, and is responsible for verifying whether the calculation results meet the constraints.
[0011] in, This represents the sum of all bits in the Bloom filter that are 1, i.e., the number of candidates supported by voters. This represents the position index of each bit in the Bloom filter; S3.4: Section individual voters For each bit of the Bloom vector Perform a 2-out-of-2 addition secret share; S3.5: Call the verifiable random function VRF again to perform a second random assignment for each voter and generate two aggregate voters based on the lowest two outputs. and .
[0012] As a preferred embodiment of the present invention, the specific steps of S4 are as follows: S4.1: Aggregator Voters and Perform homomorphic addition digit by digit to obtain the respective cumulative results. and Each of them generates a Pedersen commitment for the accumulated result and exchanges them; S4.2: Aggregator Voters and Add the sums of the individual results and take the modulo of a prime number to obtain the final vote count. ; S4.3: Aggregator Voters and According to the corresponding votes of each voter in the Bloom filter For each hash position, count the votes at each position and take the minimum value as the valid vote count for that candidate. Construct a vote vector for all candidates. Simultaneously, they jointly invoke a pre-deployed zk-SNARK circuit to generate zero-knowledge proofs. ; S4.4: Select the candidate with the most votes. No candidates ( ), to determine the final list of committee members .
[0013] As a preferred technical solution of the present invention, in S5, the smart contract sets the list of committee members. The verification process includes: verifying the submission time and ensuring the verification committee list meets the requirements. ; in, Represents the set of committee members Merkle root, Represents the set of committee members The counting vector roots, This indicates that a pre-deployed zk-SNARK circuit generates zero-knowledge proofs; If the verification is successful, the contract status will be immediately updated with the new committee's address list, and the contract will record the committee's roster. And trigger the consensus process and subscribe to that time; S5 also includes recalculating the vote during the dispute period. And verify the zero-knowledge proofs generated by the pre-deployed zk-SNARK circuit. If there is a discrepancy, a challenge transaction can be submitted, and the smart contract will automatically penalize the aggregated voters and restart the vote counting process.
[0014] Compared with existing technologies, this invention provides a blockchain committee election method based on multi-party privacy set computation, which has the following beneficial effects: 1. This invention effectively solves the problem of privacy leakage in traditional committee elections, preventing malicious nodes or external attackers from manipulating election results by analyzing voting data. By introducing multi-party privacy set computation technology, it ensures that the source of candidate nominations and voting preferences remain private throughout the election process. Combined with zero-knowledge proof technology, it achieves provable security assurance of the correctness of vote counting, making the results verifiable but the data invisible.
[0015] 2. This invention ensures data security and immutability by uploading the final election results to the blockchain via smart contracts, making the election process and results transparent and traceable to all participants. All participants and external auditors can publicly verify the results, thereby improving system transparency and trust.
[0016] 3. This invention can still meet the efficiency and security requirements of blockchain platforms for large-scale committee consensus elections. The computational tasks that are linearly related to the node size are all migrated to off-chain execution, and only constant-level summary information and zero-knowledge proofs are retained on the chain, thereby significantly reducing on-chain communication and storage overhead. Attached Figure Description
[0017] Figure 1 This is a schematic diagram of the blockchain committee election of the present invention; Figure 2 This is a schematic diagram of the blockchain committee election process of the present invention; Figure 3 This is a schematic diagram of the anonymous election process for the committee of this invention. Figure 4 This is a schematic diagram of the blockchain operation process of the present invention. Detailed Implementation
[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0019] Please see Figures 1-4 A blockchain committee election method based on multi-party privacy set computation includes the following steps: S1: Initialization, publishing global election parameters on the blockchain; The blockchain system will uniformly announce the required committee size, election rules, and various parameters for this round of election to the entire network, and write them into the on-chain state for subsequent verification by validators. Specifically, the announced content mainly includes: the final committee size. Expected intermediate-sized candidate set Validator's maximum approval vote threshold Bloom filter tolerance Safety parameters And the CRS, a general-purpose circuit corresponding to zero-knowledge proof systems. The VRF parameters are simultaneously published on the on-chain contract. Pedersen promises to generate elements This ensures that all subsequent validators execute the protocol under the same security baseline. Each validator then generates a VRF private key locally. Register the public key on the blockchain The system uses encrypted channels to ensure the confidentiality and integrity of subsequent off-chain interactions. The initialization phase also needs to determine the start and end heights of the epoch for this election, the vote submission time window, the dispute period for vote results, and the storage format of the Merkle-Root, ensuring that the entire election process can be fully verified and traced by any validator. S2: Obtain the validator set and use a verifiable random function (VRF) to randomly select the participation size of the validator set. Converging to candidate set ; During the random election phase, the system uses a verifiable random function (VRF) to randomly select participants to determine the scale of verifier participation. Converging to candidate set A committee vote is then held to elect the next candidate, replacing the traditional large-scale voting method of direct network-wide broadcasting. This reduces the communication and computational complexity of approving votes in large-scale networks from O(N) to O(N). This significantly reduces election load and response time. Each VRF random value is generated with a VRF-Proof, which can be verified instantly by any node and cannot be biased, ensuring security and fairness. Compared to existing EoS methods that rely on network-wide staking and broadcasting, this approach simultaneously ensures scalability, public verifiability, and resistance to manipulation.
[0020] First, let the set of all validators on the network be... Each validator First, call the Verifiable Random Function (VRF) locally, and pass the verifier's private key. Current timestamp seed and public context context (Including epoch, block height, and other information) as input, calculate ,in This is a pseudo-random output. This is the proof value corresponding to the VRF. The on-chain contract is based on the expected candidate size. The threshold is given by the ratio of the total number of validators (N) across the entire network. The verifier only needs to perform the threshold comparison locally. Then the verifier is identified. Advancement Candidates and put This is recorded on-chain as an on-chain transaction. Other validators can use validators. public key pass Function verification proof The correctness, if Then the verifier Add to the local medium-sized candidate list. Define statistical variables. The number of those who advance to the verification stage Ultimately, after verification by all validators... After self-comparison and on-chain verification, the resulting candidate set is as follows: .
[0021] To ensure the candidate set Probability of election failure Controlled Within this range, it needs to meet the following requirements. ,in This represents the maximum number of malicious nodes the system can tolerate. This represents the number of malicious nodes in the candidate set. This can be set according to the consensus protocol (e.g., taking 1 / 2). The smart contract can adjust the release threshold based on network size. malicious ratio Failure rate with target Calculate the number of candidate sets and threshold Set as If the number of validators N A significant change followed: the contract was automatically re-evaluated at the end of each epoch. And adjust τ to ensure that the failure probability remains stable in the long term, without having to stop operation and redeploy; S3: From candidate set Each voter generates their corresponding vote list, which is then processed by a Bloom filter to generate a zero-knowledge proof range. For each voter in the candidate set, a 2-out-of-2 addition secret sharing operation is performed on each bit of the Bloom vector. A verifiable random function (VRF) is then called again to perform a second random allocation for each voter, and two aggregate voters are generated by sorting the lowest two bits of the output. and A Bloom vector is a binary vector used to store the state of a Bloom filter, where each bit represents the level of support for a candidate in the vote. For each voter's vote list, the Bloom vector is mapped to different positions using a set of hash functions, and the values at these positions are set to 1, thus marking the candidates supported by those voters.
[0022] As shown in Figure 3, the committee's anonymous election includes a privacy-preserving nomination and merging phase and an encrypted vote counting and decision-making phase. In the privacy-preserving nomination and merging phase, the candidate set... Every voter You must submit your approved vote list in accordance with the approval voting rules. Submitted in encrypted form. The approval voting rules allow validators to cast their votes for multiple highly credible candidates at once, rather than being forced to put all their votes on one person. The advantage of this approval voting rule is that it fully utilizes the credible information held by validators and significantly reduces the risk of miscasting or single-point manipulation in probabilistic statistics. Compared to the traditional EOS method of reporting approval votes in plaintext, the privacy-focused nomination merging phase uses Bloom filters and additive secret sharing to ensure that no node or aggregator can discern individual voting preferences, and that any tampering by any party will be detected immediately, achieving efficient, low-cost, and completely anonymous nomination collection.
[0023] Regarding Bloom filters, existing blockchain solutions treat them as public indexes, for example, by writing block hashes into multi-layered Bloom filter skip lists to compress on-chain data and accelerate random queries. This approach aims to improve data reading performance, but the entire bitmap is public to everyone, offering neither privacy nor support for subsequent secure computation. In traditional privacy computing, Bloom filters are used for set operations, but the output is limited to Boolean results of "present / absent," making it impossible to count votes and even more difficult to meet the needs of election vote counting scenarios. This invention, for the first time, combines Bloom filters with additive secret sharing and a minimum value strategy to ensure efficient, low-communication, and fully auditable anonymous vote counting without revealing any single point of voting content. Moreover, only constant-level data is needed on the blockchain to publicly verify the correctness of the vote counting.
[0024] During the privacy nomination consolidation phase, each voter First, generate a local file with a length of Bloom filter Then select Each independent hash function The list of approved voters will be published. Each candidate index in the database is mapped to of Each bit is set to 1. The size of the intermediate set can be determined from the parameters published on the chain. Approval threshold (A single voter can vote for a maximum of 100 people) (candidate votes) and Bloom filter tolerance Calculation formula The position length can be obtained With hash number Due to the Bloom filter Only "existence / non-existence" is marked, so even if the voting results are publicly verified, it is impossible to directly deduce which candidates a particular voter supported. For each voter... In other words, the number of people actually voted on the approved vote list The number of candidates is often much smaller than that of a medium-sized candidate set, for example, the number of candidates set by the system to the top of the candidate set. Voters select the most credible candidate. To prevent malicious voters from constructing full-1 Blooms and causing large-scale false positive noise, voters... When sending the approval vote message, the Bulletproof-Range zero-knowledge proof range must be attached. Declare within the circuit To prove that the number of its voters does not exceed the threshold The publicly available proof only includes Pedersen's commitment. The set of public messages during the proof process; aggregated voters must execute offline before receiving their shares. Verification of this proof is required; only shares that pass verification will proceed to the subsequent vote counting process. Verifiers who fail verification will be rejected, and any attempt to maliciously vote will be rejected due to the inability to provide a legitimate verification result. And are filtered out in real time.
[0025] Secondly, each voter For each bit of the Bloom vector Perform 2-out-of-2 addition secret sharing, that is, for any bit Generate random values ,make Each voter Generated random shares satisfy This means that neither party possesses half the information, and a single share is insufficient to determine whether a bit is 0 or 1. To prevent centralized manipulation of aggregated voters, the system can again invoke a verifiable random function (VRF) for each voter. Perform a second random assignment and generate two aggregate voters based on the lowest two output values. and Each voter Two groups of shares and Send to each and .because It follows a uniform distribution, and no single party can infer the true bit from a single share, thus completely hiding voting preferences; S4: Aggregator Voters and Each share is homomorphically added digit by digit, and each party generates a Pedersen commitment for the accumulated result and exchanges them to generate the final vote count. The system retrieves the number of valid votes for each candidate and uses a pre-deployed zk-SNARK circuit to generate a zero-knowledge proof. Perform verification and output a list of committee members. ; Compared to the traditional on-chain vote counting method of EOS, the encrypted vote counting and decision-making phase combines homomorphic summation and zero-knowledge proof technology to ensure that any node only needs to verify a constant-level proof to be certain that the vote count is absolutely correct and has no leakage. If the aggregator modifies any content without authorization, its corresponding commitment and proof immediately become invalid and are rejected on the chain. This design ensures that the results are publicly auditable and non-repudiable, and even if a unilateral aggregator is compromised, the voting data cannot be leaked or tampered with.
[0026] During the encrypted vote counting and decision-making phase, aggregate voters and Off-chain, each entity will perform homomorphic addition on its own share, bit by bit, and obtain the result. , Subsequently, both parties generate Pedersen commitments based on the accumulated results. and They will exchange the accumulated votes, ensuring that neither party can tamper with the aggregated voting data. After the exchange, they will add the two accumulated shares together and sum them against prime numbers. Taking the modulo operation, we obtain the final vote count for that index position. In this way, the true counts of all Bloom bits are reconstructed, and no single party can recover the original plaintext vote. Subsequently, the voters are aggregated. and Based on each voter's corresponding vote in the Bloom filter Given a hash position, retrieve the count for each position and take the minimum value as the valid vote count for that candidate. For candidate indexes of hash locations Take the minimum value That is, the number of votes received. The minimum-value strategy is equivalent to the possibility of mistakenly counting a non-voted element as a vote only when all slots mapped to by the hash function have collided with other elements. This is similar to the probability of a false positive in a naive Bloom filter. They are completely consistent. Therefore, as long as the Bloom filter fault tolerance is set during system initialization... Setting the value low enough will negate the occurrence of this miscounting event. Secondly, taking the minimum value ensures that false positive votes do not exceed the actual votes, and the candidate's vote count will only be undercounted, not overcounted. Finally, the number of votes cast by the validator remains monotonic, so even if a false positive occurs, low-vote candidates will not be incorrectly added to the top. Among the candidates.
[0027] Aggregator Voters and After obtaining the vote vector of all candidates Then, they jointly invoked the pre-deployed zk-SNARK circuit to generate zero-knowledge proofs. Among these, the aggregating voters must jointly declare constraints in the circuit, i.e. ; ; This proof ensures that each candidate's votes are correctly calculated based on the commitments made by both parties, that all counts have not been privately modified, and that the subsequent ranking process is fair and unbiased. Because zk-SNARKs possess zero-knowledge properties, any third party only needs to verify the proof to be certain of the vote count's accuracy, without needing to access the voters' plaintext votes. Finally, the aggregators select the candidates with the highest votes according to the Top-K rule without revealing any intermediate count details. No candidates ( ), to determine the final list of committee members ; S5: Compile the list of committee members Submitted to the smart contract, which then processes the list of committee members. Perform verification; As shown in Figure 4, after the election calculation is completed, the voters are aggregated. Collection of committee members Merkle root Counting vector roots and The results are submitted to the smart contract to prove that the election results are calculated based on legitimate scoring inputs and established rules, without revealing the scoring of any individual voter or specific details of the calculation process. Upon receiving the transaction, the contract first verifies whether the submission time falls within the system's preset "result submission window" to prevent malicious rollback of old or duplicate data. Secondly, the contract logic calls the verification function to determine whether the committee list meets the requirements. If the verification is successful, the contract status will be immediately updated with the new committee's address list, and the contract will record the committee's roster. This triggers the consensus module to subscribe to that time. All validators can read it on-chain. , And the proof This ensures the correctness, finality, and immutability of election results and vote counts, preventing manipulation by intermediaries or malicious actors. Regarding the genesis committee, the system must directly write the committee address set into the genesis configuration file upon startup to execute the consensus process for the first epoch. The genesis committee is the initial committee designated at system startup, and its members execute the consensus process within the first epoch of the blockchain. The genesis configuration file is the blockchain system's initialization file, used to define the initial settings and parameters of the blockchain. During the next epoch transition, the system automatically loads the latest committee list to complete the blockchain consensus module's operation. Validating nodes can recalculate during the dispute period. And verify the zero-knowledge proofs stored on the blockchain. Once an inconsistency is discovered, a challenge transaction can be submitted, and the contract will automatically penalize the aggregator and restart the vote counting process.
[0028] The blockchain committee election method based on multi-party privacy set computation proposed in this invention mainly comprises four core parts: data interaction, verifiable random function (VRF) random lottery, anonymous committee election, and the submission and verification stage of election results. These four parts, through the combination of privacy computation and off-chain voting mechanisms, ensure privacy, efficiency, and fairness in the committee election process. Compared to traditional large-scale committee election methods, this invention reduces on-chain election communication complexity from O(N) to O(…). Each validator's off-chain bandwidth is only O( On-chain verification requires only a single constant-level call to confirm correct vote counting and sorting, reducing on-chain gas consumption costs. For example, in a large-scale network with N = 2000 validators, a maximum of t = 10 votes per voter, and a committee fault tolerance probability... Bloom's fault tolerance With a Bloom filter length h ≈ 640 bits and each message ≈ 48 bytes, traditional approval voting requires broadcasting each vote across the entire network, resulting in a communication and vote counting complexity of O(Nt) = 2 × 10^6. 4 With a time complexity of approximately 0.96 MB, this invention utilizes a VRF function to reduce the election size to 160. Combined with a Bloom filter and encrypted secret sharing technology, the voting process can be completed in just 2 × h ≈ 64 kB, reducing the complexity to O(h). Gas costs are only incurred during on-chain and off-chain data interactions, and validators only need a single constant-level call to confirm correct vote counting and sorting. Figure 2 The specific process of the committee election method is described, including initial setup, random election, privacy-preserving nomination merging, cryptographic vote counting and decision-making, and on-chain submission and verification of results.
[0029] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A blockchain committee election method based on multi-party privacy set computation, characterized in that: Includes the following steps: S1: Initialization, publishing global election parameters on the blockchain; S2: Obtain the validator set and use a verifiable random function (VRF) to randomly select the number of participants from the validator set. Converging into candidate set ; S3: From candidate set Each voter generates their corresponding vote list, which is then processed by a Bloom filter to generate a zero-knowledge proof range. In the candidate set, each voter performs a 2-out-of-2 addition secret sharing operation on each bit of the Bloom vector. A verifiable random function (VRF) is then called again to perform a second random allocation for each voter, and two aggregate voters are generated by sorting the lowest two bits of the output. and Each voter will allocate their two sets of shares. and Send to each and ; S3 includes: S3.1: Candidate Set The Middle individual voters The list of approved voters must be submitted in accordance with the voting approval rules. Submit in encrypted form; S3.2: Section individual voters Generate a local file with a length of Bloom filter Then select An independent hash function The approved voting list Each candidate index in the database is mapped to of All bits are set to 1; S4: Aggregator Voters and Each share is homomorphically added digit by digit, and each party generates a Pedersen commitment from the accumulated result and exchanges them to generate the final vote count. The system retrieves the counts for each candidate at each position, takes the minimum value as its valid vote count, and calls a pre-deployed zk-SNARK circuit to generate a zero-knowledge proof. Perform verification and output a list of committee members. ; S4 includes: S4.1: Aggregator Voters and Each share is added digit by digit using homomorphic addition to obtain its respective cumulative result. and Each of them generates a Pedersen commitment for the accumulated result and exchanges them; S4.2: Aggregator Voters and Add the sums of the individual results and take the modulo of a prime number to obtain the final vote count. ; S4.3: Aggregator Voters and Based on each voter's corresponding vote in the Bloom filter For each hash position, count the votes at each position and take the minimum value as the valid vote count for that candidate. Construct a vote vector for all candidates. Simultaneously, they jointly invoke a pre-deployed zk-SNARK circuit to generate zero-knowledge proofs. ; For candidate indexes of hash locations Take the minimum value That is, the number of votes received. ; S5: Compile the list of committee members Submitted to the smart contract, which then processes the list of committee members. Perform verification.
2. The blockchain committee election method based on multi-party privacy set computation according to claim 1, characterized in that: The specific global election parameters published on the blockchain in S1 include: the final committee size. Expected intermediate-sized candidate set Validator's maximum approval vote threshold Bloom filter tolerance Safety parameters The general-purpose circuit CRS corresponding to the zero-knowledge proof system and the VRF parameters synchronously published by the on-chain contract. , and It is a group generators in and They are different hash functions; Pedersen promises generators. and It is a generator in Pedersen commitments, used to construct commitments and ensure their binding and privacy; The initialization phase also needs to determine the start and end heights of the epoch for this election, the vote submission time window, the dispute period for the vote results, and the storage format of the Merkle-Root.
3. The blockchain committee election method based on multi-party privacy set computation according to claim 1, characterized in that: The specific steps of S2 are as follows: S2.1: The One verifier Verifier's private key Current timestamp seed And the public context input to the local call verifiable random function. In Chinese, the specific expression is as follows: ; in, Represents a verifiable random function Evaluation algorithms during the generation process This indicates pseudo-random output. The proof value corresponding to VRF, Indicates the return value of the output; S2.2: Based on candidate set Threshold calculated based on the ratio to the total number of validators N The specific expression is as follows: ; in, |N| represents the number of candidate sets and the total number of validators, respectively; S2.3: If < Then the verifier Advancement Candidates and put As an on-chain transaction recorded on-chain, and redirected to S2.4, if ≥ Then the verifier No advancement candidate set ; S2.4: Except for the first One verifier Other validators will be the first One verifier public key pass Function verification proof The correctness, if Then the verifier Join the local medium-sized candidate list; in, express function, Indicates the first One verifier public key, Indicates the return value of the output; S2.5: For the set of validators After iterating through all validators, the total number is obtained. Expected intermediate-sized candidate set ; in, They represent 1 to n validators respectively. This represents 1 to m candidates.
4. The blockchain committee election method based on multi-party privacy set computation according to claim 3, characterized in that: S3 further includes: S3.2 also includes: The Bloom filter Number of digits See the following expression for how to obtain it: ; in, This indicates the threshold for approving a vote, meaning the maximum number of votes a single voter can approve. Each candidate votes. This indicates the tolerance of the Bloom filter; The number of hash functions See the following expression for how to obtain it: ; in, Represents the logarithmic function with the natural logarithm as the base; S3.3: Section individual voters Attach the Bulletproof-Range zero-knowledge proof range when sending the approval vote message. and declare it within the circuit. To prove that the number of its voters does not exceed the threshold ,and The circuit is used to define and enforce constraints, and is responsible for verifying whether the calculation results meet the constraints. in, This represents the sum of all bits in the Bloom filter that are 1, i.e., the number of candidates supported by voters. This represents the position index of each bit in the Bloom filter; S3.4: Section individual voters For each bit of the Bloom vector Perform a 2-out-of-2 addition secret share; S3.5: Call the verifiable random function VRF again to perform a second random assignment for each voter and generate two aggregate voters based on the lowest two outputs. and .
5. A blockchain committee election method based on multi-party privacy set computation according to claim 4, characterized in that: S4 further includes: S4.4: Select the candidate with the most votes. No candidates To determine the final list of committee members .
6. A blockchain committee election method based on multi-party privacy set computation according to claim 5, characterized in that: In S5, the smart contract sets the list of committee members. The verification process includes: verifying the submission time and ensuring the verification committee list meets the requirements. ; in, Represents the set of committee members Merkle root, Represents the set of committee members The counting vector roots, This indicates that a pre-deployed zk-SNARK circuit generates zero-knowledge proofs; If the verification is successful, the contract status will be immediately updated with the new committee's address list, and the contract will record the committee's roster. And trigger the consensus process and subscribe to that time; S5 also includes recalculating the vote during the dispute period. And verify the zero-knowledge proofs generated by the pre-deployed zk-SNARK circuit. If there is a discrepancy, a challenge transaction can be submitted, and the smart contract will automatically penalize the aggregated voters and restart the vote counting process.