Zero-knowledge proof result merging method, zero-knowledge proof result change method and apparatus, and computer system

Abstract

This specification discloses a method, modification method, apparatus, and computer system for merging zero-knowledge proof results. The merging method includes: running a first program in a zero-knowledge virtual machine (zkVM) based on a first result and a second result to perform a merging operation and generate a third result; each result includes a public output portion and a zero-knowledge proof portion. The public output portion includes a root ID field and an output list field. A single data entry in the output list field corresponds to the public output of the target program in a single run in zkVM. The root ID field is used to record the identifier of the target program. The merging operation includes: generating the public output portion of the third result if the first root ID in the first result and the second root ID in the second result are the same. In the third result, the third root ID is the same as the first ID, and the third output list includes the first output list from the first result and the second output list from the second result.

Description

1. Specification of Zero-Knowledge Proof Result Merging Method, Modification Method, Apparatus, and Computer System Technical Field This specification relates to the field of data processing technology, particularly to a method and apparatus for merging zero-knowledge proof results, a method and apparatus for modifying zero-knowledge proof results, a computer system for merging or modifying zero-knowledge proof results, and a computer-readable non-volatile storage medium. Background Technology Zero-knowledge proof (ZKP), as a cryptographic technique that verifies the truth of propositions without disclosing the original data, has been widely applied in recent years in various business areas such as financial transactions, supply chain management, digital identity authentication, and blockchain privacy protection. Its core advantage lies in its ability to balance data credibility and privacy protection needs. For example, in blockchain scenarios, it supports transaction validity verification while hiding transaction details, and in identity authentication, it enables "the prover to complete identity verification without exposing their identity information." However, with the increasing complexity and scale of application scenarios, the practical implementation of zero-knowledge proof technology still faces significant challenges. In current technical solutions, the high verification cost of zero-knowledge proof has become a key bottleneck restricting its large-scale application. Specifically, generating zero-knowledge proofs typically requires significant computational resources (such as high-dimensional matrix operations in polynomial constraint system proofs), while the verification process also necessitates the execution of complex mathematical verification logic (such as elliptic curve pairing operations). Especially in resource-sensitive scenarios like blockchain smart contract verification, high verification costs directly lead to increased transaction fees, decreased system throughput, and exacerbated energy consumption burdens on hardware, thus limiting the technology's widespread adoption in inclusive scenarios. To address these issues, the industry has proposed merging multiple zero-knowledge proofs into a single proof to reduce the number of verifications. These solutions have achieved some success in reducing overall computational overhead, but still have significant limitations. Therefore, there is an urgent need for an improved zero-knowledge proof merging scheme that can meet higher requirements in practical applications, such as lowering the barrier to entry, enhancing versatility, and supporting recursive merging. This specification describes a method, modification method, apparatus, and computer system for merging zero-knowledge proof results, which can meet the aforementioned higher requirements in practical applications. According to a first aspect, a method for merging zero-knowledge proof results is provided. The method includes: running a first program in a zero-knowledge virtual machine (zkVM) based on a first result and a second result to perform a merging operation and generate a third result; wherein each result includes a public output portion and a zero-knowledge proof portion, the public output portion including a root ID field and an output list field, the single data in the output list field corresponding to the public output of the target program in a single run in zkVM, and the root ID field used to record the identifier of the target program. The merging operation includes: [The text abruptly ends here, so the translation stops.]If the second root ID in the second result is the same, a public output portion of the third result is generated, wherein the third root ID is the same as the first root ID, and the third output list includes the first output list in the first result and the second output list in the second result. According to a second aspect, a method for modifying a zero-knowledge proof result is provided, comprising: running a fourth program in a zero-knowledge virtual machine (zkVM) based on a sixth result to perform a modification operation and generate a seventh result; wherein each result includes a public output portion and a zero-knowledge proof portion. The modification operation includes: if the sixth zero-knowledge proof in the sixth result passes verification, performing modification processing based on the sixth public output of the sixth result to obtain the public output portion of the seventh result. According to a third aspect, a method for modifying a zero-knowledge proof result is provided. The method includes: running a fourth program in a zero-knowledge virtual machine (zkVM) based on the eighth and ninth results to perform a change operation and generate a tenth result; wherein each result includes a public output portion and a zero-knowledge proof portion, the public output portion including a root ID field and an output list field, the single data in the output list field corresponding to the public output of the target program in a single run in zkVM, and the root ID field used to record the identifier of the target program. The change operation includes: generating the public output portion of the tenth result if the eighth root ID in the eighth result and the ninth root ID in the ninth result are the same, wherein the tenth root ID is the same as the eighth root ID, and the tenth output list is obtained by changing the eighth output list in the eighth result and the ninth output list in the ninth result. According to a fourth aspect, a zero-knowledge proof result merging apparatus is provided. The device includes: a first program execution module configured to run a first program in a zero-knowledge virtual machine (zkVM) based on a first result and a second result, to perform a merging operation and generate a third result; wherein each result includes a public output portion and a zero-knowledge proof portion, the public output portion including a root ID field and an output list field, a single data entry in the output list field corresponding to the public output of the target program in a single run in zkVM, and the root ID field used to record the identifier of the target program. The merging operation includes: generating the public output portion of the third result if the first root ID in the first result and the second root ID in the second result are the same, wherein the third root ID is the same as the first root ID, and the third output list includes the first output list in the first result and the second output list in the second result. According to a fifth aspect, a zero-knowledge proof result modification device is provided. The device includes: a fourth program execution module configured to run a first program in a zero-knowledge virtual machine based on a sixth result.A fourth program is run in zkVM to perform a change operation and generate a seventh result; each result includes a public output portion and a zero-knowledge proof portion. The change operation includes: if the sixth zero-knowledge proof in the sixth result passes verification, performing a change process based on the sixth public output in the sixth result to obtain the public output portion of the seventh result. According to a sixth aspect, a zero-knowledge proof result modification device is provided. The device includes: a fourth program running module configured to run a fourth program in a zero-knowledge virtual machine zkVM based on an eighth result and a ninth result to perform a change operation and generate a tenth result; each result includes a public output portion and a zero-knowledge proof portion, the public output portion includes a root ID field and an output list field, a single data entry in the output list field corresponds to the public output of a single run of the target program in zkVM, and the root ID field is used to record the identifier of the target program. The modification operation includes: if the eighth root ID in the eighth result and the ninth root ID in the ninth result are the same, generating a public output portion of the tenth result, wherein the tenth root ID is the same as the eighth root ID, and the tenth output list is obtained by modifying the eighth output list in the eighth result and the ninth output list in the ninth result. According to a seventh aspect, a computer system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor; the processor performs the following steps: running a first program in a zero-knowledge virtual machine (zkVM) based on a first result and a second result to perform a merging operation and generate a third result; wherein each result includes a public output portion and a zero-knowledge proof portion, the public output portion including a root ID field and an output list field, a single data entry in the output list field corresponding to the public output of a single run of the target program in zkVM, and the root ID field used to record the identifier of the target program; the merging operation includes: generating a public output portion of the third result if the first root ID in the first result and the second root ID in the second result are the same, wherein the third root ID is the same as the first root ID, and the third output list includes the first output list in the first result and the second output list in the second result. According to an eighth aspect, a computer system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor; the processor performs the following steps: based on a sixth result, running a fourth program in a zero-knowledge virtual machine (zkVM) to perform a change operation and generate a seventh result; wherein each result includes a public output portion and a zero-knowledge proof portion. The change operation includes: in the sixth result...If the zero-knowledge proof verification passes, a change process is performed based on the sixth public output of the sixth result to obtain the public output portion of the seventh result. According to a ninth aspect, a computer system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor; the processor performs the following steps: running a fourth program in a zero-knowledge virtual machine (zkVM) based on the eighth and ninth results to perform a change operation and generate a tenth result; wherein each result includes a public output portion and a zero-knowledge proof portion, the public output portion including a root ID field (HK 30138782 A 3) and an output list field, a single data entry in the output list field corresponding to the public output of a single run of the target program in zkVM, and the root ID field used to record the identifier of the target program. The change operation includes: generating the public output portion of the tenth result if the eighth root ID in the eighth result and the ninth root ID in the ninth result are the same, wherein the tenth root ID is the same as the eighth root ID, and the tenth output list is obtained by performing a change process on the eighth output list in the eighth result and the ninth output list in the ninth result. According to a tenth aspect, a computer-readable non-volatile storage medium is provided, wherein the storage medium stores a computer program that, when executed by a processor, implements the method described in the first, second, or third aspect above. In summary, the zero-knowledge proof merging method, apparatus, and computer system disclosed in the embodiments of this specification can lower the implementation threshold for zero-knowledge proof merging, improve versatility, and further support recursive merging. The zero-knowledge proof modification method, apparatus, and computer system disclosed in the embodiments of this specification, by introducing a wrapper program, allows users to dynamically perform field expansion or pruning and other dynamic processing operations on the public output of the original client program without modifying the original client program. Brief Description of the Drawings To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments are briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 is a schematic diagram of the data flow of the Unify program running in zkVM disclosed in the embodiments of this specification. Figure 2 is a schematic diagram of the data flow of running the Merge program in zkVM with two Unify run results as input, as disclosed in the embodiments of this specification. Figure 3 is a schematic diagram of the data flow of running the Merge program in zkVM with two Merge run results as input, as disclosed in the embodiments of this specification. Figure 4Figure 5 is a data flow diagram of running a Merge program in zkVM with one Unify run result and one Merge run result as input, as disclosed in an embodiment of this specification. Figure 6 is an execution chain diagram of two original run results to be merged, as disclosed in an embodiment of this specification. Figure 7 is an execution chain diagram of three original run results to be merged, as disclosed in an embodiment of this specification. Figure 8 is an execution chain diagram of four original run results to be merged, produced in one go, as disclosed in an embodiment of this specification. Figure 9 is an execution chain diagram of four original run results to be merged, continuously produced, as disclosed in an embodiment of this specification. Figure 10 is an execution chain diagram of a scenario where the original run results to be merged are dynamically and continuously changing, as disclosed in an embodiment of this specification. Figure 11 is a data flow diagram of running a wrapper program in zkVM, as disclosed in an embodiment of this specification. Figure 12 is a functional structure diagram of a zero-knowledge proof merging device disclosed in an embodiment of this specification. Figure 13 is a schematic diagram of the computer system provided in the embodiments of this specification. Detailed implementation methods are described below with reference to the accompanying drawings. As mentioned above, an improved zero-knowledge proof merging scheme is needed to meet higher requirements in practical applications. Specifically, current technology allows users to design specific merging procedures to merge zero-knowledge proofs, but this native design has the following problems: 1) There is no standard scheme, requiring users to implement the merging logic themselves, which is difficult; 2) The merging logic cannot be reused for different client programs, resulting in poor versatility and preventing it from being provided as a standard service; 3) It does not support recursive merging and cannot support streaming dynamic merging scenarios. Therefore, the embodiments of this specification provide a general and reliable scheme for merging the running results of a general zero-knowledge virtual machine (zkVM). The merging process in this scheme does not require the participation of a centralized system, and smart contracts and other verifiers can verify the legality of multiple executions of the original user program by verifying the merged result. To aid understanding, the main terms mentioned in the embodiments of this specification are explained below. 1) Contract: In this article, "contract" refers to blockchain smart contracts, not commercial contracts. 2) Client Program: Also known as a user program, it is program code that needs to be interpreted, executed, and used to generate zero-knowledge proofs. 3) zkVM: Zero-knowledge virtual machine. It reads input, interprets and executes the client program, completes the execution of the client program, and provides the output specified by the program.4) Prover: The algorithm for generating zero-knowledge proofs, or the party running the corresponding algorithm. This paper considers it as part of zkVM. After zkVM completes the interpretation and execution of the client program, the internal Prover will provide zero-knowledge proofs of the correctness and completeness of the client program execution. 5) Image ID: The unique identifier of the client program. Image ID (·) represents the Image ID of a specific client program. 6) Seal: The zero-knowledge proof generated by Prover, proving the correctness and completeness of the original client program execution result. 7) Journal: The public output of the client program, which will be used as part of the input of the verification program during zero-knowledge proof verification. 8) Receipt: The result generated by the client program after running through zkVM, including Image ID, Journal, and Seal. 9) Verify: The operation within the client program to verify the zero-knowledge proofs in the execution results of other client programs. 10) Commit: The operation by which the client program generates public output; its input parameters will be output to the Journal. 11) Gas: In blockchain networks (primarily the Ethereum network), this is a unit for measuring computational work and used to pay for transactions and smart contract execution. Next, we introduce the general process of running arbitrary client programs in zkVM to generate corresponding zero-knowledge proof results. 1) Client Program Deployment: Using the zkVM toolchain (such as a RISC Zero compiler), the client program's source code is compiled into an executable binary file, or executable machine code. 2) Image ID Generation: zkVM standardizes the client program's machine code (e.g., removing debug information) and calculates its hash value as a unique identifier, ensuring that the subsequently executed program has not been tampered with. 3) Loading Input and Executing the Client Program: zkVM loads the input for the client program. For example, assuming the client program's logic is y=3x, a possible input is x=2. zkVM uses this input as the client program's initial state and interprets and executes the instructions in its machine code, dynamically recording the execution state and intermediate results of each instruction as an execution trajectory. 4) Generate Public Output (Journal): zkVM uses the return value of the client program as a publicly verifiable log file. For example, if the client program is a general computation program, the return value can be the computation result or a "success" message indicating successful computation; if the client program packages a batch of transactions in the blockchain to generate blocks, the return value can be the block hash of the generated blocks. 5) Generate Zero-Knowledge Proofs (Seal): The proof generator in zkVM generates proofs based on the execution trace, Image ID, and Journal.Seal. HK 30138782 A 5 6) Constructing the Verification Credential (Receipt) zkVM packages the program identifier (Image ID), public output (Journal), and zero-knowledge proof (Seal) into a final structured credential for verification by the verifier. The above describes the general process of running a client program in zkVM to obtain the zero-knowledge proof result (or Receipt). The following describes the improved scheme provided by the embodiments in this specification. In the improved scheme, three client programs with a partial compilation order are designed: Unify → Merge → Confirm, to achieve the merging of zero-knowledge proofs. The Merge program is compiled after the Unify program is compiled, and the Confirm program is compiled after the Merge program is compiled. It should be understood that the Image ID of the client program is calculated based on the compiled executable file after the client program is compiled. This means that: 1) the client program cannot know its own Image ID; 2) the Merge program can contain the Image ID of the Unify program, and the Confirm program can contain the Image IDs of both the Unify and Merge programs. Next, the functions of the three client programs—Unify, Merge, and Confirm—will be introduced in turn. 1. Unify Client Program (also referred to as Unify, Unify Program, or Second Program in the text) It should be noted that the "second" in "second program," and similar terms like "first" and "third" elsewhere in the text, are used to distinguish similar things and do not have any other limiting function such as ordering. The Unify program is used to eliminate the format differences between the execution results of the original client program and the execution results of the Unify / Merge program, enabling the Merge program to merge the Journals from multiple zkVM execution results in the same way. It should be noted that the aforementioned original client program (or target program) is the code implementation of business logic in a specific business scenario. For example, the business logic could be the block generation logic in a blockchain scenario, or the user authentication logic in a financial transaction scenario, etc. Furthermore, all execution results in this article refer to the client program's execution results in zkVM. To clarify the hierarchical relationship between the components in the execution result (Receipt), the Image ID, Journal, and Seal in the Receipt can be referred to as the Program ID part, the public output part, and the zero-knowledge proof part, respectively. Further, for each part, fields are used as suffixes. Returning to the functional introduction of the Unify program, see the figure for a visual representation.1. The input to the Unify program includes the execution result of the original client program, specifically including: Image ID (original), which is the Image ID of the original client program, or the target ID of the target program; Journal (original), which is the original public output; and Seal (original), which is the original zero-knowledge proof. Running the Unify program in zkVM yields the execution result of the Unify program, which includes: 1) Program ID part: Figure 1 shows the Image ID (Unify), which is the Image ID of Unify. As mentioned above, this Image ID is temporarily calculated using zkVM tools based on the Unify executable file, and is not pre-compiled in the Unify program. 2) Public output part: Figure 1 shows the Journal (Unify), which specifically includes Temp Image ID (or Temporary ID field), Root Image ID (or Root ID field), and Journal (original). The Journal (original) is included in the output list field (or original output list field), which records the original public output in the merged original execution results. The newly added Temp Image ID and Root Image ID fields allow the Merge program to recursively merge the original execution results. 3) Zero-knowledge proof part: Figure 1 illustrates Seal (Unify), which is generated using the Prover in zkVM based on the program ID and public output data already determined. It should be noted that the program ID and zero-knowledge proof parts in the Unify program's execution results can be understood based on the general process of running client programs in zkVM described above. Regarding the public output part in the Unify program's execution results, the following section uses pseudocode to explain its generation logic, which is the program logic of the Unify program. For example, the pseudocode for the Unify program is as follows: HK 30138782 A 6 0 unify( input : Receipt ) { 1 verify(input) 2 commit({ 3 Root Image ID =input.imageId, 4 Temp Image ID =input.imageId, 5 [ 6 journal =input.journal 7 ] 8}) 9} In the above pseudocode, line 0 indicates that the input to the Unify client program is a single Receipt. It should be understood that UnifyThe valid input for the client program is a single raw execution result. Line 1 indicates the execution of a verify operation, verifying the original zero-knowledge proof in the raw execution result, thereby ensuring the correctness and integrity of the execution using the original client program. It should be understood that subsequent processes are executed only if the verification passes; otherwise, the process terminates. Lines 2-8 indicate the execution of a commit operation, whose input parameters are used as the public output (Journal) of the Unify program. It should be understood that the execution of the client program may involve a large amount of intermediate states, private data, or computational logic, but not all data needs to be made public. The client program explicitly specifies the data to be made public through the commit input parameters to avoid privacy leaks. Observing lines 3-6, the commit operation input parameters include input.imageId and input.journal. Referring to Figure 1: Line 3 indicates that the Image ID (raw) in the raw execution result is passed through to the Root Image ID in the Journal (Unify). It should be understood that passing through means transparent transmission, meaning that the fields are transmitted unchanged without modification. Line 4 indicates that the Image ID (raw) is passed through to the Temp Image ID in the Journal (Unify). Line 6, `input.journal`, indicates that the Journal (raw) is passed through to the output list field in the Journal (Unify). The above describes the functionality and results of the Unify client program. The Unify program performs the first transformation operation on the Journal in the original results, allowing the Merge program to recursively merge based on the transformed Unify results. 2. Merge Client Program (hereinafter referred to as Merge, Merge Program, or First Program) The Merge program can receive zkVM results from two or more client programs as input, and the structure of the publicly exposed output in the Merge results is consistent with that of Unify. To aid understanding, the following example illustrates the Merge program receiving zkVM results from two client programs. There are three possible combinations of these two client programs: Unify and Unify, Merge and Merge, and Unify and Merge (equivalent to Merge and Unify). It should be noted that in this text, the two zkVM execution results received by the Merge program may be referred to as the first result and the second result, and the result obtained by running the Merge program on zkVM based on the first and second results may be referred to as the third result. The following discussion will address these three cases regarding Merge.The program logic is explained below. A. Both received zkVM execution results are Unify execution results (non-recursive merge). It should be understood that if the current input of the Merge program includes the Merge execution result, then this Merge operation is a recursive merge; otherwise, it is not a recursive merge. Referring to Figure 2, in the current case, running the Merge program in zkVM yields the following results: 1) Program ID: In Figure 2, this is illustrated as Image ID (Merge), which is the Image ID of the Merge program. This Image ID is temporarily calculated by the zkVM tool based on the executable file of the Merge program. 2) Public output: In Figure 2, this is illustrated as Journal (Merge), which specifically includes Temp Image ID, Root Image ID, and output list fields. The output list fields include HK 30138782 A 7 Journal 1 (original) and Journal 2 (original) from the two Unify execution results, respectively. The Temp Image ID is taken from the Image ID of the Unify program, and the Root Image ID is taken from the Root Image ID in the Unify execution result, which is the target ID of the target program. 3) Zero-knowledge proof part: Figure 2 shows Seal (Merge), which is generated using Prover in zkVM based on the program ID part and public output part that have been determined in this case. It should be noted that in the current case (the other two cases are similar), the program ID part and zero-knowledge proof part in the execution result of the Merge program can be understood based on the general process of running client programs in zkVM introduced above. For the public output part in the execution result of the Merge program, the generation logic is introduced below with pseudocode. Specifically, the complete pseudocode includes a pre-processing part shared by the three cases, and three conditional branches corresponding to the three cases, as well as a post-processing part after the conditional branches. Next, we will introduce the preamble and conditional branches of the complete pseudocode. For example, the preamble of the Merge program pseudocode is as follows: 0 merge( input1 : Receipt, input2 : Receipt ) { 1 get imageId_1 2 get imageId_2 3 get rootImageId_1 4 get rootImageId_2 5 assert( rootImageId_1 == rootImageId_2 ) 6The code snippet `get tempImageId_1`, `get tempImageId_2`, `get originalJournals_1`, `get originalJournals_2`, and `create newTempImageId` executes the following steps: Line 0 indicates that the Merge program receives two zkVM execution results (two receipts) as input. Lines 1 and 2 extract the Image IDs from the first and second receipts, respectively. Lines 3 and 4 extract the Root Image IDs from the first and second receipts, respectively. Line 5 asserts (or verifies, checks) whether the two extracted Root Image IDs are equal. It's important to understand that only zkVM execution results from the same original client program can be merged. If the assertion passes, the subsequent process continues; otherwise, the process terminates. Lines 6 and 7 extract the Temp Image IDs from the first and second receipts, respectively. Lines 8 and 9 extract the output list fields from the first and second receipts, respectively. Line 10 declares the Temp Image ID variable (not yet assigned a value) in this public output. The above describes the preamble of the Merge program pseudocode. For example, the conditional branch in the Merge program pseudocode corresponding to the current case A is as follows: 11 if (imageId_1 == Unify program ImageID && imageId_2 == Unify program ImageID) { 12 assert( rootImageId_1 == tempImageId_1 ) 13 assert( rootImageId_2 == tempImageId_2 ) 14 newTempImageId := Unify program ImageID 15} Line 11 indicates that if both extracted Image IDs are equal to the Unify program's ImageID, then the subsequent steps under this conditional branch are executed. It's important to understand that because the partial compilation order between the Unify program and the Merge program is Unify → Merge, the Unify program's ImageID can be written into the Merge program, and is a known quantity for the Merge program. Line 12 asserts whether the Root Image ID and Temp Image ID extracted from the first Receipt are equal. It should be understood that in a valid Unify...In the execution result, the Root Image ID and Temp Image ID must be equal, both being the ImageID of the original program. For example, refer to the process of generating the Unify execution result normally described in conjunction with Figure 1. Furthermore, if the assertion passes, the subsequent process is executed; otherwise, the process terminates. HK 30138782 A 8 Line 13 indicates whether the Root Image ID and Temp Image ID extracted from the second Receipt are equal. Line 14 indicates that the newTempImageId variable is assigned the Image ID of the Unify program. The above describes the conditional branch part in the Merge program pseudocode corresponding to the current situation. The above describes situation A, where the input of the Merge program is two Unify execution results. B, where the two zkVM execution results received are both Merge execution results (recursive merging). See Figure 3. In the current situation, running the Merge program in zkVM yields the following execution results: 1) Program ID part and zero-knowledge proof part. For a detailed explanation of these two parts, please refer to the aforementioned description of Figure 2; further details will not be provided here. 2) Public Output Part: Figure 3 illustrates this as Journal (Merge), which specifically includes Temp Image ID, Root Image ID, and the output list field. The output list field includes Journal 1 (raw) and Journal 2 (raw) from the first Merge execution result, and Journal 3 (raw) and Journal 4 (raw) from the second Merge execution result. The Temp Image ID is taken from the Image ID (Merge) in the Merge execution result, and the Root Image ID is taken from the Root Image ID in the Merge execution result, which is the target ID of the target program. Next, the generation logic of the public output part in the current case will be explained using pseudocode. For example, the conditional branch corresponding to the current situation B in the Merge program pseudocode is as follows: 16 if (imageId_1 unkown && imageId_2 unknown) { 17 assert( imageId_1 == imageId_2 ) 18 newTempImageId := imageId_1 19} Line 16 indicates that if both extracted Image IDs are unknown, the subsequent steps under this conditional branch are executed. It is important to understand that Merge...The program cannot know its own Image ID. Therefore, the Image IDs in the two Merge results in this input are unknown to the Merge program, and it is impossible to determine whether they are valid. Line 17 asserts whether the Image IDs in the two Merge results are equal. It should be understood that even unknown quantities must be equal to be valid. Furthermore, if the assertion passes, the subsequent process is executed; otherwise, the process terminates. Line 18 assigns the newTempImageId variable to the Image ID in the first Merge result. It should be understood that it can also be assigned the Image ID in the second Merge result, since their values ​​are the same. The above describes situation B, where the input to the Merge program is two Merge results. C, the two zkVM results received include the Unify result and the Merge result (recursive merging). See Figure 4. In the current case, running the Merge program in zkVM yields the following results: 1) The program ID part and the zero-knowledge proof part. For a description of these two parts, please refer to the aforementioned description of Figure 2, which will not be repeated here. 2) Public Output Part: Figure 4 shows the Journal (Merge) part, which specifically includes the Temp Image ID, Root Image ID, and output list fields. The output list fields include Journal 1 (raw) from the Unify execution result, and Journal 2 (raw) and Journal 3 (raw) from the Merge execution result. The Root Image ID is taken from the Root Image ID in the Unify or Merge execution result, which is the target ID of the target program. Next, the generation logic of the public output part in the current case will be introduced with pseudocode. For example, the conditional branch corresponding to the current state C in the Merge program pseudocode is as follows: 20 if ((imageId_1 == Unify program ImageID && imageId_2 unknown ) { 21 assert( rootImageId_1 == tempImageId_1 ) 22 newTempImageId := imageId_2 23} 24 if (imageId_2 == Unify program ImageID && imageId_1 unknown) { 25 assert( rootImageId_2 ==Line 20 indicates that if the first extracted Image ID is Unify ImageID and the second Image ID is unknown, then the subsequent steps under this conditional branch are executed. Line 21 asserts whether the Root Image ID and Temp Image ID extracted from the first Receipt are equal. It should be understood that in a valid Unify result, the Root Image ID and Temp Image ID must be equal. Furthermore, if the assertion passes, the subsequent process is executed; otherwise, the process terminates. Line 22 assigns the newTempImageId variable to the Image ID in the second Merge result. Lines 24-27 are equivalent to the cases represented by lines 20-23 and can be interpreted accordingly, so they will not be elaborated further. The above describes scenario C, where the input to the Merge program is the result of the Unify operation and the result of the Merge operation. Next, we will introduce the post-processing parts in the complete pseudocode of the Merge program, following the three conditional branches corresponding to the three scenarios described above. For example, the post-processing parts are as follows: Line 28 verify(input1) Line 29 verify(input2) Line 30 commit({ 31 newTempImageId, 32 rootImageId_1, 33 union ( originalJournals_1, originalJournals_2 ) 34}) 35} Line 28 verifies the zero-knowledge proof in the first Receipt. Further, if all verifications pass, the subsequent process is executed; otherwise, the process terminates. Line 29 verifies the zero-knowledge proof in the second Receipt. Further, if all verifications pass, the subsequent process is executed; otherwise, the process terminates. It should be understood that lines 28 and 29 can also be moved to the preceding code section. Lines 30-34 indicate the execution of the commit operation, with its input parameters being passed to the public output (Journal) of the Merge program. Line 31 indicates that the value of the newTempImageId variable is passed to the Temp Image ID in this public output. It's important to understand that the newTempImageId variable is declared in the preamble of the pseudocode and assigned a value in any of the three conditional branches. Line 32 indicates that the first...The Root Image ID in the Receipt is passed through to the Root Image ID in this public output. It should be understood that the Root Image ID from the second Receipt can also be passed through; both are equal, being the target ID of the target program. Line 33 indicates that the output list fields in the first and second Receipts are merged and then passed through to the output list fields in this public output. See Figures 2, 3, and 4 for details. The above describes the post-processing part of the Merge program pseudocode. The above uses the example of the Merge program receiving zkVM execution results from two client programs to introduce the functionality and execution results of the Merge program. In fact, the Merge program can also be configured to support receiving more than two zkVM execution results as input. In this case, these zkVM execution results can also be divided into three cases: D. All received zkVM execution results are Unify execution results. E. All received zkVM execution results are Merge execution results. F. Of the multiple zkVM execution results received, some are Unify execution results and others are Merge execution results. The execution logic of the Merge program for cases D, E, and F can be reasonably inferred based on the descriptions of cases A, B, and C in the previous embodiments. For example, for case D, it is asserted that the Root Image ID extracted from each Unify execution result is equal to the Temp Image ID. For case E, it is asserted that the Image IDs extracted from all Merge execution results are equal. For case F, for each Unify execution result among the multiple zkVM execution results, it is asserted that the Root Image ID extracted from it (HK 30138782 A 10) is equal to the Temp Image ID; if the number of Merge execution results among these multiple zkVM execution results is greater than 1, it is asserted that the Image IDs extracted from all of them are equal. The above describes the functionality and execution results of the Merge client program. The Merge program merges multiple original public outputs and supports recursive merging. 3. The Confirm client program (also referred to as Confirm, Confirm program, or third-party program in this text) eliminates the intermediate variable Temp Image ID from the Merge output, producing a unified and more concise output. It also addresses issues inherent in the Merge client program itself.The issue of questionable validity of the execution results due to the unknown Image ID. Referring to Figure 5, the input to the Confirm client program is the zkVM execution result of the Merge client program. Running the Confirm program in zkVM yields its execution result, which includes: 1) Program ID: In Figure 5, this is illustrated as the Image ID (Confirm), the Image ID of Confirm. As mentioned earlier, this Image ID is temporarily calculated using zkVM tools based on the Confirm executable file, and is not pre-compiled into the Confirm program. 2) Public output: In Figure 5, this is illustrated as the Journal (Confirm), specifically including the Root Image ID (or root ID field) and the Journal List (raw), excluding the Temp Image ID. The Journal List (raw) refers to the output list field, which is passed through to the Merge execution result. The Root Image ID is also passed through to the Merge execution result. 3) Zero-knowledge proof part: Figure 5 illustrates Seal (Confirm), which is generated using the Prover in zkVM based on the program ID and public output data already determined. It should be noted that the program ID and zero-knowledge proof parts in the Confirm program's output can be understood based on the general process of running client programs in zkVM described above. The public output part of the Confirm program's output is explained below with pseudocode to illustrate its generation logic. For example, the pseudocode for the Confirm procedure is as follows: 0 confirm( input: Receipt ) { 1 get imageId 2 get rootImageId 3 get tempImageId 4 get originalJournals 5 if ( image Id == Merge procedure's ImageID ){ 6 assert ( ( tempImageId == Unify procedure's ImageID ) || ( tempImageId == Merge procedure's ImageID ) ) 7} 8 else { 9 panic! 10} 11 verify(input) 12 commit({ 13 rootImageId, 14 originalJournals 15})Line 16} indicates that the input to the Confirm client program is a single Receipt. It should be understood that the valid input to the Confirm client program is a single Merge result. Line 1 extracts the Image ID from the Receipt. Line 2 extracts the Root Image ID from the Receipt. Line 3 extracts the Temp Image ID from the Receipt. Line 4 extracts the Journal List from the Receipt. Line 5 indicates that if the extracted Image ID is the Merge Image ID, the subsequent steps under this conditional branch (HK 30138782 A 11) will be executed. It should be understood that since the partial compilation order of the Unify, Merge, and Confirm programs is Unify → Merge → Confirm, the Image IDs of the Unify and Merge programs can be written into the Confirm program, and are known quantities for the Confirm program. Line 6 asserts whether the extracted Temp Image ID is equal to the Unify Image ID or the Merge Image ID. It's important to understand that in a valid Merge execution result, the Temp Image ID must be either equal to the Unify Image ID or equal to the Merge Image ID. Furthermore, if the assertion passes, the subsequent process is executed; otherwise, the process terminates. Lines 8-10 indicate that if the extracted Image ID is not the Merge Image ID, it means there is a malicious / unknown Image ID input, and the process terminates. Line 11 indicates the execution of the verify operation, verifying the original zero-knowledge proof in the Merge execution result, thereby ensuring the correctness and integrity of the Merge client program execution. It's important to understand that if the verification passes, the subsequent process is executed; otherwise, the process terminates. Lines 12-15 indicate the execution of the commit operation, whose input parameters are used as the public output of the Confirm procedure. Observing lines 13-14, the input parameters for the commit operation include rootImageId and originalJournals. Referring to Figure 5: In line 13, rootImageId indicates that the Root Image ID from the Merge result will be passed through to the Root Image ID in the Journal (Confirm). In line 14, originalJournals indicates that the Root Image ID will be passed through to the Journal (Confirm).The original Journal List in the Merge result is passed through to the original Journal List in the Confirm process. The above description of the valid input for the Confirm program is merely a pseudocode example of the Merge result. It should be noted that, for generality, the valid input for the Confirm program can be configured to also include the Unify result, although merging is unnecessary if the original client program is only executed once. In this case, after receiving the zKVM result, the Confirm program will first determine whether it is the Unify or Merge result before proceeding with further processing. To aid understanding, the following pseudocode example of the Confirm procedure is provided: 0 confirm( input: Receipt ) { 1 get imageId 2 get rootImageId 3 get tempImageId 4 get originalJournals 5 if ( imageId == Unify program ImageID ) { 6 assert ( tempImageId == rootImageId ) 7} 8 else if ( imageId == Merge program ImageID ){ 9 assert ( ( tempImageId == Unify program ImageID ) || ( tempImageId == Merge program ImageID ) ) 10} 11 else { 12 panic! 13} 14 verify(input) 15 commit({ 16 rootImageId, 17 originalJournals 18}) 19} This pseudocode example, compared to the previous pseudocode example that only uses the Merge result as valid input, mainly differs in the addition of steps 5-7. The lines represent conditional branches, which receive the Unify execution result as input. Line 5 indicates that if the extracted Image ID is the Unify Image ID, the subsequent steps under this conditional branch will be executed. Line 6 asserts whether the extracted Temp Image ID is equal to the Root Image ID. It should be understood that in a valid HK 30138782 A 12 Unify execution result, the Root Image ID and Temp Image ID must be equal. Furthermore, if the assertion passes, then...Execute the subsequent process; otherwise, terminate the process. For other lines of code in this pseudocode example, please refer to the relevant descriptions in the preceding embodiments. The above describes the function and execution result of the Confirm client program. The Confirm client program implements the second transformation operation on the Journal in the Merge (or Unify) execution result, eliminating the Temp Image ID in the Journal, thereby producing a unified output result. The above describes the execution result and functional logic of the three client programs used to implement merging: Unify, Merge, and Confirm. It should be noted that in the above pseudocode examples, the program input is a complete structured data Receipt. In practice, it can also be designed so that the necessary fields in the Receipt are passed into the client program separately and used directly within the client program without extraction within the client program. In addition, for the pseudocode corresponding to each client program, the instructions used to verify the legality of the program input (zkVM execution results), including assertion instructions and zero-knowledge proof verification instructions, are generally designed to be executed after assertion instructions, considering the large computational overhead of zero-knowledge proof verification. However, they can also be executed before assertion instructions. The relative execution order between instructions in the pseudocode is not uniquely limited, as long as it conforms to logic. Next, the scheduling strategy for the above three types of programs is introduced. It should be noted that the scheduling strategy can be flexibly set according to the implementation situation. In implementation situation A, the number of original execution results that need to be merged is determined, thus determining how many Merge operations need to be performed before the Confirm operation. Further, in this case A, assuming the Merge client program is configured to receive two zkVM execution results as input each time, the execution chain under 5 possible scenarios is given: Scenario 1: The original client program has 1 execution result. The execution chain in this scenario is: Original client program ⇒ Unify program ⇒ Confirm program. Specifically, for a single original execution result obtained by running the original client program once in zkVM, a Unify execution result is obtained by running the Unify program in zkVM. Then, a Confirm execution result is obtained by running the Confirm program in zkVM based on this Unify execution result. Scenario 2: The original client program has two execution results. The execution chain in this scenario can be seen in Figure 6, which includes the following execution steps: 1) For the two original execution results obtained by running the original client program twice in zkVM, two Unify execution results are obtained by running the Unify program twice in zkVM.1) Unify the results. 2) Based on the two Unify results, run the Merge program in zkVM to obtain the Merge result. 3) Based on the Merge result, run the Confirm program in zkVM to obtain the Confirm result. Scenario 3: The original client program has 3 results. The execution chain in this scenario can be seen in Figure 7, which includes the following execution steps: 1) For the original client program running 3 times in zkVM to obtain 3 original results, run the Unify program 3 times in zkVM to obtain 3 Unify results. 2) Based on two of the Unify results, run the Merge program for the first time in zkVM to obtain the first Merge result. 3) Based on the first Merge result and the other Unify result, run the Merge program for the second time in zkVM to obtain the second Merge result. 4) Based on the second Merge result, run the Confirm program in zkVM to obtain the Confirm result. Scenario 4: The original client program has 4 execution results, and the results are produced all at once. The execution chain in this scenario can be seen in Figure 8, which includes the following execution steps: 1) For the 4 original execution results obtained by running the original client program 4 times in zkVM, run the Unify program 4 times in zkVM to obtain 4 Unify results. 2) Divide the 4 Unify results into two groups, and run the Merge program twice in zkVM to obtain two Merge results. 3) Based on the two Merge results, run the Merge program 3rd time in zkVM to obtain the 3rd Merge result. 4) Based on the third Merge result, run the Confirm program in zkVM to obtain the Confirm result. Scenario 5: The original client program has four execution results, and the results are continuously generated. The execution chain in this scenario can be seen in Figure 9, which includes the following execution steps: 1) The original client program is run twice in zkVM to obtain two original execution results. Based on these, the Unify program is run twice in zkVM to obtain two Unify results. 2) Based on the two Unify results, the first Merge result is obtained in zkVM.The Merge program is run a second time in zkVM to obtain the first Merge result; and the Unify program is run a third time in zkVM to obtain the third Unify result. Based on the first Merge result and the third Unify result, the Merge program is run a second time in zkVM to obtain the second Merge result; and the Unify program is run a fourth time in zkVM to obtain the fourth Unify result. Based on the second Merge result and the fourth Unify result, the Merge program is run a third time in zkVM to obtain the third Merge result. 5) Based on the third Merge result, run the Confirm program in zkVM to obtain the Confirm result. For a larger number of results, they can always be broken down or merged as described in scenarios 1-5 above. The above provides an example of scheduling the execution chain of the three programs in implementation scenario A, where the number of original results to be merged is fixed. In implementation scenario B, the number of original results to be merged is dynamically changing. For example, suppose the original client program is a block generation program, and the blockchain is continuously producing blocks. In this case, one possible scheduling strategy is to continuously and periodically execute the Merge operation serially until the number of original results corresponding to the Merge result reaches or exceeds a predetermined threshold (e.g., 100 blocks), and then perform the Confirm operation. Furthermore, assuming the Merge client program is configured to receive at most 3 zkVM execution results as input each time, and the predetermined threshold for the number of original execution results to be merged is 5, then the execution chain shown in Figure 10 can be referred to. This chain includes the following execution steps: 1) In the first time period, the original client program runs 3 times in zkVM to obtain 3 original execution results, thereby triggering the Unify program to run 3 times in zkVM based on these 3 original execution results, obtaining 3 Unify execution results. 2) In response to the end of the first time period, based on the 3 Unify execution results, the Merge program is run for the first time in zkVM to obtain the first Merge execution result. 3) In the second...Within a time period, assuming the original client program runs twice in zkVM, yielding two original results, this triggers two Unify processes in zkVM based on these two original results, resulting in two Unify results. 4) In response to the end of the second time period, based on the first Merge result and the two Unify results, the Merge process runs a second time in zkVM, yielding a second Merge result. 5) If the number of original results corresponding to the second Merge result reaches a predetermined threshold of 5, this triggers a Confirm process in zkVM based on the second Merge result, yielding a Confirm result. The above provides an illustrative example of the scheduling strategy for HK 30138782 A 14 under implementation scenario B, where the number of original results to be merged is dynamically changing. In Implementation Scenarios B, other conditions can be set to trigger the Confirm operation. For example, if the earliest generation time of multiple original execution results participating in this round of merging (which have already been merged) reaches a predetermined time, the Confirm operation will be triggered even if the multiple original execution results have not reached a predetermined threshold, to prevent excessive waiting time and impact on user experience. It should be noted that for both Implementation Scenarios A and B, the Merge operation can be configured for parallel or serial execution, ordered or unordered execution, depending on actual needs such as business scenarios and hardware conditions. The above describes the scheduling strategies for the three client programs: Unify, Merge, and Confirm, in conjunction with different implementation scenarios. It should be noted that the Confirm execution result will be provided to the verifier as the final merged result of multiple original execution results. Therefore, the verifier only needs to perform a verification operation once based on the Confirm execution result to verify multiple original execution results, effectively reducing verification costs. For example, if the zero-knowledge proof in the Confirm execution result is verified to be valid, it can be determined that multiple zero-knowledge proofs in multiple original execution results are also valid. For example, multiple original execution results can be multiple original zero-knowledge proof results corresponding to multiple blocks (or groups of blocks) in a first blockchain (such as a consortium blockchain with insufficient public access, or a private blockchain). If a client challenges the legitimacy of the block generation process in the first blockchain, the verification logic can be executed by the verifier to verify the Confirm execution result. If the verification passes, it can be proven that all the involved blocks are legitimate. Additionally, in the aforementioned embodiment, Root is added to the public outputs of both Unify and Merge.The Image ID and Temp Image ID fields enable Merge to support recursive merging. In practice, it's also possible to add only the Root Image ID to the public output without adding the Temp Image ID field. While Merge doesn't support recursive merging in this case, it can merge multiple Unify results at once, still offering advantages in versatility and low barrier to entry. Furthermore, since the Temp Image ID field doesn't need to be removed, a Confirm procedure isn't required; the Merge result is directly used as the final output. In summary, this specification's embodiments, using the Merge procedure, enable the merging of zero-knowledge proof results from multiple runs of any original client program in zkVM. Specifically, this specification provides the following implementation: Based on the first and second results, a first program (i.e., the Merge program) is run in the zero-knowledge virtual machine zkVM to perform a merging operation (Merge operation), generating a third result (the Merge result). It should be noted that the first and second results mentioned above can both be Unify execution results, or both be Merge execution results, or one can be an Unify execution result and the other a Merge execution result; in addition, the input of the first program can also include other Unify execution results or Merge execution results. Each result in the input and output of the first program is either an Unify execution result or a Merge execution result. These two types of results have the same data structure, specifically, this data structure includes a program ID part, a public output part, and a zero-knowledge proof part. The public output part includes: a root ID field and an output list field. The root ID field is used to record the identifier of the target program, and a single data entry in the output list field corresponds to the public output of the target program in a single run in zkVM. For this public output part, see also Journal (Unify) or Journal (Merge) in Figure 2. The first program provides a merge operation capability, which includes: generating the public output part of the third result when the first root ID in the first result and the second root ID in the second result are the same. The third root ID in this publicly available output section is the same as the first root ID, and the third output list includes the first output list from the first result and the second output list from the second result. It should be understood that the third root ID is also the same as the first root ID, because the first root ID and the second root ID are the same. In one embodiment, the above merging operation includes the following sub-steps S1-S4: StepS1: Receive the first and second results as input. For example, refer to the description of line 0 in the Merge program pseudocode example above. S2: Extract the first root ID and the first output list from the first result, and extract the second root ID and the second output list from the second result. For example, refer to the descriptions of lines 3, 4, 8, and 9 in the Merge program pseudocode example above. S3: Determine if the first root ID and the second root ID are the same. For example, refer to the description of line 5 in the Merge program pseudocode example above. S4: If they are the same, generate the public output portion of the third result, including assigning the third root ID to the first root ID, and assigning the third output list to the merged result of the first and second output lists. For example, refer to the descriptions of lines 30, 32, and 33 in the Merge program pseudocode example above. The above description of the merging operation may include sub-steps S1 to S4. In another embodiment, steps S1 and S2 can be replaced by receiving the first root ID, the second root ID, the first output list, and the second output list. It should be understood that, similarly, the use of other fields in the first and second results can be extracted internally or directly passed in independently, thus eliminating the need for internal extraction. On the other hand, the input to the first program may include only two zkVM running results (the first result and the second result), or it may include more than two zkVM running results. Therefore, two or more zkVM running results are collectively referred to as a predetermined number of running results. Accordingly, the above merging operation may include generating the public output portion of the third result when all root IDs extracted from the predetermined number of running results are identical. Furthermore, in one embodiment, the public output portion of each result in the input and output of the first program also includes a temporary ID field (Temp Image ID). In this case, the above merging operation needs to determine the temporary ID field in the public output portion of the third result. Specifically, a third temporary ID is determined based on the first program ID in the first result and the second program ID in the second result, and is included in the temporary ID field of the third result. Further, in a specific embodiment, the first program ID and the second program ID are the same, both being the program ID of a predetermined second program (i.e., Unify Image ID); in this case, determining the third temporary ID may include: determining the first program ID as the third temporary ID. For this, please refer to the aforementioned embodiment for case A: Merge.The program receives two zkVM results that are both Unify execution results. For example, see lines 11 and 14 of the Merge program pseudocode example. In another specific embodiment, the first program ID and the second program ID are both unknowns; in this case, determining the third temporary ID may include: determining whether the first program ID and the second program ID are the same; if they are the same, the first program ID is determined as the third temporary ID. For this, see the description of case B in the aforementioned embodiment: the Merge program receives two zkVM execution results that are both Merge execution results; for example, see lines 16 and 18 of the Merge program pseudocode example. In yet another specific embodiment, the first program ID is an unknown, and the second program ID is the program ID of a predetermined second program; in this case, determining the third temporary ID may include: determining the first program ID as the third temporary ID. For this, please refer to the description of Case C in the aforementioned embodiments: the two zkVM execution results received by the Merge program include the Unify execution result and the Merge execution result; for example, see lines 20, 22, 24, and 26 of the Merge program pseudocode example. The above describes the determination of the third root ID in the public output portion of the third result. Furthermore, in one embodiment, during the merge operation, generating this public output portion also requires meeting the following conditions: the first zero-knowledge proof in the first result and the second zero-knowledge proof in the second result are both verified, and the first root ID and the second root ID are the same. For this, please refer to lines 5, 28, and 29 of the aforementioned pseudocode example for the Merge program. By performing the merge operation as described above, the public output portion of the third result can be obtained. It should be understood that the third result also includes a program ID part and a zero-knowledge proof part. The program ID can be obtained by calculating the code digest of the first program, and the zero-knowledge proof part can be generated based on the program ID part and the public output part of the third result. For details, please refer to the foregoing introduction to the general process of running any client program in zkVM. HK 30138782 A 16 According to another embodiment, for the above-mentioned second result, assuming it is a Unify execution result, in this case, before running the first program, it further includes: running the second program (Unify program) in the zkVM based on the first original result to perform the first transformation operation and generate the second result. It should be understood that the case where the first result is a Unify execution result can be similarly deduced. It should be noted that the above-mentioned first original result is generated by running the target program in the zkVM, specifically...Please refer to the description of the original execution result in the foregoing embodiments. By performing the first transformation operation described above, the public output portion of the second result can be obtained, specifically including: setting the root ID field and temporary ID field (if any) in the public output portion to the program ID part of the first original result, that is, the target ID of the target program; and setting the output list field in the public output portion to consist of the first public output in the first original result. For this, please also refer to the description of lines 2-8 in the pseudocode example of the Unify program described above. Furthermore, in a specific embodiment, generating this public output portion in the first transformation operation requires meeting the condition that the first original zero-knowledge proof in the first original result is verified. For this, please also refer to the description of line 1 in the pseudocode example of the Merge program described above. The above describes the execution of the first transformation operation to obtain the public output portion of the second result. It should be understood that the second result also includes a program ID part and a zero-knowledge proof part. The program ID can be obtained by calculating the code digest of the second program, and the zero-knowledge proof part can be generated based on the program ID part and the public output part of the second result. For details, please refer to the aforementioned general process for running any client program in zkVM. According to another embodiment, after generating the third result, a Confirm operation can be performed on it. Specifically, based on the third result, a third program (i.e., the Confirm program) is run in zkVM to perform a second transformation operation, generating a fourth result. The public output part of the fourth result has the temporary ID field removed compared to the third result. By performing the above second transformation operation, the public output part of the second result can be obtained, specifically including: setting the root ID field in the fourth result to the third root ID in the third result, and setting the output list field in the fourth result to consist of the third output list in the third result. For further details, please refer to the aforementioned description of the pseudocode example of the Confirm program, such as lines 13 and 14 of the pseudocode example that only supports Merge execution results as input. In one embodiment, generating the publicly available output portion in the first transformation operation also requires that the third zero-knowledge proof in the third result is verified. For further details, please refer to the aforementioned description of the pseudocode example for the Confirm program, such as line 11 of the pseudocode example that only supports the Merge result as input. The above describes the publicly available output portion of the fourth result obtained by performing the second transformation operation. It should be understood that the fourth result also includes a program ID portion and a zero-knowledge proof portion, where the program ID can be obtained by calculating the code digest of the third program, and the zero-knowledge proof portion can be based on the program ID of the fourth result.The output is generated in part and in part, and for details, please refer to the aforementioned general process for running any client program in zkVM. Furthermore, regarding the triggering conditions for the Confirm operation, in one business scenario, the number of original execution results to be merged is dynamically changing. For example, in a payment transaction scenario, the number of transactions changes dynamically, and the number of execution results for authenticating transaction users also changes dynamically. In this case, after obtaining the third result, it can be determined whether the number of data entries in the output list fields has reached a predetermined threshold, that is, whether the number of currently merged original results has reached a predetermined threshold. If it has, then a third program is run in zkVM based on the third result. In another business scenario, the number of original execution results to be merged is fixed, such as in a voting scenario where the number of participants is fixed, and the number of voting program execution results is also fixed. In this case, the scheduling strategy for the Unify, Merge, and Confirm programs can be directly designed, and the Confirm operation is executed according to the scheduling strategy. For the introduction of the scheduling strategies in the above two business scenarios, please refer to the relevant descriptions in the aforementioned embodiments, for example, the relevant explanations of Figures 6 to 10. In summary, the zero-knowledge proof merging scheme disclosed in the embodiments of this specification achieves the following: 1) Through the Unify operation, the difference between the execution result of the original client program and the execution result of the Unify / Merge program (HK 30138782 A 17 format) is eliminated, enabling the Merge operation to merge the Journal from several inputs in the same way. 2) In the Journal of the execution results of Unify and Merge, the scheme designs Root Image ID and Temp Image ID fields. By passing through the Root Image ID, merging the original client program's Journal, and selectively passing through the Temp Image ID, the Merge and Confirm operations can ultimately distinguish between the original client program and the client program of the merging scheme, allowing the Merge operation to achieve recursive calls. 3) There is a clear partial order relationship between the Unify, Merge, and Confirm programs in the scheme, enabling the above three client programs to automatically complete the identification and comparison of a specific Image ID without using any Image ID as an input parameter. 4) The solution is universal and applicable to different original client programs. Therefore, the solution has a low barrier to entry and requires no user development. The above describes the zero-knowledge proof merging scheme disclosed in the embodiments of this specification. In this merging scheme, the input to the Merge program is the results of running two or more zkVMs, and the program's main function is to perform merging of the original Journal...The applicant discovered a modification scheme based on the idea of ​​merging the original client program and designing a wrapper program whose input can be one or more zkVM execution results. The program's function is to modify these zkVM execution results, such as pruning. Specifically, in some zero-knowledge proof application scenarios, the public output of the original client program contains redundant fields, which increases the storage and transmission costs of related data, as well as the verification costs of zero-knowledge proofs. It should be noted that, for clarity, the original client program here has the same meaning as the original client program in the aforementioned merging scheme. However, in the actual modification scheme, the "program" in the "program zkVM execution result" input to the wrapper program is not limited to the original client program; it can also be other client programs, such as the aforementioned Confirm program. For example, in a scenario where zero-knowledge proofs are performed on block data of the first blockchain, the public output of the client program simulating blockchain transactions may contain some fields unrelated to the business logic. If the generated public output is submitted to the verifier unchanged, it will result in a large amount of useless data transmission, increasing both data storage and transmission costs, as well as the computational load for transaction input parameters and zero-knowledge proof verification, thus increasing verification costs. An intuitive modification method is to directly adjust the public output of the original client program, removing fields unrelated to the target business logic. However, this would fundamentally damage the original client program code, requiring direct modification of both the original client program and the verification logic for any minor adjustments. Based on the above observations and analysis, and combined with the ideas of the aforementioned merging scheme, the applicant proposes a zero-knowledge proof modification scheme that, without modifying the original client program, uses a newly designed wrapper program to trim (but is not limited to trimming) the public output of the original client program, removing redundant fields and retaining only those relevant to the business logic. This reduces the storage, transmission, and verification costs of related data. The wrapper program (or fourth program) is introduced below. The wrapper program is used to dynamically process the public output of the original client program, such as trimming or adding predefined fields. Intuitively, see Figure 11, where the gray area represents the execution process of the original client program in zkVM, and the white area represents the new processing flow added in the change plan. Specifically, first, the program input of the original client program is loaded into zkVM, and the original client program is run to obtain its execution result, which includes: Image ID (original), i.e., the Image ID of the original client program; Journal (original), i.e., the public output of the original client program; and Seal (original), i.e., the original zero-knowledge proof. Then, the execution result of the original client program is loaded into zkVM as the program input of the wrapper program, and the wrapper program is run to obtain its execution result, which includes: Image ID.ID (Wrapper), i.e., the Image ID of the wrapper; Journal (Wrapper), i.e., the public output of the wrapper; Seal (Wrapper), i.e., the zero-knowledge proof obtained by running the wrapper. It should be noted that the program ID and zero-knowledge proof parts in the wrapper's output can be understood based on the general process of running client programs in zkVM described above. Regarding the public output part of the wrapper's output, its generation logic is explained below with pseudocode, which is also the program logic of the wrapper. For example, the pseudocode of the wrapper is as follows: 0 Wrapper(input: Receipt) { 1 assert(input.imageId == ImageID(original client program)) 2 verify (input) 3 newJournal := process(input.journal) 4 commit(newJournal) 5} In the above pseudocode, line 0 indicates that the input of the wrapper is a single Receipt. Line 1 asserts whether the Image ID in the Receipt is equal to the Image ID of the original client program. This confirms that the input result is indeed the result of the specified original client program, preventing a break in the zero-knowledge proof / verification chain and thus preventing the wrapper program from acting maliciously. Line 2 verifies the zero-knowledge proof in the Receipt, ensuring the correctness and integrity of the original client program's execution. Line 3 processes the public output (input.journal) of the original client program, obtaining the public output field of this wrapper program, denoted as newJournal. Line 4 commits the operation, using its input parameter newJournal as the public output of this wrapper program. Regarding the processing logic for the original public output in line 3 above, taking field pruning as an example, assume Journal (original) has three fields: X, Y, and Z. Assuming the final verifier of the zero-knowledge proof consumes only two fields, X and Z, the pseudocode for the `process()` operation in the corresponding wrapper is as follows: `process ( journal : struct { X, Y, Z} ) { return { journal.X, journal.Z}}` It should be noted that the above description of the wrapper primarily focuses on a single wrapper, with its input being the result of a single run of the original client program, and the processing logic for the original public output being field pruning. In reality...1) Besides field trimming, the wrapper program can dynamically add fields or perform complex business logic such as splicing, processing, and filtering public data from multiple original client programs. 2) The wrapper program can be nested in a multi-level chain, and each layer of the wrapper program can have different logic. Therefore, the final verifier (such as a smart contract) verifies the zero-knowledge proof in the wrapper program's execution result, not the zero-knowledge proof in the original client program's execution result. In summary, the embodiments in this specification, with the help of the wrapper program, can achieve modification processing of the public output in the results generated by running any original client program once or multiple times in zkVM. This specification provides the following implementation method: In one implementation method, a fourth program (i.e., the wrapper program) is run in the zero-knowledge virtual machine zkVM based on the sixth result to perform the modification operation and generate a seventh result. It should be noted that the sixth result can be the execution result of any client program on zkVM, where any client program can be the original client program or the wrapper program, etc. In addition, the input of the fourth program can also include other zkVM execution results besides the sixth result. In a broad sense, the wrapper program can include the Unify program, Merge program, and Confirm program mentioned above. For example, the sixth result can be the fourth result (Confirm execution result) mentioned above. It should be understood that each of the sixth and seventh results mentioned above is a zkVM execution result, including the public output portion, the zero-knowledge proof portion, and the program ID portion. The above change operation can include: if the sixth zero-knowledge proof in the sixth result passes verification, performing change processing based on the sixth public output in the sixth result to obtain the public output portion of the seventh result. For this, please also refer to the relevant descriptions in lines 2, 3, and 4 of the aforementioned wrapper program pseudocode example. In one embodiment, performing change processing in the change operation also requires the condition that the sixth program ID in the sixth result is a predetermined program ID. For example, the sixth result is the fourth result (Confirm execution result) mentioned above, where the predetermined program ID is the target ID of the aforementioned target program. Additionally, please also refer to the relevant description in line 1 of the aforementioned wrapper program pseudocode example. In one embodiment, if the input of the fourth program also includes other zkVM execution results, then the modification process must meet the following conditions: the zero-knowledge proofs contained in each execution result in the input of the fourth program are all verified, and / or, the program ID portion in each execution result is a predetermined program ID. On the other hand, in one embodiment, the above modification process may include: adding or deleting predetermined fields, field concatenation, field filtering, etc. The above describes the public output portion of the seventh result obtained by performing modification operations. It should be understood that the seventh result also includes the program...The process consists of an ID portion and a zero-knowledge proof portion. The program ID can be obtained by calculating the code digest of the seventh program. The zero-knowledge proof portion is generated based on the program ID portion and the public output portion of the seventh result. For details, please refer to the aforementioned general process for running any guest program in zkVM. In the above implementation, the description focuses on the fact that the input of the wrapper program includes at least one zkVM execution result. Next, another implementation is given, focusing on the fact that the input of the wrapper program includes at least two zkVM execution results. In this other implementation, a fourth program can be run in the zero-knowledge virtual machine zkVM based on the eighth and ninth results to perform a change operation and generate a tenth result. Each result includes a public output portion and a zero-knowledge proof portion. The public output portion includes a root ID field and an output list field. A single data entry in the output list field corresponds to the public output of a single run of the specified program (such as the target program described above) in zkVM. The root ID field is used to record the identifier of the specified program. The aforementioned modification operation includes: when the eighth root ID in the eighth result and the ninth root ID in the ninth result are the same, generating the public output portion of the tenth result, wherein the tenth root ID is the same as the eighth root ID, and the tenth output list is obtained by modifying the eighth output list in the eighth result and the ninth output list in the ninth result. It should be noted that the modification process may include at least one of the following: merging, deleting a predetermined field, or adding a predetermined field. If the modification process is merging, then for this implementation method, please refer to the description of the merging scheme in the foregoing embodiments, and the aforementioned eighth, ninth, and tenth results may correspond to the aforementioned first, second, and third results. Furthermore, for the description of the modification process, please refer to the relevant introduction in the foregoing embodiments. In summary, by adopting the zero-knowledge proof modification scheme disclosed in the embodiments of this specification, and by introducing a wrapper program, the originally directly coupled "original client program" and "verification program" are isolated by the wrapper program, and changes to the original client program no longer directly affect the verification logic of the verification program. The packaging program's ability to dynamically process public output allows users to perform dynamic processing operations such as field expansion or pruning on the public output of the original client program without modifying it. When the verifier is software sensitive to verification costs, pruning unnecessary fields in the public output of the original client program reduces the amount of data input to the software, thereby lowering the cost of ultimately verifying zero-knowledge proofs. Corresponding to the above-mentioned merging and modification methods for zero-knowledge proofs, the embodiments of this specification also disclose merging and modification devices. Specifically, as shown in Figure 12.This is a functional structure diagram of the zero-knowledge proof merging device disclosed in the embodiments of this specification. As shown in Figure 12, the merging device 1200 includes the following functional modules: a first program running module 1210, configured to run a first program in a zero-knowledge virtual machine zkVM based on a first result and a second result to perform a merging operation and generate a third result; wherein each result includes a public output part and a zero-knowledge proof part, the public output part includes a root ID field and an output list field, a single data in the output list field corresponds to the public output of the target program in a single run in zkVM, and the root ID field is used to record the identifier of the target program; wherein the merging operation includes: generating the public output part of the third result when the first root ID in the first result and the second root ID in the second result are the same, wherein the third root ID is the same as the first root ID, and the third output list includes the first output list in the first result and the second output list in the second result. In one embodiment, each result also includes a program ID part, and the public output part also includes a temporary ID field. The merging operation further includes: determining a third temporary ID based on the first program ID in the first result and the second program ID in the second result, and including it in the temporary ID field of the third result. Further, in one specific embodiment, the first program ID and the second program ID are the same, both being program IDs of a predetermined second program. Determining the third temporary ID based on the first program ID in the first result and the second program ID in the second result includes: determining the first program ID as the third temporary ID. In another specific embodiment, the first program ID is an unknown quantity, and the second program ID is a program ID of a predetermined second program. Determining the third temporary ID based on the first program ID in the first result and the second program ID in the second result includes: determining the first program ID as the third temporary ID. In yet another specific embodiment, both the first program ID and the second program ID are unknown quantities. Determining the third temporary ID based on the first program ID in the first result and the second program ID in the second result includes: determining whether the first program ID and the second program ID are the same; if they are the same, determining the first program ID as the third temporary ID. In one embodiment, each result further includes a program ID portion. The first program execution module 1210 is specifically configured as follows: the first zero-knowledge proof in the first result and the second zero-knowledge proof in the second result are both verified, and the first root ID and the second root ID...Under the same conditions, the public output portion of the third result is generated; the code digest of the first program is obtained and included in the program ID portion of the third result; based on the program ID portion and the public output portion of the third result, the zero-knowledge proof portion of the third result is generated. In one embodiment, the merging device 1200 further includes a second program running module 1220, configured to: run the second program in the zkVM based on the first original result to perform a first transformation operation and generate the second result, wherein the first original result is generated by running the target program in the zkVM. Further, in a specific embodiment, the first original result includes the target ID of the target program in its program ID portion and includes a first public output in its public output portion. The first transformation operation includes: setting both the root ID field and the temporary ID field in the second result to the target ID; setting the output list field in the second result to be composed of the first public output. In one specific embodiment, the second program execution module 1220 is specifically configured to: generate a public output portion of the second result if the first original zero-knowledge proof in the first original result passes verification; obtain a code digest of the second program, which is included in the program ID portion of the second result; and generate a zero-knowledge proof portion of the second result based on the program ID portion and the public output portion. In one embodiment, the merging device 1200 further includes a third program execution module 1230, configured to: run a third program in the zkVM based on the third result to perform a second transformation operation and generate a fourth result, wherein the public output portion of the fourth result has the temporary ID field deleted relative to the third result. Further, in one specific embodiment, the second transformation operation includes: setting the root ID field in the fourth result to the third root ID in the third result, and setting the output list field in the fourth result to be composed of the third output list in the third result. In one specific embodiment, the third program execution module 1230 is specifically configured to: generate a public output portion of the fourth result if the third zero-knowledge proof verification in the third result passes; obtain the code digest of the third program, which is included in the program ID portion of the fourth result; and generate a zero-knowledge proof portion of the fourth result based on the program ID portion and the public output portion. In another specific embodiment, the third program execution module 1230 is specifically configured to: run the third program in the zkVM based on the third result if the number of data entries in the output list field of the third result reaches a predetermined threshold.In one embodiment, the first program execution module 1210 is specifically configured to: run the first program in the zkVM based on a predetermined number of results, the predetermined number of results including the first result and the second result. Specifically, generating the public output portion of the third result when the first root ID in the first result and the second root ID in the second result are the same includes: generating the public output portion of the third result when all root IDs extracted from the predetermined number of results are the same. HK 30138782 A 21 On the other hand, in a specific embodiment, the merging device 1200 further includes a fourth program execution module 1240, configured to: run the fourth program in the zkVM based on the fourth result to perform a change operation and generate a fifth result, the public output portion of which has been changed relative to the fourth result. Furthermore, in one example, the fourth program execution module 1240 is specifically configured to: when the zero-knowledge proof in the fourth result passes verification, and / or the fourth program ID in the fourth result is a predetermined target ID of the target program, modify the public output portion of the fourth result to obtain the public output portion of the fifth result; obtain the code digest of the fourth program, which is included in the program ID portion of the fifth result; and generate the zero-knowledge proof portion of the fifth result based on the program ID portion and the public output portion of the fifth result. Further, in a specific example, the public output portion of the fifth result deletes or adds predetermined fields relative to the fourth result. Embodiments of this specification also disclose a zero-knowledge proof modification device, which includes: a fourth program execution module configured to run a fourth program in a zero-knowledge virtual machine zkVM based on a sixth result to perform a modification operation and generate a seventh result; wherein each result includes a public output portion and a zero-knowledge proof portion; wherein the modification operation includes: when the sixth zero-knowledge proof in the sixth result passes verification, performing modification processing based on the sixth public output of the sixth result to obtain the public output portion of the seventh result. In one embodiment, each result further includes a program ID portion. The fourth program execution module is specifically configured as follows: if the sixth program ID in the sixth result is a predetermined program ID, and the sixth zero-knowledge proof verification passes, perform a change process based on the sixth public output to obtain the public output portion of the seventh result; obtain the code digest of the fourth program, which is included in the program ID portion of the seventh result; and generate the zero-knowledge proof portion of the seventh result based on the program ID portion and the public output portion. This specification also discloses another zero-knowledge proof change apparatus, which includes:The fourth program execution module is configured to run a fourth program in a zero-knowledge virtual machine (zkVM) based on the eighth and ninth results to perform a modification operation and generate a tenth result. Each result includes a public output portion and a zero-knowledge proof portion. The public output portion includes a root ID field and an output list field. Each data entry in the output list field corresponds to the public output of the target program in a single run within zkVM. The root ID field records the identifier of the target program. The modification operation includes generating the public output portion of the tenth result if the eighth root ID in the eighth result and the ninth root ID in the ninth result are the same, where the tenth root ID is the same as the eighth root ID. The tenth output list is obtained by modifying the eighth output list in the eighth result and the ninth output list in the ninth result. It should be understood that, for ease of description, the above device is described by functionally divided into various modules. Of course, in implementing this specification, the functions of each module can be implemented in one or more software and / or hardware components. This specification also provides a computer-readable non-transitory storage medium storing a computer program that, when executed by a processor, can be used to perform one or more steps of one or more methods described or illustrated herein, or to provide the functionality described or illustrated herein. Here, one or more computer-readable non-transitory storage media may include one or more semiconductor-based or other integrated circuits (ICs) (e.g., field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs)), hard disk drives (HDDs), hybrid hard disk drives (HHDs), optical disks, optical disk drives (ODDs), magneto-optical disks, magneto-optical disk drives, floppy disks, floppy disk drives (FDDs), magnetic tape, solid-state drives (SSDs), RAM drives, secure digital cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. The computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. HK 30138782 A 22 This specification also provides a computer system. Figure 13 illustrates an exemplary computer system 600. In certain embodiments, one or more computer systems 600 perform one or more steps of one or more methods described or illustrated herein. In certain embodiments, one or more computer systems 600 provide the functionality described or illustrated herein. In certain embodiments, software running on one or more computer systems 600 performs one or more steps of one or more methods described or illustrated herein, or provides the functionality described or illustrated herein. Specific embodiments include one or more...Computer system 600 refers to one or more parts of a computer system 600. Herein, references to a computer system may include computing devices, and vice versa, where appropriate. Furthermore, references to a computer system may include one or more computer systems, where appropriate. This disclosure contemplates any suitable number of computer systems 600. This disclosure envisions computer system 600 taking any suitable physical form. By way of example and not limitation, computer system 600 may be an embedded computer system, a system-on-a-chip (SOC), a single-board computer system (SBC) (e.g., a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a computer system network, a mobile phone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these. Where appropriate, computer system 600 may include one or more computer systems 600; single or distributed; spanning multiple locations; spanning multiple machines; spanning multiple data centers; or residing in the cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 600 may perform one or more steps of one or more methods described or illustrated herein without material space or time limitations. By way of example and not limitation, one or more computer systems 600 may perform one or more steps of one or more methods described or illustrated herein in real time or in batch mode. Where appropriate, one or more computer systems 600 may perform one or more steps of one or more methods described or illustrated herein at different times or at different locations. In a particular embodiment, computer system 600 includes processor 602, memory 604, storage 606, input / output (I / O) interface 608, communication interface 610, and bus 612. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement. In a particular embodiment, processor 602 includes hardware for executing instructions, such as instructions constituting a computer program. By way of example and not limitation, in order to execute instructions, processor 602 may retrieve (or fetch) instructions from internal registers, internal caches, memory 604, or memory 606; decode and execute them; and then write one or more results to internal registers, internal caches, memory 604, or memory 606. In certain embodiments, processor 602 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 602 where appropriate.This includes any suitable number of suitable internal caches. By way of example and not limitation, processor 602 may include one or more instruction caches, one or more data caches, and one or more translation back lookup buffers (TLBs). Instructions in the instruction cache may be copies of instructions in memory 604 or memory 606, and the instruction cache may accelerate retrieval of those instructions by processor 602. Data in the data cache may be copies of data in memory 604 or memory 606 for instruction operations executed at processor 602; results of previous instructions executed at processor 602 for subsequent instructions executed at processor 602 to access or write to memory 604 or memory 606; or other suitable data. The data cache may accelerate read or write operations of processor 602. The TLB may accelerate virtual address translation of processor 602. In certain embodiments, processor 602 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates that processor 602 may include any suitable number of suitable internal registers where appropriate. Where appropriate, processor 602 may include one or more arithmetic logic units (ALUs), may be a multi-core processor, or may include one or more processors 602. Although this disclosure describes and illustrates specific processors, this disclosure contemplates any suitable processor. In a particular embodiment, memory 604 includes main memory for storing instructions to be executed by processor 602 or data to be operated on by processor 602. By way of example and not limitation, computer system 600 may load instructions from memory 606 or another source (e.g., another computer system 600) into memory 604. Processor 602 may then load instructions from memory 604 into internal registers or internal caches. To execute instructions, processor 602 may retrieve instructions from internal registers or internal caches and decode them. During or after instruction execution, processor 602 may write one or more results (which may be intermediate or final results) to internal registers or internal caches. Processor 602 may then write one or more of these results to memory 604. In a particular embodiment, processor 602 executes only instructions in one or more internal registers, internal caches, or memory 604 (as opposed to memory 606 or elsewhere), and operates only on data in one or more internal registers, internal caches, or memory 604 (as opposed to memory 606 or elsewhere). One or more memory buses (each memory bus may include ground...)Address buses and data buses can couple processor 602 to memory 604. As described below, bus 612 may include one or more memory buses. In a particular embodiment, one or more memory management units (MMUs) reside between processor 602 and memory 604 and facilitate access to memory 604 requested by processor 602. In a particular embodiment, memory 604 includes random access memory (RAM). Where appropriate, the RAM may be volatile memory. Where appropriate, the RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Furthermore, where appropriate, the RAM may be single-port or multi-port RAM. This disclosure contemplates any suitable RAM. Where appropriate, memory 604 may include one or more memories 604. Although this disclosure describes and illustrates specific memories, this disclosure contemplates any suitable memory. In a particular embodiment, memory 606 includes a large-capacity memory for data or instructions. By way of example and not limitation, storage 606 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk drive, a magneto-optical disk drive, a magnetic tape drive, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Storage 606 may include removable or non-removable (or fixed) media where appropriate. Storage 606 may be internal or external to computer system 600 where appropriate. In a particular embodiment, storage 606 is a non-volatile solid-state memory. In a particular embodiment, storage 606 includes read-only memory (ROM). The ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically changeable ROM (EAROM), or flash memory, or a combination of two or more of these, where appropriate. This disclosure contemplates large-capacity storage 606 in any suitable physical form. Storage 606 may include one or more storage control units that facilitate communication between processor 602 and storage 606 where appropriate. Storage 606 may include one or more storage units 606 where appropriate. Although this disclosure describes and illustrates specific storage, any suitable storage is contemplated herein. In a particular embodiment, I / O interface 608 includes hardware, software, or both, providing one or more interfaces for communication between computer system 600 and one or more I / O devices. Where appropriate, computer system 600 may include one or more of these I / O devices. One or more of these I / O devices may enable human and computer system 600Communication between. By way of example and not limitation, I / O devices may include keyboards, keypads, microphones, monitors, mice, printers, scanners, speakers, still cameras, styluses, graphics tablets, touchscreens, trackballs, cameras, other suitable I / O devices, or combinations of two or more of these devices. I / O devices may include one or more sensors. This disclosure contemplates any suitable I / O devices and any suitable I / O interface 608 for them. Where appropriate, I / O interface 608 may include one or more devices or software drivers that enable processor 602 to drive one or more of these I / O devices. Where appropriate, I / O interface 608 may include one or more I / O interfaces 608. Although this disclosure describes and illustrates specific I / O interfaces, this disclosure contemplates any suitable I / O interface. In a particular embodiment, communication interface 610 includes hardware, software, or both, providing one or more interfaces for communication (e.g., packet-based communication) between computer system 600 and one or more other computer systems 600 or one or more networks. By way of example and not limitation, communication interface 610 may include a network interface controller (NIC) or network adapter for communicating with Ethernet or other wired networks, or a wireless NIC (WNIC) or wireless adapter for communicating with wireless networks such as Wi-Fi networks. This disclosure contemplates any suitable network and any suitable communication interface 610 for that network. By way of example and not limitation, computer system 600 may communicate with one or more portions of an ad hoc network, personal area network (PAN), local area network (LAN), wide area network (WAN), metropolitan area network (MAN), or the Internet, or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. By way of example, computer system 600 may communicate with a wireless PAN (WPAN) (e.g., Bluetooth WPAN), a Wi-Fi network, a Wi-Fi Max network, a cellular telephone network (e.g., a Global System for Mobile Communications (GSM) network), or other suitable wireless networks, or a combination of two or more of these networks. Where appropriate, computer system 600 may include any suitable communication interface 610 for any of these networks. Where appropriate, communication interface 610 may include one or more communication interfaces 610. Although specific communication interfaces are described and illustrated in this disclosure, any suitable communication interface is contemplated herein. In a particular embodiment, bus 612 includes hardware, software, or two-way coupling of components of computer system 600 to each other.By way of example and not limitation, bus 612 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), an HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or another suitable bus, or a combination of two or more of these buses. Where appropriate, bus 612 may include one or more buses 612. Although this disclosure describes and illustrates specific buses, this disclosure contemplates any suitable bus or interconnect. Those skilled in the art will appreciate that the functionality described in the above one or more examples can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention. HK 30138782 A 1 Claims 1. A method for merging zero-knowledge proof results, comprising: running a first program in a zero-knowledge virtual machine zkVM based on a first result and a second result to perform a merging operation and generate a third result; wherein each result includes a public output portion and a zero-knowledge proof portion, the public output portion including a root ID field and an output list field, a single data entry in the output list field corresponding to the public output of a single run of the target program in zkVM, the root ID field being used to record the identifier of the target program; the merging operation comprising: generating a public output portion of the third result when the first root ID in the first result and the second root ID in the second result are the same, wherein the third root ID is the same as the first root ID, and the third output list including the first output list in the first result and the second output list in the second result. 2. The method according to claim 1, wherein each result further includes a program ID portion, the public output portion further includes a temporary ID field; the merging operation further includes: based on the first program ID in the first result and the second program ID in the second result.3. The method according to claim 2, wherein the first program ID and the second program ID are the same, both being program IDs of a predetermined second program; determining the third temporary ID based on the first program ID in the first result and the second program ID in the second result includes: determining the first program ID as the third temporary ID. 4. The method according to claim 2, wherein the first program ID is an unknown quantity, and the second program ID is a program ID of a predetermined second program; determining the third temporary ID based on the first program ID in the first result and the second program ID in the second result includes: determining the first program ID as the third temporary ID. 5. The method according to claim 2, wherein the first program ID and the second program ID are both unknown quantities; determining the third temporary ID based on the first program ID in the first result and the second program ID in the second result includes: determining whether the first program ID and the second program ID are the same; if they are the same, determining the first program ID as the third temporary ID. 6. The method of claim 1, wherein each result further includes a program ID portion; performing a merging operation to generate a third result includes: generating a public output portion of the third result if both the first zero-knowledge proof in the first result and the second zero-knowledge proof in the second result are verified, and the first root ID and the second root ID are the same; obtaining a code digest of the first program, which is included in the program ID portion of the third result; and generating the zero-knowledge proof portion of the third result based on the program ID portion and the public output portion of the third result. 7. The method of claim 3 or 4, wherein before running the first program, it further includes: running the second program in the zkVM based on the first original result to perform a first transformation operation and generate the second result, wherein the first original result is generated by running the target program in the zkVM. 8. The method of claim 7, wherein the first original result includes the target ID of the target program in its program ID portion and a first public output in its public output portion; the first transformation operation includes: setting both the root ID field and the temporary ID field in the second result to the target ID; and setting the output list field in the second result to be composed of the first public output. 9. The method according to claim 7, wherein performing the first conversion operation to generate the second result includes: HK 30138782 A 2If the first original zero-knowledge proof in the first original result passes verification, a public output portion of the second result is generated; a code digest of the second program is obtained, which is included in the program ID portion of the second result; based on the program ID portion and the public output portion of the second result, a zero-knowledge proof portion of the second result is generated. 10. The method of claim 2, wherein, after generating the third result, it further comprises: running a third program in the zkVM based on the third result to perform a second transformation operation to generate a fourth result, wherein the public output portion of the fourth result has the temporary ID field deleted relative to the third result. 11. The method of claim 10, wherein the second transformation operation comprises: setting the root ID field in the fourth result to the third root ID in the third result, and setting the output list field in the fourth result to be composed of the third output list in the third result. 12. The method of claim 10, wherein performing the second transformation operation to generate the fourth result comprises: generating a public output portion of the fourth result if the third zero-knowledge proof verification in the third result passes; obtaining a code digest of the third program, included in the program ID portion of the fourth result; and generating a zero-knowledge proof portion of the fourth result based on the program ID portion and the public output portion of the fourth result. 13. The method of claim 10, wherein running the third program in the zkVM based on the third result comprises: running the third program in the zkVM based on the third result if the number of data entries in the output list field of the third result reaches a predetermined threshold. 14. The method of claim 1, wherein running a first program in a zero-knowledge virtual machine (zkVM) based on a first result and a second result comprises: running the first program in the zkVM based on a predetermined number of results, the predetermined number of results including the first result and the second result; wherein generating a public output portion of the third result when the first root ID in the first result and the second root ID in the second result are the same comprises: generating a public output portion of the third result when all root IDs extracted from the predetermined number of results are the same. 15. The method of claim 10, wherein after generating a fourth result, it further comprises: running a fourth program in the zkVM based on the fourth result to perform a change operation and generate a fifth result, wherein the public output portion of the fifth result has been changed relative to the fourth result. 16. The method of claim 15, wherein performing the change operation to generate the fifth result comprises:If the zero-knowledge proof in the fourth result passes verification, and / or if the fourth program ID in the fourth result is a predetermined target ID of the target program, the public output portion of the fourth result is modified to obtain the public output portion of the fifth result; a code digest of the fourth program is obtained and included in the program ID portion of the fifth result; based on the program ID portion and the public output portion of the fifth result, a zero-knowledge proof portion of the fifth result is generated. 17. The method according to claim 15 or 16, wherein the public output portion of the fifth result deletes or adds predetermined fields relative to the fourth result. 18. A method for modifying a zero-knowledge proof result, comprising: running a fourth program in a zero-knowledge virtual machine zkVM based on a sixth result to perform a modification operation and generate a seventh result; wherein each result includes a public output portion and a zero-knowledge proof portion; the modification operation includes: if the sixth zero-knowledge proof in the sixth result passes verification, performing a modification operation based on the sixth public output of the sixth result to obtain the public output portion of the seventh result. HK 30138782 A 1 Instruction Manual Figure 1 Results of the Unify Client Program Running in zkVM Image ID (Original) Journal (Original) Seal (Original) zkVM (with Prover) Unify Results of the Unify Client Program Running in zkVM Image ID (Unify) Seal (Unify) Journal (Unify) Temp Image ID Root Image ID Journal (Original) Figure 2 HK 30138782 A2. Merge Client Program Execution Results: Image ID (Merge) Seal (Merge) Journal (Merge) Temp Image ID 1 Root Image ID Journal 1 (Original) zkVM (with Prover) Merge Merge Client Program Execution Results: Image ID (Merge) Seal (Merge) Journal (Merge) Temp Image ID Root Image ID Journal 1 (Original) Journal 2 (Original) Journal 2 (Original) Merge Client Program Execution Results: Image ID (Merge) Seal (Merge) Journal (Merge) Temp Image ID 2 Root Image ID Journal 3 (Original) Journal 4 (Original) Journal 3 (Original) Journal 4 (Original) Figure 3 HK 30138782 A 3. Unify Client Program Execution Results: Image ID (Unify) Seal (Unify) Journal (Unify) Temp Image ID 1 Root Image ID Journal 1 (Original) zkVM (with Prover) Merge Merge Client Program Execution Results: Image ID (Merge) Seal (Merge) Journal (Merge) Temp Image ID Root Image ID Journal 1 (Original) Journal 2 (Original) Merge Client Program Execution Results Image ID (Merge) Seal (Merge) Journal (Merge) Temp Image ID 2 Root Image ID Journal 2 (Original) Journal 3 (Original) Journal 3 (Original) Figure 4 zkVM (with Prover) Confirm Confirm Client Program Execution Results Image ID (Confirm) Seal (Confirm) Journal (Confirm) Root Image ID Journal List (Original) Image ID (Merge) Seal (Merge) Journal (Merge) Temp Image ID Root Image ID Journal List (Original)Figure 5 shows the results of the Merge client program. (The rest of the text appears to be a series of symbols and characters, likely from different sources, and doesn't form coherent sentences.) Original client program Unif y Merge Unif y Result 2 Original result 3 Unif y Result 3 Merge Result 2 Original client program Unif y Merge Original result 4 Unif y Result 4 Merge Result 1 Confirm Figure 9 HK 30138782 A 6 Original result 1 Unif y Result 1 Merge Result 1 Figure 1 0 Original client program Unif y Original result 2 Original client program Unif y Merge Original client program Unif y Merge Unif y Result 2 Original result 3 Merge Result 2 Confirm Unif y Result 3 Original result 4 Original client program Unif y Original client program Unif yunif y Result 4 OriginalInitial result 5 un if y Result 5 Figure 1 0 HK 30138782 A 7 Input zk VM (including Pro v er) Original client program Program input Image ID (original) Sea (original) Journal (original) As program input Wrapper program zk VM (including Pro v er) Execution result of original client program Image ID (wrapper) Sea (wrapper) Journal (wrapper) Execution result of wrapper program Figure 1 1 Figure 1 1 HK 30138782 A 8 Second program execution module 1220 Third program execution module 1230 Merging device 1200 Fourth program execution module 1240 First program execution module 1210 Figure 12 Computer system 600 Processor 602 I / O interface 608 Memory 604 Storage 606 Communication interface 610 Figure 13 HK 30138782 A