Proof data generation method and apparatus, and computer system

Abstract

This specification discloses a method, apparatus, and computer system for generating proof data. The method includes: first, obtaining raw data corresponding to a target block in a first blockchain, wherein the raw data includes the block header of the target block; next, inputting the raw data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, wherein the first proof data is used to prove the legality of the block header and the hash value; then, inputting the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, wherein the second proof data is used to prove the legality of the first proof data. The second proof data and the hash value are provided to a verification system, and the verification cost of the second proof data is lower than that of the first proof data.

Description

PAR2612076HK 1 Specification of Method, Apparatus, and Computer System for Generating Proof Data Technical Field This specification relates to the field of blockchain technology, particularly to a method and apparatus for generating proof data, a computer system, and a computer-readable non-volatile storage medium. Background Technology With the rapid development of blockchain technology, it has been widely used in many fields such as finance and supply chain management. Generally, blockchains can be divided into public chains, consortium chains, and private chains according to their degree of openness and transparency. Specialized fields such as finance and supply chain often adopt non-public chain forms such as consortium chains or private chains to gain the advantages of secure and rapid on-chain access. However, for non-public chains, there is a problem of insufficient user trust in the data on the chain. For example, consortium chains used in the financial field are jointly maintained by multiple financial institutions such as banks and securities companies, with each member institution running one or more nodes. The data stored on the chain includes a large amount of sensitive information such as user account balances and transaction records. In order to protect user privacy, this data is usually not publicly disclosed, making it impossible for ordinary users to directly verify whether transactions in the consortium chain have been legally executed. This relatively closed environment makes users doubt the authenticity of the data on the consortium chain. For example, the high technical threshold for verifying the legality of data in a blockchain prevents some users from verifying it independently. Therefore, a solution is needed that can enhance users' trust in on-chain data while also being highly practical and better meeting real-world application needs. This specification describes a method, apparatus, and computer system for generating proof data, which can enhance users' trust in on-chain data and is highly practical. According to a first aspect, a method for generating proof data is provided. The method includes: obtaining raw data corresponding to a target block in a first blockchain, including the block header of the target block; inputting the raw data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value; inputting the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data. The second proof data and the hash value are provided to a verification system, and the verification cost of the second proof data is lower than that of the first proof data. According to a second aspect, an apparatus for generating proof data is provided. The device includes: a raw data acquisition module configured to acquire raw data corresponding to a target block in a first blockchain, including the block header of the target block; a first proof generation module configured to input the raw data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value; and a second proof generation module.The system is configured to input the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data. The second proof data and the hash value are provided to a verification system, and the verification cost of the second proof data is lower than that of the first proof data. According to a third 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: obtaining raw data corresponding to a target block in a first blockchain, including the block header of the target block; inputting the raw data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value; inputting the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data. The second proof data and the hash value are provided to a verification system, and the verification cost of the second proof data is lower than that of the first proof data. According to a fourth 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 aspect. In summary, by employing the methods, apparatus, and computer systems disclosed in the embodiments of this specification, a trusted endorsement system is introduced to perform zero-knowledge proofs on block data, thereby achieving endorsement of blockchain data and enhancing user trust in the data on the blockchain. Simultaneously, the implementation of zero-knowledge proofs employs a fusion of multiple zero-knowledge proof algorithms, resulting in high compatibility of proof data generation, low maintenance cost adaptation to dynamic changes in on-chain business logic, and effectively reducing the verification cost of the final zero-knowledge proof output. 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 merely some embodiments of the present invention. For those skilled in the art, without creative effort,Other figures can also be obtained based on these figures. Figure 1 is a schematic diagram of the process of executing a transfer transaction in a blockchain network. Figure 2 is a schematic diagram of the process of creating a smart contract in a blockchain network. Figure 3 is a schematic diagram of the process of calling the smart contract created in Figure 2 in a blockchain network. Figure 4 is a schematic diagram of the blockchain structure. Figure 5 shows a transaction tree built based on the transaction sequence in a block, based on Figure 4. Figure 6 shows a typical block structure in a consortium blockchain that supports smart contracts. Figure 7 shows an example of a gate circuit obtained in the problem transformation stage of the zk-SNARK algorithm. Figure 8 is a schematic diagram of the implementation architecture for zero-knowledge proof of block data disclosed in the embodiments of this specification. Figure 9 is a schematic diagram of the fusion of multiple zero-knowledge proof algorithms disclosed in the embodiments of this specification. Figure 10 is a schematic diagram of the method flow steps for generating proof data disclosed in the embodiments of this specification. Figure 11 is a schematic diagram of the data flow for zero-knowledge proof of blockchain data disclosed in the embodiments of this specification. Figure 12 shows the three sub-statements used by the second proof data disclosed in the embodiments of this specification for the proof statement. Figure 13 is a schematic diagram of the device structure for generating proof data disclosed in the embodiments of this specification. Figure 14 is a schematic diagram of the computer system provided in the embodiments of this specification. Detailed Description of the Embodiments The solution provided in this specification will be described below with reference to the accompanying drawings. As mentioned above, a solution is needed to enhance users' trust in data on the blockchain. Specifically, the embodiments of this specification disclose an improved solution that proposes introducing a trusted computing platform (e.g., managed by a credible authoritative institution) to endorse blockchain data through zero-knowledge proofs (ZKP). To aid understanding, some knowledge related to blockchain technology and ZKP technology will be introduced below. I. Basic Types of Blockchain Existing blockchains are mainly divided into three categories: public blockchains, consortium blockchains, and private blockchains. Public blockchains are open, permissionless blockchain networks, represented by Bitcoin and Ethereum. Their core characteristics include: 1) Complete decentralization: Nodes can be freely joined or removed by any participant without authorization from a centralized institution; modifications or execution of governance rules (such as token issuance and feature upgrades) rely on distributed consensus mechanisms, such as PoW (Proof of Work) or PoS (Proof of Stake), requiring the consent of a majority of nodes across the network. 2) Open and transparent data: All transaction and block data are publicly available across the entire network. 3) Censorship resistance and security: Security is ensured through cryptography and economic incentives (such as token rewards).A single entity cannot tamper with historical data. A private blockchain is a closed, permissioned blockchain network, whose core characteristics include: 1) Centralized control: Node HK 30135839 A PAR2612076HK 3 is completely controlled by a single organization or institution, with strictly limited participation rights; external nodes require authorization to join; governance rules are independently formulated and modified by the leading institution, without external consensus. 2) Strong data privacy: The visibility of transaction and block data is determined by the controller and is usually only open to authorized participants. 3) High efficiency and low cost: Few and trustworthy nodes; consensus mechanisms, such as RAFT (Replicated And Fault Tolerant), are highly efficient, resulting in fast transaction processing and low cost; suitable for scenarios such as internal enterprise data management and efficient collaboration within specific institutions. A consortium blockchain is a semi-open, permissioned blockchain network, whose core characteristics include: 1) Partial decentralization: Jointly managed by multiple pre-selected organizations (such as financial institutions and supply chain companies); node access requires collective approval from consortium members; governance rules are formulated through member negotiation, and modifications require consensus from a majority of members. 2) Controllable and Shared Data: Transaction data is distributed and stored within the consortium, kept confidential externally, but transparent and auditable to members. 3) Balancing Performance and Trust: Consensus mechanisms, such as PBFT (Practical Byzantine Fault Tolerance), achieve a balance between efficiency and security, being more efficient than public chains and more decentralized than private chains; suitable for scenarios requiring multi-party collaboration, such as cross-institutional businesses (e.g., cross-border payments, supply chain finance). II. Types of Transactions and Accounts in Blockchain Networks The core function of blockchain is mainly realized through transactions. Transaction types mainly include the following three categories: Ordinary transfer transactions, such as Bitcoin's UTXO transactions or Ethereum's ETH transfers; Contract creation transactions, used to deploy smart contract code onto the chain; Contract invocation transactions, sending transactions to deployed smart contracts to execute their function logic. The following describes the above three types of transactions respectively. 1. Ordinary Transfer Transactions Figure 1 shows the execution flow of a transfer transaction in a blockchain network. A blockchain network contains multiple nodes that can communicate with each other. Suppose node Bob needs to transfer funds to node Alice. He first initiates a transfer transaction, creating a transaction containing the following information: sender Bob (from field), receiver Alice (to field), transfer amount 10 (amount field), etc. Then, Bob adds his digital signature to this transaction and publishes it to the blockchain network. Next, the ledger nodes in the blockchain network verify the transaction. Once verified, it is packaged into a block and broadcast throughout the network. After confirmation by the consensus mechanism, the block is added to the blockchain.The transaction officially takes effect at this point. It should be noted that: 1) The above transaction execution process applies to public, private, and consortium blockchains. More granular differences lie in the specific design of the transaction fields, the selection mechanism of the accounting nodes, and the consensus mechanism used. 2) The term "accounting node" is mostly used in public blockchain scenarios. In private and consortium blockchains, it is usually called a "verification node" or "sorting node." 3) A regular transaction can also be referred to as a regular transaction or a transaction. 4) A single node in a blockchain can serve multiple user clients. For simplicity, the term "user" (e.g., Bob) was used to refer to a specific node. In actual scenarios, users interact with nodes through clients. 2. Contract Creation and Contract Invocation Transactions In blockchain platforms that support smart contracts, transactions can also be used to create or invoke smart contracts. A smart contract is an executable program that writes the terms of a traditional contract in code and deploys it on the blockchain. Figure 2 illustrates the process of creating a smart contract in the Ethereum network. Suppose node Bob wants to deploy the following smart contract: `Contract PostingData { String postData; function set(string s) { postData = s;} function get() constant returns (string) { return postData; HK 30135839 A PAR2612076HK 4}}` This contract is used to store and retrieve a string `s` as the data to be published, `postData`. Bob can deploy this contract by initiating a special transaction. Specifically: 1) The `from` field in the transaction is filled with Bob's address; 2) The `to` field is left blank; 3) The `data` field contains the bytecode compiled from the smart contract. When this transaction is broadcast to the network, the ledger nodes will verify and package it, and record it on the blockchain through a consensus mechanism. During this process, the system will generate a unique contract address (e.g., 0x6f...) for the smart contract based on a specific algorithm (such as a hash calculation based on the publisher's address). This contract address has the same format as a regular user address. After the contract is deployed, any user on the network can call it. Figure 3 illustrates the process of calling this smart contract. For example, node Alice wants to invoke this contract: 1) She initiates a transaction, filling in her own address in the `from` field; 2) The `to` field fills in the contract address 0x6f...; 3) The `data` field contains the name of the function to be invoked (set) and the parameters ("Green Charity"). After receiving this transaction, nodes in the network will process it through the Ethereum Virtual Machine (EVM).The EVM executes the contract code. After consensus is reached, the contract state is updated. At this point, any node querying the contract's postData variable will see its value changed to "Green Charity". The above describes transactions for creating and calling smart contracts. It should be noted that public chains, consortium chains, and private chains can all support smart contracts, but they may differ in implementation methods, applicable scenarios, and functional characteristics, which will not be elaborated upon here. Based on the characteristics of transactions and smart contracts described above, accounts in the blockchain can be divided into external accounts and contract accounts. External accounts (EOAs) are controlled by the user's private key and are used to initiate transactions. The state data of an external account includes a balance and a nonce. The balance represents the amount of native tokens held by the external account, such as the amount of Ether; the nonce records the number of transactions initiated by the account to prevent replay attacks. A contract account is controlled by smart contract code, and its state data is expanded to include the following fields: Balance: The number of tokens held by the contract; Nonce (optional): The number of transactions created by the contract on the partial chain record; CodeHash: The hash value of the compiled bytecode of the smart contract (if this field is empty, it indicates that the account is an external account EOA); StorageRoot: The root of a tree-like data structure composed of variables within the contract (such as Ethereum's storageRoot). As mentioned earlier, a smart contract is a piece of executable program code that includes several variables. Organizing these variables into a tree structure and performing calculations based on the variable values ​​yields a root, which serves as the value of the storage root. Therefore, the key difference between external accounts and contract accounts in terms of state data is that contract accounts manage complex states through code hashes and storage roots, while external accounts only maintain basic transaction attributes. III. Blockchain Structure (See Figure 4). A blockchain contains multiple blocks, each consisting of a block header and a block body. Some fields in the block header are generated based on the block body data. Blocks are linked by block hashes. The block body primarily consists of a transaction list, recording all transactions packaged in that block. This list is the core carrier of the blockchain as a "distributed ledger." Because the execution result of transactions may depend on the order of transactions, the transaction list is often called a transaction sequence to indicate its orderliness. The block header contains multiple fields...The field values ​​are calculated and determined based on factors such as transactions in the block body and block generation time when a block is generated. Different types of blockchains have slightly different block header fields, as shown in Table 1 below. Table 1: Comparison of Block Header Components Field Public Chain Private Chain Consortium Chain Transaction Root √ Transaction Integrity Verification √ Transaction Integrity Verification √ Transaction Integrity Verification State Root √ Ethereum and other smart contract chains Record global state × Usually no state concept √ Optional (e.g., consortium chains supporting smart contracts) Receipt Root √ Ethereum Records transaction execution result × Usually no receipt concept √ Optional (e.g., consortium chains supporting smart contracts) Version Number √ Identifies protocol version √ Identifies protocol version √ Identifies protocol version Previous Block Hash √ Links to parent block √ Links to parent block √ Links to parent block Timestamp √ Block generation time √ Block generation time √ Block generation time Random Number √ PoW Consensus Required × Usually Not Required × Usually Not Required Difficulty Target √ PoW Dynamically Adjusts Difficulty × Fixed or Not Required Difficulty × Fixed or Not Required In Table 1, the symbol √ indicates that the corresponding field may exist, and × indicates that the corresponding field generally does not exist. The following sections introduce several important fields in the block header. The transaction root, or Merkle root of the transaction tree, is the root node of the Merkle tree formed by the transactions and is used to quickly verify the integrity of the transaction data. Specifically, a Merkle tree is a binary tree structure typically used to store and verify the hash values ​​of large-scale data. Its core idea is to divide the data into blocks, calculate the hash value of each block, and build a tree structure through layer-by-layer hashing, ultimately generating a unique Merkle root. Figure 5 illustrates the calculation process of the root node of the Merkle tree formed by the transaction sequence. In Figure 5, it is assumed that the transaction sequence packaged into the current block is: Tx1-Tx2-Tx3-Tx4, and that the hash algorithm used is SHA256. At this point, the constructed Merkle tree contains: 1) Leaf nodes: Hash1 = SHA256(Tx1), Hash2 = SHA256(Tx2), Hash3 = SHA256(Tx3), Hash4 = SHA256(Tx4); 2) Intermediate nodes: Hash12 = SHA256(Hash1 + Hash2), Hash34 = SHA256(Hash3 + Hash4); 3) Root node: Root Hash = SHA256(Hash12 + Hash34). It should be noted that if the number of transactions is odd, the last leaf node will copy itself to form a pair. For example, if there are only 3 transactions, then Hash4 = Hash3. Thus, the Merkle root of the transaction tree can be calculated.The state root is used to fill the block header as a transaction root. The state root is the hash value of the global state after the block transactions are executed; in other words, the state root is like the "fingerprint" of the entire blockchain system at a given moment. The global state is the complete set of states of all accounts (including external accounts and contract accounts) on the blockchain at a given moment. Since the amount of global state data can be very large, it is difficult to directly store the entire state in the block. Therefore, a Merkle Patricia Trie (MPT) data structure is proposed to record the global state. This allows the MPT state tree to be stored in the local database of the blockchain node, and the MPT root (or state root) to be stored in the block header for efficient verification of data integrity and consistency. It should be noted that in the Ethereum context, the global state is generally referred to as the world state. The MPT global state tree records the state of all accounts in the blockchain at a given moment in a tree structure, i.e., the world state at that moment. In the MPT global state tree, leaf nodes can correspond to the state data of an account. For external accounts, their state data mainly consists of the account balance. For contract accounts, their state data also includes code hashes and StorageRoot. The StorageRoot of a contract account is actually the root value of the MPT tree, which organizes the variables in the contract into an MPT tree. This variable state MPT tree can be considered the next level MPT tree rooted at the leaf node of the MPT global state tree. Hashes are calculated layer by layer from the leaf node upwards according to certain rules, and the hash of the top node of the MPT global state tree is the state root. The state root represents the entire tree; as long as the root is consistent, the entire state data is consistent. The state root stored in the block header indicates the state of the entire blockchain network after the block ends. The MPT tree integrates three structures: Trie (for efficient key-value pair lookup, supporting prefix matching); Patricia Tree (for path compression and improved efficiency); and Merkle Tree (where each node is hashed, verifying consistency). For the global state, organizing it into an MPT tree, compared to a simple Merkle tree, offers several advantages: efficient key-value lookup and updates, reduced storage space, and support for partial updates (incremental modifications). Updates to the state root are triggered by the execution of new transactions: as transactions in a block are executed sequentially, they change the state of some accounts (such as account balances, contract state variables, etc.); these changes update the corresponding nodes in the MPT state tree. Due to the recursive nature of hashing, a change in any node affects the structure of the entire tree.This ultimately leads to a change in the root hash of the state tree (i.e., the state root). This new state root is written into the block header of the current block to identify the snapshot of the entire network state after the block ends. In short, the state root update mechanism is: after each block execution, the state tree changes → the state root changes → a new block header is written. This mechanism guarantees that as long as the state root matches, the entire state data has not been tampered with, which is one of the core foundations of blockchain security and consistency. The Receipts Root is used to efficiently verify the validity of transaction execution. After each transaction is executed, a transaction receipt is generated, which includes the transaction execution result, such as Ethereum's recorded gas consumption and event logs. The receipt root is the root node of the MPT tree built based on these transaction receipts. It should be noted that the above introduction to the transaction root, state root, and receipt root only exemplifies their corresponding tree structures. In practice, different tree structures can be selected as needed. For example, in Ethereum, the transaction root can be implemented as the MPT root. Next, we will introduce the other fields in Table 1. The version number identifies the protocol version followed by the block. The previous block hash is the hash value of the parent block header, used for chaining and ensuring immutability. The timestamp is the time the block was generated, filled in by miners / validators. The nonce is a variable used in PoW consensus to adjust the hash value of the current block header; miners find a valid nonce through brute-force computation. It should be noted that the nonce in the block header is different from the nonce in the aforementioned account. The difficulty target is the difficulty threshold for hash calculation in PoW consensus; for example, Bitcoin requires the hash value of the current block header to have multiple leading zeros. The above describes the data content of the block header and block body of three types of blockchains. Intuitively, Figure 6 shows a typical example of the block structure in a consortium blockchain (supporting smart contracts). Having introduced knowledge related to blockchain technology, we will now introduce knowledge related to ZKP. IV. Core Features and General Framework of ZKP 1. ZKP is a cryptographic protocol that allows a prover to prove the truth of a statement to a verifier without revealing any additional information. An arbitrary statement can generally be expressed as: a public input y and a private input x satisfy a specified relationship, for example, "y is calculated using f(x), i.e., y = f(x)". The public input y is visible to both the prover and the verifier, while the private input x is visible only to the prover.f() represents a mathematical function. The core characteristics of ZKP include: Completeness: If a statement (e.g., there exists a valid x such that y = f(x)) is true, an honest prover can convince an honest verifier that the statement is true. Soundness: If a statement (e.g., there does not exist an x ​​that satisfies y = f(x)) is false, a cheating prover cannot deceive (the probability of successful deception is negligible) the verifier into accepting the statement. Zero-Knowledge: The verifier has no additional information about the hidden input x other than that the statement is true. 2. The ZKP protocol includes the generation and verification of proofs (proof data, or zero-knowledge proofs), where generation is the responsibility of the Prover (or zero-knowledge proof generator), and verification is the responsibility of the Verifier. In commonly used computing frameworks, zero-knowledge virtual machines (zkVM) are often used to generate proof data. For example, zkVM and Prover can work together to generate proof data, or a zkVM module can be integrated into Prover to generate proof data. Below, we will take the zkVM+Prover architecture as an example to introduce the general process of generating proof data. 1) Overall Input and Target Overall Input: ① Computation Code: Program code written by the user based on the statement (i.e., the logical relationship to be proved), generally in high-level languages ​​such as Rust or C++. For example, assuming the statement to be proved is "y is calculated by f(x)," the computation code written accordingly can include: the code part declaring the input variables (such as x and y), and the code part implementing the calculation and judgment relationship in the statement, such as assert! (y== f(x)). ② The variable values ​​of the input variables in the computation code, such as x=3, y=10. Objective: To generate a zero-knowledge proof that computational code executes correctly and outputs a result given input, without exposing hidden inputs (e.g., x=3) and intermediate data. 2) Compilation of computational code and construction of the constraint system (zkVM responsible): First, using the compilation tools in the zkVM toolchain, the computational code is compiled into zkVM executable intermediate instructions (e.g., a subset of RISC-V), or instruction sequences. Then, each compiled instruction is transformed into a computable mathematical constraint (e.g., addition a+b=c is transformed into ca-b=0), ultimately forming a constraint system. It should be noted that the constraint system is associated with metadata, including variable index tables and constraint index tables, where the variable index table records the mapping relationship between program variables and constraint system column indices.For example, x corresponds to the 3rd column of the constraint system; the constraint index table records the execution trajectory row number corresponding to each index, such as constraint index 5 corresponding to the calculation of the 100th row in the execution trajectory. Please refer to the following text for an introduction to the execution trajectory. 3) Execution trajectory generation (zkVM is responsible) Input: Input data for the computation code provided by the user, such as x=3. Process steps: zkVM interprets and executes the intermediate instructions obtained from compiling the computation code, records the intermediate state of each step such as register values, memory reads and writes, etc., and generates the execution trajectory. For example, the computation code includes the calculation of f(x)=x 2 +1, the input x=3, and the execution trajectory will record a=3, b=9, c=10, where a corresponds to the input x, b corresponds to x 2, and c corresponds to the output f(x). Output: Execution trajectory, which is generally in matrix form, with each row corresponding to the state of a computation instruction. 4) Execution trajectory polynomialization and proof generation (Prover is responsible) Input: ① Constraint system, and associated metadata and cryptographic parameters (such as elliptic curves, hash functions). ② Execution Trajectory Matrix. Steps: ① Interpolation to a Polynomial: Fit the discrete values ​​of the execution trajectory to a polynomial, for example, using Lagrange interpolation. ② Constraint Satisfaction Verification: Check whether the interpolated polynomial satisfies the constraint system generated by zkVM, for example, verifying that a(x)*a(x) - b(x) = 0 holds true at all points. ③ Proof Generation: Generate a compact proof using cryptographic protocols (such as the Fiat-Shamir heuristic). Output: Proof, containing the polynomial commitment and auxiliary information required for verification. The above describes the general process of generating proof data using the zkVM+Prover architecture as an example. In practice, it is also possible to use only Prover and integrate the zkVM module into it. Compared to the architecture where zkVM and Prover are set up separately, using Prover with the zkVM module integrated allows for simultaneous verification of constraint system satisfaction while the zkVM module generates the execution trajectory. HK 30135839 A PAR2612076HK 8 It should be noted that Verifer is responsible for verifying the generated proof: 1) Input: proof, public output (e.g., y=9), etc. 2) Steps: Call the verification algorithm in the ZKP protocol to verify whether the polynomial constraints are satisfied based on the input without accessing the original input in the generation algorithm. 3) Output: Verification result (Accept / Reject), indicating whether the verification passed. The above introduces the core features and general execution framework of the ZKP protocol. It should be understood that there are various instances of the ZKP protocol. Considering that this article mainly uses zk-SNARK and zk-STARK as examples,The following is a brief introduction to these two protocols. V. zk-SNARK Protocol zk-SNARK stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. 1. Construction of Constraint Systems (zkVM is responsible) The statement to be proven is transformed into an arithmetic circuit or polynomial constraint, such as a first-order constraint system R1CS, which stands for Rank-1 Constraint Systems. A specific example is provided below. For instance, the statement to be proven is: y = (x1 × x2) × (x1 + x3), where the specific values ​​of x1, x2, and x3 cannot be disclosed. Then, when constructing the constraint system: 1) First, the computational code written based on the statement to be proven is converted into the form of a computational circuit. It should be noted that y is not declared as an input variable in this computational code, but rather as a public output. As shown in Figure 7, this circuit consists of a series of logic gates (such as addition and multiplication). The inputs to the circuit are x1, x2, and x3, and the output is y. The circuit design ensures that the calculation process between the inputs and outputs conforms to the stated parameters. When expressing the program, intermediate variables A1 and A2 need to be introduced, with the formulas: A1 = x1 × x2, A2 = x1 + x3. 2) Then, the circuit is transformed into R1CS. For each gate, a set of vectors (p, q, r) needs to be defined. The vector dot product operation is used to make s∙p × s∙qs∙r = 0, where s represents the vector composed of all inputs, i.e., s = [x1, x2, x3, A1, A2, y]. Note that the vector elements have no fixed order; the symbol ∙ represents the vector dot product operation. For example, for the multiplication gate x1×x2=A1, its corresponding set of vectors (p, q, r) are: p=[0,1,0,0,0,0], q=[0,0,1,0,0,0], and r=[0,0,0,0,1,0]. Substituting s, p, q, and r into s∙p×s∙qs∙r=0, we get x1×x2-A1=0, which is equivalent to the multiplication gate x1×x2=A1. Similarly, we can obtain the corresponding set of vectors (p, q, r) for the addition gate A2=x1+x3 and the multiplication gate A1+A2=y. Through the above process, the computational circuit corresponding to the statement to be proved is encoded into the form of R1CS vectors. 3) Next, the R1CS vector expression is transformed into the form of a polynomial, namely, Quadratic Arithmetic Programs (QAP), as the final mathematical expression of the constraint system. When converting R1CS to QAP,We need to construct a polynomial vector set p(t), q(t), r(t) such that the values ​​of these polynomials at specific points can reconstruct the original R1CS constraint vector. After constructing the polynomial vector set p(t), q(t), r(t), we define a scalar polynomial H(t) = s∙p(t)×s∙q(t)-s∙r(t). Since H(t) takes the value 0 at t=2,4,6, i.e., H(2)= H(4)= H(6)=0, according to the polynomial factor theorem, t-2, t-4, and t-6 are all factors of H(t). Therefore, H(t) can be divided by the objective polynomial G(t)=(t-2)(t-4)(t-6), i.e., there exists a quotient polynomial Q(t) such that H(t)= G(t)×Q(t). Thus, the QAP process transforms the proof of the original computation into the proof of the existence of a polynomial Q(t) such that H(t) = G(t) × Q(t). The Lagrange interpolation formula introduces numerous values ​​unrelated to the original computation, transforming vector values ​​into polynomial constraints. Therefore, the polynomial and the original computation are not entirely equivalent in essence. However, according to the Schwartz-Zippel theorem for polynomials, verifying the transformed polynomial is equivalent to verifying the original computation. 2. Trust Setup (Completed by the cryptographic toolchain) It should be noted that in some ZKP protocol instances, such as the zk-SNARK protocol, trust setup is required, including the pre-generation of a Common Reference String (CRS). Specifically, some random numbers are first generated, and these random numbers are used to generate a Proving Key pk and a Verification Key vk. pk and vk will be assigned as the Common Reference String (CRS) to the prover and verifier, respectively, while the original random numbers will be destroyed. 3. Proof Generation (Prover Execution) HK 30135839 A PAR2612076HK 9 Prover calls the zero-knowledge proof generation algorithm in zk-SNARK to generate the proof, which can be explicitly expressed as the following steps: 1) Calculation of the execution trajectory, which can be executed by the zkVM module integrated in Prover. In zkVM, based on the public input (e.g., y=18) and private input (e.g., x1=1, x2=3, x3=5) for the computation code, the intermediate instructions obtained from compiling the computation code are interpreted and executed, and the execution trajectory is recorded, including the variable values ​​of intermediate variables, for example, A1=x1×x2=3 (corresponding to the output of the first multiplication gate).A2 = x1 + x3 = 6 (corresponding to the output of the addition gate). 2) Verify whether the execution trajectory satisfies the constraint system. Verify whether all variable values ​​(such as x1, x2, x3, A1, A2, y) in the execution trajectory satisfy the R1CS constraint system, that is, check the constraint equation corresponding to each logic gate. For example: multiplication gate x1 × x2 = A1 → verify 1 × 3 - 3 = 0. It should be understood that if any constraint is not met, the proof process will terminate. 3) Polynomial construction. After the verification is passed, based on the variable values ​​in the execution trajectory, construct a polynomial that satisfies the following relationship: H(t) = G(t) × Q(t). Where the target polynomial G(t) = (t-2)(t-4)(t-6) corresponds to the circuit constraint point, and Q(t) is the quotient polynomial. This construction process ensures that all circuit constraint relationships are encoded into the polynomial equation. 4) Proof Data Generation: The proof key pk is used to perform encrypted computations on the following: ① a polynomial commitment to the private input variables (x₁, x₂, x₃, A₁, A₂); ② a commitment to the quotient polynomial Q(t); ③ necessary zero-knowledge proof components. The final combination generates proof data π, which hides the original input while maintaining verifiability. 4. Verification (Verifier Execution): The verifier calls the zero-knowledge proof verification algorithm in zk-SNARK to perform verification, which can be explicitly expressed as the following steps: 1) Input Preparation: ① Public input: y = 18; ② Proof data π; ③ Verification key vk (from the trusted setup phase). 2) Indirect Polynomial Verification: The verifier uses the bilinear mapping property to verify the following relationship in the encrypted space: H(τ) = G(τ) × Q(τ), where τ is a secret point generated in the trusted setup phase (which has been destroyed). This verification method has the following key characteristics: ① Confidentiality: The verifier can only access the encrypted polynomial commitment and cannot know the original polynomial or private input; ② Completeness: By using the Schwartz-Zippel theorem, verifying the equation at a random secret point τ guarantees that the original circuit constraints are valid; ③ Efficiency: The verification process only requires constant-level bilinear mapping operations. 3) Verification result determination: If all encrypted verification equations are valid, the proof is accepted; otherwise, it is rejected. This mechanism achieves zero-knowledge: The verifier can only confirm that the prover knows the input that satisfies the circuit constraints, and cannot obtain any additional information. The above introduces the four core stages of the zk-SNARK protocol: constraint system construction, trusted setup, proof generation, and verification. It should be noted that the first two stages (constraint system construction and trusted setup) depend only on the logical structure of the computation program (such as circuit design or code logic) and are independent of the specific input of the program. Therefore, when the computation program changes (such as adjusting the circuit gate structure or modifying the code logic),These two phases must be re-executed; if only the program input values ​​change while the program logic remains the same, re-execution is unnecessary. The latter two phases (proof generation and verification) are closely related to the input values ​​for each execution. Whether the public or private input changes, the proof needs to be regenerated and verification performed. VI. zk-STARK Protocol zk-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge) has three core advantages over zk-SNARK: transparency (no trusted setup required), scalability (proof / verification time is linearly related to problem size), and quantum resistance (based on hash functions and symmetric cryptography). The following describes its working phases, still using y = (x1×x2)×(x1+x3) as an example for explanation. 1. Construction of the Constraint System (zkVM is responsible) Similar to zk-SNARK, zk-STARK also requires transforming the statement to be proven into algebraic constraints. The core difference is: HK 30135839 A PAR2612076HK 10 1) Constructing an explicit execution trace template: Abstracting the computation code into a general blank execution trace table, defining only variables and operation relationships. For the statement: y = (x1×x2)×(x1+x3), first define the variables: ① Input variables: x1, x2, x3; ② Intermediate variables: A1, A2; ③ Output variable: y. Reconstruct the template for the calculation steps (without filling in specific values): Table 2, Example of the template for the calculation trajectory Step i t value range x1 x2 x3 A1 A2 y 0 [0,1) x1 x2 x3 - - - 1 [1,2) - - - x1×x2 - - 2 [2,3) - - - - x1+x3 - 3 [3,4) - - - - - A1×A2 In Table 2, i is the discrete time point, representing the i-th logical step in the calculation process (e.g., i=0,1,2,3); the variable t represents the continuous time parameter, used as the interpolation variable when constructing the polynomial. 2) Algebraic Intermediate Representation (AIR): Define a set of polynomial constraints to ensure the correctness of the calculation trajectory. Continuing with the example, define the following constraint polynomials (generally, constraint 0 does not need to be constructed): Constraint 1 (i=1): P1 (A1,x1,x2) =A1-x1×x2=0, when t∈[1,2). Constraint 2 (i=2): P2 (A2,x1,x3) =A2-(x1+x3)=0,When t∈[2,3). Constraint 3 (i=3): P3 (y,A1,A2) =y- A1×A2=0, when t∈[3,4). From the above, a constraint system of the form AIR can be constructed. 2. Proof generation (Prover is responsible) Prover calls the zero-knowledge proof generation algorithm in zk-STARK to generate the proof, which can be explicitly expressed as the following steps: 1) Calculation of the execution trajectory, which can be executed by the zkVM module integrated in Prover. Using the zkVM module, based on the following input example: ① Public input: y=18; ② Private input: x₁ =1, x₂ =3, x₃ =5. Interpret and execute the intermediate instructions obtained from the compiled calculation code to obtain the actual calculated execution trajectory in Table 3. Table 3. Actual Calculation Trajectory Step i x1 x2 x3 A1 A2 y 0 1 3 5 - - - 1 - - - 3 - - 2 - - - - 6 - 3 - - - - - 18 2) Polynomial Construction ① Column Polynomial Generation: For each column of data, construct a polynomial f(t) through interpolation, where t is a continuous variable, but the interpolation points only correspond to integer steps i (e.g., t=0,1,2,3). For example, fx1(t) satisfies: fx1(0) = x1(0), etc. It should be noted that the interpolation points are only integers t=i, because the calculation trajectory is discrete, and these points are sufficient to uniquely determine the polynomial, but the polynomial is defined in the continuous value range of t. During verification, random points need to be checked to ensure that the constraints are globally valid; if only integer points are verified, attackers can construct non-polynomial functions to deceive verifiers. ② Construction of the quotient polynomial: Example: For constraint P1, there exists Q1(t) such that: P1(fA1(t), fx1(t), fx2(t)) = (t − 1) × Q1(t). 3) Generation of proof data π This stage encodes the polynomial into a concise proof π, including the following core operations: ① Merkle commitment for the polynomial: The polynomial refers to all column polynomials generated by interpolation (such as fx1(t), fA1(t), etc.), and the corresponding quotient polynomials (such as Q1(t), Q2(t), etc.). Specifically, first, the polynomial is evaluated globally over a finite field (such as calculating the value of fx1(t) for t=0,1,…,N-1); HK 30135839 A PAR2612076HK 11 Then, the list of evaluated values ​​is constructed into a Merkle tree, and the root hash is used as the commitment for the polynomial. ② Provide an open proof at a random point z: the random point z is randomly selected by the Verifier during the verification phase (achieved non-interactively through the Fiat-Shamir transformation). It should be noted that...Both z and t are elements in a finite field, but t is the independent variable defined by the polynomial, while z is a specific point randomly sampled during verification. Open proof π includes the objective function value, i.e., the evaluation value of the polynomial at a random point z, such as fx1(z), fA1(z), fx2(z), Q1(z), used to verify whether the constraint P1(fA1(z), fx1(z), fx2(z)) = (z − 1) × Q1(z) holds. Open proof π also includes Merkle paths, which are the hash values ​​of all sibling nodes on the path from the leaf node (corresponding to the objective function value) of the Merkle tree to the root hash. Merkle paths are used to prove that the provided objective function value indeed belongs to the previously promised polynomial and has not been tampered with. For example, if z = 3.6, the prover needs to provide: the value of fx1(3.6) and its Merkle path, the value of Q1(3.6) and its Merkle path, and so on. 3. Verification of Proof Data (Verifier Execution) The verifier calls the zero-knowledge proof verification algorithm in zk-STARK to perform the verification, which can be expressed as the following steps: 1) Obtain the following data from the prover: ① Public input: Declared result (e.g., y=18); Calculation trajectory template definition, such as constraint polynomials P1, P2, P3. ② Commitment data: Root hash of the Merkle tree of all column polynomials (e.g., fA1(t), fx1(t)); Root hash of the Merkle tree of all quotient polynomials (e.g., Q1(t), Q2(t)). ③ Open proof data π (for random point z): Objective function value of the polynomial at z; Corresponding Merkle path (proving that the objective function value belongs to the committed tree path). 2) Random point generation: Generate random point z through Fiat-Shamir transformation. Specifically, first concatenate the common input (e.g., y=18) and the root hash of all polynomials into a string S, then calculate the hash H=SHA256(S), and then map the hash result to a finite field: z=H mod ∣∣. Note: This step ensures randomness and requires no interaction. 3) Verify item by item, and perform the following sub-process for each constraint polynomial Pk: ① Verify the Merkle commitment: For each open function value (e.g., fx1(z)), use the provided Merkle path to calculate the root hash layer by layer from the leaf node hash, and check whether the calculated root hash is consistent with the received commitment. If it fails, reject it immediately. ② Verify the constraint equation: Taking constraint P1: A1- x1×x2=0 as an example: first extract the relevant values ​​fA1(z), fx1(z), fx2(z) and Q1(z); then calculate the left constraint: L=fA1(z)- fx1(z)×fx2(z),And the right constraint: R = (z-1) × Q1(z); then, check if L equals R. If not, reject. ③ Verify output consistency: check if the output polynomial f(z) satisfies: within the final value range (e.g., t∈[3,4)), f(z) = . Example: if z = 3.6, f(3.6) = 18. When all the above verifications pass, accept the proof and return the verification result Accept; otherwise, return Reject. It should be noted that in the zk-STARK protocol, the FRI (Fast Reed-Solomon Interactive Oracle Proofs) low-degree test is the core component to ensure the correctness of polynomials. It is used to verify that the degree of the column polynomial and quotient polynomial provided by the prover is indeed lower than the expected threshold, thereby ensuring the legality of the computation trajectory. Since the details of FRI involve complex interactive protocols and coding theories, in the above proof generation and verification process, it is assumed that the low degree of all polynomials has been ensured by the FRI protocol, and its specific steps are not described in detail. The main differences between the zk-SNARK and zk-STARK protocols mentioned above are as follows: Table 4, Main Differences between zk-SNARK and zk-STARK Stage zk-SNARK zk-STARK Problem Transformation R1CS / QAP, relies on circuit design and elliptic curve pairing AIR / computation trajectory, relies on hashing and finite field trusted setup Requires proof-free generation of bilinear mapping cryptographic computation polynomial commitment + Merkle tree HK 30135839 A PAR2612076HK 12 Verification verification key + pairing operation hash verification + FRI low-degree test The above introduces some knowledge related to blockchain technology and ZKP technology to help understand the improved scheme disclosed in the embodiments of this specification. Returning to the improved scheme, it proposes to introduce a trusted computing platform, and through zero-knowledge proof of block data, realize the endorsement of blockchain data, so as to enhance users' trust in the data on the blockchain. Figure 8 illustrates the implementation architecture of the improved scheme. First, it should be noted that the "first" in the illustrated "first blockchain," as well as similar terms used elsewhere in the text such as "second" and "third," are merely for distinguishing similar items and do not have any ranking or other limiting function. As shown in Figure 8: 1. The endorsement system (such as a trusted computing platform) obtains the original data corresponding to the target block (such as a newly generated block) in the first blockchain, such as the block header and block body; 2. The endorsement system uses the obtained original data and a locally deployed zero-knowledge proof generator to generate proof data for the target block; 3. The proof data is submitted to the verification system. Thus, the verification system can verify the proof data and provide the verification result.This allows users to trust the target block data if the verification result is "Accept". It's important to understand that the aforementioned zero-knowledge proof generator is an engineered implementation of ZKP technology. Its core function is to automatically execute the proof generation algorithm in the ZKP protocol. For example, a zero-knowledge proof generator can be implemented as a Software Development Kit (SDK) or a dedicated hardware accelerator. Regarding the design of the target statement to be proven, considering that blockchains are composed of interconnected blockchains, proving the legality of blockchain data can be refined to proving the "legality of data in the block". Furthermore, considering that key fields such as the transaction root in the block header are cryptographically bound to the block body, the statement can be simplified to "the block header in the block is valid". In this case, the complete block header and associated proof data must be submitted to the verification system. However, since the block header contains a large amount of data, and fields such as timestamps may leak sensitive information, directly submitting the block header may affect efficiency and compromise privacy. Therefore, this paper proposes to further optimize the target statement to "the block header and its hash value are valid." In this case, only the hash value of the block header and the corresponding proof data need to be submitted to the verification system. This design ensures the reliability of verification through the uniqueness of the hash value, while significantly reducing the amount of data transmission and lowering the risk of sensitive information exposure. On the other hand, for the ZKP algorithm used by the aforementioned zero-knowledge proof generator, in the scenario where the target statement to be proved is "the block header and its hash value are valid," directly using an existing algorithm, such as zk-SNARK or zk-STARK, will make it difficult to balance the complexity of proof data generation and verification. Table 5. Performance Differences between zk-SNARK and zk-STARK zk-SNARK zk-STARK Proof Generation Performance Poor Compatibility Good Compatibility (Scalability) Verification Performance Low Verification Cost High Verification Cost Combining Tables 4 and 5, assuming the zk-SNARK algorithm is used, the verification process of the proof data depends on the verification key and pairing operations. The verification complexity is constant and does not increase with the amount of proof data. Verification speed is fast and cost is low, suitable for scenarios requiring efficient verification. However, in the proof generation stage, this algorithm relies on complex circuit design and elliptic curve cryptography, resulting in poor compatibility. If the business logic changes, such as a change in the block generation logic in the first blockchain, even a small change requires a re-transformation of the problem (such as circuit compilation and trust settings). This process is costly, significantly increases the complexity of the generated circuit structure, and is difficult to audit and verify. Therefore, it is not suitable for business scenarios where the business logic is frequently dynamically adjusted. Assuming the zk-STARK algorithm is used, its proof generation relies on hash functions and multinomial commitments.The algorithm boasts low computational complexity and deployment difficulty, high computational efficiency, and minimal modifications required when the computational logic to be proven changes, thus significantly improving the maintainability of the proof system. However, the proof data produced by this algorithm is typically 50KB-500KB, far exceeding the proof data produced by zk-SNARK (typically 128 bytes). Its verification complexity is logarithmic, increasing with the amount of proof data, resulting in high verification costs. Based on the above observations and analysis, compared to the conventional approach of optimizing the ZKP algorithm itself used in the zero-knowledge proof generator in Figure 8, the applicant innovatively proposes a fusion of multiple ZKP algorithms, each with its own strengths, to balance the contradiction between the generation complexity and verification complexity of proof data. This is particularly suitable for blockchain scenarios where business logic dynamically changes. The key to the above-mentioned fusion of multiple ZKP algorithms lies in dividing the generation of proof data into two stages (see Figure 9). First, a more compatible ZKP algorithm (such as zk-STARK) is used to generate the first proof data, proof1. Then, a ZKP algorithm with lower verification costs (such as zk-SNARK) is used to optimize proof1, resulting in the second proof data, proof2, finally submitted to the verification system. Next, the specific implementation steps of the above-mentioned improved scheme will be described with reference to more accompanying figures and embodiments. Figure 10 is a schematic diagram of the method flow steps for generating proof data disclosed in the embodiments of this specification. It should be understood that the executing entity of this method can be the endorsement system shown in Figure 1, which can be any device, equipment, platform, or server cluster with computing and processing capabilities in its specific implementation. As shown in Figure 10, the generation of proof data includes the following steps: Step S1010, obtaining the original data corresponding to the target block in the first blockchain, including the block header of the target block; Step S1020, inputting the original data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value; Step S1030, inputting the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data; wherein, the second proof data and the hash value are provided to the verification system, and the verification cost of the second proof data is lower than that of the first proof data. The above steps are further elaborated as follows: Step S1010, obtaining the original data corresponding to the target block in the first blockchain, including the block header of the target block. It should be noted that the endorsement system can be configured to have access to all data on the first blockchain, for example,It can be directly deployed on nodes of the first blockchain. The proposed improvement scheme is mainly based on the scenario where users lack sufficient trust in the data on the consortium blockchain. Therefore, the first blockchain is generally a consortium blockchain, but it can also be a private or public blockchain. The target block can refer to any block in the first blockchain. For the above original data, it is consistent with the target statement to be proved, namely: the legality of the block header and its hash value in the target block. Referring to the statement "y is calculated by f(w), i.e., y=f(w)" mentioned in "IV. Core Features and General Framework of ZKP" above, the target statement can be expressed as "the hash value y is calculated by f1(f2(x)), and the function value of f2(x) is equal to the block header in the original data, where x is the original data related to the target block, f2() represents the calculation logic or calculation function for generating the block header based on the original data, and f1() represents the hash function." Thus, the original data includes the block header of the target block, as well as the data in the first blockchain that participated in the generation of the block header. Taking the block structure of the target block as shown in Figure 6, in a consortium blockchain, as an example, the block header includes a transaction root, and correspondingly, the original data also includes the transaction sequence in the block body of the target block; the block header includes a state root, and correspondingly, the original data also includes the world state of the previous block of the target block; the block header includes a receipt root, and correspondingly, the original data also includes the transaction receipts of each transaction in the target block. The above provides an exemplary description of the obtained original data. For triggering this step, in one embodiment, the corresponding original data can be obtained in response to the generation of the target block in the first blockchain. In another embodiment, newly generated blocks in the first blockchain can be obtained periodically (e.g., every 10 seconds), possibly one or more, and each block can be used as the target block, and the corresponding original data can be obtained. Thus, the original data corresponding to the target block can be obtained. Next, in step S1020, the above original data and the hash value of the block header are input into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value. Regarding the source of the hash value of the block header, in one embodiment, when obtaining the original data corresponding to the target block (HK 30135839 A PAR2612076HK 14), the next block of the target block has already been generated in the first blockchain. At this time, the hash of the previous block can be directly obtained from the block header of the next block as the block hash of the target block (i.e., the hash value of the block header). In another embodiment, the hash value of the block header can be calculated locally using the hash function in the protocol version followed by the first blockchain. The aforementioned first proof data proof1 is generated by the first zero-knowledge proof generator based on its input data.The proof data is generated using a first ZKP algorithm (e.g., the zk-STARK algorithm illustrated in Figure 9). Specifically, referring to Figure 11, proof1 is generated by the first zero-knowledge proof generator by verifying that the first constraint system is satisfied. Further, in one implementation, the first zero-knowledge proof generator integrates a zkVM module. In this case, the first zero-knowledge proof generator can use the zkVM module to interpret and execute the first instruction sequence based on its input data, and verify that the generated first execution trajectory satisfies the first constraint system to generate the first proof data proof1. In another implementation, the second zero-knowledge proof generator does not integrate a zkVM module. In this case, the first zero-knowledge proof generator can collaborate with the zkVM platform to generate the proof data. Specifically, the original data and the hash value of the block header are input into the zkVM platform to obtain the first execution trajectory generated by executing the first instruction sequence. It should be understood that this trajectory records the input of the first instruction sequence; then, the first zero-knowledge proof generator generates the first proof data proof1 by verifying that the input first execution trajectory satisfies the first constraint system. It should be noted that the first instruction sequence is obtained by compiling the first computation code written according to the target statement, and the first constraint system is obtained by transforming the first instruction sequence. For this, please refer back to the previous introduction on "compilation of computation code and construction of constraint system". Furthermore, if the first execution trajectory does not satisfy the first constraint system, the first zero-knowledge proof generator will not output valid proof data. To aid understanding, the content of the first constraint system will be introduced first, followed by its construction and updating. Adapting to the target statement (the block header and its hash value are valid), the first constraint system includes the requirement that the data portion (such as the block body data) participating in the block header generation in the original data and the block header satisfy a first constraint relationship, and that the block header and hash value satisfy a second constraint relationship. Regarding the aforementioned first constraint relationship, we will continue with an illustrative explanation based on the block header shown in Figure 6: In Example 1, the block header of the target block includes a transaction root. In this case, the first constraint relationship includes a first sub-constraint for the transaction root, for example, the transaction root is a Merkle root obtained by calculating the transaction sequence in the block body data. In Example 2, the block header of the target block includes a state root, and the original data also includes a first world state generated by the first blockchain after executing the previous block of the target block; in this case, the aforementioned first constraint relationship includes a second sub-constraint on the state root. For example, the state root is calculated based on a second world state, which is obtained by executing the transaction sequence in the block body data based on the first world state. In Example 3, the block header of the target block includes a receipt root, and the original data also includes a receipt sequence generated by the first blockchain after executing the transaction sequence in the block body data; in this case,The first constraint relationship includes a third sub-constraint on the receipt root, for example, the receipt root is the Merkle root calculated from the receipt sequence. In embodiment 4, the block header of the target block includes the hash of the previous block. In this case, the first constraint relationship includes a fourth sub-constraint on the hash of the previous block, for example, the hash of the previous block is consistent with the hash value of the block header of the previous block that has been verified by the verification system. In embodiment 5, the block header of the target block includes a version number, and the original data also includes the version number of the previous block of the target block. In this case, the first constraint relationship includes a fifth sub-constraint on the version number, for example, the version number in the target block is consistent with the version number in the previous block. In embodiment 6, the block header of the target block includes a timestamp, and the original data also includes the timestamp of the previous block of the target block. In this case, the first constraint relationship includes a sixth sub-constraint on the timestamp, for example, the timestamp in the target block is later than the timestamp in the previous block. The above provides an exemplary description of the content of the first constraint system. The following section introduces the construction of the first constraint system and its dynamic updates triggered by changes in business logic. The construction of the first constraint system requires writing first computational code (typically in a high-level language) based on the target statement. Then, the first instruction sequence obtained by compiling the first computational code is converted into the first constraint system. It's important to understand that the first computational code can be manually written or generated automatically or semi-automatically. The first instruction sequence can take various forms, such as an Executable and Linkable Format (ELF) file or a hardware description language file. Furthermore, the instructions involved in the first instruction sequence belong to a predetermined instruction set (such as the RISC-V instruction set), and the first zero-knowledge proof generator supports this predetermined instruction set, thus enabling the execution of the first instruction sequence. Additionally, if the first computational code is updated, the first constraint system needs to be updated accordingly. The following section explains the reasons why the first computational code may need to be updated, using specific business scenarios as examples. For example, multiple financial institutions provide financial services to users by forming a first blockchain belonging to a consortium blockchain. To provide users with better services, they need to continuously optimize their business logic. Changes in business logic may require adaptation updates to the target code used to generate blocks in the first blockchain to ensure the smooth execution of the new business logic. With the update of the target code, the first computation code needs to be updated accordingly. Specifically, because the target code is updated, the problem transformation process in the first ZKP algorithm needs to be re-executed to compile the updated first computation code into a new instruction sequence, which is then converted into a new constraint system to update the first constraint system. Therefore, optimizing business logic necessitates dynamic updates to the target code, etc.This necessitates continuously re-executing the problem transformation process. In the improved solution, cost reduction can be achieved by selecting a more compatible first ZKP algorithm (such as zk-STARK). The above describes the construction and updating of the first constraint system. Regarding the deployment timing of the first constraint system in the first zero-knowledge proof generator, one possible approach is to pre-deploy and integrate (deeply coupled) the first constraint system within the first zero-knowledge proof generator. However, considering that the business logic involved in the target statement may dynamically change, it is proposed that the first constraint system be passed along with the original data and the hash value of the block header to the first zero-knowledge proof generator, thereby achieving flexible deployment of the first constraint system. Alternatively, the first constraint system can be pre-stored (cached rather than deeply coupled) in the first zero-knowledge proof generator and dynamically loaded each time it is needed. If the business logic changes, the stored first constraint system is adaptively updated. This improves the deployment flexibility of the first constraint system while reducing redundant transmission of the unupdated first constraint system. Referring also to Figure 11, in the input of the first zero-knowledge proof generator, the original data is a hidden input, and the hash value of the block header is a public input. This means that the hash value of the block header is public, but no other party besides the prover can obtain any additional information about the original data. Therefore, by processing the original data of the target block and the hash value of the block header using the first zero-knowledge proof generator, the first proof data proof1 for proving the target statement can be obtained. Then, in step S1030, the first proof data and the hash value of the block header are input into the second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data. The aforementioned second proof data proof2 is generated by the second zero-knowledge proof generator based on its input data using a second ZKP algorithm (e.g., the zk-SNARK algorithm illustrated in Figure 9). Specifically, referring to Figure 11, proof2 is generated by the second zero-knowledge proof generator by verifying that the second constraint system is satisfied. Furthermore, in one implementation, the second zero-knowledge proof generator integrates a zkVM module. In this case, the second zero-knowledge proof generator can use the zkVM module to interpret and execute the second instruction sequence based on its input data, and verify that the generated second execution trajectory satisfies the second constraint system to generate the second proof data proof2. In another implementation, the first zero-knowledge proof generator does not integrate a zkVM module. In this case, the second zero-knowledge proof generator can collaborate with the zkVM platform to generate proof data. Specifically, the first proof data proof1 and the hash value of the block header are input into the zkVM platform to obtain the second execution trajectory generated by executing the second instruction sequence. It should be understood that...This trajectory records the input of the second instruction sequence; then, the second zero-knowledge proof generator generates second proof data proof2 by verifying that the input second execution trajectory satisfies the second constraint system. It should be noted that the aforementioned second instruction sequence is obtained by compiling second computational code written according to the statement "the first proof data is valid," and the second constraint system is obtained by transforming the second instruction sequence. For this, please refer to the aforementioned introduction to "compilation of computational code and construction of constraint system" in HK 30135839 A PAR2612076HK 16. Furthermore, if the second execution trajectory does not satisfy the second constraint system, the second zero-knowledge proof generator will not output valid proof data. It can be understood that the aforementioned second computational code is the verification algorithm code corresponding to the first zero-knowledge proof generator. For example, assuming the first zero-knowledge proof generator uses the zero-knowledge proof generation algorithm in the zk-STARK algorithm, the second computational code can be the zero-knowledge proof verification algorithm code in the zk-STARK algorithm. In addition, the second proof data proof2 indirectly proves the aforementioned target statement by directly proving the "validity of the first proof data." Compared to the first proof data (proof1), the second proof data (proof2) has a lower verification cost. Specifically, the second proof data (proof2) has a smaller data volume, lower storage and transmission costs, or consumes less computational resources and takes less time to verify. Due to the performance contradiction in the generation and verification of proof data in the ZKP algorithm, the compatibility of the second ZKP algorithm is relatively poor. However, because the statement "the first proof data is valid" and its associated second computation code do not need to be changed (even if the first computation code changes), the second constraint system will not change accordingly. Therefore, the disadvantage of the poor compatibility of the second ZKP algorithm is successfully avoided in the improved scheme. To aid understanding, the reason why the second constraint system can be constant and unaffected by dynamic changes in the first computation code is explained below. The statement "the validity of the first proof data" can be broken down into the following sub-statements (see Figure 12): 1) The format of the first proof data is valid; 2) The first proof data is associated with the hash value of the block header; 3) The first proof data is associated with the digest information of the first proof logic. It should be understood that the digest information can be designed to serve a compression and identification purpose. For example, it could be the hash value of the first constraint system (or the first instruction sequence) corresponding to the first computation code, or it could be the output information obtained by processing it through a function other than a hash function that performs a one-to-one mapping. Observing the above sub-statements, it can be found that the hash value of the first proof data, the block header, and the digest information of the first constraint system are all input parameters of the second computation code.Changes in parameter values ​​do not affect the verification logic corresponding to the second computation code. For a given first ZKP algorithm, even if the first computation code changes, the format and specifications of the first proof data, as well as the specifications of the summary information of the first constraint system, will not change, and therefore will not affect the second computation code itself. In short, the second computation code can be constant. Therefore, the second constraint system deployed in the second zero-knowledge proof generator can also be constant, unaffected by dynamic changes in the first computation code, and thus unaffected by dynamic changes in business logic within the business scenario. The disadvantage of low compatibility of the second ZKP algorithm is successfully avoided in the improved solution, and the advantage of lower verification cost of the second proof data (proof2) is utilized. Regarding the content of the second constraint system, corresponding to the above sub-statements, the second constraint system can include: a third constraint that the format of the first proof data must satisfy; a fourth constraint that the hash value of the first proof data and the block header must satisfy; and a fifth constraint that the first proof data and the summary information of the first proof logic must satisfy. The above describes the constancy and content of the second constraint system. Next, we will introduce the generation and deployment of the second constraint system. The construction of the second constraint system requires first compiling the second computation code (typically a high-level language) to obtain a second instruction sequence, and then converting this second instruction sequence into the second constraint system. It's important to understand that the second computation code can be manually written or generated automatically or semi-automatically. The second instruction sequence can take various forms, such as ELF files or hardware description language files. Furthermore, the instructions involved in the second instruction sequence belong to a predetermined instruction set (such as the RISC-V instruction set), and the second zero-knowledge proof generator supports this predetermined instruction set, thus enabling the execution of the second instruction sequence. Regarding the timing of deploying the second proof logic in the second zero-knowledge proof generator, in one possible case, the second zero-knowledge proof generator is a dedicated prover for the target statement; accordingly, the second proof logic can be pre-deployed and integrated into the second zero-knowledge proof generator. In another possible case, the second zero-knowledge proof generator is a general-purpose prover; accordingly, the second proof logic is provided to the second zero-knowledge proof generator in the form of an executable file along with the aforementioned first proof data and the hash value of the block header. Regarding the timing of deploying the second constraint system in the second zero-knowledge proof generator, in one possible case, the second constraint system can be provided simultaneously when the first proof data, etc., are input into the second zero-knowledge proof generator; or, the second constraint system can be pre-stored in the second zero-knowledge proof generator, thereby dynamically loading and deploying the second constraint system before generating proof2. However,Considering that the second constraint system can be constant, it is proposed that the second constraint system can also be pre-deployed and integrated (deeply coupled) in the second zero-knowledge proof generator, reducing the time spent on repeated loading and deployment each time it is used, and improving the generation efficiency of proof2. Referring to Figure 11, in the input of the second zero-knowledge proof generator, the first proof data is a hidden input, while the hash value of the block header and the digest hash of the first proof logic are public inputs. This means that the hash value of the block header is public, but other parties besides the prover cannot obtain any additional information about the first proof data. Therefore, by using the second zero-knowledge proof generator to process the first proof data and the hash value of the block header, the second proof data can be obtained, which indirectly proves the target statement by proving that "the first proof data is valid." It should be noted that after generating the second proof data, the second proof data and the hash value of the block header are provided to the verification system. Thus, the verification system can call the second verification logic corresponding to the second ZKP algorithm based on the data provided by the endorsement system to verify the second proof data. If the second proof data passes verification, the target statement is considered true; otherwise, it is false. It should be understood that the second verification logic can be generated simultaneously with the second proof logic, which is not the focus of the improved solution and will not be elaborated here. For example, the inputs to the second verification logic include the second proof data, the hash value of the block header, and the digest information of the first proof logic, with the output being Accept or Reject. Further, the digest information can be calculated locally by the verification system based on the publicly available first proof logic. Alternatively, it can be provided by the endorsement system. In this case, before executing the second verification logic, the verification system can first calculate the digest information locally based on the publicly available first proof logic and compare it with the digest information provided by the endorsement system. If the comparison fails, Reject is directly used as the verification result; otherwise, the second verification logic continues to be executed. For example, the verification system can publicly disclose the verification process for user verification. For example, the verification system can be implemented by a smart contract deployed on the second blockchain, and the second verification logic can be written in this smart contract. It should be understood that the second blockchain is different from the first blockchain; to ensure credibility, the second blockchain can be a public blockchain. Furthermore, the above descriptions of the first and second ZKP algorithms primarily use the zk-STARK algorithm + zk-SNARK algorithm as an example. In practice, other algorithms can also be used, such as the Halo algorithm + PLONK algorithm, as long as the compatibility of the first ZKP algorithm is better than that of the second ZKP algorithm, and the verification cost of the proof data generated by the second ZKP algorithm is lower than that of the first ZKP algorithm. In summary, by using the method and apparatus for generating proof data disclosed in the embodiments of this specification, and by introducing a trusted endorsement system,Zero-knowledge proofs are performed on block data to endorse the blockchain data, thereby enhancing user trust in the data on the blockchain. Simultaneously, the implementation of zero-knowledge proofs employs a fusion of multiple zero-knowledge proof algorithms, resulting in high compatibility of the generated proof data. This allows for low-maintenance adaptation to dynamic changes in on-chain business logic and effectively reduces the verification cost of the final zero-knowledge proof. Corresponding to the above proof data generation method, this specification also discloses a generation device. As shown in Figure 13, the generation device 1300 includes the following functional modules: a raw data acquisition module 1310, configured to acquire raw data corresponding to a target block in the first blockchain, including the block header of the target block; and a first proof generation module 1320, configured to input the raw data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value. The second proof generation module 1330 is configured to input the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legitimacy of the first proof data. The second proof data and the hash value are provided to a verification system, and the verification cost of the second proof data is lower than that of the first proof data. In one embodiment, the verification system is implemented by a smart contract deployed on a second blockchain. Further, in a specific embodiment, the first blockchain is a consortium blockchain, and the second blockchain is a public blockchain. In one embodiment, the size of the second proof data is smaller than the first proof data, and the verification cost includes the storage and / or transmission cost of the proof data. In one embodiment, the verification cost includes the computing resources consumed in verification and / or the verification time. In one embodiment, the original data acquisition module 1310 is specifically configured to acquire the original data in response to the generation of the target block in the first blockchain. In one embodiment, the original data further includes block body data of the target block; the first zero-knowledge proof generator generates the first proof data by verifying that a first constraint system is satisfied, the first constraint system including a first constraint relationship between the block body data and the block header, and a second constraint relationship between the block header and the hash value. Further, in a specific embodiment, the first constraint system is pre-stored in the first zero-knowledge proof generator. In a specific embodiment, the first zero-knowledge proof generator integrates a zero-knowledge virtual machine (zkVM) module; the first proof generation module 1320 is specifically configured to: utilize the zkVM module to execute first computation code based on the original data and the hash value of the block header.The execution trajectory is obtained; the first constraint system is obtained by compiling and converting the first computation code; if the execution trajectory is verified to satisfy the first constraint system, the first proof data is generated. In a specific embodiment, the first constraint system is obtained by compiling and converting the publicly disclosed first computation code. The generation device 1300 further includes: a first constraint system update unit 1340, configured to compile and convert the updated first computation code into a corresponding constraint system in response to an update of the first computation code, for updating the first constraint system. Further, according to an example, the first computation code is associated with the target code used to generate blocks in the first blockchain; an update of the first computation code includes: the first computation code is modified accordingly based on the update of the target code. In a specific embodiment, the block header includes a transaction root, the first constraint relationship includes a first sub-constraint, the first sub-constraint includes, the transaction root being a Merkle root calculated from the transaction sequence in the block body. In one specific embodiment, the block header includes a state root, and the original data also includes a first world state of the first blockchain after executing the previous block of the target block; the first constraint relationship includes a second sub-constraint, the second sub-constraint including that the state root is calculated based on the second world state, and the second world state is obtained by executing the transaction sequence in the block body based on the first world state. In one specific embodiment, in the input of the first zero-knowledge proof generator, the original data is a hidden input, and the hash value of the block header is a public input. In one embodiment, proving the legality of the first proof data includes: proving that the format of the first proof data is legal; and proving that the first proof data is associated with the hash value of the block header. Further, in one specific embodiment, proving the legality of the first proof data also includes: proving that the first proof data is associated with the digest information of the first constraint system, the first proof data being generated by the first zero-knowledge proof generator by verifying that the first constraint system is satisfied; wherein, the input of the second zero-knowledge proof generator also includes the digest information. Further still, according to an example, in the input of the second zero-knowledge proof generator, the first proof data is a hidden input, and the hash value and digest information are public inputs. In one embodiment, the second zero-knowledge proof generator generates second proof data (HK 30135839 A PAR2612076HK 19) by verifying that the second constraint system is satisfied. The second constraint system is obtained by compiling and converting second computation code, which is the verification algorithm code corresponding to the first zero-knowledge proof generator. Further, in a specific embodiment,The first zero-knowledge proof generator generates first proof data by verifying that the first constraint system is satisfied. The second constraint system remains unchanged even if the first constraint system changes. In one specific embodiment, the first constraint system is pre-deployed and integrated into the second zero-knowledge generator. In one embodiment, the first zero-knowledge proof generator uses the zk-STARK algorithm, and the second zero-knowledge proof generator uses the zk-SNARK algorithm. It should be understood that, for ease of description, the above apparatus is described in functional modules. Of course, in implementing this specification, the functions of each module can be implemented in one or more software and / or hardware. Furthermore, for the description of the above functional modules, please refer to the relevant descriptions of the method steps in the foregoing embodiments. 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 functions 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 media may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. This specification also provides a computer system. Figure 14 illustrates an exemplary computer system 600. In a particular embodiment, one or more computer systems 600 perform one or more steps of one or more methods described or illustrated herein. In a particular embodiment, one or more computer systems 600 provide the functionality described or illustrated herein. In a particular embodiment, 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 portions of one or more computer systems 600. Here, references to a computer system may include, where appropriate, computing devices, and vice versa. Furthermore, where appropriate,References to computer systems may include one or more computer systems. This disclosure contemplates any suitable number of computer systems 600. This disclosure envisions computer systems 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 a 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 spatial or temporal limitations. By way of example and not limitation, one or more computer systems 600 may execute 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 execute 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 a particular embodiment, processor 602 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates that processor 602 may include any appropriate number of appropriate internal caches where appropriate. 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 appropriate number of appropriate 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 for execution by processor 602 or data for operation 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 an address bus and a data bus) 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 mass storage for data or instructions. By way of example and not limitation, memory 606 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, storage 606 may include removable or non-removable (or fixed) media. Where appropriate, storage 606 may be internal or external to computer system 600. In a particular embodiment, storage 606 is a non-volatile solid-state memory. In a particular embodiment, storage 606 includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmable 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. This disclosure contemplates high-capacity storage 606 in any suitable physical form. Where appropriate, 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. Although this disclosure describes and illustrates specific storage, this disclosure contemplates any suitable storage. 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 can enable communication between a person and computer system 600. By way of example and not limitation, I / O devices may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, graphics tablet, touchscreen, trackball, camera, 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. As an 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 this disclosure describes and illustrates specific communication interfaces,However, this disclosure contemplates any suitable communication interface. In a particular embodiment, bus 612 includes hardware, software, or both that couple 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), 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 recognize that the functionality described in the above one or more examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can 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 descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of the present invention should be included within the scope of protection of the present invention. HK 30135839 A PAR2612076HK 1 Claims 1. A method for generating proof data, comprising: obtaining original data corresponding to a target block in a first blockchain, including the block header of the target block; inputting the original data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value; inputting the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data; wherein the second proof data and the hash value are provided to a verification system, and the verification cost of the second proof data is lower than that of the first proof data. 2. The method of claim 1, wherein the verification system is implemented by smart contracts deployed on a second blockchain. 3. The method of claim 2, wherein the first blockchain is a consortium blockchain and the second blockchain is a public blockchain. 4. The method of claim 1, wherein...The second proof data is smaller than the first proof data, and the verification cost includes the storage and / or transmission cost of the proof data. 5. The method of claim 1, wherein the verification cost includes the computing resources consumed in the verification and / or the verification time. 6. The method of claim 1, wherein obtaining the original data corresponding to the target block in the first blockchain includes: obtaining the original data in response to generating the target block in the first blockchain. 7. The method of claim 1, wherein the original data further includes the block body data of the target block; the first zero-knowledge proof generator generates the first proof data by verifying that a first constraint system is satisfied, the first constraint system including a first constraint relationship between the block body data and the block header, and a second constraint relationship between the block header and the hash value. 8. The method of claim 7, wherein the first constraint system is pre-stored in the first zero-knowledge proof generator. 9. The method of claim 7, wherein the first zero-knowledge proof generator integrates a zero-knowledge virtual machine (zkVM) module; wherein inputting the original data and the hash value of the block header into the first zero-knowledge proof generator to generate first proof data includes: using the zkVM module to execute first computation code based on the original data and the hash value of the block header to obtain an execution trajectory; the first constraint system is obtained by compiling and converting the first computation code; and generating the first proof data when the execution trajectory is verified to satisfy the first constraint system. 10. The method of claim 7, wherein the first constraint system is obtained by compiling and converting publicly available first computation code, the method further includes: in response to an update of the first computation code, compiling and converting the updated first computation code into a corresponding constraint system for updating the first constraint system. 11. The method of claim 10, wherein the first computation code is associated with target code in the first blockchain used to generate blocks; an update of the first computation code includes: the first computation code is modified accordingly based on an update of the target code. 12. The method of claim 7, wherein the block header includes a transaction root, the first constraint relationship includes a first sub-constraint, the first sub-constraint including, the transaction root being a Merkle root calculated from the transaction sequence in the block body. 13. The method of claim 7, wherein the block header includes a state root, the original data further includes a first world state of the first blockchain after executing the previous block of the target block; the first constraint relationship includes a second sub-constraint, the second sub-constraint including,The state root is calculated based on a second world state, which is obtained by executing the transaction sequence in the block body based on the first world state. 14. The method of claim 1, wherein the original data is a hidden input and the hash value of the block header is a public input in the input of the first zero-knowledge proof generator. 15. The method of claim 1, wherein proving the legality of the first proof data includes: proving that the format of the first proof data is legal; and proving that the first proof data is associated with the hash value of the block header. 16. The method of claim 15, wherein proving the legality of the first proof data further includes: proving that the first proof data is associated with the digest information of the first constraint system, wherein the first proof data is generated by the first zero-knowledge proof generator by verifying that the first constraint system is satisfied; wherein the input of the second zero-knowledge proof generator further includes the digest information. 17. The method of claim 16, wherein the first proof data is a hidden input and the hash value and digest information are public inputs in the input of the second zero-knowledge proof generator. 18. The method of claim 1, wherein the second zero-knowledge proof generator generates second proof data by verifying that the second constraint system is satisfied, the second constraint system being obtained by compiling and converting second computation code, the second computation code being the verification algorithm code corresponding to the first zero-knowledge proof generator. 19. The method of claim 18, wherein the first zero-knowledge proof generator generates first proof data by verifying that the first constraint system is satisfied, and the second constraint system remains unchanged if the first constraint system changes. 20. The method of claim 18, wherein the first constraint system is pre-deployed and integrated in the second zero-knowledge generator. 21. The method of any one of claims 1-20, wherein the first zero-knowledge proof generator employs the zk-STARK algorithm, and the second zero-knowledge proof generator employs the zk-SNARK algorithm. 22. An apparatus for generating proof data, comprising: a raw data acquisition module configured to acquire raw data corresponding to a target block in a first blockchain, including a block header of the target block; a first proof generation module configured to input the raw data and the hash value of the block header into a first zero-knowledge proof generator to generate first proof data, which is used to prove the legality of the block header and the hash value; and a second proof generation module configured to input the first proof data and the hash value into a second zero-knowledge proof generator to generate second proof data, which is used to prove the legality of the first proof data; wherein the second proof data and the hash value are provided to a verification system.Furthermore, the verification cost of the second proof data is lower than that of the first proof data. HK 30135839 A PAR2612076HK 1 Instruction Manual Attached Diagram Tx Signature Tx Signature Tx Signature Tx Signature Tx Signature Tx Signature Transaction(Tx) From: Bob (0xf5e...) To: Alice (0x5sl...) Amount: 10 Digital Signature: 0x93a... Bob Alice Figure 1 Tx Signature Tx Signature Tx Signature Tx Signature Tx Signature Tx Signature Transaction(Tx) From: Bob (0xf5e...) To: Null Data: XXXX Digital Signature: 0x93a... Bob Contract PostingData String postData Figure 2 HK 30135839 A PAR2612076HK 2 Tx Signature Tx Signature Tx Signature Tx Signature Tx Signature Tx Signature Transaction(Tx) From: Alice (0r4s...) To: PostingData (0X6f) Data: {set(strings), Green Charity} Digital Signature: 0r4a... Alice Figure 3 Previous Block Current Block Next Block Block Body Block Header Previous Block Hash...... ...... ...... Figure 4 ... ... Current Block Block Header Previous Block Hash... Block Body Next Block Previous Block Merklegen Hash 12 Hash 34 Hash 4 Hash 1 Hash 2 Hash 3 Figure 5 HK 30135839 A PAR2612076HK 3 Hash 1 Hash 2 Figure 6 x2 x1 x3 y Figure 7 Node 1 Node 2 Node 3 ... First Blockchain Endorsement System Zero-Knowledge Proof Generator Verification System 1. Obtain the original data on the chain 2. Generate proof data 3. Submit the proof data Figure 8 HK 30135839 A PAR2612076HK 4 First Zero-Knowledge Proof Generator (e.g., using zk-STARK algorithm) Input data related to the target statement First proof data Proof 1 The second zero-knowledge proof generator (e.g., using the zk-SNARK algorithm) uses the second proof data (proof 2) as input data (Figure 9). It obtains the original data corresponding to the target block in the first blockchain, including the block header of the target block. The original data and the hash value of the block header are input into the first zero-knowledge proof generator to generate the first proof data.It is used to prove the legality of the block header and hash value. The first proof data and the hash value are input into the second zero-knowledge proof generator to generate the second proof data, which is used to prove the legality of the first proof data; wherein, the second proof data and the hash value are provided to the verification system, and the verification cost of the second proof data is lower than that of the first proof data. S1020 S1010 S1030 Figure 10 HK 30135839 A PAR2612076HK 5 HK 30135839 A PAR2612076HK 6 1) Format legality 2) Association 3) Association Figure 12 First proof generation module 1320 Second proof generation module 1330 Generation device 1300 First constraint system update unit 1340 Original data acquisition module 1310 Figure 13 HK 30135839 A PAR2612076HK 7 Computer system 600 Processor 602 I / O interface 608 Memory 604 Storage 606 Communication interface 610, Figure 14 HK 30135839 A,