Efficient distributed zero-knowledge proof method based on binary field

Abstract

The invention discloses an efficient distributed zero-knowledge proof method based on a binary field. According to the method, a traditional centralized zero-knowledge proof task is divided into a plurality of sub-tasks, and the sub-tasks are allocated to a plurality of servers to generate proof in parallel; the method comprises the steps of data preprocessing, parameter setting by a server, zero check proof generation, greedy evaluation check proof generation, small domain polynomial commitment proof generation, client scheduling and aggregation, and verification proof. According to the method, the computing performance of each server is dynamically evaluated, tasks of different sizes are allocated according to the processing capacity of each server, and load balancing and resource optimization utilization are realized; a binary field is adopted as an operation basis, and addition and multiplication operations can be directly performed on large-scale bit-level data, so that the complexity of circuit expression and the calculation overhead are remarkably reduced. In addition, the method also supports the safe execution of the intermediate proof generation step under the multi-party computing framework, and improves the overall privacy protection capability and expandability.

Description

Technical Field

[0001] The present invention relates to an efficient distributed zero-knowledge proof method based on a binary domain, belonging to the field of network security, and involving the fields of privacy protection and data security technology. Background Art

[0002] Zero-knowledge succinct non-interactive proofs achieve efficient privacy protection by compressing proof size and reducing verification costs. They are widely used in blockchain smart contracts, distributed identity authentication, and privacy-preserving computing. Their zero-knowledge nature conceals the proof's content, their simplicity ensures verification efficiency, and their non-interactivity eliminates round-trip communication overhead. However, the circuit reductions and algebraic transformations involved in generating proofs rapidly increase in computational complexity, consuming significant resources. This is especially true for polynomial computations in resource-constrained environments. To alleviate these bottlenecks, distributed methods are used to parallelize core computational tasks to improve efficiency, but they still face challenges such as communication and synchronization overhead, as well as inefficiencies in finite fields under Boolean logic.

[0003] While existing distributed zero-knowledge proof methods theoretically possess parallel scalability, they still face numerous challenges in practical deployment. For one thing, the division of proof generation tasks across multiple servers often lacks flexibility, leading to uneven load and wasted resources. Furthermore, computations based on large prime number fields are inefficient in circuits heavily populated with Boolean logic or bit shift operations, making them difficult to adapt to lightweight network environments. Summary of the Invention

[0004] In response to the shortcomings of the aforementioned prior art, the present invention aims to provide an efficient distributed zero-knowledge proof method based on binary fields. By combining distributed zero-knowledge proof with binary field technology, this method overcomes resource utilization and performance limitations. This method dynamically evaluates the computing performance of each server and allocates tasks of varying sizes based on their processing power, achieving load balancing and optimizing resource utilization. By using binary fields instead of traditional Boolean logic as the basis for operations, it can directly perform addition and multiplication operations on large amounts of bit-level data, significantly reducing the complexity of circuit representation and computational overhead. Furthermore, this method supports the secure execution of intermediate proof generation steps within a multi-party computation framework, enhancing overall privacy protection and scalability.

[0005] The technical solution of the present invention is: an efficient distributed zero-knowledge proof method based on binary domain, including data preprocessing, server parameter setting, generation of zero check proof, generation of greedy evaluation check proof, generation of small domain polynomial commitment proof, client scheduling and aggregation, and verification of proof. The specific steps are:

[0006] Step 1: Data preprocessing: The client quantifies the performance indicators of each server based on the feedback results after the server test, divides the total witness into sub-witnesses on the binary domain and assigns them to each server, and generates preprocessing information for polynomial generation and sub-proof construction.

[0007] Step 2: Parameter setting: The client generates unified public parameters in the binary domain based on the security parameters and the relationship to be proved. All servers and verifiers load the parameters and collaboratively perform calculations and proof generation in the same encryption environment.

[0008] Step 3: Generate zero-check proofs: Each server generates a set of local proofs that satisfy zero-check based on polynomials over the binary field. All local proofs are merged into batches of zero-check proofs and zero-check evaluation values ​​through mixing and evaluation operations.

[0009] Step 4: Generate greedy evaluation check proof: Perform consistency evaluation based on linear operations of the binary domain, and finally generate an evaluation proof set by mixing local proof results.

[0010] Step 5: Generate a small-field polynomial commitment proof: Generate intermediate results on the binary field and perform a weighted average operation; at the same time, construct a Merkle proof based on the binary field, and finally generate a commitment output containing the aggregated result and a unified Merkle proof.

[0011] Step 6: Client Scheduling and Aggregation: The client does not directly participate in the computation. Instead, it is responsible for task scheduling and receiving zero-check proofs, greedy evaluation check proofs, and small-field polynomial commitment proofs from each server. It then aggregates these sub-proofs generated over binary fields in batches to generate a unified aggregate proof. This aggregate proof is then submitted to the verifier for verification in Step 7.

[0012] Step 7: Verify the Proof: After receiving the public parameters, public inputs, and the aggregated final proof, the verifier generates a challenge value from the commitment based on the Fiat-Shamir hash function transformation, checks whether the polynomial relationship holds at the verification point, performs polynomial commitment verification, and finally outputs the verification result.

[0013] Preferably, the step 1 specifically includes:

[0014] Step 1.1: Performance Evaluation. The client performs computationally intensive tasks on each server, evaluating the server's computation time and resource consumption, and quantifying its computational performance metrics as the basis for task allocation weights. This evaluation task is constructed on a binary domain to reflect the server's actual computing capacity within that domain.

[0015] Step 1.2: Witness Partitioning and Distribution. The total witness is represented as a vector on a binary domain. It is then dynamically divided into multiple sub-portions based on the performance metrics of each server and distributed to each server. This ensures that task allocation matches processing capacity and that the partitioning results maintain their binary domain representation during computation.

[0016] Step 1.3: Preprocessing generation. Construct local circuit mapping and polynomial structure on the binary domain, and each server generates corresponding preprocessing information pre i , which is used as the scheduling basis for local polynomial construction, proof generation and task execution in steps 3 to 5.

[0017] Preferably, in step 2, the public parameters include a universal reference string, a circuit structure code, zero-knowledge parameters and verification parameters.

[0018] Preferably, the step 3 specifically includes:

[0019] Step 3.1: Generate batch proofs. After receiving the secret shared shares of the local polynomial, each server interpolates and reconstructs it on the binary field and generates corresponding sub-challenges α for each statement based on the global challenge α. i , a local zero-check proof is calculated on the binary domain to verify whether its local calculation satisfies the constraint relationship; the zero-check proofs generated by all servers are then packaged to form a batch combined proof.

[0020] Step 3.2: Receive zero-check proofs. Each server sends the zero-check proofs for the current batch to the client.

[0021] Step 3.3: Hybrid Proof and Evaluation. In this process, each server evaluates the local constraint polynomial at a specific evaluation point and obtains a zero-check evaluation value E. r All zero-check proofs are batched together into a unified proof and sent to the client. The client combines the received proof with the zero-check evaluation value {P r , E r}, the update rule is to update all P r and E r Perform mixing operations to form new {P′ r , E′ r}.

[0022] In the present invention, in step 3, zero-check proofs are generated in a distributed manner, that is, servers are allowed to collaborate to generate batch zero-check proofs based on local secret sharing shares on the basis of binary domains; generating zero-check proofs is a basic legitimacy verification of polynomial relationships. Each server generates a zero-check proof for its own calculated local polynomial and constraints, proving that a certain structured polynomial has a value of 0 at a certain specific point. This stage tends to be a "basic correctness check."

[0023] Preferably, the step 4 specifically includes:

[0024] Step 4.1: Initialize the proof. Each server selects a challenge α from a pre-set distribution i , used to generate a consistency evaluation proof based on the witness w. In the binary domain Evaluate its local polynomial on the i , as input to generate the consistency assessment proof.

[0025] Step 4.2: Reduce and combine the proofs. All servers merge their respective consistency evaluation proofs to form a preliminary set of consistency evaluation proofs. The servers then perform a virtual open operation based on binary domain linear operations, update their local proofs based on the new challenge value and evaluation results, generate a virtual proof, and broadcast it.

[0026] Step 4.3: Aggregation. After multiple rounds of evaluation and aggregation, each server finally generates a batch proof that contains all the challenge-response pairs and the consistency evaluation proof set for the verification process.

[0027] In the present invention, in step 4, the greedy evaluation check proves that the consistency of the evaluation and the declaration is checked. This step is to mix the "declarations" of each server together to see if there are any conflicts - this is achieved through the evaluation check protocol. Step 4 will rely on the evaluation point or evaluation status provided by step 3 in the construction (such as E i ).

[0028] Preferably, the step 5 specifically includes:

[0029] Step 5.1: Each server generates an intermediate result t based on the binary field polynomial calculation i ′ , including the consistency evaluation proof. Next, the challenger generates a challenge vector and i ′ Perform a weighted average operation to mix the calculation results of each server through different challenge coefficients.

[0030] Step 5.2: While generating the intermediate results, each server generates a Merkle proof in the binary domain based on its local results to prove the validity and traceability of its calculation results.

[0031] Step 5.3: All servers merge their generated Merkle proofs to obtain a globally consistent set of proofs; the final proof consists of the mixed intermediate value and the merged Merkle proof as the output of the small field polynomial commitment.

[0032] Preferably, the final commitment structure includes both the aggregated results of multiple server consistency evaluation values ​​and a unified Merkle proof, and the Merkle proof is constructed in a binary domain and supports unified verification.

[0033] In this invention, in step 5, the evaluation value from step 4 is used as input to generate the corresponding commitment and Merkle path. Generating a small-domain polynomial commitment proof verifies the commitment and consistency of the polynomial value at the evaluation point. After steps 3 and 4 are completed without any problems, a compressed commitment is generated for the entire calculation result, and the evaluation value and calculation proof are packaged and delivered to the client.

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] (1) Higher flexibility

[0036] The present invention adopts a task scheduling algorithm, which can flexibly allocate tasks according to the performance of the server, such as polynomial evaluation, commitment generation, sub-proof construction and verification, etc., and give full play to the performance and collaboration capabilities between different servers, thereby effectively solving the problem of server resource waste in distributed zero-knowledge proof.

[0037] (2) Performance improvement

[0038] This paper uses binary tower recursion to extend binary fields, supporting deeper recursive proofs. By generating higher-order finite fields, deeply recursive polynomial computations can be performed more efficiently. This extension optimizes the performance of deeply recursive proofs and significantly reduces the computational complexity of generating and verifying proofs.

[0039] (3) Reduced resource consumption

[0040] This method utilizes a distributed secret sharing algorithm and local computation optimization techniques to divide the polynomial coefficients and intermediate states in a zero-knowledge proof into multiple shares using a secret sharing algorithm, which are then distributed to participating servers. Each server only needs to store and process its own share and perform the relevant computations locally, without having to restore the complete proof structure or access data from other servers. This method significantly reduces the memory and computing resource requirements of a single node, and the computation time is significantly shorter than that required for standalone computations. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is the distributed zero-knowledge proof flow chart of the present invention.

[0042] Figure 2 This is a comparison diagram of the generation proof of the zero-knowledge proof of the present invention.

[0043] Figure 3 It is a comparison chart of proofs generated by the server in the present invention under different network bandwidths.

[0044] Figure 4 This is a comparison chart of the working time of the leader node in the present invention for allocating witnesses, scheduling tasks, etc. under different network bandwidths.

[0045] Figure 5 This is a comparison chart of the proof generation time between this invention and the most advanced distributed zero-knowledge proof zkSaaS and ScablezkSNARK. DETAILED DESCRIPTION

[0046] To further illustrate the purpose, technical content and advantages of the present invention, the method of the present invention is further described below with reference to the accompanying drawings and embodiments.

[0047] Experimental Environment: The leader node in this paper runs on an AWS c7.2xlarge cloud instance with 16GiB of memory. Half of the worker nodes are deployed on c7.large instances (4GiB of memory) and the other half are deployed on c7.xlarge instances (8GiB of memory). This mixed deployment setup enables us to evaluate the impact of different hardware capabilities on the generation and evaluation of distributed commitment proofs. We conduct experiments on different servers at different circuit scales (from 2 20 to 2 26 ) and evaluated the performance under different bandwidth environments (100Mbps and 4Gbps).

[0048] like Figure 1 As shown, an efficient distributed zero-knowledge proof method based on binary domain includes the following steps:

[0049] Step 1: Data preprocessing: The client quantifies the performance indicators of each server based on the feedback results after the server test, divides the total witness into sub-witnesses on the binary domain and assigns them to each server, and generates preprocessing information for polynomial generation and sub-proof construction.

[0050] Because the binary domain consists of only two numbers: 0 and 1, it is well-suited for implementation in Boolean circuits, XOR operations, and SIMD parallel computing. It is more consistent with the underlying computer logic and offers excellent computational performance. In this invention, the client evaluates the performance of each participating server and preprocesses the input data. This initialization process is used to assess the computing power of each server, enabling reasonable task allocation and efficient collaboration, thereby ensuring load balancing and maximizing resource utilization in distributed zero-knowledge proofs. Specifically, the following steps are performed:

[0051] Step 1.1: Performance Evaluation

[0052] The client assigns standardized computationally intensive test tasks to each server.

[0053] After each server completes the test, the calculation time and resource usage are returned.

[0054] The client quantifies the performance indicators of each server based on the feedback results Used as a reference for task assignment weights in step 6.

[0055]

[0056] Where T i is the computing time of server i, M i is the memory usage, and λ1 is the coefficient that adjusts the ratio of calculation to memory.

[0057] This assessment task is based on The set polynomial operation construction ensures that the evaluation performance can truly reflect the ability to perform large-scale bit-level calculations on binary fields.

[0058] Step 1.2: Witness Division and Distribution

[0059] The present invention will witness the total w according to the computing performance of the server Divide into N subparts w i , where the size of the child witness obtained by the i-th worker |w i |∝P i ,satisfy This division process is the core basis for task allocation, which not only determines the amount of data processed by each server, but also directly affects the load of polynomial generation, commitment and proof generation in the calculation. i Stay in the binary domain The representation on the server is sent to the corresponding server S through a secure channel. i .

[0060] Step 1.3: Preprocessing Generation

[0061] Server S i Received w i After that, the corresponding circuit gate mapping, clue allocation, polynomial structure and other preprocessing information are calculated.

[0062] pre i =Preprocess(w i )

[0063] pre i Contains information such as intermediate states, index mappings, local polynomials, etc. required for task division, all defined in the binary domain It is used to quickly locate the local subtask location and dependencies within the server in steps 3 to 5 to support polynomial generation and sub-proof construction.

[0064] Step 2: Parameter setting: The client generates unified public parameters in the binary domain based on the security parameters and the relationship to be proved. All servers and verifiers load the parameters and collaboratively perform calculations and proof generation in the same encryption environment.

[0065] The client executes the Setup function based on the security parameter λ and the relationship to be proved R to generate the public parameter pp, including the core content such as verification parameters and reference strings, which are used to establish a unified encryption environment. The details are as follows:

[0066] First, the client executes the zk-SNARK Setup function based on the given security parameter λ and the relation to be proved R.

[0067] Setup(1 λ ,R)→pp

[0068] Among them 1 λ The unary representation of the security parameter λ, which is used to control the security level, such as against 2 λ Time complexity attack.

[0069] Relation R corresponds to language where x pub is the public input and w is the witness.

[0070] The output pp is a public parameter, including: universal reference string, circuit structure code, zero-knowledge parameters, and verification parameters.

[0071] Then, all participating servers and verifiers load the public parameter pp and perform the proof in the same encryption environment.

[0072] All servers must perform polynomial operations, constraint system transformations, commitment and proof generation under the same circuit representation and security level to ensure that the generated sub-proofs can be correctly combined in the final aggregation stage and meet unified verification logic and security requirements.

[0073] Step 3: Generate zero-check proofs: Each server generates a set of local proofs that satisfy zero-check based on polynomials over the binary field. All local proofs are merged into batches of zero-check proofs and zero-check evaluation values ​​through mixing and evaluation operations.

[0074] The present invention first converts a polynomial Its commitment value is C = Commit(P), where is a binary domain, is the independent variable of the polynomial, and C is the polynomial commitment value generated by the commitment algorithm. Then each server receives the secret share of the polynomial P(x). The coefficients of the polynomial are a0, a1, ..., a n needs to be divided into N parts (each server holds a part), and each coefficient a i are distributed to multiple participants through a secret sharing algorithm. The secret sharing form is:

[0075]

[0076] in It is server S j Each server can only see the shares it holds and cannot access the shares of other servers. j Based on the secret sharing share a ij , evaluate the polynomial p at a specific point x0 i The value of (x).

[0077] Distributed zero-check proofs are designed to verify that all participating parties have correctly executed local computations within circuit constraints without leaking local data. This mechanism ensures that each server, while holding only partial secret information, can collaboratively verify polynomial relationships, effectively improving the system's scalability and tamper resistance. Specifically:

[0078] Step 3.1: Generate batch proof

[0079] Generate a series of challenges {α for each claim based on the challenge α i} i =1 n , where each challenge α iIt is sampled from a pre-set distribution. i =(p i (x), W i ) calculates the corresponding zero check proof, the formula is:

[0080] ZerocheckProof i =ZerocheckProof(p i (x), W i , α i )

[0081] Each ZerocheckProof(p i (x), W i , α i ) is the local polynomial p computed on the authentication server i (x) whether it satisfies the zero constraint (i.e., p i (x)=0), which is to generate a "local zero check proof" based on the polynomial coefficients

[0082] Finally, a batch of zero-check proofs π is generated as a combined proof of all the claims:

[0083]

[0084] in, It comes from the interpolation calculation of each server's local secret sharing share and reflects the structure of the polynomial coefficients.

[0085] Step 3.2: Receive Zero Inspection Certificate

[0086] Each server sends the zero-check proof Π of the current batch to the client.

[0087] Step 3.3: Hybrid Proof and Evaluation

[0088] The client updates its local state based on the received zero-check proof and zero-check evaluation value. For each round of zero-check proof and zero-check evaluation value P r , E r , the update rule is to update all P r and E r Perform MixProof operation and multiplication and accumulation operation π respectively to form a new {P r ′, E r ′}:

[0089]

[0090] Among them, P r Denotes the cumulative proof maintained by the client, P iFor the i-th zero-check proof submitted by the server, E r is the existing zero-check evaluation value, and E i is the i-th zero check evaluation value submitted by the server. The above aggregation operations and evaluations are based on the binary domain is being carried out.

[0091] Step 4: Generate greedy evaluation check proof: Perform consistency evaluation based on linear operations of the binary domain, and finally generate an evaluation proof set by mixing local proof results.

[0092] The core of the distributed greedy evaluation proof proposed in this paper lies in compressing multiple evaluation statements into a single Polynomial Commitment Scheme (PCS) by alternating between evaluation verification and sum verification without revealing the polynomial structure, thereby reducing verification overhead and communication costs. This process is performed collaboratively by each server in a distributed environment, calculating based on local shares and a shared challenge value, achieving a low-interaction, high-efficiency consistency proof. The details are as follows:

[0093] Step 4.1: Initialize the proof

[0094] Each server S i Generate an α selected from a pre-specified distribution i , change α i Used in subsequent calculations. Each server is based on the challenge value and witness w i , in the binary domain Generate a consistency assessment certificate on:

[0095] EvalcheckProof i =EvalCheck(S i (x), α i , w i ).

[0096] Step 4.2: Reduce and Mix Proofs

[0097] In the first round, all servers merge their generated consistency evaluation proof EvalcheckProof i To a consistency assessment proof set:

[0098]

[0099] The server performs a virtual open based on the current consistency evaluation proof and a reduction step similar to the sum check. In this phase, each server updates its own proof based on the received challenge value and evaluation result, and sends the new virtual proof to other servers to gradually compress the intermediate proof information of all servers and achieve the goal of ultimately unified and verifiable batch proof aggregation. The update rules are:

[0100]

[0101] and

[0102] Step 4.3: Aggregation

[0103] After multiple rounds of consistency assessment and checking, the servers aggregate all updated proof sets to generate the final batch proof Πf inal , including all challenge-response pairs and evaluation results:

[0104]

[0105] in represents the set of challenge-response pairs of all servers, Represents the set of consistency evaluation certificates for all servers.

[0106] Step 5: Generate a small-field polynomial commitment proof: Generate intermediate results on the binary field and perform a weighted average operation; at the same time, construct a Merkle proof based on the binary field, and finally generate a commitment output containing the aggregated result and a unified Merkle proof.

[0107] For a specific polynomial P(x), the prover first determines a polynomial P(x) used to represent the intermediate results and data in its calculation process. The coefficients of this polynomial are defined in the binary field Next, the prover uses a hash function H and the introduced random parameter r to generate a commitment value C, which is a combination of the polynomial P(x) and the random number r. The present invention ensures the data integrity and privacy during the calculation process by making a commitment to the polynomial in the binary field, namely:

[0108] C=H(P(x),r)

[0109] Where H is a homomorphic hash function, and the use of binary tower expansion can ensure the compactness and efficiency of the commitment value C. In the present invention, each server holds a corresponding package share, denoted as {C i} j ∈N, where N represents the number of servers.

[0110] Step 5.1: Mixing

[0111] Each server generates an intermediate result t i ′, including the consistency evaluation proof. Next, the challenger generates the challenge vector {α i} i =1 for these t i 'Perform a weighted average operation. The purpose is to mix the calculation results of each server through different challenge coefficients, expressed as: The multiplication and addition in the mixed operation are both in the binary domain This hybrid step not only compresses the communication volume, but also enhances the system's robustness to single-point failures and erroneous calculations, providing efficient consistency input for the verification process.

[0112] Step 5.2: Generate t′ i At the same time, each server will also generate a Merkle proof M i , used to prove the validity of its calculation results. The Merkle proof is in the binary domain The leaf nodes are encoded by the consistency evaluation results, ensuring the verifiability in the unified structure. The final Merkle proof set is obtained by merging the Merkle proofs of all servers:

[0113] Step 5.3: The final proof is obtained by mixing t prime and the combined Merkle proof M final Composition: Proof=(t prime ,M final ). Among them, M final Represents a unified Merkle proof, which together with the aggregated result constitutes the final commitment output.

[0114] Step 6: Client Scheduling and Aggregation: The client does not directly participate in the computation. Instead, it is responsible for task scheduling and receiving zero-check proofs, greedy evaluation check proofs, and small-domain polynomial commitment proofs from each server. It aggregates these sub-proofs in batches to generate a unified aggregate proof. This aggregate proof is then submitted to the verifier for verification in Step 7.

[0115] Client task scheduling is done in step 1.2, and the client allocates witnesses w based on server performance. i The scheduling at this time has nothing to do with the preprocessing generation in step 2, and is only dynamically partitioned based on performance indicators.

[0116] Step 7: Verify the Proof: After receiving the public parameters, public inputs, and the aggregated final proof, the verifier generates a challenge value from the commitment based on the Fiat-Shamir hash function transformation, checks whether the polynomial relationship holds at the verification point, performs polynomial commitment verification, and finally outputs the verification result. The details are as follows:

[0117] First, the verifier receives parameters, including: public parameter pp = (crs, vrs), public input x pub , the final proof of aggregation Π.

[0118] The public parameter pp comes from the parameter setting phase in step 2 and is constructed by the client executing the parameter generation algorithm based on the predefined relationship R and the security parameter λ.

[0119] Furthermore, we can parse out the related commitments C1, C2, ..., C from the proof Π. k With the challenge α, β, γ, these values ​​are calculated by the Fiat-Shamir hash function transformation: α=Hash(C1,C2,…,x pub ).

[0120] Furthermore, the verifier checks whether the constraints between the polynomials hold at point z, P1(z)·P2(z)+α·P3(z)=0.

[0121] where α is the Fiat-Shamir hash function from the commitment set {C1, ..., C k} with common input x pub The challenge value generated in is used to construct the verification constraint.

[0122] Finally, verify the polynomial commitment: PCS.Verify(pp, C, z, y, π′) = true, where C is the commitment, z is the verification point, y is the evaluation value of the aggregated commitment polynomial at point z, π′ is the evaluation proof value, and return the result.

[0123] The present invention is compared with the advanced zero-knowledge proof groth16 and plonk3 under different server numbers (from 16 to 128). According to the experimental results, the present invention is superior to the advanced zero-knowledge proof groth16 and plonk3 under the condition of 128 servers and 2 gates. 20 to 2 22 In the range of , the efficiency is 400% and 800% higher than Groth16 and Plonk3 respectively. In addition, this efficiency advantage becomes more obvious as the number of gates increases. In the case of comparing a single prover with multiple servers, the present invention not only supports the calculation of large-scale gate numbers, but also improves its efficiency by 40% to 200% as the number of servers increases. And when the number of gates exceeds 2 23When groth16 and plonk3 cannot complete the calculation, the present invention can still run efficiently. Figure 2 As shown, the gray dashed line shows the time variation of groth16 generating proofs, the yellow dashed line shows the time variation of plonk3 generating proofs, and the remaining dashed lines show the time variation of the present invention generating proofs under different numbers of servers. This shows that the generation time of groth16 and plonk3 is significantly higher than the generation time of the present invention under different numbers of servers. In terms of the time complexity and space complexity of generating proofs, the framework has significant advantages.

[0124] The present invention has been tested and compared under different network bandwidths (100Mbps and 4Gbps) and different numbers of participants. According to the experimental results, the performance gap of the present invention under different bandwidths is controlled within 1 times. Compared with the baseline, the proof generation efficiency of the present invention under different network conditions can be improved by up to 300%. Figure 3 As shown in the figure, the black dotted line represents the baseline performance of a single prover, the blue dotted line represents the perfect performance of the present invention without network delay, the green solid line represents the speed ratio of the present invention with different numbers of participants in a low-speed network of 100Mbps, and the red solid line represents the speed ratio of the present invention with different numbers of participants in a high-speed network of 4Gbps. This shows that the performance of the present invention is significantly improved with the increase of the number of participants, especially at a bandwidth of 4Gbps and a large number of participants (for example, 2 7 When there are multiple participants), the speedup ratio is close to the ideal value.

[0125] This paper compares the running time of the leader node under different numbers of participants in simulated 100Mbps and 4Gbps network environments. According to the experimental results, as the number of servers increases, the aggregation time of the leader node is relatively stable. Figure 4 As shown in the figure, the red solid line represents the running time of the leader node of the present invention at a bandwidth of 100Mbps, and the green solid line represents the running time of the leader node of the present invention at a bandwidth of 4Gbps. This shows that the leader node is responsible for coordinating distributed computing tasks, and its performance affects the efficiency of the entire method. The efficiency of the leader node in aggregate proof under 4Gbps bandwidth is improved by 400% compared to the leader node under 100Mbps bandwidth.

[0126] The present invention is compared with the most advanced distributed zero-knowledge proof methods zkSaaS and Scalable zkSNARK in terms of proof generation time. According to the experimental results, when the number of gates is 2 26In this case, the generation time of zkSaaS is close to 2000ms, the generation time of ScablezkSNARK is close to 1500ms, and the generation time of the present invention is only 724ms, which is better than the current state-of-the-art work. Figure 5 As shown, the yellow solid line represents the time it takes zkSaaS to generate a proof with different numbers of gates, the blue solid line represents the time it takes ScablezkSNARK to generate a proof with different numbers of gates, and the red solid line represents the time it takes the present invention to generate a proof with 32 participants and different numbers of gates. The final experimental results show that while ensuring zero-knowledge, simplicity, and non-interactivity, the present invention effectively shortens proof generation time, improves parallel scalability and system throughput by optimizing the distributed task partitioning mechanism and the efficient binary domain computing structure. This significantly outperforms existing mainstream methods and demonstrates greater scalability and practicality in large-scale circuits.

[0127] The above describes the specific embodiments of the present invention in detail with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Various changes can be made within the knowledge of ordinary technicians in this field without departing from the scope of the present invention.

Claims

1. An efficient distributed zero-knowledge proof method based on binary domain, characterized in that: The following steps are involved: Step 1: Data preprocessing: The client quantifies the performance indicators of each server based on the feedback results after the server test and divides the total witness into binary domains The child on the witness w i Distributed to each server, generating pre-processing information for polynomial generation and sub-proof construction; Step 2: Parameter Setting: The client generates unified public parameters in the binary domain based on the security parameters and the relationship to be proved. All servers and verifiers load these parameters and collaboratively perform calculations and proof generation in the same encrypted environment. Step 3: Generate zero-check proofs: Each server generates a set of local proofs that satisfy zero-check based on a polynomial over a binary field. All local proofs are combined into batches of zero-check proofs and zero-check evaluation values ​​through mixing and evaluation operations. Step 4: Generate greedy evaluation check proof: Perform consistency evaluation based on linear operations in the binary domain, and finally generate an evaluation proof set by mixing local proof results; Step 5: Generate a small-field polynomial commitment proof: Generate intermediate results on the binary field and perform a weighted average operation; simultaneously construct a Merkle proof based on the binary field, and ultimately generate a commitment output containing the aggregated result and a unified Merkle proof; Step 6: Client Scheduling and Aggregation: The client does not directly participate in the computation. Instead, it is responsible for task scheduling and receiving zero-check proofs, greedy evaluation check proofs, and small-domain polynomial commitment proofs from each server. The client aggregates these sub-proofs generated based on the binary domain in batches, ultimately generating a unified aggregate proof. This aggregate proof will be submitted to the verifier for verification in step 7. Step 7: Verify the Proof: After receiving the public parameters, public inputs, and the aggregated final proof, the verifier generates a challenge value from the commitment based on the Fiat-Shamir hash function transformation, checks whether the polynomial relationship holds at the verification point, performs polynomial commitment verification, and finally outputs the verification result.

2. The efficient distributed zero-knowledge proof method based on binary domain according to claim 1, characterized in that: Step 1 is as follows: Step 1.1: Performance Evaluation: The client performs computationally intensive tasks on each server, evaluating the server's computation time and resource consumption, and quantifying its computational performance indicators as the basis for task allocation weights. The evaluation tasks are constructed on a binary domain to reflect the server's actual computing capacity within that domain. Step 1.2: Witness Partitioning and Distribution: Represent the total witness as a vector on a binary domain, and dynamically divide it into multiple sub-parts based on the performance indicators of each server. These sub-parts are then distributed to each server, ensuring that the task allocation matches the processing capacity and that the partition results maintain the binary domain representation during calculations. Step 1.3: Preprocessing Generation: Construct a local circuit mapping and polynomial structure on the binary domain. Each server generates corresponding preprocessing information, which is used as the basis for local polynomial construction, proof generation, and task execution scheduling in steps 3 to 5.

3. The efficient distributed zero-knowledge proof method based on binary domain according to claim 1, characterized in that: In step 2, the public parameters include a universal reference string, a circuit structure code, zero-knowledge parameters, and verification parameters.

4. The efficient distributed zero-knowledge proof method based on binary domain according to claim 1, characterized in that Step 3 is as follows: Step 3.1: Generate Batch Proofs: After receiving the secret share of the local polynomial, each server interpolates and reconstructs it on the binary field, generates corresponding sub-challenges for each claim based on the global challenge, and calculates a local zero-check proof on the binary field to verify whether its local computation satisfies the constraints. The zero-check proofs generated by all servers are then bundled together to form a batched combined proof; Step 3.2: Receive zero-check proof: Each server sends the zero-check proof of the current batch to the client; Step 3.3: Hybrid Proof and Evaluation: In this process, each server evaluates the local constraint polynomial at the evaluation point and obtains the zero-check evaluation value E r , and generate a proof together with the zero check result; All zero-check proofs are batched together into a unified proof and sent to the client. The client combines the received proof with the zero-check evaluation value. The update rule is to update all zero-check proofs P in each round. r and zero check evaluation value E r Perform mixing operations to form new {P′ r , E′ r }.

5. The efficient distributed zero-knowledge proof method based on binary domain according to claim 1, characterized in that: Step 4 is as follows: Step 4.1: Initialize the proof: Each server selects a challenge value α from a preset distribution i , used to generate a consistency evaluation proof based on a sub-witness, evaluate its local polynomial on the binary field, and obtain a consistency evaluation value as the input for generating the consistency evaluation proof; Step 4.2: Reduce and combine proofs: All servers merge their own generated consistency evaluation proofs to form a preliminary consistency evaluation proof set. Subsequently, the server performs a virtual open operation based on binary domain linear operations, updates the local proof based on the new challenge value and evaluation result, generates a virtual proof, and broadcasts it. Step 4.3: Aggregation: After multiple rounds of evaluation and aggregation, each server finally generates a batch proof that contains the challenge-response pairs and consistency evaluation proof set of all servers for the verification process.

6. The efficient distributed zero-knowledge proof method based on binary domain according to claim 1, characterized in that: Step 5 is as follows: Step 5.1: Each server generates an intermediate result t based on the binary field polynomial calculation i ', including proof of conformity assessment; Next, the challenger generates a challenge vector and compares these t i 'Perform weighted averaging to mix the calculation results of each server through different challenge coefficients; Step 5.2: While generating the intermediate results, each server generates a Merkle proof in the binary domain based on its local results to prove the validity and traceability of its calculation results. Step 5.3: All servers merge their generated Merkle proofs to obtain a globally consistent set of proofs; the final proof consists of the mixed intermediate value and the merged Merkle proof as the output of the small field polynomial commitment.

7. The efficient distributed zero-knowledge proof method based on binary fields according to claim 6, characterized in that: The final commitment structure includes both the aggregated results of multiple server consistency evaluation values ​​and a unified Merkle proof, and the Merkle proof is constructed in a binary domain and supports unified verification of multi-source results.

Images