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

Abstract

The application discloses a general zk-SNARK zero-knowledge proof optimization system and method. The system comprises a trusted device, a prover and a verifier, wherein the prover realizes multi-scalar multiplication operation by using a bucket algorithm, the prover comprises a split window unit, a point reduction unit in a bucket, a window reduction unit and a window aggregation unit, the split window unit splits the multi-scalar multiplication operation into a plurality of subtasks based on a set window, and the window is dynamically set according to Montgomery modular multiplication calculation amount; the point reduction unit in the bucket reduces points on each elliptic curve finite field to a bucket to obtain the result of each subtask; the window reduction unit is used for multiplying the bucket number point with the reduced bucket, and accumulates and reduces the buckets in the same window into one bucket to obtain the window value of each window; and the window aggregation unit obtains the calculation result of the multi-scalar multiplication based on the window value of each window. The application effectively optimizes the execution efficiency of the multi-scalar multiplication, and is beneficial to realizing efficient operation of the zk-SNARK proof generation process.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer technology, and more particularly, to a general zk-SNARK zero-knowledge proof optimization system and method. BACKGROUND

[0002] Zero Knowledge Proof (ZKP) is a cryptographic protocol based on mutual recognition between two or more parties, which mainly functions to make the prover (Prover) convince the verifier (Verifier) that a certain statement is correct without revealing any useful information to the verifier.

[0003] An interactive zero-knowledge proof system is a system in which the verifier asks questions to the prover, and the probability of answering correctly is 1 if the prover knows the information, and 1 / 2 if the prover does not know the information. The verifier can determine whether the prover knows the information by asking enough questions, while ensuring that these questions and their corresponding answers do not reveal any useful information. This technology enables an NP problem to be verified in polynomial time without revealing any detailed information related to the solution.

[0004] A non-interactive zero-knowledge proof system is a cryptographic protocol that allows the prover to prove to the verifier that a certain statement is true without multiple rounds of interaction. In this system, the prover can demonstrate the proof to the verifier through a one-time information transmission, without revealing any information other than the truth of the statement. Unlike the interactive zero-knowledge proof system, the prover in the non-interactive zero-knowledge proof system does not need to wait for the verifier's challenge and only needs to send the proof once to complete the entire proof process. The implementation of the non-interactive zero-knowledge proof system relies on some complex cryptographic techniques, such as the construction of zero-knowledge proof and the application of difficult problems such as discrete logarithm. Currently, two widely used non-interactive zero-knowledge proof implementation methods are zk-STARK (Zero-Knowledge Scalable Transparent Arguments of Knowledge) and zk-SNARK (Zero-Knowledge Succinct Non-interractive Argument of Knowledge) technology.

[0005] zk-STARK is a new zero-knowledge proof system designed to efficiently, scalably, and transparently verify the correctness of large-scale computations without revealing specific information. It is based on error correction codes and low-rank encoding, and through the construction of a verifiable polynomial, it provides a strong cryptographic solution to ensure the reliability of the computing process.

[0006] zk-SNARK is a widely recognized reliable choice among existing zero-knowledge proof protocols, aiming to optimize the limitations of previous interactive proof-based systems. It achieves zero-knowledge in a concise non-interactive manner, avoiding multiple interactive communications between the prover and the verifier, and significantly reducing communication costs, providing important technical progress in the field of information security. The main advantage of zk-SNARK is the fixed proof size, which reduces the verification complexity and communication complexity, and this advantage is more pronounced when the number of transactions increases. However, it requires an additional verification key, although the key can be generated in advance, when the number of transactions increases, it inevitably brings corresponding storage and computing pressure.

[0007] In existing interactive zero-knowledge proof systems, the prover and the verifier need to perform multiple challenge-response communications during the proof process. This approach limits the efficiency and applicability of the proof, as each round of communication can only transfer a small amount of proof information, and increases the overall computational and communication costs. This high-frequency communication often results in significant delays and bandwidth consumption, especially in situations requiring a large number of proofs or in poor network conditions. In addition, due to the need for multiple rounds of interaction, the prover and the verifier must be online at the same time and be able to complete real-time communication. This is a significant limitation for distributed systems or asynchronous environments, such as out-of-sync networks or offline devices. The synchronization requirement increases the complexity and inconvenience of protocol implementation.

[0008] Although zk-STARK has significant advantages in security and transparency, it also has some significant drawbacks, including high computational and storage overhead, large generated proofs, and long verification times. These factors can result in lower efficiency when dealing with complex computational tasks. In addition, zk-STARK has high requirements for mathematical foundations, increasing the complexity of implementation and deployment. Due to these limitations, the application of zk-STARK in large-scale zero-knowledge proof systems faces challenges, especially in large-scale distributed systems or blockchain networks that require efficient processing and fast verification. These shortcomings can become performance bottlenecks, affecting the overall scalability and practicality of the system.

[0009] zk-SNARK performs well in reducing proof size and verification time, but has limitations such as trusted setup problems, high computational complexity, high hardware requirements, and insufficient transparency, which limit its application in large-scale zero-knowledge proof systems. In particular, the trusted setup phase is vulnerable to attacks, generating proofs requires a large amount of computing resources, and high hardware requirements make it challenging to apply in large-scale systems.

[0010] Despite some shortcomings, zk-SNARK is still the current mainstream zero-knowledge proof technology. This is mainly due to its significant advantages in proof size and verification time, making it perform well and efficiently in many practical applications. In contrast, while zk-STARK has higher transparency and lower trusted setup requirements, it is generally less computationally complex and efficient than zk-SNARK. By continuously optimizing the computational complexity and efficiency of zk-SNARK, its position as the dominant technology in the field of zero-knowledge proof can be further consolidated, and its widespread application and development can be promoted.

[0011] The proof generation process of zk-SNARK mainly relies on Number Theoretic Transformation (NTT) and Multi-Scalar Multiplication (MSM). According to existing research, multi-scalar multiplication operations are the main computational bottleneck in the proof generation process of zk-SNARK. In the Bellman open-source library, the execution time of MSM usually accounts for more than 70% of the total proof generation time. Therefore, how to effectively shorten the zk-SNARK proof generation process dominated by MSM is a crucial improvement direction.

[0012] Multi-scalar multiplication is a mathematical operation that calculates the multiplication of points and corresponding scalars on a given elliptic curve and scalar set, and then adds them. The mathematical definition is:

[0013]

[0014] where N is the size of MSM, G i is a point on the finite field of the elliptic curve, k i is a λ-bit scalar, k i G i represents the scalar multiplication of points on the elliptic curve (PMULT), and the main calculation in PMULT is point addition (PADD) and point doubling (PDBL). See Figure 1As shown, the point addition operation on the elliptic curve can be implemented by the following steps: given two points F and G, first draw a straight line connecting them, and find the third intersection point of the curve-H. Then, take-H as the axisymmetric center, reflect it about the X axis to get point H, which is the sum of F and Q. And for the point doubling operation, it is to add point G to itself (i.e. 2G), you need to find the tangent of the elliptic curve at point G, determine the third intersection point of the tangent and the curve, and then take this point as the axisymmetric center to reflect about the X axis. The point obtained by reflection is 2G. This method can effectively calculate the addition of points on the elliptic curve. Therefore, it can be seen that the point addition operation on the elliptic curve involves complex operations such as slope calculation and intersection point solving of the elliptic curve equation, which consumes a large amount of computing resources. Therefore, in order to improve the generation efficiency of zero-knowledge proof, it is necessary to reduce the calculation amount of elliptic curve and improve the operation efficiency.

[0015] In actual scalar multiplication operations, the scalar value is scanned from low to high bit by bit, and the current result is doubled each time. If the encountered bit is 1, add the corresponding point value; if the encountered bit is 0, ignore it. Continue iteration until the highest bit is processed. This bit-by-bit operation method can efficiently calculate the scalar multiplication on the elliptic curve. Figure 2 is the calculation of the elliptic curve addition of the scalar 23. As can be seen, the larger the bit width of the scalar, the more the number of point doubling and point addition calculations, and the larger the calculation amount of the point scalar multiplication operation. Taking the blockchain project Filecoin as an example, a proof will contain millions of scalar and point sets, where the scalar bit width is 256 bits. If the result of the scalar multiplication of each point is calculated, and then added by point addition to get the total result, it will produce huge calculation delay.

[0016] In addition, the existing zero-knowledge proof system has problems such as resource management and scheduling difficulties and load imbalance. In a multi-task environment, efficiently managing and scheduling GPU resources is a challenging task. In the zero-knowledge proof generation process, task allocation and resource scheduling need to be finely controlled to avoid resource waste and performance degradation. And in terms of resource management, it needs to consider how to balance the demand of different tasks for GPU resources.

[0017] In summary, the core advantage of zero-knowledge proof technology lies in the ability to prove the authenticity of information without revealing private data. However, existing zero-knowledge proof technology faces major problems including long proof generation time, large computational load, and high cost. These problems seriously restrict the popular application of zero-knowledge proof technology in blockchain systems and other fields. Especially in the financial field and other scenarios with high real-time requirements, the generation and verification time of zero-knowledge proof may adversely affect the security and reliability of transactions, leading to negative consequences. Moreover, long proof generation also increases the cost of using computing resources and reduces the economic benefits of the system. SUMMARY

[0018] The purpose of the present application is to overcome the above-mentioned defects 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 application, a general zk-SNARK zero-knowledge proof optimization system is provided. The system comprises a trusted device, a prover, and a verifier, wherein:

[0020] 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;

[0021] The prover uses a bucket algorithm to implement a multi-scalar multiplication operation to generate a proof, which is an operation process of multiplying points and corresponding scalars and then adding them for a given set of points and a set of scalars on an elliptic curve;

[0022] 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;

[0023] The prover comprises a split window unit, an in-bucket 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 sub-tasks based on a set window, and the size of the window is dynamically set according to Montgomery modular multiplication calculation amount. The in-bucket point reduction unit is used to reduce points on each elliptic curve finite field to a bucket to obtain the result of each sub-task. The window-in 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.

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

[0025] Generating and managing security parameters and keys for zero-knowledge proof;

[0026] The multi-scalar multiplication operation is implemented by using a bucket algorithm to generate a proof, the multi-scalar multiplication operation is an operation process of multiplying points and corresponding scalars and then adding for a given point set on an elliptic curve and a scalar set;

[0027] The generated proof is compared with the key to confirm the validity of the proof;

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

[0029] 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 Montgomery modular multiplication calculation amount;

[0030] Each point on the elliptic curve finite field is reduced to a bucket to obtain the result of each sub-task;

[0031] The bucket number point 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;

[0032] The calculation result of the multi-scalar multiplication is obtained based on the obtained window value of each window.

[0033] Compared with the prior art, the advantages of the present application are that by focusing on the development of zero-knowledge proof and the generation process, the performance of zero-knowledge proof is improved by designing optimization algorithm and improving calculation, etc. on the basis of ensuring that other processes of proof generation are not affected. For example, the number of multi-scalar multiplication calculations is reduced, the calculation efficiency of multi-scalar multiplication is improved, and a dynamic resource allocation and priority scheduling mechanism is designed. According to the characteristics and priority of the task, the resources such as GPU core, memory and bandwidth are reasonably allocated to ensure that each task obtains an appropriate amount of resources and reduces the idle and waste of resources as much as possible. The execution efficiency of multi-scalar multiplication can be effectively optimized by using the present application, and other optimization strategies are explored as much as possible to realize the efficient operation of the zk-SNARK proof generation process.

[0034] Other features and advantages of the present application will become apparent from the following detailed description of exemplary embodiments thereof, taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0035] The accompanying drawings incorporated in and forming a part of the specification, illustrate embodiments of the present application and, together with the description, serve to explain the principles of the application.

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

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

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

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

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

[0041] Figure 6 is a schematic diagram of in-bucket parallel architecture according to an embodiment of the present application. DETAILED DESCRIPTION

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

[0043] The following description of at least one exemplary embodiment is merely exemplary in nature and is in no way intended to limit the scope of the application, its application, or uses.

[0044] Techniques, methods, and apparatus known to those of ordinary skill in the relevant art can not be discussed in detail herein, but should be considered as part of the specification, where appropriate.

[0045] In all of the examples shown and discussed herein, any specific values should be interpreted as merely exemplary, and not as a limitation. Thus, other examples of exemplary embodiments can have different values.

[0046] It should be noted that like references and characters herein relate to like items throughout the figures, and once an item is defined in one figure, it need not be discussed further in subsequent figures.

[0047] Taking application in the field of blockchain as an example, the zero-knowledge proof technology effectively solves the contradiction between openness and transparency and personal privacy, so that users can conduct transactions and data transmission under the characteristics of blockchain information openness, without worrying about leaking specific transaction details or personal identity information. By proving that they meet the transaction rules or own specific assets, the zero-knowledge proof technology ensures the privacy of data and the security of transactions. The zero-knowledge proof technology can be applied to the fields of blockchain privacy protection, data privacy protection, identity authentication, and digital copyright protection, etc., and provides an efficient solution for protecting personal privacy and ensuring data security.

[0048] Figure 3 is the overall architecture diagram of the zero-knowledge proof system. The system mainly includes a trusted device, a verifier (or verifier module) and a prover (or prover module). The present application mainly optimizes the functions of the prover.

[0049] The trusted device is responsible for generating and managing the security parameters required by the zero-knowledge proof system, such as elliptic curve parameters, prime numbers, group order, etc. These parameters need to be random and secure enough to ensure the security of the system and resist attacks. In addition, the trusted device is also used to generate and manage encryption and signature keys in the system. These keys play an important role in the generation and verification of proofs, ensuring the integrity and security of the system. Overall, the trusted device generates circuit constraints for the problem to be calculated, and then converts them into constraint vectors, such as R1CS (Rank-1 Constraint System).

[0050] The main role of the verifier is to compare the keys sent by the trusted device with the proofs generated by the prover. First, it receives the zero-knowledge proof generated by the prover. This proof usually 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 the verification algorithm to confirm the validity of the proof. This process usually involves using the security parameters and public keys of the zero-knowledge proof system to ensure that the proof has not been forged or tampered with. The verifier implements the process of verifying the proof and gives the result of passing the verification or failing the verification.

[0051] The role of the prover is to generate a proof that proves that it has certain information or meets certain conditions without revealing any specific details about these information or conditions. This proof can be used by the verifier, who can confirm the validity of the proof using public parameters and verification algorithms without needing to understand the specific content behind the proof. Overall, the prover constructs polynomial problems by performing multiple rounds of NTT (Number Theoretic Transform) calculations, and then generates proofs by performing multiple rounds of MSM (Multi-Scalar Multiplication) calculations.

[0052] In the development of zero-knowledge proof systems, one of the main problems affecting their application is that the prover takes too long to generate the proof, resulting in a certain lag in the proof, which affects the stability and real-time performance of the system. Therefore, the present application focuses on optimizing the prover part of the zero-knowledge system. Specifically, by improving the multi-scalar multiplication operation (MSM) that takes the longest time in the proof generation process, the performance bottleneck of proof generation is solved, thereby significantly improving the efficiency and response speed of proof generation.

[0053] In one embodiment, Pippenger algorithm (or bucket algorithm) is adopted to perform the multi-scalar multiplication operation. The core idea of Pippenger algorithm is to decompose a high-bit-width MSM into multiple low-bit-width MSMs by finely decomposing the scalar, so as to reduce the total multiplication operation and improve the calculation efficiency. The improvement proposed in the present application is based on the original Pippenger algorithm, aiming to further optimize its performance. Specifically, referring to Figure 4 As shown in the figure, for the multi-scalar multiplication operation involved in the prover, the Pippenger algorithm framework is divided into a split window unit, an in-bucket point reduction unit, a window-in reduction unit, and a window aggregation unit according to functions, which respectively realize the corresponding functions.

[0054] 1. Split window unit

[0055] The split window unit is used to split the binary scalar into a window of a certain bit number, for example, in Figure 4 , the window is split into a 4-bit window.

[0056] The purpose of splitting the window is to decompose the original large-scale multi-scalar multiplication operation into multiple sub-tasks, which facilitates parallel operation using GPU. First, according to the size of the original MSM, a fixed window c (c < λ) is selected, and the original scalar k i of size λ-bit is divided into parts, that is, a MSM of size λ-bit is decomposed into L MSMs of size c-bit (i.e. L sub-tasks), and the calculation formula is represented as:

[0057]

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

[0059] In practical applications, the optimal window size can be dynamically selected according to the specific GPU model and its computing power and the size of the initial multi-scalar multiplication, so as to realize effective division of sub-tasks. The traditional method usually evaluates the workload based on the number of simple point additions to determine the optimal window size. Considering that Montgomery modular multiplication is the main calculation step in point addition operation, the amount of calculation directly affects the execution time of the sub-task, in one embodiment of the present application, a more refined mechanism is introduced, that is, the window size is dynamically adjusted according to the amount of Montgomery modular multiplication required in the window, and the dynamic window division process is as follows Figure 5As shown, the overall process includes determining initialization windows, task partitioning, estimating computation, monitoring and feedback, and adjusting windows in real-time based on monitoring and feedback results.

[0060] Specifically, the process of dynamically adjusting window size mainly includes estimating the required Montgomery multiplication computation before each subtask starts, and selecting the optimal window size based on this estimation to optimize execution efficiency. By monitoring the actual computation of each subtask in real-time, analyzing the data collected during actual execution, and evaluating whether the window size of the next subtask needs to be adjusted. For example, if the actual computation is lower than the estimated value, the window size can be increased to improve execution efficiency and reduce resource idling. Through optimization strategies and real-time adjustment, the system can dynamically adapt to different workloads and hardware environment changes, ensuring efficient allocation of computing resources in various situations, improving the efficiency of point addition operation and overall system performance. Certain pre-processing tests and verifications can be performed before application to ensure that the selected window size selection strategy can perform optimally in actual scenarios. Through this method, the execution efficiency of point addition operation and overall system performance can be optimized, providing more accurate and efficient processing methods, especially suitable for complex computing task application scenarios.

[0061] In another embodiment, dynamic adjustment of window size can be achieved based on statistical analysis and machine learning models to further improve computing efficiency. For example, a trained machine learning model reflects the correspondence between one or more of Montgomery multiplication computation, GPU resources, and window size. In this way, more accurate prediction and adjustment of window size can be achieved, maximizing the use of GPU resources, thereby improving the efficiency of computing operation to adapt to different workloads and hardware environments.

[0062] In summary, compared to the fixed window size of the original Pippenger algorithm, by using a more fine-grained mechanism in the window splitting stage and adjusting the window size according to actual computing requirements, the workload can be more accurately allocated, avoiding performance loss or resource waste caused by excessively large or small windows. Moreover, since the selection of window size is based on specific computing requirements, it can be flexibly adjusted according to different application scenarios and hardware configurations, so that the best running state can be achieved under various conditions.

[0063] 2. In-bucket point reduction unit

[0064] The in-bucket point reduction unit is used to classify points on each elliptic curve finite field into buckets. For example, in the case of a window size of c, that is, every c bits is a window, each window corresponds to an array of size 2 c -1, that is, a bucket. For example, in combination with Figure 4As shown, after decomposing the scalar into a 4-bit window, each point on the elliptic curve finite field can be classified into a bucket covering the range of 1-15. It should be noted that since the point multiplication of the bucket with the number 0 is reduced to the bucket, the result is zero, so the 0th bucket can be considered as not calculated.

[0065] For the point reduction in the bucket, after selecting the appropriate window size, initialize 2 c -1 buckets, and then sequentially accumulate G i to the bucket corresponding to its coefficient k i,j , calculate the result of each sub-MSM, and implement the parallel execution in the bucket through the point reduction in the bucket. However, the traditional Pippenger algorithm often cannot reasonably use GPU threads, resulting in a part of the bucket threads being idle for a long time, while another part of the bucket threads is excessively busy, thereby reducing the overall throughput and efficiency of the system.

[0066] In an embodiment of the present application, for the point reduction in the bucket in the Pippenger algorithm, a load-balanced scheduling mechanism and parallelization structure are designed according to the number of points in the bucket to ensure the reasonable scheduling of resources during the execution of the algorithm.

[0067] When considering the allocation of threads, the traditional algorithm usually allocates the number of GPU threads according to a fixed window size, but since the number of points in each bucket may differ greatly, this leads to uneven distribution of work tasks. To solve this challenge, in an embodiment of the present application, first, the number of points in each bucket is counted, and after all points are placed, the allocation of threads is dynamically adjusted according to the proportion of points in each bucket. In addition, during the calculation process, the system monitors the number of points and the calculation progress in each bucket in real time. Once the calculation task in a certain bucket is completed, the system collects data about the current state of all buckets. Based on the collected data, the system reevaluates the dynamic thread allocation. For example, more threads are allocated to the bucket that is still processing a large number of points, or the resource allocation is reduced to the bucket that has completed the calculation. The above process is repeated periodically until all calculation tasks are completed. This cyclic iteration can ensure that the system can dynamically adjust resource allocation when processing complex data distribution, thereby improving the overall calculation efficiency and performance utilization.

[0068] This method can effectively optimize the utilization of GPU and improve the overall calculation efficiency. In addition, a new parallel structure is further introduced during the actual execution of the task, as shown in the bucket parallel architecture diagram Figure 6 , which adopts a tree structure for pairwise pairing to support the parallel operation of the reduction of points in the bucket. This structure not only can effectively process large-scale data sets, but also can realize efficient data communication and cooperation between different buckets, thereby further improving the parallelization performance of the algorithm.

[0069] In summary, the design of the parallel structure enables the calculation of the in-bucket point reduction phase to be performed more efficiently. By means of the pairwise pairing parallel operation of the tree structure, the dependency relationship between the calculation tasks can be effectively reduced, and the overall calculation delay can be reduced. This optimization is particularly important for the requirement of quickly generating proofs in the zero-knowledge proof generation process, and can significantly shorten the time required to generate proofs.

[0070] 3. In-window reduction unit

[0071] For a given window, when each point is classified into a bucket, all points can be added to obtain a point for each bucket. For each window, multiply all bucket values by their bucket numbers and then add them together to obtain a window value.

[0072] Specifically, still in combination with Figure 4 shown, multiply the bucket number (u) by the reduced bucket (B j ), and then accumulate the buckets in the same window into one bucket. For the operation of in-window reduction, the present application uses the prefix sum idea to optimize, when a bucket is reduced, the reduction result can be updated to the cumulative sum of the previous window in an incremental manner, in this way, it avoids recalculating the cumulative sum of the previous window from the beginning each time, but realizes more efficient calculation through incremental updating. This way reduces the calculation amount of in-window reduction to The specific algorithm is as follows: by recording from the last bucket, when processing the in-window reduction, only the cumulative sum of the previous window needs to be simply added to obtain the cumulative result in the current window, thereby significantly improving the calculation efficiency and reducing the complexity.

[0073] For example, the calculation process of in-window reduction is represented as:

[0074]

[0075] where u represents the bucket number, [B j ] represents that it is a bucket in Y j , and Y j represents the jth MSM of c-bit that is split.

[0076] 4. Window aggregation unit

[0077] The window aggregation unit (or window reduction unit) is used to: when the window value of each window is calculated, they can all be added to obtain the final output of the MSM.

[0078] For example, still in combination with Figure 4 shown, in the window aggregation unit, the algorithm flow is optimized by multiplication distribution rate, using 2 cDot product last window Y L , then accumulated to the second last window, then multiplied by 2 c dot product the merged window, so recursively until the final window Y0 is merged. Specifically, the window reduction is expressed as:

[0079]

[0080] where Q represents the window reduction result, Y L represents the Lth window value.

[0081] For the sake of clarity, still in conjunction with Figure 3 shown, the role of the present application in ensuring the security and efficiency of the blockchain transaction is described. In the generation process of the zero-knowledge proof, a trusted setting stage is essential, which defines the public parameters of the entire zero-knowledge system framework, including the selection of elliptic curve, generator, and other problem parameters, which ensure network consistency and security. The main responsibility of the trusted device is to convert the circuit constraints of the specific problem, that is, to convert the smart contract or business logic into the R1CS format suitable for zero-knowledge proof. R1CS is a linear algebra model for expressing constraints, which allows complex computing logic to be converted into a set of linear constraints. Optimizing this conversion process, such as reducing the number of unnecessary constraints, can significantly reduce the complexity of the proof, and in turn reduce the time and resource consumption required to generate the proof.

[0082] In the proof generation part, the prover first converts the R1CS constraints into polynomial form through a number theoretic transform (NTT), and then performs solving operations on them, which is a multi-round multi-scalar multiplication calculation. This part is also the largest part of the prover's operation, often accounting for about 75% of the entire proof generation process. Given the importance of MSM, the present application optimizes it in particular. The optimization strategy is to decompose MSM in order to take advantage of the parallel processing capabilities of GPU and improve computational efficiency. Specifically, the optimization scheme first subdivides the large-bit-width MSM into multiple small-bit-width MSMs in the split window unit, facilitating GPU parallel processing; and by dynamically adjusting the window size, it ensures optimal partitioning of sub-tasks based on Montgomery modular multiplication calculation estimates, while using real-time monitoring and feedback mechanisms to dynamically adjust the window size to adapt to different workloads and hardware environments. In the in-bucket point reduction unit, a load-balanced scheduling mechanism is implemented, which dynamically adjusts GPU thread allocation based on the number of in-bucket points, and combines tree structure to support in-bucket point reduction parallel operation, optimizing GPU utilization and overall computational efficiency. The window-in reduction unit uses the prefix sum idea for optimization, reducing the calculation amount and complexity through incremental updating to improve the calculation efficiency of window-in reduction. Finally, the window aggregation unit uses the distributive law of multiplication to optimize the algorithm process, recursively merging window values until the final MSM output is obtained, significantly accelerating the proof generation process. Through these comprehensive optimization measures, the prover can significantly improve the speed of proof generation, especially when dealing with large-scale data sets and complex computing tasks, ensuring that the zero-knowledge proof system is more stable, real-time and efficient in practical applications. The final proof generated is submitted to the blockchain network, which contains encrypted information confirming the validity of the transaction, but does not reveal any substantive personal or financial details. Other nodes in the blockchain network, as verifiers, use the same public parameter key and verification algorithm to check the validity of the proof and confirm the legality of the transaction without knowing the specific transaction value. Once the proof passes the verification, 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.

[0083] It should be noted that although the system provided by the present application is described in the form of functional units, in actual application, these units can also be integrated as hardware accelerators or acceleration devices embedded with blockchain nodes to improve the computational efficiency of proof generation.

[0084] In summary, the present application analyzes and optimizes the Pippenger algorithm, which is beneficial to fully utilize the advantages of GPU parallel computing, especially when dealing with large-scale multiple scalar multiplication operations. Pippenger algorithm reduces the complexity of multiple scalar multiplication by reducing the number of multiplication operations, which is particularly effective for cases where there are more allocations of points within each bucket. First, through a reasonable workload allocation mechanism, it ensures that each thread on the GPU can be fully utilized, avoiding thread idling, thereby maximizing parallelism. Second, algorithm-level optimizations such as using shared memory and reducing data transmission further improve computing efficiency. These optimization measures not only reduce the overall complexity of the algorithm, but also significantly shorten the calculation time. By parallelizing the computing task, GPU can handle multiple multiplication operations simultaneously, significantly improving the execution speed of multiple scalar multiplication compared to traditional CPU computing. This specialized optimization is not only suitable for scientific computing and data processing fields, but also particularly important for application scenarios that require real-time response and high-performance computing.

[0085] In summary, compared with the prior art, the present application has the following advantages:

[0086] 1) The present application provides an optimization scheme for the proof generation speed of zero-knowledge proof system, which significantly improves the proof generation speed while maintaining the security, integrity and confidentiality of zero-knowledge proof. It is suitable for current systems using zk-SNARK technology without modifying the existing proof generation process and steps. Moreover, an optimization scheme compatible with existing zk-SNARK technology systems is designed, which specifically improves the efficiency of multiple scalar multiplication calculation.

[0087] 2) The present application provides an analysis mechanism for Pippenger algorithm and improves its algorithm process, which fully utilizes the performance of GPU and speeds up the calculation of multiple scalar multiplication module. First, a dynamic window selection algorithm is designed to optimize the split window phase of Pippenger algorithm, which reasonably allocates large-scale multiple scalar multiplication operations and achieves significant performance improvement. Further, the resource allocation strategy of Pippenger algorithm in the bucket point reduction phase is improved to ensure the effective use of GPU resources, and an optimized calculation structure is designed to enable efficient parallel execution, thereby speeding up the calculation speed of multiple scalar multiplication module. In addition, by restructuring the processes of window bucket reduction and window reduction, an efficient prefix sum algorithm is introduced, which significantly improves the running efficiency of the calculation. These improvements maintain the correctness of the calculation while effectively reducing the time and resource consumption required for the calculation.

[0088] 3) The application is based on the Pippenger algorithm, which divides the multi-scalar multiplication definition into four parts, modularizes and optimizes them respectively. Through scalar decoupling and the parallel advantage of GPU, the multi-scalar multiplication can perform parallel operation, thereby reducing the waiting time required for operation and improving the proof generation efficiency.

[0089] 4) The traditional Pippenger algorithm often cannot fully utilize the parallel computing capability of the GPU in the bucket point reduction stage, resulting in a large number of threads being idle or overloading and waiting. The application designs a scheduling mechanism for the workload, dynamically allocates threads according to the number of points in each bucket, maximizes the use of GPU thread resources, avoids the idling of threads, and significantly improves the calculation efficiency of the multi-scalar multiplication module.

[0090] 5) After multiple tests and verifications, the application can meet the expected design indicators, and does not need to consider specific zero-knowledge proof schemes and forms, and can adapt to the current zk-SNARK zero-knowledge proof generation system under any condition.

[0091] The application can be a system, a method and / or a computer program product. The computer program product can include a computer readable storage medium having computer readable program instructions loaded thereon for causing a processor to implement various aspects of the application.

[0092] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. More specific examples (a non-exhaustive list) of the computer readable storage medium include a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punched card or a concave and convex structure in a slot, and any suitable combination of the above. The computer readable storage medium used herein is not to be interpreted as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (for example, an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0093] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0094] Computer readable program instructions for carrying out operations of the present application can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computing / processing device, partly on the user's computing / processing device, as a stand-alone software package, partly on the user's computing / processing device and partly on a remote computing / processing device or entirely on the remote computing / processing device or server. In the latter scenario, the remote computing / processing device can be connected to the user's computing / processing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing / processing device, for example, through the Internet using an Internet Service Provider. In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0095] The computer readable program instructions can also be loaded onto a computing / processing device, other programmable data processing apparatus, or other device to cause a series of operations to be performed on the computing / processing device, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computing / processing device, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0096] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include a non-transitory computer readable storage medium that can be a computer- readable storage medium having no data, programs, program modules, e.g., instructions for operation, or digital content stored thereon or therein for a short time or not at all. The computer readable storage medium can also have instructions stored thereon or therein which may

[0097] The computer readable program instructions can 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 apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0098] The flow diagrams and block diagrams in the accompanying drawings show archi tectures, functional and operational architectures of possible implementations of systems, methods, and computer program products according to the present disclosure. In this regard, each block in the flow diagrams and block diagrams can represent a module, a segment, or a portion of instructions, which comprises one or more executable instructions for implementing the specified logical functions (acts). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in some cases, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0099] Having described various embodiments of the application, it is to be understood that the above description is meant to be illustrative only and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art, without departing from the scope and spirit of the described embodiments. The selection of terms to be used in the description is intended to best explain the principles of the embodiments, the practical application, or technical improvement over the prior art, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of the application is defined by the claims appended hereto.

Claims

1. A general zk-SNARK zero-knowledge proof optimization system, comprising: Trusted devices, provers, and verifiers, among which: 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; 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. The verifier compares the key sent by the trusted device with the proof generated by the verifier to confirm the validity of the proof; 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 the points on each elliptic curve finite field to buckets 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 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. The splitting window unit splits a multi-scalar multiplication operation of size λ-bit into multiple subtasks according to the following formula: Where N represents the scale of multiscalar multiplication, c is the window size, and c < λ. Y j This represents a multiscalar multiplication of the j-th c-bit, k i，j Let j represent the j-th part of the i-th scalar, where i ∈ [1, N] and j ∈ [1, L]. The split window unit sets the window according to the following steps: Before each subtask begins, estimate the required Montgomery modular multiplication computations and obtain the estimated amount. Select the corresponding window size based on the estimated value and execute the subtask; The actual computational load of each subtask is monitored in real time, and the difference between the actual computational load and the estimated load is compared to determine whether to adjust the window size of the next subtask.

2. The system according to claim 1, characterized in that, The reduction unit within the window is calculated according to the following formula: Where u represents the bucket number, [B j ] indicates that it is Y j The bucket in the middle.

3. The system according to claim 2, characterized in that, The window aggregation unit obtains the calculation result of the multi-scalar multiplication according to the following formula: Among them, Y L Y0 represents the Lth window as the last window, Y1 represents the first window after merging.

4. The system according to claim 1, characterized in that, The split window unit sets the window according to the following steps: Before each subtask begins, estimate the required Montgomery modular multiplication computations and obtain the estimated amount. Select the corresponding window size based on the estimated value and execute the subtask; Monitor the actual computational load of each subtask in real time, and calculate the difference between the actual computational load and the estimated load; The difference is fed into a trained deep learning model to determine whether to adjust the window size for the next subtask.

5. The system according to claim 1, characterized in that, The in-bucket point reduction unit performs the following process: By counting the number of points in each bucket, the thread allocation is dynamically adjusted according to the proportion of points in each bucket; During the calculation process, the number of points in each bucket and the calculation progress are monitored, and when the calculation task in a bucket is completed, the current status data of all buckets are collected. Based on the collected data, a re-evaluation of dynamic thread allocation is performed.

6. The system according to claim 5, characterized in that, For the reduction units within the bucket, a tree structure is used to pair them up in pairs to perform parallel reduction operations on the bucket points.

7. A general zk-SNARK zero-knowledge proof optimization method based on the system described in any one of claims 1 to 6, comprising the following steps: Generate and manage security parameters and keys used for zero-knowledge proofs; 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. The validity of the proof is confirmed by comparing the key with the generated proof. The multi-scalar multiplication operation is implemented according to the following steps: 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. Reduce the points on the finite field of each elliptic curve to buckets to obtain the results of each subtask; 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; Based on the window value of each window, the calculation result of the multiscalar multiplication is obtained.

8. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed by the processor, it implements the steps of the method according to claim 7.

Images