Processor, zero-knowledge proof system, trajectory generation method and system on chip

Abstract

This application discloses a processor, a zero-knowledge proof system, a trajectory generation method, and a system-on-a-chip. The processor includes: a trajectory processing circuit for processing instructions to be processed in a program and generating at least one proof trajectory record; and an auxiliary trajectory generation circuit connected to the trajectory processing circuit for tracing the instructions in the program during program execution to generate a memory event final state record and a register event final state record corresponding to the program. The memory event final state record and the register event final state record are used to construct an auxiliary trajectory record to prove the execution process of the program along with the at least one proof trajectory record. This effectively solves the problems of insufficient credibility of final state data and the disconnect between process evidence and result evidence, balancing the credibility, completeness, and execution efficiency of trajectory generation.

Description

Technical Field

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

[0002] The proof process is usually divided into two interconnected stages: trajectory generation and proof generation. The former generates the instruction-by-instruction main trajectory by capturing the deterministic state of program execution, while the latter completes the proof generation based on the main trajectory and combined with memory final state data and register final state data.

[0003] Currently, the generation of memory final state data and register final state data is generally postponed to the proof generation stage. This stage requires obtaining memory final state data and register final state data by offline reverse engineering of the main trajectory or by inserting software scan instructions to read the state after execution. This has the drawbacks of introducing additional overhead and low accuracy, increasing processing latency and easily leading to proof failure. Summary of the Invention

[0004] To address the aforementioned issues, this application proposes a processor, a zero-knowledge proof system, a trajectory generation method, and an on-chip system, which effectively solves the problems of insufficient credibility of final state data and the disconnect between process evidence and result evidence, while taking into account the credibility, completeness, and execution efficiency of trajectory generation.

[0005] In a first aspect, this application provides a processor, comprising: a trajectory processing circuit for processing instructions to be processed in a program and generating at least one proof trajectory record; and an auxiliary trajectory generation circuit connected to the trajectory processing circuit for tracing the instructions in the program during program execution to generate a memory event final state record and a register event final state record corresponding to the program, wherein the memory event final state record and the register event final state record are used to construct an auxiliary trajectory record to prove the execution process of the program along with the at least one proof trajectory record.

[0006] In some embodiments, the trajectory processing circuit includes a processor core, the processor core including an instruction pipeline circuit, the instruction pipeline circuit being used to execute the instructions to be processed in the program instruction by instruction, and to generate the at least one proof trajectory record one by one.

[0007] In some embodiments, the auxiliary trajectory generation circuit is located outside the processor core. The auxiliary trajectory generation circuit includes: a preprocessing circuit connected to the instruction pipeline circuit, configured to receive instruction tracing information output by the instruction pipeline circuit, and perform multi-level pipeline preprocessing on the instruction tracing information in parallel with the process of generating the at least one proof trajectory record one by one by the instruction pipeline circuit, based on the instruction tracing information, to obtain a preprocessing result corresponding to each proof trajectory record.

[0008] In some embodiments, the preprocessing circuit is further configured to perform user program area filtering, instruction type identification, termination instruction masking, and retirement instruction counting based on the instruction trace information.

[0009] In some embodiments, the preprocessing circuit is further configured to calculate the memory access address corresponding to the memory event instruction based on the instruction trace information when the result of the instruction type identification is a memory event instruction.

[0010] In some embodiments, the preprocessing circuit is further configured to determine whether the program has ended based on a first preset condition when the result of the instruction type identification is a preset program end instruction, wherein the first preset condition includes at least one of multi-level pipeline consistency, multi-cycle debouncing, and data storage request.

[0011] In some embodiments, the auxiliary trajectory generation circuit includes: a memory event tracking circuit connected to the preprocessing circuit, used to track memory event instructions in the program, set the bitmap corresponding to the memory event instruction, and record the memory timestamp corresponding to the memory event instruction in a memory timestamp table.

[0012] In some embodiments, the memory event tracking circuit is further configured to track the memory event instruction when the memory access address corresponding to the memory event instruction is located in the user data area.

[0013] In some embodiments, the memory event tracking circuit is further configured to: after the program execution ends, perform an operation to generate the final state record of the memory event; wherein, the operation to generate the final state record of the memory event includes: scanning the bitmap to obtain a bitmap scanning result; reading the final state memory timestamp from the memory timestamp according to the bitmap scanning result and the memory timestamp table; reading the final state memory value from the corresponding memory data address in the memory data address region according to the bitmap scanning result; and writing the memory data address, the final state memory value, and the final state memory timestamp into the memory event final state record result region according to a preset width to generate the final state record of the memory event.

[0014] In some embodiments, the auxiliary trajectory generation circuit includes: a register event tracking circuit connected to the preprocessing circuit, used to track register event instructions in the program, so as to record the register timestamps corresponding to the register event instructions in a register timestamp table.

[0015] In some embodiments, the register event tracking circuit includes: a register timestamp array connected to the instruction pipeline circuit, used to track register event instructions in the program and store the register timestamps corresponding to the register event instructions.

[0016] In some embodiments, the register event tracking circuit is further configured to maintain the register timestamp corresponding to the register event instruction based on the instruction type and retirement instruction count corresponding to the register event instruction.

[0017] In some embodiments, the register event tracking circuit is further configured to, when there are at least two identical register indices corresponding to the register event instruction, select one of the register timestamps corresponding to the at least two identical register indices for maintenance according to a preset priority.

[0018] In some embodiments, the trajectory processing circuit includes: a register file located in the processor core and connected to the instruction pipeline circuit, the register file being used to store register business data; the register event tracing circuit is further used to: after the program execution ends, perform an operation to generate the register event final state record; wherein, the operation to generate the register event final state record includes: reading the final state register timestamp from the register timestamp table and reading the final state register value from the register file; writing the final state register timestamp and the final state register value into the register event final state record result area to generate the register event final state record.

[0019] In some embodiments, the memory event tracking circuit is further configured to determine whether to perform the operation of generating the memory event final state record based on a second preset condition before performing the operation of generating the memory event final state record after the program execution ends, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0020] In some embodiments, the register event tracking circuit is further configured to determine whether to perform the operation of generating the register event final state record based on a second preset condition before performing the operation of generating the register event final state record after the program execution ends, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0021] 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) including the processor described in the first aspect, 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 an auxiliary trajectory record corresponding to the program; and a proof circuit for acquiring the proof trajectory record and the auxiliary trajectory record, and after generating proof data corresponding to the proof trajectory record and the auxiliary trajectory record, returning the proof data to the host computer.

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

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

[0024] In some embodiments, the processor 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 and the auxiliary trajectory record corresponding to the program, so as to start the proof circuit through the host.

[0025] 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.

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

[0027] Thirdly, this application provides a trajectory generation method, comprising: processing instructions to be processed in a program and generating at least one proof trajectory record; during the execution of the program, tracing the instructions in the program to generate a memory event final state record and a register event final state record, wherein the memory event final state record and the register event final state record are used to construct an auxiliary trajectory record to prove the execution process of the program together with the at least one proof trajectory record.

[0028] In some embodiments, tracing the instructions in the program during program execution includes: obtaining instruction tracing information corresponding to the instructions, and performing multi-stage pipeline preprocessing on the instruction tracing information in parallel with the process of generating the at least one proof trajectory record based on the instruction tracing information, so as to obtain a preprocessing result corresponding to each proof trajectory record.

[0029] In some embodiments, the multi-stage pipeline preprocessing of the instruction trace information includes: filtering the user program area, identifying the instruction type, masking the termination instruction, and counting the retirement instruction based on the instruction trace information.

[0030] In some embodiments, when the result of the instruction type identification is a memory event instruction, the memory access address corresponding to the memory event instruction is calculated based on the instruction trace information.

[0031] In some embodiments, when the result of the instruction type identification is a preset program end instruction, the program is determined to have ended according to a first preset condition, wherein the first preset condition includes at least one of multi-level pipeline consistency, multi-cycle debouncing, and data storage request.

[0032] In some embodiments, memory event instructions in the program are tracked to set the bitmap corresponding to the memory event instruction and record the memory timestamp corresponding to the memory event instruction in a memory timestamp table.

[0033] In some embodiments, when the memory access address corresponding to the memory event instruction is located in the user data area, the memory event instruction is traced.

[0034] In some embodiments, after the program execution is completed, an operation to generate the final state record of the memory event is performed; wherein, the operation to generate the final state record of the memory event includes: scanning the bitmap to obtain a bitmap scanning result; reading the final state memory timestamp from the memory timestamp according to the bitmap scanning result and the memory timestamp table; reading the final state memory value from the corresponding memory data address in the memory data address region according to the bitmap scanning result; and writing the memory data address, the final state memory value, and the final state memory timestamp into the memory event final state record result region according to a preset width to generate the final state record of the memory event.

[0035] In some embodiments, register event instructions in the program are tracked, and the register timestamps corresponding to the register event instructions are recorded in a register timestamp table.

[0036] In some embodiments, the register timestamp corresponding to the register event instruction is maintained according to the instruction type and retirement instruction count corresponding to the register event instruction.

[0037] In some embodiments, when there are at least two identical register indices corresponding to the register event instruction, a register timestamp is selected from the register timestamps corresponding to the at least two identical register indices for maintenance according to a preset priority.

[0038] In some embodiments, after the program execution is completed, an operation to generate the final state record of the register event is performed; wherein, the operation to generate the final state record of the register event includes: reading the final state register timestamp from the register timestamp table and reading the final state register value from the register file; writing the final state register timestamp and the final state register value into the register event final state record result area to generate the register event final state record.

[0039] In some embodiments, before performing the operation of generating the memory event final state record after the program finishes execution, it is determined whether to perform the operation of generating the memory event final state record according to a second preset condition, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0040] In some embodiments, before performing the operation of generating the register event final state record after the program execution ends, it is determined whether to perform the operation of generating the register event final state record according to a second preset condition, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0041] Fourthly, this application provides a system-on-a-chip including the processor described in the first aspect above, or for implementing the method described in the third aspect above.

[0042] The beneficial effects of this application are as follows: Through the coordinated operation of the trajectory processing circuit and the auxiliary trajectory generation circuit, the trajectory processing circuit captures the entire state transition process natively during instruction execution based on hardware logic and generates a proof trajectory record. This record fully depicts the numerical and temporal characteristics of each architectural state change through instruction context fields, old and new state value fields, and old and new state timestamp fields, providing fine-grained procedural evidence for the backend proof system. Simultaneously, the auxiliary trajectory generation circuit performs lightweight tracking of state changes involving memory and registers based on the same instruction stream during program execution, capturing only access markers and timing information. After program execution, it outputs the final state records of memory events and register events, and constructs the auxiliary proof trajectory record. This lightweight final state tracking mechanism significantly reduces the total amount of tracking data, effectively reducing the bandwidth consumption of on-chip cache and off-chip storage subsystems, and alleviating the performance limitations imposed by the memory wall. Both types of trajectories share a unified global timing benchmark, which can ensure that the final state of the program derived from the proof trajectory record is completely consistent with the actual execution state of the hardware through cross-validation. Furthermore, it can synchronously output procedural proof data and result auxiliary data without inserting additional scan instructions after program execution, thus avoiding the occupation of the processor's front-end and back-end execution units by scan instructions. From a hardware performance perspective, the parallel and independent operation of the trajectory processing circuit and the auxiliary trajectory generation circuit completely separates the generation of procedural evidence from the generation of outcome evidence into dedicated hardware logic. This does not interfere with the out-of-order execution and resource scheduling of the main processor core, significantly reducing the number of instruction cycles per instruction and improving instruction-level parallel throughput. At the same time, the compact data structure of the final state record reduces the power consumption overhead of writing and transmitting trajectory data. The cross-verification mechanism is completed in real time at the hardware level, eliminating the need for repeated calculations or retrying due to the disconnect between procedural and outcome evidence. This significantly shortens the verification latency of the back-end proof system, improves the real-time response and operational efficiency of the entire on-chip system, and effectively solves the problems of insufficient credibility of final state data and the disconnect between procedural and outcome evidence. It balances the credibility, completeness, and execution efficiency of trajectory generation, achieving hardware performance enhancement across the entire chain from state tracking and evidence generation to proof verification. Attached Figure Description

[0043] 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.

[0044] Figure 1 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 1 ; Figure 2 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 2 ; Figure 3This is a schematic diagram of the processor structure in some embodiments of this application. Figure 3 ; Figure 4 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 4 ; Figure 5 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 5 ; Figure 6 This is a schematic diagram of the structure of a zero-knowledge proof system according to some embodiments of this application. Figure 1 ; Figure 7 This is a schematic diagram of the structure of a zero-knowledge proof system according to some embodiments of this application. Figure 2 ; Figure 8 This is a schematic diagram of the zero-knowledge proof process for some embodiments of this application. Figure 1 ; Figure 9 This is a schematic diagram of the zero-knowledge proof process for some embodiments of this application. Figure 2 ; Figure 10 This is a schematic flowchart of a trajectory generation method according to some embodiments of this application; Figure 11 This is a schematic diagram of the process for generating auxiliary trajectory records according to some embodiments of this application; Figure 12 This is a schematic diagram of the final state record collection process in some embodiments of this application; Figure 13 This is a schematic diagram of the memory timestamp address mapping process in some embodiments of this application; Figure 14 This is a schematic diagram of the structure of a system-on-a-chip according to some embodiments of this application. Detailed Implementation

[0045] 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.

[0046] 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.

[0047] 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.

[0048] With the rapid implementation of blockchain applications such as scaling, privacy transactions, verifiable computation, and decentralized off-chain execution, the computational scale and input data volume of the procedures to be proven are growing exponentially. The computational overhead of the proof generation process has become a core bottleneck for system throughput. During the proof generation phase, the following defects are common: final state data in memory and registers are generally obtained through offline reverse engineering or software scanning. This approach not only introduces additional overhead and increases processing latency but also fails to detect dirty data not written back in the write-back cache, leading to a misalignment between the final state value and the actual hardware execution state, causing backend proof failure.

[0049] To address this, this application provides a processor comprising: a trajectory processing circuit for processing instructions to be processed in a program; and an auxiliary trajectory generation circuit connected to the trajectory processing circuit for tracing the instructions in the program during program execution to generate a memory event final state record and / or a register event final state record, wherein the memory event final state record and the register event final state record are used to assist in proving the execution process of the program. This effectively solves the problems of insufficient credibility of final state data and the disconnect between process evidence and result evidence, balancing the credibility, completeness, and execution efficiency of trajectory generation.

[0050] 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.

[0051] Please see Figure 1 , Figure 1 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 1The processor 100 includes: a trajectory processing circuit 110 for processing instructions to be processed in the program and generating at least one proof trajectory record; and an auxiliary trajectory generation circuit 120 connected to the trajectory processing circuit 110 for tracing instructions in the program during program execution to generate memory event final state records and register event final state records, wherein the memory event final state records and register event final state records are used to construct auxiliary trajectory records to prove the execution process of the program along with at least one proof trajectory record.

[0052] The processor 100 can be an integrated circuit chip used to execute a program and generate a proof track record and an auxiliary track record corresponding to the program. The program can be a user program, and the program includes at least one instruction. The proof track record and / or auxiliary track record can be used for zero-knowledge proofs, or for proofs in other cryptographic proofs or secure computing fields.

[0053] In one implementation, the processor 100 may be a CPU (Central Processing Unit), specifically implemented based on a reduced instruction set architecture. In a specific embodiment, the processor 100 may be a RISC-V (Reduced Instruction Set Computer-Five) based processor, configured to execute programs and generate corresponding proof trajectory records and auxiliary trajectory records, wherein the program may be an executable program conforming to the RISC-V instruction set architecture.

[0054] The instructions to be processed in the program can be instructions that have not yet been acquired and executed by the trajectory processing circuit 110. In one example, the program includes multiple instructions, which are acquired and executed instruction by instruction by the trajectory processing circuit 110. For example, the trajectory processing circuit 110 acquires and executes the instructions in the program instruction by instruction through a five-stage pipeline.

[0055] The evidence trajectory record can be a data form of instruction execution evidence structure. It is a data set that is automatically captured and constructed by the trajectory processing circuit 110 from the relevant data generated by the execution instruction, and is used to record and prove the execution process and result of the instruction.

[0056] In one example, the proof trajectory record includes at least an instruction context field, a state old value field, a state new value field, a state old timestamp field, and a state new timestamp field. The instruction context field indicates the basic identification information of the instruction execution event corresponding to this state transition, providing an index for the backend proof system to locate instruction semantics and correlate preceding and following state transitions. Examples include the program counter, instruction code, global instruction identifier, and instruction type identifier. The state old value field and state new value field indicate the numerical changes in the architectural state transition caused by this instruction execution, allowing the backend proof system to verify the legality of the numerical calculations during the state transition. For example, for ordinary arithmetic instructions, the state old value field includes the old values ​​of the first source register, the second source register, and the destination register, while the state new value field includes the destination register write-back value. The old and new timestamp fields are used to indicate the timing changes of the current architectural state transition, allowing the backend verification system to verify the timing monotonicity of the state transition and the legality of cross-instruction state dependencies. For example, for ordinary arithmetic instructions, the old timestamp field includes the old timestamp corresponding to the first source register, the old timestamp corresponding to the second source register, and the old timestamp corresponding to the destination register. The new timestamp field includes the timestamp when reading the first source register, the timestamp when reading the second source register, and the timestamp when writing a value to the destination register.

[0057] At least one proof trajectory record corresponds to a program. For example, if the program includes instructions A, B, and C, the trajectory processing circuit 110 processes instructions A, B, and C sequentially, generating three proof trajectory records corresponding to instructions A, B, and C. These three proof trajectory records can characterize the state changes during program execution. Alternatively, if the program includes instructions A, B, and C, where instruction B is an instruction whose execution process and result do not need to be proven, the trajectory processing circuit 110 processes instructions A, B, and C sequentially, generating two proof trajectory records corresponding to instructions A and C. These two proof trajectory records can characterize the state changes during program execution.

[0058] A memory event final state record can be a final state data record related to a memory event at the memory word granularity after program execution. For example, if a program includes instructions A, B, and C, and instructions A, B, and C sequentially perform read and / or write operations on the same memory address, then after program execution, the memory value corresponding to the last read or write operation at that memory address is the memory final state value, which is the final state data record related to the memory event. In one example, if instruction C is the last instruction in the program, then the memory value corresponding to the last read or write operation performed by instruction C on that memory address is the memory final state value, which is the final state data record related to the memory event.

[0059] Similarly, the timestamp corresponding to the last read or write operation on a memory address in the program is the memory final state timestamp.

[0060] The final state data record related to the memory event includes at least one of the following: memory address, memory final state value corresponding to the memory address, and memory final state timestamp corresponding to the memory address.

[0061] Understandably, if a program involves read and / or write operations to multiple memory addresses, the memory event final state record can include multiple sets of final state data records. Each set of records represents the corresponding memory final state after program execution, thus representing program-level static state data. For example, one set of final state data records includes the memory address, the memory final state value corresponding to the memory address, and the memory final state timestamp corresponding to the memory address, and the memory addresses in each set of final state data records are different. Furthermore, for memory addresses that the program did not read or write, the memory address and its corresponding memory value and timestamp can still be output, for example, set to a preset value and output.

[0062] A register event final state record can be a final state data record related to a register event at the register level after program execution. For example, if a program includes instructions A, B, and C, and instructions A, B, and C sequentially perform read and / or write operations on the same register, then after program execution, the register value corresponding to the last read or write operation on that register is the register final state value, which is the final state data record related to the register event. In one example, if instruction C is the last instruction in the program, then the register value corresponding to the last read or write operation performed by instruction C on that register is the register final state value, which is the final state data record related to the register event.

[0063] Similarly, the timestamp corresponding to the last read or write operation on the register in the program is the register final state timestamp.

[0064] Among them, the final state data record related to the register event includes at least the register final state value and the register final state timestamp corresponding to the register final state value.

[0065] Understandably, if a program involves read and / or write operations on multiple registers, the register event final state record can include multiple sets of final state data records to characterize program-level static state data. For example, one set of final state data records includes the register final state value and the register final state timestamp corresponding to the register final state value, and each set of final state records corresponds to a different register. Furthermore, for registers that the program has not read or written, the corresponding register value and register timestamp can still be output, for example, set to a preset value and output.

[0066] Auxiliary trajectory records can be a data form of program execution evidence structure. They are data sets automatically captured and constructed by the auxiliary trajectory generation circuit 120 from relevant data generated by the executed program, used to record and assist in proving the program execution result. Among them, the memory event final state records and register event final state records in the auxiliary trajectory records serve as program-level result evidence and can be used for consistency verification with the program execution result represented by at least one proof trajectory record, ensuring that the program final state derived from at least one proof trajectory record matches the actual hardware final state.

[0067] In one implementation, the auxiliary trajectory generation circuit 120 traces instructions in the program to generate memory event final state records and register event final state records corresponding to the program. For example, the program includes instructions A, B, and C. When instruction A is executed, the auxiliary trajectory generation circuit 120 captures state data related to instruction A; when instruction B is executed, the auxiliary trajectory generation circuit 120 captures state data related to instruction B; when instruction C is executed, the auxiliary trajectory generation circuit 120 captures state data related to instruction C. Further, if instructions A, B, and C involve both memory events (such as memory read and / or write operations) and register events (such as register read and / or write operations), then memory event final state records and register event final state records corresponding to the program are generated. In one example, capturing state data related to instructions can be done by capturing the state data generated by the executed instructions during the process of the trajectory processing circuit 110 generating the proof trajectory record. For status data, if the instruction involves a memory event, the status data may include an access flag (such as a bitmap) to identify the accessed memory address and the corresponding memory timestamp. The access flag is used to mark the memory address accessed by the memory event, or to mark the memory word being accessed, so that the corresponding memory final state value can be obtained according to the marked memory address after the program execution ends. The memory timestamp also corresponds to the memory address. If the instruction involves a register event, the status data may include a register timestamp, and the register final state value can be obtained together after the program execution ends.

[0068] In the above scheme, through the coordinated operation of the trajectory processing circuit 110 and the auxiliary trajectory generation circuit 120, the trajectory processing circuit 110 captures the entire state transition process natively during instruction execution using hardware logic and generates a proof trajectory record. This record fully characterizes the numerical and temporal features of each architectural state change through instruction context fields, old and new state value fields, and old and new state timestamp fields, providing fine-grained procedural evidence for the backend proof system. Simultaneously, the auxiliary trajectory generation circuit 120 performs lightweight tracking of state changes involving memory and registers based on the same instruction stream during program execution, capturing only access markers and timing information. After program execution, it outputs the final state records of memory events and register events, and constructs the auxiliary proof trajectory record. This lightweight final state tracking mechanism significantly reduces the total amount of tracking data, effectively reducing the bandwidth usage of on-chip cache and off-chip storage subsystems, and alleviating the limitation of memory walls on system performance. Both types of trajectories share a unified global timing benchmark, which can ensure that the final state of the program derived from the proof trajectory record is completely consistent with the actual execution state of the hardware through cross-validation. Furthermore, it can synchronously output procedural proof data and result auxiliary data without inserting additional scan instructions after program execution, thus avoiding the occupation of the processor's front-end and back-end execution units by scan instructions. From a hardware performance perspective, the parallel and independent operation of the trajectory processing circuit 110 and the auxiliary trajectory generation circuit 120 completely separates the generation of procedural evidence from the generation of outcome evidence into dedicated hardware logic. This does not interfere with the out-of-order execution and resource scheduling of the main processor core, significantly reducing the number of instruction cycles per instruction and improving instruction-level parallel throughput. At the same time, the compact data structure of the final state record reduces the power consumption overhead of writing and transmitting trajectory data. The cross-verification mechanism is completed in real time at the hardware level, eliminating the need for repeated calculations or retrying due to the disconnect between procedural evidence and outcome evidence. This significantly shortens the verification latency of the back-end proof system, improves the real-time response and operational efficiency of the entire on-chip system, and effectively solves the problems of insufficient credibility of final state data and the disconnect between procedural evidence and outcome evidence. It balances the credibility, completeness, and execution efficiency of trajectory generation, achieving hardware performance enhancement across the entire chain from state tracking and evidence generation to proof verification.

[0069] Please see Figure 2 , Figure 2 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 2 The trajectory processing circuit 110 includes a processor core 111, which includes an instruction pipeline circuit 1111. The instruction pipeline circuit 1111 is used to execute the instructions to be processed in the program instruction by instruction and generate at least one evidence trajectory record for each instruction.

[0070] Processor core 111 is one of the core components of trajectory processing circuit 110 / processor 100. In one example, processor 100 can be modified based on Rocket Chip RV32IM sequential single-issue core, that is, processor core 111 is a sequential single-issue core based on Rocket Chip RV32IM.

[0071] The instruction pipeline circuit 1111 can be an integrated circuit that includes multiple functional parts. The instruction pipeline circuit 1111 is the core circuit for executing instructions in the trace processing circuit 110 / processor 100.

[0072] In one example, processor 100 can be modified from Rocket Chip RV32IM sequential single-issue core, and instruction pipeline circuit 1111 is configured to process instructions sequentially according to the RISC-V five-stage pipeline, where the five-stage pipeline can correspond to five functional parts, namely instruction fetch, decode, execute, memory access and write back.

[0073] In one implementation, the instruction pipeline circuit 1111 executes the instructions to be processed in the program instruction by instruction, and generates at least one proof trajectory record for each instruction. For example, the program includes instructions A, B, and C. The instruction pipeline circuit 1111 sequentially acquires and executes instructions A, B, and C, and uses the instruction-related data generated during instruction execution to fill preset fields. The field filling process follows the order in which the instructions are acquired, thereby generating three proof trajectory records one by one. Instructions A, B, and C retire instruction by instruction in the order they are acquired and executed. In one example, using the instruction-related data generated during instruction execution to fill preset fields includes: data for filling the instruction context field, data for filling the old state value field and the new state value field, and data for filling the old state timestamp field and the new state timestamp field. The global instruction identifier in the instruction context field can be used as a unique and monotonically increasing identifier to identify the retirement order of each instruction.

[0074] In the above scheme, the processor core 111 and instruction pipeline circuit 1111 built into the trajectory processing circuit 110 realize the orderly processing of program instructions and trajectory generation. The instruction pipeline circuit 1111 is configured to execute the instructions to be processed in sequence, ensuring strict synchronization between the instruction execution flow and the trajectory recording flow in terms of timing, eliminating the uncertainty of the execution state at the hardware architecture level. On this basis, the instruction pipeline circuit can generate corresponding proof trajectory records one by one with instructions as the basic unit, so that each record can be accurately mapped to a specific instruction execution event. This synchronous generation mechanism based on pipeline hardware not only ensures the complete capture of state transitions in the numerical dimension of the proof trajectory record, but also ensures its global monotonic consistency in the temporal dimension, providing a high-fidelity, low-ambiguity procedural evidence foundation for the back-end proof system.

[0075] Please continue reading. Figure 2 The auxiliary trajectory generation circuit 120 is located outside the processor core 111. The auxiliary trajectory generation circuit 120 includes a preprocessing circuit 121, which is connected to the instruction pipeline circuit 1111. It is used to receive instruction tracing information output by the instruction pipeline circuit and, based on the instruction tracing information, perform multi-level pipeline preprocessing on the instruction tracing information in parallel with the process of generating at least one proof trajectory record one by one by the instruction pipeline circuit 1111, so as to obtain the preprocessing result corresponding to each proof trajectory record.

[0076] Instruction trace information can be field data generated during the execution of instructions by the instruction pipeline circuit 1111, used to construct the proof trajectory record. For example, the proof trajectory record may include fields such as: pc (program counter), used to record the program counter address of the instruction; inst (instruction code), used to record the opcode and operand code of the instruction; zk_clk (global instruction identifier) ​​or base_timestamp derived from zk_clk according to a preset offset, used to record the position of the instruction in the global instruction clock sequence number column. Other fields that may be included in the proof trajectory record can be referred to the description in the above embodiments, and will not be listed here. That is to say, the instruction trace information / field information can be reused from the field data generated during instruction execution used to construct the proof trajectory record.

[0077] Optionally, the instruction trace information can be expanded as needed, based on the field data of the reused proof trace record. In one example, the instruction trace information includes at least: a program_finished field to indicate whether the program has ended; a dcache_flushed field to indicate whether the data cache has been flushed; rs1_val (source register 1 value); rd_wen (destination register write enable) to indicate whether there is a valid destination register write-back operation in the current instruction; rd_idx (destination register index) to identify the index of the destination register to be written; rd_val (destination register write-back value) to identify the value of the destination register to be written back; rf_valid (register file scan valid flag) to indicate whether the register file scan after the program ends is valid; and rf_data (register file scan data) to scan register values ​​from the register file when rf_valid is valid.

[0078] Multi-stage pipeline preprocessing can be a streaming process that performs multiple serial processing stages on a single instruction, according to the output order of the instruction trace information corresponding to the instruction.

[0079] Continuing with instructions A, B, and C as examples, instruction A corresponds to instruction trace information A1, instruction B corresponds to instruction trace information B1, and instruction C corresponds to instruction trace information C1. Multi-stage pipeline preprocessing preprocesses the instruction trace information A1, B1, and C1 sequentially output by the instruction pipeline circuit 1111. More specifically, multi-stage pipeline preprocessing can be three-stage pipeline preprocessing, consisting of first-stage preprocessing, second-stage preprocessing, and third-stage preprocessing. The step-by-step preprocessing can involve first-stage preprocessing of instruction trace information A1, followed by second-stage preprocessing of instruction trace information A1 and then first-stage preprocessing of instruction trace information B1. After second-stage preprocessing of instruction trace information A1, third-stage preprocessing of instruction trace information A1 and then second-stage preprocessing of instruction trace information B1, and finally first-stage preprocessing of instruction trace information C1. In one example, Level 1 preprocessing is used to receive and extract key data from the instruction trace information; Level 2 preprocessing is used to parse and compute the key data; and Level 3 preprocessing is used to structure the preprocessing results for output.

[0080] In one embodiment, the preprocessing circuit 121 and the trajectory processing circuit 110 operate in parallel. For example, when an instruction in the instruction pipeline circuit 1111 retires, instruction tracing information corresponding to that instruction is sent to the preprocessing circuit 121. The instruction pipeline circuit 1111 constructs a proof trajectory record based on the instruction tracing information. At the same time, the preprocessing circuit 121 performs multi-stage pipeline preprocessing based on the received instruction tracing information. The preprocessing circuit 121 and the trajectory processing circuit 110 share the same retirement event trigger source, thereby ensuring timing consistency while operating in parallel. For example, a mapping relationship is established between the proof trajectory record and the preprocessing result through a global instruction identifier. Similarly, this mapping relationship is maintained between the proof trajectory record and the auxiliary trajectory record.

[0081] In the above scheme, the auxiliary trajectory generation circuit 120 is externalized to the processor core 111, achieving physical decoupling between the generation of the proof trajectory and the auxiliary trajectory, avoiding intrusion into the critical timing path of the processor core 111, and ensuring that the main processing performance is not affected by the auxiliary logic. The preprocessing circuit 121 is based on the same instruction retirement event and is executed in parallel with the generation process of each proof trajectory. By sharing a global timing benchmark, it ensures that the preprocessing results and the proof trajectory records are strictly corresponding in timing, providing cross-verifiable dual-track evidence for the backend proof. A streaming multi-level preprocessing architecture is adopted, with single instruction tracing information as the smallest processing unit, and progressively advancing step by step. High-throughput real-time preprocessing is achieved without blocking instruction retirement, transforming unstructured raw hardware signals into directly consumable information, significantly reducing the generation overhead of the auxiliary trajectory. This provides a low-latency, highly reliable final state context for the backend proof at the hardware level, effectively avoiding the state pollution and performance loss problems caused by software scanning.

[0082] In some embodiments, the preprocessing circuit 121 is also used to perform user program area filtering, instruction type identification, termination instruction masking, and retirement instruction counting based on instruction trace information.

[0083] User program area filtering can be used to filter instructions outside the user program area. For example, instruction trace information includes PC. The preprocessing circuit 121 compares the PC with a preset user program area address range. When the PC falls within the preset user program area address range, the instruction is determined to be a user program area instruction and is retained. When the PC falls outside the preset user program area address range, the instruction is determined to be a non-user program area instruction and is filtered.

[0084] Instruction type identification can be performed by identifying the type of instruction based on instruction trace information. For example, the preprocessing circuit 121 decodes the opcode in the instruction trace information (inst) and obtains the instruction category based on the decoding result. In one example, the instruction category includes at least ordinary arithmetic instructions, load instructions, and store instructions.

[0085] End instruction masking can be achieved by identifying whether the current instruction is an end instruction based on instruction trace information. For example, the preprocessing circuit 121 matches the 'inst' in the instruction trace information with a preset end instruction code. If the match is successful, the current instruction is determined to be an end instruction, and a masking signal is generated to prevent instruction trace information following the end instruction from continuing to enter the preprocessing path. In one example, the preset end instruction code is 0x0000006F.

[0086] The retirement instruction count can be a global instruction retirement count maintained by the preprocessing circuit 121. Whenever the preprocessing circuit 121 processes a valid retirement instruction trace, it increments the count and appends the current count value as the global instruction identifier zk_clk or its derived base_timestamp to the preprocessing result, thereby sharing the same instruction retirement event with the instruction pipeline circuit 1111.

[0087] In one implementation, user program area filtering, instruction type identification, termination instruction masking, and retirement instruction counting can be steps in a multi-stage pipeline preprocessing. Taking a three-stage pipeline preprocessing as an example, user program area filtering, instruction type identification, and termination instruction masking can be performed in the second stage of preprocessing; and retirement instruction counting can be performed in the third stage of preprocessing.

[0088] In the above scheme, runtime metadata maintenance and core execution flow are decoupled by acquiring instruction tracing information. Based on hardware-level parsing of the program counter and instruction encoding, it accurately defines execution boundaries and dynamically generates control flow shielding windows, effectively eliminating noisy data. Simultaneously, by maintaining a global retirement count shared with the core, it ensures strict temporal synchronization between auxiliary trajectories and proof trajectories, providing a highly reliable, low-latency verification context for backend proofs with zero additional core overhead.

[0089] In some embodiments, the preprocessing circuit 121 is further configured to calculate the memory access address corresponding to the memory event instruction based on the instruction trace information when the result of instruction type identification is a memory event instruction.

[0090] Taking the pretreatment of a three-stage production line as an example: In the first-level preprocessing, key fields of the instruction trace information corresponding to the instruction are latched, and some fields are expanded, such as pc, inst, rs1_val, rd_wen, rd_idx, rd_val, program_finished, dcache_flushed, and zk_clk.

[0091] In the second-level preprocessing, the instruction type is decoded and identified based on inst. When a memory event instruction is identified (such as a load instruction or a store instruction), the memory access address can be calculated. For example, for a load instruction, it can be obtained from rs1_val and an I-type immediate value, and for a store instruction, it can be obtained from rs1_val and an S-type immediate value. The I-type immediate value and the S-type immediate value can be extracted from inst.

[0092] Additionally, it determines whether the current instruction is the last valid instruction in the program based on whether program_finished is valid, and checks whether dcache_flushed is valid. If valid, it then performs memory event processing based on the memory access address to ensure memory consistency.

[0093] In the three-level preprocessing, the mapping relationship between the destination register index and the write-back value is constructed based on rd_wen, rd_idx, and rd_val. Whether to output the mask signal is determined based on whether program_finished is valid. zk_clk is incremented. Finally, the preprocessing results are output in a structured manner, such as instruction type, memory access address, user program area filtering flag, destination register write-back information, etc.

[0094] In the above scheme, the hardware-level parsing of instruction tracing information by the preprocessing circuit 121 enables the native derivation of the memory access address of the memory event instruction, realizing the real-time calculation of the memory access address without software intervention. This reduces core performance overhead while avoiding the risks of address resolution delay and state inconsistency that may be introduced by software simulation.

[0095] In some embodiments, the preprocessing circuit 121 is further configured to determine whether the program has ended based on a first preset condition when the result of instruction type identification is a preset program end instruction, wherein the first preset condition includes at least one of multi-level pipeline consistency, multi-cycle debouncing, and data storage request.

[0096] Continuing with the example of the three-stage pretreatment process described above: In the secondary preprocessing stage, the preprocessing circuit 121 decodes inst. When it detects that the current instruction matches the preset end instruction code, it is initially determined to be a potential program end event. In order to avoid misjudgment caused by transient glitches or bit errors, the recognition result of the end instruction must be consistent over multiple consecutive clock cycles and / or program_finished must be consistent over multiple consecutive cycles before the end event is determined to be valid.

[0097] And / or, in the third-level preprocessing stage, the preprocessing circuit 121 performs multi-level pipeline consistency checks. Since instruction trace information is passed step-by-step through the three-level pipeline, the preprocessing circuit 121 checks whether the processing results of each pipeline stage for the instruction are consistent. For example, the instruction type identification result (end instruction) of the second-level preprocessing must match the logical determination result based on the program_finished signal in the third-level preprocessing. Simultaneously, the preprocessing circuit 121 monitors the completion status of data storage requests, i.e., checks the validity of the dcache_flushed signal. Since a forced flush of the data cache usually accompanies program termination, the preprocessing circuit 121 only confirms program termination after confirming that dcache_flushed is valid (indicating that all pending data storage requests have been written back to main memory and the memory data is in a consistent state).

[0098] Finally, when the first preset condition is met, the preprocessing circuit 121 generates a shielding signal to prevent noise instructions from subsequent non-user programs from entering the effective preprocessing path.

[0099] The above scheme effectively avoids false termination judgments caused by hardware noise and timing deviations through a multi-dimensional composite verification mechanism for program termination determination. Specifically, cross-processing stage consistency verification eliminates single-point identification biases and improves judgment reliability; steady-state verification at the timing dimension filters out transient signal jitter and avoids invalid instructions interfering with auxiliary trajectory generation; and pre-confirmation of memory consistency ensures that data has been written to disk during judgment, guaranteeing the authenticity of the final state snapshot. This provides precise program execution boundaries for backend proof, significantly reduces invalid verification overhead, and improves the credibility of auxiliary trajectories and overall verification efficiency.

[0100] Please see Figure 3 , Figure 3 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 3 The auxiliary trajectory generation circuit 120 includes a memory event tracking circuit 122, which is connected to the preprocessing circuit 121. It is used to track memory event instructions in the program, set the bitmap corresponding to the memory event instruction, and record the memory timestamp corresponding to the memory event instruction in the memory timestamp table.

[0101] Memory event instructions can be a class of instructions that involve reading and writing memory, such as load instructions and store instructions.

[0102] A bitmap can be a set of binary codes used to mark memory words. Specifically, each bit of the bitmap corresponds to a memory access address and a memory word, used to mark which memory access address and memory word a memory event instruction accessed. For example, a mapping relationship is established between each bit of the bitmap and the access address. When a certain memory access address is accessed, that is, when the memory word corresponding to that memory access address is accessed, the bitmap corresponding to that memory word is set to 1 to mark that the memory word has been accessed. The bitmap can be stored in a bitmap storage plane, specifically in the storage structure of the memory event tracking circuit 122 or in a storage structure outside the processor 100, such as... Figure 3 As shown, the bitmap is stored in the bitmap storage plane of the storage structure outside the processor 100.

[0103] Memory timestamps can be timestamps corresponding to read and write operations of memory event instructions. For example, for a load instruction, it is the timestamp corresponding to the time when a memory value is read from the memory access address; for a store instruction, it is the timestamp corresponding to the time when a memory value is written to the memory access address.

[0104] Specifically, the memory timestamp can be obtained during the execution of the instruction. Taking the load instruction as an example, the trajectory processing circuit 110 constructs a new state timestamp field during the execution of the load instruction: when reading the old value of the first source register, the first timestamp corresponding to this read operation is obtained; when reading the memory value of the memory access address, the second timestamp corresponding to this read operation is obtained; when writing a new value to the destination register, the third timestamp corresponding to this write operation is obtained. The first timestamp, the second timestamp, and the third timestamp are used to construct the new state timestamp field, and the second timestamp can be a memory timestamp.

[0105] In one example, the first, second, and third timestamps are obtained based on the global instruction identifier and according to a preset offset rule. For example, when the global instruction identifier is n, the first, second, and third timestamps are incremented by a preset value in the order of events. That is, the first timestamp is n+n1, the second timestamp is n+n1+n1, and the third timestamp is n+n1+n1+n1.

[0106] The memory timestamp table can be a storage structure indexed by memory word / access address, where each entry stores the timestamp of the most recent valid access to the corresponding memory word / access address. The memory timestamp table can be stored in a memory timestamp storage plane, specifically a storage structure within the memory event tracking circuit 122 or a storage structure outside the processor 100, such as... Figure 3 As shown, the memory timestamp table is stored in the memory timestamp storage plane in the storage structure outside the processor 100.

[0107] In one implementation, the memory event tracking circuit 122 tracks memory event instructions in the program. For example, if instruction A is a load instruction, the memory event tracking circuit 122 obtains the memory access address corresponding to the load instruction, sets the bitmap of the memory word corresponding to the memory access address to 1, and records the timestamp corresponding to the read operation as a memory timestamp in the memory timestamp table when the load instruction reads the memory value from the memory access address.

[0108] In the above scheme, the memory event tracing circuit 122 sets up a bitmap that works in conjunction with the memory timestamp table. By utilizing the bitmap's minimal storage space, it achieves fast indexing and marking of massive memory accesses. It extracts only the timestamp records corresponding to the accessed memory words. While ensuring that the auxiliary trajectory fully reflects the program's memory access behavior, it significantly reduces storage overhead and timing acquisition latency, effectively improving the efficiency of sparse tracing and its adaptability to complex program execution processes.

[0109] In some embodiments, the memory event tracking circuit 122 is further configured to track memory event instructions when the memory access address corresponding to the memory event instruction is located in the user data area.

[0110] The user data area can be a region that stores memory data. For example, a preset user data area address range.

[0111] In one embodiment, after completing instruction type identification and memory access address calculation, the preprocessing circuit 121 determines whether the memory access address falls within a preset user data area address range. If the determination result is that it falls within the range, the preprocessing circuit 121 sends a tracking instruction to the memory event tracking circuit 122; if the determination result is that it falls outside the range, the preprocessing circuit 121 sends a non-tracking instruction to the memory event tracking circuit 122.

[0112] Furthermore, the corresponding memory word index is calculated based on the memory access address, and the bitmap position at that index is set to mark that the memory word in the user data area has been accessed. Additionally, the memory timestamp corresponding to the access time is obtained and written to the corresponding index entry in the memory timestamp table. Thus, memory event instructions can be traced when the memory access address corresponding to the memory event instruction is located in the user data area.

[0113] In the above scheme, the memory event tracing circuit 122 achieves precise hardware-level definition of the tracing range through the interval determination mechanism of the memory access address by the preprocessing circuit 121. It effectively eliminates redundant metadata generated by the access of memory addresses in non-user data areas, reduces storage overhead, and avoids the encroachment of invalid tracing on system resources. This enables the generated auxiliary trajectory to accurately map the operation semantics of the user program on the user data area, and significantly improves the purity and credibility of the backend proof verification context.

[0114] In some embodiments, the memory event tracking circuit 122 is further configured to: after the program execution ends, perform an operation to generate a memory event final state record; wherein, performing the operation to generate a memory event final state record includes: scanning a bitmap to obtain a bitmap scan result; reading a final state memory timestamp from a memory timestamp table according to the bitmap scan result and a memory timestamp table; reading a final state memory value from a corresponding memory data address in a memory data address region according to the bitmap scan result; and writing the memory data address, the final state memory value, and the final state memory timestamp into a memory event final state record result region according to a preset width to generate a memory event final state record.

[0115] In one implementation, the bitmap is scanned to obtain a bitmap scan result. For example, the bitmap is read from a bitmap storage area to obtain the bitmap scan result. In one example, the bitmap scan result is 1001010101.

[0116] In one implementation, the final memory timestamp is read from the memory timestamp table based on the bitmap scan result and the memory timestamp table. For example, if the bitmap scan result is 1001010101, where the memory words corresponding to the first, fourth, sixth, eighth, and tenth bits have been accessed, then the memory access addresses corresponding to the first, fourth, sixth, eighth, and tenth bits are obtained according to the mapping relationship. Finally, the final memory timestamp is read from the memory timestamp table based on the mapping relationship between the memory access addresses and the memory timestamp table.

[0117] The memory data address region can be the address space used to store data, such as the user data area, kernel data area, device mapping area, etc.

[0118] The memory data address can be a memory access address in the user data area.

[0119] In one implementation, the final memory value is read from the corresponding memory data address in the memory data address region based on the bitmap scan result. Continuing with the example of a bitmap scan result of 1001010101, the memory access addresses corresponding to the first, fourth, sixth, eighth, and tenth bits are obtained according to the mapping relationship between the bitmap and the memory access address, and the final memory value is read based on the aforementioned memory access address.

[0120] The memory event final state record result area can be a storage structure within the memory event tracing circuit 122 or a storage structure outside the processor 100, such as... Figure 3 As shown, the memory event final state record result area is located in the storage structure outside the processor 100.

[0121] In one implementation, the memory data address, final memory value, and final memory timestamp are written into the memory event final state record result area according to a preset width to generate a memory event final state record. Continuing with the example of a bitmap scan result of 1001010101, the memory data addresses corresponding to this bitmap scan result are represented by addr1, addr4, addr6, addr8, and addr10, respectively. The final memory values ​​corresponding to the aforementioned memory data addresses are represented by data1, data4, data6, data8, and data10, respectively. The final memory timestamps corresponding to the aforementioned memory data addresses are represented by timestamp1, timestamp4, timestamp6, timestamp8, and timestamp10, respectively. Addr1, data1, and timestamp1 are concatenated according to a preset width and written into the memory event final state record result area. Similarly, addr4, data4, and timestamp4 are concatenated according to a preset width and written into the memory event final state record result area. ... and addr10, data10, and timestamp10 are concatenated according to a preset width and written into the memory event final state record result area. Thus, five sets of records are recorded in the memory event final state record result area. In one example, the memory event final state record result area can be divided into several data blocks, each data block holding a fixed number of records, and the output scale is demonstrated to the backend by the actual number of data blocks and the number of valid records.

[0122] Taking addr1, data1, and timestamp1 as an example, concatenating them according to a preset width can be done by concatenating the memory data address, final memory value, and final memory timestamp in a preset order and with a preset width. The preset order can be addr1, data1, and timestamp1, and the preset width can be 128 bits. This results in a record set as: {addr1[31:0], data1[31:0], timestamp1[63:0]}. Here, addr1[31:0] represents a 32-bit memory data address, data1[31:0] represents a 32-bit final memory value, and timestamp1[63:0] represents a 64-bit final memory timestamp.

[0123] In one implementation, the memory event tracking circuit 122 acquires the initial state memory value and the initial state memory timestamp before program execution. The initial state memory value can be the memory value corresponding to each address in the user data area, and the initial state memory timestamp can be the memory timestamp corresponding to the memory value at each address in the user data area. The initial state memory value and the initial state timestamp can be used to verify the memory state changes before and after program execution by recording the verification trajectory. Further, after program execution, the memory event tracking circuit 122 can, based on the bitmap scan results, retain only the memory values ​​at the accessed memory addresses and their corresponding memory timestamps as the initial state memory value and initial state memory timestamp.

[0124] In the above scheme, the memory event tracing circuit 122 accurately locates the validly accessed memory words after the program ends through a bitmap-guided sparse acquisition mechanism, completely avoiding the performance loss caused by full memory scanning. By fusing memory data addresses, final state memory values, and final state memory timestamps to construct a fixed-width structured record, a complete evidence chain of address-state-time sequence is formed at the hardware level. While significantly reducing the storage overhead and transmission bandwidth of auxiliary trajectories, it provides a low-latency, highly reliable verification context for backend proof through a standardized data encapsulation format, effectively resolving the contradiction between runtime metadata maintenance and final state consistency verification.

[0125] Please see Figure 4 , Figure 4 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 4 The auxiliary trajectory generation circuit 120 includes a register event tracking circuit 123, which is connected to the preprocessing circuit 121 and is used to track register event instructions in the program so as to record the register timestamps corresponding to the register event instructions in the register timestamp table.

[0126] Register event instructions can be a class of instructions that involve reading and writing back registers, such as ordinary arithmetic instructions and load instructions.

[0127] Register timestamps can be timestamps corresponding to register read and write-back operations. Taking ordinary arithmetic instructions as an example, the timestamps corresponding to reading register values ​​and writing register values ​​are register timestamps.

[0128] Specifically, the register timestamp can be obtained during the execution of the instruction. Taking a normal arithmetic instruction as an example, the trajectory processing circuit 110 constructs a new state timestamp field during the execution of the normal arithmetic instruction: when reading the old value of the first source register, the first timestamp corresponding to this read operation is obtained; when reading the old value of the second source register, the second timestamp corresponding to this read operation is obtained; when writing a new value to the destination register, the third timestamp corresponding to this write operation is obtained. The first timestamp, the second timestamp, and the third timestamp are used to construct the new state timestamp field, and the first timestamp, the second timestamp, and the third timestamp can be register timestamps.

[0129] The register timestamp table can be a register-index-addressable storage structure, where each entry stores the timestamp of the most recent valid read or write-back of the corresponding register. The register timestamp table can be stored in a register timestamp storage plane, specifically in a storage structure within the register event tracking circuit 123 or in a storage structure outside the processor 100, such as... Figure 4 As shown, the register timestamp table can be located in a memory structure outside the processor 100.

[0130] In one implementation, the register event tracking circuit 123 tracks register event instructions in the program. For example, instruction B is a normal arithmetic instruction. The register event tracking circuit 123 obtains the register index corresponding to the normal arithmetic instruction and records the timestamp corresponding to the read or write operation as a register timestamp in the register timestamp table when the normal arithmetic instruction reads a register value or writes a value to a register.

[0131] Taking 32 register indices from x0 to x31 as an example, when reading the register value corresponding to x1, the register timestamp corresponding to the read operation of x1 is stored in the register timestamp table. When reading the register value corresponding to x2, the register timestamp corresponding to the read operation of x2 is stored in the register timestamp table. When writing a value to the register corresponding to x3, the register timestamp corresponding to the write operation of x3 is stored in the register timestamp table.

[0132] In the above scheme, the register event tracing circuit 123 sets up a register timestamp table that is addressed by register index. It uses the minimal storage space of the register timestamp table to quickly index and mark register write-back events. Only the timestamp record corresponding to the write-back destination register is extracted. While ensuring that the auxiliary trajectory fully reflects the program register write-back behavior, it significantly reduces storage overhead and timing acquisition delay, effectively improving the efficiency of sparse tracing and the adaptability to complex program execution processes.

[0133] Please see Figure 5 , Figure 5 This is a schematic diagram of the processor structure in some embodiments of this application. Figure 5 The register event tracing circuit 123 includes a register timestamp array 1231, which is connected to the instruction pipeline circuit 1111 and is used to trace register event instructions in the program and store the register timestamps corresponding to the register event instructions.

[0134] As described in the above embodiments, the register timestamp table can be stored in the register timestamp storage plane, specifically in the storage structure of the register event tracking circuit 123 or in a storage structure outside the processor 100. That is to say, the register timestamp array 1231 is a storage structure in the register event tracking circuit 123, and the register timestamp array 1231 can include multiple registers or storage units, wherein each register or storage unit can be used to store register timestamps.

[0135] Continuing with the example of 32 register indices from x0 to x31, the register timestamp array 1231 can also include 32 storage units, with each storage unit corresponding to one of the 32 register indices (registers). The indices of these 32 storage units can be x32 to x63, where x0 corresponds to x32, x1 to x33, and so on, x31 to x63. Furthermore, when reading a value from the register corresponding to x1, the timestamp of this read operation is stored in the storage unit corresponding to x33. When reading a value from the register corresponding to x2, the timestamp is stored in the storage unit corresponding to x34. When writing a value to the register corresponding to x3, the timestamp is stored in the storage unit corresponding to x35.

[0136] Furthermore, the register timestamp array 1231 is connected to the instruction pipeline circuit 1111, and the register timestamps stored therein can be acquired and / or rewritten by the instruction pipeline circuit 1111 during instruction execution.

[0137] In the above scheme, the register timestamp array 1231 adopts a storage architecture that addresses by register index. This overwrite mechanism only retains the global timing of the most recent write-back of each register, achieving accurate tracking of register write-back behavior with extremely low storage overhead. Its timing is derived from the memory timestamp table, providing a reliable timing anchor for the final state of the registers. Together with the memory-side tracking logic, it constructs a full-state timing evidence chain, effectively reducing the complexity of generating and verifying auxiliary trajectories.

[0138] In some embodiments, the register event tracking circuit 123 is further configured to maintain the register timestamp corresponding to the register event instruction based on the instruction type and retirement instruction count corresponding to the register event instruction.

[0139] Different instruction types have different register timestamps corresponding to those instructions.

[0140] Taking a register event instruction as an example where the instruction type is a normal arithmetic instruction, during instruction execution, when reading the old value of the first source register, the first timestamp corresponding to this read operation is obtained; when reading the old value of the second source register, the second timestamp corresponding to this read operation is obtained; when writing a new value to the destination register, the third timestamp corresponding to this write operation is obtained, and the first timestamp, the second timestamp, and the third timestamp are used as register timestamps.

[0141] In one example, the first, second, and third timestamps are obtained based on the retirement instruction count and according to a preset offset rule. For example, when the retirement instruction count is N, the first, second, and third timestamps are incremented by a preset value in the order of events. That is, the first timestamp is N+N1, the second timestamp is N+N1+N1, and the third timestamp is N+N1+N1+N1, where the retirement instruction count is the same as the global instruction identifier.

[0142] Taking the instruction type corresponding to the register event instruction as a load instruction as an example, during the instruction execution process, when reading the old value of the first source register, the fourth timestamp corresponding to this read operation is obtained. When reading the memory access address, which involves memory read, the fifth timestamp corresponding to this read operation is not obtained (it can be obtained by the memory event tracking circuit 122). When writing a new value to the destination register, the sixth timestamp corresponding to this write operation is obtained, and the fourth timestamp and the sixth timestamp are used as the register timestamp.

[0143] In one example, the fourth, fifth, and sixth timestamps are obtained based on the retirement instruction count and according to a preset offset rule. For example, when the retirement instruction count is N, the fourth, fifth, and sixth timestamps are incremented by a preset value in the order of events. That is, the fourth timestamp is N+N2, the fifth timestamp is N+N2+N2, and the sixth timestamp is N+N2+N2+N2, where the retirement instruction count is the same as the global instruction identifier.

[0144] In the above scheme, the register event tracing circuit 123 maintains register timestamps based on instruction type differentiation. By distinguishing the timing granularity of read and write operations, it accurately depicts the complete lifecycle of register state transitions. Relying on the timing benchmark derived from the retirement instruction count, and combined with a multi-dimensional timestamp system constructed using preset offset rules, it ensures both the strict order of source operand reads and destination register writes in timing logic, and maintains the minimalism of the storage structure through the overwrite mechanism. At the hardware level, it provides timing evidence for the register interaction history, significantly reducing the complexity and computational overhead of backend proofs for verifying complex instruction flows.

[0145] In some embodiments, the register event tracking circuit 123 is further configured to, when there are at least two identical register indices corresponding to a register event instruction, select one register timestamp from the register timestamps corresponding to the at least two identical register indices for maintenance according to a preset priority.

[0146] If at least two register indices are identical for a register event instruction, then at least two entries in the register timestamp table or the storage cell indices in the register timestamp array 1231 corresponding to that register event instruction are also identical.

[0147] In one implementation, the preset priority is set to increase sequentially according to the read and write order. Taking the first, second, and third timestamps as register timestamps as an example, the priority of writing the first timestamp into the corresponding entry of the register timestamp table is lower than that of writing the second timestamp into the corresponding entry of the register timestamp table, and the priority of writing the second timestamp into the corresponding entry of the register timestamp table is lower than that of writing the third timestamp into the register timestamp table.

[0148] Continuing with the example of using the first, second, and third timestamps as register timestamps, and assuming that register timestamp array 1231 comprises 32 storage units with indices x32 to x63, when two register indices are identical (e.g., the first source register index is x1, the second source register index is x2, and the destination register index is x2), the first timestamp is written to the storage unit corresponding to x33, the second timestamp is discarded, and the third timestamp is written to the storage unit corresponding to x34. When three register indices are identical (e.g., the first source register index is x1, the second source register index is x1, and the destination register index is x1), the first and second timestamps are discarded, and the third timestamp is written to the storage unit corresponding to x33.

[0149] In the above scheme, when the same instruction accesses registers with the same register index, conflict resolution is performed according to the order of events within the instruction, and the timestamp of the last access to the register by the instruction is retained first, thus eliminating the ambiguity of multiple timestamps for the same register within the same clock cycle.

[0150] Please continue reading. Figure 4The trajectory processing circuit 110 includes: a register file 1112, located in the processor core 111, connected to the instruction pipeline circuit 1111 and the register event tracing circuit 123. The register file 1112 is used to store register business data. The register event tracing circuit 123 is also used to: perform the operation of generating a register event final state record after the program execution ends. The operation of generating a register event final state record includes: reading the final state register timestamp from the register timestamp table and reading the final state register value from the register file 1112; and writing the final state register timestamp and the final state register value into the register event final state record result area to generate a register event final state record.

[0151] Register service data can be register values. In one example, during instruction execution, register service data is fetched and / or rewritten by instruction pipeline circuit 1111.

[0152] The register event final state record result area can be a storage structure within the register event tracing circuit 123 or a storage structure outside the processor 100, such as... Figure 4 As shown, the register event final state record result area can be located in a storage structure outside the processor 100.

[0153] like Figure 4 As shown, the bitmap storage plane, memory timestamp storage plane, memory event final state record result area, register timestamp storage plane, and register event final state record result area can all be located in a storage structure outside the processor 100, for example, in the same storage device, and each storage plane / result area can be isolated through different channels or arbitration lock state machines to independently read and write to one of the planes / result areas.

[0154] Continuing with the example of 32 register indices x0 to x31, the register file 1112 includes 32 registers with register indices x0 to x31. The register event tracking circuit 123 scans the register value stored in each register in the register file 1112 step by step and uses it as the final state register value. It also scans the register timestamp in each entry of the register timestamp table step by step, or scans the register timestamp in the register or storage unit in the register timestamp array 1231 step by step and uses it as the final state register timestamp. Then, the final state register timestamp and the final state register value are written into the register event final state record result area to generate the register event final state record.

[0155] In one implementation, the final state register timestamp and the final state register value are written to the register event final state record result area according to a preset format. For example, the final state register timestamp is recorded according to final_register_values_timestamp[0..31], and the final state register value is recorded according to final_register_values_value[0..31]. Here, final_register_values_timestamp[0..31] represents 32 register timestamps. Each entry at index i stores the timestamp of the last valid read or write of the corresponding register. For example, final_register_values_timestamp[0] represents the timestamp of the last valid read or write of storage unit x32, final_register_values_timestamp[1] represents the timestamp of the last valid read or write of storage unit x33, and final_register_values_timestamp

[31] represents the timestamp of the last valid read or write of storage unit x63. `final_register_values_value[0..31]` represents 32 register values. Each entry at index i stores the current value of the corresponding register at the end of the program. For example, `final_register_values_value[0]` represents the current value of register x0 at the end of the program, `final_register_values_value[1]` represents the current value of register x1 at the end of the program, and `final_register_values_value

[31] ` represents the current value of register x31 at the end of the program.

[0156] In the above scheme, the register event tracing circuit 123 collaboratively extracts the final state business data of the register file 1112 and the timing markers of the register timestamp table or register timestamp array 1231 after the program ends. Through a batch scanning mechanism, the final state of the registers is completely captured without intruding into the core execution flow. The final state value is bound and encapsulated with the corresponding most recent access timing, constructing a complete evidence chain of register state-timing at the hardware level. This chain is of the same origin as the timing logic of the final state acquisition logic on the memory side, providing a globally consistent state verification context for backend proof, and significantly reducing the complexity and computational overhead of register state verification.

[0157] In some embodiments, the memory event tracking circuit 122 is further configured to determine whether to perform the operation of generating a memory event final state record based on a second preset condition before performing the operation of generating a memory event final state record after the program execution ends, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0158] As described in the above embodiments, key fields in the instruction trace information can be expanded to obtain program_finished and dcache_flushed.

[0159] Among them, the program finish field can be set to 1 if program_finished is set to 1, and the memory cache flush field can be set to 1 if dcache_flushed is set to 1.

[0160] In the above scheme, the memory event tracking circuit 122 accurately defines the legitimate window for collecting the final state of memory through a dual hardware handshake mechanism of program termination and cache flushing, ensuring that the data has been completely written to disk and is in a consistent state at the time of collection. This avoids false final states caused by runtime noise and cache inconsistency at the hardware level, significantly improving the credibility of the auxiliary trajectory and providing a verification benchmark for backend proof that is accurate in timing and true in state.

[0161] In some embodiments, the register event tracking circuit 123 is further configured to determine whether to perform the operation of generating register event final state record based on a second preset condition before performing the operation of generating register event final state record after the program execution ends, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0162] As described in the above embodiments, key fields in the instruction trace information can be expanded to obtain program_finished and dcache_flushed.

[0163] Among them, the program finish field can be set to 1 if program_finished is set to 1, and the memory cache flush field can be set to 1 if dcache_flushed is set to 1.

[0164] In the above scheme, the register event tracking circuit 123 relies on a dual hardware handshake mechanism of program termination and cache flushing to accurately anchor the stable window of register final state acquisition, ensuring that the acquired value is the true steady state at program exit and avoiding non-final state erroneous acquisition caused by dynamic fluctuations during runtime. This provides a globally consistent register verification benchmark for backend proof, effectively reducing verification complexity.

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

[0166] The host 610 can be a control-side electronic device in the zero-knowledge proof system 600 responsible for controlling and managing the proof task. In one embodiment, the host 610 includes, but is not limited to, a host CPU, 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.

[0167] 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 610 compiles the program into a preset format file, such as a RISC-V ELF format file.

[0168] 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.

[0169] 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, the base address and length of the auxiliary trajectory record output area, and other system configuration parameters.

[0170] The system-on-a-chip 620 includes, but is not limited to, the processor 100 in the above embodiments.

[0171] In one implementation, the system-on-chip 620 is connected to a host 610 to obtain programs, input parameters, and configuration data from the host 610. Further, the system-on-chip 620 generates a proof trajectory record and an auxiliary 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.

[0172] The auxiliary trajectory record can be used to verify the consistency between the program execution result represented by the proof trajectory record and the actual hardware final state.

[0173] The proof circuit 630 can be an integrated circuit in the zero-knowledge proof system 600 responsible for proving the proof trajectory record and auxiliary trajectory record to generate proof data.

[0174] In one implementation, the proof circuit 630 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.

[0175] In one implementation, the proof circuit 630 acquires proof trajectory records and auxiliary trajectory records. For example, the proof circuit 630 is connected to the system-on-a-chip (SoC) 620 to acquire the proof trajectory records from the SoC 620. Alternatively, the proof circuit 630 reads the proof trajectory records and auxiliary trajectory records from a preset storage area, where the preset storage area can be the storage area of ​​a storage device in the host 610, i.e., the proof circuit 630 is connected to the host 610. Figure 6 As shown. The preset storage area can also be the storage area of ​​an independent storage device, where the on-chip system 620 outputs the proof trajectory record and the auxiliary trajectory record to this storage area after generating them.

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

[0177] In one embodiment, the proof circuit 630 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 630.

[0178] In the above solution, the efficient flow of the entire process from the issuance to the generation of zero-knowledge proof tasks is realized through a three-level collaborative architecture of host 610, system-on-chip 620 and proof circuit 630. At the same time, the output proof trajectory record and auxiliary trajectory record have completeness, order and semantic compliance, taking into account both execution efficiency and proof reliability, and providing feasible hardware support for the large-scale implementation of zero-knowledge proof.

[0179] In some embodiments, the host 610 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.

[0180] The shared memory can be a storage area accessible and writable by the host 610 and / or the system-on-chip 620 and / or the verification circuit 630. For example, the shared memory includes at least one of the following: a storage area within the host 610, a storage area within the system-on-chip 620, a storage area in the verification circuit 630, and an external storage device (such as DRAM).

[0181] 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 610; the trajectory result collection area is used to store the proof trajectory record and auxiliary trajectory record generated by the system-on-chip 620; and the proof data area is used to store the proof data generated by the proof circuit 630.

[0182] 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 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 620 can generate.

[0183] Furthermore, after the host 610 writes the program, input data, 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 610's cache. This ensures that the subsequent system-on-chip 620 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 620.

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

[0185] In some embodiments, the host 610 is further configured to send a trajectory generation start signal to the system-on-chip 620; the system-on-chip 620 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 and an auxiliary trajectory record corresponding to the program.

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

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

[0188] In the above scheme, the host 610 triggers the transmission of the trajectory generation start signal only after performing a preset operation. The on-chip system 620 responds to the signal and starts data acquisition and proof trajectory record generation. This establishes a cross-device task triggering timing between the host 610 and the on-chip system 620. Furthermore, the host 610 sends the trajectory generation start signal only after performing the preset operation, which avoids the on-chip system 620 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 and auxiliary trajectory record generation.

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

[0190] In one implementation, after generating a proof track record corresponding to at least one instruction and an auxiliary track record corresponding to the program, the on-chip system 620 generates an end signal via a PCIe MSI-X interrupt, completion register, or doorbell to notify the host 610 that a proof track record corresponding to at least one instruction and an auxiliary track record corresponding to the program have been generated. Then, the host 610 starts the proof circuit 630 to generate proof data based on the proof track record and the auxiliary track record.

[0191] In the above scheme, the closed-loop mechanism of the host 610 starting the proof circuit 630 is triggered by the end signal generated by the on-chip system 620, which further reduces the system idle waiting time and eliminates the computing power overhead of the host 610 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 630 is complete and valid.

[0192] In some embodiments, the host 610 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 630 after performing the memory barrier operation to start the proof circuit 630.

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

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

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

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

[0197] 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 610, so that the host 610 can read the latest proof data.

[0198] 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.

[0199] Please see Figure 10 and combined Figure 11-13 , Figure 10 This is a flowchart illustrating the trajectory generation method of some embodiments of this application. Figure 11 This is a schematic diagram illustrating the process of generating auxiliary trajectory records according to some embodiments of this application. Figure 12 This is a schematic diagram illustrating the final state record collection process of some embodiments of this application. Figure 13 This is a schematic diagram illustrating the memory timestamp address mapping process in some embodiments of this application, wherein, Figures 11-13These are three examples from numerous embodiments of the proof state generation process in this application. This method can be applied to processors, systems-on-a-chip (SoCs), electronic devices, etc., for example, to processor 100 or SoC 620. Specifically, the relevant steps in this method can be executed by specific circuits in processor 100 or SoC 620. The processor can be a CPU, specifically implemented based on a reduced instruction set architecture. In one specific embodiment, the processor can be a RISC-V based processor configured to execute a user program and generate corresponding proof states to construct proof trajectory records and auxiliary trajectory records. The processor can be integrated into the SoC or disposed in an electronic device, and the SoC can also be disposed in an electronic device. The electronic device can be a computer, and the electronic device can execute the method through a processor or SoC, or it can implement the method through a program. In the method steps, the processor or SoC is used as the execution subject for description. The method includes the following steps: Step S101: Process the instructions to be processed in the program and generate at least one proof trajectory record.

[0200] The instructions to be processed in the program can be instructions that have not yet been fetched and executed. In one example, the program includes multiple instructions, which are fetched and executed one by one.

[0201] Evidence trace records can be a data form of instruction execution evidence structure. They are data sets automatically captured and constructed from relevant data generated by the execution of instructions, used to record and prove the execution process and results of the instructions.

[0202] In one example, the proof trajectory record includes at least an instruction context field, a state old value field, a state new value field, a state old timestamp field, and a state new timestamp field. The instruction context field indicates the basic identification information of the instruction execution event corresponding to this state transition, providing an index for the backend proof system to locate instruction semantics and correlate preceding and following state transitions. Examples include the program counter, instruction code, global instruction identifier, and instruction type identifier. The state old value field and state new value field indicate the numerical changes in the architectural state transition caused by this instruction execution, allowing the backend proof system to verify the legality of the numerical calculations during the state transition. For example, for ordinary arithmetic instructions, the state old value field includes the old values ​​of the first source register, the second source register, and the destination register, while the state new value field includes the destination register write-back value. The old and new timestamp fields are used to indicate the timing changes of the current architectural state transition, allowing the backend verification system to verify the timing monotonicity of the state transition and the legality of cross-instruction state dependencies. For example, for ordinary arithmetic instructions, the old timestamp field includes the old timestamp corresponding to the first source register, the old timestamp corresponding to the second source register, and the old timestamp corresponding to the destination register. The new timestamp field includes the timestamp when reading the first source register, the timestamp when reading the second source register, and the timestamp when writing a value to the destination register.

[0203] At least one proof trajectory record corresponds to the program. For example, the program includes instructions A, B, and C. Instructions A, B, and C are processed sequentially, generating three proof trajectory records corresponding to instructions A, B, and C. These three proof trajectory records can characterize the state changes during program execution. As another example, the program includes instructions A, B, and C, where instruction B is an instruction whose execution process and result do not need to be proven. The trajectory processing circuit 110 processes instructions A, B, and C sequentially, generating two proof trajectory records corresponding to instructions A and C. These two proof trajectory records can characterize the state changes during program execution.

[0204] Step S102: During program execution, the instructions in the program are traced to generate memory event final state records and register event final state records, wherein the memory event final state records and register event final state records are used to construct auxiliary trajectory records to prove the program execution process with at least one proof trajectory record.

[0205] A memory event final state record can be a final state data record related to a memory event at the memory word granularity after program execution. For example, if a program includes instructions A, B, and C, and instructions A, B, and C sequentially perform read and / or write operations on the same memory address, then after program execution, the memory value corresponding to the last read or write operation at that memory address is the memory final state value, which is the final state data record related to the memory event. In one example, if instruction C is the last instruction in the program, then the memory value corresponding to the last read or write operation performed by instruction C on that memory address is the memory final state value, which is the final state data record related to the memory event.

[0206] Similarly, the timestamp corresponding to the last read or write operation on a memory address in the program is the memory final state timestamp.

[0207] The final state data record related to the memory event includes at least one of the following: memory address, memory final state value corresponding to the memory address, and memory final state timestamp corresponding to the memory address.

[0208] Understandably, if a program involves read and / or write operations to multiple memory addresses, the memory event final state record can include multiple sets of final state data records. Each set of records represents the corresponding memory final state after program execution, thus representing program-level static state data. For example, one set of final state data records includes the memory address, the memory final state value corresponding to the memory address, and the memory final state timestamp corresponding to the memory address, and the memory addresses in each set of final state data records are different. Furthermore, for memory addresses that the program did not read or write, the memory address and its corresponding memory value and timestamp can still be output, for example, set to a preset value and output.

[0209] A register event final state record can be a final state data record related to a register event at the register level after program execution. For example, if a program includes instructions A, B, and C, and instructions A, B, and C sequentially perform read and / or write operations on the same register, then after program execution, the register value corresponding to the last read or write operation on that register is the register final state value, which is the final state data record related to the register event. In one example, if instruction C is the last instruction in the program, then the register value corresponding to the last read or write operation performed by instruction C on that register is the register final state value, which is the final state data record related to the register event.

[0210] Similarly, the timestamp corresponding to the last read or write operation on the register in the program is the register final state timestamp.

[0211] Among them, the final state data record related to the register event includes at least the register final state value and the register final state timestamp corresponding to the register final state value.

[0212] Understandably, if a program involves read and / or write operations on multiple registers, the register event final state record can include multiple sets of final state data records to characterize program-level static state data. For example, one set of final state data records includes the register final state value and the register final state timestamp corresponding to the register final state value, and each set of final state records corresponds to a different register. Furthermore, for registers that the program has not read or written, the corresponding register value and register timestamp can still be output, for example, set to a preset value and output.

[0213] Auxiliary trajectory records can be a data form of program execution evidence structure. They are data sets automatically captured and constructed from relevant data generated by the executing program, used to record and assist in proving the program execution result. Among them, the memory event final state records and register event final state records in the auxiliary trajectory records serve as program-level result evidence. They can be used to verify consistency with the program execution result represented by at least one proof trajectory record, ensuring that the program final state derived from at least one proof trajectory record matches the actual final state.

[0214] In one implementation, instructions in the program are traced to generate memory event final state records and register event final state records corresponding to the program. For example, the program includes instructions A, B, and C. When instruction A is executed, state data related to instruction A is captured; when instruction B is executed, state data related to instruction B is captured; and when instruction C is executed, state data related to instruction C is captured. Further, if instructions A, B, and C involve both memory events (such as memory read and / or write operations) and register events (such as register read and / or write operations), then memory event final state records and register event final state records corresponding to the program are generated. In one example, capturing state data related to instructions can be done by capturing the state data generated by the executed instructions during the generation of the evidence trace record. For status data, if the instruction involves a memory event, the status data may include an access flag (such as a bitmap) to identify the accessed memory address and the corresponding memory timestamp. The access flag is used to mark the memory address accessed by the memory event, or to mark the memory word being accessed, so that the corresponding memory final state value can be obtained according to the marked memory address after the program execution ends. The memory timestamp also corresponds to the memory address. If the instruction involves a register event, the status data may include a register timestamp, and the register final state value can be obtained together after the program execution ends.

[0215] In the above scheme, a proof trajectory record of the entire state transition process is generated during instruction execution. At the same time, lightweight tracking of state changes involving memory and registers is performed based on the same instruction stream during program execution. After program execution, the final state records of memory events and register events are output, and auxiliary proof trajectory records are constructed. The two types of trajectories share a unified global timing benchmark. This can ensure that the program final state derived from the proof trajectory record completely matches the actual execution state through cross-validation. Furthermore, it can synchronously output procedural proof data and result auxiliary data without inserting additional scanning instructions after program execution. This effectively solves the problems of insufficient credibility of final state data and the disconnect between process evidence and result evidence, and balances the credibility, completeness, and execution efficiency of trajectory generation.

[0216] In some embodiments, during program execution, tracing instructions in the program includes: acquiring instruction tracing information corresponding to the instructions, and performing multi-stage pipeline preprocessing on the instruction tracing information in parallel with the process of generating at least one proof trajectory record, based on the instruction tracing information, to obtain a preprocessing result corresponding to each proof trajectory record.

[0217] Instruction tracing information can be field data generated during instruction execution to construct the proof trajectory record. For example, the proof trajectory record may include fields such as: pc (program counter), used to record the program counter address of the instruction; inst (instruction code), used to record the opcode and operand codes of the instruction; and zk_clk (global instruction identifier) ​​or base_timestamp derived from zk_clk according to a preset offset, used to record the position of the instruction in the global instruction clock sequence number column. Other fields that may be included in the proof trajectory record can be referred to the description in the above embodiments, and will not be listed here. That is to say, instruction tracing information / field information can be reused field data generated during instruction execution to construct the proof trajectory record.

[0218] Optionally, the instruction trace information can be expanded as needed, based on the field data of the reused proof trace record. In one example, the instruction trace information includes at least: a program_finished field to indicate whether the program has ended; a dcache_flushed field to indicate whether the data cache has been flushed; rs1_val (source register 1 value); rd_wen (destination register write enable) to indicate whether there is a valid destination register write-back operation in the current instruction; rd_idx (destination register index) to identify the index of the destination register to be written; rd_val (destination register write-back value) to identify the value of the destination register to be written back; rf_valid (register file scan valid flag) to indicate whether the register file scan after the program ends is valid; and rf_data (register file scan data) to scan register values ​​from the register file when rf_valid is valid.

[0219] Multi-stage pipeline preprocessing can be a streaming process that performs multiple serial processing stages on a single instruction, according to the output order of the instruction trace information corresponding to the instruction.

[0220] Continuing with instructions A, B, and C as an example, instruction A corresponds to instruction trace information A1, instruction B corresponds to instruction trace information B1, and instruction C corresponds to instruction trace information C1. Multi-stage pipeline preprocessing follows the generation order of instruction trace information A1, B1, and C1, preprocessing them level by level. More specifically, multi-stage pipeline preprocessing can be a three-stage pipeline preprocessing, consisting of first-stage preprocessing, second-stage preprocessing, and third-stage preprocessing. The step-by-step preprocessing can be as follows: first, perform first-stage preprocessing on instruction trace information A1; after completing first-stage preprocessing, perform second-stage preprocessing on instruction trace information A1, and then perform first-stage preprocessing on instruction trace information B1; after completing second-stage preprocessing on instruction trace information A1, perform third-stage preprocessing on instruction trace information A1, and then perform second-stage preprocessing on instruction trace information B1, and finally perform first-stage preprocessing on instruction trace information C1. In one example, Level 1 preprocessing is used to receive and extract key data from the instruction trace information; Level 2 preprocessing is used to parse and compute the key data; and Level 3 preprocessing is used to structure the preprocessing results for output.

[0221] In one implementation, the generation of proof trajectory records and multi-stage pipeline preprocessing are performed in parallel. For example, when an instruction retires, a proof trajectory record is constructed based on instruction tracing information. At the same time, multi-stage pipeline preprocessing is performed based on instruction tracing information. The proof trajectory record and multi-stage pipeline preprocessing share the same retirement event trigger source, thereby ensuring timing consistency while working in parallel. For example, a mapping relationship is established between the proof trajectory record and the preprocessing result through a global instruction identifier. Similarly, this mapping relationship is maintained between the proof trajectory record and the auxiliary trajectory record.

[0222] The above scheme achieves physical decoupling between the generation of proof trajectories and auxiliary trajectories. Based on the same instruction retirement event, the generation process of each proof trajectory is executed in parallel. By sharing a global timing benchmark, it ensures that the preprocessing results and the proof trajectory records strictly correspond in time, providing cross-verifiable dual-track evidence for backend proof. A streaming multi-level preprocessing architecture is adopted, using single instruction tracing information as the smallest processing unit to advance step by step. High-throughput real-time preprocessing is achieved without blocking instruction retirement, transforming unstructured raw signals into directly consumable information and significantly reducing the overhead of auxiliary trajectory generation. This provides a low-latency, highly reliable final state context for backend proof, effectively avoiding the state pollution and performance degradation problems caused by software scanning.

[0223] In some embodiments, the instruction trace information is subjected to multi-stage pipeline preprocessing, including: filtering the user program area, identifying the instruction type, masking the termination instruction, and counting the retirement instruction based on the instruction trace information.

[0224] User program area filtering can be used to filter instructions outside the user program area. For example, instruction tracing information includes the program counter (PC). The PC is compared with a preset user program area address range. When the PC falls within the preset user program area address range, the instruction is determined to be a user program area instruction and is retained. When the PC falls outside the preset user program area address range, the instruction is determined to be a non-user program area instruction and is filtered.

[0225] Instruction type identification can be performed by identifying the type of instruction based on instruction tracing information. For example, based on the `inst` in the instruction tracing information, the opcode in `inst` is decoded, and the instruction category is obtained based on the decoding result. In one example, the instruction category includes at least ordinary arithmetic instructions, load instructions, and store instructions.

[0226] End instruction masking can identify whether the current instruction is an end instruction based on instruction trace information. For example, it can match the `inst` in the instruction trace information with a preset end instruction code. If a match is found, the current instruction is determined to be an end instruction, and a masking signal is generated to prevent instruction trace information following this end instruction from continuing into the preprocessing path. In one example, the preset end instruction code is 0x0000006F.

[0227] The retirement instruction count can be a globally maintained instruction retirement count. Each time a valid retirement instruction trace is processed, the count is incremented, and the current count value is appended to the preprocessing result as the global instruction identifier zk_clk or its derived base_timestamp, thus sharing the same instruction retirement event with the proof trace record generation.

[0228] In one implementation, user program area filtering, instruction type identification, termination instruction masking, and retirement instruction counting can be steps in a multi-stage pipeline preprocessing. Taking a three-stage pipeline preprocessing as an example, user program area filtering, instruction type identification, and termination instruction masking can be performed in the second stage of preprocessing; and retirement instruction counting can be performed in the third stage of preprocessing.

[0229] In the above scheme, runtime metadata maintenance and core execution flow are decoupled by acquiring instruction tracing information. Based on the parsing of the program counter and instruction encoding, it accurately defines execution boundaries and dynamically generates control flow masking windows, effectively eliminating noisy data. At the same time, by maintaining a global retirement count shared with the core, it ensures that the auxiliary trajectory and the proof trajectory are strictly synchronized in time, providing a highly reliable and low-latency verification context for backend proof with zero additional core overhead.

[0230] In some embodiments, when the instruction type identification result is a memory event instruction, the memory access address corresponding to the memory event instruction is calculated based on the instruction trace information.

[0231] Taking the pretreatment of a three-stage production line as an example: In the first-level preprocessing, key fields of the instruction trace information corresponding to the instruction are latched, and some fields are expanded, such as pc, inst, rs1_val, rd_wen, rd_idx, rd_val, program_finished, dcache_flushed, and zk_clk.

[0232] In the second-level preprocessing, the instruction type is decoded and identified based on inst. When a memory event instruction is identified (such as a load instruction or a store instruction), the memory access address can be calculated. For example, for a load instruction, it can be obtained from rs1_val and an I-type immediate value, and for a store instruction, it can be obtained from rs1_val and an S-type immediate value. The I-type immediate value and the S-type immediate value can be extracted from inst.

[0233] Additionally, it determines whether the current instruction is the last valid instruction in the program based on whether program_finished is valid, and checks whether dcache_flushed is valid. If valid, it then performs memory event processing based on the memory access address to ensure memory consistency.

[0234] In the three-level preprocessing, the mapping relationship between the destination register index and the write-back value is constructed based on rd_wen, rd_idx, and rd_val. Whether to output the mask signal is determined based on whether program_finished is valid. zk_clk is incremented. Finally, the preprocessing results are output in a structured manner, such as instruction type, memory access address, user program area filtering flag, destination register write-back information, etc.

[0235] In the above scheme, the parsing of instruction tracing information enables the native derivation of the memory access address of memory event instructions, realizing the real-time calculation of the memory access address without software intervention. This reduces core performance overhead while avoiding the risks of address resolution delay and state inconsistency that may be introduced by software simulation.

[0236] In some embodiments, when the result of instruction type identification is a preset program end instruction, the program is determined to end according to a first preset condition, wherein the first preset condition includes at least one of multi-level pipeline consistency, multi-cycle debouncing, and data storage request.

[0237] Continuing with the example of the three-stage pretreatment process described above: In the secondary preprocessing stage, inst is decoded. When the current instruction is identified as matching the preset end instruction code, it is initially determined to be a potential program end event. In order to avoid misjudgment due to transient glitches or bit errors, multi-cycle debouncing is used to require that the identification result of the end instruction must be consistent over multiple consecutive clock cycles and / or that program_finished must be consistent over multiple consecutive cycles before the end event is deemed valid.

[0238] And / or, in the third-level preprocessing stage, multi-level pipeline consistency checks are performed. Since instruction tracing information is passed step-by-step through the three-level pipeline, the processing results of each pipeline level for the instruction must be consistent. For example, the instruction type identification result (end instruction) in the second-level preprocessing must match the logical determination result based on the program_finished signal in the third-level preprocessing. Simultaneously, the completion status of data storage requests is monitored, i.e., the validity of the dcache_flushed signal is checked. Since a forced flush of the data cache usually accompanies program termination, program termination is only confirmed after confirming that dcache_flushed is valid (indicating that all pending data storage requests have been written back to main memory and the memory data is in a consistent state).

[0239] Finally, once the first preset condition is met, a shielding signal is generated to prevent subsequent noise instructions from non-user programs from entering the effective preprocessing path.

[0240] The above scheme effectively avoids false termination judgments caused by noise and timing deviations through a multi-dimensional composite verification mechanism for program termination determination. Specifically, cross-processing stage consistency verification eliminates single-point identification biases and improves judgment reliability; steady-state verification at the timing dimension filters out transient signal jitter and avoids invalid instructions interfering with auxiliary trajectory generation; and pre-confirmation of memory consistency ensures that data has been written to disk during judgment, guaranteeing the authenticity of the final state snapshot. This provides precise program execution boundaries for backend proof, significantly reduces invalid verification overhead, and improves the credibility of auxiliary trajectories and overall verification efficiency.

[0241] In some embodiments, memory event instructions in the tracking program are used to set the bitmap corresponding to the memory event instructions and record the memory timestamp corresponding to the memory event instructions in the memory timestamp table.

[0242] Memory event instructions can be a class of instructions that involve reading and writing memory, such as load instructions and store instructions.

[0243] A bitmap can be a set of binary codes used to mark memory words. Specifically, each bit of the bitmap corresponds to a memory access address and a memory word, used to mark which memory access address and memory word a memory event instruction accessed. For example, each bit of the bitmap is mapped to an access address. When a memory access address is accessed, that is, when the memory word corresponding to that memory access address is accessed, the bitmap corresponding to that memory word is set to 1 to mark that the memory word has been accessed.

[0244] Memory timestamps can be timestamps corresponding to read and write operations of memory event instructions. For example, for a load instruction, it is the timestamp corresponding to the time when a memory value is read from the memory access address; for a store instruction, it is the timestamp corresponding to the time when a memory value is written to the memory access address.

[0245] Specifically, the memory timestamp can be obtained during the execution of the instruction. Taking the load instruction as an example, a new status timestamp field is constructed during the execution of the load instruction: when reading the old value of the first source register, the first timestamp corresponding to this read operation is obtained; when reading the memory value of the memory access address, the second timestamp corresponding to this read operation is obtained; when writing a new value to the destination register, the third timestamp corresponding to this write operation is obtained. The first, second, and third timestamps are used to construct the new status timestamp field, and the second timestamp can be a memory timestamp.

[0246] In one example, the first, second, and third timestamps are obtained based on the global instruction identifier and according to a preset offset rule. For example, when the global instruction identifier is n, the first, second, and third timestamps are incremented by a preset value in the order of events. That is, the first timestamp is n+n1, the second timestamp is n+n1+n1, and the third timestamp is n+n1+n1+n1.

[0247] A memory timestamp table can be a table structure indexed by memory word / memory address, where each entry stores the timestamp of the most recent valid access to the corresponding memory word / memory address.

[0248] In one implementation, memory event instructions in the tracking program are used. For example, if instruction A is a load instruction, the memory access address corresponding to the load instruction is obtained, and the bitmap of the memory word corresponding to the memory access address is set to 1. When the load instruction reads the memory value from the memory access address, the timestamp corresponding to the read operation is recorded as a memory timestamp in the memory timestamp table.

[0249] In the above scheme, by setting up a bitmap that works in conjunction with the memory timestamp table, the bitmap's minimal storage space usage enables fast indexing and marking of massive memory accesses. Only the timestamp records corresponding to the accessed memory words are extracted. While ensuring that the auxiliary trajectory fully reflects the program's memory access behavior, the storage overhead and timing acquisition latency are significantly reduced, effectively improving the efficiency of sparse tracing and its adaptability to complex program execution processes.

[0250] In some embodiments, memory event instructions are traced when the memory access address corresponding to the memory event instruction is located in the user data area.

[0251] The user data area can be a region that stores memory data. For example, a preset user data area address range.

[0252] In one implementation, after completing instruction type identification and memory access address calculation, it is determined whether the memory access address falls within a preset user data area address range. If the determination result is that it falls within the range, a tracking instruction is sent; if the determination result is that it falls outside the range, a non-tracking instruction is sent.

[0253] Furthermore, the corresponding memory word index is calculated based on the memory access address, and the bitmap position at that index is set to mark that the memory word in the user data area has been accessed. Additionally, the memory timestamp corresponding to the access time is obtained and written to the corresponding index entry in the memory timestamp table. Thus, memory event instructions can be traced when the memory access address corresponding to the memory event instruction is located in the user data area.

[0254] In the above scheme, the interval determination mechanism for memory access addresses achieves precise definition of the tracking range, effectively eliminates redundant metadata generated by access to memory addresses outside the user data area, reduces storage overhead while avoiding the encroachment of invalid tracking on system resources, and enables the generated auxiliary trajectory to accurately map the operation semantics of the user program on the user data area, significantly improving the purity and credibility of the backend proof verification context.

[0255] In some embodiments, after the program execution ends, an operation to generate a final state record of a memory event is performed; wherein, the operation to generate the final state record of the memory event includes: scanning a bitmap to obtain a bitmap scan result; reading a final state memory timestamp from a memory timestamp table according to the bitmap scan result and a memory timestamp table; reading a final state memory value from a corresponding memory data address in a memory data address area according to the bitmap scan result; and writing the memory data address, the final state memory value, and the final state memory timestamp into a memory event final state record result area with a preset width to generate a final state record of the memory event.

[0256] In one implementation, the bitmap is scanned to obtain a bitmap scan result. For example, the bitmap is read from a bitmap storage area to obtain the bitmap scan result. In one example, the bitmap scan result is 1001010101.

[0257] In one implementation, the final memory timestamp is read from the memory timestamp table based on the bitmap scan result and the memory timestamp table. For example, if the bitmap scan result is 1001010101, where the memory words corresponding to the first, fourth, sixth, eighth, and tenth bits have been accessed, then the memory access addresses corresponding to the first, fourth, sixth, eighth, and tenth bits are obtained according to the mapping relationship. Finally, the final memory timestamp is read from the memory timestamp table based on the mapping relationship between the memory access addresses and the memory timestamp table.

[0258] The memory data address region can be the address space used to store data, such as the user data area, kernel data area, device mapping area, etc.

[0259] The memory data address can be a memory access address in the user data area.

[0260] In one implementation, the final memory value is read from the corresponding memory data address in the memory data address region based on the bitmap scan result. Continuing with the example of a bitmap scan result of 1001010101, the memory access addresses corresponding to the first, fourth, sixth, eighth, and tenth bits are obtained according to the mapping relationship between the bitmap and the memory access address, and the final memory value is read based on the aforementioned memory access address.

[0261] The memory event final state record result area can be an address area used to store memory event final state records.

[0262] In one implementation, the memory data address, final memory value, and final memory timestamp are written into the memory event final state record result area according to a preset width to generate a memory event final state record. Continuing with the example of a bitmap scan result of 1001010101, the memory data addresses corresponding to this bitmap scan result are represented by addr1, addr4, addr6, addr8, and addr10, respectively. The final memory values ​​corresponding to the aforementioned memory data addresses are represented by data1, data4, data6, data8, and data10, respectively. The final memory timestamps corresponding to the aforementioned memory data addresses are represented by timestamp1, timestamp4, timestamp6, timestamp8, and timestamp10, respectively. Addr1, data1, and timestamp1 are concatenated according to a preset width and written into the memory event final state record result area. Similarly, addr4, data4, and timestamp4 are concatenated according to a preset width and written into the memory event final state record result area. ... and addr10, data10, and timestamp10 are concatenated according to a preset width and written into the memory event final state record result area. Thus, five sets of records are recorded in the memory event final state record result area. In one example, the memory event final state record result area can be divided into several data blocks, each data block holding a fixed number of records, and the output scale is demonstrated to the backend by the actual number of data blocks and the number of valid records.

[0263] Taking addr1, data1, and timestamp1 as an example, concatenating them according to a preset width can be done by concatenating the memory data address, final memory value, and final memory timestamp in a preset order and with a preset width. The preset order can be addr1, data1, and timestamp1, and the preset width can be 128. This results in a record set as: {addr1[31:0], data1[31:0], timestamp1[63:0]}. Here, addr1[31:0] represents a 32-bit memory data address, data1[31:0] represents a 32-bit final memory value, and timestamp1[63:0] represents a 64-bit final memory timestamp.

[0264] In one implementation, the initial state memory value and initial state memory timestamp are obtained before program execution. The initial state memory value can be the memory value corresponding to each address in the user data area, and the initial state memory timestamp can be the memory timestamp corresponding to the memory value at each address in the user data area. The initial state memory value and initial state timestamp can be used to verify the memory state changes before and after program execution by recording the verification trajectory. Further, after program execution, based on the bitmap scan results, only the memory values ​​at the accessed memory addresses and their corresponding memory timestamps can be retained as the initial state memory value and initial state memory timestamp.

[0265] In the above scheme, the bitmap-guided sparse acquisition mechanism accurately locates the memory words that are effectively accessed after the program ends, completely avoiding the performance loss caused by full memory scanning. By integrating memory data addresses, final state memory values ​​and final state memory timestamps to construct a fixed-width structured record, a complete evidence chain of address-state-time sequence is formed. While significantly reducing the storage overhead and transmission bandwidth of auxiliary trajectories, the standardized data encapsulation format provides a low-latency, highly reliable verification context for backend proof, effectively resolving the contradiction between runtime metadata maintenance and final state consistency verification.

[0266] In some embodiments, register event instructions in the program are tracked, and the register timestamps corresponding to the register event instructions are recorded in a register timestamp table.

[0267] Register event instructions can be a class of instructions that involve reading and writing back registers, such as ordinary arithmetic instructions and load instructions.

[0268] Register timestamps can be timestamps corresponding to register read and write-back operations. Taking ordinary arithmetic instructions as an example, the timestamps corresponding to reading register values ​​and writing register values ​​are register timestamps.

[0269] Specifically, the register timestamp can be obtained during the execution of the instruction. Taking a normal arithmetic instruction as an example, a new status timestamp field is constructed during the execution of a normal arithmetic instruction: when reading the old value of the first source register, the first timestamp corresponding to this read operation is obtained; when reading the old value of the second source register, the second timestamp corresponding to this read operation is obtained; when writing a new value to the destination register, the third timestamp corresponding to this write operation is obtained. The first, second, and third timestamps are used to construct the new status timestamp field, and the first, second, and third timestamps can be register timestamps.

[0270] A register timestamp table can be a table structure addressed by register index, where each entry stores the timestamp of the last valid read or write-back of the corresponding register.

[0271] In one implementation, the register event instructions in the program are tracked. For example, if instruction B is a normal arithmetic instruction, the register index corresponding to the normal arithmetic instruction is obtained, and when the normal arithmetic instruction reads a register value or writes a value to a register, the timestamp corresponding to the read or write operation is recorded as a register timestamp in the register timestamp table.

[0272] Taking 32 register indices from x0 to x31 as an example, when reading the register value corresponding to x1, the register timestamp corresponding to the read operation of x1 is stored in the register timestamp table. When reading the register value corresponding to x2, the register timestamp corresponding to the read operation of x2 is stored in the register timestamp table. When writing a value to the register corresponding to x3, the register timestamp corresponding to the write operation of x3 is stored in the register timestamp table.

[0273] In the above scheme, by setting up a register timestamp table that is addressed by register index, the register timestamp table occupies very little storage space to achieve fast indexing and marking of register write-back events. Only the timestamp record corresponding to the write-back destination register is extracted. While ensuring that the auxiliary trajectory fully reflects the program register write-back behavior, the storage overhead and timing acquisition delay are greatly reduced, and the efficiency of sparse tracing and the adaptability to complex program execution processes are effectively improved.

[0274] In some embodiments, the register timestamp corresponding to the register event instruction is maintained based on the instruction type corresponding to the register event instruction and the retirement instruction count.

[0275] Different instruction types have different register timestamps corresponding to those instructions.

[0276] Taking a register event instruction as an example where the instruction type is a normal arithmetic instruction, during instruction execution, when reading the old value of the first source register, the first timestamp corresponding to this read operation is obtained; when reading the old value of the second source register, the second timestamp corresponding to this read operation is obtained; when writing a new value to the destination register, the third timestamp corresponding to this write operation is obtained, and the first timestamp, the second timestamp, and the third timestamp are used as register timestamps.

[0277] In one example, the first, second, and third timestamps are obtained based on the retirement instruction count and according to a preset offset rule. For example, when the retirement instruction count is N, the first, second, and third timestamps are incremented by a preset value in the order of events. That is, the first timestamp is N+N1, the second timestamp is N+N1+N1, and the third timestamp is N+N1+N1+N1, where the retirement instruction count is the same as the global instruction identifier.

[0278] Taking the instruction type corresponding to the register event instruction as a load instruction as an example, during the instruction execution, when reading the old value of the first source register, the fourth timestamp corresponding to this read operation is obtained. When reading the memory access address, which involves memory read, the fifth timestamp corresponding to this read operation is not obtained (it can be stored in the memory timestamp table). When writing a new value to the destination register, the sixth timestamp corresponding to this write operation is obtained, and the fourth and sixth timestamps are used as register timestamps.

[0279] In one example, the fourth, fifth, and sixth timestamps are obtained based on the retirement instruction count and according to a preset offset rule. For example, when the retirement instruction count is N, the fourth, fifth, and sixth timestamps are incremented by a preset value in the order of events. That is, the fourth timestamp is N+N2, the fifth timestamp is N+N2+N2, and the sixth timestamp is N+N2+N2+N2, where the retirement instruction count is the same as the global instruction identifier.

[0280] In the above scheme, register timestamps are maintained based on instruction type differences. By distinguishing the timing granularity of read and write operations, the complete lifecycle of register state transitions is accurately depicted. Relying on a timing benchmark derived from retired instruction counts, and combined with a multi-dimensional timestamp system constructed using preset offset rules, this ensures both the strict temporal order of source operand reads and destination register writes, and maintains the minimalism of the storage structure through an overwrite mechanism. This provides timing evidence for register interaction history, significantly reducing the complexity and computational overhead of backend verification of complex instruction flows.

[0281] In some embodiments, when there are at least two identical register indices corresponding to register event instructions, a register timestamp is selected from the register timestamps corresponding to the at least two identical register indices for maintenance according to a preset priority.

[0282] Specifically, if there are at least two identical register indices corresponding to a register event instruction, then there are also at least two identical entries in the register timestamp table corresponding to that register event instruction.

[0283] In one implementation, the preset priority is set to increase sequentially according to the read and write order. Taking the first, second, and third timestamps as register timestamps as an example, the priority of writing the first timestamp into the corresponding entry of the register timestamp table is lower than that of writing the second timestamp into the corresponding entry of the register timestamp table, and the priority of writing the second timestamp into the corresponding entry of the register timestamp table is lower than that of writing the third timestamp into the register timestamp table.

[0284] In one implementation, the register timestamp table includes 32 entries, and each entry's index corresponds to a register index. For example, there are 32 register indices, x0 to x31, and 32 entry indices, c0 to c31. Register index x0 corresponds to entry index c0, register index x1 corresponds to entry index c1, and so on, register index x31 corresponds to entry index c31.

[0285] Continuing with the example of using the first, second, and third timestamps as register timestamps, if two register indices are identical (e.g., the index of the first source register is x1, the index of the second source register is x2, and the index of the destination register is x2), then the first timestamp is written to the entry corresponding to table entry index c1, the second timestamp is discarded, and the third timestamp is written to the entry corresponding to table entry index c2. If three register indices are identical (e.g., the index of the first source register is x1, the index of the second source register is x1, and the index of the destination register is x1), then the first and second timestamps are discarded, and the third timestamp is written to the entry corresponding to table entry index c1.

[0286] In the above scheme, when the same instruction accesses registers with the same register index, conflict resolution is performed according to the order of events within the instruction, and the timestamp of the last access to the register by the instruction is retained first, thus eliminating the ambiguity of multiple timestamps for the same register within the same clock cycle.

[0287] In some embodiments, after the program execution ends, an operation to generate a register event final state record is performed; wherein, the operation to generate a register event final state record includes: reading the final state register timestamp from the register timestamp table and reading the final state register value from the register file; and writing the final state register timestamp and the final state register value into the register event final state record result area to generate a register event final state record.

[0288] The register event final state record result area can be an address area used to store register event final state records.

[0289] Continuing with the example of 32 register indices from x0 to x31, the register file contains 32 registers with register indices from x0 to x31. The register value stored in each register in the register file is scanned step by step and used as the final register value. Additionally, the register timestamp in each entry of the register timestamp table is scanned step by step and used as the final register timestamp. Then, the final register timestamp and the final register value are written into the register event final state record result area to generate the register event final state record.

[0290] In one implementation, the final state register timestamp and the final state register value are written to the register event final state record result area according to a preset format. For example, the final state register timestamp is recorded according to final_register_values_timestamp[0..31], and the final state register value is recorded according to final_register_values_value[0..31]. Here, final_register_values_timestamp[0..31] represents 32 register timestamps. Each entry at index i stores the timestamp of the last valid read or write of the corresponding register. For example, final_register_values_timestamp[0] represents the timestamp of the last valid read or write of the entry with index c0 in the register timestamp table, final_register_values_timestamp[1] represents the timestamp of the last valid read or write of the entry with index c1 in the register timestamp table, and final_register_values_timestamp

[31] represents the timestamp of the last valid read or write of the entry with index c31 in the register timestamp table. `final_register_values_value[0..31]` represents 32 register values. Each entry at index i stores the current value of the corresponding register at the end of the program. For example, `final_register_values_value[0]` represents the current value of register x0 at the end of the program, `final_register_values_value[1]` represents the current value of register x1 at the end of the program, and `final_register_values_value

[31] ` represents the current value of register x31 at the end of the program.

[0291] In the above scheme, the final state business data of the register file and the timing markers of the register timestamp table are extracted, and the final state of the register is completely captured through a batch scanning mechanism. The final state value is bound and encapsulated with the corresponding most recent access timing to construct a complete evidence chain of register state-timing, which is of the same origin as the timing logic of the final state acquisition logic on the memory side. This provides a globally consistent state verification context for backend proof, significantly reducing the complexity and computational overhead of register state verification.

[0292] In some embodiments, before performing the operation of generating a memory event final state record after the program execution ends, it is determined whether to perform the operation of generating a memory event final state record according to a second preset condition, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0293] As described in the above embodiments, key fields in the instruction trace information can be expanded to obtain program_finished and dcache_flushed.

[0294] Among them, the program finish field can be set to 1 if program_finished is set to 1, and the memory cache flush field can be set to 1 if dcache_flushed is set to 1.

[0295] The above scheme employs a dual handshake mechanism of program termination and cache flushing to precisely define the legitimate window for collecting final state data in memory, ensuring that the data is fully written to disk and in a consistent state at the time of collection. This avoids false final states caused by runtime noise and cache inconsistencies, significantly improving the credibility of the auxiliary trajectory and providing a verification benchmark for backend proof that is accurate in timing and true in state.

[0296] In some embodiments, before performing the operation of generating the final state record of the register event after the program execution ends, it is determined whether to perform the operation of generating the final state record of the register event according to a second preset condition, wherein the second preset condition includes setting the program end field and setting the memory cache flush field.

[0297] As described in the above embodiments, key fields in the instruction trace information can be expanded to obtain program_finished and dcache_flushed.

[0298] Among them, the program finish field can be set to 1 if program_finished is set to 1, and the memory cache flush field can be set to 1 if dcache_flushed is set to 1.

[0299] The above scheme relies on a dual handshake mechanism of program termination and cache flushing to accurately anchor the stable window of register final state acquisition, ensuring that the acquired value is the true steady state at program exit and avoiding non-final state erroneous acquisition caused by runtime dynamic fluctuations. This provides a globally consistent register verification benchmark for backend proof, effectively reducing verification complexity.

[0300] Please see Figure 14 , Figure 14 This is a schematic diagram of the structure of a system-on-a-chip (SoC) according to some embodiments of this application. The SoC 1400 includes a processor 1410, which may be the processor 100 in the above embodiments. In one example, the SoC 1400 can be used in a zero-knowledge proof system, for example, in the zero-knowledge proof system 600 in the above embodiments, to acquire a program, input parameters, and configuration data, and to generate a proof trajectory record corresponding to at least one instruction and an auxiliary trajectory record corresponding to the program.

[0301] In the above scheme, a proof trajectory record of the entire state transition process is generated during instruction execution. At the same time, lightweight tracking of state changes involving memory and registers is performed based on the same instruction stream during program execution. After program execution is completed, memory event final state records and register event final state records are output, and auxiliary proof trajectory records are constructed. The two types of trajectories share a unified global timing benchmark. This can ensure that the program final state derived from the proof trajectory record completely matches the actual hardware execution state through cross-validation. Furthermore, it can synchronously output procedural proof data and result auxiliary data without inserting additional scanning instructions after program execution. This effectively solves the problems of insufficient credibility of final state data and the disconnect between process evidence and result evidence, and balances the credibility, completeness, and execution efficiency of trajectory generation.

[0302] 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.

[0303] 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.

[0304] 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.

[0305] 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.

[0306] 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 processor, characterized in that, include: A trajectory processing circuit is used to process the instructions to be processed in the program and generate at least one evidence trajectory record; An auxiliary trajectory generation circuit, connected to the trajectory processing circuit, is used to trace the instructions in the program during program execution to generate a memory event final state record and a register event final state record corresponding to the program. The memory event final state record and the register event final state record are used to construct an auxiliary trajectory record to prove the execution process of the program together with the at least one proof trajectory record. The trajectory processing circuit and the auxiliary trajectory generation circuit operate in parallel and independently.

2. The processor according to claim 1, characterized in that, The trajectory processing circuit includes: The processor core includes an instruction pipeline circuit, which is used to execute the instructions to be processed in the program instruction by instruction and generate the at least one proof trajectory record one by one.

3. The processor according to claim 2, characterized in that, The auxiliary trajectory generation circuit is located outside the processor core, and the auxiliary trajectory generation circuit includes: A preprocessing circuit, connected to the instruction pipeline circuit, is used to receive instruction tracing information output by the instruction pipeline circuit, and, based on the instruction tracing information, perform multi-level pipeline preprocessing on the instruction tracing information in parallel with the process of the instruction pipeline circuit generating the at least one proof trajectory record one by one, so as to obtain a preprocessing result corresponding to each proof trajectory record.

4. The processor according to claim 3, characterized in that, The preprocessing circuit is also used to perform user program area filtering, instruction type identification, termination instruction masking, and retirement instruction counting based on the instruction tracing information.

5. The processor according to claim 4, characterized in that, The preprocessing circuit is also used to calculate the memory access address corresponding to the memory event instruction based on the instruction tracing information when the result of the instruction type identification is a memory event instruction.

6. The processor according to claim 4, characterized in that, The preprocessing circuit is further configured to determine whether the program has ended based on a first preset condition when the result of the instruction type identification is a preset program end instruction, wherein the first preset condition includes at least one of multi-level pipeline consistency, multi-cycle debouncing, and data storage request.

7. The processor according to claim 3, characterized in that, The auxiliary trajectory generation circuit includes: A memory event tracking circuit, connected to the preprocessing circuit, is used to track memory event instructions in the program, set the bitmap corresponding to the memory event instruction, and record the memory timestamp corresponding to the memory event instruction in a memory timestamp table.

8. The processor according to claim 7, characterized in that, The memory event tracking circuit is also used to track the memory event instruction when the memory access address corresponding to the memory event instruction is located in the user data area.

9. The processor according to claim 7, characterized in that, The memory event tracking circuit is also used for: After the program finishes execution, the operation of generating the final state record of the memory event is performed; The operation of generating the final state record of the memory event includes: The bitmap is scanned to obtain the bitmap scanning result; Based on the bitmap scan results and the memory timestamp table, the final state memory timestamp is read from the memory timestamps; The final memory value is read from the corresponding memory data address in the memory data address region based on the bitmap scan result; The memory data address, the final memory value, and the final memory timestamp are written into the memory event final state record result area according to a preset width to generate the memory event final state record.

10. The processor according to claim 3, characterized in that, The auxiliary trajectory generation circuit includes: A register event tracking circuit, connected to the preprocessing circuit, is used to track register event instructions in the program and record the register timestamps corresponding to the register event instructions in a register timestamp table.

11. The processor according to claim 10, characterized in that, The register event tracking circuit includes: A register timestamp array, connected to the instruction pipeline circuit, is used to track register event instructions in the program and store the register timestamps corresponding to the register event instructions.

12. The processor according to claim 10, characterized in that, The register event tracking circuit is also used to maintain the register timestamp corresponding to the register event instruction based on the instruction type and retirement instruction count corresponding to the register event instruction.

13. The processor according to claim 12, characterized in that, The register event tracking circuit is also used to select one of the register timestamps corresponding to the at least two identical register indices for maintenance, according to a preset priority, when there are at least two identical register indices corresponding to the register event instruction.

14. The processor according to claim 10, characterized in that, The trajectory processing circuit includes: The register file, located in the processor core, is connected to the instruction pipeline circuit and the register event tracing circuit. The register file is used to store register business data. The register event tracking circuit is also used for: After the program finishes execution, the operation of generating the final state record of the register event is performed; The operation of generating the final state record of the register event includes: Read the final state register timestamp from the register timestamp table, and read the final state register value from the register file; Write the final state register timestamp and the final state register value into the register event final state record result area to generate the register event final state record.

15. The processor according to claim 9, characterized in that, The memory event tracking circuit is further configured to determine whether to perform the operation of generating the memory event final state record based on a second preset condition before performing the operation of generating the memory event final state record after the program execution ends. The second preset condition includes setting the program end field and setting the memory cache flush field.

16. The processor according to claim 14, characterized in that, The register event tracking circuit is further configured to determine whether to perform the operation of generating the register event final state record based on a second preset condition before performing the operation of generating the register event final state record after the program execution ends. The second preset condition includes setting the program end field and setting the memory cache flush field.

17. 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; The system-on-a-chip includes a processor as described in any one of claims 1-16, configured to acquire the program, the input parameters and the configuration data, and generate a proof trajectory record corresponding to the at least one instruction and an auxiliary trajectory record corresponding to the program; The proof circuit is used to acquire the proof trajectory record and the auxiliary trajectory record, and after generating proof data corresponding to the proof trajectory record and the auxiliary trajectory record, return the proof data to the host.

18. The zero-knowledge proof system according to claim 17, 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.

19. The zero-knowledge proof system according to claim 18, 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 a proof trajectory record corresponding to the at least one instruction and an auxiliary trajectory record corresponding to the program.

20. The zero-knowledge proof system according to claim 17, 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 and the auxiliary trajectory record corresponding to the program, so as to start the proof circuit through the host.

21. The zero-knowledge proof system according to claim 20, 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.

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

23. A trajectory generation method, characterized in that, include: The program processes the instructions to be processed and generates at least one evidence trajectory record; During the execution of the program, the instructions in the program are traced to generate memory event final state records and register event final state records, wherein the memory event final state records and the register event final state records are used to construct auxiliary trajectory records to prove the execution process of the program together with the at least one evidence trajectory record; The step of processing the instructions to be processed in the processing program and generating at least one proof trajectory record is parallel and independent of the step of tracing the instructions in the program during the execution of the program to generate memory event final state records and register event final state records.

24. The method according to claim 23, characterized in that, The step of tracing the instructions in the program during program execution includes: Obtain instruction tracking information corresponding to the instruction, and based on the instruction tracking information, perform multi-level pipeline preprocessing on the instruction tracking information in parallel with the process of generating the at least one proof trajectory record, so as to obtain the preprocessing result corresponding to each proof trajectory record.

25. The method according to claim 24, characterized in that, The multi-stage pipeline preprocessing of instruction tracing information includes: Based on the instruction tracing information, user program area filtering, instruction type identification, termination instruction masking, and retirement instruction counting are performed.

26. The method according to claim 25, characterized in that, When the instruction type identification result is a memory event instruction, the memory access address corresponding to the memory event instruction is calculated based on the instruction tracing information.

27. The method according to claim 25, characterized in that, When the result of the instruction type identification is a preset program end instruction, the program is judged to end according to a first preset condition, wherein the first preset condition includes at least one of multi-level pipeline consistency, multi-cycle debouncing, and data storage request.

28. The method according to claim 24, characterized in that, Track memory event instructions in the program, set the bitmap corresponding to the memory event instruction, and record the memory timestamp corresponding to the memory event instruction in the memory timestamp table.

29. The method according to claim 28, characterized in that, When the memory access address corresponding to the memory event instruction is located in the user data area, the memory event instruction is traced.

30. The method according to claim 28, characterized in that, After the program finishes execution, the operation of generating the final state record of the memory event is performed; The operation of generating the final state record of the memory event includes: The bitmap is scanned to obtain the bitmap scanning result; Based on the bitmap scan results and the memory timestamp table, the final state memory timestamp is read from the memory timestamps; The final memory value is read from the corresponding memory data address in the memory data address region based on the bitmap scan result; The memory data address, the final memory value, and the final memory timestamp are written into the memory event final state record result area according to a preset width to generate the memory event final state record.

31. The method according to claim 24, characterized in that, Track register event instructions in the program and record the register timestamps corresponding to the register event instructions in the register timestamp table.

32. The method according to claim 31, characterized in that, The register timestamp corresponding to the register event instruction is maintained based on the instruction type and retirement instruction count corresponding to the register event instruction.

33. The method according to claim 32, characterized in that, When there are at least two identical register indices corresponding to the register event instruction, a register timestamp is selected from the register timestamps corresponding to the at least two identical register indices for maintenance according to a preset priority.

34. The method according to claim 31, characterized in that, After the program finishes execution, the operation of generating the final state record of the register event is performed; The operation of generating the final state record of the register event includes: Read the final state register timestamp from the register timestamp table, and read the final state register value from the register file; Write the final state register timestamp and the final state register value into the register event final state record result area to generate the register event final state record.

35. The method according to claim 30, characterized in that, Before performing the operation of generating the final state record of the memory event after the program finishes execution, a second preset condition is used to determine whether to perform the operation of generating the final state record of the memory event. The second preset condition includes setting the program end field and setting the memory cache flush field.

36. The method according to claim 34, characterized in that, Before performing the operation of generating the register event final state record after the program finishes execution, a second preset condition is used to determine whether to perform the operation of generating the register event final state record. The second preset condition includes setting the program end field and setting the memory cache flush field.

37. A system-on-a-chip, characterized in that, Includes a processor as described in any one of claims 1-16, or for performing the method as described in any one of claims 23-36.

Images