System on chip, Zero-knowledge proof system, Proof trajectory record generation method

Abstract

The application discloses a system on chip, a zero-knowledge proof system, and a proof track record generation method. The system on chip comprises a pre-compiled operation circuit configured to perform a pre-compiled operation; and a processor connected to the pre-compiled operation circuit and configured to process instructions in a program. When the type of an instruction is a pre-compiled call instruction, the processor sends a pre-compiled operation command package to the pre-compiled operation circuit to perform the pre-compiled operation by the pre-compiled operation circuit, and generates a proof track record corresponding to the instruction according to the result of the pre-compiled operation. The execution process originally requiring a large amount of fine-grained track is compressed into a single semantic complete entry, which greatly reduces the track generation delay and storage overhead, avoids the disconnection between the track and the execution semantics, optimizes the track generation and back-end verification efficiency, significantly reduces the back-end calculation complexity and storage occupation, and improves the response real-time performance.

Description

Technical Field

[0001] This application relates to the field of proof technology, and in particular to a system-on-a-chip, a zero-knowledge proof system, and a method for generating proof trajectory records. Background Technology

[0002] The proof process is usually divided into two interconnected stages: trajectory generation and proof generation. The former is responsible for capturing the deterministic state of program execution, while the latter completes cryptographic verification based on the former.

[0003] However, for pre-compiled operations such as hash operations, elliptic curve operations, and large integer operations, if the trajectory generation stage is implemented entirely by expanding ordinary instructions, not only will the trajectory generation efficiency decrease significantly due to the exponential increase in the number of instructions, but it will also generate a massive amount of fine-grained trajectory records. This rapid expansion in the scale of such records will significantly increase the overall latency of trajectory generation, leading to extremely high computational complexity and storage overhead for backend verification, becoming a key bottleneck restricting the throughput and real-time response of the proof system. Summary of the Invention

[0004] To address the aforementioned issues, this application proposes an on-chip system, a zero-knowledge proof system, and a method for generating proof trajectory records. This method compresses the execution process, which originally required a massive number of fine-grained trajectories, into a single semantically complete entry. This significantly reduces trajectory generation latency and storage overhead, and avoids the disconnect between trajectory and execution semantics. While optimizing the efficiency of trajectory generation and backend verification, it also significantly reduces backend computational complexity and storage usage, thereby improving real-time response.

[0005] In a first aspect, this application provides a system-on-a-chip, comprising: a pre-compilation operation circuit for performing pre-compilation operations; and a processor connected to the pre-compilation operation circuit for processing instructions in a program, and when the type of the instruction is a pre-compilation call instruction, sending a pre-compilation operation command packet to the pre-compilation operation circuit to perform the pre-compilation operation through the pre-compilation operation circuit, and generating a proof trajectory record corresponding to the instruction based on the result of the pre-compilation operation; wherein the result of the pre-compilation operation includes data acquired or generated by the pre-compilation operation circuit during the execution of the pre-compilation operation based on the pre-compilation operation command packet, and result data of the execution of the pre-compilation operation.

[0006] In some embodiments, the processor includes: an instruction pipeline circuit connected to the pre-compilation computation circuit, configured to process the instructions in the program one by one and identify the type of the instructions; when the type of the instruction is the pre-compilation call instruction, generate a pre-compilation computation command package and send the pre-compilation computation command package to the pre-compilation computation circuit.

[0007] In some embodiments, the instruction pipeline circuit is further configured to obtain a plurality of first trajectory data corresponding to the instruction during the processing of the instruction, and generate the pre-compiled operation command package based on the plurality of first trajectory data.

[0008] In some embodiments, the processor further includes: a general-purpose register circuit connected to the instruction pipeline circuit, used to provide register data; the instruction pipeline circuit is further used to obtain the register data corresponding to the instruction through the general-purpose register circuit during the process of processing the instruction and obtaining the plurality of first trajectory data corresponding to the instruction.

[0009] In some embodiments, the pre-compilation operation circuit is further configured to receive the pre-compilation operation command package from the instruction pipeline circuit, and perform the pre-compilation operation according to the first trajectory data in the pre-compilation operation command package to obtain a plurality of second trajectory data.

[0010] In some embodiments, the processor further includes: a memory data cache circuit connected to the pre-compilation operation circuit, used to provide memory data; the pre-compilation operation circuit is also used to obtain the memory data corresponding to the pre-compilation operation through the memory data cache circuit during the execution of the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, and to return the memory data based on the plurality of second trajectory data and through the memory data cache circuit after the pre-compilation operation is completed.

[0011] In some embodiments, the processor further includes: a trajectory construction circuit connected between the instruction pipeline circuit and the pre-compilation operation circuit, for receiving the plurality of first trajectory data from the instruction pipeline circuit, receiving the plurality of second trajectory data from the pre-compilation operation circuit, and constructing the proof trajectory record based on the plurality of first trajectory data and the plurality of second trajectory data.

[0012] In some embodiments, the instruction pipeline circuit is further configured to obtain the plurality of second trajectory data from the trajectory construction circuit and complete the return of the register data through the general-purpose register circuit.

[0013] In some embodiments, the pre-compilation circuit is further configured to return memory data through the memory data cache circuit when the instruction retires; the instruction pipeline circuit is further configured to return register data through the general-purpose register circuit when the instruction retires.

[0014] In some embodiments, the processor further includes: a synchronous decoupling trajectory circuit connected to the trajectory construction circuit, configured to receive the proof trajectory record from the trajectory construction circuit; the trajectory construction circuit is further configured to send the proof trajectory record to the synchronous decoupling trajectory circuit when a first preset condition is met; wherein, when the proof trajectory record is received by the synchronous decoupling trajectory circuit, the instruction completes retirement.

[0015] In some embodiments, the processor is further configured to generate the proof trajectory record when the instruction satisfies a second preset condition.

[0016] Secondly, this application provides a zero-knowledge proof system, comprising: a host computer for providing a program, input parameters, and configuration data, wherein the program includes at least one instruction; a system-on-a-chip (SoC), which is the SoC described in the first aspect above, for acquiring the program, the input parameters, and the configuration data, and generating a proof trajectory record corresponding to the at least one instruction; and a proof circuit for acquiring the proof trajectory record and, after generating proof data corresponding to the proof trajectory record, returning the proof data to the host computer.

[0017] In some embodiments, the host is further configured to write the program, the input parameters, and the configuration data into shared memory, and perform a cache refresh operation after the writing is completed.

[0018] In some embodiments, the host is further configured to send a trajectory generation start signal to the system-on-chip; the system-on-chip is further configured to, upon receiving the trajectory generation start signal, acquire the program, the input parameters and the configuration data, and generate the proof trajectory record corresponding to the at least one instruction.

[0019] In some embodiments, the system-on-chip is further configured to send a trajectory generation end signal to the host after generating the proof trajectory record corresponding to the at least one instruction, so as to start the proof circuit through the host.

[0020] In some embodiments, the host is further configured to perform a memory barrier operation after receiving the trajectory generation end signal, and send a proof start signal to the proof circuit after performing the memory barrier operation to start the proof circuit.

[0021] In some embodiments, the proof circuit is further configured to write the proof data into shared memory after generating proof data corresponding to the proof trajectory record, and send a proof completion signal to the host.

[0022] Thirdly, this application provides a method for generating proof trajectory records, comprising: processing instructions in a program, and generating a pre-compiled operation command package when the type of the instruction is a pre-compiled call instruction; performing a pre-compiled operation according to the pre-compiled operation command package, and generating a proof trajectory record corresponding to the instruction according to the result of the pre-compiled operation; wherein, the result of the pre-compiled operation includes data acquired or generated during the execution of the pre-compiled operation according to the pre-compiled operation command package, and result data of the execution of the pre-compiled operation.

[0023] In some embodiments, the instructions in the processing program, and when the type of the instruction is a pre-compiled call instruction, generating a pre-compiled operation command package, includes: processing the instructions in the program one by one, identifying the type of the instruction, and obtaining a plurality of first trajectory data corresponding to the instruction; when the type of the instruction is the pre-compiled call instruction, generating the pre-compiled operation command package based on the plurality of first trajectory data.

[0024] In some embodiments, acquiring multiple first trajectory data corresponding to the instruction includes: in the process of acquiring multiple first trajectory data corresponding to the instruction, acquiring register data corresponding to the instruction from the register file, and using the register data as the first trajectory data.

[0025] In some embodiments, performing a pre-compilation operation based on the pre-compilation operation command package to obtain the result of the pre-compilation operation includes: performing the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package to obtain a plurality of second trajectory data.

[0026] In some embodiments, the step of performing the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package to obtain a plurality of second trajectory data includes: during the process of performing the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, obtaining memory data corresponding to the pre-compilation operation from the memory storage space, and using the memory data as the second trajectory data.

[0027] In some embodiments, generating the proof trajectory record includes: constructing the proof trajectory record based on the plurality of first trajectory data and the plurality of second trajectory data.

[0028] In some embodiments, after performing the pre-compilation operation based on the first trajectory data in the pre-compiled operation command package to obtain a plurality of second trajectory data, the method includes: returning register data return values ​​to the register file or returning memory data return values ​​to the memory storage space based on the plurality of second trajectory data.

[0029] In some embodiments, returning register data return values ​​to the register file or returning memory data return values ​​to the memory storage space based on the plurality of second trajectory data includes: when the instruction retires, returning register data return values ​​to the register file or returning memory data return values ​​to the memory storage space based on the plurality of second trajectory data.

[0030] In some embodiments, after constructing the proof trajectory record based on the plurality of first trajectory data and the plurality of second trajectory data, the method includes: in response to satisfying a first preset condition, sending the proof trajectory record to a synchronous decoupled trajectory queue, and when the synchronous decoupled trajectory queue receives the proof trajectory record, the instruction completes retirement.

[0031] In some embodiments, the proof trajectory record is generated when the instruction satisfies a second preset condition.

[0032] The beneficial effects of this application are as follows: The on-chip system includes a processor and a pre-compiled computation circuit connected to the processor, effectively solving the bottleneck of generating proof trajectory records for pre-compiled computations. The pre-compiled computation circuit decouples highly complex pre-compiled computations from the processor, fundamentally avoiding the exponential expansion of instruction size caused by general instruction expansion, and reducing the operational pressure on the processor front end (such as instruction fetching and decoding). After the processor recognizes the pre-compiled call instruction, it can automatically integrate all the scheduling parameters required for instruction execution, encapsulate them into a pre-compiled computation command package, and send it to the pre-compiled computation circuit. The entire data preparation process is completed natively by the hardware logic. After the pre-compiled computation circuit performs the computation and returns the result, the processor integrates the full-link execution information to generate a proof trajectory record that uniquely corresponds to a single pre-compiled call instruction. This compresses the complete execution process, which originally required a massive number of fine-grained trajectories, into a single record entry with complete semantics. This approach continuously compresses the trajectory generation time, reduces the space required for trajectory data storage, and ensures that the trajectory information and the actual execution semantics of the instruction remain consistent, avoiding the overhead of repeated verification caused by the disconnect between the two. At the hardware operation level, task decomposition frees core processor resources from prolonged, complex computations, improving processor throughput. Pre-compiled computation circuits, through customized computational pipelines, achieve computational efficiency far exceeding that of general-purpose instruction simulation. Trajectory data undergoes semantic compression, effectively reducing bandwidth pressure on on-chip cache and off-chip storage subsystems, alleviating performance constraints imposed by the memory wall, and reducing power consumption from frequent memory reads and writes. The backend verification phase relies on low-latency, high-consistency proof trajectory for verification, reducing computational load and storage consumption, shortening the overall latency from instruction issuance to retirement, and improving the real-time response of the entire on-chip system. Ultimately, this achieves a simultaneous improvement in overall hardware performance and operational energy efficiency across the entire chain, from computation execution and data flow to trajectory recording and verification. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0034] Figure 1 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 1 ; Figure 2 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 2 ; Figure 3 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 3 ; Figure 4 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 4 ; Figure 5 This is a schematic diagram of the structure of a zero-knowledge proof system according to some embodiments of this application. Figure 1 ; Figure 6 This is a schematic diagram of the structure of a zero-knowledge proof system according to some embodiments of this application. Figure 2 ; Figure 7 This is a schematic diagram of the zero-knowledge proof process for some embodiments of this application. Figure 1 ; Figure 8 This is a schematic diagram of the zero-knowledge proof process for some embodiments of this application. Figure 2 ; Figure 9 This is a flowchart illustrating a method for generating proof trajectory records according to some embodiments of this application; Figure 10 This is a schematic diagram of the pre-compilation operation process of some embodiments of this application. Detailed Implementation

[0035] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be noted that the following embodiments are for illustrative purposes only and are not intended to limit the scope of the application. Similarly, the following embodiments are only some, not all, embodiments of the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0036] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0037] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Additionally, the character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, "many" in this application means two or more. Moreover, the term "at least one" in this application means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C. Furthermore, the terms "first," "second," and "third" in this application are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0038] With the rapid development of blockchain scaling, privacy transactions, verifiable computation, decentralized computing, and off-chain execution scenarios, the computational scale of programs to be proven continues to increase. The computational overhead of the proof generation process has become a key bottleneck for system throughput and response latency, and this bottleneck effect becomes increasingly significant with the increase in program size and input data volume. Currently, trajectory generation that requires pre-compiled instructions suffers from low efficiency and high latency. For example, if the trajectory generation stage is implemented entirely by unfolding ordinary instructions, not only will the exponential expansion of the number of instructions lead to a significant decrease in trajectory generation efficiency, but it will also generate massive amounts of fine-grained trajectory records, which will significantly increase the overall latency of trajectory generation.

[0039] Taking the zKVM (Zero-Knowledge Virtual Machine) scenario as an example, zero-knowledge proofs have been widely used in blockchain scaling, privacy protection, verifiable computing, decentralized computing, and off-chain execution scenarios. The performance and reliability of the proof system have become key links in the entire technology stack.

[0040] To address this, this application provides a system-on-a-chip (SoC) comprising: a pre-compilation operation circuit for performing pre-compilation operations; and a processor connected to the pre-compilation operation circuit for processing instructions in a program. When the instruction type is a pre-compilation call instruction, the processor sends a pre-compilation operation command packet to the pre-compilation operation circuit to perform the pre-compilation operation, and generates a proof trajectory record corresponding to the instruction based on the result of the pre-compilation operation. This reduces the execution process, which originally required a massive number of fine-grained trajectories, into a single semantically complete entry, significantly reducing trajectory generation latency and storage overhead, and preventing the trajectory from becoming disconnected from execution semantics. While optimizing trajectory generation and backend verification efficiency, it significantly reduces backend computational complexity and storage usage, and improves real-time response.

[0041] To enable those skilled in the art to better understand the technical solution of this application, the technical solution of this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0042] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 1 The system-on-chip 100 includes: a pre-compilation operation circuit 110 for performing pre-compilation operations; and a processor 120 connected to the pre-compilation operation circuit 110 for processing instructions in the program. When the instruction type is a pre-compilation call instruction, the processor sends a pre-compilation operation command packet to the pre-compilation operation circuit 110 to perform pre-compilation operations and generate a proof trajectory record corresponding to the instruction based on the result of the pre-compilation operation.

[0043] The pre-compilation operation circuit 110 is used to perform pre-compilation operations. The pre-compilation operation circuit 110 can be an integrated circuit that includes pre-compilation operation functions. For example, the pre-compilation operation circuit 110 may include a coprocessor, which is used to perform pre-compilation operations. The pre-compilation operations include, but are not limited to, hash operations, elliptic curve operations, and large integer operations.

[0044] The processor 120 is used to process instructions in a program, wherein the program may be a user program and the program includes at least one instruction.

[0045] In one implementation, the processor 120 is based on a reduced instruction set architecture, and the program is in a format executable by the processor 120. For example, the processor 120 is a RISC-V (Reduced Instruction Set Computer-Five) processor configured to execute programs and generate corresponding proof trace records, wherein the program can be an executable program conforming to the RISC-V instruction set architecture.

[0046] A pre-compiled call instruction can be an instruction that requires pre-compilation operations. The pre-compiled call instruction can be processed and recognized by the processor 120. For example, the processor 120 obtains an instruction in the program and identifies the type of the instruction, thereby determining that the instruction is a pre-compiled call instruction.

[0047] The precompiled call instructions include information that characterizes the type of precompiled operation. For example, precompiled call instruction A includes information that indicates that a hash operation needs to be performed, precompiled call instruction B includes information that indicates that an elliptic curve operation needs to be performed, and precompiled call instruction C includes information that indicates that a large integer operation needs to be performed.

[0048] A pre-compiled operation command package can be a data package used to perform pre-compiled operations, for example, performing pre-compiled operations based on data in the pre-compiled operation command package.

[0049] In one implementation, the precompiled operation command package is generated based on and corresponds to the precompiled call instruction. For example, during the execution of the precompiled call instruction by the processor 120, the processor 120 parses the precompiled call instruction to obtain parsed data, and executes the operation indicated by the precompiled call instruction (such as a read operation) to obtain the read data. This results in multiple data related to the precompiled call instruction, and a precompiled operation command package corresponding to the precompiled call instruction is generated based on this data. In one example, precompiled operation command package A1 is generated based on and corresponds to precompiled call instruction A; precompiled operation command package B1 is generated based on and corresponds to precompiled call instruction B; and precompiled operation command package C1 is generated based on and corresponds to precompiled call instruction C.

[0050] The precompiled operation command package may include, but is not limited to, at least one of the following fields: a precompiled type field, used to indicate the type of precompiled operation that the instruction needs to perform; a program counter value field, used to locate the position of the instruction in the program; a machine code field, used to record the complete encoding of the instruction; a global timing field, used to record the position of the instruction in the global instruction clock sequence; a source register value field, used to record the operands required by the instruction to be read from the register; a memory parameter address field, used to record the address range of memory data accessed by the instruction; an input length field, used to record the length of the input data of the instruction; and a control field, used to record the immediate value, function code, or operation configuration parameters of the instruction.

[0051] Understandably, depending on the design requirements, the fields in the pre-compiled computation command package can be adjusted, for example, changed, deleted, or expanded.

[0052] The result of the pre-compilation operation may include the pre-compilation operation execution process and the result. For example, the result of the pre-compilation operation may include relevant data obtained or generated by the pre-compilation operation circuit 110 during the pre-compilation operation based on the pre-compilation operation command package, as well as the result data of the pre-compilation operation circuit 110 performing the pre-compilation operation based on the pre-compilation operation command package.

[0053] The results of the pre-compilation operation can be recorded in the form of fields. For example, the results of the pre-compilation operation may include at least one of the following fields: a status code field, used to record the execution result of this pre-compilation operation (such as success or failure); an exception code field, used to record the error type of this pre-compilation operation; a register write-back value field, used to record the result value that needs to be written back to the register for this pre-compilation operation; a memory write-back value field, used to record the result value that needs to be written back to the memory address for this pre-compilation operation; and a memory read value field, used to record the memory value read by this pre-compilation operation.

[0054] The proof trace record can be a data form of instruction execution evidence structure, a data set automatically captured and constructed by the processor 120 from the relevant data generated by the executed instruction, used to record and prove the instruction execution process and result. For example, it could be the relevant data generated from the processing of a pre-compilation call instruction by the processor 120 to the execution of the pre-compilation operation by the pre-compilation operation circuit 110, until the instruction retires. In one example, the proof trace record is recorded in the form of fields, including at least the fields in the pre-compilation operation command package mentioned above, the fields of the pre-compilation operation result, and fields consisting of data processed by the processor 120 for the pre-compilation call instruction but not written into the pre-compilation operation command package. For example, a proof trace record validity field indicates whether the proof trace record is valid; a timestamp field indicates the timestamp corresponding to the read / write operation during instruction execution.

[0055] In one implementation, a pre-compilation operation command packet is sent to the pre-compilation operation circuit 110 to perform pre-compilation operations and generate a proof trajectory record corresponding to the instruction based on the result of the pre-compilation operation. For example, when the processor 120 identifies a pre-compilation call instruction A, it generates a pre-compilation operation command packet A1 corresponding to the pre-compilation call instruction A, and sends the pre-compilation operation command packet A1 to the pre-compilation operation circuit 110. The pre-compilation operation circuit 110 performs the corresponding pre-compilation operation based on the pre-compilation operation command packet A1 and obtains the pre-compilation operation result. Then, the pre-compilation operation result is returned to the processor 120, and the processor 120 generates a proof trajectory record based on the relevant data generated during the complete process from the start of processing of the instruction to retirement.

[0056] Furthermore, for non-precompiled call instructions, the processor 120 can independently generate a proof trace record. For example, for ordinary arithmetic instructions, the processor 120 executes the ordinary arithmetic instructions and automatically captures the relevant data generated by executing the ordinary arithmetic instructions to construct a data set used to record and prove the execution process and results of the instructions as a proof trace record.

[0057] In the above scheme, the system-on-a-chip 100 includes a processor 120 and a pre-compilation operation circuit 110 connected to the processor 120, effectively solving the bottleneck of generating proof trajectory records for pre-compilation operations. The pre-compilation operation circuit 110 decouples high-complexity pre-compilation operations from the processor 120, fundamentally avoiding the problem of exponential expansion of instruction size caused by general instruction expansion, and reducing the operating pressure on the processor front end (such as instruction fetching and decoding). After the processor 120 recognizes the pre-compilation call instruction, it can automatically integrate all the scheduling parameters required for instruction execution, encapsulate them into a pre-compilation operation command package, and send it to the pre-compilation operation circuit 110. The entire data preparation process is completed natively by the hardware logic. After the pre-compilation operation circuit 110 performs the operation and returns the result, the processor 120 integrates the full-link execution information to generate a proof trajectory record that uniquely corresponds to a single pre-compilation call instruction, compressing the complete execution process that originally required a massive number of fine-grained trajectories into a single record entry with complete semantics. This approach continuously compresses trajectory generation time, reduces the space required for trajectory data storage, and ensures that trajectory information and the actual execution semantics of instructions remain consistent, avoiding the overhead of repeated verification caused by their disconnect. At the hardware operation level, the separation of computational tasks prevents the core resources inside the processor 120 from being continuously occupied by long-cycle complex calculations, improving the throughput of the processor 120. The pre-compiled computation circuit 110 achieves computational efficiency far exceeding that of general instruction simulation through a customized computational pipeline. The trajectory data is semantically compressed, effectively reducing the access bandwidth pressure of on-chip cache and off-chip storage subsystems, alleviating the performance constraints caused by the memory wall, and reducing the power consumption caused by frequent memory reads and writes. The back-end verification stage relies on low-latency, high-consistency proof trajectories to carry out verification work, reducing the computational load and storage occupation of the verification stage, shortening the overall latency from instruction issuance to retirement, and improving the real-time response of the entire on-chip system. Ultimately, it achieves a simultaneous improvement in overall hardware performance and operational energy efficiency across the entire chain of computation execution, data flow, trajectory recording, and verification.

[0058] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 2The processor 120 includes an instruction pipeline circuit 121 connected to the pre-compilation circuit 110, which processes each instruction in the program and identifies the type of the instruction. When the type of the instruction is a pre-compilation call instruction, it generates a pre-compilation command package and sends the pre-compilation command package to the pre-compilation circuit 110.

[0059] The instruction pipeline circuit 121 may be an integrated circuit comprising multiple functional sections, which processes instructions in a pipelined manner. For example, the instruction pipeline circuit 121 may include five functional sections, which process instructions in a five-stage pipelined manner.

[0060] In one embodiment, the instruction pipeline circuit 121 is used to process instructions in the program one by one and identify the type of instruction. For example, the instruction pipeline circuit 121 is configured to process instructions sequentially according to the RISC-V five-stage pipeline. The instruction pipeline circuit 121 includes five functional parts, namely instruction fetch, decode, execute, memory access and write back. The five parts of the instruction pipeline circuit 121 are used to sequentially fetch, decode, execute, access memory and write back the instructions in the program.

[0061] Continuing with the example of the instruction pipeline circuit 121 as a five-stage pipeline circuit, after a certain instruction is fetched and reaches the decoding stage, the decoding stage parses the machine code of the instruction, extracts the opcode and function code fields to identify the type of the instruction, for example, identifying the type of the instruction as a pre-compiled call instruction.

[0062] When processing and identifying instructions in the program as pre-compiled call instructions, a pre-compiled operation command package can be generated in the instruction pipeline circuit 121 and sent to the pre-compiled operation circuit 110. For example, the instruction pipeline circuit 121 generates a pre-compiled operation command package based on the relevant data generated by executing the pre-compiled call instruction and sends the pre-compiled operation command package to the pre-compiled operation circuit 110 through the write-back stage.

[0063] Furthermore, when parsing instructions of a custom type that require processing by the pre-compilation processing circuit 110, based on the description in the above embodiments, the relevant information of the instruction is passed to the pre-compilation processing circuit 110 for corresponding processing. For example, the instruction type is a custom coprocessor instruction.

[0064] In the above scheme, by integrating an instruction pipeline circuit 121 into the processor 120, the pipeline's step-by-step processing mechanism accurately identifies the pre-compiled call instructions and transfers the pre-compilation operation to the pre-compilation operation circuit 110 for processing. This avoids complex operations consuming resources and significantly improves the overall throughput efficiency of the pipeline. After identifying the instruction type, the instruction pipeline circuit 121 generates a pre-compilation operation command package and sends it to the pre-compilation operation circuit 110, reducing the interaction overhead between the processor 120 and the pre-compilation operation circuit 110. At the same time, the pipelined automatic data capture mechanism ensures the integrity and timeliness of the command package parameters, providing hardware-level timing guarantees for the accurate execution of the pre-compilation operation and the atomic generation of the subsequent proof trajectory record, effectively avoiding the risk of trajectory disorder caused by instruction expansion.

[0065] In some embodiments, the instruction pipeline circuit 121 is further configured to obtain multiple first trajectory data corresponding to the instruction during the instruction processing process, and generate a pre-compiled operation command package based on the multiple first trajectory data.

[0066] Multiple first trajectory data can be data corresponding to an instruction generated by the instruction pipeline circuit 121 during instruction processing, serving as witnesses to the execution of that instruction. In one example, multiple first trajectory data correspond to fields, such as a precompiled type field, a program counter value field, etc.

[0067] In one implementation, multiple first trajectory data corresponding to an instruction are acquired, and a pre-compiled operation command package is generated based on the multiple first trajectory data. For example, during instruction processing, the instruction pipeline circuit 121 obtains multiple fields corresponding to the instruction, including a pre-compiled type field, and then generates a pre-compiled operation command package based on the multiple fields. In one example, generating the pre-compiled operation command package based on multiple fields may involve using some of the multiple fields to generate the pre-compiled operation command package.

[0068] In the above scheme, the instruction pipeline circuit 121 naturally captures the first trajectory data as the native witness of instruction execution during instruction processing. It can generate a pre-compiled operation command package with complete parameters without the need to add a dedicated data acquisition module. This reduces hardware overhead and ensures strict alignment between the parameters of the pre-compiled operation command package and the instruction execution context. It provides native data support for the accurate execution of pre-compiled operations and the atomic generation of subsequent proof trajectory records, effectively avoiding the risk of the proof trajectory records being disconnected from the semantics of instruction execution, and further reducing the verification complexity of the back-end verification stage.

[0069] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 3The processor 120 also includes a general-purpose register circuit 122 connected to the instruction pipeline circuit 121 for providing register data; the instruction pipeline circuit 121 is also used to obtain register data corresponding to the instruction through the general-purpose register circuit 122 during the process of processing the instruction and obtaining multiple first trajectory data corresponding to the instruction.

[0070] The general-purpose register circuit 122 is used to provide register data. For example, the general-purpose register circuit 122 includes a register file consisting of multiple registers, each of which stores register data.

[0071] The general-purpose register circuit 122 is used to provide register data; that is, the register data in the general-purpose register circuit 122 can be retrieved, for example, by the instruction pipeline circuit 121. Furthermore, the register data in the general-purpose register circuit 122 can also be rewritten; for example, the instruction pipeline circuit 121 can rewrite the register data in the general-purpose register circuit 122 through a write operation.

[0072] In one implementation, the instruction pipeline circuit 121 is used to acquire register data corresponding to the instruction via the general-purpose register circuit 122 during the process of processing an instruction and obtaining multiple first trajectory data corresponding to the instruction. For example, during the process of processing a pre-compiled call instruction and obtaining multiple first trajectory data corresponding to the pre-compiled call instruction, in response to the pre-compiled call instruction instructing the reading of a source register value for pre-compilation operations from the general-purpose register circuit 122, the instruction pipeline circuit 121 reads the source register value from the general-purpose register circuit 122. In one example, the source register index field obtained by parsing the pre-compiled call instruction is used to indicate the reading of the source register value for pre-compilation operations from the general-purpose register circuit 122.

[0073] In the above scheme, during the process of generating the first trajectory data by processing the instruction, the instruction pipeline circuit 121 obtains the register data corresponding to the instruction in the general-purpose register circuit 122, reuses the pipeline's native register access path, and does not require the addition of a dedicated data capture interface. This reduces the hardware implementation complexity and area overhead, while ensuring the timeliness and accuracy of the register context in the first trajectory data. It provides native data support for the parameter completeness of the pre-compiled operation command package and the atomic generation of the subsequent proof trajectory record, effectively avoiding the risk of trajectory semantic inconsistency caused by data lag or read conflicts.

[0074] In some embodiments, the pre-compilation operation circuit 110 is further configured to receive a pre-compilation operation command package from the instruction pipeline circuit 121, and perform a pre-compilation operation based on the first trajectory data in the pre-compilation operation command package to obtain a plurality of second trajectory data.

[0075] Multiple second trajectory data can be data corresponding to the pre-compiled operation commands generated by the pre-compiled operation command package processed by the pre-compiled operation circuit 110, and used as witnesses for the execution of the pre-compiled call instruction corresponding to the pre-compiled operation command package. In one example, multiple second trajectory data can be the result of the pre-compiled operation, and the multiple second trajectory data correspond to the fields contained in the result of the pre-compiled operation, such as status code fields, exception code fields, etc.

[0076] In one implementation, the pre-compilation operation circuit 110 performs a pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, obtaining multiple second trajectory data. For example, it determines the type of pre-compilation operation to be executed based on the pre-compilation type field and matches the corresponding operation logic accordingly; it obtains the source operands required by the pre-compilation call instruction based on the source register value field, using them as inputs for the operation. Subsequently, based on the above inputs and configuration, it performs the corresponding pre-compilation operation and outputs multiple second trajectory data, wherein the multiple second trajectory data includes a status code field obtained based on the operation execution status, an exception code field obtained based on the exception events during the operation, and a register write-back value field obtained based on the operation output result.

[0077] In the above scheme, the pre-compilation operation circuit 110 receives the pre-compilation operation command packet from the instruction pipeline circuit 121, and performs the pre-compilation operation based on the first trajectory data carrying the instruction execution context in the pre-compilation operation command packet to obtain the second trajectory data as a witness to the instruction execution. Parameter passing and result generation can be completed without additional hardware interaction, reducing communication overhead. There is a clear causal correspondence between the first and second trajectory data, enabling the proof trajectory record to completely and accurately reflect the input, processing, and output of the pre-compilation operation, providing a verifiable hardware context for back-end proof. This avoids trajectory bloat caused by instruction expansion and ensures the completeness and consistency of trajectory semantics, effectively improving verification efficiency.

[0078] Please continue reading. Figure 3 The processor 120 also includes a memory data cache circuit 123 connected to the pre-compilation operation circuit 110, used to provide memory data; the pre-compilation operation circuit 110 is also used to obtain memory data corresponding to the pre-compilation operation through the memory data cache circuit 123 during the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, and to return memory data based on multiple second trajectory data through the memory data cache circuit 123 after the pre-compilation operation is completed.

[0079] The memory data cache circuit 123 is used to provide memory data. For example, the memory data cache circuit 123 includes multiple cache units, each storing memory data. As another example, the memory data cache circuit 123 performs a memory read operation to read memory data from the memory storage space according to the memory data address to provide the memory data.

[0080] The memory data cache circuit 123 is used to provide memory data; that is, memory data can be obtained from the memory data cache circuit 123, for example, by the pre-compilation operation circuit 110. Furthermore, the memory data cache circuit 123 can also rewrite memory data. For example, the pre-compilation operation circuit 110 can perform a write operation to rewrite the memory data cached in the memory data cache circuit 123, or the memory data in the memory storage space can be rewritten through the memory data cache circuit 123.

[0081] In one embodiment, the memory data cache circuit 123 is connected to the pre-compilation operation circuit 110. For example, the pre-compilation operation circuit 110 is connected to the processor 120 through the RoCC (Rocket Custom Coprocessor) interface. The RoCC interface includes a memory access sub-interface, which is connected to the memory data cache circuit 123 and implements memory access.

[0082] In one embodiment, the memory data cache circuit 123 is also connected to the instruction pipeline circuit 121, and can acquire and rewrite memory data through the instruction pipeline circuit 121. For example, the instruction pipeline circuit 121 performs a memory read operation, acquiring memory data through the memory data cache circuit 123. As another example, the instruction pipeline circuit 121 performs a write operation to rewrite the memory data cached in the memory data cache circuit 123, or rewrites the memory data in the memory storage space through the memory data cache circuit 123.

[0083] In one implementation, the pre-compilation operation circuit 110 is used to obtain memory data corresponding to the pre-compilation operation through the memory data cache circuit 123 during the pre-compilation operation performed according to the first trajectory data in the pre-compilation operation command package. For example, during the pre-compilation operation performed according to the first trajectory data in the pre-compilation operation command package, the pre-compilation operation circuit 110 reads memory data for performing the pre-compilation operation from the memory data cache circuit 123 in response to the instruction of the first trajectory data in the pre-compilation operation command package. In one example, the first trajectory data used to indicate the reading of memory data may be a memory parameter address field and an input length field.

[0084] In one implementation, the pre-compilation operation circuit 110, after completing the pre-compilation operation, returns memory data based on a plurality of second trajectory data and through the memory data cache circuit 123. For example, after completing the pre-compilation operation, in response to the inclusion of second trajectory data indicating memory data return among the plurality of second trajectory data, the pre-compilation operation circuit 110 returns the corresponding second trajectory data to the memory data cache circuit 123. In one example, the second trajectory data indicating memory data return may be a memory write-back value field.

[0085] In the above scheme, a memory data cache circuit 123 connected to the pre-compilation operation circuit 110 is set in the processor 120. This allows the pre-compilation operation circuit 110 to directly obtain the input memory data required for operation based on the indication of the first trajectory data, and to directly return the memory data based on the second trajectory data after the operation is completed, without additional relay, thus reducing memory access latency and bus overhead. At the same time, the read and write behavior of memory data is fully witnessed by the first and second trajectory data, ensuring the completeness and traceability of the pre-compilation operation memory access trajectory. This allows the memory operations of pre-compilation operation to share a unified consistency proof mechanism with ordinary memory access instructions, effectively improving backend verification efficiency and overall system performance.

[0086] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Figure 4 The processor 120 further includes a trajectory construction circuit 124, connected between the instruction pipeline circuit 121 and the pre-compilation operation circuit 110, for receiving multiple first trajectory data from the instruction pipeline circuit 121, receiving multiple second trajectory data from the pre-compilation operation circuit 110, and constructing a proof trajectory record based on the multiple first trajectory data and the multiple second trajectory data.

[0087] Taking the pre-compiled call instruction A as an example, the trajectory construction circuit 124 encapsulates multiple first trajectory data corresponding to the pre-compiled call instruction A and multiple second trajectory data corresponding to the pre-compiled call instruction A to obtain a complete proof trajectory record corresponding to the pre-compiled call instruction A.

[0088] In the above scheme, a trajectory construction circuit 124 is set between the instruction pipeline circuit 121 and the pre-compilation operation circuit 110 to aggregate the first trajectory data of the instruction execution context and the second trajectory data of the pre-compilation operation result, and construct a complete proof trajectory record accordingly. This achieves atomic aggregation of the instruction execution flow and the pre-compilation operation flow at the trajectory level, decoupling the coupling relationship between each module and the trajectory encapsulation logic, and ensuring the completeness of the proof trajectory record in witnessing the entire lifecycle execution of the instruction.

[0089] In some embodiments, the instruction pipeline circuit 121 is also used to obtain multiple second trajectory data from the trajectory construction circuit 124 and complete the return of register data through the general-purpose register circuit 122.

[0090] In one implementation, the instruction pipeline circuit 121 is used to acquire multiple second trajectory data from the trajectory construction circuit 124 and complete the register data return via the general-purpose register circuit 122. For example, the instruction pipeline circuit 121 acquires multiple second trajectory data returned from the pre-compilation operation circuit 110 from the trajectory construction circuit 124, and in response to the inclusion of second trajectory data indicating register data return among the multiple second trajectory data, completes the register data return based on the second trajectory data. In one example, the second trajectory data indicating register data return may be a register write-back value field.

[0091] In the above scheme, the second trajectory data is obtained from the trajectory construction circuit 124 through the instruction pipeline circuit 121, and the register data return is completed by reusing the general-purpose register circuit 122. There is no need to set up a separate register write-back channel for the pre-compilation operation circuit 110, which reduces the hardware implementation complexity and area overhead. At the same time, the second trajectory data is completely captured by the trajectory construction circuit 124 during the transmission process and used to construct the proof trajectory record. This ensures that the register write-back operation and the generation of the proof trajectory record are strictly aligned in timing, guaranteeing the atomic consistency between the write-back value and the proof trajectory record, avoiding verification failure caused by the disconnect between the two, and further improving the completeness of the proof trajectory record and the overall reliability of the system.

[0092] In some embodiments, the pre-compilation circuit 110 is further configured to return memory data via the memory data cache circuit 123 when an instruction retires; the instruction pipeline circuit 121 is further configured to return register data via the general-purpose register circuit 122 when an instruction retires.

[0093] Instruction retirement can be the end of the instruction's lifecycle. Instruction retirement is tied to the completion of memory data return or register data return. For example, for a pre-compiled call instruction, the lifecycle of the pre-compiled call instruction ends when all steps corresponding to the pre-compiled call instruction have been executed (such as the steps of obtaining multiple first trajectory data and multiple second trajectory data) and the data return operation corresponding to the pre-compiled call instruction has been completed (such as memory data return or register data return).

[0094] In the above scheme, by binding the memory data return or register data return operation with instruction retirement, the pre-compiled call instruction is only determined to have ended its life cycle after the operation result is successfully written back to the corresponding hardware circuit, thus ensuring strict timing consistency between instruction execution results and architecture state updates.

[0095] Please continue reading. Figure 4 The processor 120 further includes: a synchronous decoupling trajectory circuit 125 connected to the trajectory construction circuit 124, for receiving a proof trajectory record from the trajectory construction circuit 124; the trajectory construction circuit 124 is also used to send the proof trajectory record to the synchronous decoupling trajectory circuit 125 when a first preset condition is met; wherein, when the proof trajectory record is received by the synchronous decoupling trajectory circuit 125, the instruction completes retirement.

[0096] The synchronous decoupling trajectory circuit 125 is used to receive proof trajectory records of retired instructions and includes multiple storage areas for storing these records. The proof trajectory records in the synchronous decoupling trajectory circuit 125 can be parsed or proven by subsequent circuits. For example, the synchronous decoupling trajectory circuit 125 receives proof trajectory records of multiple retired pre-compiled call instructions and other types of instructions, and outputs them to a subsequent parsing circuit for parsing the proof trajectory records; or it outputs them to a subsequent proof circuit for proving the proof trajectory records. In one example, the other types of instructions can be ordinary arithmetic instructions, load instructions, store instructions, etc.

[0097] In one implementation, the synchronous decoupling trajectory circuit 125 can receive the complete proof trajectory record at once, or it can receive the complete data of the proof trajectory record asynchronously. For example, after the trajectory construction circuit 124 completes the construction of the complete proof trajectory record, the complete proof trajectory record is received from the trajectory construction circuit 124. Alternatively, a portion of the proof trajectory record data can be received from the trajectory construction circuit 124 at a first moment, and another portion of the proof trajectory record data can be received at a second moment. This achieves asynchronous reception of the complete data of the proof trajectory record within the synchronous decoupling trajectory circuit, adapting to the rate difference between the trajectory construction circuit 124 and the synchronous decoupling trajectory circuit 125, and avoiding congestion caused by synchronous waiting.

[0098] The first preset condition is used to characterize that the synchronous decoupling trajectory circuit 125 has the condition to receive the proof trajectory record, and can be determined according to the storage area occupancy status of the synchronous decoupling trajectory circuit 125.

[0099] In one embodiment, the trajectory construction circuit 124 is further configured to send a proof trajectory record to the synchronous decoupling trajectory circuit 125 when a first preset condition is met. For example, when the synchronous decoupling trajectory circuit 125 further includes a storage area for accommodating the next proof trajectory record, it sends a valid signal indicating that the proof trajectory record can be received to the trajectory construction circuit 124. Conversely, when all storage areas in the synchronous decoupling trajectory circuit 125 for accommodating proof trajectory records are occupied, it sends a signal indicating that the proof trajectory record cannot be received to the trajectory construction circuit 124.

[0100] Specifically, the receipt of the proof trajectory record by the synchronous decoupling trajectory circuit 125 is bound to the completion of the instruction retirement. In other words, the synchronous decoupling trajectory circuit 125 contains the complete execution witness data of the instruction throughout its life cycle. By binding the receipt of the proof trajectory record by the synchronous decoupling trajectory circuit 125 to the completion of the instruction retirement, it is ensured that the complete execution witness data of the instruction throughout its life cycle is effectively parsed and / or proven by subsequent circuits.

[0101] In the above scheme, by setting up a synchronous decoupling trajectory circuit 125 between the trajectory construction circuit 124 and the instruction retirement logic, instruction retirement is strictly bound to the successful receipt of the proof trajectory record by the synchronous decoupling trajectory circuit 125. The instruction lifecycle is only determined to be over when the proof trajectory record is reliably stored, thus eliminating verification failure caused by trajectory loss or out-of-order delivery at the hardware level. When the trajectory construction circuit 124 meets the first preset condition, it sends the proof trajectory record to the synchronous decoupling trajectory circuit 125, realizing the rate decoupling between trajectory generation and back-end processing. This avoids pipeline blockage caused by synchronous waiting and effectively prevents trajectory data overflow, thereby effectively improving the reliability of trajectory collection and the overall system throughput efficiency.

[0102] In some embodiments, the processor 120 is further configured to generate a proof trajectory record when the instructions satisfy a second preset condition.

[0103] The second preset condition can be that the instruction meets the retirement candidate conditions, and a proof trajectory record can be generated for the instruction.

[0104] In one embodiment, the second preset condition may include a second sub-preset condition a and a second sub-preset condition b. For example, the second sub-preset condition a includes determining whether the instruction is valid, whether a return has occurred, and whether an exception has occurred. If all conditions are met, the instruction satisfies the second sub-preset condition a. The second sub-preset condition b includes determining whether the address of the instruction is located in a preset region. In one example, the preset region is a pre-configured user program address region. The determination of whether the instruction is located in the region can be made based on the program counter value field of the instruction. Only when the instruction is located in the region will a corresponding proof trajectory record be generated.

[0105] In one embodiment, the instruction is a pre-compiled call instruction, and when the processor 120 determines that the instruction meets the second preset condition, it generates a proof trajectory record corresponding to the instruction. For example, the proof trajectory record corresponding to the instruction is constructed in the trajectory construction circuit 124.

[0106] In one embodiment, the instruction is a precompiled call instruction, and when the processor 120 determines that the instruction does not meet the second preset condition, it does not generate a proof trajectory record corresponding to the instruction. For example, when the instruction only meets the second sub-preset condition a and does not meet the second sub-preset condition b, the instruction can be retired, but no proof trajectory record corresponding to the instruction is constructed.

[0107] In the above scheme, the behavior of generating proof trajectory records by setting a second preset condition is filtered. The corresponding proof trajectory record is constructed only when the instruction meets the retirement candidate condition, runs effectively, has no abnormalities, and the address is located in the preset user program area. This effectively filters out redundant trajectory data generated by invalid instructions, abnormal instructions, and instructions outside the target address range. While ensuring the verifiability of the key execution process of the user program, it significantly reduces the resource overhead of trajectory generation, storage, and backend verification. For pre-compiled call instructions, the instruction is allowed to retire normally but unnecessary trajectory records are not generated, further simplifying the trajectory scale, avoiding invalid data from occupying storage bandwidth, and improving the overall throughput efficiency and real-time response of the proof system.

[0108] Please see Figures 5-8 , Figure 5 This is a schematic diagram of the structure of a zero-knowledge proof system according to some embodiments of this application. Figure 1 , Figure 6 This is a schematic diagram of the structure of a zero-knowledge proof system according to some embodiments of this application. Figure 2 , Figure 7 This is a schematic diagram of the zero-knowledge proof process for some embodiments of this application. Figure 1 , Figure 8 This is a schematic diagram of the zero-knowledge proof process for some embodiments of this application. Figure 2 ,in, Figures 7-8 These are two examples of numerous zero-knowledge proof process embodiments in this application. The zero-knowledge proof system 500 includes: a host 510, used to provide a program, input parameters, and configuration data, wherein the program includes at least one instruction; an on-chip system 520, used to acquire the program, input parameters, and configuration data, and generate a proof trajectory record corresponding to at least one instruction; and a proof circuit 530, used to acquire the proof trajectory record, and after generating proof data corresponding to the proof trajectory record, return the proof data to the host.

[0109] The host 510 can be a control-side electronic device in the zero-knowledge proof system 500 responsible for controlling and managing the proof task. In one embodiment, the host 510 includes, but is not limited to, a HOST CPU (Central Processing Unit), HOST DDR (Double Data Rate Synchronous Dynamic Random-Access Memory), an operating system, a ZKTrace application, a PCIe driver, a task scheduling module, and a shared memory management module.

[0110] The program can be a user program, that is, a program to be proven, which includes at least one instruction. In one implementation, the host 510 compiles the program into a preset format file, such as a RISC-V ELF format file.

[0111] Input parameters can be a collective term for program input data provided by the host that the program to be proven depends on when executing zero-knowledge proof. In one implementation, input parameters include, but are not limited to, common proof inputs and nondeterministic inputs.

[0112] Configuration data can be data used to initialize and manage the hardware resources of the zero-knowledge proof system. In one implementation, the configuration data includes configuring multiple regions. For example, the configuration data includes, but is not limited to: the base address and size of the user program area, the base address and size of the memory timestamp area, the base address and length of the proof trajectory record output area, and other system configuration parameters.

[0113] The system-on-chip 520 may be the system-on-chip 100 in the above embodiments.

[0114] In one implementation, the system-on-chip 520 is connected to a host 510 to obtain programs, input parameters, and configuration data from the host 510. Further, the system-on-chip 520 generates a proof trajectory record corresponding to at least one instruction. The proof trajectory record can be used for zero-knowledge proofs. The number of proof trajectory records can be equal to or less than the number of at least one instruction. For details on how to generate the proof trajectory records, please refer to the above embodiments; further details will not be repeated here.

[0115] The proof circuit 530 can be an integrated circuit in the zero-knowledge proof system 500 responsible for proving the proof trajectory record to generate proof data.

[0116] In one implementation, the proof circuit 530 includes, but is not limited to, a GPU (Graphics Processing Unit), an FPGA (Field-Programmable Gate Array), an ASIC (Application-Specific Integrated Circuit), or other programmable parallel computing devices.

[0117] In one implementation, the proof circuit 530 acquires proof trajectory records. For example, the proof circuit 530 is connected to the system-on-a-chip 520 to acquire proof trajectory records from the system-on-a-chip 520. Another example is that the proof circuit 530 reads proof trajectory records from a preset storage area, where the preset storage area can be the storage area of ​​a storage device in the host 510, i.e., the proof circuit 530 is connected to the host 510. Figure 5 As shown. The preset storage area can also be the storage area of ​​an independent storage device, where the on-chip system 520 outputs the proof trajectory record to the storage area after generating the proof trajectory record.

[0118] In one implementation, the proof circuit 530 generates proof data based on the proof trajectory record and returns the proof data to the host 510, such as... Figure 5 As shown, the proof circuit 530 is connected to the host 510. The proof circuit 530 directly transmits the proof data to the host 510, or the proof circuit 530 outputs the proof data to a storage area in an independent storage device accessible to the host 510, so that the host 510 can read the proof data from that storage area. Furthermore, the proof circuit 530 can notify the host 510 via MSI-X (Extended Message Signaled Interrupts). When handling this interrupt, the host 510 can perform buffer refresh operations and memory cache invalidation operations to read the latest proof data.

[0119] In one embodiment, the proof circuit 530 performs a preset proof data generation operation to generate proof data. The preset proof data generation operation includes, but is not limited to, columnarizing, sorting, calculating permutation parameters, calculating search parameters, and calculating polynomial commitments on the proof trajectory record according to the constraints in the proof circuit 530.

[0120] In the above solution, the three-level collaborative architecture of host 510, system-on-chip 520 and proof circuit 530 realizes the efficient flow of the entire process of zero-knowledge proof task from issuance to generation. At the same time, the output proof trajectory record has completeness, order and semantic compliance, taking into account both execution efficiency and proof reliability, and provides feasible hardware support for the large-scale implementation of zero-knowledge proof.

[0121] In some embodiments, the host 510 is also configured to write the program, input parameters, and configuration data to shared memory, and perform a cache refresh operation after the writing is complete.

[0122] The shared memory can be a storage area accessible and writable by the host 510 and / or the system-on-chip 520 and / or the proof circuit 530. For example, the shared memory includes at least one of the following: a storage area within the host 510, a storage area within the system-on-chip 520, a storage area in the proof circuit 530, and an external storage device (such as dynamic random access memory).

[0123] In one example, the shared memory includes at least a separate input data area, a trajectory result collection area, and a proof data area. The input data area is used to store the program, input parameters, and configuration data provided by the host 510; the trajectory result collection area is used to store the proof trajectory records generated by the system-on-chip 520; and the proof data area is used to store the proof data generated by the proof circuit 530.

[0124] The trajectory result collection area can be further subdivided into multiple result collection areas. For example, it may include a result collection area for storing proof trajectory records, a result collection area for storing final state auxiliary trajectory records, and a result collection area for storing timestamp final state and result header information. The specific design can be based on the structure of the data related to the proof task that the System-on-Chip 520 can generate. The final state auxiliary trajectory records may include a memory final state data set and a register final state data set.

[0125] Furthermore, after the host 510 writes the program, input parameters, and configuration data to the shared memory, it performs a cache refresh operation to ensure that the latest data is written back to the shared memory from the host 510's cache. This ensures that the subsequent system-on-chip 520 accurately retrieves the program, input parameters, and configuration data from the shared memory. Additionally, after performing the cache refresh operation, a memory barrier operation can be performed to ensure that the program, input parameters, and configuration data are globally visible to the system-on-chip 520.

[0126] In the above solution, shared memory balances cross-device interaction efficiency and reliability, and in conjunction with the host 510 cache refresh mechanism, it prevents data from becoming outdated and is compatible with various certifications.

[0127] In some embodiments, the host 510 is further configured to send a trajectory generation start signal to the system on-chip 520; the system on-chip 520 is further configured to, upon receiving the trajectory generation start signal, acquire the program, input parameters and configuration data, and generate a proof trajectory record corresponding to at least one instruction.

[0128] In some implementations, after performing a preset operation (such as a cache refresh operation and / or a memory barrier operation), the host 510 sends a trace generation start signal to the system-on-chip 520, for example, by notifying the system-on-chip 520 to start via a PCIe doorbell or control register.

[0129] In some implementations, the system-on-chip 520 acquires the program, input parameters, and configuration data according to a preset reading method. For example, the read interface of the system-on-chip 520 is configured in a non-cached or strongly ordered mode to directly read the program, input parameters, and configuration data, bypassing obsolete caches. Furthermore, a proof trajectory record corresponding to at least one instruction is generated, as described in the above embodiments, and will not be repeated here.

[0130] In the above scheme, the host 510 triggers the transmission of the trajectory generation start signal only after performing a preset operation. The on-chip system 520 responds to the signal and starts data acquisition and proof trajectory record generation. This establishes a cross-device task triggering timing between the host 510 and the on-chip system 520. Furthermore, the host 510 sends the trajectory generation start signal only after performing the preset operation, which avoids the on-chip system 520 starting prematurely before the data is ready, thus preventing the reading of outdated data and ensuring the accuracy and completeness of the proof trajectory record generation.

[0131] In some embodiments, the system-on-chip 520 is further configured to send a trajectory generation end signal to the host 510 after generating a proof trajectory record corresponding to at least one instruction, so as to start the proof circuit 530 through the host 510.

[0132] In one implementation, after generating a proof trace record corresponding to at least one instruction, the on-chip system 520 generates an end signal via a PCIe MSI-X interrupt, completion register, or doorbell to notify the host 510 that a proof trace record corresponding to at least one instruction has been generated. Subsequently, the host 510 starts the proof circuit 530 to generate proof data based on the proof trace record.

[0133] In the above scheme, the closed-loop mechanism of the host 510 starting the proof circuit 530 is triggered by the end signal generated by the on-chip system 520, which further reduces the system idle waiting time and eliminates the computing power overhead of the host 510 polling the state. At the same time, the timing boundary from trajectory readiness to proof start is strictly locked by hardware signals to ensure that the data obtained by the proof circuit 530 is complete and valid.

[0134] In some embodiments, the host 510 is further configured to perform a memory barrier operation after receiving a trajectory generation end signal, and send a proof start signal to the proof circuit 530 after performing the memory barrier operation to start the proof circuit 530.

[0135] The memory barrier operation is used to ensure that the proof trajectory record is globally visible to the proof circuit 530.

[0136] In one implementation, the read interface of the proof circuit 530 is configured in an unbuffered or strongly ordered mode to directly read the complete proof trajectory record, for example, by reading the proof trajectory record from the trajectory result collection area.

[0137] In the above scheme, after receiving the trajectory generation end signal, the host 510 executes a memory barrier to ensure that the proof trajectory record output by the on-chip system 520 has been completely written to the shared memory, avoiding the risk of out-of-order transmission where the proof start signal is globally visible before the proof trajectory record. Furthermore, with the non-cached / strongly ordered read configuration of the proof circuit 530, there is no need to deploy a complex cross-device cache consistency protocol, which reduces the complexity of hardware implementation and avoids proof verification failure caused by incomplete or out-of-order trajectory data from the source, further improving the reliability of system operation and the success rate of tasks.

[0138] In some embodiments, the proof circuit 530 is further configured to write the proof data into shared memory after generating proof data corresponding to the proof trajectory record, and send a proof completion signal to the host 510.

[0139] As described in the above embodiments, the proof data can be written to the proof data area in shared memory. Then, after the proof data writing is complete, a proof completion signal is sent to the host 510, so that the host 510 can read the latest proof data.

[0140] In the above scheme, the task progress is precisely synchronized by hardware signals, avoiding host polling overhead and ensuring that the host can read the latest valid content only after the proof data is completely written to disk. Furthermore, the unified shared memory interface is compatible with various proof devices, further improving the closed loop of heterogeneous collaborative zero-knowledge proof tasks.

[0141] Please see Figure 9 and combined Figure 10 , Figure 9 This is a flowchart illustrating the proof trajectory record generation method of some embodiments of this application. Figure 10 This is a schematic diagram of the pre-compilation operation flow of some embodiments of this application. This method can be applied to systems-on-a-chip (SoCs), electronic devices, etc., for example, to SoC 100. Specifically, the relevant steps in this method can be executed by specific circuits in the processor SoC 100. The SoC can be located in an electronic device, which can be a computer. The electronic device can execute this method through the SoC or implement it through a program. In this method, the SoC is used as the execution subject for description. The method includes the following steps: S91: Processes instructions in the program and generates a pre-compiled operation command package when the instruction type is a pre-compiled call instruction.

[0142] The program can be a user program, and the program includes at least one instruction.

[0143] A pre-compiled call instruction can be an instruction that requires pre-compilation operations. Pre-compiled call instructions can be processed and identified. For example, a certain instruction in the program can be obtained and its type can be identified to determine that the instruction is a pre-compiled call instruction.

[0144] The precompiled call instructions include information that characterizes the type of precompiled operation. For example, precompiled call instruction A includes information that indicates that a hash operation needs to be performed, precompiled call instruction B includes information that indicates that an elliptic curve operation needs to be performed, and precompiled call instruction C includes information that indicates that a large integer operation needs to be performed.

[0145] A pre-compiled operation command package can be a data package used to perform pre-compiled operations, for example, performing pre-compiled operations based on data in the pre-compiled operation command package.

[0146] In one implementation, the precompiled operation command package is generated based on and corresponds to a precompiled call instruction. For example, during the execution of the precompiled call instruction, the instruction is parsed to obtain parsed data, and the operation indicated by the instruction (such as a read operation) is executed to obtain read data. This results in multiple data related to the precompiled call instruction, and a precompiled operation command package corresponding to the instruction is generated based on this data. In one example, precompiled operation command package A1 is generated based on and corresponds to precompiled call instruction A; precompiled operation command package B1 is generated based on and corresponds to precompiled call instruction B; and precompiled operation command package C1 is generated based on and corresponds to precompiled call instruction C.

[0147] The precompiled operation command package may include, but is not limited to, at least one of the following fields: a precompiled type field, used to indicate the type of precompiled operation that the instruction needs to perform; a program counter value field, used to locate the position of the instruction in the program; a machine code field, used to record the complete encoding of the instruction; a global timing field, used to record the position of the instruction in the global instruction clock sequence; a source register value field, used to record the operands required by the instruction to be read from the register; a memory parameter address field, used to record the address range of memory data accessed by the instruction; an input length field, used to record the length of the input data of the instruction; and a control field, used to record the immediate value, function code, or operation configuration parameters of the instruction.

[0148] Understandably, depending on the design requirements, the fields in the pre-compiled computation command package can be adjusted, for example, changed, deleted, or expanded.

[0149] S92: Perform pre-compilation operations according to the pre-compilation operation command package, and generate proof trajectory records corresponding to the instructions based on the results of the pre-compilation operations.

[0150] The results of pre-compilation operations can include the pre-compilation operation execution process and results. For example, the results of pre-compilation operations can include relevant data obtained or generated during the pre-compilation operation based on the pre-compilation operation command package, as well as the result data of the pre-compilation operation based on the pre-compilation operation command package.

[0151] The results of the pre-compilation operation can be recorded in the form of fields. For example, the results of the pre-compilation operation may include at least one of the following fields: a status code field, used to record the execution result of this pre-compilation operation (such as success or failure); an exception code field, used to record the error type of this pre-compilation operation; a register write-back value field, used to record the result value that needs to be written back to the register for this pre-compilation operation; a memory write-back value field, used to record the result value that needs to be written back to the memory address for this pre-compilation operation; and a memory read value field, used to record the memory value read by this pre-compilation operation.

[0152] A proof trajectory record can be a data form of instruction execution evidence structure, consisting of a data set automatically captured and constructed from relevant data generated by the executed instruction, used to record and prove the instruction execution process and results. For example, it could be the data generated from the complete process of a pre-compiled call instruction being acquired, executing the pre-compiled operation, and until the instruction retires. In one example, the proof trajectory record is recorded in the form of fields, including at least the fields from the pre-compiled operation command package mentioned above, the fields for the results of the pre-compiled operation, and possibly fields consisting of data that processed the pre-compiled call instruction but was not written into the pre-compiled operation command package. For example, a proof trajectory record validity field indicates whether the proof trajectory record is valid; a timestamp field indicates the timestamps corresponding to read and write operations during instruction execution.

[0153] In one implementation, a pre-compilation operation is performed based on a pre-compilation operation command package, and a proof trajectory record corresponding to the instruction is generated based on the result of the pre-compilation operation. For example, when a pre-compilation call instruction A is identified, a pre-compilation operation command package A1 corresponding to the pre-compilation call instruction A is generated based on the pre-compilation call instruction A, and the corresponding pre-compilation operation is performed based on the pre-compilation operation command package A1 to obtain the pre-compilation operation result. Then, a proof trajectory record is generated by combining the pre-compilation operation result with the relevant data generated from the start of processing of the instruction to retirement.

[0154] Furthermore, for non-precompiled call instructions, there is no need to generate precompiled operation command packages or other types of command packages. Proof trajectory records can be generated directly. For example, for ordinary operation instructions, the ordinary operation instructions are executed, and the relevant data generated by the execution of the ordinary operation instructions is automatically captured and constructed as a data set used to record and prove the execution process and results of the instruction as proof trajectory records.

[0155] The above solution effectively solves the bottleneck of generating proof trajectory records for pre-compiled operations, avoids the exponential expansion of instructions caused by ordinary instruction expansion, significantly reduces front-end execution overhead, and compresses the execution process that originally required a massive number of fine-grained trajectories into a single semantically complete entry. This not only significantly reduces trajectory generation latency and storage overhead, but also avoids the disconnect between trajectory and execution semantics. While optimizing trajectory generation and back-end verification efficiency, it significantly reduces back-end computational complexity and storage usage, and improves real-time response.

[0156] In some embodiments, the instructions in the processing program, and when the type of the instruction is a pre-compiled call instruction, generate a pre-compiled operation command package, including: processing each instruction in the processing program, identifying the type of the instruction, and obtaining multiple first trajectory data corresponding to the instruction; when the type of the instruction is a pre-compiled call instruction, generating a pre-compiled operation command package based on the multiple first trajectory data.

[0157] Multiple first trajectory data can be data generated by processing instructions and corresponding to those instructions, serving as witnesses to the execution of those instructions. In one example, multiple first trajectory data correspond to fields, such as precompiled type fields, program counter value fields, etc.

[0158] One method for identifying the type of instruction is to parse the machine code of the instruction during the processing of the instruction to extract the opcode and function fields, thereby achieving instruction type identification.

[0159] In one implementation, each instruction in the program is processed sequentially. The type of each instruction is identified, and multiple first trajectory data corresponding to each instruction are obtained. For example, if the program includes instructions X1, X2, and X3, instructions X1, X2, and X3 are obtained sequentially from the program. The types of instructions X1, X2, and X3 are identified sequentially, and multiple fields corresponding to instruction X1, instruction X2, and instruction X3 are obtained sequentially. Specifically, the multiple fields corresponding to instruction X1 are multiple first trajectory data corresponding to instruction X1, the multiple fields corresponding to instruction X2 are multiple first trajectory data corresponding to instruction X2, and the multiple fields corresponding to instruction X3 are multiple first trajectory data corresponding to instruction X3.

[0160] Continuing with the examples of instructions X1, X2, and X3, when the instruction type is a pre-compiled call instruction, a pre-compiled operation command package is generated based on multiple first trajectory data. For instance, a pre-compiled operation command package corresponding to instruction X1 is generated based on multiple fields corresponding to instruction X1, a pre-compiled operation command package corresponding to instruction X2 is generated based on multiple fields corresponding to instruction X2, and a pre-compiled operation command package corresponding to instruction X3 is generated based on multiple fields corresponding to instruction X3. In one example, generating a pre-compiled operation command package corresponding to instruction X1, instruction X2, or instruction X3 based on multiple fields corresponding to instruction X1, instruction X2, or instruction X3 could involve using only some of the multiple fields to generate the pre-compiled operation command package.

[0161] In the above scheme, the first trajectory data, which serves as the native witness to instruction execution, is naturally captured during instruction processing. This eliminates the need for an additional dedicated data acquisition module to generate a pre-compiled operation command package with complete parameters. This reduces hardware overhead and ensures strict alignment between the parameters of the pre-compiled operation command package and the instruction execution context. It provides native data support for the accurate execution of pre-compiled operations and the atomic generation of subsequent proof trajectory records, effectively avoiding the risk of semantic decoupling between proof trajectory records and instruction execution, and further reducing the verification complexity in the back-end verification stage.

[0162] In some embodiments, acquiring multiple first trajectory data corresponding to an instruction includes: in the process of acquiring multiple first trajectory data corresponding to an instruction, acquiring register data corresponding to the instruction from a register file, and using the register data as the first trajectory data.

[0163] The register file is used to provide register data. For example, the register file can be the register file in the general-purpose register circuit 122 in the above embodiment. The register file includes multiple registers, each of which stores register data.

[0164] The register data in the register file can be read and modified. For example, during instruction execution, read and / or write operations generated by executing the instruction can read and / or modify the register data in the register file.

[0165] In one implementation, during the acquisition of multiple first trajectory data corresponding to an instruction, register data corresponding to the instruction is retrieved from the register file and used as the first trajectory data. For example, during the acquisition of multiple first trajectory data corresponding to a pre-compilation call instruction, in response to the pre-compilation call instruction instructing the reading of a source register value from the register file for pre-compilation operations, the source register value is read from the register file and used as the first trajectory data. In one example, the source register index field obtained by parsing the pre-compilation call instruction is used to indicate the reading of the source register value from the register file for pre-compilation operations.

[0166] In the above scheme, during the process of acquiring multiple first trajectory data corresponding to the instruction, the register data corresponding to the instruction is obtained from the register file, and the pipeline native register access path is reused. There is no need to add a dedicated data capture interface, which reduces the hardware implementation complexity and area overhead, and ensures the timeliness and accuracy of the register context in the first trajectory data. This provides native data support for the parameter completeness of the pre-compiled operation command package and the atomic generation of the subsequent proof trajectory record, effectively avoiding the risk of trajectory semantic inconsistency caused by data lag or read conflicts.

[0167] In some embodiments, performing a pre-compilation operation based on a pre-compilation operation command package to obtain the result of the pre-compilation operation includes: performing a pre-compilation operation based on the first trajectory data in the pre-compilation operation command package to obtain a plurality of second trajectory data.

[0168] Multiple second trajectory data can be data corresponding to pre-compiled operation commands generated from processing pre-compiled operation command packages, used as witnesses to the execution of pre-compiled call instructions corresponding to the pre-compiled operation command packages. In one example, multiple second trajectory data can be the result of pre-compiled operations, and the multiple second trajectory data correspond to fields contained in the result of pre-compiled operations, such as status code fields, exception code fields, etc.

[0169] In one implementation, a pre-compiled operation is performed based on the first trajectory data in the pre-compiled operation command package to obtain multiple second trajectory data. For example, the type of pre-compiled operation to be executed is determined based on the pre-compiled type field, and the corresponding operation logic is matched accordingly. The source operands required by the pre-compiled call instruction are obtained based on the source register value field as the input of the operation. Subsequently, the corresponding pre-compiled operation is performed based on the above input and configuration, and multiple second trajectory data are output. The multiple second trajectory data include a status code field obtained based on the operation execution status, an exception code field obtained based on the exception events during the operation, and a register write-back value field obtained based on the operation output result.

[0170] In the above scheme, pre-compilation operation is performed based on the first trajectory data carrying the instruction execution context in the pre-compiled operation command package to obtain the second trajectory data as witness to instruction execution. There is a clear causal correspondence between the first trajectory data and the second trajectory data, which enables the proof trajectory record to completely and accurately reflect the input, processing and output of the pre-compilation operation, providing a verifiable hardware context for back-end proof. This avoids trajectory expansion caused by instruction expansion and ensures the completeness and consistency of trajectory semantics, effectively improving verification efficiency.

[0171] In some embodiments, a pre-compilation operation is performed based on the first trajectory data in the pre-compilation operation command package to obtain multiple second trajectory data, including: during the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, memory data corresponding to the pre-compilation operation is obtained based on the memory storage space, and the memory data is used as the second trajectory data.

[0172] The memory storage space is used to provide memory data. For example, the memory storage space can be the storage space used to cache memory data in the memory data caching circuit 123 in the above embodiment, or it can be a storage space used to cache memory data that can be accessed by the memory data caching circuit 123. The memory storage space includes multiple storage units, and each storage unit stores memory data.

[0173] In this context, the memory data in the memory storage space can be read and modified. For example, during instruction execution, read and / or write operations generated by executing the instruction can read and / or modify the memory data in the memory storage space.

[0174] In one implementation, during the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, memory data corresponding to the pre-compilation operation is obtained from the memory storage area and used as the second trajectory data. For example, during the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, in response to the instruction of the first trajectory data in the pre-compilation operation command package, memory data for performing the pre-compilation operation is read from the memory storage space, and this memory data is used as the second trajectory data. In one example, the first trajectory data used to indicate the reading of memory data may be a memory parameter address field and an input length field.

[0175] In the above scheme, the reading and writing behavior of memory data is fully witnessed by the first trajectory data and the second trajectory data, which ensures the completeness and traceability of the memory access trajectory of the pre-compiled operation, and enables the memory operation of the pre-compiled operation to share a unified consistency proof mechanism with ordinary memory access instructions, effectively improving the back-end verification efficiency and the overall system performance.

[0176] In some embodiments, generating a proof trajectory record includes: constructing a proof trajectory record based on a plurality of first trajectory data and a plurality of second trajectory data.

[0177] Taking the pre-compiled call instruction A as an example, multiple first trajectory data corresponding to the pre-compiled call instruction A and multiple second trajectory data corresponding to the pre-compiled call instruction A are encapsulated to obtain a complete proof trajectory record corresponding to the pre-compiled call instruction A.

[0178] In the above scheme, the first trajectory data of the instruction execution context and the second trajectory data of the pre-compiled operation result are aggregated, and a complete proof trajectory record is constructed accordingly. This achieves atomic aggregation of the instruction execution flow and the pre-compiled operation flow at the trajectory level, ensuring the completeness of the proof trajectory record in witnessing the entire lifecycle of the instruction execution.

[0179] In some embodiments, after performing a pre-compilation operation based on the first trajectory data in the pre-compiled operation command package to obtain a plurality of second trajectory data, the method includes: returning register data return values ​​to the register file or returning memory data return values ​​to memory storage space based on the plurality of second trajectory data.

[0180] In one implementation, a register data return value is returned to the register file based on a plurality of second trajectory data. For example, in response to the inclusion of second trajectory data indicating the return of register data among the plurality of second trajectory data, the second trajectory data (register data return value) is returned to the register file. In one example, the second trajectory data indicating the return of register data may be a register write-back value field.

[0181] In one implementation, a memory data return value is returned to memory storage based on a plurality of second trajectory data. For example, in response to the inclusion of second trajectory data indicating the return of memory data among the plurality of second trajectory data, the second trajectory data (memory data return value) is returned to memory storage. In one example, the second trajectory data indicating the return of memory data may be a memory write-back value field.

[0182] In the above scheme, the register write-back value or memory write-back value in the second trajectory data is returned to complete the update of the architecture state, ensuring the completeness and traceability of the pre-compiled operation trajectory, enabling the read and write operations of pre-compiled operations to share a unified consistency proof mechanism with non-pre-compiled operation instructions, effectively improving the back-end verification efficiency and the overall system performance.

[0183] In some embodiments, returning register data return values ​​to the register file or returning memory data return values ​​to memory storage space based on a plurality of second trajectory data includes: returning register data return values ​​to the register file or returning memory data return values ​​to memory storage space based on a plurality of second trajectory data when an instruction retires.

[0184] Instruction retirement can be the end of the instruction's lifecycle. Instruction retirement is tied to the return of register data and memory data. For example, for a precompiled call instruction, the lifecycle of the precompiled call instruction ends when all steps corresponding to the precompiled call instruction have been executed (such as the steps of obtaining multiple first trajectory data and multiple second trajectory data) and the data return operation corresponding to the precompiled call instruction has been completed (such as register data return or memory data return).

[0185] In the above scheme, by binding the memory data return or register data return operation with instruction retirement, the pre-compiled call instruction is only determined to have ended its life cycle after the operation result is successfully written back to the corresponding hardware circuit, thus ensuring strict timing consistency between instruction execution results and architecture state updates.

[0186] In some embodiments, after constructing a proof trajectory record based on a plurality of first trajectory data and a plurality of second trajectory data, the method includes: in response to satisfying a first preset condition, sending the proof trajectory record to a synchronous decoupled trajectory queue, and when the synchronous decoupled trajectory queue receives the proof trajectory record, instructing to complete retirement.

[0187] The synchronous decoupling trajectory queue is used to receive proof trajectory records of retired instructions and includes multiple storage areas for storing these records. The proof trajectory records in the synchronous decoupling trajectory queue can be parsed or proven subsequently. For example, the synchronous decoupling trajectory queue can be the synchronous decoupling trajectory circuit 125 in the above embodiment. The synchronous decoupling trajectory queue receives proof trajectory records of multiple retired pre-compiled call instructions and other types of instructions, and outputs them to a subsequent parser for parsing; or outputs them to a subsequent prover for proving the proof trajectory records. In one example, the other types of instructions can be ordinary arithmetic instructions, load instructions, store instructions, etc.

[0188] In one implementation, the synchronous decoupled trajectory queue can receive the complete proof trajectory record all at once, or it can receive the complete data of the proof trajectory record asynchronously. For example, it can receive the complete proof trajectory record after the complete construction of the proof trajectory record is completed. Alternatively, it can receive a portion of the proof trajectory record data at a first moment and another portion at a second moment, thereby achieving asynchronous reception of the complete proof trajectory record data within the synchronous decoupled trajectory queue. This adapts to the rate difference between the construction of the proof trajectory record and the synchronous decoupled trajectory queue, avoiding congestion caused by synchronous waiting.

[0189] The first preset condition is used to characterize that the synchronous decoupled trajectory queue has the conditions to receive proof trajectory records, and can be determined based on the storage area occupancy status of the synchronous decoupled trajectory queue.

[0190] In one implementation, a proof trajectory record is sent to the synchronous decoupling trajectory queue when a first preset condition is met. For example, when the synchronous decoupling trajectory queue also includes a storage area for accommodating the next proof trajectory record, the next proof trajectory record is sent to the synchronous decoupling trajectory queue. Conversely, when all storage areas in the synchronous decoupling trajectory queue for accommodating proof trajectory records are occupied, the sending of the next proof trajectory record to the synchronous decoupling trajectory queue is stopped.

[0191] Specifically, the receipt of the proof trajectory record by the synchronous decoupled trajectory queue is bound to the completion of the instruction's retirement. In other words, the synchronous decoupled trajectory queue contains the complete execution witness data of the instruction throughout its lifecycle. By binding the receipt of the proof trajectory record by the synchronous decoupled trajectory queue to the completion of the instruction's retirement, it is ensured that the complete execution witness data of the instruction throughout its lifecycle can be effectively parsed and / or proven in the future.

[0192] In the above scheme, a synchronous decoupled trajectory queue is set up, and instruction retirement is strictly bound to the proof that the trajectory record has been successfully received by the synchronous decoupled trajectory queue. The life cycle of the instruction is only determined to be over when the proof trajectory record is reliably stored, thus eliminating verification failure caused by trajectory loss or out-of-order delivery at the hardware level. When the first preset condition is met, the proof trajectory record is sent to the synchronous decoupled trajectory queue, realizing the decoupling of the trajectory generation and back-end processing rates. This avoids pipeline blockage caused by synchronous waiting and effectively prevents trajectory data overflow, thereby effectively improving the reliability of trajectory collection and the overall system throughput efficiency.

[0193] In some embodiments, a proof trajectory record is generated when the instruction meets a second preset condition.

[0194] The second preset condition can be that the instruction meets the retirement candidate conditions, and a proof trajectory record can be generated for the instruction.

[0195] In one embodiment, the second preset condition may include a second sub-preset condition a and a second sub-preset condition b. For example, the second sub-preset condition a includes determining whether the instruction is valid, whether a return has occurred, and whether an exception has occurred. If all conditions are met, the instruction satisfies the second sub-preset condition a. The second sub-preset condition b includes determining whether the address of the instruction is located in a preset region. In one example, the preset region is a pre-configured user program address region. The determination of whether the instruction is located in the region can be made based on the program counter value field of the instruction. Only when the instruction is located in the region will a corresponding proof trajectory record be generated.

[0196] In one embodiment, the instruction is a pre-compiled call instruction, and when it is determined that the instruction meets a second preset condition, a proof trajectory record corresponding to the instruction is generated. For example, when the instruction meets both the second sub-preset condition a and the second sub-preset condition b, a proof trajectory record corresponding to the instruction is constructed.

[0197] In one embodiment, the instruction is a pre-compiled call instruction, and if it is determined that the instruction does not meet the second preset condition, no proof trajectory record corresponding to the instruction is generated. For example, if the instruction only meets the second sub-preset condition a and does not meet the second sub-preset condition b, the instruction can be retired, but no proof trajectory record corresponding to the instruction is constructed.

[0198] In the above scheme, the behavior of generating proof trajectory records by setting a second preset condition is filtered. The corresponding proof trajectory record is constructed only when the instruction meets the retirement candidate condition, runs effectively, has no abnormalities, and the address is located in the preset user program area. This effectively filters out redundant trajectory data generated by invalid instructions, abnormal instructions, and instructions outside the target address range. While ensuring the verifiability of the key execution process of the user program, it significantly reduces the resource overhead of trajectory generation, storage, and backend verification. For pre-compiled call instructions, the instruction is allowed to retire normally but unnecessary trajectory records are not generated, further simplifying the trajectory scale, avoiding invalid data from occupying storage bandwidth, and improving the overall throughput efficiency and real-time response of the proof system.

[0199] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0200] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0201] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0202] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0203] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A system-on-a-chip, characterized in that, include: Pre-compilation operation circuitry, used to perform pre-compilation operations; The processor, connected to the pre-compilation operation circuit, is used to process instructions in the program. When the type of the instruction is a pre-compilation call instruction, it sends a pre-compilation operation command packet to the pre-compilation operation circuit to execute the pre-compilation operation through the pre-compilation operation circuit, and generates a proof trajectory record corresponding to the instruction based on the result of the pre-compilation operation. The result of the pre-compilation operation includes data acquired or generated by the pre-compilation operation circuit during the execution of the pre-compilation operation based on the pre-compilation operation command package, as well as the result data of the pre-compilation operation.

2. The system-on-a-chip according to claim 1, characterized in that, The processor includes: An instruction pipeline circuit, connected to the pre-compilation operation circuit, is used to process each instruction in the program and identify the type of the instruction. When the type of the instruction is the pre-compilation call instruction, a pre-compilation operation command package is generated and the pre-compilation operation command package is sent to the pre-compilation operation circuit.

3. The system-on-a-chip according to claim 2, characterized in that, The instruction pipeline circuit is also used to obtain multiple first trajectory data corresponding to the instruction during the processing of the instruction, and to generate the pre-compiled operation command package based on the multiple first trajectory data.

4. The system-on-a-chip according to claim 3, characterized in that, The processor also includes: A general-purpose register circuit, connected to the instruction pipeline circuit, is used to provide register data; The instruction pipeline circuit is further configured to, during the process of processing the instruction and obtaining the plurality of first trajectory data corresponding to the instruction, acquire the register data corresponding to the instruction through the general-purpose register circuit.

5. The system-on-a-chip according to claim 4, characterized in that, The pre-compilation operation circuit is further configured to receive the pre-compilation operation command package from the instruction pipeline circuit, and perform the pre-compilation operation according to the first trajectory data in the pre-compilation operation command package to obtain multiple second trajectory data.

6. The system-on-a-chip according to claim 5, characterized in that, The processor also includes: A memory data caching circuit, connected to the pre-compiled computation circuit, is used to provide memory data; The pre-compilation operation circuit is further configured to, during the process of performing the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, obtain the memory data corresponding to the pre-compilation operation through the memory data cache circuit, and after completing the pre-compilation operation, return the memory data based on the plurality of second trajectory data through the memory data cache circuit.

7. The system-on-a-chip according to claim 5, characterized in that, The processor also includes: A trajectory construction circuit, connected between the instruction pipeline circuit and the pre-compilation operation circuit, is used to receive the plurality of first trajectory data from the instruction pipeline circuit, receive the plurality of second trajectory data from the pre-compilation operation circuit, and construct the proof trajectory record based on the plurality of first trajectory data and the plurality of second trajectory data.

8. The system-on-a-chip according to claim 7, characterized in that, The instruction pipeline circuit is also used to obtain the plurality of second trajectory data from the trajectory construction circuit and to return the register data through the general-purpose register circuit.

9. The system-on-a-chip according to claim 6 or 8, characterized in that, The pre-compilation operation circuit is also used to return memory data through the memory data cache circuit when the instruction retires; The instruction pipeline circuit is also used to return the register data via the general-purpose register circuit when the instruction retires.

10. The system-on-a-chip according to claim 7, characterized in that, The processor also includes: A synchronous decoupling trajectory circuit, connected to the trajectory construction circuit, is used to receive the proof trajectory record from the trajectory construction circuit; The trajectory construction circuit is also used to send the proof trajectory record to the synchronous decoupling trajectory circuit when the first preset condition is met; Specifically, the instruction completes retirement when the proof trajectory record is received by the synchronous decoupling trajectory circuit.

11. The system-on-a-chip according to claim 1, characterized in that, The processor is also configured to generate the proof trajectory record when the instruction satisfies the second preset condition.

12. A zero-knowledge proof system, characterized in that, include: A host computer is used to provide programs, input parameters, and configuration data, wherein the program includes at least one instruction; A system-on-a-chip, wherein the system-on-a-chip is the system-on-a-chip according to any one of claims 1-11, is used to acquire the program, the input parameters and the configuration data, and generate a proof trajectory record corresponding to the at least one instruction; The proof circuit is used to acquire the proof trajectory record and, after generating proof data corresponding to the proof trajectory record, return the proof data to the host.

13. The zero-knowledge proof system according to claim 12, characterized in that, The host is also used to write the program, the input parameters and the configuration data into shared memory, and to perform a cache refresh operation after the writing is completed.

14. The zero-knowledge proof system according to claim 13, characterized in that, The host computer is also used to send a trajectory generation start signal to the on-chip system; The on-chip system is also used to, upon receiving the trajectory generation start signal, acquire the program, the input parameters, and the configuration data, and generate the proof trajectory record corresponding to the at least one instruction.

15. The zero-knowledge proof system according to claim 13, characterized in that, The on-chip system is also used to send a trajectory generation end signal to the host after generating the proof trajectory record corresponding to the at least one instruction, so as to start the proof circuit through the host.

16. The zero-knowledge proof system according to claim 15, characterized in that, The host is also configured to perform a memory barrier operation after receiving the trajectory generation end signal, and send a proof start signal to the proof circuit after performing the memory barrier operation to start the proof circuit.

17. The zero-knowledge proof system according to claim 16, characterized in that, The proof circuit is also used to write the proof data corresponding to the proof trajectory record into shared memory after generating the proof data, and send a proof completion signal to the host.

18. A method for generating proof trajectory records, characterized in that, include: The program processes instructions and, when the type of the instruction is a pre-compiled call instruction, generates a pre-compiled operation command package; The pre-compilation operation is performed according to the pre-compilation operation command package, and a proof trajectory record corresponding to the instruction is generated based on the result of the pre-compilation operation. The result of the pre-compilation operation includes data acquired or generated during the execution of the pre-compilation operation according to the pre-compilation operation command package, as well as the result data of the pre-compilation operation.

19. The method according to claim 18, characterized in that, The instructions in the processor, and when the type of the instruction is a pre-compiled call instruction, generate a pre-compiled operation command package, including: The instructions in the program are processed one by one, the types of the instructions are identified, and multiple first trajectory data corresponding to the instructions are obtained; When the type of the instruction is the pre-compiled call instruction, the pre-compiled operation command package is generated based on the plurality of first trajectory data.

20. The method according to claim 19, characterized in that, The acquisition of multiple first trajectory data corresponding to the instruction includes: In the process of acquiring multiple first trajectory data corresponding to the instruction, register data corresponding to the instruction is acquired from the register file and used as the first trajectory data.

21. The method according to claim 20, characterized in that, Perform pre-compilation operations according to the pre-compilation operation command package to obtain the results of the pre-compilation operations, including: Based on the first trajectory data in the pre-compiled operation command package, the pre-compiled operation is performed to obtain multiple second trajectory data.

22. The method according to claim 21, characterized in that, The step involves performing the pre-compilation operation based on the first trajectory data in the pre-compiled operation command package to obtain multiple second trajectory data, including: During the execution of the pre-compilation operation based on the first trajectory data in the pre-compilation operation command package, memory data corresponding to the pre-compilation operation is obtained from the memory storage space, and the memory data is used as the second trajectory data.

23. The method according to claim 21, characterized in that, Generating the proof trajectory record includes: The proof trajectory record is constructed based on the plurality of first trajectory data and the plurality of second trajectory data.

24. The method according to claim 22, characterized in that, After performing the pre-compilation operation based on the first trajectory data in the pre-compiled operation command package to obtain multiple second trajectory data, the process includes: The register data return value is returned to the register stack based on the plurality of second trajectory data, or the memory data return value is returned to the memory storage space.

25. The method according to claim 24, characterized in that, The step of returning register data return values ​​to the register file or returning memory data return values ​​to the memory storage space based on the plurality of second trajectory data includes: When the instruction retires, the register data return value is returned to the register file or the memory data return value is returned to the memory storage space based on the plurality of second trajectory data.

26. The method according to claim 23, characterized in that, After constructing the proof trajectory record based on the plurality of first trajectory data and the plurality of second trajectory data, the process includes: In response to the fulfillment of a first preset condition, the proof trajectory record is sent to the synchronous decoupling trajectory queue. When the synchronous decoupling trajectory queue receives the proof trajectory record, the instruction completes retirement.

27. The method according to claim 18, characterized in that, When the instruction meets the second preset condition, the proof trajectory record is generated.

Images