Lightweight zero knowledge proving systems for unstructured computation

Abstract

Systems and methods are provided for succinct, memory-efficient zero-knowledge proofs verifying the correctness of arbitrary software program executions, including both computational logic and secret-dependent memory accesses. Techniques can combine preprocessing commitments to program constraint matrices and dynamic program blocks, block-based modularity, and lookup arguments for memory access integrity. A prover can commit various program objects and auxiliary data, generate aggregate proximity, multiplication, and linear checks, and compute cryptographic fingerprints interdependent on program and memory constraints. The verifier can authenticate commitments, perform aggregate and spot checks, and verify global consistency via succinct fingerprint proofs, without re-executing the program or learning secret data or execution paths. The approach enables scalable, privacy-preserving verification for programs with dynamic branching and random-access memory, supporting efficient deployment in resource-constrained environments such as blockchains or browsers. The system is applicable to privacy-preserving virtual machines, secure smart contracts, and advanced zero-knowledge computation platforms.

Description

PATENT Attorney Docket No. 116297-000210PC- 1492484LIGHTWEIGHT ZERO KNOWLEDGE PROVING SYSTEMS FOR UNSTRUCTURED COMPUTATIONCROSS-REFERENCES TO RELATED APPLICATION

[0001] This application is a non-provisional of and claims the benefit of U. S. Provisional Patent Application No. 63 / 762,627, entitled ‘'Lightweight Zero Knowledge Proving Systems For Unstructured Computation,” filed on February' 24, 2025, which is herein incorporated by reference in its entirety for all purposes.BACKGROUND

[0002] In the current electronic world, there are many instances for the need of one computer to provide knowledge, possession, or properties of secret information, such as a particular credential, software program, etc. Examples of such problems are the authentication of a person, verification of electronic accounts and actions, e.g., using block chain, and verifying computation (e.g.. by an Al model) is accurate. In such situations, a prover computer can provide computational information that provides sufficient proof to a verifier computer. It is often desirable for no secret information to be leaked to the verifier computer.

[0003] A problem is that the verifier can be required to perform many complex computations, which are not capable of being performed by typical user devices (e.g., a laptop computer or a mobile phone), thereby preventing wide use of certain techniques.BRIEF SUMMARY

[0004] Embodiments correspond to techniques for succinct, memory -efficient zeroknowledge proofs verifying the correctness of arbitrary software program executions, including both computational logic and secret-dependent memory accesses. Techniques can combine preprocessing commitments to program constraint matrices and dynamic program blocks, block-based modularity,, and lookup arguments for memory access integrity. A prover can commit various program objects and auxiliary data, generate aggregate proximity, multiplication, and linear checks, and compute cryptographic fingerprints interdependent on program and memory constraints. The verifier can authenticate commitments, perform179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 aggregate and spot checks, and verify global consistency via succinct fingerprint proofs, without re-executing the program or learning secret data or execution paths. The approach enables scalable, privacy -preserving verification for programs with dynamic branching and random-access memory, supporting efficient deployment in resource-constrained environments such as blockchains or browsers. The system is applicable to privacypreserving virtual machines, secure smart contracts, and advanced zero-knowledge computation platforms.

[0005] According to some embodiments for succinct zero-knowledge proof verification, the heavy computational burden of calculating a randomized linear aggregation of the constraint matrix (r‘A) is shifted from the verifier to the prover. To ensure the prover performs this computation honestly, a cryptographic fingerprint mechanism can be used. The verifier can perform a dual-verification on this fingerprint: confirming that the fingerprint is consistent with the prover's committed r‘A, and second, and using a separate proof to confirm that the same fingerprint is also consistent with the constraint matrix A. By ensuring both paths yield the identical fingerprint, the verifier can trust the prover's computation without needing to perform the expensive calculation itself, enabling a succinct and efficient verification of the program's execution.

[0006] Some embodiments provide for verifying software programs with dynamic, secretdependent control flow, such as conditional branches and loops, without revealing the actual execution path. The program can be broken down into smaller program blocks, each having its own pre-committed constraint submatrix and a corresponding cryptographic fingerprint. The prover, knowing the secret execution sequence, can also generates a total fingerprint, e.g., by cryptographically aggregating the individual fingerprints of the specific blocks that were executed, in the correct order. The verifier can confirms the integrity' of the entire computation by checking that this total fingerprint is a valid combination of the individual block fingerprints, e.g., using a zero-knowledge proof. This allows the verifier to confirm the program was executed correctly without learning which path was taken, providing an efficient, scalable, and privacy-preserving solution for verifying complex, real-world software.

[0007] Some embodiments verify the integrity of both a program's computational logic and its memory access patterns. The proof process can be bifurcated into two parallel tracks. One track can use a first set of constraints and a corresponding cryptographic fingerprint to279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 prove that the program's internal operations were performed correctly. The second track can uses a separate set of constraints and a second fingerprint to prove that all memory accesses — such as reading a value from a secret location in a table — were also performed correctly. The verifier confirms the overall correctness of the program's execution by validating both fingerprints independently. To perform a linear check and verify the witness, the two sets of constraints can be combined.

[0008] These and other embodiments of the disclosure are described in detail below. For example, other embodiments are directed to systems, devices, and computer readable media associated with methods described herein.

[0009] A better understanding of the nature and advantages of embodiments of the present disclosure may be gained with reference to the following detailed description and the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1A shows an example interactive proof system. FIG. 1B shows an example non-interactive proof system.

[0011] FIG. 2 illustrates an exemplary proof system that can facilitate a zero-knowledge verification process between a Prover and a Verifier.

[0012] FIG. 3 illustrates a process for generating a succinct cryptographic commitment from a program's computational data.

[0013] FIG. 4 provides an illustration of a data structure used for generating and verifying commitments, specifically a Merkle tree.

[0014] FIG. 5 provides an example sequence diagram for performing random spot checks between a prover and a verifier.

[0015] FIG. 6 is an example sequence diagram for performing verification using aggregate values and spot checks.

[0016] FIG. 7 depicts the process and data flow involved in the code (proximity) check w ithin the zero-knowledge proof protocol.

[0017] FIG. 8A illustrates the process for verifying multiplication constraints. FIG.8B illustrates the homomorphic property leveraged in the multiplication check379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0018] FIG. 9 is a block diagram illustrating the linear (addition) constraint check in the zero-knowledge system.

[0019] FIG. 10 provides an example of selecting columns to perform a spot check for the linear test.

[0020] FIG. 11 shows a process flow using preprocessing-based succinct verification for linear constraints in zero-knowledge proofs.

[0021] FIG. 12 is a sequence diagram for succinct verification for a system including prover and verifier.

[0022] FIG. 13. is a block diagram illustrating the modular verification of a dynamically executed program in a zero-knowledge proof system.

[0023] FIG. 14 is a sequence diagram illustrating the protocol for modular, block-based verification of a dynamically executed program in a zero-knowledge proof system.

[0024] FIG. 15 provides a prover technique that combines the succinct prepressing, dynamic branching, and verification of memory accesses, e.g., using use of lookup tables.

[0025] FIG. 16 shows a block diagram of an example computer system usable with systems and methods according to embodiments of the present disclosure.TERMS

[0026] An application is whatever is to be proved. For example, that the application is possessed or that output is correct.

[0027] A “Prover” may refer to machine (computer) that attempts to convince a verifier that the prover possesses an application (software program) and / or that the application has been correctly executed to obtain the provided output, without revealing certain private information.

[0028] A verifier is a machine (computer) that receives cryptographic information from a prover and uses cryptographic techniques to confirm if the cryptographic information is true, e.g., that the application is possessed or that output is correct.

[0029] A “zero-knowledge proof’ (sometimes just “proof’) may refer to a statement that demonstrates proof of something without revealing any additional information (“knowledge”) about that thing. For example, a zero-knowledge proof can be used to prove that an entity 479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 knows a secret value without revealing the value. As another example, a zero-knowledge proof can be used to verify the output of a computation without revealing the inputs of the computation.

[0030] A SNARK is a type of cryptographic proof that allows one party' to prove they know a specific piece of information without revealing what that information is. A SNARK can be zero knowledge or not. The term is an acronym that describes its core characteristics:Succinct: The proofs are small in size (e.g., less than a few hundred bytes or 1 kb) and can be verified in milliseconds, regardless of how complex the original calculation was.Non-Interactive: Unlike protocols that required a back-and-forth "conversation," a prover sends a single message that the verifier can check immediately.Argument: It is "computationally sound," meaning it’s mathematically impossible for a dishonest prover to trick a verifier without massive computing power (e.g., a computer that can run 2128CPU cycles.Relating to Knowledge: It proves the prover actually possesses the secret data (the "witness"), not just that the statement is true.

[0031] The Prover’s ‘‘witness” or ‘‘solution” may refer to the set of all input and intermediate values that make the circuit compute correctly (e.g., that final check passes). A witness can comprise can include at least 1,000, 10,000, 50,000, one hundred thousand, 500 thousand, or one million different values.

[0032] An “encoded witness” may refer to an encoding of the “witness.” Example encodings include using Reed-Solomen codes, packed secret sharing, Pairing-Based Cry ptography, Multilinear Maps / Graded Encoding Schemes, Puncturable Pseudorandom Functions (PRFs), Witness Encryption over Signatures (BLS), Arithmetization (Constraint Systems). Subset-Sum Problem Instances, and decentralized / Committee-Based Encoding.

[0033] The term “constraints” refers to how all of the values of the application relate if the prover truly has the secret information, e.g., credential, software program (application), Al model, etc. The constraints can be encoded in a succinct form, referred to as a “key.” A set of linear constraints can include at least 1,000, 10,000, 50,000, one hundred thousand, 500 thousand, or one million different constraints. The linear constraints can be represented as a matrix A, which may be sparse.579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0034] A “commitment’' may refer to a cryptographic primitive that allow entities to “commit” to something while keeping that thing hidden, thereby generating a “commitment value” corresponding to the thing being committed. Later, an entity can reveal the commitment value. A “commitment function” may refer to a function that can be used to generate commitments corresponding to inputs. A homomorphic commitment may comprise a commitment that satisfies homomorphic properties. That is. mathematical relationships between commitment inputs may be preserved when those same relationships are applied to commitments.

[0035] A decommitment can correspond to columns of the encoded witness. A redundancy in the encoding can satisfy the property that if we open a few for spot checks the revealed columns will leak zero information about the witness.

[0036] A “server computer” (or just a computer) may include a powerful computer or cluster of computers. For example, the server computer can include a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, a server computer can include a database server coupled to a web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests for one or more “client computers.” A prover or a verifier may includes any of such computer(s).

[0037] A “memory ” may include any suitable device or devices that may store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method.Examples of memories include one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0038] A “processor” may include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU that comprises at least one high-speed data processor adequate to execute program components for executing user and / or system generated requests. The CPU may be a microprocessor such as AMD’s Athlon, Duron and / or Opteron; IBM and / or Motorola’s PowerPC; IBM’s and Sony’s Cell processor; Intel’s Celeron, Itanium. Pentium, Xenon, and / or Xscale; and / or the like processor(s).679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0039] A “database” may include any structure used to store data, which may be organized into “datasets.” Such datasets may comprise “data elements,” “data records,” (including digital data records), “data record vectors,” etc. A “data record vector” may refer to a list or array of one or more data records. A database may comprise a physical structure (e.g., a specialized computer system or memory element) that stores data, or may refer to organized memory on a computer used to store data (e.g., a filing system implemented using a computer’s operating system).DETAILED DESCRIPTION

[0040] It is a technical problem for how a prover computer can prove to a venfier computer that the prover computer knows a solution. For instance, a prover computer may want to prove that it has a particular software application (program) or a stored credential is valid, e.g., by showing a particular function applied to the credential returns a valid result (e.g., 1). The verifier computer wants to be convinced that a solution exists (and is correct). A further problem is that the verifier computer does not want to redo all the computations from scratch, as such a requirement is too exhaustive for typical applications.

[0041] Accordingly, a goal is for the prover computer to prove the correctness of their solution in a way that (1) requires less effort from the verifier computer than performing the entire calculation themselves and / or the proof length is smaller than the computation size, (2) prevents cheating (if the prover computer does not actually have a valid solution, they are highly likely to be caught), and (3) protects privacy, e.g., the prover computer does not reveal all details of their solution — only enough to prove correctness. For (1), it is desirable that the verifier should not spend time or effort proportional to the size of the computation performed by the prover Otherwise, there is not advantage by using this system.

[0042] As enabled by embodiments of the present disclosure, a server can perform computational operations (a proof including a witness) that can be verified by a small device that can verify it because the verifier can verify a proof with much smaller effort than doing the computation. The verification can use a set of constraints A for the relation between the witness values (e.g.. values with a circuit representing a program). These constraints can be used to verify the witness values have the proper relation. Such verification use encodings (e.g., commitments) as opposed to the actual values, so that the actual values can be kept secret779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0043] As part of performing a succinct verification, the verifier or a trusted 3rdparty can preprocess the constraints A (e.g., to form a commitment of A). A fingerprint involving A can collapse the number of constraints, such that the verifier can perform fewer operations involving the constraints A. Two random vectors (r,s) can be generated (e.g., using Fiat Shamir), and these two vectors can be used to generate a fingerprint value for a constraint matrix A. A commitment of A can ensure a prover does not change A. Additionally, another witness rA can allow the verifier to use the resulting vector without having to compute it, and the commitment thereof can allow the verify to confirm the prover has provided a correct result, as part of a first proof, which may be implemented in a browser of a user computer. The verifier can use a second proof using the two random vectors (r,s) along with the public constraint matrix A to verify the fingerprint, which provides a sufficient accuracy check. The second proof can be performed using a variety of techniques, some existing techniques (e.g., Spartan at eprint.iacr.org / 2019 / 550]) and some described herein. The second proof may be highly uniform. The second proof may not be zero knowledge, e.g., but just a SNARK. And the second proof may be implemented by a server, e.g., a backend server.

[0044] Additionally or alternatively, embodiments can provide support for dynamic flow control. Existing solutions that are hash-based need to rely on an expensive recursive composition to achieve the same memory efficiency and the resulting implementations have not been efficient enough to scale on low-memory environments such as a browser. To address this, embodiments can separate a program in program blocks where control can jump between the program blocks according to an execution sequence. Each program block corresponds to a submatrix of the constraint matrix A. Individual fingerprints can be determined for each program block and the individual fingerprints can be used to determine a total fingerprint that depends on the execution sequence. In this manner, the execution sequence can be verified using the individual fingerprints. As an example way to verify the execution sequence, a lookup table can be used along with lists of items with entries that correspond to the execution sequence. As another example, the prover can prove knowledge of a sequence of indices of the blocks of the constraint matrix A and / or execution sequence of the program blocks, where the sequence provides the total fingerprint as a linear combination of the individual fingerprints. The linear combination can include powers of two random values. To prove knowledge of the sequence, any ZK-SNARK can be used. For example, a lookup technique can be used, as is described herein. Other examples are Noir(aztec. network / noir) and folding schemes with memory.879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0045] Additionally or alternatively, other embodiments can check that memory accesses made by the software program were correctly made. Two constraint matrices can be used: e.g., a first set of constraints A within program blocks and a second set of constraints A’ between invocations of the program blocks according an execution sequence dependent on input values to the software program. Corresponding witnesses (w, w’) can be generated. Random vectors r and r* can be combined with the respective constraints to generate a total fingerprint. The verifier can use commitments to the witnesses along with the fingerprint and a public vector b (generated using Aw and Aw’) to check for the execution sequence as well as verify each program block.

[0046] As another example for checking memory accesses, the two sets of constraints can be checked separately using separate fingerprints. The two sets of constraints can be combined when checking witness rA when performing the linear test.

[0047] The verification of the memory accesses can be performed using lookup tables. Two witness portions can be generated corresponding to invocations of the program or program blocks. The first witness portion can address being accessed and a counter for a number of times the program block has been invoked, The second witness portion can comprise a first list R and a second list W, both generated using random numbers and invocations of the program blocks, the addresses of the program blocks, and counters for the sequence of the invocations. A first product of elements in the first list R and the table value p can be confirmed to equal a second product of elements in the second list W.

[0048] Various embodiments can combined preprocessing to achieve a succinct verification, support for verifying dynamic flow control, and verifying memory access.

[0049] Accordingly, embodiments can provide efficiency. In this disclosure, we show how to design a proof system that allows a Prover to convince the Verifier of an arbitrary program evaluation on a secret input where essentially only the running time of the evaluation is revealed and the total number of constraints are proportional to exactly the constraints for each instructions without incurring the overhead of building a universal circuit. Moreover, the verification of the system is made succinct even for non-structured program by designing a pre-processing zkSNARK variant, as mentioned above. Finally, the new system retains the memory efficiency property of the system described in R. Wang, C. Hazay and M.Venkitasubramaniam, " Ligetron: Lightweight Scalable End-to-End Zero-Knowledge Proofs Post-Quantum ZK-SNARKs on a Browser," 2024 IEEE Symposium on Security) and Privacy 979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 (SP), San Francisco, CA, USA, 2024, pp. 1760-1776, doi: 10.1109 / SP54263.2024.00086., allowing it to be deployed on the browser efficiently at scale.

[0050] As for Reliability: The new system is a proof system satisfying completeness, i.e. any correct execution of the program can generate a proof that will always convince the Verifier and for any incorrect execution, any proof will be caught with high probability' by the Verifier.

[0051] As for Privacy: The new system remains a zero-knowledge proof system unlike existing zero-knowledge virtual machines (zkVMs).

[0052] As an example for improvement to solve dynamic branching, a multiplicative overhead of 80-100 in the number of values committed for previous techniques can be reduced to 10-15, which reduces the size of witness and improves the prover time proportionally.I. PROVER- VERIFIER SYSTEMS

[0053] Proof systems can be used such that a verifier can verify that a prover has correctly executed a software program and provided a valid final result. Proof systems can have requirements of:• Completeness: if the statement is true, the honest prover (that is, one following the protocol properly) can convince the honest verifier that it is indeed true.• Soundness: if the statement is false, no prover, even if it doesn't follow the protocol, can convince the honest verifier that it is true, except with some small probability.

[0054] Accordingly, certain properties should hold for a verifiable computation scheme to be useful: correctness or completeness implies that assuming the keys were validly generated and the proof was correctly generated, the verifier will always accept theproof; security or soundness implies that no adversary can generate a proof that will be accepted if the correct computation is not performed; and efficiency requires that verification should be faster than doing the original computation.1079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 A. Interactive

[0055] Interactive proof systems can model computation as the exchange of messages between two parties: a prover and a verifier. The parties interact by exchanging messages in order to ascertain whether a given string belongs to a language or not. The prover is assumed to possess unlimited computational resources but cannot be trusted, while the verifier has bounded computation power but is assumed to be always honest. Messages are sent between the verifier and prover until the verifier has an answer to the problem and has "convinced" itself that it is correct.

[0056] FIG. 1 A shows an example interactive proof system. A prover and a verifier obtain common input and multiple rounds of messages are exchanged until the verifier accepts or rejects whether the prover has provided a valid result. As part of the messages, the verifier can send random values (e.g., as challenges) and queries to the prover as a way to check that the prover is not cheating.B. Non-Interactive

[0057] FIG. 1B shows an example non-interactive proof system. Techniques such as Fiat-Shamir can be used to generate randomness using a seed or set of seeds for values previously obtained such that the verifier does not need to send any random queries or random values. Instead, the random values and the random queries can be generated based on previous values, e.g., previous witnesses. Fiat-Shamir can use a pseudorandom generator Any of the techniques described herein can use a pseudorandom generator for generating random values, a random vector, or a random selection of data (e.g., columns in an encoded matrix). In some embodiments, Fiat Shamir can use hash functions, such as SHA-256.C. Zero Knowledge

[0058] It can be desirable for the verifier to not obtain any secret values (e.g., inputs to the software program). Such proofs are referred to as zero-knowledge proofs. If the statement is true, then no verifier learns anything other than the fact that the statement is true. In other words, just knowing the statement (not the secret) is sufficient to imagine a scenario showing that the prover knows the secret. This is formalized by showing that every' verifier has some simulator that, given only the statement to be proved (and no access to the prover), can1179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 produce a transcript that "looks like" an interaction between an honest prover and the verifier in question.

[0059] Accordingly, zero-knowledge proofs (ZKP) correspond to a cryptographic method that enables authentication without revealing the information that could be compromised. Zero-knowledge proofs can be used to protect data privacy in a diverse set of use cases.

[0060] Zero-knowledge proofs offer a solution by doing away with the need to reveal information to validate assertions. The zero-knowledge protocol utilizes a statement as input to construct evidence of its validity. This proof ensures a statement’s truth without revealing the information at the source. For example, the zero-knowledge proof is the only necessary evidence to verify your citizenship claim. The verifier just needs to examine specific proof characteristics to be convinced that the underlying assertion is true.

[0061] A key advantage of non-interactive zero-knowledge proofs is that they can be used in situations where there is no possibility of interaction between the prover and verifier, such as in online transactions where the two parties are not able to communicate in real time. This makes non-interactive zero-knowledge proofs particularly useful in decentralized systems like blockchains, where transactions are verified by a network of nodes and there is no central authority to oversee the verification process.D. Use cases

[0062] For an application, there are public values (e.g, constraints A) and there are private secret values (e.g., input values and intermediate results). Public values are proven and verifiable know The secret values, only the prover knows. The verifier, to verify a proof needs the public values and the proof, and it will return, “I accept the proof,” or "‘I reject the proof.” Some use cases are below.1. Verifiable Computation

[0063] One use case is verifiable computation (VC), where a computationally weak device (Verifier) outsources a program execution to a powerful server (Prover) and receives guarantees that the execution was performed faithfully. A Prover can further demonstrate knowledge of a secret input that causes the Verifier's program to satisfy certain assertions,1279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 without ever revealing which input was used. Computation can use arithmetic circuits and preserve the privacy of Prover’s inputs while attesting the integrity of program execution..

[0064] For instance, a problem setting can be that we have a computational problem (for instance, “does this input make a particular function or algorithm return 1?”). One party (i.e., computer system), called the Prover, knows a solution; another party, called the Verifier, wants to be convinced that a solution exists (and is correct), but without having to redo all the computations from scratch.

[0065] A particular example is that a prover has an Al model that is private. The pro ver may not want to show the weights but wants to allow users to run an inference algorithm for queries. Another example is database queries, e.g., to count people with some criteria. The database owner (prover) does not want to show the table but will give the result of the query. The prover will provide some way to authenticate the database, e.g., a hash of the database or a signature of the database.2. Smart contract on blockchain

[0066] Another application is a smart contract on a blockchain. Smart contracts on a blockchain are capable of doing arbitrary computation. If our proof system does not have the succinctness feature, it will be very expensive to verify the truth via a smart contract

[0067] Most implements are layer 1 block chains, which are because they require consensus. This can limit the number of verifications to 100 per second while standard (nonblockchain) systems can process 50,000 verifications per second but without privacy secured in the same way. In order to scale, layer 2 technology the computers verify a proof that these transactions were done correctly. The verification of the proof can be significantly smaller than redoing the computation, to check that the transactions were done correctly.3. Authentic person

[0068] Identity protection can reduce the danger with the identity management systems in use today. Therefore, zero-knowledge proofs can assist users in confirming identification while safeguarding sensitive data. In particular, Zero-knowledge Proofs are beneficial in terms of decentralized identity. Decentralized identification, also known as self-sovereign identity, empowers an individual to manage access to personal identifiers.1379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0069] In one example, a device (including a person using the device) can be authenticated. Authentication can be used for online services that need your identification to access such platforms. A drawback is that it frequently asks for personal information like names, email addresses, birth dates, and so on. The need is also to remember long passwords lest access is denied.

[0070] As an example, a sen ice pro vider can want to onboard customers. The provider does not want to wait for the customer to prove to me that they are eligible. The customer can have a digital credential. A digital credential is something that some trusted authority has digitally signed, some case on file, for example. A European ID is one example. The user has this digital credential and wants to prove either to a smart contract or to an organization that it possesses a valid credential that meets some criteria, e.g., the user is in a geographical region or has invested accreditation from some financial institution.

[0071] A further example is to prove the suer is over 21 with a Valid Government-Issued License. A user can have a digital version of your driver’s license, e.g., stored as JSON, CSV, or XML, that includes personal fields like Name, Birthdate, Address, Eye Color, etc. This license file is digitally signed by the government using their private key, which means anyone with the government’s public key can verify its authenticity.

[0072] In a zero-knowledge (ZK) setup, the user wants to prove two things to a verifier (e.g., a bar, an online sendee) wdthout revealing all your personal details:1. The license is legitimate (i.e., the government’s signature is valid under their public key).2. The Birthdate indicates you are at least 21 (i.e., the birthdate in the file is before today’s date, 21 years ago).

[0073] Using a ZK proof, you share only the cryptographic evidence that:• The license file is properly signed by the government.• The birthdate field is older than 21 years from today.

[0074] No other information — such as your actual name, address, or eye color — needs to be disclosed. The verifier learns only that “this is a genuine driver’s license issued by the government, and the ow ner is over 21,” but sees none of the license’s private details. This preserves your privacy while meeting the age-verification requirement.1479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 4. Prove accreditation

[0075] As another example, it can be desirable to Prove an Investor’s Accreditation Without Revealing Their Personal Data. Suppose a wealth management firm is acting on behalf of an investor who wants to purchase a restricted security. To complete the transaction, the firm must prove to a transfer agent that (1) The investor satisfies certain accreditation criteria (e.g., net worth above a specified threshold) and (2) The investor’s name does not appear on any sanctions list. However, the investor’s full financial details and personal information are private and should not be disclosed to the transfer agent.

[0076] Digital Credential from a Trusted Financial Institution can include:1. Credential Issuance- Another trusted financial institution — mutually recognized by the wealth management firm and the transfer agent — issues a digitally signed credential attesting to the investor’s personal details (PII, net worth, etc.).- Anyone with the institution’s public key can verify the authenticity' of this credential.2. Wealth Management Firm’s Role- The wealth management firm holds this credential on behalf of the investor.- Their goal is to prove the investor meets the net worth and OF AC requirements without revealing sensitive data.

[0077] As to the Zero-Knowledge Proof to the Transfer Agent, using zero-knowledge (ZK) technology, the wealth management firm can provide the transfer agent with cryptographic proof that:1. The Credential is valid, meaning the digital signature from the trusted financial institution checks out under the institution’s public key.2. The investor’s net worth in that credential exceeds the required threshold.3. The investor’s name is not listed in the OF AC database.1579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0078] Throughout the process, the firm does not disclose the investor’s exact net worth or assets, the investor’s name or other personal identifying information, or any other details from the credential (address, age, etc.).

[0079] As an outcome, the transfer agent gains high confidence that the investor is properly accredited and compliant with regulations. The investor’s privacy remains intact, as no personal or financial specifics are revealed beyond the binary truth of “accredited, not sanctioned.” This approach ensures regulatory and procedural compliance for all parties involved — without sacrificing the investor’s confidentiality.E. Example Improvements to use cases

[0080] In the examples below, we will illustrate how the features we present in the disclosure will improve the state-of-the-art.

[0081] Improvements can be made for JSON parsing. In typical applications, the data element is in a particular format and needs to be parsed to extract the values of certain entries. The parsing requires non-oblivious control flow as the fields can have variable width and varying formats (numeric, alphanumeric, hexadecimal, string). This will require different parsing functions to be invoked. The dynamic flow control will allow to choose this function adaptively depending on the field. If the entire file is compressed using some data compression algorithm such as gzip, then a system would unzip first before parsing the data. Unzipping is a highly unstructured computation and with the dynamic flow control the resulting circuit will not be huge.

[0082] Improvements can be made for Field extraction. After parsing the system would extract only certain fields as needed in the verifying condition. The verification should not know where the fields that are being extracted are in the file. For this, some embodiments can use Lookup arguments described below so that the contents can be put in virtual memory and the access patter will not be revealed.

[0083] Improvements can be made for On-chain verification. On chain verification require verification to be succinct. This can use the succinct verification and the dynamic flow control as described herein.1679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 II. AGGREGATE TESTS TO PROVE PROGRAM VALUES SATISFY CONSTRAINTS

[0084] After the prover has cryptographically committed to its entire computational trace — the witness — the next challenge is for the verifier to check that this committed data actually satisfies all the required computational constraints without needing to re-execute the entire program. To overcome this, the protocol employs a series of "aggregate tests," which are designed to efficiently validate the integrity of the prover's witness with minimal work for the verifier.

[0085] Instead of checking each of the potentially millions of constraints individually, the protocol uses tests that collapse large sets of constraints into compact aggregate values. These tests are designed to verily three fundamental aspects of the computation. First, a Proximity Test (also called a Code Test) ensures that the prover has correctly encoded its witness values, which is a prerequisite for all subsequent checks. Second, a Multiplication Test (or Quadratic Test) verifies that all multiplication operations within the computation were performed correctly. Third, an Addition Test (or Linear Test) confirms that all linear and affine relationships are satisfied.

[0086] These tests can be structured as row operations performed on the encoded witness matrix. This can enable the protocol's efficiency. Because each test results in a row aggregate, the verifier can confirm the correctness of these global checks by requesting that the prover reveal only a small, random subset of columns from the committed witness. By performing the same row operations on these few authenticated columns and comparing the results to the prover's aggregates, the verifier can be convinced with very high probability that the constraints hold for the entire witness, thereby achieving a succinct and secure verification.

[0087] FIG. 2 illustrates an exemplary proof system 200 that can facilitate a zeroknowledge verification process between a Prover 201 and a Verifier 202. This system can be designed to allow the Prover 201 to convince the Verifier 202 that it has correctly executed a software program and possesses a valid solution, often referred to as a "witness," without revealing the secret information contained within that witness. The overall architecture of the system can be conceptualized in three primary stages: an initial commitment, a series of aggregate tests, and a final query stage involving random spotchecks.1779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0088] At block 210, a commitment h of the witness is sent from Prover 201 to Verifier 202. This stage effectively establishes a binding agreement on the witness data that will be subject to verification. The Prover can take all the input and intermediate values generated during the execution of a program and arrange them into a matrix, which can be referred to as the witness matrix. This witness matrix can then be encoded to create a redundant representation known as the "encoded witness." Prover 201 can commit to this entire encoded witness. The commitments h cryptographically binds Prover 201 to the specific witness it has generated. Because the Verifier 202 now holds the commitment h, the Prover 201 cannot alter the witness at a later stage without invalidating this commitment.

[0089] At block 220, aggregate tests are performed. In this stage, Prover 201 can compute and provide aggregate values that are derived from the entire encoded witness. Each test can be structured as a row operation on the encoded witness matrix. This approach allows for efficient verification later through column-wise spot checks. These tests can include a Proximity test, a Multiplication test, and an Addition test. These tests can be performed in parallel.

[0090] A Proximity test, which can also be called a Code Test, may be performed to verify that Prover 201 has correctly encoded the witness values. Prover 201 can compute a random linear combination of all the rows in the encoded witness matrix. If the original rows were properly encoded, the resulting aggregate vector should itself be a valid codeword. Verifier 202 can then check this property to gain confidence that the witness is well-formed and adheres to the required structure.

[0091] A Multiplication test, or Quadratic Test, can verify the correctness of all multiplication operations within the original computation, such as constraints of the form a * b = c. To facilitate this, the witness values corresponding to each multiplication can be arranged in a specific structure within the witness matrix, for example, in consecutive triplets of rows. Prover 201 can then compute an aggregate value which, if all multiplications are correct, will decode to an all-zeros vector.

[0092] An Addition test, or Linear Test, can be employed to verify all linear and affine constraints. This can often be the most complex of the tests, as it may involve a large and sparse constraint matrix A that captures all the linear relationships in the computation. The test can involve the Verifier performing a random linear check of these constraints, for which the Prover 201 computes a corresponding aggregate value.1879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0093] At block 230, a query stage is used to perform spot checks, e.g., confirming certain parts of the determination of the commitment (e.g., using a Merkle tree) are consistent with the commitment. These spot checks can use decommitments as described in more detail later. Block 230 can involve queries from Verifier 202 to obtain the decommitments used to perform random spot checks. This stage allows the Verifier 202 to confirm that the aggregate values provided in the previous stage were computed honestly and are consistent with the witness that was committed to in block 210.

[0094] Verifier 202 can initiate this stage by randomly selecting a small number of column indices and issuing a query to the Prover 201, asking it to "open" the values at those positions, i.e., provide those value in the clear. In some embodiments, anon-interactive technique can be used (e.g., using Fiat-Shamir technique) such that Prover 201 automatically selects the columns using a procedure known to Verifier 202, where the selection is based on commonly known values, such as the commitment. In response to a query, Prover 201 can reveal two pieces of information for each specified column. First, it can provide the actual values from that column of the encoded witness. Second, it can provide a decommitment, which may consist of the sibling hashes along the path from that column's leaf node up to the commitment h. More details about commitments are provided later.

[0095] Upon receiving this information, Verifier 202 can perform its verification. It can use the revealed column values and the decommitments (e.g., hashes) to independently recompute the commitment (e.g., a Merkle root). If this recomputed root matches the original commitment h. Verifier 202 can be assured that the revealed column is authentic and has not been altered. Verifier 202 can then perform the same row operations from the aggregate checks, but restricted only to these few authenticated columns. It can then compare its locally computed results for these columns against the corresponding entries in the aggregate values provided by the Pro ver. If they match, the Verifier can be convinced with very high probability that the Prover's aggregates are correct for the entire witness, thereby confirming the validity of the original computation. Such proofs can be referred to as probabilistically checkable proofs (probabilistically settable tree).

[0096] Generally, at no point of time, the entire encoded witness can be kept in memory. Embodiments described later make the operations succinct thereby saving memory and enabling the system to be performed on systems with relatively low memory and to be1979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 performed fast, e.g., prover computer speed reaching million constraints per second with a commodity GPU and verifier reaching tens of millions of constraints on CPU.A. Encodings, commitments, and queries (spot checks)

[0097] Before the verifier can check the computational constraints of the program, the prover can first establish a secure and verifiable record of its entire computation. This is achieved through a multistep process that transforms the raw computational data, known as the witness, into a compact, cryptographic commitment. This commitment sen es two critical purposes: it binds the prover to the specific set of values it claims to have used, preventing any subsequent alteration, and it does so without revealing the secret information contained within the witness itself.

[0098] The process can begin by organizing the witness into a matrix and applying a redundant encoding scheme, which prepares the data for efficient verification. This encoded data can then used to construct a Merkle tree, a hierarchical hash-based data structure that produces a single, succinct root hash as the final commitment. This Merkle tree structure provides a commitment but also provides the mechanism for the verifier to later perform efficient and secure "spot checks" by requesting and authenticating small, randomly selected portions of the prover's data.1. Encoding witness from program values

[0099] As part of preparing a computation for zero-knowledge verification, the raw computational data, or "witness," can be transformed into a structured and redundantly encoded format. This process can take the complete set of a program's inputs, intermediate values, and outputs and organize them into a two-dimensional w itness matrix. Each row of this matrix can be individually processed through an encoding scheme, such as a Reed-Solomon error-correcting code. The primary purpose of this encoding is not merely to reformat the data, but to introduce specific mathematical properties that are essential for the security and efficiency of the proof system. By creating a redundant representation, any attempt by a prover to use an incorrect value will be amplified across the encoded data, allowing such inconsistencies to be detected with high probability through the random sampling techniques used in later verification stages.2079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0100] FIG. 3 illustrates a process for generating a succinct cryptographic commitment h from a program's computational data. This process can begin with the raw computational values, known as the witness, and can conclude with the generation of a single Merkle root hash that securely represents the entirety of that data. This commitment process establishes the data that will be subject to subsequent verification checks.

[0101] The witness 310 can be generated and arranged. Witness 310 can be defined as the complete set of values related to a specific program execution. This can include all secret inputs, public inputs, and all intermediate values, sometimes called "wire values," that are calculated as the program runs through its sequence of arithmetic operations. The witness 310 represents the entire solution or proof of computation that the prover intends to validate.

[0102] If the witness is streaming, which is usually true when evaluating a circuit, the witness can be streamed. This means the elements of my matrix can be generated row by row using the actual wire values.

[0103] Once witness 310 is generated, its constituent values can be organized into a structured format, specifically a witness matrix. While the witness can be thought of as a single long vector of values, arranging it into a two-dimensional matrix provides flexibility. The Prover can choose the dimensions of the matrix, such as its width and height, to optimize for certain efficiency metrics like the final proof length. For an optimum proof length, the matrix can be roughly square root the number of values being put into the matrix. A constraint is that the matrix must have sufficient capacity to contain all the values from witness 310.

[0104] The witness matrix can be encoded to generate encoded witness 330. After the witness values are arranged into the witness matrix, this matrix can be encoded to produce an encoded witness 330. This encoding step is not merely a change in data format but introduces properties that are useful for the efficiency of the zero-knowledge proof system. This step transforms the solution into a structured format that has properties amenable to efficient verification through sampling.

[0105] The encoding can be performed on arow-by-row basis. Each row of the witness 310 can be treated as a vector of values and can be encoded using a suitable error-correcting code, such as a Reed-Solomon code. This procedure transforms each row into a longer, encoded row, which contains redundant information. The resulting encoded rows are then combined to2179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 form the encoded witness 330. The purpose of this redundant encoding is to ensure that if the Prover attempts to cheat by using an incorrect value in the original witness, the error will be amplified and spread across many positions in the encoded representation. This property allows the Verifier to detect such inconsistencies with high probability by checking only a small, random subset of the encoded data.

[0106] The encodings can have homomorphic properties. Adding the encoding of two vectors will be the encoding of the sum of the vectors. Multiplying the encoding (point- wise) results in an encoding of the product of the vectors. There is a row by row correspondence between witness 310 and encoded witness 330.

[0107] When streaming, a row of witness 310 can be generated and encoded. When encoded, the hash can be accumulated. The space needed is the width of this matrix, e.g., 100 megabytes for a row. This encoding can be a number theoretic transform or FFT or NTT. The resulting encoded matrix can be twice or four times longer, e g., as it is an error correcting code. It is a redundant encoding of each row.

[0108] As shown in this example, a Merkle tree 340 is generated as part of generating commitment h. The result is the generation of a single, succinct commitment from the potentially very large encoded witness matrix. The construction of the Merkle tree 340 can begin by treating each column of the encoded witness matrix 430 as a leaf of the tree. The data within each column can be individually hashed using a cryptographic hash function to create a set of leaf hashes. These leaf hashes form the bottom layer of the tree.

[0109] The tree can then be built upwards from these leaves. In a binary Merkle tree, adjacent pairs of hashes are concatenated and hashed together to form a parent node at the next level up. For instance, the hash of the first column and the hash of the second column are combined to create their parent hash. This process of pairwise hashing is repeated for each level of the tree, with each successive level having half the number of nodes as the level below it.

[0110] This hierarchical hashing process continues until it culminates in a single hash value at the top of the tree. This final value is the Merkle root 450. This Merkle root 450 serves as the compact and secure representation of the entire witness, also referred to as the commitment to the entire witness 310. It is a small, fixed-size value that the Prover can send to the Verifier. The cryptographic properties of the hash function make it computationally2279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 infeasible for the Prover to alter any part of the witness data without producing a different Merkle root, thereby securely binding the Prover to the witness it has committed to.

[0111] The Prover can send this Merkle root h to the Verifier. This action is a critical step, as it cryptographically binds the Prover to the specific witness it has generated. Because the Verifier now holds the root hash h, the Prover cannot alter the witness at a later stage without invalidating this commitment.2. Generating Commitments from encoded witness

[0112] Once the witness data has been encoded, a next step is to generate a cryptographic commitment that securely represents the entire encoded witness matrix. This can be accomplished using a Merkle tree, a hierarchical data structure built upon cryptographic hashing. The process begins by treating each column of the encoded witness matrix as a leaf node in the tree. These columns are individually hashed, and the resulting hashes are then paired and hashed together, level by level, until a single hash value, known as the Merkle root, is produced. This root serves as the prover's commitment. A key advantage of this structure is that it enables the prover to later reveal a specific column and provide a corresponding "decommitment" — the set of sibling hashes along the path to the root — which allows the verifier to efficiently and securely confirm that the revealed data is authentic and consistent with the original commitment.

[0113] FIG. 4A provides an illustration of a data structure used for generating commitments, specifically a Merkle tree 440. This structure allows a Prover to commit to a large dataset, such as the encoded witness 330, using a single, small hash value (e.g., N bits, such as 128, 256, 512, etc. bits). More importantly, it provides a mechanism for the Prover to later reveal specific portions of the data along with a proof, know n as a decommitment, that confirms the revealed data is authentic and consistent with the original commitment.

[0114] The construction of the Merkle tree 440 begins at the bottom level with the data to be committed. In this system, each column of the encoded witness matrix can serve as a leaf for the tree. As shown in the example of FIG. 4, Column 1 (461), Column 2 (462), Column 3 (463), and Column n (464) of encoded witness matrix can be hashed to provide hash 471 of Column 1 (461), hash 472 of Column 2 (462), hash 473 of Column 3 (463). and hash 474 of Column n (464), where such hashes can be the leaves. Thus, the contents of each column are individually processed by a cryptographic hash function to produce a corresponding set of2379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 leaf hashes: Hash 471, Hash 472, Hash 473, and Hash 474. These hashes form the lowest level of the tree's internal nodes. The tree is then built upwards by repeatedly hashing adjacent nodes. For instance, Hash 471 and Hash 472 can be combined and hashed to create the parent node Hash 481. Similarly, Hash 472 and Hash 473 can be hashed to create Hash 482. Hash 473 and Hash 474 can be hashed to create Hash 483. Alternatively only pairs of nodes are hashed, as in FIG. 3. This hierarchical hashing continues, e.g., generating hash 491 and hash 492, until a single hash remains at the top, which is the Merkle Root 450. This Root 450 is the final commitment value that the Prover sends to the Verifier.

[0115] A utility of the Merkle tree structure becomes apparent during the spot-check phase of the verification protocol, where the Verifier requests that the Prover reveal specific columns. To prove that a revealed column is authentic, the Prover must provide not only the column's data but also a decommitment. A decommitment can be defined as the minimal set of additional hashes from the tree that allows the Verifier to reconstruct the path from the revealed column's leaf hash all the way to the Root 450. This set of hashes consists of the "sibling" nodes along that path.3. Verifying Commitments - Decommitments and Merkle tree

[0116] FIG. 4B provides an illustration of a data structure used for using decommitments to verify the root hash and thus the encoded witness. The verifier can request decommitments and certain columns of the encoded matrix in the clear so as to perform a verification.For example, if the Verifier queries for Column 1 (461). the Prover provides the data of Column 1 (461) and its corresponding decommitment. The direct path from Column 1 (461) to the Root 450 involves the nodes Hash 471, Hash 481, and Hash 491. The decommitment, therefore, consists of the siblings to the nodes on this path. The sibling to Hash 471 is Hash 472. and the sibling to Hash 481 is Hash 482. And the sibling to Hash 491 is Hash 492. Thus, the decommitment for Column 461 is the set of hashes {Hash 472, Hash 482, and Hash 492} as is highlighted.

[0117] The Verifier can use these decommitments to verify the authenticity of the revealed Column 1 (461). The Verifier first takes the provided data for Column 1 (461) and computes its hash, which should equal Hash 471. Then, the Verifier combines this locally computed hash with the first element of the decommitment. Hash 472, and hashes them together to recompute Hash 1-2 (481). Finally, the Verifier combines this result with the2479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 second element of the decommitment, Hash 3-4 (482), and hashes them to get Hash 491, which is combined with Hash 492 to recompute the final root 450. If this recomputed root value is identical to the original Merkle Root 450 that the Prover sent in the commitment stage, the Verifier is cryptographically assured that the data in Column 1 (461) is authentic and was part of the originally committed dataset. This process enables secure and efficient spot-checking without requiring the transmission of the entire dataset.

[0118] This decommitment procedure binds the revealed columns to the committed encoding and enables the verifier to perform the aggregate tests on authenticated data while revealing only a negligible portion of the witness.

[0119] Accordingly, during the spot-check phase the verifier chooses a small set of column positions at random. For each chosen position the prover must ‘‘open” that column by providing two items: The column values taken directly from the encoded matrix, and a list of hashes from the Merkle tree that lie on the path from that column to the root and their siblings. This information is called a decommitment for that column. To verily this information, the verifier performs the following conceptual steps:• Using the revealed column values, the verifier computes the hash that should appear at the corresponding leaf position.• The verifier then combines this hash with the accompanying path hashes, exactly following the structure of the Merkle tree, until a candidate root is obtained.• If the candidate root matches the original commitment (root of tree) sent in the first stage, the column is accepted as authentic.• Otherwise, the proof is rejected.4. Sequence - Random spot checks

[0120] As part of performing a verification, queries can be performed as random spot checks. An example sequence is provided below. This sequence ensures that the Verifier can efficiently and securely check the correctness of a complex computation, relying on cryptographic commitments, random sampling, and probabilistic checks, without needing to access or recompute the entirety of the Prover's data.2579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0121] FIG. 5 provides an example sequence 500 for performing involving random spot checks between a prover 505 and a verifier 510.

[0122] In step 515, the software program is received.

[0123] In step 520, the software program is represented as a circuit. This transformation allows the program’s logic to be expressed as a collection of interconnected arithmetic gates — such as additions and multiplications — each corresponding to a specific operation within the computation. The circuit structure establishes the foundation for extracting constraints and enables the later steps of the zero-knowledge proof protocol. The circuit can act as a flowchart of operations (e g., additions and multiplications) that ends with a ‘’check” (for example, “is this final output = 1?”).

[0124] In step 525, Prover 505 generates the witness w by executing the circuit on the given inputs. The witness w is a comprehensive record of every input and all intermediate values (sometimes called “wire values”) produced during the computation. The Prover’s “witness” or “solution” is the set of all input and intermediate values that make the circuit compute correctly (that final check passes). This set of values provides the complete evidence of correct program execution that Prover 505 will ultimately commit to and demonstrate to Verifier 510.

[0125] At step 530, Prover 505 encodes the witness w and generates a cryptographic commitment of w, e g., as described in FIGS. 3 and 4. Accordingly, this can be achieved by arranging the witness values into a matrix, encoding each row using an error-correcting code such as Reed-Solomon, and then treating each column of the encoded matrix as a leaf node in a Merkle tree. By hashing pairs of columns up through the tree structure, the Prover produces a single Merkle root hash, which serves as the succinct commitment to the full witness. This Merkle root is sent to the Verifier, binding the Prover to all the committed values without revealing them.

[0126] The commitment (w) is sent to verifier 510. The verifier can then perform spot checks. Thus, instead of sending the entire witness (which can be huge), the Prover can transform (or encodes) it using a special error-correcting code. Such a step is referred to as the Prover giving oracle" access to the pieces and the Verifier can choose which of the pieces to “open” or ‘’reveal.’2679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0127] In step 535, Verifier 510 initiates a query by requesting a random sample, denoted as Sample I, from the encoded witness matrix. Verifier 510 selects certain columns using publicly determined randomness, such as from the Fiat-Shamir heuristic. The purpose of this selection is to challenge the Prover on a small subset of the data, thereby providing a probabilistic check on the Prover’s honesty while limiting the amount of revealed information. In some embodiments (e.g.. non-interactive). Prover 505 can determine the same randomness and provide the samples without requiring a query from Verifier 510.

[0128] In step 540, Prover 505 responds by revealing the contents of the requested sample columns and providing the corresponding Merkle decommitments — this includes the necessary sibling hashes along the path from each revealed column up to the Merkle root.

[0129] In step 545, Verifier 510 uses these decommitments to recompute the root hash. If the recomputed root matches the original commitment, the Verifier is assured that the revealed data is consistent with the original witness matrix. This check confirms that Prover 505 has not altered the data after the initial commitment.

[0130] In step 550, Verifier 510 may repeat the querying process by selecting another random sample, referred to as Sample K. Each additional query further strengthens the protocol’s soundness, as any inconsistency or attempt at cheating by the Prover becomes increasingly likely to be detected as more samples are checked.

[0131] In step 555, Verifier 510 again provides the values and decommitments for Sample K.

[0132] In step 560, Verifier 510 repeats the authentication process to ensure the new- sample matches the commitment. The iterative nature of these spot checks increases the Verifier’s confidence in the Prover’s honesty and the correctness of the overall computation.

[0133] Verifier 510 can perform additional spot checks, either on further random columns or on specific aggregates derived from the encoded witness. This step allows the Verifier to focus on particular constraints or to increase the statistical security of the protocol bybroadening the scope of the checks.

[0134] In step 565. after a predetermined number of samples (t samples) have been queried and verified. Verifier 510 assesses whether all the spot checks have passed. If every' sampled column is authenticated and consistent with the aggregate values and the original2779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 commitment, the Verifier concludes with high probability that the Pro ver’s entire encoded witness is valid and that the computation was performed correctly.

[0135] Verifier 510 can aggregate the outcomes of all spot checks and aggregate checks to make a final determination. If all checks are satisfied, the Verifier accepts the proof, concluding that the Prover's computation is correct with overwhelming probability. If any check fails, the Verifier rejects the proof, indicating possible dishonesty or error by the Prover.

[0136] The process can concludes with a final verdict: the Verifier either accepts or rejects the proof based on the cumulative results of all the sampled and aggregate checks. This step ensures the integrity and soundness of the protocol and provides a clear outcome for the verification of the Prover’s computation.B. Aggregate checks

[0137] As described for FIG. 2, queries can be performed. The valid execution of an application (software program) and result to be proved is written in some programming language. It can be compiled to a low level language, e.g.. a circuit, which has logic gates. Any application can be reduced down to a circuit level, e.g.. using add gates and multiply gates. The circuit defines constraints for how the program operates. The gate’s description is not sensitive: it is public. These constraints can be used to confirm that the operation has been performed correctly. Spot checks of certain parts of the computations (e.g.. using encoded values) can be used to confirm that the witness w is valid.1. Sequence - Aggregate values and random spot checks

[0138] One w ay to check that the Prover’s application and / or execution of the application is correct, various checks (e.g.. proximity, multiplication, and linear) can be performed by determining aggregates over the constraints. An example technique is provided below.

[0139] FIG. 6 is an example sequence diagram for performing verification using aggregate values and spot checks. The proof system 600 includes a prover 605 and a verifier 610. The proof system 600 is shown as non-interactive in this example.

[0140] At step 615, the process commences with the Prover generating the witness vector w (e.g., as part of a commit stage) by executing the software program. This execution2879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 involves running the program logic on specific inputs and recording all intermediate and final values produced throughout the computation. The witness w is a comprehensive set of these values, capturing the entire computation path.

[0141] At step 620, Prover 605 generates the commitment of witness w. Prover 605 can organize the witness w into a matrix and encodes it, e.g., by applying a row-wise errorcorrecting code such as Reed-Solomon to each row. The encoded witness matrix is then used to generate the commitment cw = Commil(w ). e.g., by constructing a Merkle tree, where each column of the encoded matrix serves as a leaf node. Prover 605 can hash these columns up through the tree structure, ultimately producing a single Merkle root hash, denoted as the commitment Cw. This Merkle root is a succinct cryptographic binding of the entire witness and is sent to the Verifier as the Prover's commitment to its data. An aggregate stage can follow.

[0142] At step 625, Prover 605 can engage in a first phase of the aggregate checks. Prover 605 obtains a random number rl, either by direct communication with Verifier 610 or via the Fiat-Shamir heuristic, which allows for non-interactive randomness generation. For example, the random number n can be generated using the program or its constraints.

[0143] At step 630, using this randomness and the constraints derived from the program’s circuit, Prover 605 computes aggregate values — specifically, the aggregates for the code (proximity) check, multiplication (quadratic) check, and addition (linear) check. Each aggregate can be computed as a row operation over the encoded witness matrix, yielding succinct representations of the satisfaction of the relevant constraints.

[0144] As described above, three examples are provided for the aggregate values. For a Code Test: Prover prepares a row aggregate obtained by a set of row operations on the encoded matrix encwthat depends on randomness derived from n. Denote the aggregate as Aggcode. For a Quadratic Test, Prover can prepare a row aggregate that will succinctly capture validity of all multiplication constraints (i.e. c = a x b). The aggregate can be denoted as Aggquad. For a Linear Test, the Prover can prepares a row aggregate that will succinctly capture validity of all linear or affine constraints (i.e. c = 5a + 4b - 2c). This aggregate can be denoted as Aggiin. A query stage can follow.2979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0145] At step 635, Prover 605 receives another random number r (e.g., via Fiat-Shamir or from verifier 610). As examples, the random number r2can be generated using any one or more of the aggregate values.

[0146] At step 640, prover 605 can sample t columns from encw. Prover 605 can prepare the columns along with their decommitment. The sampled column indices can be denoted by / i, i and the columns / decommitments prepared by the Prover by (su, du,..., s it). The s values can be encoded values from the encoded matrix and the decommitments are hash values of the Merkle tree for confirming the encoded values. The purpose of this selection (sampling) is to challenge the Prover on a small, unpredictable subset of its data, thereby providing a probabilistic guarantee of correctness without requiring full disclosure of the witness.

[0147] Accordingly, the Prover can reveal the contents of the t selected columns, along with their respective Merkle decommitments. Each decommitment can comprise the sibling hashes along the path from the revealed column (leaf) to the Merkle root. For each sampled column, the Prover can also provide the corresponding values required for the aggregate row checks.

[0148] In some embodiments, Verifier 610 can initiate the spot-checking phase by generating an additional source of randomness, denoted as r2, again either interactively or via the Fiat-Shamir heuristic. Using r2, Verifier 610 can request a random subset of columns — t columns in total — from the encoded witness matrix. In this manner or by the Prover’ s non-interactive actions for determining randomness r2 itself, the Prover is asked to reveal the contents of these columns, along with their Merkle decommitments (the minimal set of sibling hashes necessary to reconstruct the Merkle root from the revealed data).

[0149] At step 645, the prover can generate the proof and send to the verifier 610. Thus, the Prover can provide the values of the requested columns and the associated decommitments, as well as the aggregate values and the commitment cw. Together these values can form a proof. Accordingly, the proof can comprise the commitment Cw from first Stage, the aggregates from aggregate Stage, and the columns with decommitments from the query Stage, e.g., denoted as (Commit(w), Aggiin, Aggquad, Aggiin, i / , du,..., sit, Jit). Next is the verifier’s stage.3079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0150] At step 650, verifier 610 can obtain the random number rl and r2, e g., using the same Fiat-Shamir procedure as performed by prover 605. For interactive embodiments, verifier 610 can determine the random numbers and send to prover 605.

[0151] At step 655, Verifier 610 verifies aggregate values received from Prover 605.Verifier 610 can perform local checks on these aggregates to verify their validity with respect to the constraint system. Thus, the Verifier can check if the aggregates Aggcode, Aggquad. Agglin are valid (e.g., they are of the right degree and / or encode the all 0s vector). This step can use the random number rl. This step ensures that all cross-verifications are satisfied and that no discrepancies exist between the Prover’s aggregate claims and the sampled evidence.

[0152] For the code aggregate, the Verifier can check that it is a valid codeword, reflecting correct encoding of the witness. For the multiplication aggregate, the Verifier can check that it encodes all zeros, indicating correct enforcement of multiplication constraints. For the linear aggregate, the Verifier can assess whether it satisfies the affine constraints as defined by the circuit's constraint matrix. These aggregate checks provide an initial, low-overhead validation of the Prover’s computation.

[0153] In step 660, Verifier 610 may perform additional internal consistency checks using spot checks. The Verifier can use the revealed column data and decommitments to recompute the Merkle root for each sample, ensuring that it matches the original commitment. The Verifier can apply the same row operations used in the aggregate computations to the sampled columns and compare the results to the aggregate values received earlier from the Prover. Thus, for each sampled column, the Verifier can performs the same aggregate row operations as previously applied to the entire matrix but now restricted to these authenticated columns.

[0154] For example, the Verifier can recompute and performs the same row operations but only on the t sampled columns included in the proof. It checks if the result of the row operations agree on the l columns agree with the row aggregates included in the proof on the t corresponding locations zi,.... zt. If all results match, the Verifier gains strong statistical assurance that the Prover’s aggregates are honestly computed and that the witness satisfies the program’s constraints.

[0155] The Verifier can aggregate the results of all spot checks and aggregate checks. If the revealed columns and their operations match the previously provided aggregates, and if the3179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 recomputed Merkle roots agree with the original commitment, the Verifier accepts the proof. This outcome indicates, with overwhelming probability, that the Prover’s witness is correct, the program constraints are satisfied, and the computation has been performed honestly.

[0156] This sequence in FIG. 6 demonstrates how the system can efficiently and securely verify the integrity of a computation using cryptographic commitments, aggregate checks, and probabilistic spot-checks, all while minimizing the amount of data exchanged and the computational burden on the Verifier. The combination of these steps ensures both soundness and efficiency, making it practical to verify complex computations in a zero-knowledge setting.2. Code (proximity) test

[0157] For the code (proximity) test. Prover prepares a row aggregate obtained by a set of row' operations on the encoded matrix encwthat depends on randomness derived from i. More precisely, let..., umbe the rows of the encoded matrix, then the result of the code test denoted by Aggcodeis computed as (r^l ■■■r™') x encw=The test is verified by the verifier by first checking if Aggcodeis a valid codew ord and later spot checking if it w as computed correctly w ith respect to what was committed.

[0158] FIG. 7 depicts the process and data flow involved in the code (proximity ) check within the zero-knowledge proof protocol. FIG. 7 illustrates how the Prover and Verifier interact to ensure the integrity of the encoding of the witness matrix.

[0159] Prover 705 is shown having generated the encoded witness 710, which is arranged such that each row corresponds to an encoded vector of witness values. This matrix can be generated as described in prior sections.

[0160] This test can ensure that most of these rows are encoded properly, at least mostly. There is a property of this encoding that a linear combination should provide a code. Instead of checking each of these row s, the Prover can provide a sum of a random linear combination of the row s and verifier 715 can check the sum is a valid code w ord. But verifier does not know if the code word was computed correctly. To confirm, verifier 715 can perform spot checks.

[0161] In step 720, verifier 715 initiates the code (proximity) check by' providing Prover 705 with a source of randomness, denoted as r=n, r2, n,.... This random value can be either3279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 sent directly by the Verifier or derived non-interactively using the Fiat-Shamir heuristic. The randomness r ensures that the subsequent linear combination of rows cannot be anticipated or tailored by a dishonest Pro ver.

[0162] Prover 705 computes a random linear combination of the rows of the encoded witness matrix using the randomness n. For example, Prover 705 can determine a vector q as follows: q = nrvi + rtr V2 +... + rim’ vm, where each Vi is a row of the encoded witness, and each rii is a component of the random vector n. The resulting aggregate vector q can be referred to as the AGG code (aggregate for the code check).

[0163] In step 725, Prover 705 sends this aggregate vector q (AGG code) to Verifier 715. The Verifier’s goal is to ensure two things: (1) that q is a valid codeword under the encoding scheme, and (2) that q was correctly computed as the linear combination of the actual, committed rows of the encoded witness.

[0164] In step 730, Verifier 715 performs a codeword validity check on the received aggregate q. If the encoding is correct, q should itself be a valid codeword (i.e., it should satisfy the properties of the error-correcting code used for the witness). This check provides assurance that the Prover did not introduce errors or inconsistencies in the encoding process.

[0165] To further ensure correctness, Verifier 715 can initiate a spot-check phase. Verifier 715 can select a small, random subset of columns from the encoded witness matrix for inspection. For each selected column, Prover 705 can reveal the column data, as well as the corresponding Merkle decommitment (e.g., the set of sibling hashes needed to reconstruct the Merkle root commitment made previously).

[0166] V erifier 715 can use the revealed columns and decommitment data to reconstruct the Merkle root. If the recomputed root matches the original commitment, the Verifier is assured that the revealed columns are authentic. The Verifier can perform the same linear combination (using ri) on the revealed columns to compute the corresponding entries of q locally. By comparing these locally computed values to the entries in q originally sent by the Prover, the Verifier can confirm that the aggregate was computed honestly. If the prover cheated in too many columns, it will be caught. If the prover cheated in a few columns, it could get undetected, but that is OK because this encoding is a redundant encoding.

[0167] The process can conclude with the Verifier’s decision. If both the codeword validity check and all the spot checks on the selected columns pass, the Verifier accepts the code 3379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 (proximity) check as satisfied. This outcome provides strong statistical assurance that the Prover has encoded the witness matrix correctly and that the commitment to the witness is sound.

[0168] In summary, FIG. 7 details how the code (proximity) check enables the Verifier to efficiently and securely check the integrity' of the Prover’s encoding using aggregate linear combinations and targeted spot-checks, all while leveraging cryptographic commitments to ensure soundness and zero-knowledge. The use of randomness, aggregate operations, and Merkle tree commitments together provide a high-probability guarantee that any cheating or inconsistency in the Prover’s encoding will be detected. Further details can be found in Ligero: Lightweight Sublinear Arguments Without a Trusted Setup, CCS’ 17, October 30-November 3, 2017. Dallas, TX, USA (Ligero, 2017).3. Quadratic (Multiplication) test

[0169] For the multiplication test, Prover can prepare a row7aggregate that succinctly captures validity of all multiplication constraints (i.e. c = a X b) in the same witness. To apply this test, the prover can organize the rows of the matrix in the commit phase, so that for every multiplication constraint, the three rows representing the left input, right input, and output appear in consecutive rows. Multiple sets of three rows can be used to capture all the multiplication constraints. For example, it could be u3, u4, u5could be one set, u7, u8, u9another. Thus, the rows are aligned three rows at a time.

[0170] For the quadratic test, the prover can compute the aggregate as follows: Let r2be randomness derived from the Fiat-Shamir process, then the aggregate Agg?]iadis computed asrz (y-ij Ouij+i ~uij+2^ where ij, ij + 1, ij + 2 are the triplet of rows capturing a set of multiplication constraints. In the example above, it would be r2u Q v^ - u5) + r22(u7O UQ — u9). The test is concluded by having the verifier checking that the outcome is a valid codeword and that it encodes to an all zero vector. Accordingly, the multiplication test can check row multiplication in an encoded witness.

[0171] FIG. 8A illustrates the process for verifying multiplication constraints. The test can ensure that Prover has correctly enforced all constraints of the form “a * b = c” in the original computation.3479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0172] As shown, Prover 805 possesses an encoded witness 815, which has been constructed such that the rows corresponding to each multiplication constraint are arranged in consecutive triplets. For instance, the first row in each triplet represents the left input (a), the second row the right input (b), and the third row the output (c) for each multiplication gate in the circuit. Only rows corresponding to multiplication gates would be tested. The implicated rows can correspond to all of the multiplication gates. This explicit structure allows for efficient aggregate testing of all multiplication constraints across the computation.

[0173] In step 820, Verifier 810 provides a random vector of coefficients, denoted as r=n, r2, n,.... This randomness may be transmitted directly or generated non-interactively using the Fiat-Shamir heuristic. The randomness ensures that the Prover cannot selectively cheat on certain constraints, as it does not know in advance which linear combination will be tested.

[0174] In step 820. Pro ver 805 computes the quadratic aggregate (Q). which is an aggregate value succinctly capturing the validity of all multiplication constraints. For each triplet of rows (vi, vi+1, vi+2) in the encoded witness matrix, Prover 805 performs an element- wise multiplication of the first two rows (vi O vi+1), subtracts the third row (vi+2), and then combines these results using the random coefficient n: Q = S (n • (vi O vi+1 -vi+2))where the sum runs over all sets of three consecutive rows corresponding to multiplication gates. If the original multiplication constraints are satisfied, this aggregate will decode to a vector of zeros.

[0175] In step 825. the Prover sends this quadratic aggregate Q to the Verifier.

[0176] In step 830, Verifier 810 can check that Q is a valid codeword under the encoding scheme (for example, Reed-Solomon). For example, it can be checked that the aggregate is a vector of zeros. This check can ensure that the aggregate was computed over properly encoded data. Given this construction, any random linear combination will remain all zeros because if a computer scales a zero with any number, it still remains zero. The verifier at the multiplication test can check that q encodes all zeros.

[0177] As before, in the code test, when the prover provides q, the verifier does not know if the prover performed the computation correctly. To confirm, the verifier can perform spot checks, which can be performed in the same way because the encoding was performed3579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 element-wise, which can also be considered column-wise. The prover can open columns, and the verifier can spot check if q was done correctly on those columns.

[0178] Accordingly, at this point, Verifier 810 can initiate a spot-check by requesting a random subset of columns from the encoded witness. For each selected column. Prover 805 reveals the values of that column for the relevant triplets of rows, along with the associated Merkle decommitments (e.g., the minimal set of sibling hashes needed to reconstruct the Merkle root for each revealed value).

[0179] V erifier 810 can use the revealed column data and decommitments to recompute the Merkle root and confirm the authenticity7of the revealed data. For each sampled column, the Verifier performs the element- wise multiplication and subtraction as in the aggregate computation, then sums the results using the same random coefficients r. Verifier 810 can compare these locally computed results for the sampled columns with the corresponding entries in Q originally provided by the Prover, e.g., each equals zero.

[0180] If the recomputed values for all spot-checked columns agree with the Q aggregate, and if the Merkle root checks pass, the Verifier can accept the quadratic (multiplication) check as satisfied. This process provides strong assurance — statistically, with high probability — that the Prover has correctly enforced all multiplication constraints in the computation.

[0181] FIG. 8B illustrates the homomorphic property leveraged in the multiplication check. The values on the left correspond to the witness and the values on the right correspond to the encoded witness.

[0182] Diagram 850 shows that the encoding scheme (such as Reed-Solomon) used for the witness matrix is multiplicative homomorphic. This property means that the element-wise product of the encodings of two vectors results in the encoding of the element-wise product of those vectors. That is, if vi and V2 are two rows of the encoded witness, then decoding (vi O V2) yields the element-wise product of the original, unencoded vectors of the witness.

[0183] Diagram 850 demonstrates that after performing the element-wise multiplication of the encoded vectors (as in the multiplication check), and then subtracting the encoded output row, the resulting encoded vector, when decoded, should yield a vector of all zeros if and only if the multiplication constraint was satisfied in the original (unencoded) witness. This is3679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 a direct consequence of the way the witness values are arranged and the homomorphic property of the encoding.

[0184] In this manner, Verifier 810, by spot-checking a small subset of the columns and verifying the above property, can be statistically assured that the Prover did not cheat on any of the multiplication constraints, unless it could anticipate all of the Verifier’s random challenges — a probability that is negligible in practice.

[0185] In summary, FIGS. 8A and 8B detail a protocol for checking the correctness of all multiplication gates in a computation. The system leverages the structure of the encoded witness matrix, the homomorphic properties of the encoding, and commitments (e g., from a Merkle tree) to allow the Verifier to efficiently and securely validate that the Prover’s computation satisfies all required multiplicative relationships, with only a small number of random spot checks. This approach preserves both soundness and zero-knowledge, ensuring that the Prover cannot cheat without detection, while also maintaining the privacy of the underlying witness values.4. Linear test (not using preprocessing)

[0186] The addition or linear check is responsible for verifying that all linear or affine constraints imposed by the original program are satisfied by the Prover’s witness. These constraints can be represented by a large and often sparse matrix A that encodes the relationships between inputs, intermediate variables, and outputs within the computation. Constraints can include equations like a + b = c, or more generally, affine forms such as c = 5a + 4b - 2d.a) Performing total Q check

[0187] FIG. 9 is a block diagram illustrating the linear (addition) constraint check in the zero-knowledge system. FIG. 9 depicts how linear or affine constraints from a program’s computation are represented and validated. The witness vector w containing all input, output, and intermediate values, is subject to constraints defined by a matrix A and public vector b, resulting in the equation A * w = b. The Verifier provides a random vector R, and the Prover computes the aggregate Rl / A / w, which is compared to Rl / b to ensure all linear constraints are satisfied. The process is structured to allow efficient validation using encoded matrices and probabilistic spot checks.3779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0188] As illustrated in FIG. 9, the entire set of linear constraints can be succinctly captured using a matrix-vector equation: A xw= b. where A is the constraint matrix, w is the vector of all witness values (inputs, intermediates, outputs), and b is a public vector that encodes the right-hand side values of the affine constraints. Prover 905 is to convince Verifier 910 that the encoded witness 915 it committed to satisfies all of these constraints, i.e., that the equation holds for the specific instance under consideration.

[0189] In step 920. a random vector r is provided by Verifier 910 or via a non-interactive means, such as Fiat-Shamir. To efficiently check the validity of all these constraints, the protocol employs a random linear check using the random vector r. The Prover computes the value q= R‘ x A xw. This equation collapses all the linear constraints into a single scalar value q. drastically reducing the amount of work needed for verification. The Verifier’s aim is to check that this identity' holds for the witness w, without learning w itself. The verifier can check that q=Rlx b. Thus, the verifier can perform a random linear check using the random vector r an the public vector b as the result should also be q.

[0190] As also done previously, Prover 905 can organize the encoded witness w into a matrix and encode each row using a suitable error-correcting code (e.g.. Reed-Solomon), forming the encoded witness 915. The encoding introduces redundancy so that errors or inconsistencies in the witness will be amplified in the encoded representation.

[0191] Prover 905 can compute and encode the vector 940 by determining R‘ x A, arranging its entries in the same way as the encoded witness 915. Prover 905 then encodes this vector row by row. yielding an encoded matrix 945 in the same format as the encoded witness 915. The elements of this encoded matrix 945 determined from Rlx A are arranged such that the ith entry' corresponds to the ith entry' of the encoded witness.

[0192] In step 925, to perform the linear check, Prover 905 can compute the pointwise product of corresponding rows from the encoded witness matrix 915 and the encoded matrix 945, namely determining v 0 s. This results in a set of vectors whose entries, when summed, represent the partial sums of the inner product Rlx A x w. Prover 905 aggregates these vectors to form a single vector q, which — when decoded and summed — should equal R' - A x w. Pro ver 905 sends this aggregate q to the Verifier as part of the proof.3879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 b) Performing spot checks

[0193] Verifier 910 does not have access to the full encoded matrix 945, as this is computed by Prover 905. To validate the correctness of Q, Verifier 910 selects a small random subset of columns (t columns) from the encoded witness matrix 915 and requests that Prover 905 reveal the corresponding columns from both the encoded witness 915 and the encoded matrix 945, along with their Merkle decommitments. Verifier 910 uses these decommitted columns to: (1) Recompute the Merkle root for authentication, (2) Perform the pointwise multiplications and aggregations locally for the sampled columns, and (3) Compare the computed results to the corresponding entries in q. If the sampled results match, the Verifier is statistically convinced that the linear check was performed honestly for the entire witness, with high probability of detecting any cheating.

[0194] FIG. 10 provides an example of selecting columns to perform a spot check for the linear test. As shown, the prover reveals the corresponding columns 1060 from the encoded witness and corresponding columns from the encoded matrix.

[0195] But such a spot check is not succinct because the verifier needs the same columns in the encoding of R transpose A to recompute this point-wise product of v O s on those columns. The verifier would do this computation the same way that the prover does, which is big as it is the size of the circuit. This is why the verification is not succinct.c) Example

[0196] As an example, Prover prepares a row aggregate that will succinctly capture validity of all linear or affine constraints (i.e. c = 5a + 4b — 2c). Denote the aggregate as Aggfe. This set of constraints is captured by a large and sparse matrix A which is multiplied with enclv. Following that, the verifier checks the linear combination of the outcome, similarly to the above tests, the verifier will check that the sum of the encoded vector elements is zero.

[0197] As an example, lets say u encodes the vector(a b d)and u2encodes(0 c e)3979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0198] If we want to prove a + b = c and b — d = e, the rTA matrix when arranged as a matrix will look like / r3r3+ r32-r32\\ 0 — r3— r32)Let Vi and v2be the encoding of the two rows of rTA. For the linear test, the prover will give u • vr+ u2■ v2. The resulting vector will have the property' that when decoded, the sum of the values will be 0. Namely, the resulting vector will be(r3x a (r3+ r2) x b — r3X c —r2x d — r2x e)

[0199] Accordingly with two linear constraints: a + b = c and b - d = e, the witness matrix may contain two rows, such as (a, b, d) and (0, c, e). The R A matrix is constructed so each coefficient aligns with the particular constraint and witness variable. For instance, a receives a coefficient of B, b receives B + D2. d receives -B2. C receives -B, and e receives -B2When the Prover computes the pointwise products, aggregates them, and sums the result, the sum is zero if and only if the original constraints are satisfied. For instance, the determination can be as follows: r3xa + 0x0. n + n squared times b - nxc. and - n squared times t - n squared times e. When these are added up, the total will go to 0. That is, if the constraints were satisfied, it will go to 0.

[0200] A point is that r transpose AW should be 0. That is the goal because AxW should be 0. A captures all the linear constraints. AxW should be 0, which means even if a computer pre-multiplies with r transpose, the result should be 0. For example, if multiplying a and b with n and c with - n and if a + b = c, when the system multiplies with n, the result should go to zero when these are add up. Thus, r3a + nb - nc should go to zero if c was correctly computed. Similarly, there is r- squared times b - n squared times d - n squared times e. That should also go to zero. Because b- d - e = 0.

[0201] A key feature is that every' check is ultimately a row aggregate computed via row operations, which enables the Verifier to validate these aggregates efficiently on a columnwise basis. This approach allows the Verifier, by examining just a few randomly selected columns, to check with high probability that the Prover’s aggregate computation is correct and the constraints are satisfied throughout the entire witness.4079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0202] However, for the linear check, the Verifier must recompute the encoding of R‘ x A (which may also be written as fTA) in order to validate the spot checks, and this computation is linear in the size of the constraint matrix A — meaning the verification is not succinct for unstructured computations. Nonetheless, the use of randomness, redundancy in encoding, and Merkle tree commitments ensures that any attempt to cheat by the Prover is overwhelmingly likely to be detected in the spot checks, preserving the soundness and security of the protocol.5. Efficiency metrics

[0203] Some efficiency metrics are now addressed. A way to compile interactive oracle proofs (lOPs) to ZKSNARKs is to use Merkle trees to commit to the encoding and give Merkle decommitments for the spot checks and Fiat-Shamir heuristic to remove the interaction. The leaves of the Merkle tree can be the symbols of the codeword, namely the columns of the encoded matrix.

[0204] For Proof Length: Suppose the witness can be arranged in a-m x f matrix and t leaves / symbols / columns are opened for spot checks. The Reed-Solomon encoding has parameters k-block length and n-code length where k> f + t. Let |C| =x £ denote the total size of the computation. Now, the proof contains:• Columns: t symbols which is t x m field elements if the Reed-Solomon is over some field.• Row aggregates: 3 x n.• Hashes: Merkle root which is a single hash, t decommitments which contains t x log (n) hashes.There is flexibility in choosing the dimension of the matrix, m and £. So optimizing for proof length / results in a total proof length of O(^t x |C|) field elements and (t + 1) x log2(n) hashes where t can be set as the security parameter (e.g., 128. 256, etc.).

[0205] For Prover computation: Asymptotically, the expensive part of the Prover’s computation is the encoding. If the underlying finite field admits a Fast-Fourier Transform, i.e. encoding of each row can be done in time n log2 n, then the overall time is O(| C| log2 I ).4179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0206] For Verifier computation: For unstructured computation, the Verifier's time is proportional to the size of the computation. The main computation bottleneck in the Verifier’s computation is the spot check on the linear test. For structured computation, the Verifier’s computation will be proportional to O G ). Techniques above can achieve efficiency for structured computation but not for unstructured computation.III. SUCCINCT VERIFICATION FOR LINEAR TEST

[0207] As mentioned above, the linear test is more challenging to perform in a succinct manner. A challenge for the efficient verification of linear constraints is confirming that a Prover’s encoded witness satisfies a system of linear or affine relations, formalized as A w = b. While these systems achieve sublinear verification for many aspects of the protocol described in section II. B.4, particularly for multiplication and proximity' checks, the linear test presents a significant obstacle to succinctness. As described above, the Prover computes an aggregate value encoding FA • w for a random vector r, and the Verifier checks that this matches Fb.

[0208] However, in order to perform this check, the Verifier recomputes the encoding of FA (where A is the constraint matrix and r is the random vector), and for each spot-checked column, extract the corresponding elements from this encoding to compare with the Prover’s responses.This is not succinct, since the Verifier’s work is proportional to the size of the constraint matrix A, which grows linearly with the complexity7of the computation being proved. As a result, for large or unstructured computations, the Verifier’s computational burden in reconstructing FA and extracting relevant columns for spot checks undermines much of the efficiency gained elsewhere in the protocol. Although the TOP framework provides strong guarantees of soundness and privacy, the lack of succinctness in the linear test is a critical limitation, particularly for scaling zero-knowledge proofs to large programs or for use in resource-constrained settings such as blockchain verification or mobile devices.

[0209] To overcome the inefficiency inherent in the Verifier recomputing FA, the protocol described in this section introduces a preprocessing step that fundamentally changes how the linear test is performed. A key insight is to shift the responsibility7for computing FA from the Verifier to the Prover. In the updated protocol, before the main proof is generated, a succinct commitment to the constraint matrix A can be established as a one-time setup — this could be,4279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 for example, a Merkle root of an encoding of A. When the proof is generated, the Verifier (or. in a non-interactive protocol, via Fiat-Shamir) can selects a random vector r. The Prover computes rTA (also referred to as r’), encodes it just as it encodes the witness, and commits to the encoding, e.g., by constructing a Merkle tree. This commitment to r‘A is provided to the Verifier alongside the commitment to the witness.

[0210] The Verifier can perform spot checks on the Prover's commitment to r‘A in exactly the same way as it does for the witness matrix. When the Verifier samples columns for spot checks, it requests the corresponding columns from both the encoded witness and the encoded r‘A, along with the necessary decommitments (e.g., Merkle decommitments ). The Verifier checks, for each sampled column, that the Prover’s aggregate computations (such as pointwise products and sums) are consistent, without ever having to recompute r‘A. This approach dramatically reduces the Verifier’s workload to simple local checks on a small number of revealed columns, rather than reconstructing a potentially very7large encoding of r‘A.

[0211] To ensure soundness and prevent the Prover from cheating by sending an incorrect r‘A, the protocol can use a fingerprint mechanism. The Prover computes a fingerprint — such as a = fA s for a second random vector s — and provides a secondary proof that this fingerprint is consistent with the original, public commitment to A. The Verifier checks that the fingerprint matches both the committed r‘A and the original constraint matrix, without ever reconstructing the full r‘A vector. This two-layer structure — spot checks for local consistency, and a fingerprint for global consistency — ensures that any attempt at dishonesty by the Prover is detected with high probability, all while maintaining succinctness for the Verifier.

[0212] By offloading the linear constraint encoding to the Prover and relying on spot checks and a succinct fingerprint, the protocol achieves succinct verification even for complex or unstructured computations. This innovation enables support for very large computations, dynamic program flows, and applications like on-chain verification where the Verifier’s computational resources are limited. The approach retains all the zero-knowledge and soundness guarantees of the original system and integrates naturally into the broader Ligero / Ligetron proof framework. See cited papers elsewhere within this disclosure.4379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 A. Precomputation of rTA and signature

[0213] To provide the succinctness for the linear check, the prover can provide fTA so that the verifier does not have to compute it. The verifier obtains a fingerprint (e.g., as a message authentication code, MAC) of fTA, namely fTAs. The prover proves the fingerprint is correct w.r.t to the commitment of the constraint matrix A that is committed to in a pre-processing phase, e.g., as part of a secondary (second) proof.

[0214] The protocol incorporates a fingerprinting mechanism, in which the Prover computes a succinct fingerprint a = r‘A s and provides a secondary7proof of its consistency with the original constraint matrix. The Verifier then performs spot checks on selected columns for local consistency and verifies the fingerprint for global consistency, achieving efficient and sound verification without the need to reconstruct the full r‘A encoding.

[0215] The first proof convinces committed rA times s equals alpha, which can be spot checked using commit (rA) and its related decommitments to confirm they are consistent with s and alpha according to this relationship. The second proof convinces r times committed A times s equals alpha, which can be spot checked using commit (A) and its related decommitments to confirm they are consistent with s, r, and alpha according to this relationship.1. First Proof

[0216] FIG. 11 shows a process flow using preprocessing-based succinct verification for linear constraints in zero-knowledge proofs. FIG. 11 illustrates how the preprocessing-based protocol enables the Verifier to efficiently and succinctly validate the correctness of linear constraints, offloading the heavy computation to the Prover and relying on spot checks and a fingerprint mechanism to guarantee soundness and security. A secondary proof is provided for the fingerprint’s consistency with the original constraint matrix.

[0217] In step 1110, the process begins with a preprocessing phase in which a succinct commitment to the constraint matrix A is generated. This commitment CA — such as a Merkle root of an encoding of A — serves as a public reference for the constraint system that governs the computation. This commitment is created once for each application or program to be proved, and both the Prover and Verifier have access to it. The commitment ensures that the structure of the constraints remains fixed and verifiable throughout all subsequent proofs.4479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0218] In other embodiments, the verifier or a trusted party can compute this commitment CA on its own, which may also be done as a preprocessing step. Any of these computer can extract the A matrix from the computer program such that the constraints between the values in the witness w is captured by A. The constraints A provide the relation among the input values, input values, and the final output value(s) without specifying their specific values, just the relation. Thus, the set of system linear equations for an application (program) will not change from input to input and so this preprocessing only needs to be done once. But any randomness (e.g., random vectors r and s) are done for each verification.

[0219] In step 1120, the Prover executes the software program on the given input to generate the witness w. The witness includes all input values, intermediate results, and final outputs necessary to verify the computation. The Prover then encodes the witness (for example, using a Reed-Solomon code) and commits to the encoding, e.g., by constructing a Merkle tree over its columns. The resulting Merkle root can serve as the commitment to the witness, which is sent to the Verifier. This commitment binds the Prover to a specific set of computation results without revealing any secret information. The size of w corresponds to the size of the number of add gates and multiply gates in the circuit. This is referred to as the computational size or the number of gates.

[0220] In step 1130, the Verifier generates (or, in a non-interactive setting, derives via Fiat-Shamir) a random vector r. Examples for how7to generate the random vector r are provided in a section below.

[0221] In step 1140, the Prover uses random vector r to compute PA, which is a linear aggregation of the constraints in A. The Prover encodes rTA, e.g., in the same manner as it encoded the witness and commits to this encoding, such as by constructing a Merkle tree over its columns. The commitment to r‘A is provided to the Verifier, e.g., alongside the witness commitment. Commit (r‘A) and commit (w) can be used by the verifier computer to verify that r‘Aw = r‘b.

[0222] In step 1150, the Prover obtains another random vector s (again, generated or derived via Fiat-Shamir).

[0223] In step 1160, the prover provides a fingerprint athat is consistent with the random vector r‘A and the random vector s. Using both r and s, the Prover computes a fingerprint4579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 value, a = r'A s. This fingerprint succinctly summarizes the global consistency of r'A with respect to the original constraint matrix A and the random vector s.

[0224] The Prover also prepares a first proof that this fingerprint a matches both the committed r'A and the public commitment to A. The first proof proves that fingerprint a revealed by prover is the inner product of the vector (rA) committed in step 1140 and the powers of the random vector s. The inner product can be checked using decommitments.

[0225] The first proof can include all the elements necessary for the Verifier to check both the local (e.g., spot checks) and aggregate consistency of the Prover’s claims regarding the witness and the linear aggregation r'A, without reconstructing large encodings or the full constraint matrix. Specifically, the first proof can be verified using: (1) the commitment to the witness; (2) the commitment to r'A; (3) aggregate values from the proximity, multiplication, and addition (linear) checks; (4) the fingerprint a; and / or (5) decommitments (e.g., Merkle decommitments) for spot checks. For a randomly selected set of t columns, the Prover provides the actual column values from both the encoded witness and the encoded r'A, along with the corresponding Merkle decommitments (i.e., authentication paths) that allow the Verifier to check that these revealed columns are authentic and were part of the originally committed data. As a reminder, the aggregate values can be computed as random linear combinations over the encoded witness and r'A, demonstrating that the encodings are consistent with the claimed code structure, e.g., via the constructed circuit.

[0226] Altogether, the first proof enables the Verifier to (1) confirm that the Prover’s aggregates are correct for the sampled columns, (2) verify that the encodings and commitments are internally consistent, and (3) utilize the fingerprint a as an anchor for subsequent global consistency checks through the secondary' proof. This structure allows the Verifier to achieve sound, succinct verification without heavy computation or full reconstruction of the constraint system.

[0227] In step 1170, the Prover performs a sequence of aggregate checks on the committed witness and the committed linear aggregation r'A, utilizing the random vectors provided (such as r and s). The verifier can use commit (r'A), commit (w), and corresponding decommitments to perform spot checks efficiently, particularly the linear check.

[0228] These aggregate checks consist of the proximity check, multiplication check, and addition (linear) check. For the proximity check, the Prover computes a random linear4679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 combination of the rows of both the encoded witness and the encoded r‘A and demonstrates that the resulting aggregates are valid codewords under the encoding scheme (such as Reed-Solomon). This confirms that both the witness and the linear aggregation have been encoded correctly and consistently, binding the Prover to their respective committed values. See description of FIG. 7 for more details.

[0229] The multiplication check is carried out by structuring the witness so that each multiplication constraint corresponds to a triplet of rows. The Prover computes aggregate values that succinctly capture the validity of all multiplication gates, using the random coefficients to combine the relevant row s. The Verifier can then check that these aggregates encode all zeros, ensuring the multiplication constraints are satisfied. See description of FIGS. 8A and 8B for more details.

[0230] For the addition (linear) check, the Prover leverages the committed rTA, computing aggregate values that encode the satisfaction of all linear constraints (A • w = b), again using the random vectors for aggregation. Importantly, the Verifier can now' validate these aggregates and their consistency with the commitments using spot checks and the fingerprint mechanism, without having to reconstruct rTA itself because the verifier can use commit (rTA) that was provided by the prover. This approach preserves the efficiency and succinctness of the verification process, while maintaining strong soundness guarantees.

[0231] In step 1180, the verifier can perform queries to get data (e.g., decommitments and certain column of encoded matrices) to perform spot checks on the Prover's commitments. For each of t randomly selected columns, the Verifier can request the corresponding columns from both the encoded witness and the encoded r‘A, along with the relevant Merkle decommitments. The Verifier can check that the local aggregates (such as pointw-ise products and sums) are consistent across the sampled columns, as described in the previous section. These spot checks ensure that the Prover's computations are locally consistent with the commitments, without requiring the Verifier to reconstruct rTA in its entirety.

[0232] Steps 1170 and 1180 can be performed together. For example, commit (rTA) and commit (w) can be used by the verifier computer to verify that r'Aw = r‘b, which checks the linear constraints. The process can be similar to that performed in the quadratic test, where, it was shown for a group of 3 rows, row 1 times row 2 - row 3 encoded all 0s. For the linear test, the prover reveals the linear test computed as a sum over i of products of row i of4779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 commit (w) times row i of commit (rtA). This sum encodes r‘Aw, which should equal r’b. The verifier can spot check if the aggregate provided was correct.

[0233] Accordingly, using the first proof, the verifier can confirm that the received fingerprint a equals the inner product of the random vector r and the random vector s. The linear constraints incorporated as rA in the first proof can be verified to provide fingerprint alpha using the commitment to rtA, aggregate values, and decommitments, as well as random vector s. But such a check is not sufficient as it does not confirm consistency with the public commitment to the constraints A.2. Second Proof

[0234] The first proof, while highly efficient for verifying local consistency and aggregate checks, is not sufficient on its own to guarantee full soundness in the succinct verification protocol. This is because the first proof allows the Prover to supply commitments and aggregates for the encoded witness and the encoded linear aggregation r‘A, and to demonstrate via spot checks that these commitments are internally consistent and that the sampled columns agree with the claimed aggregates and encodings. However, this process only ensures that the Prover is being honest with respect to the data it has itself committed — it does not guarantee that the Prover’s commitment to r‘A is actually derived from the authentic, public constraint matrix A.

[0235] In other words, without additional safeguards, a malicious Prover could potentially construct a fake or manipulated rA. that passes all local spot checks and aggregate consistency tests, but which does not correspond to the correct linear aggregation of the true constraint matrix A. Since the Verifier never reconstructs r‘A directly, the verifier can perform a separate proof to ensure that the Prover's commitment to r‘A is globally sound and rooted in the original, public A.

[0236] The second proof cryptographically ties the fingerprint a (claimed as a = rTA s) back to the original commitment to A, using a succinct proof system (such as a SNARK or polynomial commitment prool). By doing so, it provides global assurance that the Prover’s claimed r‘A, and therefore all local spot checks and aggregates, are indeed based on the authentic constraint matrix A. Using both the first proof (for local and aggregate consistency) and the second proof (for global consistency with A), the protocol achieves full soundness.4879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 ensuring that a cheating Prover cannot successfully fake the satisfaction of the linear constraints without being detected.

[0237] In step 1190, the Verifier receives a secondary proof for the fingerprint a equaling r‘A s to check global consistency. Some of the parts of the secondary proof can be generated by the Verifier, e.g., using Fiat-Shamir. The Prover can generate the secondary proof that the fingerprint a is correctly computed as a = rTA s, where r and s are the random vectors selected during the protocol. This secondary proof can be constructed relative to the public commitment to the constraint matrix A, which was established in the preprocessing phase. Specifically, the Prover can demonstrate (e.g., using a succinct SNARK or similar proof system) that given the committed A, and the public vectors r and s, the value a is indeed the result of first computing rTA and then taking the inner product with s. The proof attests that the Prover’s claimed a cannot be forged or manipulated without knowledge of A and the correct computation, as the Verifier will check that a matches the committed A under the specified randomization. This secondary proof can be made non-interactive and highly efficient, and it allows the Verifier to trust that the fingerprint a faithfully represents the global relationship between r, A. and s, all while avoiding the need to reconstruct or process the entire r‘A vector. As a result, the protocol maintains both succinctness and soundness in verifying the satisfaction of all linear constraints.

[0238] The secondary proof can refer to data needed to verify that when the fingerprint computed on the A matrix that was committed in preprocessing is alpha. Thus, the secondary proof can be verified using: (1) the commitment to A from step 1110. (2) random vectors r and s, (3) the fingerprint a provided in step 1160, and decommitments for commit (A). As examples, this succinct proof can be generated using a SNARK, polynomial commitment, or similar cryptographic mechanism. The Prover can provide a non-interactive proof that, given the committed A and the public vectors r and s, the value a is truly the result of the inner product computation (i.e., a = s). This proof demonstrates that a could not be correctly computed unless the Prover used the authentic, pre-committed constraint matrix. The secondary' proof does not have to be zero knowledge and can be computed on another computer, e.g., a server.

[0239] The secondary proof does not require the Prover to reveal A or rTA in the clear, nor does it require the Verifier to process large encodings or reconstruct the full linear aggregation. Instead, it leverages the commitment to A and the succinct proof mechanism to4979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 efficiently verify, with high assurance, that the Prover’s fingerprint a is legitimate and not forged. In protocols supporting dynamic program structure or branching (e.g., as described in section IV), the second proof can also include commitments and succinct proofs corresponding to the constraint submatrices for individual blocks, as well as secret execution sequence information, all structured to preserve zero-knowledge and efficiency.

[0240] The Verifier uses (1) the fingerprint a provided in step 1160 and (2) the secondary proof determined using the sparse commitment A from step 1110 to check global consistency. The Verifier confirms that the fingerprint matches both the Prover's commitment to r‘A and the original commitment to A, all while relying on succinct, sublinear verification. If all local spot checks and the fingerprint verification pass, the Verifier accepts the secondary’ proof as valid, confident that the Prover's witness satisfies the linear constraints. If any check fails, the proof is rejected.

[0241] For the secondary proof, spot checks can be performed using the commit (A) along with the knowledge of random vectors r and s. Only certain parts of the commitment to A are needed for the spot checks, so the level of complexity can be relatively low. A variety’ of techniques can be used, e.g., Spartan or variants of techniques described herein.

[0242] With the only the first proof, the verifier cannot be certain because the prover could have committed anything for rA. But the prover did so, the second proof cannot establish that r times the constraint matrix A (committed in preprocessing) times s equals the same alpha.3. Example implementation for Fiat-Shamir

[0243] Some examples for generating randomness r and s are provided below.

[0244] One approach can hash the commitments and public inputs produces a deterministic, unbiased random vector r. Both the Prover and Verifier independently generate the random vector r by hashing the concatenation of all relevant public data and commitments. After the commitments to the constraint matrix A and the witness w are fixed (for instance, their Merkle roots), these values can be concatenated together with any public inputs to the computation, forming a single bitstring. This bitstring is then hashed using a secure cryptographic hash function such as SHA-256. The resulting digest is interpreted as a seed for randomness, from which the entries of r are deterministically derived — either by expanding the hash output as a pseudo-random stream or by repeatedly hashing with incrementing counters to obtain each entry, reducing as needed to the appropriate field 5079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 elements. This method ensures that the randomness is fully determined by the protocol state up to this point and is unpredictable until all commitments are finalized.

[0245] Another technique can sequentially hash the public data with each index generates the entries of r in a reproducible and verifiable way. This technique can involve sequential hashing for each entry of r. Here, for each index i in the desired vector r = (r₁, r₂, ..., rk). the protocol computes n by hashing the concatenated public data along with the index i itself. Each hash result is then reduced modulo the underlying field’s characteristic to yield a valid field element. This process is repeated for all k entries, resulting in a random vector whose components are individually derived but all tied to the same set of public commitments and protocol state. By ty ing each entry to its position in the vector, this approach guarantees both determinism and uniqueness for every coordinate, while remaining unpredictable to the Prover until all commitments are fixed.

[0246] Y et another technique can hash the protocol transcript and expand the result via a pseudo-random number generator (PRNG) yields a deterministic r suitable for non-interactive proofs. A transcript can be assembled of the protocol up to the point when r should be generated. This transcript can include public inputs, commitments (such as those to A and w), and any other relevant context. The transcript is then hashed to obtain a seed, which is fed into a cryptographically secure pseudo-random number generator (PRNG), such as HKDF or a stream cipher. The PRNG expands the seed into a stream of random bits, from which the vector r is deterministically extracted — again, reducing as needed to field elements. This allows both Prover and Verifier to independently and identically generate the random vector, using only the transcript, without further interaction.

[0247] An additional technique can including a domain separator in the hash input to keep the randomness for r unique and isolated from other protocol components. This technique can ensure that the randomness used for generating r does not conflict with other uses of Fiat-Shamir in the protocol (or in other protocols), a domain separation technique can be employed. This involves prepending a unique domain string to the data being hashed. The domain string, along with the commitments and public inputs, is concatenated and then hashed to derive the seed for randomness. The rest of the process follows one of the methods above to generate the entries of r. Domain separation ensures that the randomness for r is isolated and protocol-specific, mitigating the risk of cross-protocol interference or hash collisions.5179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0248] The random vector s can be generated in a similar manner as described for the random vector r.B. Further details on Verification

[0249] Further details of the problem and solution of the verification are provided below.1. Checking AW=b by computing rA

[0250] A goal is to verify A x w = b. A random vector r can be used to prove that r x Aw = r x b, where A as a matrix, w is a column vector, and r is a row vector. Thus, when r x A xwis performed, r x b is an inner product that provides a single number. This combines constraints. Instead of checking each computation a single number can be used.

[0251] But to check, the verifier would need to compute r x A and r x b. Further, the verifier does not get w. As part of the proof system, the verifier can compute r transpose A, but this is proportional to the size of the entire computation performed by the prover and so it is not succinct.

[0252] The pre-processing described above can help with proving the linear constraints. Except for the linear test, the rest of the verification is sublinear. All linear constraints are captured by the system of linear equations A ■ w = b where A is a matrix and b is a vector. In the linear test, the Prover provides a row aggregate that encodes the value rTx A x w where r is a random vector derived from n obtained from Fiat-Shamir. The Verifier checks if the row aggregate Agg / / „ decodes to the value rTx b. effectively checking if rTx A x w = rTx b.

[0253] In the spot check, the Verifier can recompute Aggim on the t sampled columns and this requires recomputing rTX A. Since this computation is linear in the size of the A matrix (actually linear in the number of non-zero entries of A), the verification is not sublinear. In slightly more detail, the Verifier would need to recompute an encoding encriu of rTX A and then extract the same t columns from that encoding.2. Use of two random vectors for efficiency

[0254] To get succinctness, the prover can generate r x A as a vector f and provide a commitment to r’. The prover can treat r * A as secret values, but then the prover can cheat if5279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 nothing else is done. The verifier can check that it got the right vector r' that correspond to rxA, but in a different way. As for the witness w, rA will also be committed. The verifier can check that rAw equals rb. Then the verifier can check that rA is correct. To check rA is correct, another random vector s is used to reveal r’ x s equals a single fingerprint number, alpha, which is also received form the prover. But the verifier does not know that alpha is correct.

[0255] A secondary proof can be used to check alpha. In the preprocessing step, the A matrix was committed. A second proof can confirm that r x A * s is equal to alpha. For the second proof, the preprocessing step committed to A. With this preprocessing step with the A, the prover cannot cheat that rAs is also equal to alpha. The verifier could compute alpha to verify the fingerprint alpha because A is known. But the verifier does not do that because it is expensive and instead uses the alpha the prover provides. If the first proof passes the verifier's checks, the probability that the rA times s by the prover is not equal to alpha is negligible. Similarly, if the second proof passes all the verifier's checks, r times (committed A in preprocessing) times s not equal to alpha is negligible. Combined, if both proofs pass the checks, the prover not having committed to rA in the first proof is negligible. In this manner, the verifier checks without computing A, rA, or alpha.

[0256] Accordingly, in the first proof, the prover can commit to rA, e.g., a merkle root hash. The prover can provide an aggregate that is computed over the rows of the committed rA with s. This aggregate, when the verifier decodes, should equal rAs if prover performed operations correctly. The verifier does not know what prover committed to as rA. but the verifier can spot check the aggregate and be convinced that whatever was committed to in place of rA (e.g., referred to as a vector r') will satisfy that r's = alpha, since alpha was also shown to be equal to rAs in the second proof. The verifier can conclude that if the prover committed anything else besides rA for r', the probability the first and second proof agree on alpha would be very small.3. Example solution of second proof

[0257] As described above, the second proof can be performed in various ways (e.g., Spartan at eprint.iacr.org / 2019 / 550] or Ligero. Lightweight Sublinear Arguments Without a Trusted Setup, CCS’ 17, October 30-November 3, 2017, Dallas, TX, USA ) as will be appreciated by the skilled person. Since these do not involve performing operations using A5379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 (e.g., multiplying A by a vector or other matrix), the second proof can be succinct. In the example below, we describe techniques that perform the first proof and the second proof in a combined manner.a) Offline Phase (Preprocessing) - Block 0

[0258] At block 0, for the offline phase, randomness is provided. An example of a randomness row can be used. In this example, we work over a cyclic row of length €. For illustration, here are the first few entries:1 2 3 4... €

[0259] A sequence of constraint tuples can be generated. We convert each nonzero term into a triple (coeff, i, j) where coeff is the integer coefficient, i is the exponent of r, and j is the column index (variable sequence). For the example row above, the extracted sequence is:(3, 1, 1), (4, 2, 1) # from $3r + 4r"2$ in column 1(5, 1, 2), (-1, 3, 2) # from $5r - F3$ in column 2(1, 1, 3), (1, 2, 3), (1, 3, 3), (1, 4, 3) # from $r + r 2 + r’3 + r"4$ in column 3

[0260] A pre-processing matrix (e.g., of A) can be built. The coefficients can bearranged into a “constraint matrix” M_pre. The value i denotes the power of r and j denotes the constraint number. Cnt i and Cnt j is a counter of how many times the correspondingpower of i and j have been accessed.3r 4r25r r3p r2r3r4Row 1 (coeff) 3 4 5 -1 1 1 1 1...Row 2 (i) 1 2 1 3 1 2 3 4Row 3 (j) 1 1 2 2 3 3 3 3...Row 3 (cnt i) 1 1 2 1 3 1 2 1...Row 3 (cnt j) 1 2 1 2 1 2 3 4...Matrix M_pre.

[0261] A commitment can be generated, such as a Merkle-root hash. For example, the following steps can be performed: pad, encode, and Merklize. As part of padding, a zero-pad can be applied to each row of M_pre up to the next power-of-two length. As part of encoding, each padded row can be encoded into the desired field element representation,5479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 where these rows can be called Mi-rows. For the commitment, a Merkle tree can be built over the list of encoded rows. The commitment p0(e.g.. the Merkle-root hash) can be output as the result of pre-processing.b) Online Phase (first proof)

[0262] At block 1, a witness commitment is generated. This can be performed in a same way as described above. For example, an extended witness can be generated by evaluating the program. A blinding row can be added for linear test and quadratic test.Further details on a blinding row are provided in Ligero (2017). Rows can be padded with randomness and then encoded. The rows of the matrix can be called the u1-rows. A witness commitment p can then be generated, e.g., by generating a Merkle tree and computing the Merkle root.

[0263] Regarding a blinding row; the linear test and quadratic test aggregates can leak some information on the actual witness values. To achieve privacy, the values can masked so that this leakage is removed. For example, in the linear test, the verifier can receive an aggregate row which it decodes to get a vector of values whose sum needs to be checked if equal to r'b. Here the vector of values could leak something but the sum of them does not as it is equal to rlb. In order to remove the leakage while keeping the sum correct, a row can be added to the committed witness w that contains random values that sum up to 0. This row¬ will be added to the aggregate when computing the linear test. This modification will not affect the sum computed by the verifier but can mask all the values of the aggregate (computed without the blinding row). For the quadratic test a similar technique is used.

[0264] As part of a Fiat-Shamir to make the process non-interactive, the following values can be hashed together to genera a hash hp (public inputs) x * p0(Merkle root of Pre-processing stage) * pt (Merkle root of Stage 1).

[0265] At block 2, randomness can be generated. For example, randomness rows can be generated using r obtained from Fiat-Shamir. The rows can be pad with 0 (e.g., as opposed to randomness) and encoded. One more row7can be add at the end that contains minus of single constant sum. and that row can be encoded. The resulting rows of the matrix can be called the u2-rows. A commitment p2can be generated, e.g., by generating a Merkle tree and computing a Merkle root.5579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0266] The result of linear test can optionally be determined, e.g., as done for the first proof. This result can be included in the proof at this time or later.

[0267] As part of a Fiat-Shamir process, the following values can be hashed together for form a hash h2*(everything hashed in Stage 1) * (Merkle root) p2* (linear test result if computed here).

[0268] At block 3, an encoded Matrix M_pre is generated, e.g., to be memory efficient so it is recomputed as was done in the precomputing stage 0. We can start with Mpre (computed during pre-processing), which is repeated here:[ 3 4 5 -1 1 1 1 1 ][ 1 2 1 3 1 2 3 4 ][ 1 1 2 2 3 3 3 3 ][ 1 1 2 1 3 1 2 1 ][ 1 2 1 2 1 2 3 4]Matrix Mpre

[0269] A seed s is generated using Fiat-Shamir. The following rows (matrix below) containing powers of r, s and its product can be encoded. The rows can be padded with 0. Here the randomness is separated,, e.g., by computing the sum over i and j of r1x aij x s’. The prover computes n and Sj separately and commits to them, so that the verifier does not need to compute them on its own. In the next stage, the prover proves that it computed the powers correctly. The rows of the matrix can be referred to as the u3-rows. The resulting matrix (U3 matrix) can take the example form for the Mpre described above:1 2 3 4 5 6 7 8

[0270] In this example for Matrix Mpre. the rows are grouped 5 at a time. Rows 2 and 3 are the powers of r and j. For each group of 5, there are three rows in this stage. A sample of the three rows is what is described in the table above. The power of r corresponds to values in row 2 of the group of 5 from Mpre and the power of s in the second row corresponds to the value in row 3 of Mpre. The third row in the table above is the product of the first two rows5679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0271] A commitment p3can be generated. For example, a Merkle tree and Merkle root can be generated. For Fiat-Shamir, the following items can be hashed together to form hash h3 / i2(hash from stage 2) * (Merkle root) p3.

[0272] At block 4, lookup arguments can be determined. Using Fiat-Shamir, random samples X, A, B, C, and D can be generated. Rows in pairs for the powers of r and powers of s can be prepared for a U4 matrix. The randomness is separated in this block, which is proving that the prover computer, for every i and j, it computed rAi and sAj correctly. There is a table with powers of r and s where ith row contains rAi and sAi that are being looked up. The table is virtual and not needed as part of proof.

[0273] As example, for r, the first row of the pair can contain X — iA — rlB — (cnti^C and the second row can contain X — iA — rlB — (cnti) + 1)6. For s, the first row of the pair can contain X — jA — s1B — (cntj)C — D and second row can contain X — jA — sJB — (cntf) + 1)6 — D.1 2 3 4 X - A ■ 1 - B - ri - C - 1 X - A - 2 - B - TZ - C - I X - A - l - B - ri - C - 2 X - A - 3 - B - r3 - C - l X - A - l - B • r1- C • (1 X ~ A ■ 2 ~ B ■ f2- C ■ (1 X - A - l - B • z+ - C ■ (2 X - A - 3 - B - r2~ C - ( l + 1) + 1) + 1) + 1) X - A - l - B - s1- C • 1 X - A - l - B - si - C - 2 X - A - 2 - B - S2 - C - 1 X - A - 2 - B - s2~ C - 2 - D - D - D - D X - A - l - B • si - C- X - A - l - Bs1-C- X - A - 2 - B ■ s2- C- X - A - 2 - B - s2~ C- (1 + 1) - D (2+ 1)- D ( 1 + 1J - D (2+ 1)- D5 6 7 8 X - A - l - B - ri - C - 3 X - A - 2 - B - f2~ C - l X - A - 3 - B - r3- C - 2 X - A - 4 - B - t^ - C - l X - A - l - B - A - C - (3 X - A - 2 - B - ^ - C - (l X - A - 3 - B - r2- C - (2 X - A - 4 - B - r+ - C - ( l + 1) + 1) + 1) + 1) X - A • 3 - B • s3- C • 1 X - A ■ 3 - B • s3- C ■ 2 X - A • 3 - B • s3- C • 3 - X - A • 3 - B ■ s3- C • 4 - - D - D D D X - A - 3 - B - s? - C- X - A ■ 3- B ■ s3- C- X - A - 3 - B - sA - C- X - A - 3 - B - s? - C-(1 + 1)- D (2+ l) - D (3+ 1J - D (4+ l)- DAs shown, for each pair of r,s rows, there can be 4 rows in this matrix.

[0274] In addition to these rows, an intermediate computation can be performed where rows 1,3,5,... are multiplied together and 2,4,6,... are multiplied together to check if products are5779340501 V 4PATENT Attorney Docket No. 116297-000210PC- 1492484 equal. We can multiply these rows pointwise. Then finally there are two rows, and the system can show that the product of the secrets in these rows are equal.

[0275] One way is to compute another row that contains the inverse of the elements of one row. The system can prove it is the inverse by multiplying the row with the inverse row and assert all secrets are 1. Then the provider computer can multiply the second row and the inverse of the first and reveal that. The verifier can take the secrets of that revealed row and check if the product of the secrets equal 1.

[0276] A second way is for the Prover reveal the row that is the product of 1,3,5,... and also reveal the row that is the product of 2,4,6, and the verifier can multiply the secrets on these two revealed rows and check if they are equal.Initial Rows _Product of (rows 1 and 3)Product of (rows 2 and 4)Product of (rows 5 and 7)Product of (rows 6 and 8)Product of (rows 1 and 3 and 5 and 7)Product of (rows 2 and 4 and 6 and 8) - RowEvenInverse of RowEvenFor all the rows generated in block 4, the rows can be padded with 0 (as opposed to randomness) and encoded. A commitment p4can be generated, e.g., by generating a Merkle tree and a Merkle root.

[0277] At block 5, tests can be performed, such as code test, multiplication (quadratic) test, and linear test. Randomness p can be obtained from Fiat-Shamir. For this implementation, the aggregate tests can be performed again. In other implementations (e.g., Spartan), they do need to be done.

[0278] A code test can be performed to rows ur, u2, u, u4(corresponding to matrices Ul, U2, U3, and U4) with powers of p. A consideration is that it is preferred not generate the rows in each of u, u2, u3and u4sequentially because the system would make 4 passes on the entire witness to do that in Stage 5. Instead, the system can do them in parallel and while doing it compute the code test aggregate. Two options are:5879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 (i) if we generate first row of u2, u3, u4, the system (prover) can use p, (JJ2, (p)3, (p)4for them. When the system generates the next set of rows it can use (P)5> (P)6< (P)7< (P)8- (ii) For the other option, the system can use p, (pY1, pY1*112, pY1, +ri +'1'' for first set of rows and(p)2, (p)V1+1, pyh+ + s+i forsecond set of rows, where T|i, i, i]3 are the number of rows in it17u2, u3respectively. Preferably, the system should compute pi, r|2, T|3 when we generate the stages. Different powers of p can be used for each row.

[0279] The linear test can be performed the same as 1.0. e g., as follows. Multiply element-wise i"th row of Stage 1 encoded values and i-th row of Stage 2 encoded values and sum them up over i. There is no need of p in this stage, the randomness for the linear test can be that used in Stage 2 (Observe that the i-th row of Stage 2 are the randomness rows corresponding to the i-th row in Stage 1). Reveal the aggregate as the result of the linear test

[0280] For the quadratic test, quadratic constraints arise in rows u17u3 / it4 / u5. With powers of p, the system (prover) can compute the aggregate over all these constraints together.

[0281] A fingerprint on the rows committed in block 2 in two different ways can be revealed and checked if they are equal. First, the system can compute a linear test on the rows of block 2 where the randomness rows encode (1, s,If € be the packing factor, it can be done as follows: Encode (.s; s1, ), call this row s. ComputeQ / pi = Q u2\j\)j=owhere the summation is over the rows of u2and O is elementwise product. The Prover can reveal this aggregate in the clear. The verifier can decode and sum the elements. This is the fingerprint. For the column check, verifier can compute s and then raise with appropriate powers of v to recompute the aggregate for that column and compare against r / / pi■

[0282] The fingerprint can computed a different way w.r.t block 0 and block 3. The preprocessing matrix in block 0 can grouped 5 -rows at a time where the first row are the coefficients. The matrix in block 3 are grouped 3-rows at a time and the third row is a product. The prover can compute elementwise the encoding of first row' in Stage 0 and 3rd row of Stage 3 for each set and aggregate them. When the verifier decodes this aggregate and sums the5979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 secret values it will be equal to i coeffi ]rlsJ'which is the fingerprint computed w.r.t preprocessed values. Verifier can check both fingerprints are equal.

[0283] At block 6, sample columns can be checked as part of a spot check. The verifier can sample columns across Stages u17u2, u2, u4and u0(from pre-processing). The verifier’s computation can be performed as follows.

[0284] For the code test, check aggregate of code test is a valid codeword and that on the sampled columns they agree for the rows inu2, u2,u4. It checks p was computed correctly according to Fiat-Shamir

[0285] For linear test, a simplification when using preprocessing is that verifier does not have to go through the entire code (e g., multiply A times a vector). First, it can decode the aggregated code (vector) from linear test and check if sum of the values of the aggregated vector add up to 0. By design, the sum of the values of the vector encodes r*A * w. This should be equal to r*b if all the linear constraints were computed correctly in w.

[0286] Then for the column check, for example, column 25, it will take Ithrow of column 25 in Stage 1. multiply with U'-row of column 25 in Stage 2 that are revealed, and sum over i and compare against the 25th element in linear test. (Note we will have to simply add 25th element of blinding row in Stage 1 and the 25th element of row encoding constant sum term in Stage 2).

[0287] For the quadratic test, it can be similar that described in section II. B.3. A difference can be that the test spans across multiple stages. Using correct powers of p, the verifier can check encoding is valid.

[0288] For the fingerprint check, check that the fingerprint computed in two different ways are equal.C. Sequence

[0289] The preprocessing-based protocol for succinctly verifying linear constraints in zeroknowledge proof systems introduces an approach that significantly reduces the Verifier’s computational load, particularly for large or complex computations. By shifting the responsibility for constructing the linear aggregation rTA to the Prover and leveraging commitments, spot checks, and a global fingerprint mechanism, the protocol achieves both6079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 soundness and efficiency. The workflow not only maintains the integrity and zero-knowledge properties of the original system, but also enables practical deployment in resource-constrained settings, such as on-chain verification or browser-based applications. This approach is operationalized through a sequence in which commitments, randomness, and succinct proofs are exchanged between the Pro ver and Verifier.

[0290] FIG. 12 is a sequence diagram 1200 for succinct verification for a system including prover 1205 and verifier 1210. The sequence diagram provides these interactions, illustrating how each component — preprocessing, proof generation, aggregate checks, spot checks, and fingerprint verification — can be orchestrated to ensure both local and global consistency. The protocol can be non-interactive and deterministic, e.g., using the Fiat-Shamir heuristic for generating randomness and anchoring all proofs and commitments as may be done to the public state of the protocol. The system can provide a preprocessing zkSNARK by having the prover provide the t columns of the encoding of rTX A (enCriA) to the verifier and prove they are correct without having the verifier recompute rTX A on its own.

[0291] At step 1212, preprocessing of the constraint matrix A is performed. Here, the full set of linear constraints governing the computation is compiled into matrix form, and a succinct, public commitment to A is generated — such as by encoding A and computing a Merkle root over the encoding. This commitment (e.g., denoted as CA) is published and serves as a reference point for both the Prover and Verifier throughout the protocol, ensuring that all subsequent proofs are tied to a fixed, verifiable set of constraints.

[0292] Accordingly, the constraints A and its commitment CA are provided to the prover and the verifier. Since A is a public matrix, the verifier can compute this on its own, once for each application. Or a trusted third party can perform these operations.

[0293] This matrix A is a sparse matrix, which means most of the entries are 0. One way is to break up the program into program blocks, described in more detail in section IV.

[0294] At step 1214, the Prover executes the target software program using the chosen input values to generate the witness w. The witness encompasses all relevant data — inputs, intermediate values, and final outputs — that collectively demonstrate correct execution of the program. The Prover encodes this witness (e.g., row-wise using an error-correcting code like Reed-Solomon). Such operations are described in more detail in other sections.6179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0295] At step 1216, the Prover applies the constraint matrix A to the witness w, producing the public vector b = Aw. This vector b captures the right-hand sides of all linear constraints and is included in the proof sent to the Verifier. By providing b, the Prover allows the Verifier to check that the encoded witness, if valid, should satisfy all the required linear (affine) relationships, thereby verifying the witness w.

[0296] In step 1218, the prover generates the commitment Cw of the witness w, e.g., as described herein. For example, the prover can construct a Merkle tree over the columns of the encoded matrix. The Merkle root (Cw) can be transmitted as the commitment to the witness, binding the Prover to a specific computation without leaking any secret details.

[0297] At step 1220, the Verifier (or both parties, deterministically via Fiat-Shamir) generates a random vector r, which is used to create a randomized linear aggregation of the constraints. The random vector can be determined using various techniques, e.g., as described above, which may use the constraints A.

[0298] At step 1222, the Prover computes the vector rTA, encodes it in the same manner as the witness, and commits to it, e.g., by constructing a Merkle tree over the encoded r‘A (commitment CrA). This commitment is sent to the Verifier, shifting the computational effort of constructing the linear aggregation from the Verifier to the Prover. Thus, in this step, the prover can generate r'=r7x A and generates a commitment of r’ denoted as CrA

[0299] A fingerprint stage can follow.

[0300] At step 1224, a second random vector s is produced, e.g., via Fiat-Shamir, which can use the protocol state up to this point (including prior commitments). In some implementations, the Prover can construct a vector s= (y s2, V....).

[0301] In step 1226, the provider can compute the fingerprint a = rTx A x s also denoted as a = r A • s, which succinctly summarizes the global relationship between the random vectors and the constraint matrix. This fingerprint a is included in the proof and serves as a compact anchor for global consistency verification.

[0302] At step 1228, an aggregate value of r’ is determined. Viewing the commitment to rTx A as another witness, e.g., as r' x rTx, which is an inner product with itself, the prover can compute a row aggregate AggrTA for a linear test that captures the affine constraint r s = a.6279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0303] The Prover can compute aggregate values for the proximity check, multiplication check, and addition (linear) check. For the proximity’ check, the Prover computes a random linear combination of the rows of both the encoded witness and the encoded rTA, demonstrating that the resulting aggregates are valid codewords under the encoding scheme. For the multiplication check, the Prover arranges the witness so that multiplication constraints correspond to triplets of rows, and computes aggregates that succinctly capture the validity of all multiplication gates. For the addition (linear) check, the Prover leverages the committed r‘A, computing aggregate values that encode the satisfaction of all linear constraints, using the random vectors for aggregation. These aggregates are sent to the Verifier and are used to validate consistency with the commitments.

[0304] At step 1230, the prover can sample t random columns of CrA with their decommitments for spot checking r’. The random columns can be determined by the V erifier or via Fiat-Shamir. Similarly, t random columns can be provided for Cw for spot checking the witness w and its encoded matrix. The prover can include the columns of the encoding of rTx A with their decommitments from the same t locations the Prover uses to sample from the encoding of w.

[0305] Accordingly, the Prover can prepare decommitments (e.g., Merkle decommitments) for a randomly selected set of t columns. For each sampled column, the Prover provides the actual column values from both the encoded witness and the encoded r‘A, along with the corresponding authentication paths (e.g.. Merkle decommitments). These spot checks give the Verifier the ability to efficiently validate local consistency between the aggregates, the commitments, and the sampled data, all without reconstructing the full r‘A vector.

[0306] At this point, the relation of r’ to the constraints A has not been verified. A second proof can be used for that.

[0307] In step 1234, the prover generates the second proof n using the random vector r, the constraints A, the random vector s. the commitment CA. and the fingerprint a. The second proof can be of various types as described herein, e.g., Spartan. The second proof is generated relative to the commitment given in the pre-processing step Commit(A) proving that rTX A X s = a where r and s are of the form (p, pi,...) for p = r and P =s respectively. This proof system can be efficient for sparse matrices A and such a system can be based on FIGS. 2-10 or other systems such as Spartan or Brakedown (eprint.iacr.org / 2021 / 1043). As6379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 an example, any SNARK for bivariate sparse polynomials can be used. The second proof atests that the fingerprint a is correct and valid for the previous determination of a. thereby confirming that r’ is correct, so it may be used in verifying the witness w, e.g., using spot checks.

[0308] In step 1236, various values are provided to the verifier 610. The various values can include n, b, Cw, CrA, a, and decommitments.

[0309] In step 1238, verifier 1210 can obtain the random vectors r and s in a same manner as the prover 1205 obtained.

[0310] In step 1239, the Verifier can verify the commitment to r’ using the sampled columns and decommitments to perform spot checks. The spot checks with random columns of CrA can be used for this purpose. The Verifier checks that the revealed columns are authenticated by their respective decommitments and can verify the results of local aggregate computations (such as pointwise products and sums) on these columns match the provided aggregates. This step ensures local consistency and deters the Prover from forging valid-looking but incorrect data.

[0311] Accordingly, the verifier can perform spot checks to verify that commit (r’) (received from prover) is consistent with r’=rA using the commitment CrA, e.g.. using encoded values of an rA matrix and decommitments (nodes) of a Merkle tree.

[0312] In step 1240, the verifier can check that commit(r’) is consistent with r’s = a. This is a check of the first proof. One check can be to perform parts of the inner product for certain revealed columns of r’ and the random vector s to ensure that the result is consistent with the fingerprint a. The first proof proves that fingerprint a revealed by prover is the inner product of the vector (rA) commited in step 1140 and the powers of the random vector s. The inner product can be checked using decommitments. Note that the first proof and second proof can be performed in parallel, as long as the random vectors r and s from the first proof are obtained for use with the second proof..

[0313] In step 1242, the verifier can perform the secondary proof that rAs=a. In the first proof, the verifier knows r, but it is not verifying the prover pre-multiplied by r. Instead the verifier checked whether r’s=a, where there is a commitment to r’. In this second proof, there is only a commitment to A and the verifier checks that pre-multiplying by r and post-6479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 multiplying by s provides a. In this manner, the verifier can rely on r’ without having to compute rA, and instead have the prover do this additional computational effort.

[0314] Accordingly, the Verifier can use the provided fingerprint a and the secondary proof to check global consistency. The secondary proof, provided by the Prover, demonstrates that the fingerprint a is indeed equal to r‘A ■ s with respect to the committed constraint matrix A. This can be achieved using a succinct SNARK, polynomial commitment proof, or similar cryptographic mechanism, allowing the Verifier to perform the check, without reconstructing or processing the full r‘A vector.

[0315] If all spot checks on the sampled columns in step 1239 pass and the secondary proof confirms that a is consistent with the committed A in steps 1240 and 1242, the Verifier can proceed to verily the witness using spot checks. These checks can confirm r’=rA, so rA can be used to verily r’w=rb. e.g., with (a) spot checks of decommitments to confirm consistent with r’w=rb and (b) confirm random cols, of encoded matrix enc_w are consistent with Cw.

[0316] In step 1244, the verifier can perform spot checks of r’w=rb to verify the witness w, since commit (f) has been verified via the first and second proofs, which involve verifying the fingerprint a. The value of c=r'w is something the verifier can learn from the prover and the verifier can confirm that rb also provides c. Additionally, spot checks can be performed of certain intermediate values. If the spot checks hold, then r'w = rb with very high probability. If the spot checks are verified, the verifier can accept the prover has properly executed the application, concluding that the Prover’s witness satisfies the linear constraints. If any check fails, the Verifier rejects the proof, ensuring both soundness and security.

[0317] The protocol may incorporate additional internal consistency checks, such as verifying that the column indices used in spot checks are consistent across all commitments and that the random vectors used in the fingerprint computation are properly derived from the protocol transcript. The protocol may optionally store or publish the commitments, aggregates, decommitments, and fingerprint for future reference or auditability, particularly in applications such as on-chain verification or public attestations. The Verifier may optionally produce a succinct proof of verification (such as a SNARK attestation) that can be reused or relayed to other parties, thereby supporting recursive proofs or aggregation in larger systems. If the protocol is being run in a batch or parallelized setting (such as verifying6579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 multiple witnesses at once), the steps above may be repeated or extended in a pipelined fashion, utilizing shared randomness and commitments to maximize efficiency.

[0318] Accordingly, since the columns of the encoding of rTx A are included in the proof, the verifier can recompute Agglinon the t locations without having to compute rTX A. The verifier can also recompute Aggrrx for spot checks of the commitment of r'. An observation here is that the affine constraint in the fingerprint stage is highly structured and can be computed by the Verifier in sublinear time, thus making the overall time of the Verifier sublinear. Finally, the Verifier can verify the second proof w.r.t CA the commitment from the pre-processing step.

[0319] Advantages are as follows. For Succinct Verification, the Verifier needs to perform all operations as in the original system except for building the Rene matrix which is sublinear in the computation size. The Verifier additionally needs to verily a linear test over Rene but that is a structured computation which is sublinear in the computation size. With this modification, embodiments can be used as a zkSNARK / SNARK for unstructured computation and allows for efficient verification on a blockchain by composing with highly succinct SNARKs such as Groth16 (dblp.org / rec / conf / eurocrypt / Groth16.html) and Halo2 (github.com / zcash / halo2).

[0320] For Memory Efficiency, the Verifier will remain memory efficient as long as the polynomial commitment used for encoding the constraint matrix A is memory -efficient. The Prover also continues to be memory efficient. There is some additional work on the Prover, e.g., committing to Rene using Merkle trees but this will not add significant time.IV. VERIFICATION WHEN DYNAMIC FLOW IS PRESENT

[0321] There can be two kinds of programs (applications): structured and unstructured. Structured is fixed. Unstructured makes no assumptions on executions m the program. There can be various function calls, recursion, etc. For example, suppose that the code has a if-then-else block, this can result in the Prover and Verifier diverging in the way they extract the constraints and hence the Verifier will not be able to verify the checks needed for the linear test.

[0322] In previous sections, we assumed that there are no branches so there was no overhead of a universal circuit because the verifier knew what instruction is being executed.6679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 The A matrix was fixed. There is only one set of constraints to verify. There are no choices to make. So the set of constraints is fixed no matter what the input is.

[0323] But for dynamic flow control, there are branches. Execution control can jump from one branch to another. The prover does not want to show the verifier the execution sequence. To address this branching, there is still an A matrix except that the A matrix is composed of blocks of code (discussed more below). The verifier can verify that the prover knows the sequence.

[0324] Accordingly, instead of representing the entire program as a single, static circuit, which becomes unwieldy for complex or branching logic, embodiments can logically divides the program into a series of program blocks. Each program block is a segment of code that executes linearly, without internal branches, and is associated with a specific constraint submatrix ( Ai) that captures the rules and relationships (constraints) governing the variables and computations within that block. As the program executes, the specific sequence of blocks traversed is determined by the (possibly secret) inputs, meaning the overall constraint matrix A for a given execution is formed by concatenating the constraint submatrices of the blocks actually executed, in the order they were visited.

[0325] To enable scalable and privacy-preserving verification, the system computes an individual (block) fingerprint for each constraint submatrix corresponding to a program block, e.g., determined as rAis. These fingerprints are cryptographic commitments — such as inner products of random vectors with the submatrices — that attest to the satisfaction of the constraints within each block, without revealing either the values being checked or the execution sequence itself e.g., as described in section III. The prover, who knows the actual execution path, also computes a total fingerprint, e.g., (1) by combining the individual fingerprints of the executed blocks in a mathematically defined manner or (2) by applying a total matrix A that includes the constraint submatrices in the selected order (sequence), which may be done by determining rAs. This total fingerprint serves as a succinct, cryptographic summary of the entire computation, reflecting the correctness of the dynamic execution while keeping both the secret inputs and the branching path hidden from the verifier.

[0326] This approach allows the verifier to check, using the published fingerprints provided by the verifier and supporting zero-knowledge proofs, that the prover has executed a legitimate sequence of program blocks and satisfied all relevant constraints — without learning anything about which path was taken or the underlying secret data. The modular 6779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 structure, based on program blocks and their associated constraint submatrices, avoids the inefficiency of universal circuits and enables succinct, scalable verification for complex software, including applications with highly dynamic or input-dependent control flow. This framework ensures that the integrity of software execution can be attested to with both efficiency and strong privacy guarantees, making it highly suitable for applications such as smart contracts, privacy-preserving computation, and secure audits.A. Problems with certain techniques

[0327] There is a challenge that arises in zero-knowledge proof systems when the execution path of a software program depends on secret or private input data. In many real-world programs, the sequence of instructions executed is not fixed in advance but can vary dynamically based on conditional branches, loops, or function calls that are triggered by the program's inputs. This dynamic control flow introduces a problem: if a verifier were to observe which branches or blocks of the program were executed, it could potentially infer sensitive information about the inputs themselves, thereby violating the privacy guarantees expected from a zero-knowledge system.

[0328] To address this challenge, several techniques have been developed. The entire program can be put in memory A program counter can map to a memory cell and retrieve the instruction from this memory cell, execute it, and then move to the next program counter. But this is problematic since the size of the circuit being called in one invocation can divulge what is being performed. To get around this, a universal circuit can be used so that each invocation looks the same, but such a. circuit is very large The Prover would have to execute every possible instruction at each operation to hide the sequence. There is an overhead in mapping different instructions into one circuit. This is called a “universal circuit" because it's capable of doing multiple operations. In such techniques, the program is flattened so that every possible instruction that could be executed at each step is represented in the circuit, and the actual instruction executed is selected based on input-dependent control signals. This ensures that the control flow is “oblivious"’ — the verifier cannot tell which path was taken — but it comes at a steep computational and efficiency cost. The universal circuit must be large enough to accommodate every possible instruction and every possible branch, which causes significant overhead, especially as the complexity and branching factor of the program increases. The result is that even the simplest operation, such as an XOR or addition, must be6879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 handled by the same large subcircuit as the most complex operation, such as division or a function call, drastically reducing the efficiency of proof generation and verification.

[0329] Alternative strategies attempt to remove dynamic branching altogether by rewriting the program logic to be branch-free, effectively transforming all conditional branches into data-dependent operations that do not affect the observable control flow. While this can sometimes be practical for small or simple programs, it quickly becomes infeasible as the complexity of the software grows, as manually rewriting the program for every possible use case is labor-intensive and error-prone.

[0330] Some programs can use a lookup table. Many proof systems like the Jolt SNARK proof system (dblp.org / rec / conf / eurocrypt / ArunST24. html?view=bibtex) assume the program instructions are in a lookup table and for each cycle the program counter is used to index the next instruction and updated to the next value at the end of the instruction. However, this approach will require for the Prover to prepare a circuit that for any cycle is capable of evaluating any of the possible instructions. For example, in a RISC-V architecture, there are roughly 30 possible instructions and the circuit in each step should be able to select from one of the 30 possible instructions and execute that instructions. Such a circuit is sometimes referred to as a “universal circuit’’ and this incurs an overhead. For example, the simplest instruction, say “XOR” needs to be evaluated by a circuit of the same size as a complex instruction “DIV’. Moreover, this approach does not scale for larger instruction set VMs such as WASM (WebAssembly) that has over 100 instructions because the overhead of the universal circuit becomes bigger.

[0331] Despite these advancements, existing techniques still face significant limitations. Universal circuits and lookup-based approaches both require substantial extra computation and memory, which reduces their scalability' and practicality' for large or highly branching programs. Additionally, these methods often fail to fully decouple the verification workload from the total size of the program, meaning that verification remains inefficient as program complexity grows. As a result, there remains a need for more scalable, efficient, and privacypreserving approaches to verifying programs with dynamic, input-dependent control flow in zero-knowledge settings.6979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 B. Use of blocks

[0332] As described above, embodiments can leverage a modular, block-based approach to both program structure and constraint verification. A software program can be logically partitioned into program blocks, each block associated with its own constraint submatrix. The generation and aggregation of cryptographic fingerprints can succinctly attest to the correctness of execution without revealing the secret-dependent execution path. A final verification of execution integrity can be achieved via spot checks and fingerprint aggregation.

[0333] FIG. 13. is a block diagram illustrating the modular verification of a dynamically executed program in a zero-knowledge proof system. A program 1310 includes program blocks B1-B4, which represent discrete segments of the software, each executing without internal branching. Each of these program blocks is associated with a corresponding constraint submatrix Ai, denoted collectively as constraint submatrices 1325 of constraint matrix 1320. These submatrices 1325 encode the specific relationships and computational rules that must be satisfied during the execution of their respective blocks. The commitments 1330 to these constraint submatrices, which may be generated during a preprocessing phase, are labeled as Commit (Ai), etc. and are provided to both the prover and the verifier.

[0334] The verifier knows the different program blocks B1-B4 of program 1310. The verifier will also know constraint submatrices 1325 of constraint matrix 1320. But the verifier will not know the order of execution of program blocks B1-B4.

[0335] As shown using conditional branches S1-S5, block Bl is executed first, which is followed by execution of block B2 via branch S 1 or block B3 via branch S2. If block B2 is executed, block B2 can be executed multiple times via branch S3, following by execution of branch B4 via branch S5. If block B3 is executed, branch B4 can then be executed via branch S5.

[0336] Accordingly, the program control flow goes dynamically between blocks. In other words, the code can be broken into blocks where a subset set of constraints can be derived for a block because there is no branching in between for a given block. But at the end of the block, the program can branch out to one or the other, depending on what the secret input values are. For each of these blocks, a computer can derive constraints.7079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0337] As shown, for block Bi, the constraint is As, for Bj s Az, and so on. Commitments can be made to these blocks separately but can also be done together. When committing to them separately, the block sequence can be such that the corresponding sequence for constraints is from Aii to Ai2, to Ai?, to Air. For each block, the first proof from section 111 can be performed. Note that the reference to first proof or second proof is arbitrary and either can be done first or both performed in parallel.

[0338] To generate the witness and the total fingerprint, the pro ver can perform the rearranging (based on the execution sequence) of the submatrices for the correct determination of the total fingerprint. For the prover, if the program jumps from Bi to B2, goes back to B2 a bunch of times (e.g., a for ■■loop), and then goes to B-i, the Prover would perform the execution fully. In this manner, the prover assembles the constraint matrix A 1320 to correspond to the order of the blocks executed. The Prover’s actions depend on which branches are taken based on the input values, which specify the execution sequence. Thus, the prover does not have to explore every possible branch. For the Verifier, a complexity can come from the preprocessing step, which is done just once.

[0339] Additionally, it can be proven that only legitimate branching is performed, e g. using techniques from section III or other techniques that are not as efficient. For example, the prover can commit to r * big A by walking through the execution and concatenating r x Ai. The commitment for r x big A can be formed as a concatenation of the respective r x Ai. The prover can then prove what r x A x s is. Further details when an embodiment uses techniques from section III are not provided.1. Proof for total fingerprint

[0340] The total fingerprint proof can be problematic because the verifier does not have the full set of constraints (as that would include the sequence) but instead just has the constraints for each of the program blocks. This proof can check the consistency of the total fingerprint with the commitment to A, and the verifier can confirm the total fingerprint is consistent with the aggregated fingerprint determined from the individual fingerprints from the other proof.

[0341] For this proof, the system treats the entire constraint matrix A — assembled according to the actual execution sequence — as a single object for fingerprinting. Rather than working with the individual constraint submatrices Ai corresponding to each program block, the prover constructs the full constraint matrix A by concatenating the submatrices in the7179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 order dictated by the secret-dependent execution path. This unified matrix A then ser es as the basis for all subsequent cryptographic operations, allowing the protocol to succinctly attest to the validity' of the computation as a whole.

[0342] To generate the total fingerprint, the protocol begins by selecting random vectors r and s, which are either provided interactively by the verifier or derived non-interactively from the protocol transcript using the Fiat-Shamir heuristic. The prover computes the fingerprint a by first multiplying the random vector r (as a row vector) with the full constraint matrix A. resulting in an aggregated constraint vector rTA. This vector is then multiplied (as an inner product) with the random vector s (as a column vector), yielding the scalar fingerprint a = r‘A s. The proof checks whether r times committed A times s equals alpha, which can be done using spot checks. This fingerprint a acts as a succinct, cryptographic summaiy of the entire constraint system as instantiated for the actual execution; it binds together both the randomness and the concrete structure of A as determined by the traversed program blocks.

[0343] During verification, the prover supplies the fingerprint a along with a proof it that attests to the correct computation of a from the committed A, r, and s. The verifier, having access to the commitment to A (generated in a preprocessing phase) and the public randomness, can efficiently check the validity of the fingerprint by verifying that it matches the committed constraint matrix and the provided random vectors. This check can be accomplished using a succinct SNARK or polynomial commitment protocol, ensuring that the verifier's workload remains sublinear in the size of the program — even as the proof encompasses the correctness of an arbitrarily long and dynamically chosen execution path.

[0344] The soundness of this approach rests on the properties of the randomization and aggregation steps. Because the random vectors r and s are unknown to the prover until after commitments are made, any attempt to cheat by constructing an invalid or inconsistent constraint matrix A is overwhelmingly likely to be detected: a false proof would rarely yield the correct fingerprint a when challenged with genuinely random r and s. Thus, the protocol compresses the verification of potentially thousands or millions of individual linear constraints into the verification of a single scalar value, without sacrificing security7.2. Proof for aggregated fingerprint

[0345] In the supplemental proof, the prover can prove that there exists a sequence of numbers, of blocks, bi, b2, bn, such that the individual fingerprints r transpose AiS, r7279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 transpose A to S, and this sequence will provide an aggregated fingerprint (later checked whether it matches the total fingerprint) when the constraint matrix A corresponds to the proper execution sequence of all of the program blocks. The sequence and each individual fingerprint can be pushed into this proof, which can hide the sequence. This is accomplished through the use of a zero-knowledge proof of knowledge in which the prover demonstrates, in zero-knowledge, that the total fingerprint it presents is a valid combination of the individual fingerprints of the committed constraint submatrices (blocks), corresponding to some valid execution sequence permitted by the program's logic. This can be done efficiently, e.g.. using Tight ZK, a SNARK, or dblp.org / rec / conf / ccs / 0001HHKV24.html?view=bibtex. The proof system is constructed so that the verifier can check the validity of this claim without learning which specific blocks were involved or in what order. The only requirement is that the formula for aggregation is public, and the commitments to all possible blocks and their fingerprints are available.

[0346] As an example, the prover can compute for each At, r transpose Ai xs for each block. The same fingerprint concept can be used, thereby resulting in individual fingerprints for the blocks. If the verifier computes r transpose AS where A comprises these submatrices of the blocks, the verifier can recompute this r transpose AS by the fingerprints of the individual blocks because the verifier already viewed the constraint matrix 4 as submatrices.

[0347] Looking at matrix multiplication of r transpose AS, the verifier can use the individual fingerprints and recompute a total fingerprint to be compared to the result of the total fingerprint proof. But to use the individual fingerprints to generate the total fingerprint, the execution sequence is to be verified. For example, each block could appear many times as there is dynamic flow control. A for loop would appear as many times as there is for loop. The verifier may only compute fingerprint once. To verify the sequence, the individual fingerprints would be aggregated to get one version of the total fingerprint, which is compared to the total fingerprint obtained in the total fingerprint proof. This can all be done without the verifier knowing the sequence.

[0348] The individual fingerprint for each executed program block can be generated during a preprocessing step. Using random vectors r and s (which may be determined via the Fiat-Shamir heuristic or similar randomness generation procedures), the prover can compute individual fingerprints for each block, such as r‘AiS (e.g., rAis, rA2S, rAss, rA4S, etc.), which serve as cryptographic attestations that the corresponding constraints have been satisfied. The7379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 total fingerprint can then calculated by combining these individual fingerprints in a manner that reflects the actual (but hidden) execution sequence. This combination can be performed according to a defined aggregation procedure, ensuring that the total fingerprint is consistent with the concatenation of the executed constraint submatrices.

[0349] More specifically, during the preprocessing phase, the verifier and prover agree on the set of all possible program blocks and generate commitments to each block's constraint submatrix. For each block, the prover computes and commits to its individual fingerprint (e.g., ai = r’Ai s for block i). The prover, who knows the actual execution sequence, aggregates these fingerprints according to a formula — e.g., a sum, possibly with scaling factors such as powers of r and s determined by the execution ordering and the positions of the blocks. For example, if the execution sequence is (Bl, B2. B3), the total fingerprint might be a = al + rAa sAb a2 + rAc sAd a3, where the exponents or coefficients encode the positions of the blocks or the branching structure.

[0350] Accordingly, the individual fingerprints for each block can be determined using the individual proof (e.g., r’s=individual alpha) from section III. And these individual fingerprints can be combined (e.g.. according to a formula that is dependent on the sequence) to obtain the total fingerprint, which is generated using the total proof (e.g., using rAs=total a).

[0351] Thus, even though the verifier does not know the execution sequence, it is assured that the total fingerprint corresponds to a legitimate combination of pre-committed block fingerprints, consistent with some valid execution path, without learning anything about which path was actually taken or w hat the secret inputs were. This preserves zero-knowledge w hile enabling scalable and sound verification of dynamic program executions. This proof is much smaller as it is not verifying constraints, but instead just getting the block-level fingerprints and recomputing a. The complexity of this proof is much smaller than the total fingerprint proof.3. Verification of witnesses

[0352] The verifier can verify7the witness w for each program block using the corresponding constraints for that block. The total fingerprint from the previous proof can be used to check the witness for the entire program.7479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0353] During execution, the prover can generate the witness w, which comprises all relevant values — inputs, intermediate variables, and outputs — produced as the program traverses its sequence of blocks. This witness reflects the actual path taken through the program, determined by the secret or public inputs, and thus implicitly encodes the execution sequence without revealing it.

[0354] The prover can next generate the commitment Cw for the witness w, using a cryptographic commitment scheme such as a Merkle tree. This succinct commitment binds the prover to the specific execution trace without exposing the underlying data.Simultaneously, the prover applies each constraint submatrix Ai to the relevant portion of the witness, generating a public vector b that captures the outcomes of all linear constraints imposed by the executed blocks.

[0355] For verification, the prover provides the commitments, public vector b, individual fingerprints, total fingerprint, and a set of decommitments to the verifier. The verifier performs spot checks by requesting the opening of randomly selected columns from the committed witness, leveraging the decommitments to authenticate the revealed data. The verifier then checks that the individual fingerprints correspond to the correct application of the random vectors to the committed constraint submatrices, and confirms that the total fingerprint matches the expected aggregation of the individual fingerprints, given the permissible program structure.

[0356] Through this process, the system enables the verifier to confirm — without learning the execution path or any secret information — that the prover has faithfully executed a legitimate sequence of program blocks and satisfied all associated constraints. The modular, block -based architecture and the fingerprint aggregation mechanism together provide an efficient, scalable, and privacy-preserving solution for verifying complex software with dynamic, input-dependent control flow.C. Example

[0357] An example is provided. Consider code that has three basic blocks and their corresponding linear constraint matrices are A A2, A3. The program execution has two possible paths: Either Block 1 follo ed by Block 2 or Block 1 followed by Block 3. The path is chosen depending on a secret input bit. The verifier will have to verify the constraints not7579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 knowing which path was taken. Here is how the constraint matrix would be for each of the two paths:

[0358] The prover is supposed to commit to the correct constraint matrix, namely A' or A". In one proof for the total fingerprint, assume the prover commits to a matrix A. The prover reveals a — R x A x S. If A =, the total fingerprint can be computed as:Rx A x S = R x Arx S + x d2x S where i,j are the dimensions of Ar.

[0359] Relevant to the other proof (for individual fingerprints), the prover would have committed to AltA2, A3in the preprocessing step, e.g., by providing individual fingerprints. In this proof, the prover can reveal a = R x A x S, a2= R x A2x S and a3= R x A3X S and prove they are correct w.r.t the matrices J413J42, and3that were committed in the preprocessing phase.

[0360] Then to combine the proofs as a verification check to confirm the two results match, the prover can prove that it knows a 2-sequence Yi> y2that come from {1,2,3} such that the total fingerprint a revealed in that proof equals aYi+ rlsJay2for the individual fingerprint proof. Note that in this proof y1;y2are secrets. A match will convince the verifier that the prover when it generated the constraints in the first proof, it was a combination of the blocks that was preprocessed.

[0361] Embodiments can ensure that no other combination of two blocks were used, which can be incorporated into the constraints themselves, namely, beginning block must be block 1 and from block 1 we can only jump 2 or 3. For the individual fingerprint proof, the prover can prove the sequencey2satisfies a regular expression capturing the possible program sequence.

[0362] Proving knowledge of the sequence of execution (e g., sequence yt, y2) can be performed as follows. A sequence of block numbers yl, y2,..., yt. a can be computed as follows.

[0363] Suppose arrays i [], j [], alpha[] contain the row, column and alpha values of corresponding blocksalpha = 07679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 for k = t to 1lookup i,j for the gamma_kAth blockalpha = rA(i[k]) * sA(j [k]) * alpha + alpha[k]endfor

[0364] The verifier needs to make sure that no other combination of two blocks were used, but this can be incorporated into the constraints themselves, e.g., beginning block is block 1, and from block 1 the program can only jump 2 or 3. Alternatively, this can be incorporated into the second proof it can be proven the sequence yl, y2 satisfies a regular expression capturing the possible program sequence.D. Sequence diagram

[0365] Using techniques described above, embodiments can efficiently and privately verify the execution of a dynamically branching software program using zero-knowledge proofs. The approach is grounded in the modular decomposition of the program into basic program blocks, each associated with its own constraint submatrix. By leveraging cryptographic commitments, individual and aggregated fingerprints, and randomized spot checks, the system enables the verifier to confirm the correctness of the program's execution — including both the computations and the branching logic — without learning the actual execution path or any secret data. This framework is particularly well-suited for programs whose control flow can depend on secret or private inputs, such as those found in privacy -preserving smart contracts, confidential auditing, or secure computation.

[0366] Rather than requiring the verifier to reconstruct or examine the entire execution trace, the system allows the prover to provide cryptographic evidence — anchored by commitments and fingerprints — demonstrating that the witness data (the collection of input, intermediate, and output values) is consistent with some valid sequence of program blocks and that all prescribed constraints have been satisfied. The verifier, in turn, checks the validity of these claims through a series of efficient operations, including spot checks of randomly selected data and succinct verification of fingerprint relationships, all while remaining agnostic to the actual control flow taken during execution.7779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0367] FIG. 14 is a sequence diagram 1400 illustrating the protocol for modular, blockbased verification of a dynamically executed program in a zero-knowledge proof system. The control flow of a program execution can execute basic blocks of code where within each basic block the control flow is oblivious and at the end of each block the control flow can jump dynamically to another block. Let Ai capture the linear constraints of block i. Similar operations can be performed in a similar manner as described for previous sequence diagrams (methods) described herein, as is the case for all sequence diagrams herein.

[0368] Sequence diagram 1400 can include various stages. In the Agg Stage, Prover 1405 can provide a commitment r' = rTX A where depending on the control flow 4 will contain the corresponding matrix Ai as the submatrix. In the Fingerprint Stage, Prover 1405 can provide the value a and the aggregate for a linear test on the witness r ' for the constraint r' X s = a.

[0369] Embodiments can incorporate pre-processing from section III but in an updated manner because A is not a fixed matrix, but instead depends on the control flow. However, the set of blocks are fixed. The pre-processing can separately commit each At. A proof can show that there exists a sequence of block numbers bi....,br such that a can be recomputed from the values rTX AtX s and the sequence bi....,br. A formula of the individual fingerprints can equal the total fingerprint determined from rAs, where A is the total constraints.

[0370] At step 1412, the program blocks are provided. There is a logical division of the software program into a set of program blocks, each representing a segment of code that executes without internal branching.

[0371] At step 1414, for each block, the system (e.g., prover, verifier, or trusted third party ) derives a corresponding constraint submatrix Ai. During a preprocessing phase, both the prover 1405 and verifier 1410 obtain commitments CA to these submatrices. These commitments serve as immutable references for the structure and content of the constraints governing each block’s execution.

[0372] The commitments to the constraint submatrices (CA) are distributed to both prover 1405 and verifier 1410. These commitments ensure that both parties are working with the same reference set of constraints and provide the cryptographic anchor for all later verification steps. As examples, the commitments can be generated using a Merkle tree or7879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 similar mechanism, enabling efficient authentication of any subset of the constraint data as needed.

[0373] At step 1416, prover 1405 executes the software program using the actual input values, traversing a secret-dependent sequence of program blocks. As the program runs, it generates the witness w, which includes all input values, intermediate computations, and output values encountered along the execution path. This witness encapsulates not only the data values but also, implicitly, the order and identity of the executed blocks, though this information remains hidden from verifier 1410. The witness can be arranged so that it aligns with the structure of the executed constraint submatrices, facilitating subsequent constraint verification. Individual witness values wi for each problem block can be determined. Thus, a witness can be generated for each sequence block in the execution sequence.

[0374] At step 1418, prover 1405 produces the public vector b using the constraint matrix A and the witness w, e.g., via Aw=b. Prover 1405 can apply each executed constraint submatrix Aito the corresponding segment of the witness, producing a public vector b. This vector b encodes the outcomes of all linear constraints imposed by the program blocks in the actual execution sequence, serving as a reference for verifying that the witness satisfies the prescribed computational relationships. Individual public vector bi for each problem block can be determined. Thus, a public vector can be generated for each sequence block in the execution sequence.

[0375] At step 1420, prover 1405 generates a cryptographic commitment Cw to the witness w, binding itself to the specific set of values produced during execution. This commitment can be realized as a Merkle root over an encoded version of the witness matrix.

[0376] At step 1422, individual fingerprints can be generated using random vector r and submatrices of A. For example, a random vector n can be generated for each block, e.g., using the commitment for the submatrix for that block. In some implementations, a random vector s can also be determined, which could be generated using ri’Ai as can be done for FIG.12. The individual fingerprints can be generated using r’ or using r and submatrix Ai.

[0377] Accordingly, in some embodiments, using random vectors r and s, prover 1405 can calculate a fingerprint for each constraint submatrix Ai, e.g., as a; = r‘AiS. These individual fingerprints cryptographically attest that the constraints for each block have been satisfied, without revealing the underlying data or the order in which the blocks were executed.7979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0378] In step 1424, a total fingerprint is generated. The total fingerprint could be generated in various ways by the prover. A total constraint matrix A can be determined based on the sequence and rAs =total fingerprint alpha can be determined. Or the execution sequence of the program blocks can be determined and used to combine the individual fingerprints, e.g., such the a particular fingerprint for a first program block can be summed multiple times depending on how many times the program block is invoked.

[0379] Accordingly, in some embodiments, prover 1405 can aggregate the individual fingerprints according to a predefined aggregation procedure, generating the total fingerprint. This aggregation is performed in a manner that reflects the actual (but secret) sequence of executed blocks, such that the total fingerprint represents a succinct cryptographic summary of the entire execution.

[0380] In step 1426, prover 1405 can sample t columns of the Cw using any one or more the random numbers and obtain the decommitments. Accordingly, prover 1405 can prepare a set of decommitments for randomly selected columns of the committed witness, enabling the verifier to perform spot checks for data authenticity.

[0381] In step 1428, various values are sent in a proof to verifier 1410. For example, the proof can include public vector b (which may include individual public vectors), the witness commitment Cw, individual fingerprints ai, total fingerprint a, and the decommitments for the selected witness columns. This collection of data provides the verifier with all the necessary cryptographic evidence to validate the integrity' of the execution without exposing any private information.

[0382] In step 1430, the random vector r is obtained. If random vector s is also used, then it can also be obtained. A same procedure as used by prover 1405 is used for the non-interactive implementation. In an interactive implementation, verifier 1410 can provide the random vectors to prover 1405.

[0383] In step 1432, the individual fingerprints are verified for each program block and corresponding constraint submatrix, e.g.. as in step 1240 of FIG. 12. Verifier 1410 can check that each individual fingerprint corresponds to a valid application of the random vector r and s to the committed constraint submatrices. This step confirms that the constraints for each executed block are satisfied.8079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0384] In some implementations, a commitment of each r’=rAi can be verified. Verifier 1410 can perform spot checks by requesting the opening of randomly selected columns from the committed CrA. Using the decommitments, the verifier can authenticate the revealed data, ensuring that it matches the original commitment CrA and has not been altered. These spot checks provide a statistical guarantee that the entirety of the r' vector is consistent with the claimed computation.

[0385] In step 1434, the total fingerprint is verified. Various verifications steps can be performed. If r’ is used (e g., preprocessing from section III is used), then application of r’ to s can be confirmed to provide the total alpha a received in step 1428. Additionally, total alpha a can be compared to an aggregated fingerprint as determined using the individual fingerprints and a second (supplemental) proof.

[0386] Accordingly, verifier 1410 can compute the expected total fingerprint from the individual fingerprints (e g., as described in section IV. B.2), using the publicly defined aggregation procedure. The verifier then checks that the prover’s supplied total fingerprint )e.g., verified using the proof described in section IV. B.l) matches this computed value, thus confirming that the overall execution is consistent with some valid, though hidden, sequence of program blocks and that all constraints have been satisfied.

[0387] In step 1436, the verifier can perform spot checks of rAw=rb to verify the witness w since the fingerprints have been verified via the first and second proofs, which involve verifying the fingerprint a. As part of the process, spots checks can be performed to very Cw and C first. The spot check can be performed in various ways. For example, the spot check can be performed in the same manner as step 1244 of FIG. 12. Accordingly, verifier 1410 can conduct these spot checks, examining additional randomly selected elements to further confirm the authenticity and correctness of the computation. Upon successful completion of all checks, the verifier accepts the proof, confident in the correctness of the execution while remaining oblivious to the actual execution path and secret data.V. VERIFYING MEMORY ACCESSES (USE OF LOOKUP TABLE)

[0388] Various embodiments can also be used to verify memory accesses were correctly performed in addition to the execution of the program code. Such memory accesses can occur within a program block or relate to different program blocks.8179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0389] A challenge encountered in zero-knowledge proof (ZKP) systems is how to verify that a program’s memory accesses are performed correctly, without leaking information about which memory locations were accessed. In many privacy-sensitive applications, the indices or addresses used to access memory depend on secret input data; if the verifier could observe these access patterns, it could potentially infer the secrets that the proof system is intended to protect. This problem becomes especially pronounced in practical software, where random access is commonplace, and where the precise elements accessed may reveal confidential information, such as cryptographic keys, personal identifiers, or business logic.

[0390] Traditional approaches to hiding memory access patterns in ZKP systems often rely on making the access pattern “oblivious.” One naive solution is to design the circuit so that it simulates every possible memory’ access at each step, ensuring that the verifier cannot distinguish which specific element was actually used. However, this approach is highly inefficient: the circuit size and the computational workload scale linearly with the product of the number of accesses and the total size of the memory (i.e., O(T*D), where T is the number of accesses and D is the table size). Such inefficiency renders these methods impractical for large datasets or for applications with frequent random access.

[0391] Embodiments can overcome these limitations by incorporating “lookup arguments” into the zero-knowledge proof framework. Instead of simulating all possible accesses, the protocol allows the prover to succinctly demonstrate that the elements it claims to have accessed are indeed correct, while keeping the identity of those elements hidden. This is achieved by committing to both the program code and the memory access patterns, then using randomized checks and products to ensure that the revealed outcomes are consistent with respective constraints. As described above, a constraint matrix A can be used for checking execution of the program code and a constraint matrix A* can be used for checking the memory’ accesses. As described in a later section, some embodiments can check these constraints separately for some parts (e.g., for fingerprints) and combine them for other parts (e.g., for the aggregate checks, such as the code / proximity test, the multiplication test, and the linear test. For checking the memory accesses embodies in constraint matrix A*, the protocol can introduce additional witness components — such as counters and auxiliary lists (denoted R and W below) — which encode the access information and enable efficient batch verification of the lookup operations (memory accesses).8279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 A. Example problems with certain techniques and benefit of lookup table

[0392] As a Problem Statement, consider a ZK application that proves the total cost of an operation by looking up a table of cost for different items. Suppose the table has 1024 bytes representing the cost of 1024 items. Assume the cost of the i’th item is contained in row i of the table. Let the secret witness be a list of item numbers. The ZK proof system will read the witness, lookup the table for the corresponding item and total the sum of costs for each item. If we need to keep the actual items hidden and only reveal the total cost, the Prover cannot let the Verifier know which item in the table it is accessing. Depending on the secret input, the program fetches Ai or Aio, the important thing is that the verifier should not know the prover is accessing Aio because 10 was computed from the secret value.

[0393] For a naive solution, the Prover creates a big circuit that computes the OR of 1024 predicates, where the i’th predicate checks if the item number in the witness matches the row number, and if it matches return the cost. For each item in the witness, the cost would be 1024 times the size of the circuit for the predicate.

[0394] Lookup arguments allow for the proof system to efficiently incorporate memory lookups on secret indices. With lookup arguments, embodiments can reduce the circuit size to exactly the number of times the table is accessed plus a one time cost of accessing the 1024 elements. The description below shows how we can incorporate this into the proof systems described herein. Further details about lookup arguments can be found in M. Blum et al., " Checking the correctness of memories," [1991 J Proceedings 32nd Annual Symposium of Foundations of Computer Science, San Juan, PR, USA, 1991, pp. 90-99, doi:10.1109 / SFCS.1991.185352.

[0395] As an example, assume a cost database includes the cost per item. The secret witness is a subset of these elements, and the verifier wants to confirm a criteria of the total cost. The prover wants to prove that the set of elements (e.g., for some project) is a subset of the publicly available table that the prover is showing the total cost will be. But the prover does not want to show which items are selected. The prover will only give the sum total of the cost and assert that the total was determined from items in the table. A goal is to prove that they accessed the correct elements to provide a final value.8379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 B. Use of two lists and a second witness

[0396] As described above, the execution of the program can be broken down to a circuit, wi th all the intermediate wire values put in this witness called W. In addition to wires for execution of the program, the circuit can include wires (e.g., sequence values) for the memory’ accesses. When lookup arguments are used, there will be two sets of wire values. For program execution as described previously, values form executing the program are put into the witness. But whenever the program makes an access into memory, the memory' address being queried will be added to the witness. A counter for how many times that memory’ address is accessed can also be added to the witness.

[0397] Whenever a program block accesses memory’, the prover can add the address to the witness, the memory value, and a counter on how many times the address was accessed in that particular cell. Two lists can be generated using the same values but generated in a different manner, however a total product of the values in both lists will be the same. If the prover did its actions correctly, the product of the numbers in each of these lists will be equal. If prover did not perform the actions correctly, then the product of these numbers will not be equal

[0398] In a first memory’ access stage (first stage), a prover can commit to the address, the value, and a counter for each access. In the second memory access stage (second stage), the prover takes these things that were committed in the first stage and produces two lists R and W. There are two lists that are going to produce, and each number in these lists are computed as a function of what was computed before. In other words, there is a checking mechanism that when the prover added values (e.g., sequence values) to each list, the verifier will check that they were computed correctly from whatever the prover committed to in the first stage. If the prover cheated in incorporating values into a list, the prover will be caught because there will be a constraint that will check that the number added in list R or list W is based on things committed in the first stage, and the verifier’s check will catch it. The values in the lists relate to the execution of the program, e.g., whenever a memory access is performed.

[0399] During the first stage, for each lookup into the table during the first stage, the Prover can includes in the witness (addr. val, j) where val is the value in the table in row addr and the application is accessing this row the / th time. At the end of the execution, the Prover8479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 will include (addr, val, ent) for every row in the table where ent denotes one more than the total number of times that row was accessed.

[0400] The second memory access stage can be introduced between the Commit Stage and the Aggregate Stage (e.g., as described in FIGS. 6, 12, and 14), where the Prover will include the commitment of a second witness w In this second stage, the Prover can receive randomness (a, b. c) via the Fiat-Shamir heuristic. In this second witness w’, the Prover can include all values in two lists R and W. For a lookup addr, val, j) during the execution. W will include the value (a * addr + b * val + c * j) and R will include the value (a * addr + b * val + c * (J + 1)). For the final set of entries (addr, val, ent), W will include (a * addr + b * val + c * f) and R will include (a * addr + b * val + c * 1).

[0401] The constraints on the second witness can be: (1) Every entry in W and R corresponding to an entry' in the first witness was computed correctly using a, b, c; and (2) a product of all values in R is equal to the product of all values in W.

[0402] The Agg Stage and Query Stage can proceed exactly as before, with the exception that the prover will use the witness as -or concatenated with rzr' and the aggregates for the test will be computed for both the commitments together. For the Query’ Stage, when t columns can be sampled, they will be revealed separately for w and -or’. An example is provided below;C. Example

[0403] Here is an example with 5 elements in the table, which corresponds to the memory being accessed by the program:addr Val1 52 113 124 205 33

[0404] Suppose the memory accesses for the witness were 3, 4, 2, 3,.... That is, address 3 was accessed first such that the program obtained the value 12, then address 4 was accessed such that the program obtained the value 20, then address 2 was accessed such that the8579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 program obtained the value 11. and then address 3 was accessed again such that the program obtained the value 12 again.1. First Witness (first stage)

[0405] The following is an example for generating a first witness during the first memory access stage, where the full list of memory addresses accessed is 3, 4, 2, 3, 1,2, 3, 4, 5. As described above, the Prover will include (addr. val, ent) for every row in the table where ent denotes one more than the total number of times that row was accessed. Thus, the Prover can include in the witness(3,12, 1), (4, 20,1), (2,11, 1), (3,12, 2), (1, 5,1), (2,11, 2), (3,12, 3), (4, 20, 2), (5,33, 1)

[0406] There is no check at this moment whether the prover gave the value 12 in the first request correctly. The prover just fetches the value. There will be a different mechanism to check whether the prover cheated or not. This counter indicates if address 3 was accessed the first time, add one. When address 3 is accessed a second time, the counter is increased to two. The prover then commits to these values. The commitment can be generated by encoding these values and then performing hashes, e.g., using a Merkle tree.2. Second witness - Computations with random numbers

[0407] In the second stage, the prover takes the values committed in the first stage and produce two lists: called R and W. These lists can be used in the second part of the witness or considered a second witness for the memory accesses. Each number in these lists is computed as a function of what was computed before. There will be a checking mechanism when values are added to these lists; the verifier can check that the values were computed correctly using the commitment in the first stage. If the prover cheated in incorporating these lists, the prover will be caught because there will be a constraint that will check that the number added in list R or list W is based on values committed in the first stage.

[0408] The verifier will get a commitment for the two lists. The verifier will perform spot checks to confirm they are correct.8679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 a) Example R and values

[0409] Now, after Prover provides the encoded witness from the first stage, the Verifier gives random numbers a = 2, b = 1, c = 8. Or the randomness can be through Fiat-Shamir. For example, three random numbers, a, b, and c can be obtained. Each of these 3-tuples, which is address, value, and counter, can be reduced to a number. This number can be determined by computing (3 * a + 12 * b + 1 * c), (4 * a + 20 * b + 1 * c), and s on.

[0410] Thus, if the program has the first access tuple (3, 12, 1), then the first entry to W is (3 * 2 + 12 * 1 + 1 * 8). But in R, the proof increases the counter by one. Whenever an element is added to W, an element is added to R but the counter is increased by one. At the end, the two lists cancel out if anything was done wrong. At the end, the two lists will have the same number of elements, e g., if R is prepopulated or if all elements are added during the online phase.

[0411] The Prover can generate a second set of witness values that will include the following two lists R and W:R: (3 * 2 + 12 * 1 + 2 * 8), (4 * 2 + 20 * 1 + 2 * 8), (2 * 2 + 11 * 1 + 2 * 8), (3 * 2 +12 * 1 + 3 * 8),...

[0412] W: (3 * 2 + 12 * 1 + 1 * 8), (4 * 2 + 20 * 1 + 1 * 8), (2 * 2 + 11 * 1 + 1 * 8), (3 * 2 + 12 * 1 + 2 * 8), (1 * 2 + 5 * 1 + 1 * 8), (2 * 2 + 11 * 1 + 2 * 8), (3 * 2 + 12 * 1 + 3 * 8), (4 * 2 + 20 * 1 + 2 * 8)(5 * 2 + 33 * 1 + 1 * 8)

[0413] The prover builds these lists R and W, as well as a pre-population list for R, discussed in next section. The second witness contains all the values in these lists and some extra computational values to prove that the products are equal.b) Pre-population

[0414] The two lists will cancel out when R is pre-populated properly. The pre-population list contributes a value p, where p times the product of values in R will equal to the product of values in W as all the items in the list R and for p cancel out with the list W. Both the Prover and Verifier can compute p, which depends on the original table and is the product of the following values:(1 * 2 + 5 * 1 + 1 * 8), (2 * 2 + 11 * 1 + 1 * 8), (3 * 2 + 12 * 1 + 1 * 8), (4 * 2 + 20 * 1+ 1 * 8)(5 * 2 + 33 * 1 + 1 * 8)8779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0415] Accordingly, R is prepopulated with some set of values. This pre-population is a one-time setup cost for the table. The list can be prepopulated under the assumption each address is accessed once. An optimization can be the prover does not have to include this prepopulation in the list R because the verifier can compute it once. The verifier can spend one time the length of the database and can compute the product of those numbers on its own. Because both computers (prover and verifier) know the pre-population list will always be included in the list R. the verifier can precompute this value and keep it. This is why W is longer than R. In the zero-knowledge system, it is desirable to reduce the number of values put in the witness and the commitment because that improves speed and thus the reason for this pre-population list. For each address, there is a computation that introduces values in R and W.

[0416] This shows how to incorporate lookups for tables that are read-only. This can be enhanced to read-write tables following the approach in (Y ang-Heath 24)[eprint.iacr.org / 2023 / ll 15],c) Products are equal

[0417] The second part of the witness contains everything that should be in R and W, and then there can also be some more values in the second witness that will help prove the product of R and product of W are the same. A small circuit can occur in the second step also, e.g., for multiplying all elements of R, multiplying all elements of W, and checking that they are equal. This is a computation that can be hidden from the verifier and so can be incorporated in the witness.

[0418] At the end of the computation, there can be a post-population to W. The whole table with the total number of accesses plus one is added. This can cancel the last set of accesses that were added to R. Thus, the system can prepopulate R with all the elements from the table and post-populates W with the total number of accesses plus one.

[0419] The commitment of R includes encoded intermediate values (e.g., an encoding of each value in the list), as well as encodings for certain operations (sum and products) of different values in the list. Same is done for W. Only encodings (combined into a commitment) are provided. The encodings of the commitments can have homomorphic properties. Adding the encoding of two vectors will be the encoding of the sum of the8879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 vectors. Multiplying the encoding (point-wise) results in an encoding of the product of the vectors.3. Verifier

[0420] In the second part of the witness for memory accesses, the verifier can check two things. The verifier can check the numbers added in R and 1+ were correctly computed based on the values that were committed in the first step. For example, when (3 * 2 + 12 * 1 + 2 * 8) is added, the verifier knows 2, 1, and 8 because those were the random numbers the verifier knows. And the verifier can check a constraint that whatever address, value, and counter the prover obtained that it was properly added to the list. This is a linear constraint.

[0421] Due to the use of the commitments, the verifier does not get the contents, but the verifier verifies the constraints on the contents, e.g., check two elements add to a value, two elements multiply to values, etc.. The verifier can check but cannot see the values.

[0422] For example, the constraints imposed on these values can be that for every number added in R, it is the correct linear combination of the values that are committed in the first witness. If a number 34, a constraint can be that this number 34 is equal to a times whatever the prover put in the first stage plus b times the second value plus c times the third value in the tuple. Thus, it is verified to be computed correctly with the randomness with the values that the prover used, which was a = 2,b = l,c = 8 in the example above.

[0423] As a point of clarification, R can be prepopulated with the list in V. C.2(c) above. If the first access made is to addr 3, the value would be 12. The third entry in the prepopulated list corresponds to address 3 and its value is 26. We add 26 to W. Then we compute a new value for addr 3 with ctr 2, which comes to 34 and this added to R. (The 34 will be cancelled out either if the prover accesses again, and if not, the prover adds it to W at the end.. If different numbers are used, then there will not be a match, or at least a low probability for a match.

[0424] As part of the proof, there can be two sets of constraints. One is that W and R were computed correctly from whatever was committed and the prepopulation and post-population was done correctly. And then the product of R and the product of W are equal. The verifier can check these things. And local constraints (e.g., intermediate multiplications between pairs of values) can show if the prover cheated somewhere; one of the constraints would fail. If one of the constraints fails, then the system will catch it, e.g., using the spot checks.8979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0425] As to checking intermediate values to confirm R and W are equal, the verifier can check if one number is the sum of two numbers or one number is the product of two numbers, or for more numbers. For example, assume boxes (unknown values) had the values (3, 2,12,1,2,8), and the prover wanted to convince the verifier that this is correct. The prover in addition to providing these values, the prover also provides three numbers determined as 3x2, 12x1, and 2x8. A sum of two of these values and a sum of these three values can be provided. The constraints can be be that the box that contains three times two has the quadratic constraint that it was the product of 3 and 2. Then 12 and 1 and then 2 and 8 for other boxes. Thus, there are boxes that represent 3x2, 12x1, 2x8. These boxes can be summed up.Accordingly, instead of verifying a large computation, the system can verify smaller computations of just addition and multiplication. The prover can provide more values to show the product of R and product of W are equal.

[0426] Accordingly, the verifier does not need the lists to verify the memory accesses. The verifier can check that the products of the numbers in R equal to the products of the numbers in W, e.g., by incorporating such a product computation inside the quadratic test. This quadratic test in turn can be verified through the aggregate and decommitments. The verifier can also check that the lists R and W themselves were constructed correctly, e g., incorporated via a linear test as each entry in R and W come from a memory access and related to the memory access via a linear relation.D. Advantages

[0427] The following advantages can be obtained.

[0428] Regarding prover efficiency, the Prover includes a constant number of values 3 for read only and 4 for read-write per access in the first set of witness values. In the second set of witness values it includes two values per access, one in R and one in W and finally one value per entry of the table. Overall, the number of witness values generated by T accesses from a table of size D will be O(T + D). In the naive solution it was O(T x D).

[0429] For memory' efficiency, the modifications can be incorporated in a memory efficient manner. The Prover will have to recompute the values when it generates the second set of witnesses. So it adds one more pass on the computation. The original Ligero requires three passes. Incorporating lookups results in a total of four passes.9079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 VI. EXAMPLE COMBINATION TECHNIQUE #1

[0430] As described in the preceding sections, individual systems and methods can be used to provide for succinct verification, dynamic branching, and verification of memory accesses. For many practical software applications, a combination of these features is desirable to create a single, unified system that is capable of efficiently and privately verifying complex, real-world programs. Such programs often feature control flow that depends on secret inputs (dynamic branching) and make random-access calls to memory, where the access patterns themselves is to be kept private. Accordingly, embodiments described herein provide a single, integrated zero-knowledge proof system that enables succinct verification for programs exhibiting both dynamic branching and secret-dependent memory access patterns, combining the principles of preprocessing, block-based modularity, and lookup arguments into a cohesive protocol.

[0431] The combined method bifurcates the program's constraints into two primary sets: a first set governing the computational logic and execution flow within program blocks, and a second set dedicated to validating the integrity of memory accesses (e.g., which element of the memory was accessed) via lookup arguments. These two sets of constraints, represented by distinct but related constraint matrices (e.g., A and A*), are handled in a coordinated manner throughout the proof generation and verification process. While certain stages of the protocol, such as the generation of cryptographic fingerprints, may treat these constraint sets independently to maintain modularity, other stages (e.g., aggregate tests), combine them to ensure holistic consistency. This structure allows the verifier to confirm that the memory accesses claimed by the prover are consistent with the program's execution logic, and that both aspects of the computation were performed correctly.A. Flow

[0432] FIG. 15 provides a prover technique that combines the succinct prepressing, dynamic branching, and verification of memory accesses, e.g., using use of lookup tables. As illustrated, the prover executes a multi-stage protocol to generate a comprehensive proof. The prover first generates and commits to separate witnesses for the program's computational values and the auxiliary' values required for the lookup argument (e.g., the R and W lists). Subsequently, the prover generates commitments to the randomized constraint matrices and performs a series of aggregate checks, including a unified linear test that cross-validates the 9179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 witnesses from both the program execution and the memory lookup stages. The protocol then generates separate fingerprints for each constraint set and a final, second proof. This second proof demonstrates that the computed fingerprints correspond to a valid, secret sequence of pre-committed program and memory' constraint submatrices, thereby providing an end-to-end guarantee of the program’s integrity in a succinct and memory-efficient manner.

[0433] In a one-time preprocessing step, commitments are made to all possible constraint submatrices, Ai for the program and Ai* for the lookup arguments, corresponding to each program block. Commitments can also be made for the entire constraint matrices A and A*.

[0434] At block 1510 (Stage 1), the prover performs a Commit Stage by executing the program to generate a primary witness. This witness contains all the "wire values," which include all inputs, intermediate computational values, and outputs that define the program's execution trace. To incorporate memory access verification, for every lookup operation performed by the program, the prover can append a tuple to the witness, such as (addr, val, counter), where 'addr' is the memory' address accessed, 'val' is the value at that address, and 'counter' is a value tracking the number of times that specific address has been accessed. The complete witness can then be arranged into a matrix, encoded row-by-row using an errorcorrecting code, and cryptographically committed to, for instance by constructing a Merkle tree and sending the root to the verifier. Block 1510 can be performed in a similar manner as described in FIGS. 2-10 and other sections herein. The tuples can be generated on the fly, as opposed to storing ahead of time, so as to reduce memory requirements.

[0435] At block 1520 (Stage 1.5), the prover performs a Commit Lookup Stage to generate a second witness dedicated to verifying the memory accesses. After obtaining a set of random numbers (e.g., from the verifier or via Fiat-Shamir), the prover constructs two lists, R and W, based on the (addr, val, counter) tuples from the first witness. These lists are populated with values derived from linear combinations of the tuple elements and the random numbers. The second witness includes all the elements of the R and W lists, along w ith any auxiliary values needed to prove that the product of all elements in list R is equal to the product of all elements in list W, e.g., as described in section V. This second witness is then encoded and committed to in the same manner as the first, providing a cryptographic binding to the memory’ access data.

[0436] At block 1530 (Stage 2), in a Commit Randomness Matrix Stage, the prover prepares the randomized constraint matrices needed for the succinct linear test. Using a 9279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 random vector rTderived from the protocol state, the prover computes two separate matrices: rTA, which corresponds to the affine constraints on the primary witness from Stage 1, and rTA*. which captures the affine constraints related to the lookup argument witness from Stage 1.5. The prover commits to both of these matrices, e.g., by encoding them and generating Merkle roots, thereby offloading the computational burden of their construction from the verifier to the prover. In the following Agg Stage, the prover will commit to rTX A together with rTX A*.

[0437] At block 1540 (Stage 2.25), the prover executes the Aggregate Stage, where it computes and provides aggregate values for several checks that span both the primary' and lookup witnesses. For the code test and the quadratic (multiplication) test, the pro ver computes aggregates across the combined set of values committed in Stages 1 and 1.5 to verify correct encoding and the satisfaction of all multiplication constraints. For the linear test, the prover performs a combined check, applying the rTA matrix to the witness from Stage 1 and the rTA* matrix to the witness from Stage 2. These results are combined into a single aggregate value that, if the constraints are satisfied, can decode to a known value, such as zero.

[0438] At block 1550 (Stage 2.5), in a Fingerprint Stage, the prover generates the fingerprint values used for the second proof. This stage proceeds as described in section III (e.g., for the pre-processing SNARK), but it is performed separately (independently unlike block 1540) for the two sets of constraints. Using a second random vector s, the prover computes two distinct fingerprints: a = rTAs and a* = rTA *s. These two scalar values, a and a*, serve as compact cryptographic summaries of the entire constraint system for the program logic and the memory’ lookups, respectively. The individual Oi and oti* can also be determined at this stage.

[0439] At block 1560 (Stage 3), in the query stage, the prover facilitates spot-checking by the verifier. In response to a set of randomly selected column indices, the prover samples t columns for all commitments made in the preceding stages. This includes revealing ('“opening”) the column values from the encoded witnesses (from Stages 1 and 1.5) and the encoded randomness matrices (from Stage 2), along with the decommitments (e g., Merkle decommitments) to prove that the revealed data is authentic and consistent wi th the original commitments.9379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0440] For the query stage, verification (e.g., via spot checks) can be made for the commitments of both rTx A and rTx A*. as well as the primary witness and the second witness as well as any commitments for the entire A and A* along with the corresponding constraint submatrices. Such spot checks can be performed as described herein, e.g., for FIGS. 12 and 14.

[0441] At block 1570 (Stage 4), a second proof is generated using the commitments from the preprocessing stage to provide a second proof demonstrating that there exists a secret sequence of block numbers corresponding to the actual program execution. In the preprocessing step, the Prover committed to Atthat capture the linear constraints for Stage 1 and A* that are the constraints on the values in Stage 1.5.

[0442] The prover will provide a second proof that there exists block numbers b1(..., bTsuch that a and a* can be recomputed from r and commitments Atand A* for each block i that were committed to in the pre-processing stage. Accordingly, the second proof can attest that the fingerprints a and a* can be correctly recomputed from a valid combination of the pre-committed Ai and Ai* constraint submatrices, thereby assuring the verifier that the entire computation, including its dynamic branches and memory accesses, was performed correctly.

[0443] The Verifier can perform similar operations, e.g., as in each of the optimizations, pre-processing, dynamic branching and lookups except for how the linear test is computed. The prover provides the sampled columns that are used to compute aggregate for the values in Stage 1. For Stage 1.5. the verifier computes the pre-population for the list R and verifies the products of the lists R and W are equal, however, this is structured, so it can be computed in sublinear time.B. Stage 1.5: Commit Lookup Stage

[0444] As described in block 1520, the prover generates commitments for checking memory access (lookups). Scalar values are used to populate two lists, referred to as R and W. The value added to list R is computed using an incremented counter, while the value for list W uses the original counter, establishing a relationship between the two lists.

[0445] The second witness, committed to in this stage, is composed of all the elements in the R and W lists, as well as any auxiliary "wire values" necessary' to prove that the product of all elements in list R is equal to the product of all elements in list W. This product equality9479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 serves as a constraint for verifying the entire sequence of memory lookups in a single, batched operation. The prover includes the intermediate computations for these products within the second witness. Once fully constructed, this second witness is arranged into a matrix, encoded, and cryptographically committed to, for instance by generating a second Merkle root, creating a cryptographic binding that is distinct from the commitment made in Stage 1.

[0446] A key aspect of this stage is that it introduces constraints that span across the two separate commitments from Stage 1 and Stage 1.5. The verifier can confirm that the values populating the R and W lists in the second witness were correctly computed from the corresponding (addr, val, counter) tuples that were committed to in the first witness. For example, a value in the second memory witness can be constrained to be equal to a linear combination of three specific values from the first memory witness and public random numbers. These cross-commitment constraints ensure that the prover cannot fabricate the memory access proof independently of the actual program execution, thereby linking the memory’ integrity check directly to the computational trace.

[0447] For dynamic branching, the constraints are dynamic for stages 1 and 1.5. Similar to the constraint submatrices Ai, A2, A3 committed in stage 1, and there is a separate set of constraint submatrices Ai*, A2*, A3* committed in stage 1.5. Thus, there are two sets of constraints submatrices corresponding to the program blocks, given dynamic branching is present. When the linear test is performed, the fingerprint can be performed separately for the two sets of constraint submatrices.C. Stage 2.25 Dependent parts

[0448] As described for block 1540, the prover executes the aggregate stage, where the cryptographic checks are performed across the full scope of the computation, encompassing both the program execution witness from Stage 1 and the memory' lookup witness from Stage 1.5. For the code (proximity) and quadratic (multiplication) tests, the prover treats the two sets of committed values as a single, unified set. It computes random linear combinations and aggregate values that span both witnesses to demonstrate that all values were encoded correctly and that all multiplication constraints throughout the entire process have been satisfied. For the linear test, the distinct roles and dependencies of the constraint matrices A and A* are explicitly combined.9579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0449] The linear test enforces the interdependence of the program logic and the memory access verification. The prover does not treat the two constraint systems in isolation; instead, it combines them into a single, comprehensive check. Using the previously committed randomized matrices, the prover applies rTA to the witness values from Stage 1 and rTA* to the witness values from Stage 1.5. The resulting aggregate vectors from these two operations are then added together. This combined result is what the prover provides to the verifier as the final aggregate for the linear test.

[0450] As the matrix A captures the constraints within the program's logic and A* captures the constraints between the program's logic and the memory' lookups, this ensures that a value used in the R and W lists of the second witness corresponds correctly to an (addr, val, counter) tuple in the first witness. When the linear test aggregates are combined, the terms are constructed in such a way that they can cancel each other out, and the total sum resolves to zero if and only if all constraints, both computational and memory -related, are simultaneously satisfied. This unified check ensures that the prover cannot create a valid proof without maintaining consistency between its claimed program execution and its claimed memory accesses, providing a holistic and robust verification of the entire computation.D. Example types of constraints

[0451] The combined zero-knowledge proof systems described herein are structured to verify not only the integrity of the computational logic of a program but also the correctness of all memory access operations performed during its execution. To enable this comprehensive verification, the system defines and enforces several distinct types of constraints.

[0452] Primary computational constraints govern the relationships among the internal variables of the program as it executes. These constraints include linear or affine equations derived from the program’s logic, and they encode the correct evaluation of arithmetic operations, control flow, and data manipulation within each block of code. The complete set of such relationships for a given program is captured in the form of a constraint matrix, commonly denoted as A. This matrix A encodes, for each block, the required relationships among the program’s wire values — inputs, intermediate results, and outputs — ensuring that, for the claimed witness, all computational steps are performed as specified by the program logic.9679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0453] Memory' access constraints enforce the integrity of the program's interactions with memory. To address this, the system introduces a second set of constraints, e.g., represented as a matrix A*, that is specifically designed to validate the sequence and correctness of memory accesses. These constraints link the memory operations observed in the computational trace (such as reads and writes to particular addresses) to auxiliary witness values — such as the R and W lists described in the lookup argument technique — ensuring that the prover cannot forge or misrepresent which memory locations were accessed or what values were read or written.

[0454] A third type of constraint is the cross-commitment constraint, which connects values appearing in both the primary witness (committed in Stage 1) and the auxiliary' witness for memory accesses (committed in Stage 1.5). These constraints enforce that for every memory access, the tuple (address, value, counter) recorded in the primary witness is faithfully reflected in the construction of the R and W lists in the auxiliary witness. This linkage can guarantee that the memory access proof is not fabricated independently of the actual computation, but instead is intrinsically tied to the program’s execution trace.

[0455] Additionally, the protocol may impose internal consistency constraints within the lookup argument itself. These can ensure that the product of the R list equals the product of the W list, and may include auxiliary' constraints on intermediate computations (such as sums or products of subsets of values) to allow for efficient batch verification. These product constraints serve as a succinct global check that all memory accesses were performed correctly and that no tampering or omission has occurred.

[0456] In the context of dynamic or secret-dependent control flow, the protocol can support constraints that enforce the legitimacy of the execution path itself. This is achieved by requiring that the sequence of constraint matrices Ai (for computation) and Ai* (for memory') used in the proof correspond to a valid sequence of program blocks, as determined by the program’s design. The commitments to all possible submatrices can be established in the preprocessing stage, and during proof verification, the prover can demonstrate — without revealing the actual path — that the constraints applied were drawn from this precommitted set and arranged in a manner consistent with an allowed execution.

[0457] By assembling these classes of constraints — computational, memory access, crosscommitment. internal consistency, and path legitimacy — the protocol ensures that the verifier can be confident, with succinct communication and minimal computational effort, that the 9779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 prover’s claimed execution is both correct and privacy -preserving, even in the presence of complex, dynamic branching and secret-dependent memory access patterns.VII. EXAMPLE COMBINATION TECHNIQUE #2

[0458] Another example for a combination technique is provided. In this example, a single fingerprint is determined using both the primary constraint matrix A and memory constraint matrix A*.

[0459] In the preceding section, a combined method was described in which the program’s computational constraints and the memory access constraints were treated as separate entities, with independent fingerprints generated for each using their respective constraint matrices, A and A*. While this modular approach provides efficiency and flexibility-, certain applications can benefit tighter integration between the verification of program logic and memory integrity.

[0460] This section introduces an alternative method in which the computation of the fingerprint directly interweaves the contributions of both A and A*, producing a single, unified fingerprint that is dependent on both types of constraints. This alternative approach changes the structure of the fingerprinting stage (Stage 2.5) and the global consistency check. Instead of producing two parallel fingerprints, this alternative method computes a single fingerprint by aggregating the results of linear operations that span both the primary' constraint matrix A and the auxiliary constraint matrix A* associated with memory accesses. In this construction, respective random vectors r and r* are applied to the respective constraint matrices A and A*, and then a combined result used with an inner product with the random vector s to produce the fingerprint a. This ensures that the resulting fingerprint value cannot be decomposed or manipulated independently for the program logic and the memory¬ checks. As a result, a valid fingerprint can only be produced if the prover’s witness satisfies all constraints — both computational and memory-related — simultaneously.A. Prover Stages

[0461] This section describes a single proof system that enables succinct verification through pre-processing, dynamic branching, and lookup arguments. The Prover steps are below. Certain steps can be per block as described herein.9879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 1. Preprocessing

[0462] Before the main execution of the proof protocol, a one-time preprocessing stage can be performed to generate cryptographic commitments to all possible constraint submatrices that may be encountered during the execution of the program. This preprocessing can enable both the succinctness and the security of the subsequent verification process, particularly in scenarios involving dynamic branching and secret-dependent memory accesses.

[0463] In this stage, the program can be logically divided into a collection of discrete program blocks, each representing a segment of code that executes linearly without internal branching. For each block, a corresponding constraint submatrix is derived: Ai for the computational logic of the block, and Ai for the memory access constraints associated with that block. The set of all Ai captures computational constraints that the program might execute, while the set of all A*i captures memory access constraints relevant to the execution paths.

[0464] The prover (or, in some embodiments, a trusted third party or the verifier) can generate a cryptographic commitment to each submatrix Ai and Ai*. This can be accomplished by encoding each submatrix — such as through row-wise application of an error-correcting code — and then constructing a Merkle tree over the resulting encoded data. The Merkle root (or a comparable succinct cryptographic digest) for each submatrix serves as its commitment. These commitments are made publicly available and are referenced throughout the main proof protocol. The commitments ensure that neither party can alter the constraint matrices after the preprocessing step, thereby establishing an immutable foundation for the integrity' of the proof.

[0465] By precommitting to all possible constraint submatrices (both computational and memory’ -related), the system enables the prover, during the main proof protocol, to later demonstrate that the constraints it used in the course of a secret-dependent execution path were in fact drawn from this fixed, pre-established set. During the final proof stages, the verifier will require that any fingerprint or aggregate value submitted by the prover can be recomputed from a valid combination of these precommitted submatrices, corresponding to some legitimate (but hidden) sequence of program blocks. This structure guarantees that the prover cannot invent new' constraints or manipulate the constraint system to its advantage,9979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 and it is the cornerstone of the protocol’s ability to efficiently and securely verify both computational and memory integrity in complex, branching programs.2. Commit stage

[0466] In stage 1 (commit stage), the prover executes the target program to generate the primary witness. For example, the Prover can computes the witness that contains all wire values and for every lookup into a table, it can include additional values like counter with (addr, val), if memory access to lookup tables is used. The prover can generate a second set of witness values w’ specifically for verifying memory accesses. This stage can be performed in a similar manner to block 1 10 in FIG. 15. This stage can be performed for each program block if there is dynamic branching, e.g., execution of a sequence of the program blocks.3. Commit lookup stage

[0467] In stage 1.5 (commit lookup stage), following the receipt of random numbers (e.g., via the Fiat-Shamir heuristic), the prover constructs two lists, R and W, from the (addr, val, counter) tuples in the second witness portion w’ for memory’ accesses. Each value in R and W is computed as a linear combination of the tuple elements and the provided random numbers, with R using an incremented counter and W using the original counter, e.g., as described in section V. The second witness includes these lists, along with any intermediate values to prove that the product of the elements in R equals the product of the elements in W. This second witness is also encoded and cryptographically committed, e.g., by constructing a second Merkle root. This stage is performed in a similar manner to block 1520 in FIG. 15.

[0468] This stage can be performed across program blocks if there is dynamic branching, e.g., execution of a sequence of the blocks. Thus, lists of R and W can span across all blocks, e.g., because memory’ can be accessed across blocks. For instance, the program can store a number in block one and read the number in block five.4. Agg stage

[0469] In stage 2 (Agg Stage), the prover computes aggregate values for the code (proximity) test and the quadratic (multiplication) test, spanning both the program execution witness (stage 1) and the lookup witness (stage 1.5), as previously described.10079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0470] For the linear test, the pro ver prepares rTX A for all the affine constraints within -» Tstage 1. The prover also prepares r* x A* that affine constraints between Stages 1 and 1.5 in -» Ta different way. The prover prepares A* and r*such that r* x A x w will equal(v, v2,... x w' where w' are the values committed in Stage 1.5 and v is a random vector. In the Agg Stage, the prover will prepare a commitment of rTX A + r*TX A* and the result of the linear test computed across both stages.

[0471] Accordingly, rather than treating the aggregates for A and A* independently, the prover forms a single aggregate by combining the results: the aggregate vector from rTA Tapplied to the primary witness and the aggregate from r* A applied to the lookup witness are added together. The resulting unified aggregate is provided to the verifier, and is constructed so that it resolves to zero if — and only if — both the computational and memory-related constraints are simultaneously satisfied. This stage thus ensures that the integrity of the program logic and the validity of all memory accesses are checked together in a single, holistic operation.5. Fingerprint stage

[0472] In stage 2.5 (Fingerprint Stage), the fingerprint can be determined in a similar manner as determined in section III. Here the fingerprint can be determined as a = rTx A + r* X *) X s. The fingerprinting stage reveals the alpha and proves that it was correct.

[0473] Accordingly, instead of producing two parallel fingerprints (one for A and one for A*), the prover computes a single fingerprint that is jointly dependent on both constraint matrices. The random vectors used for fingerprinting are applied respectively across the combined or concatenated constraint matrices, so that the resulting fingerprint value cannot be decomposed or manipulated independently. This single fingerprint a succinctly summarizes the global consistency of the entire constraint system, encompassing both computational and memory integrity in one value. The proofs soundness now requires that the witness satisfy all constraints across both A and A*, as the fingerprint is inextricably linked to both.6. Query stage (spot checks)

[0474] In stage 3 (Query Stage), the prover will sample t columns and reveal the columns in the commitments made in Stage 1, 1.5 and 2. In this stage, the prover opens this10179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 commitment, so that the verifier can perform spot checks on these commitments to check that they are consistent with all the constraints.

[0475] Accordingly, in this stage, the verifier can perform spot-checks by selecting a set of random column indices, e g., from Fiat-Shamir. The prover opens the corresponding columns from all commitments made in the previous stages — including the encoded witnesses from Stages 1 and 1.5, and the encoded randomness matrices from Stage 2 — and provides the associated decommitments (e.g., Merkle decommitments). This enables the verifier to check that the revealed data is consistent with the original commitments and that the aggregate and fingerprint computations were performed honestly. This stage can operates in a manner analogous to block 1560 in FIG. 15, but the use of the single fingerprint means that any inconsistency across A or A* is likely to be detected.7. Second proof

[0476] In stage 4 (second proof), the prover can provide a second proof that there exists block numbers bi,...,br. such that a can be recomputed from rT, r*Tand commitments At for each block i that is computed in a pre-processing stage.

[0477] The second proof can rely on the preprocessing step where commitments are generated for all possible constraint submatrices Ai (for the program) and Ai (for memory accesses), corresponding to each possible program block. The prover can demonstrate, using a succinct proof system (such as a SNARK), that there exists a secret execution sequence of block numbers such that the single, unified fingerprint a can be recomputed from a valid combination of the pre-committed Ai and A*i submatrices. This proof assures the verifier that all constraints — both computational and memory -related — were satisfied together, and that the claimed program logic and all memory accesses form a consistent, correct computation.B. Verifier

[0478] The Verifier’s steps can follow as in each of the optimizations, pre-processing, dynamic branching and lookups except for how the linear test is computed. The prover provides the sampled columns that will help compute aggregate for the values in Stage 1. For Stage 1.5, the verifier computes on its own, however, this is structured, so it can be computed in sublinear time.10279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 VIII. METHODS

[0479] Various methods described above are now described. Each of the methods can be combined together, e.g., two together, three together, and so on. Thus, embodiments described for one method can be used in combination with embodiments described from another method. And similar steps in one method can be performed in a similar manner as the step in another method.A. Succinct verification

[0480] As described in section III and elsewhere, succinct verification can be achieved program constraints corresponding to a state of the software program on the prover computer.1. Prover computer

[0481] The following method can be performed by a prover computer for proving a state of the prover computer to a verifier computer.

[0482] At step 1610, the prover computer obtains a software program having a set of constraints. In some embodiments, the process can involve generating a circuit that represents the software program, where the set of constraints corresponds to the logic gates and connections within the circuit. This transformation allows the program’s logic to be expressed as a collection of interconnected arithmetic gates, such as additions and multiplications, which establishes the foundation for extracting the constraints.

[0483] At step 1620, the prover computer obtains a constraint matrix A corresponding to the set of constraints and a commitment CA generated by performing a commit cryptographic function on the constraint matrix A. The constraint matrix A and its commitment CA are public, e.g.. being obtained from the prover. This can be part of a preprocessing phase where the commitment CA, such as a Merkle root of an encoding of A, serves as a public reference for the constraint system. The commitment ensures the structure of the constraints remains fixed and verifiable. In some embodiments, the constraint matrix A can correspond to a specific block of the software program (e.g., as described in section IV), allowing for modular verification of programs with dynamic branching. The commit cryptographic function used to generate CA, and other commitments, can involve constructing a Merkle tree.10379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0484] At step 1630, the prover computer generates a witness w by applying the software program to one or more inputs. The witness w can comprise the one or more inputs, one or more intermediate values (sometimes called '‘wire values”), and one or more final values, which can represent a complete record of the program's execution. In some embodiments, the witness w can be encoded, for example using a Reed-Solomon code, to obtain an encoded witness prior to generating the commitment Cw in a later step.

[0485] For embodiments that also verify memory accesses (e.g., as described in section V), the system can use another constraint matrix A* corresponding to memory accesses made by the software program. In such cases, generating the witness w can include generating a first witness portion with a set of tuples for each memory access, where a tuple may comprise a memory address, a program value, and a counter for the number of times the address has been accessed. This can be followed by obtaining a set of random numbers known to the verifier and generating a second witness portion comprising a first list R and a second list W. These lists are generated using the random numbers and the tuples, such that a product of elements (e.g., sequence values) in list R equals a product of elements in list W. This process may also involve generating a pre-population value p to generate a portion of list R, such that the product of additional elements in list R and the value p equals the product of elements in list W. Such checks can be performed as part of the quadratic test, e.g., as described herein.

[0486] At step 1640, the prover computer generates a public vector b by application of the constraint matrix A to the witness w. This public vector b captures the right-hand sides of all linear constraints defined by the matrix A and can be used by the verifier to check that the witness satisfies the required relationships.

[0487] At step 1645, the prover computer generates a commitment Cw by applying a commit cryptographic function to the witness w7. As mentioned, the witness w can be encoded first to create an encoded witness, and the commitment Cw is then generated from this encoded witness. The commit cryptographic function can be the construction of a Merkle tree over the columns of the encoded witness matrix, with the Merkle root serving as the commitment CW.

[0488] At step 1650, the prover computer obtains a first random vector r. This random vector, along with others used in the process, can be generated using a non-interactive technique such as a Fiat-Shamir heuristic. For example, the first random vector r can be generated using the constraint matrix A.10479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0489] At step 1655, the prover computer generates a commitment CrA of a second random vector r’ resulting from an application of the first random vector r to the constraint matrix A. This step effectively offloads the computation of r' from the verifier to the prover. The commitment CrA can also be generated using a Merkle tree.

[0490] At step 1660, the prover computer obtains a third random vector s. Similar to the first random vector r, this can be generated using a Fiat-Shamir heuristic. In some embodiments, the third random vector s can be generated using the second random vector r'.

[0491] At step 1665, the prover computer generates a fingerprint a using the first random vector r, the constraint matrix A, and the third random vector s. This fingerprint, a = r‘A-s, succinctly summarizes the global consistency of the prover's computations with respect to the original constraint matrix. In embodiments that also verify memory accesses using a second constraint matrix A*, the fingerprint a can be generated using both the constraint matrix A and the other constraint matrix A*. Alternatively, another fingerprint a* can be generated using the first random vector r, the constraint matrix A*, and the third random vector s.

[0492] At step 1670, the prover computer generates a proof n using the first random vector r, the constraint matrix A, the third random vector s, the fingerprint a, and commitment CA. This proof is a secondary proof, such as a SNARK, that attests to the consistency of the fingerprint a with the publicly committed constraint matrix A. For embodiments that also verify memory accesses using another constraint matrix A*, the proof n can be generated using the other constraint matrix A* as well. After generating the necessary commitments and proofs, the prover can also generate aggregate values for various checks. A code aggregate can be generated for a code check of the encoded witness, computed as a linear combination of a fourth random vector (which can be the first random vector r) and the encoded witness values. A quadratic aggregate can be generated for a quadratic check by performing element-wise operations on rows of the encoded witness. A linear aggregate can be generated for a linear check by performing an element-wise operation of the second random vector r’ and the encoded witness. These aggregates can be sent to the verifier computer.

[0493] At step 1680, the prover computer sends the proof n, the fingerprint a, the commitment Cw, and commitment CrA to a verifier computer, enabling the verifier to verify the accuracy of the one or more final values without re-executing the entire program. The prover computer can also send the public vector b to the verifier computer. To facilitate spot checks by the verifier, the prover computer can also generate and send decommitments. This 10579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 can involve generating a first set of decommitments corresponding to a number of random columns of the witness w and a second set of decommitments corresponding to a number of random columns of the second random vector r’. The random columns for these decommitments can be selected using a Fiat-Shamir heuristic. The decommitments themselves can include hashes from the data structures, such as Merkle trees, that were used to generate the commitments Cw and CrA.2. Verifier computer

[0494] The following method can be performed by a verifier computer for verifying a state of a prover computer.

[0495] At step 1710, a verifier computer receives, from the prover computer, a proof?i, a fingerprint a. a commitment CW to a witness w. and a commitment CrA to a random vector r'. The witness w comprises the inputs, intermediate values, and final values from the execution of a software program. The software program is associated with a set of constraints captured by a public constraint matrix A and a public commitment CA to that matrix. The random vector r' results from the application of a first random vector r to the matrix A, and the fingerprint a is computed using r, A, and a second random vector s.

[0496] In some embodiments, the verifier computer can also receive, from the prover computer, the public vector b generated by the application of the constraint matrix A to the witness w. The constraint matrix A can correspond to a block of the software program, enabling modular verification. The verifier can also obtain a constraint matrixA corresponding to memory accesses made by the software program when applied to the one or more inputs, where the proof it is also generated using this constraint matrix A.

[0497] At step 1720, the verifier computer obtains the first random vector r and the second random vector s. To maintain a non-interactive protocol, the first random vector r and the second random vector s can be generated using a Fiat-Shamir heuristic. This ensures that both the prover and verifier can derive the same random values independently from the public state of the protocol, such as from the commitments and public inputs.

[0498] At step 1730, the verifier computer verifies the witness w and the random vector r' by performing several checks using decommitments. The verifier receives a first set of decommitments for the witness w and a second set for the random vector r'. In some embodiments, the first set of decommitments can include a first number of random columns 10679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 of an encoding of the witness w and correspond to a first data structure (like a Merkle tree) used to generate Cw, and the second set of decommitments can include a second number of random columns of an encoding of r' and correspond to a second data structure used to generate CrA. The random columns can be selected using a Fiat-Shamir heuristic. The verifier can use the first set of decommitments to verify that sampled data of the witness w is consistent with the commitment Cw. The verifier can use the second set of decommitments to verify that sampled data of the random vector r' is consistent with the commitment CrA.

[0499] For embodiments verifying memory access (e.g., as described in section V), verifying the witness w can comprise obtaining a set of random numbers and verifying a first list R and a second list W, both generated using the set of random numbers and a set of tuples corresponding to memory’ accesses. This verification can include confirming a first product of elements (e.g., sequence values) in the first list R equals a second product of elements in the second list W. Such checks can be performed as part of the quadratic test, e.g., as described herein.

[0500] At step 1740, the verifier computer verifies that the fingerprint a is consistent with the received commitments and the public constraint matrix A. This can be a two-part process. The verifier can use the second set of decommitments to verify that the random vector r' applied to the second random vector s provides the fingerprint a. This confirms the fingerprint is consistent with the r1committed to by the prover.

[0501] The verifier can also use the proof n, the public commitment CA, and decommitments to the public commitment CA to confirm that the fingerprint a is also obtained from applying the first random vector r and the second random vector s to the original constraint matrix A. This second check ensures the prover used the correct, public matrix A to generate r1. In embodiments that use a separate constraint matrix A for memory, the verifier can also receive another fingerprint a generated using r, A, and s, and can proceed to verify the other fingerprint a in a similar manner.

[0502] At step 1750, the verifier computer verifies, using the first set of decommitments and the second set of decommitments, that the random vector r' applied to the witness w provides a same result as the random vector r applied to a public vector b, where b is generated by A applied to w. This step, referred to as the linear check, ties together the prover's witness, the public constraints, and the prover-computed random vector r', ensuring all linear relationships in the computation hold true.10779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0503] At step 1760, the verifier computer verifies that the pro ver computer executed the software program using the one or more inputs based on the successful completion of the verifications. If all checks pass, the verifier accepts the proof, concluding with high probability that the prover's computation is correct without having learned any secret information.

[0504] As part of a broader verification process, the verifier computer can perform additional checks. It can receive, from the prover computer, a code aggregate generated as a linear combination of a third random vector and values of an encoding of the witness w. The verifier can then perform a code check of the encoding of the witness w by checking that the code aggregate corresponds to one or more valid codewords.

[0505] The verifier computer can perform further checks on the computation's integrity. It can receive, from the prover computer, a quadratic aggregate generated by performing an element-wise operation of two rows of an encoding of the witness in combination with a reduction of a third row and a third random vector. The verifier can confirm the quadratic aggregate is all zeros, which validates that all multiplication constraints in the original program were correctly satisfied.B. Dynamic branching

[0506] As described in section IV and elsewhere, verification of proper execution of a software program that includes dynamic branching can be achieved program constraints corresponding to a state of the software program on the prover computer.1. Prover computer

[0507] The following method can be performed by a prover computer for proving a state of the prover computer to a verifier computer. The state includes dynamic branching of a software program.

[0508] In step 1810, the prover computer obtains a software program having a set of constraints. The software program can have a dynamic flow control between program blocks of the software program. Instead of a single, linear execution path, the program is logically divided into a series of program blocks, and the sequence of blocks traversed is determined by the program's inputs, which may be secret.10879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0509] In step 1820, the prover computer obtains a constraint matrix A corresponding to the set of constraints. The constraint matrix A can include a set of constraint submatrices, each corresponding to a program block of the software program. The prover computer can also obtain a set of commitments CA generated by performing a commit cryptographic function on each of the set of constraint submatrices. The constraint matrix A is public and the commitment CA is public, e.g., by being provided to the verifier from the prover. This can be done in a preprocessing phase, where a commitment is generated for each submatrix Ai, creating a verifiable and immutable reference for the constraints of each possible program block.

[0510] In step 1830, the prover computer generates a witness w by applying the program blocks of the software program according to a sequence specified by a set of inputs. The witness w can comprise the set of inputs, intermediate values, and one or more final values. At least one of the intermediate values and the one or more final values (e.g.,, one of these values) can be dependent on a sequence of execution of the program blocks. The witness can further comprise sequence values that are dependent on the sequence of execution of the program blocks.

[0511] In embodiments that also verily memory accesses (e.g. as described in section V), the prover can obtain another constraint matrix A* corresponding to memory accesses made by the software program when applied to the set of inputs. The sequence values (e.g., values in lists R and W) can correspond to the memory accesses. Generating these sequence values can comprise generating a first witness portion comprising a set of tuples corresponding to memory accesses of the program blocks. Each tuple can comprise a memory address accessed by one of the program blocks, a program value for that program block, and a counter for a number of times the memory address has been accessed in the sequence. The prover can then obtain a set of random numbers known to the verifier and generate a second witness portion comprising a first list R and a second list W. These lists are generated using the random numbers and tuples, and the process can involve generating a pre-population value p such that a first product of elements in the first list R and the pre-population value p equals a second product of elements in the second list W.

[0512] In step 1840, the prover computer generates a public vector b by application of the constraint matrix A to witness w. For this step, the constraint matrix A is the total matrix formed by concatenating the constraint submatrices of the blocks that were actually executed,10979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 in the order they were visited. Such a generation can be performed as aggregation of individual public vector bi using each constraint submatrix.

[0513] In step 1850, the prover computer generates a commitment Cw by applying a commit cryptographic function to the witness w. This commitment, e.g., a Merkle root, cryptographically binds the prover to the entire execution trace, including all values generated along the secret execution path.

[0514] In step 1860, for each program block, the prover computer generates a respective (individual) fingerprint using a first random vector r, a corresponding constraint submatrix, and a random vector s. These individual fingerprints, such as ai= r‘AiS, serve as cryptographic attestations that the constraints wi thin each individual block are satisfied.

[0515] In step 1870, the prover computer generates a total fingerprint consistent with the respective fingerprints and the sequence of execution of the program blocks. This total fingerprint can be generated using a linear combination of the respective fingerprints that includes one or more coefficients corresponding to a size of one or more of the constraint submatrices. This method aggregates the individual fingerprints according to the secret sequence. Alternatively, the total fingerprint can be generated using the random vector r and the full, dynamically-assembled constraint matrix A (i.e., a total = rTAs). The consistency between these two methods of calculating the total fingerprint is what the verifier will ultimately check.

[0516] In step 1880, the prover computer can generate a proof that the prover computer stores the sequence of execution of the program blocks. This proof, e.g., a zero-knowledge proof of knowledge, demonstrates that the total fingerprint is a valid combination of the individual fingerprints corresponding to a legitimate, but hidden, execution path.

[0517] In step 1890, the prover computer sends, to a verifier computer, the respective fingerprints for the program blocks, the total fingerprint, the public vector b, the set of commitments CA, and the commitment Cw, and can also send the proof of knowledge of the execution sequence. This enables the verifier computer to verify an accuracy of the one or more final values by checking that the individual and total fingerprints are consistent without learning the secret execution sequence.11079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 2. Verifier computer

[0518] The following method can be performed by a verifier computer for proving a state of a prover computer. The state includes dynamic branching of a software program.

[0519] In step 1910, the verifier computer receives, from the prover computer, a proof comprising a commitment CW to a witness w, a plurality of individual fingerprints, each corresponding to a respective program block of a plurality of program blocks of a software program, a total fingerprint, and a first set of decommitments corresponding to the witness w. The software program has dynamic flow control between its program blocks, and that the witness w was generated by applying these blocks according to a secret sequence specified by a set of inputs. Consequently, the witness w. which comprises the inputs, intermediate values, and final values, is dependent on this secret sequence of execution.

[0520] In step 1920, the verifier computer obtains a random vector r and a random vector s. In a non-interactive setting, these vectors are typically derived deterministically using a Fiat-Shamir heuristic, which applies a cryptographic hash function to the public transcript of the protocol up to this point. This ensures both the prover and verifier compute the exact same random vectors without direct communication.

[0521] In step 1930, the verifier computer verifies, using the first set of decommitments, that sampled data of the witness w is consistent with the commitment CW. The first set of decommitments can include a first number of random columns of an encoding of the witness w and correspond to a first data structure, such as a Merkle tree, that was used to generate the commitment CW. By recomputing the path to the Merkle root using the provided hashes, the verifier authenticates the revealed columns.

[0522] The witness w can further comprise sequence values that are dependent on the sequence of execution of the program blocks. These sequence values can correspond to the memory’ accesses made by the program. Verifying the witness w in such cases can comprise the verifier obtaining a set of random numbers and verifying a first list R and a second list W, which were generated by the prover using tuples corresponding to memory accesses. This verification can include confirming that a first product of elements in the first list R equals a second product of elements in the second list W.

[0523] In step 1940, the verifier computer verifies, for each program block, that a corresponding individual fingerprint corresponds to an application of the random vector r to a 11179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 constraint submatrix Ai for that program block followed by application to the random vector s. This check confirms that the constraints for each potential block were correctly handled by the prover. This verification step can use a commitment of the random vector r applied to the constraint submatrix Ai for that program block and a corresponding set of decommitments, allowing the verifier to check the fingerprint succinctly without recomputing the entire operation. As a further implementation detail, different portions of random vector r can be applied to different constraint submatrices for different program blocks.

[0524] In step 1950, the verifier computer performs a zero knowledge proof with the prover computer to verily that the prover computer knows the sequence of execution of the program blocks that provides, using a public aggregation procedure, an aggregated fingerprint that matches the total fingerprint. The verifier does not leam the sequence, but confirms that a valid sequence exists. As part of this proof, the verifier can verify that the total fingerprint is generated using a linear combination of the individual fingerprints that includes one or more coefficients corresponding to a size of one or more of the constraint submatrices. This aggregation formula cryptographically links the total proof of execution to the individual, pre-committed program blocks.

[0525] In step 1960, the verifier computer verifies that the prover computer executed the software program using the set of inputs based on the successful completion of all prior checks. If the witness commitment is valid, the individual fingerprints are correct, and the total fingerprint is consistent with an aggregation of the individual fingerprints via a valid-but-secret execution sequence, the verifier accepts the proof as validC. Verifying memory accesses

[0526] As described in section V and elsewhere, verification of proper execution of a software program and memory accesses can be achieved program constraints corresponding to a state of the software program on the prover computer.1. Prover computer

[0527] The following method can be performed by a prover computer for proving a state of the prover computer to a verifier computer. The state includes memory accesses of a software program.11279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0528] In step 2010, the prover computer obtains a software program. The software program can have a first set of constraints that apply within program blocks, governing the computational logic, and a second set of constraints for memory accesses made by an execution sequence that is dependent on input values to the software program. In embodiments where the software program has dynamic flow control between program blocks (e.g., as described in section IV). the prover computer can also provide, to the verifier computer, a proof that the prover computer has knowledge of the execution sequence of the program blocks.

[0529] In step 2020, the prover computer obtains a first constraint matrix A corresponding to the first set of constraints and a second constraint matrix A* corresponding to the second set of constraints. The prover computer can also generate a first commitment to the first constraint matrix A and a second commitment to the second constraint matrix A*, and can later send these commitments to the verifier computer. The commitment Cw to the witness w, and the first commitment and the second commitment to the constraint matrices A and A*, can each be generated by arranging the underlying data into a matrix, encoding the matrix using an error-correcting code, and constructing a Merkle tree over the columns of the encoded matrix.

[0530] In step 2030, the prover computer generates a witness w by applying the software program to the input values, where the witness w comprises the input values, intermediate values, memory access values, and one or more final values. Generating the witness w can include, for each memory access, adding a tuple (addr, val, counter) to the witness w. The prover computer can then obtain a set of random numbers and generate auxiliary lists R and W (examples of sequence values) as linear combinations of the tuples and the set of random numbers. Furthermore, generating the witness w can include obtaining decommitments for a set of sampled columns for the commitment Cw and from the commitments to A and A*, which can then be sent to the verifier computer.

[0531] In step 2040, the prover computer generates a first public vector b and a second public vector b* by respective application of the first constraint matrix A and the second constraint matrix A* to the witness w. These vectors represent the expected outcomes of the linear constraints and can be used by the verifier to check the correctness of the witness.

[0532] In step 2050, the prover computer generates a commitment Cw by applying a commit cryptographic function to the witness w. As previously noted, this commitment 11379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 function can involve encoding the witness into a matrix and constructing a Merkle tree over its columns.

[0533] In step 2060, the prover computer obtains a first random vector r, a second random vector r*, a third random vector s, and a fourth random vector s*. In some implementations, to simplify the protocol, the second random vector r* can be the same as the first random vector r, and the fourth random vector s* can be the same as the third random vector s.

[0534] In step 2070, the prover computer generates a first fingerprint using the first random vector r, the third random vector s, and the first constraint matrix A.

[0535] In step 2080, the prover computer generates a second fingerprint using the second random vector r*. the fourth random vector s*. and the second constraint matrix A*.

[0536] In step 2090, the prover computer can generate additional proof elements before sending the final proof package to the verifier. The prover can generate a proof n using the first random vector r. the first constraint matrix A. the third random vector s, the first fingerprint, a commitment CA, the second random vector r, the second constraint matrix A*, the fourth random vector s, and the second fingerprint. The prover can also generate a code aggregate for performing a code check of an encoding of the witness w, a quadratic aggregate for performing a quadratic check, and a linear aggregate for performing a linear check. The linear aggregate can be generated by combining aggregates derived from both the constraint matrix A using the first random vector r and the constraint matrix A using the second random vector r*.

[0537] In step 2095, the prover computer sends, to a verifier computer, the first fingerprint, the second fingerprint, the first public vector b, the second public vector b, and the commitment CW. The prover can also send the proof n, any commitments to A and A*, all decommitments, and the code, quadratic, and linear aggregates, thereby enabling the verifier computer to verify an accuracy of an output value of the software program.2. Verifier computer

[0538] The following method can be performed by a verifier computer for proving a state of a prover computer. The state includes memory accesses of a software program.

[0539] In step 2110, the verifier computer receives, from the prover computer, a proof. This proof can comprise a commitment Cw to a witness w, where the witness w includes 11479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 program inputs, intermediate values, memory access values, and final values. The software program can have a first set of constraints within its program blocks and a second set of constraints for memory7accesses made during an execution sequence. The proof also includes a first fingerprint for the first set of constraints (matrix A) and a second fingerprint for the second set of constraints (matrix A), a first public vector b and a second public vector b* generated from these matrices, and decommitments for a set of sampled columns from each commitment.

[0540] In step 2120, the verifier computer receives a first commitment CA to the first constraint matrix A and a second commitment CA* to the second constraint matrix A*. These commitments, established during a preprocessing phase, serve as the public, immutable ground truth for the program's computational and memory access rules.

[0541] In step 2130, the verifier computer obtains a first random vector r. a second random vector r* (possible same as r), a third random vector s, and a fourth random vector s* (possibly same as s). In a non-interactive protocol, these are derived independently by the verifier using a Fiat-Shamir heuristic, ensuring they are identical to the ones used by the prover without requiring direct communication.

[0542] In step 2140, the verifier computer verifies that the first fingerprint is consistent with the commitments. This involves confirming, using the first commitment CA and decommitments to the first commitment CA, that the first fingerprint is obtained from applying the first random vector r and the third random vector s to the first constraint matrix A. This step can validate the integrity of the program's computational logic.

[0543] In step 2150, the verifier computer verifies that the second fingerprint is consistent with the commitments. This involves confirming, using the second commitment CA and decommitments to the second commitment CA, that the second fingerprint is obtained from applying the second random vector r* and the fourth random vector s* to the second constraint matrix A*. This step specifically validates the integrity of the memory access constraints.

[0544] The verifier computer can perform a verification of the witness related to memory accesses. The verifier can verify, using decommitments, that the witness w includes, for each memory access, a tuple (addr, val, counter), and that values in auxiliary lists R and W, committed by the pro ver computer, are computed as linear combinations of the tuples and a11579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 set of random numbers. As part of this lookup argument, verifying the auxiliary lists R and W can include verifying that a first product of values in list R equals a second product of values in list W.

[0545] The verifier computer can perform, using the decommitments, a linear aggregate check. This check can be performed by combining aggregates derived from both the first commitment CA and the first random vector r, and the second commitment CA* and the second random vector r*. in combination with the commitment Cw. The verifier then can verify that the linear aggregate resolves to a predetermined value, which corresponds to a combination using both (1) the first random vector r, the first commitment CA, and the public vector b and (2) the second random vector r*, the second commitment CA*, and the public vector b*. This check can ensure consistency between the program's execution and its memory accesses.

[0546] In cases where the software program has dynamic flow control between program blocks (e.g., as described in section IV), the verifier computer can verify, using another proof received from the pro ver computer, that the prover computer has knowledge of the execution sequence of the program blocks. This ensures that the memory’ access verification is valid even for programs with input-dependent branching.

[0547] In step 2160, the verifier computer verifies that the prover computer executed the software program using the input values based on the successful verification of the fingerprints and all other checks. If all checks pass, the verifier accepts the proof, concluding with high confidence that the program's computation and all its memory’ accesses were performed correctly and privately.IX. COMPUTER SYSTEM

[0548] Any of the computer systems mentioned herein may utilize any suitable number of subsystems. Examples of such subsystems are shown in FIG. 40 in computer system 10. In some embodiments, a computer system includes a single computer apparatus, where the subsystems can be the components of the computer apparatus. In other embodiments, a computer system can include multiple computer apparatuses, each being a subsystem, with internal components. A computer system can include desktop and laptop computers, tablets, mobile phones and other mobile devices.11679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0549] The subsystems shown in FIG. 40 are interconnected via a system bus 75.Additional subsystems such as a printer 74, keyboard 78, storage device(s) 79, monitor 76 (e.g., a display screen, such as an LED), which is coupled to display adapter 82, and others are shown. Peripherals and input / output (I / O) devices, which couple to I / O controller 71, can be connected to the computer system by any number of means known in the art such as input / output (I / O) port 77 (e.g., USB, FireWire®). For example, I / O port 77 or external interface 81 (e.g., Ethernet, Wi-Fi, etc.) can be used to connect computer system 10 to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus 75 allows the central processor 73 to communicate with each subsystem and to control the execution of a plurality of instructions from system memory 72 or the storage device(s) 79 (e.g., a fixed disk, such as a hard drive, or optical disk), as well as the exchange of information between subsystems. The system memory 72 and / or the storage device(s) 79 may embody a computer readable medium. Another subsystem is a data collection device 85, such as a camera, microphone, accelerometer, and the like. Any of the data mentioned herein can be output from one component to another component and can be output to the user.

[0550] A computer system can include a plurality of the same components or subsystems, e.g., connected together by external interface 81, by an internal interface, or via removable storage devices that can be connected and removed from one component to another component. In some embodiments, computer systems, subsystem, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system. A client and a server can each include multiple systems, subsystems, or components. In various embodiments, methods may involve various numbers of clients and / or servers, including at least 10, 20, 50, 100, 200, 500, 1,000, or 10,000 devices. Methods can include various numbers of communication messages between devices, including at least 100, 200, 500, 1,000, 10,000, 50,000, 100,000, 500,00, or one million communication messages. Such communications can involve at least 1 MB, 10 MB, 100 MB, 1 GB, 10 GB, or 100 GB of data.

[0551] Aspects of embodiments can be implemented in the form of control logic using hardw are circuitry (e.g., an application specific integrated circuit or field programmable gate array) and / or using computer software stored in a memory with a generally programmable processor in a modular or integrated manner, and thus a processor can include memory11779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 storing software instructions that configure hardware circuitry, as well as an FPGA with configuration instructions or an ASIC. As used herein, a processor can include a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked, as well as dedicated hardware. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods to implement embodiments of the present disclosure using hardware and a combination of hardware and software.

[0552] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission. A suitable non-transitory computer readable medium can include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk) or Blu-ray disk, flash memory, and the like. The computer readable medium may be any combination of such devices. In addition, the order of operations may be re-arranged. A process can be terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0553] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device (e.g., as firmware) or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.11879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484

[0554] Any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps. Any operations performed with a processor may be performed in real-time. The term “real-time” may refer to computing operations or processes that are completed within a certain time constraint. As examples, a time constraint may be 1 microsecond, 100 microseconds, 1 millisecond (ms), 50 ms, 100 ms, 500 ms, 1 second, 30 seconds, 1 minute.10 minutes, 30 minutes, 1 hour, 4 hours, 1 day, or 7 days. Thus, embodiments can be directed to computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing a respective step or a respective group of steps. Although presented as numbered steps, steps of methods herein can be performed at a same time or at different times or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, all or portions of a step may be optional. Additionally, any of the steps of any of the methods can be performed with modules, units, circuits, or other means of a system for performing these steps.

[0555] The specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of embodiments of the disclosure.However, other embodiments of the disclosure may be directed to specific embodiments relating to each individual aspect, or specific combinations of these individual aspects.

[0556] The above description of example embodiments of the present disclosure has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form described, and many modifications and variations are possible in light of the teaching above.

[0557] A recitation of "a", "an" or "the" is intended to mean "one or more" unless specifically indicated to the contrary. The use of “or” is intended to mean an “inclusive or.” and not an “exclusive or” unless specifically indicated to the contrary. Reference to a “first” component does not necessarily require that a second component be provided. Moreover, reference to a “first” or a “second” component does not limit the referenced component to a particular location unless expressly stated. The term “based on” is intended to mean “based at least in part on.”

[0558] The claims may be drafted to exclude any element which may be optional. As such, this statement is intended to serve as antecedent basis for use of such exclusive terminology 11979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 as “solely"’, ‘'only’", and the like in connection with the recitation of claim elements, or the use of a "'negative” limitation.

[0559] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted as prior art. Where a conflict exists between the instant application and a reference provided herein, the instant application shall dominate.12079340501 V4

Claims

PATENT Attorney Docket No. 116297-000210PC- 1492484 WHAT IS CLAIMED IS:

1. A method performed by a prover computer for proving a state of the prover computer, the method comprising:obtaining a software program having a set of constraints;obtaining (1) a constraint matrix A corresponding to the set of constraints and (2) a commitment CA generated by performing a commit cryptographic function on the constraint matrix A, wherein the constraint matrix A is public and the commitment CA is public;generating a witness w by applying the software program to one or more inputs, the witness w comprising the one or more inputs, one or more intermediate values, and one or more final values;generating a public vector b by application of the constraint matrix A to witness wgenerating a commitment Cw by applying a commit cryptographic function to the witness wobtaining a first random vector r;generating a commitment GA of a second random vector r’ resulting from an application of the first random vector r to the constraint matrix A;obtaining a third random vector s;generating a fingerprint a using the first random vector r, the constraint matrix A, and the third random vector s;generating a proof 7i using the first random vector r, the constraint matrix A. the third random vector s, the fingerprint a, and commitment CA; andsending, to a verifier computer, the proof it, the fingerprint a, the commitment Cw, and commitment GA, thereby enabling the verifier computer to verify an accuracy of the one or more final values.

2. The method of claim 1, wherein the prover computer also sends the public vector b to the verifier computer.

3. The method of claim 1, further comprising:12179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 generating a first set of decommitments corresponding to a first number of random columns of the witness w and corresponding to a first data structure used to generate the commitment Cw; andgenerating a second set of decommitments corresponding to a second number of random columns of the second random vector r’ and corresponding to a second data structure used to generate the commitment GA.

4. The method of claim 3, wherein the first set of decommitments include hashes.

5. The method of claim 3, further comprising sending the first set of decommitments and the second set of decommitments to the verifier computer.

6. The method of claim 3, wherein the first number of random columns of the commitment Cw and the second number of random columns of the commitment GA are selected using a Fiat-Shamir heuristic.

7. The method of claim 1, wherein the first random vector r and the third random vector s are generated using a Fiat-Shamir heuristic.

8. The method of claim 7, wherein the first random vector r is generated using the constraint matrix A, and wherein the third random vector s is generated using the second random vector r’.

9. The method of claim 1, wherein the witness w is encoded to obtain an encoded witness prior to generating the commitment Cw.

10. The method of claim 9, further comprising:generating a code aggregate for performing a code check of the encoded witness, wherein the code aggregate is generated as a linear combination of a fourth random vector and values of the encoded w itness, and wherein the code aggregate is configured to be checked by the verifier computer against one or more valid codewords: andsending the code aggregate to the verifier computer.

11. The method of claim 10, wherein the fourth random vector is the first random vector r.12279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 12. The method of claim 9, further comprising:generating a quadratic aggregate for performing a quadratic check of the encoded witness, wherein the quadratic aggregate is generated by performing an element-wise operation of two rows of the encoded witness in combination with a reduction of a third row and a fourth random vector; andsending the quadratic aggregate to the verifier computer.

13. The method of claim 9, further comprising:generating a linear aggregate for performing a linear check of the encoded witness, wherein the linear aggregate is generated by performing an element-wise operation of the second random vector r’ and the encoded witness; andsending the linear aggregate to the verifier computer.

14. The method of claim 1, further comprising:generating a circuit representing the software program, wherein the set of constraints correspond to the circuit.

15. The method of claim 1, further comprising:obtaining another constraint matrix A* corresponding to memory accesses made by the software program when applied to the one or more inputs, wherein the proof it is generated using the other constraint matrix A*.

16. The method of claim 15, wherein the fingerprint a is further generated using the constraint matrix A*.

17. The method of claim 15, further comprising:generating another fingerprint a* using the first random vector r, the constraint matrix A*, and the third random vector s.

18. The method of claim 15, wherein generating the witness w comprises: generating a first witness portion comprising a set of tuples corresponding to memory accesses made by the software program, wherein each tuple comprises a memory address accessed by the software program, a program value, and a counter for a number of times the software program has accessed the memory address;obtaining a set of random numbers that are known to the verifier computer; and12379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 generating a second witness portion comprising a first list R and a second list W, both generated using the set of random numbers and the set of tuples, wherein a first product of elements in the first list R equals a second product of elements in the second list W.

19. The method of claim 18, further comprising:generating a pre-population value p using the set of random numbers and a portion of the set of tuples, thereby generating a portion of the first list R, wherein the first product of additional elements in the first list R and the pre-population value p equals the second product of elements in the second list W.

20. The method of claim 1, wherein the commit cryptographic function includes a Merkle tree.

21. The method of claim 1, wherein the constraint matrix A corresponds to a block of the software program.

22. A method performed by a verifier computer for verifying a state of a prover computer, the method comprising:(a) receiving, from the prover computer, a proof TI, a fingerprint a, a commitment Cw to a witness w, a commitment CrA to a random vector r', wherein:the witness w comprises one or more inputs, one or more intermediate values, and one or more final values generated by applying a software program to the one or more inputs,the software program is associated with (1) a set of constraints captured by a constraint matrix A and (2) a public commitment CA generated by applying a commit cryptographic function to the constraint matrix A,the random vector r' results from application of a first random vector r to the constraint matrix A, and the commitment CrA is generated by applying a commit cryptographic function to the random vector r',the fingerprint a is computed using the first random vector r, the constraint matrix A, and a second random vector s;(b) obtaining the first random vector r and the second random vector s;(c) verifying the witness w and the random vector r' by performing:12479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 receiving, from the prover computer, a first set of decommitments corresponding to the witness w and a second set of decommitments corresponding to the random vector r';verifying, using the first set of decommitments, that sampled data of the witness w is consistent with the commitment Cw; andverifying, using the second set of decommitments, that sampled data of the random vector r' is consistent with the commitment GA;(d) verifying that the fingerprint a is consistent with the second set of decommitments by:verifying, using the second set of decommitments, that the random vector r' applied to the second random vector s provides the fingerprint a;confirming, using the proof it, the public commitment CA, and decommitments to the public commitment CA, that the fingerprint a is obtained from applying the first random vector r and the second random vector s to the constraint matrix A;(e) verifying, using the first set of decommitments and the second set of decommitments, that the random vector r' applied to the witness w provides a same result as the random vector r applied to a public vector b, wherein the public vector b is generated by application of the constraint matrix A to the witness w; and(f) verifying that the prover computer executed the software program using the one or more inputs based on (c)-(e).

23. The method of claim 22, further comprising:receiving, from the prover computer, the public vector b generated by application of the constraint matrix A to the witness w.

24. The method of claim 22, wherein the first set of decommitments include a first number of random columns of an encoding of the witness w and correspond to a first data structure used to generate the commitment Cw, and wherein the second set of decommitments include a second number of random columns of an encoding of the random vector r' and correspond to a second data structure used to generate the commitment GA.12579340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 25. The method of claim 24, the first random vector r, the second random vector, the first number of random columns, and the second number of random columns of the commitment CrA are selected using a Fiat-Shamir heuristic.

26. The method of claim 22, further comprising:receiving, from the prover computer, a code aggregate generated as a linear combination of a third random vector and values of an encoding of the witness w; and performing a code check of the encoding of the witness w by checking that the code aggregate corresponds to one or more valid codewords.

27. The method of claim 22, further comprising:receiving, from the prover computer, a quadratic aggregate generated by performing an element-wise operation of two rows of an encoding of the witness in combination with a reduction of a third row and a third random vector; andconfirming quadratic aggregate is all zeros.

28. The method of claim 22, wherein the constraint matrix A corresponds to a block of the software program.

29. The method of claim 22, further comprising:obtaining a constraint matrix A* corresponding to memory’ accesses made by the software program when applied to the one or more inputs, wherein the proof n is generated using the constraint matrix A*.

30. The method of claim 29, further comprising:receiving another fingerprint a* generated using the first random vector r, the constraint matrix A*, and the second random vector s; andverifying the other fingerprint a*.

31. The method of claim 29, wherein verifying the witness w comprises: obtaining a set of random numbers; andverifying a first list R and a second list W, both generated using the set of random numbers and a set of tuples corresponding to memory accesses made by the software program, wherein the verifying includes confirming a first product of elements in the first list R equals a second product of elements in the second list W.12679340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 32. A method performed by a prover computer for verifying a state of the prover computer, the state including dynamic branching, the method comprising:obtaining a software program having a set of constraints, wherein the software program has dynamic flow control between program blocks of the software program;obtaining a constraint matrix A corresponding to the set of constraints, wherein the constraint matrix A includes a set of constraint submatrices, each corresponding to a program block of the software program;obtaining a set of commitments CA generated by performing a commit cryptographic function on each of the set of constraint submatrices;generating a witness w by applying the program blocks of the software program according to a sequence specified by a set of inputs, the witness w comprising the set of inputs, intermediate values, and one or more final values, wherein at least one of the intermediate values and the one or more final values is dependent on a sequence of execution of the program blocks;generating a public vector b by application of the constraint matrix A to witness wgenerating a commitment Cw by applying a commit cryptographic function to the witness wfor each program block, generating a respective fingerprint using a first random vector r, a corresponding constraint submatrix, and a random vector s;generating a total fingerprint consistent with the respective fingerprints and the sequence of execution of the program blocks; andsending, to a verifier computer, the respective fingerprints for the program blocks, the total fingerprint, the public vector b, set of commitments CA, and the commitment Cw, thereby enabling the verifier computer to verify an accuracy of the one or more final values.

33. The method of claim 32, wherein the constraint matrix A is public and the commitment CA is public.

34. The method of claim 32, wherein the total fingerprint is generated using a linear combination of the respective fingerprints that includes one or more coefficients corresponding to a size of one or more of the constraint submatrices.12779340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 35. The method of claim 32, wherein the total fingerprint is generated using the random vector r and the constraint matrix A.

36. The method of claim 32, further comprising:generating a proof that the prover computer stores the sequence of execution of the program blocks; andsending the proof to the verifier computer, thereby enabling the verifier computer to verify the total fingerprint is consistent with the respective fingerprints and the sequence of execution of the program blocks.

37. The method of claim 32, wherein the witness further comprises sequence values that are dependent on the sequence of execution of the program blocks.

38. The method of claim 37, wherein generating the sequence values of the witness w comprises:generating a first witness portion comprising a set of tuples corresponding to memory accesses of the program blocks, wherein each tuple comprises a memory’ address accessed by one of the program blocks, a program value for the one program block, and a counter for a number of times the memory address has been accessed in the sequence of execution of the program blocks;obtaining a set of random numbers that are known to the verifier computer; generating a pre-population value p using the set of random numbers and a portion of the set of tuples; andgenerating a second witness portion comprising a first list R and a second list W, both generated using the set of random numbers and the set of tuples, wherein a first product of elements in the first list R and the pre-population value p equals a second product of elements in the second list W.

39. The method of claim 37, further comprising:obtaining another constraint matrix A* corresponding to memory accesses made by the software program when applied to the set of inputs, wherein the sequence values correspond to the memory accesses.

40. A method performed by a verifier computer for verifying a state of a prover computer, the state including dynamic branching, the method comprising:12879340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 (a) receiving, from the pro ver computer, (1) a commitment Cw to a witness w, (2) a plurality of individual fingerprints, each corresponding to a respective program block of a plurality' of program blocks of a software program, (3) a total fingerprint, and (4) a first set of decommitments corresponding to the witness w, wherein:the software program has dynamic flow' control between program blocks of the software program, andthe witness w is generated by applying the program blocks of the software program according to a sequence specified by a set of inputs, the witness w comprising the set of inputs, intermediate values, and one or more final values, wherein at least one of the intermediate values and the one or more final values is dependent on a sequence of execution of the program blocks;(b) obtaining a random vector r and a random vector s;(c) verifying, using the first set of decommitments, that sampled data of the witness w is consistent with the commitment Cw;(d) verifying, for each program block, that a corresponding individual fingerprint corresponds to an application of the random vector r to a constraint submatrix Ai for that program block followed by application to the random vector s;(e) performing a zero knowledge proof with the prover computer to verify that the prover computer knows the sequence of execution of the program blocks that provides, using the plurality of individual fingerprints and public aggregation procedure, an aggregated fingerprint that matches the total fingerprint; and(d) verifying that the prover computer executed the softw are program using the set of inputs based on (c)-(e).

41. The method of claim 40, wherein performing the zero knowledge proof comprises:verifying that the total fingerprint is generated using a linear combination of the individual fingerprints that includes one or more coefficients corresponding to a size of one or more of the constraint submatrices.

42. The method of claim 40, wherein the first set of decommitments include a first number of random columns of an encoding of the witness w and correspond to a first data structure used to generate the commitment Cw.12979340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 43. The method of claim 40, wherein different portions of random vector r are applied to different constraint submatrices for different program blocks.

44. The method of claim 40, wherein verifying, for each program block, the corresponding individual fingerprint uses a commitment of the random vector r applied to the constraint submatrix Ai for that program block and a corresponding set of decommitments.

45. The method of claim 40, wherein the witness w further comprises sequence values that are dependent on the sequence of execution of the program blocks.

46. The method of claim 45, wherein verifying the witness w comprises: obtaining a set of random numbers; andverifying a first list R and a second list W, both generated using the set of random numbers and a set of tuples corresponding to memory accesses made by the software program, wherein the verifying includes confirming a first product of elements in the first list R equals a second product of elements in the second list W.

47. The method of claim 45, wherein the sequence values correspond to the memory accesses.

48. A method performed by a prover computer for verifying memory’ accesses made by the prover computer, the method comprising:obtaining a software program, the software program having (1) a first set of constraints within program blocks and (2) a second set of constraints for memory’ accesses made by an execution sequence dependent on input values to the softw are program;obtaining a first constraint matrix A corresponding to the first set of constraints and a second constraint matrix A* corresponding to the second set of constraints;generating a witness w by applying the software program to the input values, the witness w comprising the input values, intermediate values, memory access values, and one or more final values;generating a first public vector b and a second public vector b* by respective application of the first constraint matrix A and the second constraint matrix A* to witness w generating a commitment Cw by applying a commit cryptographic function to the witness w;13079340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 obtaining a first random vector r, a second random vector r*, a third random vector s, and a fourth random vector s*;generating a first fingerprint using the first random vector r, the third random vector s, and the first constraint matrix A;generating a second fingerprint using the second random vector r*, the fourth random vector s*, and the second constraint matrix A*; andsending, to a verifier computer, the first fingerprint, the second fingerprint, the first public vector b, the second public vector b*, and the commitment Cw, thereby enabling the verifier computer to verify an accuracy of an output value of the software program.

49. The method of claim 48, further comprising:generating a proof n using the first random vector r, the first constraint matrix A, the third random vector s, the first fingerprint, a commitment CA, the second random vector r*, the second constraint matrix A*, the third random vector s, and the second fingerprint; andsending, to the verifier computer, the proof rr, thereby enabling the verifier computer to verify the witness w satisfies the first constraint matrix A and the second constraint matrix A*.

50. The method of claim 48, wherein the second random vector r* is the first random vector r, and wherein the fourth random vector s* is the third random vector s.

51. The method of claim 48, further comprising:generating a first commitment to the first constraint matrix A and a second commitment to the second constraint matrix A*; andsending, to the verifier computer, the first commitment and the second commitment.

52. The method of claim 51, wherein the commitment Cw to the witness w, and the first commitment and the second commitment to the constraint matrices A and A*, are each generated by arranging underlying data into a matrix, encoding the matrix using an error-correcting code and constructing a Merkle tree over columns of the encoded matrix.

53. The method of claim 48, wherein generating the witness w includes:13179340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 obtaining decommitments for a set of sampled columns for the commitment Cw and from the commitments to A and A*; andsending the decommitments to the verifier computer.

54. The method of claim 48, wherein generating the witness w includes: for each memory access, adding a tuple (addr, val, counter) to the witness w; obtaining a set of random numbers; andgenerating auxiliary' lists R and W as linear combinations of the tuples and the set of random numbers.

55. The method of claim 48, further comprising:generating a code aggregate for performing a code check of an encoding of the witness w to obtain an encoded witness, wherein the code aggregate is generated as a linear combination of a random vector and values of the encoded witness, and wherein the code aggregate is configured to be checked by the verifier computer against one or more valid codewords; andsending the code aggregate to the verifier computer.

56. The method of claim 48, further comprising:generating a quadratic aggregate for performing a quadratic check of an encoding of the witness w, wherein the quadratic aggregate is generated by performing an element-wise operation of two rows of the encoded witness in combination with a reduction of a third row and a random vector; andsending the quadratic aggregate to the verifier computer.

57. The method of claim 48, further comprising:generating a linear aggregate for performing a linear check of an encoding of the witness w, wherein the linear aggregate is generated by combining aggregates derived from both (1) the constraint matrix A using the first random vector r and (2) the constraint matrix A* using the second random vector r*; andsending the linear aggregate to the verifier computer.

58. The method of claim 48, wherein the softw are program has dynamic flow' control betw een program blocks of the software program, the method further comprising:13279340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 providing, to the verifier computer, a proof that the prover computer has knowledge of the execution sequence of the program blocks.

59. A method performed by a verifier computer for verifying memory accesses made by a prover computer, the method comprising:receiving, from the prover computer, a proof comprising:a commitment Cw to a witness w, wherein the witness w comprises program inputs to a software program, intermediate values, memory access values, and one or more final values, wherein the software program has (1) a first set of constraints within program blocks and (2) a second set of constraints for memory accesses made by an execution sequence dependent on input values to the software program;a first fingerprint generated using a first constraint matrix A corresponding the first set of constraints and a second fingerprint generated using a second constraint matrix A* corresponding to the second set of constraints,a first public vector b and a second public vector b* generated by respective application of the constraint matrices A and A* to the witness w, and decommitments for a set of sampled columns from each commitment; receiving a first commitment CA to the first constraint matrix A and a second commitment CA* to the second constraint matrix A*;obtaining a first random vector r, a second random vector r*, a third random vector s, and a fourth random vector s*;verifying that the first fingerprint is consistent with the commitments by: confirming, using the first commitment CA and decommitments to the first commitment C. that the first fingerprint is obtained from applying the first random vector r and the third random vector s to the first constraint matrix A;verifying that the second fingerprint is consistent with the commitments by:confirming, using the second commitment CA* and decommitments to the second commitment CA*, that the second fingerprint is obtained from applying the second random vector r* and the fourth random vector s* to the second constraint matrix A; andverifying that the prover computer executed the software program using the input values based on the verifying.13379340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 60. The method of claim 59, further comprising:verifying, using decommitments, that the witness w includes, for each memory access, a tuple (addr, val, counter), and that values in auxiliary lists R and W, committed by the prover computer, are computed as linear combinations of the tuples and a set of random numbers.

61. The method of claim 60, wherein verifying the auxiliary lists R and W includes verifying that a first product of values in list R equals a second product of values in list W.

62. The method of claim 59, further comprising:performing, using the decommitments, a linear aggregate check by combining aggregates derived from both (1) the first commitment CA and the first random vector r and (2) the first commitment CA* and the second random vector r* in combination with commitment Cw; andverifying that the linear aggregate resolves to a predetermined value corresponding to a combination using both (1) the first random vector r, the first commitment CA, and a public vector b and (2) the second random vector r*, the second commitment CA*, and the public vector b*.

63. The method of claim 59, wherein the software program has dynamic flow control between program blocks of the software program, the method further comprising:verifying, using another proof received from the prover computer, that the prover computer has knowledge of the execution sequence of the program blocks.

64. A method performed by a prover computer for verifying memory¬ accesses made by the prover computer, the method comprising:obtaining a software program having dynamic flow control between program blocks of the software program, the software program having (1) a first set of constraints within program blocks and (2) a second set of constraints between invocations of the program blocks according an execution sequence dependent on input values to the software program;obtaining a first constraint matrix A corresponding to the first set of constraints and a second constraint matrix A’ corresponding to the second set of constraints;13479340501 V4PATENT Attorney Docket No. 116297-000210PC- 1492484 generating a first witness w using the software program and the first constraint matrix A;generating a second witness w’ using the software program and the second constraint matrix A’;obtaining a first random vector r and a second random vector r’; generating a total fingerprint using (a) a first product of the first random vector r and the first constraint matrix A and (b) a second product of the second random vector r’ and the second constraint matrix A’;generating a public vector b by application of the first constraint matrix A to witness w and application of the second constraint matrix A’ to witness wgenerating a first commitment Cw by applying a commit cryptographic function to the first witness w;generating a second commitment Cw by applying a commit cryptographic function to the second witness w andsending, to a verifier computer, the total fingerprint, the public vector b. the first commitment Cw, and the commitment Cwy thereby enabling the verifier computer to verify an accuracy of an output value of the software program.

65. A computer product comprising a non-transitory computer readable medium storing a plurality of instructions that, when executed, cause a computer system to perform the method of any one of the preceding claims.

66. A system comprising:the computer product of claim 65; andone or more processors configured to execute instructions stored on the computer readable medium.

67. A system comprising means for performing any of the above methods.

68. A system comprising one or more processors configured to perform any of the above methods.

69. A system comprising modules that respectively perform the steps of any of the above methods.13579340501 V4

Images