General-purpose zk-snark zero-knowledge-proof optimization system and method

Abstract

Disclosed in the present invention are a general-purpose zk-SNARK zero-knowledge-proof optimization system and method. The system comprises: a trusted device, a prover and a verifier, wherein the prover uses a bucket algorithm to implement a multi-scalar multiplication operation, and the prover includes a window splitting unit, an in-bucket point reduction unit, an in-window reduction unit and a window aggregation unit, the window splitting unit splitting the multi-scalar multiplication operation into a plurality of subtasks on the basis of a set window, which is dynamically set on the basis of the computational cost of Montgomery modular multiplication, the in-bucket point reduction unit reducing each point on an elliptic-curve finite field into a bucket, so as to obtain a result of each subtask, the in-window reduction unit being used for point-multiplying a bucket number by a reduced bucket and accumulating buckets within the same window to reduce same into one bucket, so as to obtain the window value of each window, and the window aggregation unit obtaining a computational result of the multi-scalar multiplication on the basis of the window value of each window. The present invention effectively optimizes the execution efficiency of multi-scalar multiplication, and is conducive to realizing the efficient operation of a zk-SNARK proof generation process.

Description

A general zk-SNARK zero-knowledge proof optimization system and method Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a general zk-SNARK zero-knowledge proof optimization system and method. Background Technology

[0002] Zero-knowledge proof (ZKP) is a cryptographic protocol based on the agreement of two or more parties. Its main function is to enable the prover to convince the verifier that a certain statement made by the prover is true without revealing any useful information to the verifier.

[0003] Interactive zero-knowledge proof systems involve the verifier posing questions to the prover. If the prover knows the information, the probability of a correct answer is 1; if the prover does not know the information, the probability of a correct answer is 1 / 2. The verifier can infer whether the prover knows the information through a sufficient number of questions, while ensuring that these questions and their corresponding answers do not reveal any relevant useful information. This technique allows an NP-hard problem to be verified in polynomial time without revealing any data related to the solution.

[0004] Non-interactive zero-knowledge proof systems are cryptographic protocols that allow a prover to demonstrate the truth of a statement to a verifier without multiple rounds of interaction. In such systems, the prover can demonstrate their proof to the verifier through a single message transmission, without revealing any other information besides the statement's truth value. Unlike interactive zero-knowledge proof systems, in non-interactive systems, the prover does not need to wait for a challenge from the verifier and only needs to send the proof once to complete the entire proof process. The implementation of non-interactive zero-knowledge proof systems relies on complex cryptographic techniques, such as the construction of zero-knowledge proofs and the application of problems like discrete logarithms. Currently, two widely used implementations of non-interactive zero-knowledge proofs are zk-STARK (Zero-Knowledge Scalable Transparent Arguments of Knowledge) and zk-SNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge).

[0005] zk-STARK is a state-of-the-art zero-knowledge proof system designed to efficiently, scalably, and transparently verify the correctness of large-scale computations without revealing specific information. Based on error-correcting codes and low-rank encoding, it provides a robust cryptographic solution for ensuring the reliability of computation processes by constructing verifiable polynomial implementations.

[0006] zk-SNARK is a recognized reliable choice among current zero-knowledge proof protocols, designed to overcome the limitations of previous interactive proof-based methods. It achieves zero-knowledge proofs in a concise, non-interactive way, avoiding multiple interactions between the prover and verifier, and significantly reducing communication costs, representing a significant technological advancement in information security. The main advantage of zk-SNARK lies in its fixed proof size, which reduces verification and communication complexity; this advantage becomes more pronounced with an increased number of transactions. However, it requires an additional verification key, and although the key can be pre-generated, this inevitably leads to corresponding storage and computational burdens as the number of transactions increases.

[0007] In existing interactive zero-knowledge proof systems, provers and verifiers need to engage in multiple challenge-response communications during the proof process. This approach limits the efficiency and applicability of proofs because each round of communication can only transmit a small amount of proof information and increases the overall computational and communication costs. This high-frequency communication often results in significant latency and bandwidth consumption, especially when a large number of proofs are required or under poor network conditions. Furthermore, due to the need for multiple rounds of interaction, provers and verifiers must be online simultaneously and able to communicate in real time. This is a significant limitation for distributed systems or asynchronous environments (such as asynchronous networks or offline devices). The synchronization requirement increases the complexity and inconvenience of protocol implementation.

[0008] While zk-STARK offers significant advantages in security and transparency, it also suffers from several notable drawbacks, including high computational and storage overhead, large generated proofs, and lengthy verification times. These factors can lead to inefficiencies when handling complex computational tasks. Furthermore, zk-STARK places high demands on mathematical foundations, increasing the complexity of its implementation and deployment. Due to these limitations, the application of zk-STARK in large-scale zero-knowledge proof systems faces challenges, particularly in large-scale distributed systems or blockchain networks requiring efficient processing and rapid verification. These shortcomings can become performance bottlenecks, impacting the overall scalability and usability of the system.

[0009] While zk-SNARKs excel in reducing proof size and verification time, they suffer from limitations such as the trusted setup problem, computational complexity, high hardware requirements, and insufficient transparency. These factors restrict their application in large-scale zero-knowledge proof systems. In particular, the trusted setup phase is vulnerable to attacks, and generating proofs requires significant computational resources and has high hardware requirements, posing challenges to their application in large-scale systems.

[0010] Despite some shortcomings, zk-SNARK remains the mainstream zero-knowledge proof technique. This is primarily due to its significant advantages in proof size and verification time, making it perform excellently and efficiently in many practical applications. In contrast, while zk-STARK offers higher transparency and lower trusted setup requirements, it generally lags behind zk-SNARK in terms of computational complexity and operational efficiency. Continuous optimization of zk-SNARK's computational complexity and operational efficiency can further solidify its position as the dominant technique in the field of zero-knowledge proofs and promote its widespread application and development.

[0011] The proof generation process of zk-SNARK primarily relies on Number Theoretic Transformation (NTT) and Multi-Scalar Multiplication (MSM). Existing research indicates that MSM is the main computational bottleneck in zk-SNARK proof generation; in the open-source zk-SNARK library Bellman, MSM execution time typically accounts for over 70% of the total proof generation time. Therefore, effectively shortening the zk-SNARK proof generation process, which is heavily reliant on MSM, is a crucial area for improvement.

[0012] Multiplication of multiple scalars is a mathematical operation that, given a set of points and a set of scalars on an elliptic curve, involves multiplying each point by its corresponding scalar and then adding the results. Mathematically, it is defined as follows:

[0013] Where N is the size of MSM, G i k is a point on the finite field of an elliptic curve. i It is a λ-bit scalar, k i G iThe scalar multiplication (PMULT) on an elliptic curve mainly involves point addition (PADD) and point doubling (PDBL). Referring to Figure 1, point addition on an elliptic curve can be implemented through the following steps: Given two points F and G, first draw the straight line connecting them and find the third intersection point -H of the curve. Then, using -H as the center of symmetry, reflect it about the X-axis to obtain point H, which is the sum of F and Q. For point doubling, when adding point G to itself (i.e., 2G), find the tangent line to the elliptic curve at point G, determine the third intersection point of the tangent line with the curve, and then use this point as the center of symmetry to reflect it about the X-axis; the reflected point is 2G. This method can efficiently calculate additions between points on an elliptic curve. Therefore, it can be seen that point addition on an elliptic curve involves complex operations such as calculating the slope of the elliptic curve and solving for intersection points, which consumes a lot of computational resources. Therefore, to improve the efficiency of zero-knowledge proof generation, it is necessary to start by reducing the computational amount of elliptic curves and improving computational efficiency.

[0014] In actual scalar multiplication, the scalar value is scanned bit by bit starting from the least significant bit. Each time, the current result is doubled. If a bit is 1, the corresponding point value is added; if a bit is 0, it is ignored. This iteration continues until the most significant bit has been processed. This bit-by-bit method can efficiently compute scalar multiplication on elliptic curves. Figure 2 shows the computation of elliptic curve addition for a scalar of 2^3. It can be seen that the larger the bit width of the scalar, the more times point doubling and point addition are performed, and the greater the computational cost of point scalar multiplication. Taking the Filecoin blockchain project as an example, a proof will contain millions of scalars and point sets, where the scalar bit width is 256 bits. If the result of scalar multiplication for each point is calculated and then summed using point addition to obtain the total result, it will result in a huge computational latency.

[0015] Furthermore, existing zero-knowledge proof systems suffer from difficulties in resource management and scheduling, as well as load imbalance. In a multi-tasking environment, efficiently managing and scheduling GPU resources is a challenging task. During zero-knowledge proof generation, task allocation and resource scheduling require fine-grained control to avoid resource waste and performance degradation. Moreover, in terms of resource management, it is necessary to consider how to balance the GPU resource demands of different tasks.

[0016] In summary, the core advantage of zero-knowledge proof technology lies in its ability to prove the authenticity of information to others without disclosing private data. However, existing zero-knowledge proof technologies face major challenges, including long proof generation times, high computational demands, and high costs. These issues severely restrict the widespread application of zero-knowledge proof technology in fields such as blockchain systems. Especially in scenarios with high real-time requirements, such as finance, delays in the generation and verification of zero-knowledge proofs can adversely affect the security and reliability of transactions, leading to negative consequences. Furthermore, lengthy proof generation times also increase the cost of computing resources, reducing the system's economic efficiency.

[0017] Summary of the Invention

[0018] The purpose of this invention is to overcome the shortcomings of the prior art and provide a general zk-SNARK zero-knowledge proof optimization system and method.

[0019] According to a first aspect of the present invention, a general zk-SNARK zero-knowledge proof optimization system is provided. The system includes: a trusted device, a prover, and a verifier, wherein:

[0020] Trusted devices are used to generate and manage the security parameters required by the system, and to generate and manage the keys in the system;

[0021] The prover uses the bucket algorithm to perform multi-scalar multiplication to generate the proof. This multi-scalar multiplication is the process of multiplying a point with its corresponding scalar and then adding them together, given a set of points and a set of scalars on an elliptic curve.

[0022] The verifier compares the key sent by the trusted device with the proof generated by the verifier to confirm the validity of the proof;

[0023] The prover comprises a split window unit, a bucket-in-point reduction unit, a window-in-reduction unit, and a window aggregation unit. The split window unit is used to split the multi-scalar multiplication operation into multiple subtasks based on a set window, and the size of the window is dynamically set according to the Montgomery modular multiplication computation. The bucket-in-point reduction unit is used to reduce each point on the finite field of the elliptic curve to a bucket to obtain the result of each subtask. The window-in-reduction unit is used to multiply the bucket number by the reduced bucket and accumulate and reduce the buckets in the same window into a single bucket to obtain the window value of each window. The window aggregation unit is used to obtain the calculation result of the multi-scalar multiplication based on the obtained window value of each window.

[0024] According to a second aspect of the present invention, a general zk-SNARK zero-knowledge proof optimization method is provided. The method includes the following steps:

[0025] Generate and manage security parameters and keys used for zero-knowledge proofs;

[0026] The bucket algorithm is used to implement multi-scalar multiplication to generate proof that the multiplication operation is the process of multiplying a point with its corresponding scalar and then adding them together, given a set of points and a set of scalars on an elliptic curve.

[0027] The validity of the proof is confirmed by comparing the key with the generated proof.

[0028] The multi-scalar multiplication operation is implemented according to the following steps:

[0029] Based on the set window, the multi-scalar multiplication operation is divided into multiple sub-tasks, and the size of the window is dynamically set according to the Montgomery modular multiplication computation amount.

[0030] Reduce the points on the finite field of each elliptic curve to buckets to obtain the results of each subtask;

[0031] Multiply the bucket number by the reduced bucket, and sum and reduce the buckets in the same window into one bucket to obtain the window value of each window;

[0032] Based on the window value of each window, the calculation result of the multiscalar multiplication is obtained.

[0033] Compared with existing technologies, the advantages of this invention lie in its focused analysis of the development and generation process of zero-knowledge proofs. While ensuring that other processes involved in proof generation are not affected, it designs optimized algorithms and improves computation to enhance the performance of zero-knowledge proofs and shorten the proof generation time. For example, it reduces the number of multi-scalar multiplication operations, improves the computational efficiency of multi-scalar multiplication, and designs a dynamic resource allocation and priority scheduling mechanism. This mechanism can rationally allocate GPU cores, memory, and bandwidth resources according to the characteristics and priorities of tasks, ensuring that each task receives adequate resources and minimizing resource idleness and waste. Using this invention, the execution efficiency of multi-scalar multiplication can be effectively optimized, and other optimization strategies can be explored to achieve efficient operation of the zk-SNARK proof generation process.

[0034] Other features and advantages of the invention will become clear from the following detailed description of exemplary embodiments of the invention with reference to the accompanying drawings. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the invention and, together with their description, serve to explain the principles of the invention.

[0036] Figure 1 is a schematic diagram of elliptic curve calculation in the prior art;

[0037] Figure 2 is a schematic diagram of the calculation process of scalar multiplication in the prior art;

[0038] Figure 3 is a system architecture diagram of zero-knowledge proof according to an embodiment of the present invention;

[0039] Figure 4 is a schematic diagram of the execution of the Pippenger algorithm according to an embodiment of the present invention;

[0040] Figure 5 is a schematic diagram of the dynamic window partitioning execution process according to an embodiment of the present invention;

[0041] Figure 6 is a schematic diagram of an in-bucket parallel architecture according to an embodiment of the present invention. Detailed Implementation

[0042] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the invention.

[0043] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0044] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0045] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0046] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0047] Taking its application in the blockchain field as an example, zero-knowledge proof technology effectively resolves the conflict between transparency and personal privacy. It allows users to conduct transactions and data transfers within the publicly accessible nature of blockchain information without worrying about leaking specific transaction details or personal identification information. By proving that they comply with transaction rules or possess specific assets, zero-knowledge proof technology ensures both data privacy and transaction security. Zero-knowledge proof technology can be applied to areas such as blockchain privacy protection, data privacy protection, identity authentication, and digital copyright protection, providing an efficient solution for protecting personal privacy and ensuring data security.

[0048] Figure 3 is the overall architecture diagram of a zero-knowledge proof system. This system mainly includes a trusted device, a verifier (or verifier module), and a prover (or prover module). This invention primarily optimizes the functionality of the prover.

[0049] Trusted devices are responsible for generating and managing the security parameters required for zero-knowledge proof systems, such as elliptic curve parameters, prime numbers, and group orders. These parameters must be sufficiently random and secure to guarantee the system's security and resistance to attacks. Furthermore, trusted devices are used to generate and manage encryption and signing keys in the system. These keys play a crucial role in the generation and verification of proofs, ensuring their integrity and security. Overall, trusted devices generate circuit constraints for the problem to be computed, which are then transformed into constraint vectors, such as R1CS (Rank-1 Constraint System).

[0050] The verifier's primary role is to compare the key sent by the trusted device with the proof generated by the prover. First, it receives the zero-knowledge proof generated by the prover. This proof typically contains the prover's claim of the validity of certain statements or operations, such as possessing a certain key or meeting certain conditions. Second, using the system's public parameters and the proof provided by the prover, it executes a verification algorithm to confirm the proof's validity. This process usually involves using the zero-knowledge proof system's security parameters and public key to ensure the proof has not been forged or tampered with. The verifier implements the proof verification process and provides a result indicating whether the verification passed or failed.

[0051] The role of the prover is to generate a proof that they possess certain information or meet certain conditions without revealing any specific details about that information or condition. This proof can be used by the verifier, who can verify its validity using common parameters and a verification algorithm without needing to know the specifics behind the proof. In general, the prover constructs a polynomial problem by performing multiple rounds of NTT (number-theoretic transformation) computations, and then generates the proof through multiple rounds of MSM (method-based transformation) computations.

[0052] One of the main problems affecting the application of zero-knowledge proof systems is the excessive time required for provers to generate proofs, leading to a certain lag in the proofs and impacting the stability and real-time performance of the system. Therefore, this invention focuses on optimizing the prover component in zero-knowledge systems. Specifically, it addresses the performance bottleneck of proof generation by improving the most time-consuming multi-scalar multiplication (MSM) operation during proof generation, thereby significantly improving the efficiency and response speed of proof generation.

[0053] In one embodiment, the Pippenger algorithm (or bucket algorithm) is used to perform multi-scalar multiplication. The core idea of ​​the Pippenger algorithm is to decompose a high-bit-width MSM into multiple low-bit-width MSMs by fine-grained decomposition of scalars, thereby reducing the overall multiplication operations and improving computational efficiency. The improvement proposed in this invention is based on the original Pippenger algorithm and aims to further optimize its performance. Specifically, as shown in Figure 4, for the multi-scalar multiplication operations involved in the prover, the Pippenger algorithm framework is functionally divided into split window units, bucket-in-point reduction units, window-in-reduction units, and window aggregation units, each implementing its corresponding function.

[0054] 1. Split window units

[0055] Split window units are used to divide a binary scalar into windows of a certain number of bits, such as in Figure 4, where it is divided into 4-bit windows.

[0056] The purpose of window splitting is to decompose the original large-scale multi-scalar multiplication operation into multiple subtasks, making it easier to perform parallel computation using GPUs. First, a fixed window c (c < λ) is selected based on the size of the original MSM. Then, a scalar k of size λ-bit is split into multiple subtasks. i Divided into Each part, i.e., a MSM of size λ-bit, is decomposed into L MSMs of size c-bit (i.e., L subtasks), and the calculation formula is expressed as:

[0057] Where Q represents the result of multi-scalar multiplication, and G... i Y is the i-th scalar point on the finite field of an elliptic curve. j Let k represent the MSM of the j-th c-bit. i，j Let j represent the j-th part of the i-th scalar, where i∈[1,N] and j∈[1,L].

[0058] In practical applications, the optimal window size can be dynamically selected based on the specific GPU model, its computing power, and the initial scale of multi-scalar multiplications to achieve effective subtask partitioning. Traditional methods typically evaluate the workload based on the number of simple point additions to determine the optimal window size. Considering that Montgomery modular multiplication is the main computational step in point addition operations, its computational load directly affects the execution time of subtasks. In one embodiment of this invention, a more refined mechanism is introduced: dynamically adjusting the window size based on the required Montgomery modular multiplication computation within the window. The dynamic window partitioning process is shown in Figure 5, and generally includes determining the initial window, task partitioning, pre-estimating the computational load, monitoring and feedback, and real-time window adjustment based on monitoring and feedback results.

[0059] Specifically, the process of dynamically adjusting the window size mainly includes: estimating the required Montgomery modular multiplication computation before each subtask begins, and selecting the optimal window size based on this estimate to optimize execution efficiency. By monitoring the actual computational load of each subtask in real time and analyzing the data collected during actual execution, it is assessed whether the window size for the next subtask needs adjustment. For example, if the actual computational load is lower than the estimated value, the window size can be increased to improve execution efficiency and reduce resource idleness. Through optimization strategies and real-time adjustments, the system can dynamically adapt to different workloads and hardware environment changes, ensuring effective allocation of computing resources under various conditions, improving the efficiency of point addition operations and overall system performance. Preprocessing tests and verifications can be performed before application to ensure that the selected window size selection strategy exhibits optimal performance and efficiency in real-world scenarios. This method optimizes the execution efficiency of point addition operations and overall system performance, providing a more accurate and efficient processing method, particularly suitable for complex computational tasks.

[0060] In another embodiment, the window size can be dynamically adjusted based on statistical analysis and machine learning models to further improve computational efficiency. For example, a trained machine learning model reflects the correspondence between one or more of the Montgomery modular multiplication computation, GPU resources, and window size. In this way, the window size can be predicted and adjusted more accurately to maximize the utilization of GPU resources, thereby improving the efficiency of computational operations to adapt to different workloads and hardware environments.

[0061] In summary, compared to the fixed window size of the original Pippenger algorithm, employing a finer-grained mechanism in the window splitting stage to adjust the window size according to actual computational needs allows for more precise workload allocation, avoiding performance loss or resource waste caused by excessively large or small windows. Furthermore, because the window size selection is based on specific computational requirements, it can be flexibly adjusted according to different application scenarios and hardware configurations, thus achieving optimal performance under various conditions.

[0062] 2. In-bucket point specification unit

[0063] In-bucket point reduction units are used to classify points on each finite domain of an elliptic curve into buckets. For example, with a window size of c, that is, one window for every c bits, each window corresponds to a bucket of size 2. c An array of -1s is called a bucket. For example, as shown in Figure 4, after decomposing the scalar into 4-bit windows, points on the finite field of each elliptic curve can be classified into buckets covering the range of 1-15. It should be noted that since the product of the bucket number 0 and the reduced bucket is zero, the result can be considered that bucket number 0 is not calculated.

[0064] For the bucket point reduction, after selecting an appropriate window size, initialize 2. c -1 buckets, then sequentially add G i Accumulate to its coefficient k i,j Within the corresponding buckets, the result of each sub-MSM is calculated, and parallel execution within the bucket can be achieved through bucket point reduction. However, the traditional Pippenger algorithm often fails to make reasonable use of GPU threads, resulting in some bucket threads being idle for a long time while others are overworked, thus reducing the overall throughput and efficiency of the system.

[0065] In one embodiment of the present invention, for the bucket point reduction part of the Pippenger algorithm, a load balancing scheduling mechanism and a parallelization structure are designed according to the number of bucket points to ensure reasonable resource scheduling during the execution of the algorithm.

[0066] When considering thread allocation, traditional algorithms typically distribute GPU threads evenly based on a fixed window size. However, since the number of points within each bucket can vary significantly, this leads to uneven distribution of workloads. To address this challenge, in one embodiment of this invention, the number of points in each bucket is first counted. After all points have been placed, the thread allocation is dynamically adjusted based on the proportion of points in each bucket. Furthermore, during computation, the system monitors the number of points and computation progress in each bucket in real time. Once the computation task in a bucket is completed, the system collects data on the current state of all buckets. Based on the collected data, the system re-evaluates the dynamic thread allocation. For example, more threads may be allocated to buckets still processing a large number of points, or resources may be reduced for buckets that have completed computation. This process is repeated periodically until all computation tasks are completed. This iterative cycle ensures that the system can dynamically adjust resource allocation when dealing with complex data distributions, thereby improving overall computational efficiency and performance utilization.

[0067] This method effectively optimizes GPU utilization and improves overall computational efficiency. Furthermore, a novel parallel architecture is introduced during actual task execution. Referring to Figure 6, the intra-bucket parallel architecture uses a tree structure for pairwise pairing to support reduction-parallel computation within each bucket. This structure not only effectively handles large-scale datasets but also enables efficient data communication and collaboration between different buckets, further enhancing the algorithm's parallelization performance.

[0068] In summary, the parallelized architecture design enables more efficient computation during the bucket-based point reduction phase. By using a tree-structured, pairwise parallel computation, the dependencies between computational tasks can be effectively reduced, lowering the overall computational latency. This optimization is particularly important for the requirement of rapid proof generation in zero-knowledge proof generation, significantly shortening the time needed to generate proofs.

[0069] 3. Specification Units within the Window

[0070] For a given window, once each point is classified into a bucket, all points can be summed to obtain a point for each bucket. For each window, all bucket values ​​are multiplied by their bucket numbers and then summed to obtain a window value.

[0071] Specifically, referring to Figure 4, multiply the bucket number (u) by the reduced bucket (B). j Then, the buckets within the same window are accumulated and reduced into a single bucket. For the window-based reduction operation, this invention uses a prefix sum approach for optimization. After a bucket is reduced, the reduction result can be incrementally updated to the accumulated sum of the previous window. This avoids recalculating the accumulated sum of the previous window from scratch for each calculation, achieving more efficient computation through incremental updates. This method reduces the computational cost of window-based reduction to the original computational cost. The specific algorithm is as follows: By starting the recording from the last bucket, when processing the reduction within the window, we only need to add the sum of the previous window to obtain the sum of the current window, which significantly improves the computational efficiency and reduces the complexity.

[0072] For example, the calculation process of the window reduction is represented as:

[0073] Where u represents the bucket number, [B j ] indicates that it is Y j The bucket in the middle, where Y j This represents the MSM of the j-th c-bit that has been split.

[0074] 4. Window aggregation unit

[0075] The window aggregation unit (or window reduction unit) is used to: after calculating the window value of each window, add them all together to obtain the final output of MSM.

[0076] For example, still referring to Figure 4, in the window aggregation unit, the algorithm flow is optimized by the multiplication distribution rate, using 2 c Multiply by the last window Y LThen, the sum is accumulated up to the second-to-last window, and then 2c is multiplied by the merged window, and so on, until the final window Y0 is reached. Specifically, the window reduction is expressed as:

[0077] Where Q represents the window reduction result, Y L This represents the Lth window value.

[0078] For clarity, the role of this invention in ensuring the security and efficiency of blockchain transactions will still be described with reference to Figure 3. In the generation process of zero-knowledge proofs, a trusted setup phase is essential. It defines the common parameters of the entire zero-knowledge system framework, including the choice of elliptic curves, generators, and other problem parameters. These parameters ensure network consistency and security. The primary responsibility of the trusted device is to transform the circuit constraints of a specific problem, that is, to convert smart contracts or business logic into an R1CS format suitable for zero-knowledge proofs. R1CS is a linear algebraic model expressing constraints, which allows complex computational logic to be transformed into a set of linear constraints. Optimizing this transformation process, such as reducing the number of unnecessary constraints, can significantly reduce the complexity of the proof, thereby reducing the time and resource consumption required to generate the proof.

[0079] In the proof generation section, the prover first transforms the R1CS constraints into polynomial form using number-theoretic transformations (NTT), and then performs the calculations, i.e., multiple rounds of multi-scalar multiplication. This part is also the most computationally intensive for the prover, often accounting for about 75% of the entire proof generation process. Given the importance of the MSM (Mean Self-Management Model), this invention specifically optimizes it. The optimization strategy involves decomposing the MSM to utilize the parallel processing capabilities of the GPU and improve computational efficiency. Specifically, the optimization scheme first subdivides the large-width MSM into multiple small-width MSMs within the split window unit, facilitating parallel processing by the GPU; and by dynamically adjusting the window size based on the estimated computational complexity of Montgomery modular multiplication, it ensures the optimal partitioning of subtasks. Simultaneously, it utilizes real-time monitoring and feedback mechanisms to dynamically adjust the window size to adapt to different workloads and hardware environments. In the bucket-point reduction unit, a load-balanced scheduling mechanism is implemented, dynamically adjusting GPU thread allocation based on the number of points within the bucket. Combined with a tree structure, it supports parallel reduction operations for points within the bucket, optimizing GPU utilization and overall computational efficiency. The window reduction unit is optimized using the prefix sum approach, reducing computational load and complexity through incremental updates, thus improving the computational efficiency of window reduction. Finally, the window aggregation unit utilizes the multiplicative distributive law to optimize the algorithm flow, recursively merging window values ​​until the final MSM output is obtained, significantly accelerating the proof generation process. Through these comprehensive optimization measures, provers can significantly improve the speed of proof generation, especially when handling large-scale datasets and complex computational tasks, ensuring that the zero-knowledge proof system is more stable, real-time, and efficient in practical applications. The final generated proof is submitted to the blockchain network, containing encrypted information confirming the validity of the transaction, but without revealing any substantial personal or financial details. Other nodes in the blockchain network, acting as verifiers, use the same public parameter key and verification algorithm to check the validity of the proof, confirming the legality of the transaction without knowing the specific value of the transaction. Once the proof is verified, the transaction is officially confirmed and permanently recorded on the blockchain, forming a fast and secure transaction confirmation process that greatly improves the feasibility and privacy protection level of blockchain technology in practical applications.

[0080] It should be noted that although the system provided by the present invention is described in the form of functional units, in practical applications, these units can also be integrated into hardware accelerators or acceleration devices, and embedded with blockchain nodes to improve the computational efficiency of generating proofs.

[0081] In summary, this invention analyzes and optimizes the Pippenger algorithm, which is beneficial for fully leveraging the advantages of GPU parallel computing, especially in handling large-scale multi-scalar multiplication operations. The Pippenger algorithm reduces the complexity of multi-scalar multiplication by reducing the number of multiplication operations, which is particularly effective when there are many points allocated within each bucket. First, through a reasonable workload allocation mechanism, it ensures that each thread on the GPU can be fully utilized, avoiding thread idleness and thus maximizing parallelism. Second, algorithm-level optimizations, such as utilizing shared memory and reducing data transfer, further improve computational efficiency. These optimizations not only reduce the overall complexity of the algorithm but also significantly shorten the computation time. By parallelizing the computational tasks, the GPU can process multiple multiplication operations simultaneously, significantly improving the execution speed of multi-scalar multiplication compared to traditional CPU computation. This specialized optimization is not only applicable to scientific computing and data processing but is also particularly important for applications requiring real-time response and high-performance computing.

[0082] In summary, compared with the prior art, the present invention has the following advantages:

[0083] 1) This invention provides an optimization scheme for the proof generation speed of zero-knowledge proof systems. While maintaining the security, integrity, and confidentiality of zero-knowledge proofs, it significantly improves the proof generation speed, making it applicable to current systems using zk-SNARK technology without requiring modification to existing proof generation processes and steps. Furthermore, an optimization scheme compatible with existing zk-SNARK technology systems is designed, specifically improving the efficiency of multi-scalar multiplication calculations.

[0084] 2) This invention provides an analysis mechanism for the Pippenger algorithm and improves its algorithm flow, achieving full utilization of GPU performance and accelerating the computation of the multi-scalar multiplication module. First, a dynamic window selection algorithm is designed to optimize the window splitting stage of the Pippenger algorithm, rationally allocating large-scale multi-scalar multiplication operations and achieving a significant performance improvement. Furthermore, the resource allocation strategy in the bucket reduction stage of the Pippenger algorithm is improved to ensure effective utilization of GPU resources, and an optimized computational structure is designed to enable efficient parallel execution, thereby accelerating the computation speed of the multi-scalar multiplication module. In addition, by reconstructing the bucket reduction and window reduction processes within the window, an efficient prefix sum algorithm is introduced, significantly improving computational efficiency. These improvements effectively reduce the time and resource consumption required for computation while maintaining computational correctness.

[0085] 3) This invention is based on the common Pippenger algorithm, which divides the definition of multi-scalar multiplication into four parts, performs modular decomposition and optimization on each part. By decoupling scalars and leveraging the parallelization advantages of GPUs, multi-scalar multiplication can be performed in parallel, thereby reducing the waiting time required for computation and improving the efficiency of proof generation.

[0086] 4) Traditional Pippenger algorithms often fail to fully utilize the parallel computing capabilities of GPUs during the bucket point reduction phase, leading to a large number of idle threads or excessively high load waiting. This invention designs a workload scheduling mechanism that dynamically allocates threads based on the number of points in each bucket, maximizing the utilization of GPU thread resources, avoiding thread idleness, and thus significantly improving the computational efficiency of the multiscalar multiplication module.

[0087] 5) After multiple tests and verifications, the present invention can meet the expected design indicators and does not require consideration of specific zero-knowledge proof schemes and forms. It can be adapted to zk-SNARK zero-knowledge proof generation systems under any current circumstances.

[0088] This invention can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of the invention.

[0089] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0090] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0091] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, Python, etc., and conventional procedural programming languages ​​such as "C" or similar languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0092] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0093] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0094] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It will be known to those skilled in the art that implementation in hardware, implementation in software, and implementation using a combination of software and hardware are equivalent.

[0096] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of the invention is defined by the appended claims.

Claims

1. A universal zk-SNARK zero-knowledge proof optimization system, comprising: The trusted device, the prover and the verifier, wherein: The trusted device is used to generate and manage the security parameters required by the system, and to generate and manage the keys in the system; The prover uses a bucket algorithm to implement a multi-scalar multiplication operation to generate a proof, the multi-scalar multiplication operation is to calculate the multiplication of points and corresponding scalars and then add them up for a given set of points and a set of scalars on an elliptic curve; The verifier is used to compare the key sent by the trusted device with the proof generated by the prover to confirm the validity of the proof; The prover comprises a split window unit, an intra-bucket point reduction unit, an intra-window reduction unit and a window aggregation unit, the split window unit is used to split the multi-scalar multiplication operation into multiple sub-tasks based on a set window, the size of the window is dynamically set according to the Montgomery modular multiplication calculation amount; the intra-bucket point reduction unit is used to reduce each point on the elliptic curve finite field to a bucket to obtain the result of each sub-task; the intra-window reduction unit is used to multiply the bucket number points with the reduced bucket, and aggregate the buckets in the same window into one bucket to obtain the window value of each window; the window aggregation unit is used to obtain the calculation result of the multi-scalar multiplication based on the obtained window value of each window.

2. The system of claim 1, wherein, The splitting window unit splits the multi- scalar multiplication operation of size λ-bit into multiple sub-tasks according to the following formula: where N denotes the size of the multi- scalar multiplication, c is a set window, c < λ, Y j denotes a multi- scalar multiplication of the jthc-bit, k i，j denotes the jthpart of the ithscalar, i∈[1,N], j∈[1,L].

3. The system of claim 2, wherein, The split window unit sets the window according to the following steps: Estimate the required Montgomery modular multiplication calculation amount before starting each sub-task to obtain an estimated amount; According to the estimated amount, select a corresponding window size to execute the sub-task; Real-time monitor the actual calculation amount of each sub-task, and compare the difference between the actual calculation amount and the estimated amount to determine whether to adjust the window size of the next sub-task. The split window unit sets the window according to the following steps:

4. The system of claim 2, wherein, The window inner reduction unit operates according to the following formula: where u denotes the bucket number, [B j ] denotes that it is a bucket in Y j .

5. The system of claim 4, wherein, The window aggregation unit obtains the calculation result of the multi- scalar multiplication according to the following formula: wherein Y L wherein Y0represents the last window after merging, Y1represents the first window.

6. The system of claim 2, wherein, Estimate the required Montgomery modular multiplication calculation amount before starting each sub-task to obtain an estimated amount; According to the estimated amount, select a corresponding window size to execute the sub-task; Real-time monitor the actual calculation amount of each sub-task, and calculate the difference between the actual calculation amount and the estimated amount; Input the difference into a trained deep learning model to determine whether to adjust the window size of the next sub-task. The intra-bucket point reduction unit performs the following process:

7. The system of claim 1, wherein, By counting the number of points in each bucket, dynamically adjust the allocation of threads according to the proportion of points in each bucket; During the calculation process, monitor the number of points in each bucket and the calculation progress, and collect the data of the current state of all buckets when the calculation task in a certain bucket is completed; Based on the collected data, re-evaluate the dynamic thread allocation. For the intra-bucket point reduction unit, a tree structure is used for pairwise pairing to perform parallel operation of intra-bucket point reduction.

8. The system of claim 7, wherein, 9. A general zk-SNARK zero-knowledge proof optimization method based on the system of any one of claims 1 to 8, comprising the following steps: Generating and managing security parameters and keys for zero-knowledge proof; Using a bucket algorithm to implement a multi-scalar multiplication operation to generate a proof, the multi-scalar multiplication operation is to calculate the multiplication of points and corresponding scalars and then add them up for a given set of points and a set of scalars on an elliptic curve; Comparing the key with the generated proof based on the key to confirm the validity of the proof; ​ The multi-scalar multiplication operation is implemented according to the following steps: The multi-scalar multiplication operation is split into multiple sub-tasks based on a set window, and the size of the window is dynamically set according to the Montgomery modular multiplication calculation amount; Each point on an elliptic curve finite field is reduced to a bucket to obtain the result of each sub-task; The bucket number is multiplied by the reduced bucket, and the buckets in the same window are accumulated and reduced into one bucket to obtain the window value of each window; Based on the obtained window value of each window, the calculation result of the multi-scalar multiplication is obtained.

10. A computer readable storage medium having stored thereon a computer program, wherein, The computer program is executed by the processor to implement the steps of the method according to claim 9.

Images