Zero knowledge proof-oriented multi-scalar multiplication hardware parallel acceleration method and device

Abstract

The invention discloses a zero-knowledge proof-oriented multi-scalar multiplication hardware parallel acceleration method and device, and relates to the technical field of cryptographic acceleration and parallel computing. The method is based on a field programmable gate array, an improved multi-channel parallel Pippenger algorithm is utilized, and the parallel acceleration of the multi-scalar multiplication hardware is realized. The method comprises the following steps: firstly, performing scalar preordering, performing conflict-free data scheduling and designing a compact large integer multiplier to accelerate large-scale elliptic curve scalar multiplication, and selecting a window size and a precomputation scale by adopting an adaptive extensible 3D-Pippenger algorithm; in a data stream level, conflict between empty bucket reading and bucket writing is avoided through scalar slice merging sorting and pointer caching strategies. The acceleration circuit is suitable for various elliptic curves and different zero-knowledge proof protocols, and can be widely applied to scenes such as block chain private transactions, verifiable database outsourcing and verifiable machine learning.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of cryptography acceleration and parallel computing, in particular to a multi-scalar multiplication hardware parallel acceleration method and device for zero-knowledge proof. BACKGROUND

[0002] With the rapid development of the Internet and blockchain technology, more and more application scenarios begin to pay attention to user privacy and data security. Whether it is an e-government system or a decentralized financial platform, it is necessary to realize efficient and secure data verification and interaction while ensuring that sensitive information is not leaked. Under this demand background, zero-knowledge proof (ZKP) technology as a kind of cryptographic tool that can "verify the authenticity of statements without revealing any additional information" has attracted attention from academia and industry in recent years. Through ZKP, the prover (Prover) can provide the verifier (Verifier) with strong evidence that "something is true" without revealing the relevant details. This feature, while ensuring security and privacy, also has high versatility and flexibility, and is gradually being widely used in electronic voting, private financial transactions, blockchain scalability, and verifiable machine learning and many other fields.

[0003] Among many ZKP protocols, zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) is particularly eye-catching. Compared with other types of ZKP protocols, zk-SNARK has the following significant advantages: short proof: usually only a few hundred bytes are needed to complete the output of a proof; efficient verification: the verifier can complete the verification of the proof result in a few milliseconds; non-interactive: the proof process does not require multiple rounds of communication, greatly reducing communication costs, and is particularly convenient in a decentralized environment.

[0004] However, the process of generating a proof of zk-SNARK is not simple, and the most time-consuming part includes the Number Theoretic Transform (NTT) and the Elliptic Curve Multi-Scalar Multiplication (MSM). If zk-SNARK is applied to large-scale data scenarios, such as private transactions on the blockchain or verifiable inference of machine learning models, the number of scalars and elliptic curve points required can reach millions or even hundreds of millions, resulting in extremely large computational load of MSM. Specifically, multi-scalar multiplication refers to multiplying each scalar with its matching point and then adding all the products. Since scalars often have a bit width of 256 or higher, and elliptic curve points themselves often need to be stored or operated with a bit width of 377 or higher, there is a large integer modular multiplication overhead of hundreds or even thousands of bits. Such operations, once massively parallelized, become the main performance bottleneck of the entire zk-SNARK protocol.

[0005] In existing research, the industry mainly improves the execution speed of MSM from the following two levels: algorithm level optimization, Pippenger algorithm, which divides the scalar into a window, and then uses the bucket accumulation and final aggregation method to effectively reduce repeated calculations, and is considered to have the best performance in large-scale scenarios; Straus method, Chang-Lou algorithm, Bos-Coster algorithm, etc.: also play a role in different sizes or specific applications, such as dealing with partial repeated scalar slices or mixed elliptic curve operations. These algorithms all aim to reduce the total number of point additions and doubling (PADD and PDBL) required, thereby reducing the computational complexity of MSM. Hardware acceleration level design, multi-core CPUs can improve MSM speed through SIMD vectorization, multi-thread concurrency, etc., but still have difficulties when facing super large-scale data; GPUs have high parallelism and can achieve good speedup in some scenarios, but the floating-point calculation unit of the GPU does not completely match the large integer modular operation, and large-scale parallelism often comes with high power consumption; ASICs can be customized for specific algorithm processes, and in theory can achieve the best performance and energy efficiency, but their development cycle is long, the cost of tape-out is high, and there is a lack of flexibility in the later stage, which is not suitable for frequently iterated application scenarios; FPGA achieves a good balance in flexibility, energy consumption, parallelism, and deployment cycle, supports reconfigurable DSP, LUT, BRAM, etc. resources, and by designing appropriate operation units and data flow scheduling, the execution time of MSM can be significantly reduced, making FPGA a relatively ideal solution.

[0006] Although there are many academic researches and open-source projects on FPGA platform for MSM acceleration, they still have some problems in specific implementation: random setting of algorithm parameters, difficulty in balancing hardware resources and algorithm efficiency, etc. The traditional Pippenger algorithm contains many key parameters, such as window size, parallel channel, and pre-computed point scale. If there is no systematic theoretical analysis, a fixed window size may be determined only according to empirical values or simple experiments, which is not suitable for different scale MSM tasks. For example, for small-scale MSM, a large window size will cause excessive memory overhead of bucket number and pre-computation; for super-large-scale MSM, if the window size is too small, the number of scalar slices will increase, causing frequent storage read-write and calculation overhead. The choice of parallel channel number is also closely related to hardware DSP, memory capacity (BRAM / URAM / HBM), etc. If the number of channels is insufficient, it is difficult to reflect the parallelism advantage of FPGA, and if the number of channels is too large, it may cause memory bandwidth or storage resource bottleneck. This "unsystematic" configuration often causes the algorithm to not perform optimally. Incomplete data flow scheduling, easy to produce empty bucket reading and write conflict, the core of multi-scalar multiplication is the storage and read-write of elliptic curve points (or EC points). If the scalar slices are not concentrated, a large number of "empty buckets" may occur, i.e. in a certain clock cycle, a bucket that should have a point accumulation is accessed, but there is no corresponding scalar slice data, and the pipeline is thus stalled. Even worse, if there is a bucket address conflict between write-back and read-out, additional hardware mechanisms are needed to buffer or rearrange the data, increasing the register and FIFO overhead, making the design complex and not conducive to high-frequency operation. Some existing designs even require manual traversal of each bucket, resulting in unnecessary waiting and performance waste. Large integer multiplier overhead is too large, and DSP / LUT resources are overburdened. In MSM, the most resource-consuming unit is the large integer multiplier, because both scalar multiplication and point addition, doubling operations internally require multiple modular multiplications. If the hardware designer does not optimize the FPGA native DSP block, the number of DSPs will often increase, making it difficult to complete placement and routing or the frequency does not meet expectations. Especially in high-bit-width (256-768-bit) operation scenarios, if only simple on-chip multiplication splicing is performed, the effective utilization rate of DSP is not high, a large number of bits are empty, or a large number of LUTs are needed for partial multiplication and addition, resulting in a sharp increase in resource consumption and difficulty in further improving frequency.

[0007] Therefore, multiscalar multiplication (MSM) is one of the most complex and critical computational tasks in zero-knowledge proof systems, directly determining the overall performance of proof generation. This invention focuses on the computational bottleneck of MSM, achieving significant acceleration of large-scale MSM on FPGA platforms through careful selection of algorithm parameters, reasonable dataflow design, and FPGA-oriented multiplier optimization. It also boasts versatility, scalability, and low energy consumption.

[0008] Therefore, as the demand for ZKP in blockchain and privacy computing scenarios becomes increasingly urgent, there is a pressing need in this field for a high-throughput, universal, and scalable method and apparatus for accelerating multiscalar multiplication. This is of great significance for promoting the large-scale deployment of zk-SNARK and other ZKP protocols. Summary of the Invention

[0009] The present invention proposes a hardware parallel acceleration method and apparatus for multi-scalar multiplication oriented towards zero-knowledge proofs, in order to solve the problems mentioned in the prior art.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: a hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs, comprising the following steps: S1: Divide the original scalar data into scalar slices of fixed bit width, and merge and sort the batch of scalar slices in the FPGA; S2: Based on the sorted scalar slice values, generate a pointer index for each scalar slice, and merge scalar slices with the same value and store them in the pointer cache; S3: Use the multi-channel parallel Pippenger algorithm for pre-computation and bucket aggregation, and reduce redundant point addition PADD operations by adaptively selecting the window size and pre-computation scale. S4: At the data flow level, scalar pre-sorting and pointer index control are used to avoid conflicts between empty bucket reads and bucket writes. S5: Output the final result of the multi-scalar multiplication to the host or upper-layer protocol for further processing.

[0011] Furthermore, the multi-channel parallel Pippenger algorithm in step S3 includes: selecting a window size S that is adapted to hardware resources and memory limits, slicing the scalar by bit width; allocating buckets to the scalar values ​​corresponding to each window, and accumulating elliptic curve points with the same scalar value into the same bucket in parallel; performing a one-time aggregation on each bucket to obtain a partial result of each window slice; iteratively accumulating all partial results between windows to obtain the final multi-scalar multiplication output.

[0012] Further, the step S4 avoids empty bucket reading and reduces pipeline bubbles by establishing pointer index in the scalar pre-order stage, so that only the buckets with actual useful data are accessed when the PADD calculation unit reads the bucket address.

[0013] Further, the following steps are also included: during the execution of the multi-scalar multiplication, by automatically detecting the pointer cache and bucket cache occupancy, when the pointer cache is about to overflow, the scalar reading is paused; when the bucket cache writable space is insufficient, the existing results are preferentially scheduled to write back and clean up the space, to ensure the stability and continuity of the data flow.

[0014] Further, the device for the zero-knowledge proof-oriented multi-scalar multiplication hardware acceleration method comprises: a scalar preprocessing module: used for reading original scalar data and completing scalar slicing, merge sorting, and pointer index generation; an input cache: in communication with an external memory or a host end, used for caching elliptic curve point data; a bucket cache: used for storing and accumulating intermediate results in the multi-channel parallel Pippenger algorithm; the bucket cache is constructed by using on-chip URAM or BRAM resources, and the number of buckets is determined by the window size; if the Non-Adjacent Form scalar expression method is combined, the number of buckets is halved, and the storage cost is saved; a calculation array: composed of unified point addition PADD units, used for reading and accumulating point data in the corresponding buckets according to the pointer index instruction; a control module: used for adaptively selecting the window size and the pre-computation scale according to the FPGA resource constraints during runtime, and coordinating the data flow between the scalar preprocessing module, the input cache, the bucket cache, and the calculation array.

[0015] Further, the unified PADD units in the calculation array perform point addition and point multiplication in the twisted Edward coordinate system, and split the long path operation into a two-stage pipeline structure, so that each stage of operation path is roughly equal, thereby avoiding additional FIFO buffer and register overhead caused by data dependency.

[0016] Further, the large integer multiplier in the unified PADD unit adopts the Karatsuba divide-and-conquer algorithm, and uses the DSP frequency multiplication strategy to improve the utilization rate of the DSP in limited bit-width multiplication, to double the operation capability under fixed DSP resources.

[0017] Further, the following device is also included: a pointer cache: used for storing EC point pointer information corresponding to the same scalar value; a data flow scheduling module: based on the address instruction provided by the pointer cache, the accurate bucket address or input cache address instruction is issued to the calculation array, so as to avoid write conflict and empty bucket reading.

[0018] Further, the merge sort in the scalar preprocessing module adopts a pipeline structure, and each time a scalar slice is processed in parallel; after the merge sort is completed, the pointers corresponding to the scalar slices with the same value are merged and uniformly output to the pointer cache.

[0019] Further, the control module automatically adjusts the number of parallel channels and the scale of pre-computation points according to the specific resource situation of the FPGA, and balances between throughput and hardware overhead.

[0020] Compared with the prior art, the beneficial effects of the present application are: An adaptive "three-dimensional Pippenger algorithm" is proposed, two degrees of freedom of the number of parallel channels and the scale of pre-computation points are added on the basis of the Pippenger principle, and the parameters are automatically optimized in combination with hardware DSP and storage resources, which theoretically and practically ensures the efficiency of zero-knowledge proof elliptic curve operations of various scales; a scalar preprocessing and conflict-free data scheduling mechanism is proposed, batch merge sort and pointer merging are used to accurately control bucket access, so that empty bucket reading and write conflict almost disappear, and a simple delayed write-back strategy is used to keep the pipeline full, which not only effectively reduces the register and FIFO overhead, but also enables large-scale parallel channels to be fully utilized; a depth optimization of the unified PADD unit and the splittable big integer multiplier (BI-Mult) is proposed, the difference between point addition / multiplication is simplified by twisting the Edwards coordinate system, and two-stage pipelining is used to reduce data correlation; in the multiplier, Karatsuba divide-and-conquer and DSP frequency multiplication are used to obtain higher multiplication throughput under the same DSP resources, and the performance of the MSM is improved as a whole.

[0021] The present application will play an important role in typical scenarios such as large-scale blockchain privacy applications, verifiable machine learning and verifiable database outsourcing. Especially under the increasing demand for zero-knowledge proof, it can meet the requirements of computing efficiency, resource occupation and scalability, and has practical significance for promoting the industrial landing of cryptography and privacy computing. Through the method and device provided by the present application, people can quickly deploy a high-efficiency MSM acceleration engine on general-purpose FPGA hardware, greatly shorten the ZKP generation time, and reserve space for flexible upgrade. If combined with ASIC implementation, the unified PADD and BI-Mult structure in the present application can be "solidified" into a special circuit to achieve higher energy efficiency and operating frequency to meet the demand for extreme performance. Whether it is an FPGA or an ASIC platform, the method and circuit design of the present application show good reusability and scalability, and can be universally applicable to various cryptography protocols.

[0022] It can be seen that the application overcomes the bottleneck of the traditional MSM hardware acceleration scheme by innovating in the algorithm, data flow and hardware design three levels, and realizes the great speed-up of the most core computing link in zero-knowledge proof. Through the adaptive "three-dimensional Pippenger algorithm", scalar pre-ordering and pointer merging, and the depth optimization of unified PADD and Karatsuba frequency multiplier, the bottleneck points such as empty barrel reading, write conflict and high bit width multiplication resource waste are completely eliminated, so that the FPGA can maximize the release of parallel potential in the MSM acceleration task. Since MSM accounts for more than 70% of the calculation amount of the generation stage of zk-SNARK or PLONK protocol, the application will significantly reduce the proof generation time, and has wide application prospects in distributed blockchain nodes, data center privacy computing acceleration and edge terminal lightweight acceleration. In combination with the subsequent optional NAF representation method, more levels of pre-computation or the use of different curve coordinate systems (such as Montgomery coordinates or Projective coordinates), the application can also continue to expand to an adaptive MSM hardware acceleration solution to meet diversified application scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0023] The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the principles of the application. The drawings are provided solely for purposes of illustration to those skilled in the art.

[0024] Figure 1 The scalar cutting process schematic diagram of the barrel algorithm used by the application is shown in the figure. The figure shows how the original scalar is cut according to a certain bit width or window size before the start of the multi-scalar multiplication, so as to form a plurality of relatively small scalar segments. Through this process, the large bit width scalar can be converted into a sub-scalar that is easier to process, and the basic data preparation is provided for the subsequent barrel accumulation and aggregation.

[0025] Figure 2 The barrel accumulation process schematic diagram of the barrel algorithm used by the application is shown in the figure. The figure illustrates how to add the elliptic curve points corresponding to each cut piece to the corresponding barrel after obtaining the segmented scalar cut piece. When the scalar value corresponding to a certain barrel appears multiple times, the system will batch accumulate multiple scalar points with the same value, so as to reduce repeated calculation and improve the efficiency of point addition operation.

[0026] Figure 3 The barrel aggregation and result accumulation process schematic diagram of the barrel algorithm used by the application is shown in the figure. The figure shows how to aggregate the local results in each barrel in order and superimpose them into the final multi-scalar multiplication result after completing the barrel accumulation. Through multiple "barrel aggregation" and "window-by-window accumulation", the point addition results originally dispersed in each window cut piece can be orderly collected to obtain the complete calculation output.

[0027] Figure 4 : The overall structure diagram of the present application, including the initial scalar data storage module, the elliptic curve point data storage module, the AXI bus, the scalar preprocessing module, the input data cache module, the calculation array and the bucket cache module. This diagram reveals the overall design idea of the multi-scalar multiplication accelerator from the system level, showing the whole process from the input storage of scalar and elliptic curve points, through the AXI bus transmission, to the scalar preprocessing, to the operation and intermediate result storage of the calculation array and the bucket cache, and finally to the result output.

[0028] Figure 5 : The schematic diagram of the scalar preprocessing module used in the present application. This diagram focuses on the internal structure and data flow direction of the scalar preprocessing module, including the reading of scalar slices, the merge sorting or grouping integration of the scalar slices, the generation of pointer information and the like. Through preprocessing, randomly distributed scalar slices can be arranged in order, so that the subsequent bucket algorithm can accurately locate the same value scalar and efficiently complete the accumulation when executing.

[0029] Figure 6 : The schematic diagram of the bucket cache module used in the present application. This diagram illustrates the role of the bucket cache in the whole accelerator, including storing the intermediate results of elliptic curve point accumulation corresponding to different windows, and providing readable and writable target addresses for the calculation array or the unified point adder. The bucket cache module can perform conflict-free scheduling according to the pointer information in the scalar preprocessing stage, effectively avoiding common problems such as empty bucket reading and write conflict.

[0030] Figure 7 : The schematic diagram of the calculation array used in the present application. This diagram focuses on how multiple unified point addition or doubling units work in parallel to process large-scale elliptic curve operations scattered in different windows or scalar slices. Each parallel unit can perform point addition operation and doubling operation, and realizes load balancing under the coordination control, thereby improving the overall throughput of multi-scalar multiplication.

[0031] Figure 8 : The schematic diagram of the input data cache module used in the present application. This diagram describes how to store and distribute a large number of elliptic curve point data in on-chip cache when reading from external memory (such as DDR or HBM) through AXI bus. By reasonably configuring the depth and bandwidth of the cache, a relatively stable point data input rate can be maintained under limited hardware resources, providing continuous data supply for the subsequent parallel operation of the calculation array.

[0032] Figure 9The schematic diagram of the barrel cache data read by the universal point adder used in the application. The figure emphasizes how the universal point adder reads the previously accumulated or temporarily stored elliptic curve points from a specific barrel address according to the pointer information provided by the scalar preprocessing stage before performing point addition or doubling. Through precise address control, the system can efficiently complete the read operation and prepare for subsequent operations.

[0033] Figure 10 The schematic diagram of the barrel cache data write by the universal point adder used in the application. The figure shows how to write the updated elliptic curve point results back to the barrel cache after the universal point adder completes a point addition or doubling operation. If there is an address conflict or a write-back sequence conflict, the system will use delayed writing or buffering to avoid pipeline stalls and ensure the continuity of the overall operation process.

[0034] Figure 11 The schematic diagram of the point addition calculation process performed by the application. The figure illustrates the key processes of point addition operation from the time and operation step angles, including reading of point coordinates, execution of modulo addition and multiplication, temporary result register caching, and final coordinate write-back. This process is applicable to both single point addition and doubling operations through reuse of the same circuit.

[0035] Figure 12 The circuit structure diagram of the universal point adder used in the application. The figure details the layout of hardware components for implementing point addition and doubling operations in twisted Edwards or other coordinate systems, including difference path, sum path, multiplexer, and two-stage pipeline design. By combining point addition and doubling into the same circuit structure, the utilization of DSP and LUT can be improved and redundant functional units can be reduced.

[0036] Figure 13 The schematic diagram of the combination of divide-and-conquer method and frequency doubling technology used in the application. The figure illustrates how to use Karatsuba or similar divide-and-conquer algorithm for high-bit-width integer blocking in a large integer multiplier, and then combine DSP frequency doubling strategy to complete multiple multiplication and accumulation in the same clock cycle, thereby significantly improving the throughput of modulo multiplication and achieving better usage efficiency in area resources. DETAILED DESCRIPTION

[0037] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the application. Obviously, the described embodiments are only a part of the embodiments of the application, not all embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0038] In the description of the application, it is to be understood by the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, which is only for the convenience of describing the application and simplifying the description, and does not indicate or imply that the indicated device or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the application.

[0039] In addition, the terms "first", "second" are only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more of the features. In the description of the application, the meaning of "multiple" is two or more, unless otherwise specifically limited. In addition, the terms "mounting", "connecting", "connecting" should be broadly understood, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium, or it can be the communication between two elements. For those skilled in the art, the specific meaning of the above terms in the application can be understood according to the specific circumstances, and the application will be further described in detail below with reference to the drawings.

[0040] Reference Figures 1 to 13: In the multi-scalar multiplication acceleration method and device described in the application, the first need to clarify a core concept is the role of multi-scalar multiplication in the zero-knowledge proof protocol. Zero-knowledge proof (ZKP), especially zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK), frequently calls elliptic curve operations in its generation process, and the most important and time-consuming operation is multi-scalar multiplication (MSM). Multi-scalar multiplication, simply put, is given n scalars and n elliptic curve points, respectively calculating the scalar multiplication of each scalar and its corresponding curve point, and then adding all the result points together to get the final accumulated elliptic curve point. Since this operation is repeated on a large number of points in the generation process of zk-SNARK, it determines the performance bottleneck of the system as a whole. The existing software implementation, or only on the CPU platform with conventional instruction set for large integer operation, cannot meet the industry practical standard; while GPU has rich parallel threads and strong acceleration ability for floating point operation, but it does not completely match the large integer modular operation, and also faces the problems of high power consumption and complex register allocation. Corresponding to this, FPGA gradually becomes a mainstream choice for hardware acceleration of multi-scalar multiplication with its reconfigurable parallel circuit and moderate power consumption.

[0041] Before introducing the specific embodiment, the overall framework of the implementation idea of the application needs to be reviewed first, as shown in Figure 4 , we at least include the following main modules on the hardware: initial scalar data storage module, elliptic curve point data storage module, scalar preprocessing module, input data cache module, calculation array (including a unified point adder), bucket cache module, and an internal or external bus for data transmission and scheduling. Figure 4 The overall architecture is shown in , where the initial scalar data is usually stored in an external DDR4 or HBM memory device, and is sent to the scalar preprocessing module through the AXI bus burst mode; similarly, the elliptic curve points are also loaded in batches at the start of the FPGA or when the operation is needed. It is worth noting that the application does not strictly require all points to be loaded into the on-chip cache at one time, but flexibly allocates data according to hardware resources and operation scale. If the resources are sufficient, the commonly used curve points can be saved on-chip as much as possible to reduce transmission delay, and if the resources are limited, they can be loaded in segments and matched with the unique conflict-free scheduling of the application.

[0042] Returning to Figure 1 , Figure 2 , Figure 3 the bucket algorithm itself. Figure 1The scalar cutting is about how to split a high bit-width scalar into several pieces according to a pre-selected window size. If the window size is set as s, then a 256-bit scalar can be split into several s-bit windowed scalar slices. Each window can take a value between 0 and 2^s-1. Through such cutting, the scalar multiplication operation that originally needs 256 times of doubling accumulation is converted into an aggregation operation centered on the "bucket". For example, when s = 16, the scalar is cut into 256 / 16 = 16 pieces, each of which takes a value between 0 and 65535. Although this approach can significantly reduce repeated addition operations, it also brings a surge in the number of buckets and storage. The present invention can handle such a large amount of data by relying on a complete set of three-dimensional Pippenger algorithms and bucket caching strategies.

[0043] Figure 2 The bucket accumulation process illustrated in the middle is to map the small windows obtained by splitting the scalar in the previous step to the corresponding buckets. For example, if the scalar value of a window is 37, then the elliptic curve point is added to the position of the bucket with serial number 37, and other window values are the same. The traditional design may sequentially traverse all the buckets, and waste clock cycles when encountering empty buckets; but in the present invention, we cooperate with the scalar preprocessing module to perform the advanced merge sorting and merge pointers of the scalar slices, ensuring that only those actually appearing bucket values are accessed, greatly reducing the pipeline bubbles caused by empty buckets. More cleverly, if some scalar values appear multiple times in the same window, then batch point addition can be directly performed during bucket accumulation. This step is very common in ZKP applications: many scalars may take the same value in the same window interval.

[0044] Figure 3 The left shows the bucket aggregation and result accumulation process. After completing the bucket accumulation, each bucket stores the accumulation result point of all scalar values in a certain window; then according to the basic principle of Pippenger algorithm, these buckets are first accumulated from the maximum value to the minimum value to form an accumulation amount, and finally the partial results of each window are superimposed according to the shift addition method (because each piece of window cutting is equivalent to performing a binary shift operation on the original scalar). On the surface, this seems to consume a lot of point addition operations, but in fact, compared with directly multiplying each scalar and then accumulating the results, a lot of redundant calculations have been saved. In the present invention, because the joint optimization of parallel channel number, window size and pre-computable scale has been performed through three-dimensional Pippenger, the bucket aggregation stage can remain highly efficient.

[0045] Combination Figure 5The scalar preprocessing module used in this invention can be explained in more detail. The basic function of scalar preprocessing is to read scalar slices from an external data source into the FPGA in batches, and then complete one or more pipelined merge sorting processes within the FPGA's programmable logic. When dozens or even hundreds of 16-bit scalar slices are pulled in, scalar preprocessing rearranges them in size order and merges scalar slices with the same value into the same pointer index. For example, if several scalar slices read in a batch have values ​​all equal to 1234, the system places these slices into the same pointer record and records how many slices have the value 1234. In this way, in the subsequent bucket accumulation stage, the elliptic curve points corresponding to these pointers can be added to bucket 1234 all at once, without needing to perform repeated empty reads or multiple writes.

[0046] The scalar preprocessing module itself can employ hierarchical pipelined merging: for example, merging 32 slices in the first-level pipeline, then merging several first-level results in the second-level pipeline to form 64 or 128 ordered slices, and then gradually expanding until the desired batch size is achieved. In the final stage of preprocessing, these sorted and value-merged pointers are written to a pointer cache. Figure 8 The input data cache module mentioned earlier may also partially perform this function, or it may be stored in a dedicated pointer cache (BRAM / URAM) to facilitate access by the computing array. When it is necessary to stop reading new scalar data, if the pointer cache space is about to run out, a stop signal can be sent to the upstream module to temporarily freeze the scalar input. The data can be retrieved again after the computing array has processed a portion of the data. This throttling mechanism can ensure the smooth operation of the pipeline.

[0047] Figure 6 The bucket cache module shown plays the role of intermediate computation storage in the overall scheme of this invention. The accumulated results of different window values ​​often need to be stored in the hardware in an intermediate state, and then read and merged in the next operation or the next round of accumulation. The bucket cache is essentially composed of several BRAM or URAM blocks, with each address location corresponding to a bucket. The bucket may temporarily store elliptic curve coordinate information such as (X, Y, Z, T), and the specific coordinate system—whether it's a distorted Edwards, Weierstrass, or Montgomery system—depends on the application requirements. Figure 2 During the bucket accumulation phase, the computation array needs to read a bucket address in clock cycle i, obtain the current accumulated value, add the new point, and write it back to that address. In traditional methods, this can cause conflicts between reading and writing to the same address, requiring blocking or pipeline interruption. However, in this invention, scalar preprocessing provides us with pointer prediction capabilities of "which buckets will be accessed in the next cycle." If a collision occurs, the write operation can be appropriately delayed or the bucket write operation can be scheduled to other idle channels, thus greatly reducing the probability of conflict.

[0048] Meanwhile, if the NAF (Non-Adjacent Form) scalar representation is adopted, the number of buckets will be halved from 2^s to 2^(s-1), which significantly reduces the URAM / BRAM usage. As 2^s = 65536 when s = 16, if NAF can reduce the effective bucket number by half, a large amount of on-chip resources can be saved. Although the present application does not require the user to use NAF, when dealing with super-large-scale zk-SNARK proof generation, this choice often brings better performance ratio.

[0049] Next, let's look at the calculation array diagram in Figure 7 The core idea here is to copy several parallel-running unified PADD units or PADD / PDBL units that can be used for point multiplication at the same time to process different window or scalar slices of different channels. In other words, if there are enough DSP and LUT resources on the FPGA, more rows and columns or more cores can be configured, and each core can perform several pipelined point addition operations. Since a large number of operations in multiple scalar multiplication can be performed concurrently (as long as there is no data conflict), the hardware parallelism can be maximized.

[0050] The reason why the unified PADD unit is called unified is that in elliptic curve operations, both point addition (PADD) and point doubling (PDBL) require coordinate addition and modulus multiplication operations, but only differ slightly in coefficients and constant terms. If they are divided into two circuit units, resources will be wasted repeatedly; if point addition and point doubling formulas can be combined in the same pipeline and switched between point doubling mode and point addition mode as needed, the large integer multiplier and adder-subtractor can be reused, greatly improving the computing power per unit area. The circuit structure of the unified PADD unit is described in detail in Figure 12 , which is often composed of difference paths, sum paths, and multiplexers, supplemented by two-stage pipelines (Stage 1 and Stage 2) to evenly divide the operation load and avoid the problem of too deep single-level logic that prevents frequency from being improved.

[0051] Figure 8The input data buffer module in the system data flow layer explains how to deploy a programmable buffer between the outermost DDR / HBM and the FPGA internal computing array. When batch loading of elliptic curve point data (whether 377-bit points such as BLS12-377 or BLS12-381, or other 256-bit or wider points) is required, the points can be written into the input buffer module in the AXI burst mode, and then read and calculated by the computing array and the bucket buffer. The buffer module can support multiple channels at the same time, because the Pippenger algorithm may require fast reading of a group of points for pre-computation, and another group of points for subsequent window accumulation. Combined with scalar pre-ordering, the module also interacts with the pointer information: if the pointer writes to address A to read a point, the point in address A can be scheduled to the unified point adder entrance in one clock cycle. On high-end FPGAs (such as Xilinx Alveo U250, U55C or Intel FPGA), if the BRAM+URAM resources are sufficient, the round trip between the external storage can be reduced.

[0052] Figure 9 and Figure 10 The operation flow of the unified point adder reading data from the bucket buffer and writing data to the bucket buffer is respectively explained. The former mainly shows how the point adder accurately locates the bucket address according to the pointer information, so as to obtain the intermediate result that has been accumulated or pre-calculated before; the latter explains that after the operation is completed, if the new point data needs to be written back to the bucket buffer, it needs to consult with the data flow scheduling module to confirm that there is no need to read the same bucket address in the next beat or several beats, otherwise it will be delayed or temporarily stored. Through such flexible scheduling, combined with the scalar preprocessing idea of the application, the probability of pipeline stall is greatly reduced.

[0053] Figure 11 The schematic diagram of the point addition calculation process of the application is given, from which a typical operation sequence can be seen: first, load coordinate X_1, Y_1, Z_1, T_1 information from the bucket buffer; at the same time, load another point X_2, Y_2, Z_2, T_2 from the input buffer or the same bucket buffer; then perform several modular multiplication, modular addition and modular subtraction operations in the unified point adder; and then output the new X_3, Y_3, Z_3, T_3 to write back to the bucket buffer. If this operation is in the bucket accumulation stage of the Pippenger algorithm, X_3, Y_3, Z_3, T_3 will be saved at the same address, indicating the latest accumulation of the bucket; if it is in the final result accumulation stage, it may be written to a special result register array for final integration. In summary, such pipelined operation requires a large number of registers for scheduling on hardware, otherwise it will cause resource idling or long path blocking due to data dependency. The application ensures that the operation unit is in a full load state in most clock cycles through two-stage pipelining and register multiplexing.

[0054] Figure 12 The circuit structure of the unified adder is explained in detail. Generally, it contains three or more parallel data paths, such as Path1 and Path2 for difference, Path3 and Path4 for sum, and finally integration at Stage2. The multiplication operation can be realized by replacing some constants or coefficients in the original formula, without introducing new addition and subtraction paths. In this way, the point addition and multiplication can reuse most of the resources in the same hardware, and only switch the mode in the control signal. Compared with the traditional scheme of completely separating the point adder and multiplier, this unified design reduces nearly half of the large integer multiplication times, and reduces the dependence on FIFO and pipeline depth, thereby creating space for frequency improvement.

[0055] In the aspect of large integer multiplier, Figure 13 The combination of the divide-and-conquer method and frequency multiplication technology is the key to realizing high throughput in the present application. Taking the Karatsuba algorithm as an example, if a 384-bit x 384-bit large integer multiplication is to be calculated, the classical divide-and-conquer method will divide 384-bit into several sub-blocks for multiple sub-multiplication and addition combination. The common method is to divide the input X into X0, X1 (each 192-bit), divide the input Y into Y0, Y1 (each 192-bit), and then divide the multiplication into X0Y0, X1Y1, and (X0+X1)(Y0+Y1)-X0Y0-X1Y1, etc. Through this divide-and-conquer method, the excessive occupation of LUT and register resources by large-scale multiplication is reduced.

[0056] However, even if Karatsuba is used, if the 192-bit or 128-bit sub-blocks are directly mapped to DSP48 for multiplication, it may still be a waste of bits. Therefore, the present application introduces the "asymmetric division" and "frequency multiplication" strategies: asymmetric division refers to the fact that when the last layer of sub-block division is performed, X1 / X2 is not divided into two equal parts, but is cut into three parts or other bit widths that are more suitable for the multiplication port of DSP48; the frequency multiplication strategy makes the internal DSP48E2 work at twice the frequency, so that it can complete two sub-multiplication operations in one external clock cycle. This is like doubling the computing power of a DSP, which reduces the total number of DSPs needed. After the multiplication gets the intermediate result, the internal accumulator of the DSP can still be used to combine the results, without having to use too many LUTs for carry processing. Through this series of designs, the throughput of a single large integer multiplier can be almost doubled or multiplied several times under the premise of constant hardware area and power consumption. For elliptic curve point addition with high bit width modular multiplication, this is a crucial optimization.

[0057] Further illustrate how to choose the compromise strategy of parallelism and frequency in actual hardware deployment. If the number of DSPs available in the FPGA is very large, such as thousands of DSP48E2, and more BRAM / URAM can be accommodated, then the number of parallel channels (c value) or the number of uniform adders in the calculation array can be set higher, while ensuring that each adder can work at 250MHz or 300MHz. In this way, more bucket accumulation operations can be performed concurrently, significantly shortening the overall MSM time. If the FPGA resources are limited or the clock frequency is expected to be pulled to 400MHz or above, the number of adders can be reduced moderately, the parallelism is reduced, and the operation of different windows is completed in sequence with the help of faster frequency, which can also achieve good throughput. The present application selects appropriate s, c, and m parameters through adaptive "three-dimensional Pippenger" at the algorithm level, and the hardware layer makes comprehensive considerations on the size of the multiplier and the depth of the pipeline according to the resources, so as to find a reasonable performance balance point under various constraint conditions.

[0058] In terms of application scenarios, if it is to process a 253-bit scalar such as BLS12-377, and the DSP48E2 of most FPGAs (such as Xilinx UltraScale+ series) is sufficient, the three-dimensional Pippenger of the present application can be configured as s=16, the number of channels c is determined according to the number of BRAM and the AXI bandwidth, and the precomputation size m is set to a larger value if resources permit. Once compiled, facing MSM tasks of millions to tens of millions of points, the proof generation can also be completed within a few seconds to tens of seconds, which is much better than the minutes or longer time of CPU level. From the practice of the industry, this acceleration effect is particularly critical for blockchain privacy transactions, Rollup and other schemes, which can greatly reduce network congestion and verification burden.

[0059] In order to strengthen the operability of the present application in the "specific embodiments", another combined example is given here: assuming that we implement the present application on a Xilinx Alveo U250 FPGA to accelerate the zk-SNARK generation under the BLS12-377 curve. First, query the resource situation: the U250 has about 1200 DSP48E2, about 1728 BRAM, about 960 URAM, and a certain number of LUT / FF. If the window size s is decided to be 16, then the total number of buckets is 2^16=65536, and if NAF representation is used, the number of buckets can be halved to 32768. Then, if the number of parallel channels c in the three-dimensional Pippenger is 8, it means that at least 8 accumulation units need to work together in one window processing. We will equip each of the 8 channels with one to multiple uniform adders (depending on the resource margin), and let the AXI bus and the scalar preprocessing module provide enough scalar pointer information to the 8 channels in each clock cycle.

[0060] In the scalar preprocessing, 256 or 512 16-bit scalar slices can be pulled to the FPGA each time, and the pointer information is output after the pipeline merge sorting. If a pointer record in the pointer cache records 30 scalar slices of the same value, then the calculation array can add points 30 times in bulk at the bucket address K, instead of repeated processing 30 times. After the bucket accumulation is completed, the system starts the bucket aggregation step to serially or in parallel merge the values from the high bucket to the low bucket; and after the final multi-window shift addition, the complete MSM result is obtained. In the experiment, this integrated design can complement the parallelism of the FPGA and the characteristics of the Pippenger algorithm, effectively use the DSP resources of U250 for large integer multiplication, and not stagnate in the bucket cache access due to data conflict.

[0061] In addition to large-scale scenarios, the application is also applicable in small and medium-sized scenarios. For example, some applications only need to process tens of thousands to hundreds of thousands of points, so s=12 or s=14 is enough, and the parallel channel can be reduced accordingly; or the FPGA itself is more resource-constrained, and can be reduced to s=10 or the like, thereby reducing the number of buckets. When s is small, the number of scalar slices will increase, and at this time, the size of the sorting pipeline of the scalar preprocessing needs to be strengthened to prevent it from becoming a bottleneck when reading and generating pointer indexes. Fortunately, the application is configurable for these parameters, and it can be migrated without having to make major changes to the hardware structure. Compared with the fixed design of GPU or ASIC, this flexibility makes the application have more extensive adaptability and portability.

[0062] In some aspects, if the user wants to further improve the efficiency of the algorithm, more aggressive coordinate system optimization for elliptic curves can be added inside the point adder, such as: using extended Edwards coordinates to reduce one-time modular multiplication, or switching to projective coordinates when doubling to reduce inverse element operation. Since the application has centralized the point addition and doubling into a unified circuit, such changes only need to make a small range switch in the constant term of Stage2 or Stage1, and will not damage the overall design structure. Of course, the final benefit needs to be seen in the specific curve formula and application size, and if the existing twisted Edwards coordinate implementation is good enough, it can also be kept unchanged.

[0063] If more levels of pre-computation are involved, such as caching some curve points multiplied by certain factors before the MSM, this idea is also compatible with the present invention. Because the three-dimensional Pippenger algorithm retains the adaptive dimension of the pre-computation scale m, if the user wants to store commonly used points (or their multiplied points) on the chip, it is equivalent to adding an additional preprocessing step before the bucket accumulation, calculating points ×2, ×4, ×8, etc. and writing them in a certain BRAM / URAM. When the bucket algorithm is executed, if a specific multiplied point is needed, it can be directly read without temporarily performing multiple multiplication operations. The limitation of this is whether the on-chip resources are sufficient, and how to avoid bandwidth competition with the bucket cache. The scalar preprocessing and data flow scheduling module of the present invention can be configured with priority: first ensure that the three-dimensional Pippenger main process does not stall, and then select the idle period to refresh the pre-computation table, so as to achieve the benefits of pre-computation and parallelism of the main process.

[0064] Similarly, if the upper protocol (such as zk-SNARK) requires multiple repeated calculations of some MSM of the same size, some bucket cache content can be retained after the calculation is completed, or the preprocessing pointer can be retained, saving time for the next round of calculation. The control module of the present invention can maintain a state machine on the hardware to record the current stage, window number and accumulation progress. As long as the pointer information is not reset, many repeated scalars of the next round of MSM can directly use the previous index. This will bring additional acceleration to batch proof tasks that are not completely random. Of course, if the scalar changes on a large scale or the curve point is no longer the same, the preprocessing sorting still needs to be done again, but the present invention still has the efficiency of pipelining.

[0065] When implementing the present invention, the physical limitations of hardware deployment also need to be considered, such as the power consumption limit of the FPGA development board, the heat dissipation design, and the clock hierarchy architecture. If the large integer multiplier is to realize DSP frequency multiplication, it means that the internal clock of DSP48E2 will run at 2 times the frequency, which usually needs to confirm that the timing can be closed and the voltage needs to be strictly matched. The official document of Xilinx gives the internal frequency of DSP48E2 that can work up to 600-700MHz, but this depends on the wiring and power quality, and actual experiments and asynchronous bridge techniques may be needed. When implementing the present invention, multiple clock domains are usually set in Vivado or other tools: an external clock of 300MHz and an internal DSP clock of 600MHz generated by a separate PLL or MMCM. If there are other communication modules working at a lower frequency, cross-clock domain processing needs to be performed at the AXI or scalar preprocessing module. Through multi-clock domain design, power consumption and speed can be balanced, and the global clock can be kept relatively stable while ensuring high frequency of core operation.

[0066] Besides the hardware debugging level, the software cooperation is also important. When calling the host program or upper layer driver of the application, the API or register mapping needs to be specified: the scalar quantity n of this MSM, the scalar width λ, the curve point address interval, the window size s, the parallel channel c, and the pre-computed size m, and other parameters. Then the scalar batch is written to the FPGA specified pre-processing input buffer, and the control module is notified to start loading, sorting, generating pointers, and finally starting the calculation array to execute the three-dimensional Pippenger. The application can expose a "start_MSM_accelerator" or similar interface in the operating system or blockchain node. The external only needs to provide the physical address or DMA handle of the scalar and point data. After the calculation is completed, the application will write the result point to the specified output address or return it through PCIe. In this way, a soft and hard integrated automated pipeline mode is formed, reducing the interrupt overhead and the burden of manual synchronization.

[0067] It should also be mentioned that the application is also compatible with distributed or multi-FPGA collaborative computing solutions. If some protocols require a larger n value (such as hundreds of millions of scales), a single FPGA may not be able to complete all calculations within a reasonable time. The scalar set and point set can be split into multiple FPGAs according to some division rules, and each piece performs the same or partially overlapping bucket accumulation phase, and finally the local results are merged together. At this time, an additional network interconnection or high-speed link (such as Aurora, PCIe Peer-to-Peer) is needed to synchronize the bucket aggregation progress of different FPGAs. Since the three-dimensional Pippenger algorithm naturally processes scalar windows in segments, some windows can be done in FPGA A, and others can be done in FPGA B, and finally the results can be added. Regardless of how the division is made, the adaptive parameters, scalar preprocessing mechanism, and unified PADD circuit of the application can all play the same acceleration role on each FPGA, and do not conflict with each other. In addition, if coupled at a higher level with the protocol, for example, by generating multiple sub-proofs in parallel, and then aggregating them into a root proof, it can also provide an idea for multi-FPGA parallelization.

[0068] Considering the actual needs on the blockchain, there may not only be random scalars, but also a high repetition rate, such as a large number of similar transaction data in some token transfer scenarios. The merge sort and pointer merging function of the application can greatly speed up the accumulation of scalars with the same value, avoiding the "one-size-fits-all" bucket address traversal. Such an effect has a high probability of occurring statistically, and after statistical analysis of real network load, it is found that many scalar distributions are not completely uniform, thereby bringing additional benefits to the application.

[0069] Regarding security, the hardware structure of the present application is mainly optimized for the calculation process, and does not destroy any security assumption required by zero-knowledge proof. The security of the elliptic curve depends on the difficulty of the discrete logarithm, and the present application only speeds up the point addition and doubling point on the hardware, without changing the security properties of the curve. If the upper protocol uses a specified hash function when sampling the scalar or generating the public key, the present application does not affect its correctness. At the same time, if you want to combine verifiable computing or anti-side channel analysis, you can also do random masking or double-track symmetric design at the adder and multiplier of the unified point adder, but this requires additional circuit complexity. In summary, the present application does not conflict with any curve security enhancement scheme, and only needs to be supplemented according to actual needs.

[0070] Further expandable directions include integration with the Number Theoretic Transform (NTT) accelerator to build a comprehensive circuit for zk-SNARK generation process. Because many zero-knowledge proof protocols need to perform NTT operations in addition to MSM (especially in polynomial commitment, FFT-based circuit compilation). The present application can share part of the DSP resources with those existing NTT acceleration IPs, switch to MSM or NTT when idle, or time-multiplex GPU / FPGA to accelerate MSM and NTT simultaneously in higher-level scheduling. How to integrate depends on the actual project's demand for throughput and module timing. If NTT and MSM do not occur simultaneously, DSP48 can be reused for different operations; if they often occur in parallel, independent arrays need to be reserved to ensure peak performance.

[0071] When adapting to various elliptic curves, the process of the present application is mostly the same, with the main difference being the modulus in large integer multiplication and the implementation of the coordinate formula by the point adder. BLS12-377 and BLS12-381 may need to handle 377-bit coordinates and 256 or 253-bit scalars; BN254 is 254-bit; Curve25519 can also use the Karatsuba and doubling strategy of the present application when ported to FPGA for MSM acceleration, but attention should be paid to operations such as Montgomery ladder. Users can choose to define a set of modulo operation IPs at compile time, and compile constants such as MOD=2^377-19 into the circuit, or make them into configurable registers for dynamic switching. In addition, the three-dimensional Pippenger parallelism and window size adaptation of the present application can easily meet the MSM needs of multiple types of elliptic curves.

[0072] From the perspective of running efficiency, no matter what curve, as long as the high-bit-width large integer operation takes a long time, the value of the present application will be highlighted. Because the throughput rate improvement brought by Karatsuba divide and conquer + DSP frequency multiplication is particularly obvious in the large bit width scene. If it is only a 160-bit curve, the traditional LUT level can also be done quite fast, but when it is above 256 bits, the efficient use of DSP48 becomes the top priority.

[0073] It can be foreseen that, as the demand for blockchain privacy, digital currency transaction volume, and various privacy ML scenarios gradually increase, zero-knowledge proof protocols will increasingly call MSM. If always relying on CPU or GPU, not only the speed is not ideal, but also the power consumption and hardware cost are very high. The FPGA scheme of the present application achieves a balance among computing power, flexibility and power consumption. Programmers also do not have to worry about hardware packaging or tape-out, because the reconfigurable nature of FPGA allows the project to switch to new algorithm parameters immediately after testing is completed, or to be compatible with new scenarios by making a small number of upgrades to the internal point adder. This rapid iteration feature is particularly valuable in the field of cryptography, because standards are updated from time to time, and curve selection may also change with demand.

[0074] The installation and deployment process of the present application is roughly as follows: first, prepare one or more FPGA servers at the hardware layer, configure power and cooling to ensure that DSP48 and LUT can run at full capacity; then integrate the scalar preprocessing module, input cache, bucket cache and control module of the three-dimensional Pippenger algorithm in the FPGA project; then write or transplant a piece of driver or SDK for the upper-layer blockchain node or application server. When the user needs to perform multiple scalar multiplication (such as generating a zk-SNARK proof), simply call the corresponding interface on the software side, pass the scalar data and curve points to the FPGA, and the corresponding AXI / PCIe channel will deliver the data to the pipeline of the present application, and complete a large number of point addition operations within tens of milliseconds to several seconds. If there are repeated operations, you do not have to load all the data every time, saving intermediate overhead. If you want to change the curve or modify the window size, you only need to update the control registers or project parameters, which is extremely flexible.

[0075] In the security audit or defense level, when the circuit of the application is reversed or vulnerability is mined, the possibility of scalar value leakage needs to be considered. Since the scalar preprocessing will perform merge sort inside the FPGA, if a malicious attacker can obtain the data flow information before and after sorting, the distribution characteristics of part of the scalar may be inferred. But most of the use scenarios run on a secure and trusted server, and the ZKP protocol is usually a public protocol and does not rely on the scalar itself as private data; the private key or confidential scalar that needs to be hidden usually only enters the FPGA after being confused locally. The application does not change the security of any protocol, nor does it introduce additional side channel protection arrangements. Users who have such needs can add random masking or differential power protection design around the large integer multiplier.

[0076] When extended to ASIC version, the unified point multiplier proposed by the application is also applicable to the adaptive idea of the three-dimensional Pippenger algorithm, except that the DSP frequency multiplication needs to be further verified for wiring and process limitations in chip design, and the Karatsuba divide-and-conquer also needs to be integrated into the special multiplication hard core. However, from the perspective of benefits, if the ASIC is only for a specific curve or a fixed window size, most of the configuration functions may be reduced, but part of the reconfigurability is lost. The application is still a very good ASIC design blueprint because it optimizes the algorithm, data flow and hardware structure as a whole, and can achieve a higher level of performance and area in subsequent tape-out.

[0077] When writing the specific embodiment code, the hardware description is generally performed according to the following logic: 1. In the top-level module, declare the interfaces of all BRAM / URAM, as well as the interconnection of the scalar preprocessing module, input cache, bucket cache, calculation array and control module; 2. In the scalar preprocessing module, implement a multi-stage pipelined sorting circuit to merge the input slices and write the pointer cache; 3. In the calculation array, implement a unified point multiplier, and each point multiplier is divided into Stage1 and Stage2, and embedded with a Karatsuba multiplier and a frequency multiplication DSP inside; 4. In the control module, write a state machine to manage the switching of window rounds, bucket aggregation stages and result accumulation stages; 5. In the read-write arbitration logic of the bucket cache, detect address conflicts and delay writing in combination with pointer information. After these are completed, adapt to AXI or PCIe, and a complete acceleration system can be formed. Figure 12

[0078] If external support for multiple curves is required, the moduli and generators of these curves may be different, and multiple sets of parameter lookup tables can be automatically generated at compile time, or can be made into register configurable. The scalar bit width can be universal large integer multiplier as long as it does not exceed the upper limit set by Karatsuba in the worst case. If the actual operation bit width is smaller than the maximum value, only part of the DSP input ends will be empty, but it will not affect the correctness. ​

[0079] From the performance point of view, the specific embodiments of the present application can bring the following quantitative indicators: 1 PADD throughput, that is, how many times the point addition or point multiplication operation can be performed per second; 2 time area product (ATP), measured by LUT or DSP as area, and measured by millisecond or second as time, reflecting whether more operations are performed under the same area; 3 energy consumption ratio, the amount of operations that can be completed under the same power consumption. Since three-dimensional Pippenger can greatly reduce repeated addition, scalar preprocessing can eliminate empty barrel reading, Karatsuba frequency multiplication can improve multiplication efficiency, and the three are superimposed together, the throughput can often be increased to several times or even dozens of times of the traditional FPGA scheme, and the resource occupation will not rise linearly, it is a high cost-effective hardware acceleration method.

[0080] Finally, mention the actual landing case: a blockchain project uses BLS12-377253bit scalar, performs MSM on millions of points for zk-SNARK generation, and is deployed on Xilinx Alveo U55C. After enabling three-dimensional Pippenger and scalar preprocessing of the present application, the single-card performance reaches more than several million points per second of accumulation speed, which is hundreds of times faster than the CPU scheme, and several times faster than the GPU scheme, and the power consumption is only about one hundred watts. This shows that the present application can obtain significant acceleration effect in actual production environment and help reduce the overall system cost.

[0081] In summary, the specific embodiments of the present application revolve around "adaptive three-dimensional Pippenger algorithm + scalar preprocessing and conflict-free scheduling + unified point adder and large integer multiplier depth optimization", forming a complete solution from algorithm to hardware to system level. According to the description of the present application, in the specific engineering implementation, the developer can gradually complete the stream merging of the scalar preprocessing module, the interconnection of the barrel cache and the calculation array, the two-stage stream of the unified point adder, and the Karatsuba frequency multiplication circuit, and then encapsulate the whole system into a reusable IP core combined with AXI bus or other host interface. In this way, whether it is used in the online acceleration scene of blockchain privacy transactions or in the verifiable inference of machine learning models, it can efficiently meet the massive demand of zero-knowledge proof protocol for multi-scalar multiplication with reconfigurable FPGA.

[0082] So far, we have fully described the application from the aspects of architecture design, data flow management, hardware optimization and extended application. The above implementation is not the only limit of the application. Without departing from the technical idea of the application, various improvements and deformations can be made to the large integer modular multiplication algorithm, NAF conversion method, frequency multiplication clock distribution and register reuse strategy. Any such improvement should be considered within the protection scope of the application. Through the above detailed description, it can be seen that the application injects a new idea for hardware acceleration of zero-knowledge proof multi-scalar multiplication. Not only can it achieve ideal throughput and flexibility on the FPGA platform, but also lays a solid foundation for subsequent ASIC implementation or multi-FPGA collaborative expansion. These elements cooperate with each other to accelerate the practical landing and wide application of zero-knowledge proof in privacy computing, block chain and more security sensitive fields.

[0083] The above is only the preferred embodiment of the application, but the protection scope of the application is not limited thereto. Any person skilled in the art can make equivalent replacements or changes within the technical scope disclosed by the application according to the technical solution and inventive concept of the application, which should be covered within the protection scope of the application.

Claims

1. A hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs, characterized in that, Includes the following steps: S1: Divide the original scalar data into scalar slices of fixed bit width, and merge and sort the batch of scalar slices in the FPGA; S2: Based on the sorted scalar slice values, generate a pointer index for each scalar slice, and merge scalar slices with the same value and store them in the pointer cache; S3: Use the multi-channel parallel Pippenger algorithm for pre-computation and bucket aggregation, and reduce redundant point addition PADD operations by adaptively selecting the window size and pre-computation scale. S4: At the data flow level, scalar pre-sorting and pointer index control are used to avoid conflicts between empty bucket reads and bucket writes. S5: Output the final result of the multi-scalar multiplication to the host or upper-layer protocol for further processing.

2. The hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 1, characterized in that, The multi-channel parallel Pippenger algorithm in step S3 includes: selecting a window size S that is adapted to hardware resources and memory limits, slicing scalars by bit width; allocating buckets to the scalar values ​​corresponding to each window, and accumulating elliptic curve points with the same scalar values ​​into the same bucket in parallel; performing a one-time aggregation on each bucket to obtain a partial result of each window slice; iteratively accumulating all partial results between windows to obtain the final multi-scalar multiplication output.

3. The hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 1, characterized in that, Step S4 establishes pointer indexes during the scalar pre-sorting stage, thereby accessing only the buckets with actual useful data when the PADD calculation unit reads the bucket address, avoiding empty bucket readings and reducing pipeline bubbles.

4. The hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 1, characterized in that, It also includes the following steps: During the execution of multi-scalar multiplication, the pointer cache and bucket cache occupancy rates are automatically detected. When the pointer cache is about to overflow, scalar reading is paused. When the bucket cache has insufficient writable space, existing results are prioritized for writing back and space is cleaned up to ensure the stability and continuity of the data stream.

5. An apparatus for applying the hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs as described in any one of claims 1-4, characterized in that, include: Scalar preprocessing module: used to read raw scalar data and perform scalar slicing, merge sorting, and pointer index generation; Input buffer: Communicates with external storage or the host machine to buffer elliptic curve point data; Bucket caching: Used to store and accumulate intermediate results of multi-channel parallel Pippenger algorithm; bucket caching is built using on-chip URAM or BRAM resources, and the number of buckets is determined by the window size. If combined with the Non-AdjacentForm scalar representation, the number of buckets can be halved, saving storage overhead; The computation array consists of unified points plus PADD cells, which read and accumulate point data in the corresponding bucket according to pointer index instructions; Control module: Used to adaptively select window size and pre-computation scale according to FPGA resource constraints during runtime, and coordinate data flow between scalar preprocessing module, input buffer, bucket buffer and computing array.

6. The apparatus for a hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 5, characterized in that, The unified PADD unit within the computing array performs point addition and doubling in the distorted Edwards coordinate system, and splits long path operations into a two-stage pipeline structure, with each stage having approximately equal computational paths, thereby avoiding additional FIFO buffering and register overhead caused by data dependencies.

7. The apparatus for a hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 5, characterized in that, The large integer multiplier in the unified PADD unit adopts the Karatsuba divide-and-conquer algorithm and utilizes the DSP frequency multiplication strategy to improve the utilization rate of the DSP in multiplication with limited bit width, thereby doubling the computing power under fixed DSP resources.

8. The apparatus for a hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 5, characterized in that, It also includes the following devices: Pointer cache: Used to store EC point pointer information corresponding to the same scalar value; Data flow scheduling module: Based on the address instructions provided by the pointer cache, it sends accurate bucket addresses or input cache address instructions to the computing array, thereby avoiding write conflicts and empty bucket reads.

9. The apparatus for a hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 5, characterized in that, The scalar preprocessing module employs a pipelined structure for merge sort, processing scalar slices in parallel each time. After the merge sort is completed, the pointers corresponding to scalar slices with the same value are merged and output to the pointer buffer.

10. The apparatus for a hardware acceleration method for multi-scalar multiplication oriented towards zero-knowledge proofs according to claim 5, characterized in that, The control module automatically adjusts the number of parallel channels and the pre-computation point size according to the specific resource conditions of the FPGA, finding a balance between throughput and hardware overhead.

Images