A front-end hardware acceleration system, program proof hardware acceleration system and method

Abstract

This invention discloses a front-end hardware acceleration system, a program proof hardware acceleration system, and a method. Addressing the problem that existing zero-knowledge virtual machine front-ends still heavily rely on software implementation, this invention proposes a dedicated heterogeneous hardware architecture for front-end execution, main trajectory generation, and auxiliary trajectory generation. This significantly reduces front-end bottlenecks. Furthermore, the main trajectory unit, trajectory buffer unit, and auxiliary trajectory unit work collaboratively, forming a unified on-chip processing link for program execution, main trajectory generation, and auxiliary trajectory generation. On-chip collaborative processing of the main and auxiliary trajectories involves direct on-chip data transfer through the trajectory buffer unit, avoiding the need to read all main trajectories back from main memory and reducing the round-trip overhead of "main trajectory in main memory—software read back—regeneration of auxiliary trajectories." Based on the front-end hardware acceleration system, further through units such as trajectory shaping, polynomial processing, constraint combination, commitment generation, low-degree testing, query initiation, and proof encapsulation, the front-end output is directly extended to the back-end proof construction, reducing stage boundary overhead and forming an integrated end-to-end hardware processing architecture from "program execution - trajectory generation - commitment construction - low-degree testing - query initiation - proof encapsulation". Moreover, through the trajectory shaping unit, the front-end output can be directly connected to the back-end proof construction, reducing additional data format conversion overhead.

Description

Technical Field

[0001] This invention relates to a front-end hardware acceleration system, a program-based hardware acceleration system and method, and belongs to the field of hardware acceleration. Background Technology

[0002] Existing zero-knowledge virtual machines (zkVM, a virtual machine system that can convert general program execution processes into verifiable execution trajectories and further generate zero-knowledge proofs) typically divide the overall proof process into two interconnected but relatively separate stages: the front-end execution and witness generation stage (referred to as the "front-end stage") and the proof back-end stage (referred to as the "back-end stage"). The front-end stage is usually responsible for program interpretation or virtual machine execution, forming the main trajectory and some auxiliary trajectories; the back-end stage, based on the trajectory data, completes constraint construction, commitment generation, random challenge generation, low-degree testing, query initiation, and final proof encapsulation.

[0003] In existing technical solutions, the backend stage accounts for a larger proportion of computation, and operations such as NTT, MSM, hashing, and Merkle commitments in the backend are characterized by strong regularity, high parallelism, and fixed computation patterns, making them more suitable for hardware acceleration. Therefore, most existing hardware acceleration solutions prioritize the backend stage, while the frontend stage is handled by software. However, with the hardware acceleration of backend proof computation, according to Amdahl's Law, the previously small frontend overhead will be significantly amplified, gradually becoming a new end-to-end performance bottleneck. Furthermore, in the software process, the main trajectory is usually written to main memory first and then read back from main memory to generate auxiliary trajectories, resulting in significant data transfer and bandwidth overhead. Summary of the Invention

[0004] This invention provides a front-end hardware acceleration system, a program verification hardware acceleration system and method, which solves the problems disclosed in the background art.

[0005] According to one aspect of this application, a front-end hardware acceleration system is provided, comprising: According to one aspect of this application, a front-end hardware acceleration system is provided, comprising: The main trajectory unit is used to execute the program to be proven according to the program entry address written on the host side, collect execution status information during execution, generate the main trajectory based on the execution status information, and send the main trajectory to the external main memory and trajectory buffer unit. The auxiliary trajectory unit is used to read the main trajectory from the trajectory buffer unit and generate an auxiliary trajectory based on the main trajectory.

[0006] Furthermore, the main trajectory unit includes an execution unit and a data acquisition unit that is configured in bypass order with the execution unit; The execution unit is used to execute the program to be proven. The acquisition unit collects execution status information during execution, generates the main trajectory based on the execution status information, and sends the main trajectory to the external main memory and trajectory buffer unit.

[0007] Furthermore, multiple auxiliary trajectory units are provided, and these multiple auxiliary trajectory units are connected in parallel.

[0008] According to another aspect of this application, a front-end execution method is provided, which employs a front-end hardware acceleration system for execution.

[0009] Furthermore, execution status information is collected during execution, and a main trajectory is generated based on the execution status information, including: The collection range is controlled by a preset collection range control character, and the execution status information is collected within the controlled collection range; The collected execution status information is sequentially reduced by modulo, unified in word width, concatenated in fields, and packaged to generate the main trajectory.

[0010] Furthermore, the main trajectory is a line-shaped trajectory; Auxiliary trajectories are generated based on the main trajectory, including: Traverse the rows of data in the main trajectory, and generate the permutation denominator for each row based on the row data and the random challenge value; the formula for generating the permutation denominator is: D i =γ+∑(β j ×A ij ), D i Let A be the denominator term for the permutation of the data in the i-th row. ij For the j-th data in the i-th row, γ and β are both random challenge values. The results of calculating different powers of β are pre-stored in a lookup table. j Obtained by looking up the table; Based on the permutation of the denominator terms, generate the inverse column corresponding to each row of permutation of the denominator terms, and generate the auxiliary trajectory based on the inverse column. According to another aspect of this application, a program-provided hardware acceleration system is provided, comprising: Front-end hardware acceleration system; The trajectory shaping unit is used to shape the trajectory to adapt it to the backend processing; the trajectory includes the main trajectory and the auxiliary trajectory. The polynomial processing unit is used to perform polynomial processing on the shaped trajectory. Commitment unit, used to generate commitment roots from the evaluation results of the shaped trajectory and the extended domain generated by polynomial processing; Constraint combination unit, used to generate combined constraints based on the trajectory polynomial generated by polynomial processing and random challenge values; Low-degree test cells are used to perform low-degree tests on combined constraints. The query activation unit is used to extract query activation data from the commitment root based on the query position when the preset conditions are met in the low-degree test round. The proof encapsulation unit is used to encapsulate the outputs of the trajectory shaping unit, polynomial processing unit, commitment unit, constraint combination unit, low-degree testing unit, and query initiation unit into the final proof. The direct memory access unit is used to write the final proof into external main memory.

[0011] Furthermore, the program demonstrates that the hardware acceleration system also includes: The random number generator is used to generate random challenge values ​​and query locations; The status register unit is used to register information written by the host side; after receiving a preset instruction from the host side, it updates the status bit and triggers an interrupt. A shared finite field operation unit is used to store algorithms used by other units, allowing other units to schedule algorithms.

[0012] Furthermore, the commitment unit is also used to generate a program digest for the program to be proven when the program to be proven is loaded; to perform authentication path reconstruction hashing during the query initiation phase; and to generate a final proof digest for the final proof during the proof encapsulation phase.

[0013] According to another aspect of this application, a method for proving a program is provided, characterized in that a program is used to prove the execution of a hardware-accelerated system.

[0014] The beneficial effects achieved by this invention are as follows: Addressing the problem that existing zero-knowledge virtual machine front-ends still rely on software implementation, this invention proposes a dedicated heterogeneous hardware architecture for front-end execution, main trajectory generation, and auxiliary trajectory generation. This significantly reduces front-end bottlenecks. Furthermore, the main trajectory unit, trajectory buffer unit, and auxiliary trajectory unit work collaboratively, forming a unified on-chip processing link for program execution, main trajectory generation, and auxiliary trajectory generation. On-chip collaborative processing of the main trajectory and auxiliary trajectory is achieved through direct on-chip data transfer via the trajectory buffer unit, avoiding the need to read all main trajectories back from main memory and reducing the round-trip overhead of "main trajectory in main memory—software read back—regeneration of auxiliary trajectory". Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the front-end hardware acceleration system. Figure 2 A flowchart for the front-end execution method; Figure 3 A schematic diagram illustrating the structure of the hardware acceleration system for program demonstration; Figure 4 This is a flowchart of the program's proof method. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this application or its application or use. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0017] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0018] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

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

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

[0021] It should be noted that similar symbols and letters in the accompanying drawings represent similar items; therefore, once an item is defined in one accompanying drawing, it does not need to be discussed further in subsequent accompanying drawings.

[0022] See Figure 1 , Figure 1 This is a schematic diagram of the structure of a front-end hardware acceleration system provided in an embodiment of this application. The hardware acceleration system can independently complete the acceleration of front-end execution and trajectory generation. The hardware acceleration system mainly includes a main trajectory unit, a trajectory buffer unit and an auxiliary trajectory unit. The main trajectory unit is connected to the auxiliary trajectory unit through the trajectory buffer unit.

[0023] The main trajectory unit is used to execute the program to be proven according to the program entry address written on the host side, collect execution status information during execution, generate the main trajectory based on the execution status information, and send the main trajectory to the external main memory and trajectory buffer unit.

[0024] It should be noted that the main trajectory unit is not limited to a specific processor architecture; any processor capable of performing the aforementioned functions can be used. Figure 1The main trace unit in the code is called the Main Trace Unit (MTU). To improve front-end processing efficiency, the MTU can specifically include an execution unit and a data acquisition unit that is connected in bypass to the execution unit. The execution unit is used to execute the program to be proven. The data acquisition unit is used to collect execution status information during execution, generate the main trace based on the execution status information, and send the main trace to the external main memory and the trace buffer unit. The main trace is trace data directly generated by the program execution semantics and is used to record the core state of program execution.

[0025] Figure 1 The execution unit is a RISC-V Core, a processor core designed based on the RISC-V instruction set architecture. It is a deterministic execution core, which can reduce uncontrollable execution divergences and facilitate the synchronous acquisition of execution status information. It is responsible for executing the program to be proven, that is, the process of simulating or actually running instruction cycles, and generating execution status information such as instruction execution status, register status, memory access status, and bus status.

[0026] The RISC-V Core connects to external main memory sequentially via the IMEM AXI bridge and IMEM, and sequentially via the DMEMAXI bridge and DMEM. This connection is primarily used for loading instructions and data from the program to be proven. The host computer first loads the program code segment and the instruction data corresponding to the program entry address into the external main memory. After the task starts, the RISC-V Core reads instructions from the external main memory based on the program entry address configured on the host side. This path mainly involves the exchange of program instruction streams, code segment data, and necessary read-only constant data; it is not a write-back path for the main or auxiliary traces.

[0027] Figure 1 The acquisition unit is called the Trace Collection Unit (TCU). The TCU is not connected in series in the main execution pipeline of the RISC-V Core. Instead, it is connected as a side-channel acquisition / monitoring module next to the execution path. The RISC-V Core continues to execute the program to be proven according to the original pipeline. The TCU synchronously reads fields (i.e., execution status information) such as program counter, operands, results, memory access addresses, memory access data, read / write flags, clock step numbers, and bus tags from the execution stage, memory access stage, commit stage, or bus path through bypass signal lines or monitoring interfaces. It then performs field filtering, modulo reduction, word width unification, and packaging to generate the main trace. Modulo reduction is the process of mapping integers to the target finite field. The TCU adopts a non-intrusive acquisition mechanism, only copying or monitoring key signals during execution. It is not a necessary computational stage for processor instruction execution and does not change the program execution semantics. It completes the main trace construction without significantly blocking the main execution flow, thus improving front-end processing efficiency.

[0028] The TCU connects to the external main memory via the TMEM AXI bridge and TMEM in sequence to send the generated master trajectory to the main memory.

[0029] It should be noted that the method of collecting execution status information is not limited to bypass collection. Bus listening, commit-level listening, memory access-level listening, or other collection structures that do not significantly affect the main execution flow can also be used.

[0030] The trajectory buffer unit is responsible for caching intermediate results from the main trajectory and auxiliary trajectories, and supports streaming data transmission. Figure 1 The intermediate trace buffer unit is called Trace Buffer, or TB for short.

[0031] It should be noted that TB can be implemented using FIFO, on-chip SRAM, multi-level cache, or other structures capable of data transfer.

[0032] The auxiliary trajectory unit is used to read the main trajectory from the trajectory buffer unit and generate auxiliary trajectories based on the main trajectory. Specifically, it can generate auxiliary trajectories such as permutation trajectory, lookup trajectory, range check trajectory, memory access consistency trajectory, and send / receive consistency trajectory based on the main trajectory data. Among them, the auxiliary trajectory is a data column or auxiliary table that is further constructed to satisfy the proof constraints such as permutation consistency, lookup consistency, range constraint, memory access consistency, and send / receive consistency.

[0033] Figure 1 The auxiliary trajectory unit is an Auxiliary Trace Unit. In order to improve the efficiency of auxiliary trajectory generation, in some embodiments, multiple auxiliary trajectory units are set up, and multiple auxiliary trajectory units are connected in parallel to generate auxiliary trajectories in parallel, so as to improve the throughput of auxiliary trajectory generation. Among them, multiple auxiliary trajectory units can generate different types of auxiliary trajectories respectively, or they can work together to generate different blocks of data, different columns of data or different task data of the same type of auxiliary trajectory.

[0034] To address the issue that existing zero-knowledge virtual machine front-ends still heavily rely on software implementation, the aforementioned front-end hardware acceleration system proposes a dedicated heterogeneous hardware architecture for front-end execution, main trajectory generation, and auxiliary trajectory generation. This architecture significantly reduces front-end bottlenecks. Furthermore, the main trajectory unit, trajectory buffer unit, and auxiliary trajectory unit work together to form a unified on-chip processing link for program execution, main trajectory generation, and auxiliary trajectory generation. On-chip collaborative processing of the main trajectory and auxiliary trajectory is achieved through direct on-chip data transfer via the trajectory buffer unit, avoiding the need to read all main trajectories back from main memory and reducing the round-trip overhead of "main trajectory to main memory - software read back - regeneration of auxiliary trajectory".

[0035] See Figure 2 , Figure 2 This is a flowchart of a front-end execution method provided in an embodiment of this application. The front-end execution method can be executed using the aforementioned front-end hardware acceleration system. The front-end hardware acceleration system and the back-end hardware system constitute the device side. The device side and the host side cooperate to realize program verification. The host side is responsible for receiving the program to be verified, public input, private input, parameter configuration, and completing storage space allocation, task initiation, and result collection.

[0036] The front-end execution method can include at least: Step 1: Execute the program to be proven according to the program entry address written on the host side, collect execution status information during execution, generate the main trajectory based on the execution status information, and send the main trajectory to the external main memory and trajectory buffer unit.

[0037] It should be noted that the host side will write the program entry address, and the MTU can start executing the program to be proven based on the program entry address. In some embodiments, the process of collecting execution status information and generating the main trajectory based on the execution status information may include: 11) Use a preset acquisition range control character to control the acquisition range during the execution process, and acquire execution status information within the controlled acquisition range.

[0038] The TCU collects fields such as program counter, instruction type, operand, execution result, memory access address, memory access data, read / write flag, clock step number, and bus tag from the MTU's execution pipeline, commit path, memory access path, or bus path.

[0039] To avoid redundant recording of irrelevant code segments, boot code segments, or non-critical execution sections, the acquisition range can be limited by control words, special instructions, register states, compiler instrumentation marks, or microcode commands (i.e., acquisition range controllers). For example, control semantics such as "start acquisition", "pause acquisition", "resume acquisition", and "stop acquisition" can be set to reduce the length of the main trajectory and the subsequent proof load, thereby improving processing efficiency.

[0040] By limiting the acquisition range, trajectories can be generated only for the target code range, reducing redundant storage and bandwidth consumption caused by irrelevant trajectories.

[0041] 12) The collected execution status information is sequentially reduced by modulo, unified in word width, concatenated in fields, and packaged to generate the main trajectory.

[0042] It should be noted that the generated main trajectory line is processed through two paths: the first path writes back to main memory to save the complete main trajectory result for debugging, offline verification, or independent front-end processes; the second path directly enters the on-chip trajectory buffer, i.e., the trajectory buffer unit, for the auxiliary trajectory unit to read directly. This dual-path structure avoids the need to read the entire main trajectory back from main memory.

[0043] Step 2: Read the main trajectory from the trajectory buffer unit and generate an auxiliary trajectory based on the main trajectory.

[0044] It should be noted that the ATU reads the main trajectory from the trajectory buffer unit and generates an auxiliary trajectory corresponding to the proof constraints. In some embodiments, the specific generation process may be as follows: 21) Traverse the row data of the main trajectory, and generate the permutation denominator term corresponding to the row data based on the row data and the random challenge value.

[0045] Taking the data in the i-th row as an example, the formula for generating the denominator by substitution can be: D i =γ+∑(β j ×A ij ); In the formula, D i Let A be the denominator term for the permutation of the data in the i-th row. ij Let j be the j-th data in the i-th row, where γ and β are both random challenge values.

[0046] To reduce computational complexity, the results of calculating different powers of β are pre-stored in a lookup table. j The β can be obtained by looking up a table. This means that different powers of β can be pre-calculated, and the pre-calculated results can be stored in a lookup table. When calculating each row, β can then be directly obtained by looking up the table. j Use directly.

[0047] 22) Based on the permutation of the denominator, generate the inverse column corresponding to each row of permutation of the denominator, and generate the auxiliary trajectory based on the inverse column; wherein, the auxiliary trajectory includes the inverse column and its cumulative column.

[0048] After obtaining a set of permutation denominator terms, it is necessary to further obtain their inverses in order to construct the core column in the permutation trajectory. Here, the batch modular inversion method is preferred, that is, first calculate the prefix product of the entire set of data, then perform an inversion, and then use the back-pushing method to recover the inverse of each permutation denominator term, thereby reducing the number of independent modular inversion operations.

[0049] Let P be the inverse element corresponding to the i-th row. i Then we have: P i =1 / D i ; To meet the cross-table consistency construction requirements, a corresponding cumulative column can be generated based on the inverse column. The cumulative column can be represented as: S i = S (i-1) + P i ; In the formula, S i S is the accumulated value of the i-th row. (i-1) P is the accumulated value of the first i-1 rows. i This is the inverse term of the i-th row. This process can be implemented using a parallel prefix addition structure or a pipelined accumulation structure.

[0050] Specialized methods such as modular multiplication and accumulation, batch modular inversion, prefix product, and prefix accumulation are used to improve the efficiency of auxiliary trajectory generation.

[0051] See Figure 3 , Figure 3 This is a schematic diagram of a hardware acceleration system for program proof provided in an embodiment of this application. This hardware acceleration system can independently complete front-end execution and trajectory generation acceleration, as well as back-end processing based on the trajectory. The hardware acceleration system mainly includes the aforementioned front-end hardware acceleration system, trajectory shaping unit, polynomial processing unit, commitment unit, constraint combination unit, low-degree testing unit, query activation unit, proof encapsulation unit, and direct memory access unit. Specifically, the input of the polynomial processing unit is connected to the output of the auxiliary trajectory unit through the trajectory shaping unit; the output of the polynomial processing unit is connected to the input of the commitment unit and the input of the proof encapsulation unit; the output of the commitment unit is connected to the input of the constraint combination unit and the input of the proof encapsulation unit; the output of the constraint combination unit is connected to the input of the low-degree testing unit and the input of the proof encapsulation unit; the output of the low-degree testing unit is connected to the input of the query activation unit and the input of the proof encapsulation unit; the output of the query activation unit is connected to the input of the proof encapsulation unit; and the output of the encapsulation unit is connected to the input of the direct memory access unit.

[0052] The trajectory shaping unit is used to shape the trajectory to adapt it to backend processing; the trajectory includes the main trajectory and the auxiliary trajectory.

[0053] It should be noted that, Figure 3 The trajectory shaping unit in the system is the TSU (Trace Shaping Unit), which is mainly responsible for rearranging, transposing, dividing, and columnarizing the row-based trajectory data generated by the front end to adapt it to the data organization format of the back-end proof processing.

[0054] The polynomial processing unit is used to perform polynomial processing on the shaped trajectory.

[0055] It should be noted that, Figure 3The polynomial processing unit in the system is the PGU (Polynomial Generation Unit), which is mainly responsible for performing interpolation, low-degree expansion, evaluation vector generation, and quotient polynomial or combinatorial polynomial generation on the trajectory sequence. Among them, low-degree expansion is the process of evaluating the trajectory polynomial over a larger evaluation domain for use in commitment and low-degree testing.

[0056] The commitment unit is used to generate commitment roots from the evaluation results of the shaped trajectory and the extended domain generated by polynomial processing.

[0057] It should be noted that, Figure 3 The commitment unit in the code is the Hash Commitment Unit (HCU), which performs leaf node hashing and Merkle tree internal node reduction on the shaped trajectory and the extended domain evaluation result generated by polynomial processing to generate the corresponding commitment root. In some embodiments, the commitment unit is also used to generate a program digest for the program to be proven when the program is loaded; to perform authentication path reconstruction hashing during the query initiation phase; and to generate a final proof digest for the final proof during the proof encapsulation phase. This avoids the duplication of configuring multiple sets of hash hardware.

[0058] Constraint combination unit, used to generate combined constraints based on the trajectory polynomial generated by polynomial processing and random challenge values.

[0059] It should be noted that, Figure 3 The constraint composition unit in the system is the CCU (Constraint Composition Unit), which is mainly responsible for mixing boundary constraints, transition constraints, permutation constraints, search constraints, and memory access consistency constraints based on random challenge values; where random challenge values ​​are random numbers or pseudo-random numbers.

[0060] Low-degree test cells are used to perform low-degree tests on combined constraints.

[0061] It should be noted that, Figure 3 The low-degree test unit in the system is the LTU (Low-degree Test Unit), which is mainly responsible for executing the low-degree test process, including folding, round submission, and round data management.

[0062] The query activation unit is used to extract query activation data from the commitment root based on the query position when the preset conditions are met in the low-degree test round.

[0063] It should be noted that, Figure 3 The query opening unit in the system is QOU (Query Opening Unit), which is mainly responsible for reading leaf nodes, sibling nodes and necessary intermediate results according to the query position to form query values ​​and authentication paths, so that the verifier can verify the consistency of the commitment.

[0064] The proof encapsulation unit is used to encapsulate the outputs of the trajectory shaping unit, polynomial processing unit, commitment unit, constraint combination unit, low-degree testing unit, and query initiation unit into the final proof.

[0065] It should be noted that, Figure 3 The proof encapsulation unit in the code is the PFU (Proof Formation Unit), which is mainly responsible for packaging the integer trajectory, polynomial processing result, commitment root, query value, authentication path, final round data and other necessary auxiliary fields into the final proof.

[0066] The direct memory access unit is used to write the final proof into external main memory.

[0067] It should be noted that, Figure 3 The Direct Memory Access Unit (DMA) in the chip is mainly responsible for efficiently moving the final proof between the chip and main memory. Of course, it can also move intermediate results such as intermediate polynomials and commitment tree nodes as needed.

[0068] In some embodiments, to achieve integrated front-end and back-end control and scheduling, the above-described hardware acceleration system further includes a random number generation unit, a state register unit, and a shared finite field arithmetic unit; wherein, the random number generation unit is used to generate random challenge values ​​and query positions, i.e. Figure 3 The True Random Number Generator (TRNG) in the system can, of course, be handled by the host processor, an external security module, or an upper-layer authentication system; the status register unit is used to store information written by the host side; upon receiving a preset instruction from the host side (such as the trace_on instruction), it updates the status bits and triggers an interrupt (i.e., a device-side task interrupt), that is... Figure 3The Control and Status Register (CSR) is used in the system. A unified CSR, unified buffer, and unified state machine reduce stage switching overhead. A shared finite field arithmetic unit (not shown in the diagram) serves as a common computing resource in the program proof hardware acceleration system. It stores algorithms used by other units for algorithm scheduling. Specifically, it connects to the ATU, PGU, CCU, and LTU via scheduling or arbitration interfaces, providing unified finite field computation capabilities such as modular addition, modular subtraction, modular multiplication, modular reduction, modular inverse, batch modular inverse, modular multiplication and accumulation, prefix product, prefix accumulation, NTT / iNTT, Butterfly operations, and low-degree test folding operations. For example, the ATU calls the shared finite field arithmetic unit algorithm to complete the calculation of the permutation denominator, batch modular inverse, generation of inverse columns and accumulation columns; the PGU calls the shared finite field arithmetic unit algorithm to complete interpolation, low-degree expansion, NTT / iNTT and Butterfly operations; the CCU calls the shared finite field arithmetic unit algorithm to perform modular multiplication and accumulation and finite field weighted combination of various constraint terms according to random challenge values; and the LTU calls the shared finite field arithmetic unit algorithm to complete the calculation of each round of folding. By using the shared finite field arithmetic unit, it is possible to avoid repeatedly configuring complete finite field arithmetic hardware in multiple units, thereby improving the on-chip resource reuse rate and overall computing throughput.

[0069] The aforementioned program proof hardware acceleration system, based on the front-end hardware acceleration system, further extends the front-end output directly to the back-end proof construction through units such as trajectory shaping, polynomial processing, constraint combination, commitment generation, low-degree testing, query initiation, and proof encapsulation. This reduces stage boundary overhead and forms an integrated end-to-end hardware processing architecture from "program execution—trajectory generation—commitment construction—low-degree testing—query initiation—proof encapsulation". Furthermore, the trajectory shaping unit enables the front-end output to directly connect to the back-end proof construction, reducing additional data format conversion overhead.

[0070] See Figure 4 , Figure 4This is a flowchart of a program proof method provided in an embodiment of this application. The program proof method can be executed using the aforementioned program proof hardware acceleration system. The program proof hardware acceleration system constitutes the device side, and the device side and the host side cooperate to realize program proof. Among them, the host side is responsible for receiving the program to be proven, public input, private input, parameter configuration, and completing storage space allocation, task initiation, and result collection. Specifically, it receives the program to be proven, public input, private input, or witness input; allocates storage space for the main trajectory, auxiliary trajectory, intermediate polynomial, commitment tree node, and final proof data; configures running parameters such as finite field parameters, trajectory length parameters, expansion ratio parameters, number of query rounds, hash mode, buffer size, and task granularity; writes the program entry address, input address, output address, and control parameters into the CSR; starts the device side task; and collects the main trajectory, auxiliary trajectory, or final proof result after the task is completed.

[0071] Procedural proof methods can include at least: 1) Generate the trajectory according to the above front-end execution method.

[0072] It should be noted that initially, the host side will obtain the program to be proven, the program entry address, the data storage area address, the main trajectory output address, the auxiliary trajectory output address, the trajectory table configuration parameters, the target finite field parameters, and the task control parameters, and write this information into the CSR. After the configuration is completed, the host side issues a start command, and the MTU will start executing the program to be proven according to the program entry address.

[0073] 2) Shape the trajectory output by the front-end execution method.

[0074] TSU receives the main and auxiliary trajectories generated by the front end and performs rearrangement, block division, transposition, and columnization on them, transforming them from a "row-based organization" more suitable for the execution phase to a "column-based or block-based organization" more suitable for the proof backend processing. Here, it is mainly processed into a column-based structure.

[0075] 3) Perform polynomial processing on the shaped trajectory.

[0076] PGU performs polynomial processing on each trajectory series. Specifically, it first recovers the corresponding trajectory polynomial based on the trajectory series data, and then evaluates it on the extended domain to form the evaluation vector required for subsequent commitments.

[0077] If a trajectory sequence corresponds to a polynomial f(x), then its extended domain evaluation result can be expressed as: E k =f(ω k ); Where ω is the primitive root on the extended evaluation domain, k=0,2,…,(n×b-1), n ​​is the original trajectory length, b is the low-degree expansion factor, k is the index of the sampling point in the extended domain, and E k This is the evaluation value at the k-th sampling point in the extended domain.

[0078] It should be noted that the PGU can perform NTT, iNTT, Butterfly operations, modular multiplication and accumulation, and address scheduling through finite field arithmetic circuits or other equivalent hardware structures.

[0079] The implementation of finite field correlation operations is not limited to a certain algorithm or hardware structure. Modular reduction, modular multiplication, modular inversion, interpolation, and low-degree extension can all be implemented using other equivalent methods. By providing hardware support for finite field correlation calculations, the efficiency of auxiliary trajectory generation and back-end proof processing can be improved.

[0080] 4) Generate commitment roots from the evaluation results of the extended domain generated by the reshaped trajectory and polynomial processing.

[0081] HCU generates commitment roots based on the evaluation results of the main trajectory series, auxiliary trajectory series, or their extended domains. Preferably, leaf hashing is performed on the leaf nodes first, followed by layer-by-layer reduction on the internal nodes, and finally the commitment roots are output.

[0082] Specifically, the HCU receives the data to be committed, packages one or more finite field elements into leaf node data according to a preset format, performs leaf hashing on the leaf node data to generate leaf node hash values, and then concatenates the hash values ​​of adjacent nodes layer by layer according to the Merkle tree structure and performs internal node hashing until the root node hash value is obtained. The root node hash value is the commitment root of the corresponding data.

[0083] HCU is not limited to a single hash algorithm and can use Poseidon, Rescue, Keccak, BLAKE3, or other equivalent hash structures.

[0084] 5) Generate combined constraints based on the trajectory polynomial generated by polynomial processing and the random challenge value.

[0085] CCU generates combined constraints based on the main trajectory polynomial, auxiliary trajectory polynomial, and random challenge value. The purpose of this step is to unify and compress multiple boundary constraints, transition constraints, permutation constraints, lookup constraints, and memory access consistency constraints into a smaller number of objects, facilitating subsequent low-intensity testing and querying.

[0086] 6) Perform low-degree testing on the combined constraints.

[0087] LTU performs low-degree testing on composite constraints, specifically using a folded low-degree testing process. If the object to be tested in the r-th round is split into two parts L...(r,0) and L (r,1) Then the folding result L in the (r+1)th round (r+1) It can be represented as: L (r+1) = L (r,0) +ρ r L (r,1) ; In the formula, ρ r Let r be the random challenge value for the r-th round, where r represents the round number.

[0088] As the rounds progress, the polynomial degree gradually decreases, and LTU and HCU work together to cache, submit, and output the necessary summary results for each round.

[0089] It should be noted that the low-degree testing process is not limited to a specific round organization method. As long as it can achieve low-degree verification of the combined constraint results, it can be used.

[0090] 7) When the preset conditions are met in the low-degree test round, extract the query start data from the commitment root according to the query position.

[0091] After the low-degree test rounds meet the preset conditions, TRNG generates query positions. Based on these query positions, QOU extracts the query value, leaf nodes, sibling nodes, and necessary intermediate information from the commitment root to construct the query initiation data. HCU performs refactoring hashing on the nodes related to the authentication path so that the verifier can subsequently recalculate the commitment root and complete consistency verification.

[0092] 8) Encapsulate the outputs of the trajectory shaping unit, polynomial processing unit, commitment unit, constraint combination unit, low-degree testing unit, and query initiation unit into a final proof. The Proof-of-Factory Function (PFU) encapsulates the main trajectory commitment root, auxiliary trajectory commitment root, combined constraint commitment root, commitment roots for each round of low-degree testing, query value, authentication path, final round test data, and random challenge values, query positions, or random seed information used to recover the random challenge values ​​and query positions used in the proof process into the final proof output. Preferably, the PFU can also call the HCU to generate a final digest of the entire proof object for the upper-layer system to quickly index, store, or further recursively process.

[0093] It should be noted that the proof encapsulation can be further extended to higher-level encapsulations for batch proofs, aggregate proofs, or recursive proofs.

[0094] 9) Write the final proof into external main memory.

[0095] DMA writes the final proof object back to main memory, CSR updates the status bits and triggers an interrupt. After receiving the completion notification, the host can read the front-end trajectory results, or further read the final proof results, and hand them over to the verification module, on-chain validator, or upper-layer business system.

[0096] This invention can achieve front-end acceleration by deploying only a front-end hardware acceleration system, and can also form a full-link hardware acceleration from program execution to final proof output when further implemented. Therefore, it has strong compatibility, scalability and protection scope. This invention does not simply splice two independent front-end and back-end solutions together. Instead, it is based on a dedicated acceleration architecture for the front-end. Through a unified buffer structure, a unified scheduling method and a resource reuse mechanism, the back-end proof construction is naturally incorporated into the same data flow and control flow, ultimately forming an integrated heterogeneous hardware acceleration solution under a unified inventive concept.

[0097] This invention is not only applicable to a specific zero-knowledge virtual machine, but can be adopted as long as the target system has a processing chain of "program execution - trajectory generation - commitment / challenge - low-degree testing - query activation - proof output" and it is desired to perform integrated hardware acceleration on this chain.

[0098] The above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of the claims of the present invention pending approval.

Claims

1. A front-end hardware acceleration system, characterized in that, include: The main trajectory unit is used to execute the program to be proven according to the program entry address written on the host side, collect execution status information during execution, generate the main trajectory based on the execution status information, and send the main trajectory to the external main memory and trajectory buffer unit. The auxiliary trajectory unit is used to read the main trajectory from the trajectory buffer unit and generate an auxiliary trajectory based on the main trajectory.

2. The system according to claim 1, characterized in that, The main trajectory unit includes an execution unit and a data acquisition unit that is bypassed by the execution unit; The execution unit is used to execute the program to be proven. The acquisition unit collects execution status information during execution, generates the main trajectory based on the execution status information, and sends the main trajectory to the external main memory and trajectory buffer unit.

3. The system according to claim 1, characterized in that, Multiple auxiliary trajectory units are set up, and the multiple auxiliary trajectory units are connected in parallel.

4. A front-end execution method, characterized in that, The system described in any one of claims 1 to 3 shall be used.

5. The method according to claim 4, characterized in that, During execution, execution status information is collected, and a main trajectory is generated based on the execution status information, including: The collection range is controlled by a preset collection range control character, and the execution status information is collected within the controlled collection range; The collected execution status information is sequentially reduced by modulo, unified in word width, concatenated in fields, and packaged to generate the main trajectory.

6. The method according to claim 4, characterized in that, The main trajectory is a line-shaped trajectory; Auxiliary trajectories are generated based on the main trajectory, including: Traverse the rows of data in the main trajectory, and generate the permutation denominator for each row based on the row data and the random challenge value; the formula for generating the permutation denominator is: D i =γ+∑(β j ×A ij ), D i Let A be the denominator term for the permutation of the data in the i-th row. ij For the j-th data in the i-th row, γ and β are both random challenge values. The results of calculating different powers of β are pre-stored in a lookup table. j Obtained by looking up the table; Based on the permuted denominator terms, generate the inverse column corresponding to each row of permuted denominator terms, and generate the auxiliary trajectory based on the inverse column.

7. A program-provided hardware acceleration system, characterized in that, include: The system according to any one of claims 1 to 3; The trajectory shaping unit is used to shape the trajectory to adapt it to the backend processing; the trajectory includes the main trajectory and the auxiliary trajectory. The polynomial processing unit is used to perform polynomial processing on the shaped trajectory. Commitment unit, used to generate commitment roots from the evaluation results of the shaped trajectory and the extended domain generated by polynomial processing; Constraint combination unit, used to generate combined constraints based on the trajectory polynomial generated by polynomial processing and random challenge values; Low-degree test cells are used to perform low-degree tests on combined constraints. The query activation unit is used to extract query activation data from the commitment root based on the query position when the preset conditions are met in the low-degree test round. The proof encapsulation unit is used to encapsulate the outputs of the trajectory shaping unit, polynomial processing unit, commitment unit, constraint combination unit, low-degree testing unit, and query initiation unit into the final proof. The direct memory access unit is used to write the final proof into external main memory.

8. The system according to claim 7, characterized in that, The program demonstrates that the hardware acceleration system also includes: The random number generator is used to generate random challenge values ​​and query locations; The status register unit is used to register information written by the host side; after receiving a preset instruction from the host side, it updates the status bit and triggers an interrupt. A shared finite field operation unit is used to store algorithms used by other units, allowing other units to schedule algorithms.

9. The system according to claim 7, characterized in that, The commitment unit is also used to generate a program digest for the program to be proven when the program to be proven is loaded; to perform authentication path reconstruction hashing during the query initiation phase; and to generate a final proof digest for the final proof during the proof encapsulation phase.

10. A method for procedural proof, characterized in that, The system described in any one of claims 7 to 8 shall be used.

Images