Computer-implemented system and method for serializing arithmetic circuits

Abstract

To provide a computer-implemented system and a method for serializing and deserializing arithmetic circuits.SOLUTION: A system is used by nodes of a block chain network to serialize and deserialize arithmetic circuits used in the execution of a computer program. The arithmetic circuit constructs a quadratic arithmetic problem that is compiled into a set of cryptographic routines for a client and a prover. The client and the prover use a protocol to delegate execution of the program to the prover in a way that allows the client to efficiently verify that the prover executes the program correctly. The arithmetic circuit also includes a symbol set that is compressed to generate a serialization circuit that includes a code set, where the symbol set is derivable from the code set in a lossless manner.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to techniques for reducing the data footprint used by computational circuits (e.g., when stored on disk or in memory), and more particularly to techniques for generating serialized circuits from computational services using the compression techniques described herein. The computational circuits may be compressed in a lossless manner to generate serialized circuits that can be used at a later point in time to generate the original circuits. The computational circuits may be used to generate programs, the execution of which may be delegated to one or more nodes in a distributed computing environment. A protocol may be used to ensure correct execution of the programs, where a first computer system delegates the execution of the program to a second computer system. The present invention is particularly, but not exclusively, suited for use in blockchain networks. [Background technology]

[0002] Herein, we use the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referenced herein for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are encompassed within the scope of the present invention. The term "Bitcoin" is considered herein to include any protocol derived from or a variation of the Bitcoin protocol.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and these blocks are strung together to create a permanent, immutable record of all transactions written to the blockchain since its origin. Transactions contain small programs known as scripts. Scripts embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be validated. Network nodes (miners) perform the work to ensure that invalid transactions are rejected by the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must (i) be validated by the first node that receives it, and if the transaction is valid, the node relays the transaction to other nodes in the network; (ii) be added to a new block constructed by miners; or (iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such solutions could take advantage of the benefits of blockchains (e.g., permanence, tamper-resistance of event records, decentralized processing, etc.) while further diversifying their uses.

[0006] One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." These are computer programs designed to automate the execution of the terms of machine-readable contracts or agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce outcomes, which in turn cause actions to be performed that depend on the outcomes. Summary of the Invention

[0007] It is therefore desirable to provide a method for lossless compression and serialization of operational circuits into a bitstream. Circuit serialization can provide various advantages in the context of circuit templates (e.g., reused circuits or subcircuits) or standard circuits that need to be stored and retrieved. In this way, encoding, computational entities can achieve performance improvements by eliminating the need to repeatedly instantiate circuits or subcircuits for multiple programs with shared circuits or subcircuits. Operational circuits can be efficiently compressed using entropy coding on the most frequently occurring elements in data structures, such as arithmetic operator types. Instructions for deserialization and decompression can also be embedded in the bitstream, allowing the original circuit to be losslessly reconstructed.

[0008] Such an improved solution is devised here.

[0009] Therefore, according to the present invention there is provided a system and / or method as defined in the accompanying claims.

[0010] According to the present invention, there is provided a computer-implemented method for a node of a blockchain network, the computer-implemented method being usable to reduce the data footprint of a computing circuit, the method comprising: removing a first subset of data fields of a set of data fields associated with an arithmetic circuit, the first subset of data fields being obtainable from a second subset of data fields of the set of data fields, the first subset and the second subset being disjoint sets; applying an entropy coding scheme to the second subset to generate a compression operation circuit; The resulting compressed operational circuitry may be stored as data in a volatile memory (e.g., RAM), a data storage system (e.g., a hard disk drive), or the like.

[0011] Preferably, the first subset of data fields includes an identifier of an input set to the arithmetic circuit, and the second subset includes the cardinality of the input set. The cardinality of a set (alternatively, the cardinal number of the set) may represent the number of inputs in the input set. Thus, the compressed circuit can be represented using fewer data bits than an uncompressed circuit.

[0012] Preferably, the first subset of data fields includes an identifier for a set of gate outputs of the arithmetic circuit, so that the compressed circuit can be represented using fewer data bits than an uncompressed circuit.

[0013] Preferably, the second subset includes a set of gates and the first subset includes a first input of a first gate of the set of gates. An order of the gates may be determined based on the order in which the gates are evaluated. Thus, the compressed circuit can be represented using fewer data bits than the uncompressed circuit.

[0014] Preferably, the second subset includes a set of gates, and the first subset includes the last output of the last gate of the set of gates. The order of the gates may be determined based on the order in which the gates are evaluated. Thus, the compressed circuit can be represented using fewer data bits than the uncompressed circuit.

[0015] applying the entropy coding scheme to the second subset, determining a symbol set from the second subset; assigning a corresponding code to each symbol of said symbol set; In many cases, the symbols of the symbol set will be larger in size (e.g., bit-wide representation) than their corresponding codes, but this need not be the case. For example, in a Huffman code, symbols that occur less frequently may have corresponding codes of larger size.

[0016] Preferably, a symbol of said symbol set is repeated at least twice in said second subset. A symbol may for example be a sequence of bits or operations that occurs more than once in a circuit. Preferably, the length of a code is inversely proportional to the frequency of the symbol corresponding to the code. Codes generated by entropy coding schemes may have variable lengths (e.g., some codes are larger in size than others), and shorter codes may be assigned to more frequently occurring symbols.

[0017] The code corresponding to the symbol is generated according to an optimal prefix code, such as a Huffman code.

[0018] Preferably, the method further comprises the step of generating a serialization circuit; The serialization circuit includes a result based at least in part on applying the entropy coding scheme to the second subset, and a header data structure, which may include a version number and a total number of wires.

[0019] Preferably, the header data structure further includes a bit width that can be used to enable optimization of performance based at least in part on a target architecture.

[0020] Preferably, the version number indicates an encoding scheme that can be used to determine the symbols from the code.

[0021] Advantageously, unlike known interpreters and compilers, the present invention provides an architecture-independent solution. Moreover, it does not require the use of a virtual machine (VM) to enable execution. An architecture-independent circuit may refer to a representation of a circuit that is not configured to operate or be used with a particular hardware or software architecture or platform. This is in contrast to conventional compilers and interpreters, each of which is architecture-specific or requires the use of a VM.

[0022] It is also desirable to provide a system including a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform a method as claimed in any of the claims.

[0023] It is also desirable to provide a non-transitory computer readable storage medium having stored thereon executable instructions which, upon execution by one or more processors of a computer system, cause the computer system to perform a method as recited in any of the claims. [Brief explanation of the drawings]

[0024] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Figure 1] 1 shows an arithmetic circuit and a serialization circuit that can be used to generate the arithmetic circuit. [Figure 2] FIG. 1 is a flow diagram of a verifiable computation and associated actors in accordance with one embodiment of the present disclosure. [Figure 3] 1 illustrates an example of a workflow from domain-specific language (DSL) code to quadratic arithmetic program (QAP), according to one embodiment of the present disclosure. [Figure 4] 1 illustrates a process for reducing the size of an arithmetic circuit, according to one embodiment. [Figure 5] 1 shows a diagram of an arithmetic circuit and corresponding serialization circuit, according to one embodiment. [Figure 6] 1 illustrates a diagram of circuit serialization, according to at least one embodiment. [Figure 7] 1 illustrates a computing device that can be used to implement at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0025] The following provides a description of how the present invention may operate in practice according to one embodiment. The present invention may be implemented in the context of a distributed computing environment, where a first computing entity utilizes computational circuitry to generate a program whose execution can be delegated to a computing entity (e.g., a node in a blockchain network) in the distributed computing environment. Furthermore, correct execution of the program is computationally verifiable. Thus, a client computing entity that delegates execution of a program generated based at least in part on the computational circuitry can verify that the program was correctly executed by a working computing entity. In this manner, various efficiencies for distributed computing environments may be realized, including allowing a client computing entity to delegate and verify execution of a program to a computer system under the control of another entity.

[0026] As described in more detail below, possible implementations are described for compressing and serializing an operational circuit into a binary data stream. The binary data stream is de-serialized and decompressed in a lossless manner. Various advantages of serializing a circuit include reducing the data storage footprint of the circuit (e.g., by storing the serialized circuit instead of the operational circuit). For example, in the context of a blockchain network, the operational circuit or a program derived from the operation may be at least partially encoded in the blockchain network's ledger. Reducing the data storage footprint of the operational circuit using the techniques described herein may reduce the amount of data stored in the blockchain ledger. Because the blockchain ledger may be replicated by some or all nodes in the blockchain network, even small reductions in the data storage footprint of data stored in the blockchain are highly valued.

[0027] Certain structures or building blocks can be used to aid in this transformation. In one or more embodiments, this representation is considered the first step in building a comprehensive pipeline that can provide distributed, verifiable computation. The building blocks presented in this example are not intended to be a comprehensive list of all possible high-level language constructs addressed by embodiments of the present invention. Furthermore, alternative implementations of the presented examples may be provided; these are within the purview of those skilled in the art.

[0028] We provide an illustrative embodiment of the invention. Importantly, however, this is only one example of an application in which the invention can be used. Those skilled in the art will appreciate that the invention can be advantageously used in other contexts and applications.

[0029] In our example, we consider a protocol that allows users to generate applications using a Domain Specific Language (DSL). Once an application is generated, its execution can be delegated to an untrusted party (called a "worker" or "prover"), while its correctness can be publicly verified. The protocol makes use of cryptographic primitives that guarantee: Completeness, i.e., if the protocol is followed correctly, an honest verifier is confident of the validity of the output. Soundness, i.e., a dishonest prover cannot convince an honest verifier of the authenticity of the output. Zero-knowledge, meaning that a dishonest prover knows nothing other than the validity of the output.

[0030] The advantages of the protocol are: No communication between participants is required, preventing man-in-the-middle attacks. The use of blockchain technology makes it difficult for malicious nodes to tamper with data. · Trusted third parties such as trusted hardware devices are avoided. Validating a contract does not mean re-running the code. Computations are not replicated by all nodes in the network. Instead, proofs of honest execution are stored on the public blockchain and are used only for validation purposes.

[0031] Such systems can handle a variety of applications corresponding to different kinds of tasks and products. Due to its decentralized and distributed nature, the (Bitcoin) blockchain provides a well-suited environment for resolving agreements between two (or more) parties.

[0032] Such systems require providing and facilitating programmability in decentralized cryptocurrency systems. However, smart contract programming has traditionally been recognized as an error-prone process. See Delmolino, K., et al. (2015). Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab, and Juels, A., et al. (2013). The Ring of Gyges: Using Smart Contracts for Crime.

[0033] It would therefore be advantageous for a DSL to be available to programmers that makes applications easier to write and read, thus reducing errors and saving time, effort, cost, and resources during the programming process. Ideally, non-expert programmers would be able to write a variety of applications without having to implement cryptographic methods. Instead, a compiler / interpreter would automatically compile source code into cryptographic protocols between the user and the blockchain. These are among the technical problems solved by the present invention.

[0034] FIG. 1 is an illustration 100 of one embodiment that can be implemented according to the present disclosure. The techniques described herein may be used to serialize and de-serialize arithmetic circuits used in the execution of a computer program. The arithmetic circuits may be used to construct a quadratic arithmetic problem (QAP) that is compiled into a set of cryptographic routines for a client (e.g., key generation and verification) and a prover (e.g., computation and proof generation), according to one embodiment. The client and prover may use a protocol to delegate program execution to the prover in a manner that allows the client to efficiently verify that the prover executed the program correctly. Serialized circuits may be used to improve the operation of a computer system by reducing the required computational resources (e.g., hard disk space) associated with the arithmetic circuits. In one embodiment, the arithmetic circuits contain information represented as a set of symbols (e.g., arithmetic gates and values) that are compressed to generate a serialized circuit that includes the code set, where the symbol set is derivable from the code set in a lossless manner. The transmission of compression circuitry may improve the effective data transmission bandwidth of a computer system by allowing more circuitry to be transmitted. For example, if the compression circuitry reduces the size of the computation circuitry by 50%, the effective data transmission bandwidth may double. This is because at most twice as many compressed computation circuits can be transmitted using the same number of bytes (note that the actual data transmission bandwidth improvement may be less than two due to data overhead such as uncompressed packet headers). Reducing the data footprint of the computation circuitry may reduce the computer hardware requirements associated with using the computation circuitry. For example, reducing the amount of short-term memory (e.g., RAM) data storage and / or data bandwidth utilized by a computer system that uses, stores, or otherwise interacts with the circuitry described herein. The transmission of compression circuitry may improve the effective data transmission bandwidth of a computer system by allowing more circuitry to be transmitted.For example, if a compression circuit reduces the size of an arithmetic circuit by 50%, the effective data transmission bandwidth may double, since at most twice as many compressed arithmetic circuits can be transmitted using the same number of bytes (note that the actual data transmission bandwidth improvement may be less than two due to data overhead such as uncompressed packet headers). Reducing the data footprint of an arithmetic circuit may reduce the computer hardware requirements associated with using the arithmetic circuit, for example, reducing the amount of short-term memory (e.g., RAM) data storage and / or data bandwidth utilized by a computer system that uses, stores, or otherwise interacts with the circuits described herein.

[0035] Generally, an operational circuit C includes wires that carry values ​​from field F and connect logic and / or operational gates. In one embodiment, circuit C can be represented by a set of data fields including operational gates, input wires, and output wires. The circuit may further include a header containing information such as a version number, a total number of wires, and a bit width n bits, which allows for optimization of execution depending on the target execution environment (e.g., processor architecture). Compression of an operational circuit may be achieved by removing determinable data fields from other fields, applying an entropy coding scheme, or a combination thereof. Various types of simplification rules may be used as part of the compression routine based on the format in which the operational circuit is encoded. For example, some information may not be required. For example, wire identifiers for inputs, wire identifiers for output gates, the first input of the first gate, and the final output wire identifier may be compressed (e.g., not explicitly encoded as part of the serialized circuit), or any combination thereof.

[0036] In various embodiments, entropy coding or an encoding scheme is applied to the operational circuitry or portions thereof (e.g., based on the simplification rules described above). Entropy coding may be used to generate a variable-length code table for serializing the source symbols. Huffman coding may be used to generate a code table in which more frequently occurring source symbols are encoded using shorter codes and less frequently occurring source symbols are encoded using longer codes, where the length of the code may be inversely proportional to the frequency of occurrence of the source symbol or sequence. Using these techniques, the operational circuitry can be compressed into a serialized circuitry that requires fewer computational resources for storage in long-term data storage media (e.g., hard disk drives) and short-term data storage media (e.g., random access memory).

[0037] As described above, Huffman codes may be used to generate code tables. Huffman codes represent a particular type of optimal prefix code that can be used to achieve lossless data compression. The output from a Huffman algorithm may be a variable-length code table (e.g., a codebook) for encoding source symbols, such as characters or commands in a file. In one embodiment, the algorithm derives the table from estimated or measured occurrence probabilities or frequencies (weights) for each possible value from the source symbols. Typically, more common symbols are represented using fewer bits than less common symbols. In one embodiment, Huffman coding can be efficiently implemented to find codes in time linear with the number of input weights, where the input weights are in sorted order. This strategy may be optimal among methods for encoding symbols separately. Huffman coding may use a particular method for selecting a representation for each symbol, resulting in a prefix code. That is, a bit string representing any particular symbol is never a prefix of a bit string representing any other symbol.

[0038] A set of symbols {a0, a1,..., a n-1}, and their weights {p0,p1,...,p n-1}, the tree with the minimum weight path length from the root is requested. The output code C(P) = {c0, c1, ..., c n-1} is a tuple of binary codewords with minimum weight path length L(C).

[0039] Each symbol a has a non-null probability as defined by Shannon's source coding theorem. i The information content h (unit: bits) of i )=log2(1 / p i ) The entropy H (unit: bit) is the non-zero probability p i All symbols a with i is a weighted sum over:

number

[0040] Entropy is a measure of the theoretically possible minimum codeword length for a given alphabet with associated weight. Typically, Huffman codes do not need to be unique. The set of Huffman codes for a given probability distribution is a non-empty subset of codes that minimizes L(C) for that probability distribution.

[0041] The serialization circuit can be used to derive the original computational circuit using an expansion or decompression routine in a lossless manner. Note that in this context, "lossless" refers to a type of compression algorithm in which the source data is fully derivable from the compressed data. In the context of digital compression, lossless compression may refer to each bit of the source bitstream being derivable from the compressed data comprising the symbol set. Conversely, lossy compression may refer to a type of compression algorithm in which the compressed data does not allow each bit of the source bitstream to be derived from the compressed data. An example of lossy compression is the MP3 audio encoding format.

[0042] 2 illustrates an example flow diagram 200 of verifiable computation and associated actors, in accordance with one embodiment of the present disclosure. As shown in FIG. 2, verifiable computation diagram 200 may include a client node 240, a worker (e.g., prover) node 250, and a verifier node 260, which are involved in performing steps of a verifiable computation protocol in accordance with one embodiment of the present disclosure. In an embodiment, one or more of client node 240, worker node 250, or verifier node 260 are nodes in a blockchain network.

[0043] In one embodiment, the configuration phase includes writing the contract in a domain-specific language (DSL). The interpreter, which may be a client node 240, takes source code as input and generates an operation circuit C composed of "wires" that carry data from fields F and connect to add and multiply gates. The operation circuit itself may be a DAG rather than a hardware circuit. Wires may be edges in the DAG. However, it is contemplated that the operation circuit may be implemented with a physical circuit having wires and logic gates. At 202, the client node 240 compiles a computation P written in GPL into the operation circuit C. In an embodiment, the client node 240 provides the operation circuit C and the input x to the worker node 250.

[0044] From the circuit C, one embodiment of the present disclosure can generate a quadratic program Q that includes a set of polynomials that provides a complete description of the original circuit C. Public parameters may then be generated to be used by the worker node 250 and the verifier node 260 when executing and verifying the quadratic program.

[0045] At 204, a worker node 250 executes a circuit C or a secondary program Q for input x and claims that the output is y. In some embodiments, the worker node 250 (i.e., the prover) is expected to obtain a valid transcript for {C, x, y}. Thus, at 206, the worker node 250 encodes the transcript. In some examples, a valid transcript {C, x, y} is an assignment of values ​​to circuit wires, such that the value assigned to the input wire is x, the intermediate values ​​correspond to the correct operation of each gate in C, and the value assigned to the output wire is y. If the claimed output is incorrect (i.e., y ≠ P(x)), then there is no valid transcript for {C, x, y}.

[0046] At 208, the worker node 250 provides the output y to the client node 240. In an embodiment, a public evaluation key EK and a public verification key VK are derived using a secret value s selected by or from the client node 240. In an embodiment, the worker node 250 uses these public keys to evaluate a calculation for a particular input x. In an embodiment, the output y, the values ​​of the internal circuit wires, and EK are used to generate a proof-of-correctness π. The proof π is stored on the blockchain and verified by multiple parties (e.g., the verifier node 260), without the worker node 250 having to interact with multiple parties individually. In this way, at 210, the verifier node 260 can verify the payment transaction using the public verification key VK and the proof π, thereby validating the contract.

[0047] Verifiable computation is a technique that enables the generation of proofs of computation. In one embodiment, such techniques are utilized by a client to delegate the evaluation of a function f for an input x to another computational entity, referred to herein as a worker. In some instances, the client is computationally constrained and the client is unable to perform the evaluation of the function (e.g., the expected execution time of the computation using the computational resources available to the client exceeds a maximum allowed threshold). However, such is not required, and the client may typically delegate, so to speak, the evaluation of the function f for an input x based on any suitable criteria, such as computation execution time, computational cost (e.g., the economic cost of allocating computational resources to perform the evaluation of the function), etc.

[0048] In one embodiment, a worker is any suitable computational entity, such as a blockchain node, as described in more detail elsewhere in this disclosure. In one embodiment, a worker (e.g., a blockchain node) evaluates a function f for an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by other computational entities, such as the client and / or other nodes in the blockchain network. The proof, which may also be referred to as an argument, can be verified faster than performing the actual computation by verifying the correctness of the proof instead of recalculating the function f for the input x to determine the correctness of the output generated by the worker, thus reducing computational overhead (e.g., reducing power overhead and costs associated with powering and operating computational resources). In zero-knowledge verifiable computation, a worker provides a client with an attestation that the worker knows an input with certain properties.

[0049] An efficient variant of zero-knowledge proofs of knowledge is zk-SNARKs (Succinct Non-interactive ARguments of Knowledge). In one embodiment, a full pairing based on zk-SNARKs involves the worker computing a number of group elements using a generic group operation, and the verifier checking the proof using a formula for the product of a number of pairings. In one embodiment, linear interactive proofs work over finite fields, and the worker's and verifier's messages contain vectors of field elements, encode, reference, or otherwise contain information usable to determine the field elements.

[0050] In one embodiment, the systems and methods described herein allow miners (e.g., nodes) of a blockchain to perform a computation (e.g., evaluating a function f for an input x) once and generate a proof that can be used to verify the correctness of the output, where evaluating the correctness of the proof is computationally cheaper than evaluating a function. In this context, the cost of operations and tasks (i.e., how expensive) may represent the computational complexity of performing the operation or task. In one embodiment, computational complexity represents the average or worst-case computational cost when performing a sorting algorithm. For example, a heapsort algorithm or a quicksort algorithm, both of which have an average computational cost of O(n log n), but quicksort has a worst-case computational cost of O(n log n). 2), with heapsort having a worst-case computational cost of O(n log n). In one embodiment, the average computational cost and / or worst-case computational cost for evaluating a function f for an input x is worse than that for evaluating the correctness of a proof. Thus, use of the systems and methods described herein can be highly advantageous, e.g., enabling more computationally expensive contracts to be executed, e.g., contracts that do not proportionally increase the time required to verify a blockchain. Further benefits can include reduced power consumption of the verifier system, thereby improving the efficiency of the verifier computer system and reducing the energy costs associated with operating the verifier computer system when evaluating the correctness of a proof.

[0051] In one embodiment, the verification key V K or parts thereof can be extracted from the public parameters generated in the setup phase of the zero-knowledge protocol and, together with the proof π and the input / output data, can be used to verify the computation of the declared proof of correctness provided by the worker. For example, as described above and below, suppose a lock script contains a verification key V K Systems and methods that enable secure protection of the proof π from modification and check the validity of the proof π enable the execution of zero-knowledge protocols on the blockchain during transaction verification. Accordingly, the present disclosure proposes systems and methods that perform the verification phase using a blockchain script (e.g., in a Bitcoin-based network) that stores elements used in the verification of a computation.

[0052] Figure 3 illustrates an example workflow 300 from domain-specific language (DSL) code to quadratic arithmetic program (QAP), according to one embodiment of the present disclosure. Specifically, Figure 3 illustrates DSL code 302 being converted by converter 204 into GPL code 306. A GPL precompiler 308 (also known as a preprocessor) incorporates external libraries 310 referenced by GPL code 306 to generate GPL preprocessed code 312. GPL preprocessed code 312 is converted into arithmetic circuit 314. Arithmetic circuit 314 is optimized to generate reduced arithmetic circuit 316, which is compressed to generate serialization circuit 320. From serialization circuit 320, a QAP polynomial 318 is derived.

[0053] In one embodiment, the domain-specific language (DSL) code 302 is an application written in a formal language with precise semantics. In one embodiment, the code 302 includes a set of conditions, and the outcome of the DSL code 302 depends on the satisfaction of the set of conditions. One example of an application (e.g., a smart contract) is an insurance contract that takes as input the insured's insurance premium and a possible compensation for the insured by the insurance company. If the insured suffers a loss during the term of the smart contract (e.g., the first condition is satisfied), execution of the smart contract distributes the premium to the insurance company and distributes compensation for the loss to the insured. On the other hand, if the insured does not suffer a loss during the term of the smart contract, execution of the smart contract distributes the premium to the insurance company and distributes a possible compensation to the insurance company.

[0054] In one embodiment, converter 304 is a software program that, as a result of execution, receives a set of conditions written in a DSL, such as DSL code 302, and converts the DSL code into GPL source code, such as GPL code 306. In one embodiment, GPL code 306 is a GPL program, such as a C++ program, that includes the code defined in DSL code 302. In some instances, a general-purpose programming language or language (GPL), as opposed to a DSL, is broadly applicable. Examples of general-purpose programming languages ​​include Ada, ALGOL, assembly language, BASIC, Boo, C, C++, C#, Clojure, COBOL, Crystal, D, Dart, Elixir, Erlang, F#, Fortran, Go, Harbour, Haskell, Idris, Java, JavaScript, Julia, Lisp, Lua, Modula-2, NPL, Oberon, Objective-C, Pascal, Perl, PHP, Pike, PL / I, Python, Ring, RPG, Ruby, Rust, Scala, Simula, Swift, and Tcl. C++ may be referenced in embodiments of the present disclosure and is a general-purpose programming language that has imperative, object-oriented, and general-purpose programming capabilities but also provides functionality for low-level memory manipulation. It should be noted that in the context of Figure 3, "code" may alternatively refer to executable code (e.g., object code), source code, both, or a combination thereof, depending on the context being described.

[0055] In one embodiment, GPL precompiler 308 is a computer-executable program that processes GPL code 306 and required external libraries 310 to generate standalone GPL code 306 preprocessor code 312. In an embodiment, GPL precompiler 308 evaluates constant expressions and register symbols found in GPL code 306.

[0056] In one embodiment, external library 310 is a collection of pre-written subroutines, functions, classes, containers, values, and / or variable types that are utilized by GPL code 306 through calls. For example, by calling external library 310, GPL code 306 obtains the functionality of the library without having to implement the functionality itself.

[0057] In one embodiment, GPL preprocessing code 312 includes a set of expressions and operators. The operators may include arithmetic operators (e.g., addition (+), multiplication (*), etc.), comparison operators (e.g., less than (<), equal (=), greater than or equal (≧), etc.), conditional statements (e.g., if-then (?, :)), or logical operators (e.g., AND (&&), OR (||), NOT (!), XOR (+ in a circle), etc.). In some embodiments, a main function is generated to have a predetermined name and format.

[0058] In one embodiment, the computation circuit 314 is a DAG for a set of variables. In one embodiment, all nodes of a 0 indegree DAG are connected to a variable (e.g., x i ), and all other nodes in the DAG are sum gates (+) or product gates (×). In embodiments, all gates (nodes) have an outdegree of 1, and therefore the basic graph is a directed tree. In embodiments, the computation circuit 314 has two measures of complexity: size and depth. In some examples, the "size" of the computation circuit is based on the number of gates in the computation circuit 314. In some examples, the "depth" of the computation circuit is based on the length of the longest directed path in the computation circuit.

[0059] In one embodiment, the reduced arithmetic circuit 316 is a reduced or minimal directed acyclical graph (DAG) that can be used to determine the outcome of a set of conditions, as specified in the DSL code 302, given a set of inputs. In some embodiments, the reduced arithmetic circuit 316 is a minimized (i.e., reduced to a minimum degree) arithmetic circuit. In some embodiments, the optimal arithmetic circuit may not necessarily be the smallest arithmetic circuit (e.g., a particular larger arithmetic circuit may be evaluated to be faster than a larger arithmetic circuit depending on the number and type of arithmetic operations in the circuit). Also, in such embodiments, the reduced arithmetic circuit 316 is optimized (e.g., for maximum speed, less memory usage, maximum efficient processor utilization, etc.), but is not necessarily a minimized arithmetic circuit. The reduced arithmetic circuit 316 may be generated using techniques described in UK Patent Application No. GB1718505.9.

[0060] An arithmetic circuit, such as the reduced arithmetic circuit 316, may be compressed according to the techniques described herein to generate a serialized circuit 320. The serialized circuit 320 may be used for code templates or standard applications that need to be stored and retrieved. By utilizing the serialization circuit 320, a party can eliminate the need to instantiate a circuit from the GPL each time a new application is created, thereby improving the efficiency of protocols in which clients and provers reuse specific code templates or portions of such applications. The serialization circuit 320 may be generated using entropy coding of the most frequently occurring elements in a data structure, such as arithmetic operator types. Instructions for deserialization and decompression (e.g., a codebook mapping serialized codes to source symbols) may be embedded in the serialized bitstream, allowing a recipient of the serialization circuit to reconstruct the source circuit.

[0061] In one embodiment, the QAP polynomial 318 is one or more expressions with variables and coefficients expressed in a mathematical formula that provides a complete description of the original computational circuit (e.g., computational circuit 314 of FIG. 4). In an embodiment, the polynomials in the QAP polynomial are defined in terms of their evaluation at the root of the computational circuit, as described, for example, in Gennaro, R. et al., Quadratic Span Programs and Succint NIZKs without PCPs (2013). In an embodiment, the QAP polynomial is encoded within a locking script of a blockchain transaction as a representation of a smart contract. In an embodiment, the locking script, when executed, receives a set of parameter values ​​(e.g., as a result of executing the locking script). The set of parameter values ​​are input as variables into the QAP polynomial to determine the outcome of the smart contract.

[0062] In an embodiment, GPL polynomial 308 generates GPL preprocessing code 312, which may be an arithmetic circuit with arithmetic gates. Note, however, that complex arithmetic circuits also embed logic submodules with conditionals and flow control statements.

[0063] FIG. 4 illustrates a process 400 for reducing the size of an operational circuit. In one embodiment, the operational circuit has a header associated with or encoded by the body. In one embodiment, the body of the circuit includes gate wire identifiers and gate types. The header may include information, such as metadata, associated with the body. In one embodiment, the operational circuit is converted into a binary stream of data characterized by a measure of entropy that approaches theoretical limits as defined by Shannon's source coding theory. In some examples, the serialized circuit represents the binary data stream and has a higher entropy value than the operational circuit. "Entropy" as used in this disclosure refers to entropy according to principles of information theory as described in Shannon, C., A Mathematical Theory of Communication (1955).

[0064] Process 400 may be performed by any suitable computer system, such as that described in connection with FIG. 2. The circuit may be compressed and optimized by another computing entity, such as the client described in FIG. 2, or a worker delegated the task of serializing the computational circuit. Given a generic circuit, the system identifies a list of global parameters. The sender and receiver of the serialization scheme must pass the following information: a version number, which in some embodiments may include additional information such as the encoding scheme or codebook used to serialize the circuit; a total number of wires, N; and a bit width, n bit and combinations thereof; may be interchanged.

[0065] In one embodiment, a system implementing process 400 includes a memory storing executable code that, when executed by one or more processors, causes the system to obtain 402 an operational circuit that can be represented by a set of data fields. In one embodiment, the set of data fields includes gates or operations and wires representing inputs and outputs. Note that a wire can simultaneously be an output of one gate and an input of another gate. A wire can be both an input and an output to a gate. The system may use simplification rules to remove data fields of the arithmetic circuit 404. The simplification rules may be used to remove a first subset of the data fields of the arithmetic circuit that are derivable from the remaining data fields, which may be referred to as a second subset of the data fields of the arithmetic circuit. The first and second subsets may be disjoint sets with no common elements based on the characteristics of the data fields of the arithmetic circuit. Each data field of the arithmetic circuit may be classified as a calculated field or a stored field. The calculated fields are assigned to the first subset, and the stored fields are assigned to the second subset. There may be cases where a data field cannot be characterized as both a calculated field and a stored field simultaneously. In one embodiment, a calculated field represents a data field that cannot be derived from one or more stored fields. In general, this concept may be explained using an illustrative example. If there are data fields that store a start time, an end time, and a time interval duration, respectively, the end time may be identified as a calculated field, and the start time and duration are stored fields. This is because the end time can be determined from one or more stored fields (e.g., EndTime=StartTime+Duration). Of course, in this example, duration could be represented as a calculated field, and the start time and end time could be represented as stored fields (e.g., Duration=EndTime-StartTime). As noted above, any of the fields can be both a calculated field and a stored field simultaneously, rather than being one or the other based on representations that may be selected programmatically (e.g., selected by execution of an algorithm) or by a user.

[0066] In one embodiment, the system identifies one or more data fields of the set of data fields based at least in part on determining whether the data field is derivable from other data fields of the set. As a first example, starting with id0, the first n inputsSince n identifiers are reserved for inputs, the simplification rules may cause the wire identifiers of the inputs to be removed. inputs is from id0 to id ninputs-1 is sufficient to determine that the identifiers up to are input identifiers. The inputs may be automatically incremented so that the first input is assigned to id0, the second to id1, and so on.

[0067] There may be additional simplification rules. As a second example, id inputs Starting from , the wire identifiers of output gates may be removed so that all wire identifiers of output gates are automatically incremented. For example, if a circuit contains only two gates, the output of the first gate is id inputs and the output of the second gate is id inputs+1 The order of the gates may be a sequential order of arithmetic operations as specified by an interpreter, such as the interpreter described in accordance with FIG. 2. The interpreter may be implemented using techniques described in UK Patent Application No. GB1801753.3. As a third example, the first input of the first gate (e.g., with an order determined by the interpreter) may be assigned id 0 by default. As a fourth example, given a total number of wires N, the first input of the first gate may be assigned id 1 by default. N-1 is an output wire, so the last output wire identifier is not needed. An embodiment may implement none, all, or some of the exemplary simplification rules described. FIG. 5 shows an example of an operational circuit that applies the described simplification rules. It should be noted that the simplification rules as described above are merely examples, and various embodiments may implement some or all of the simplification rules, and other simplification rules may be known to those skilled in the art.

[0068] Entropy coding may be applied to the arithmetic circuit to reduce the amount of data required to encode a heavily repeated portion of the arithmetic circuit (e.g., arithmetic operations). In some examples, the system may determine a codebook that maps data in a set of data fields to a set of codes 406. Huffman coding may be used to generate a variable-length code table for serialization of source symbols. Generally speaking, given a set of M different source symbols that may include the types of operations defined for the arithmetic circuit, for each symbol i, 0 ≦ i < M, a probability p i is specified. In one embodiment, a binary tree is generated by taking the two least likely symbols and combining them to form a new symbol. For example, p a and p b are the two least likely symbols, they form a new symbol p ab , and p ab = p a + p b . This process is repeated until only one symbol remains. The tree may be read backwards while assigning different codes to different branches. The codes may be assigned according to the Huffman coding scheme. It should be noted that the resulting tree may have leaf nodes with different tree depths. In such examples, generally, symbols with higher probabilities are closer to the root than symbols with relatively lower probabilities. Thus, symbols that occur more frequently can be encoded using fewer bits than symbols that occur less frequently. In other words, in one embodiment, the length of the code is inversely proportional to the frequency of the symbol.

[0069] The binary tree and symbol codes may vary according to the value of M and the individual symbol probabilities p i , 0 ≦ i < M. For example, if M is a power of 2, p i = 2p i+1 , and p M-2 = 2p M-1 = 2p M+1 , the total number of bits S required to encode the arithmetic circuitops is as follows:

Number

[0070] Therefore, the compression ratio R for encoding the arithmetic circuit is as follows:

Number

[0071] Due to the linearity between p and ω, that is, ω M-2 = ω M-1 = 1, and ω i = 2ω i+1 , from 0 ≤ i < M - 1, the above equation can be simplified as follows:

Number

[0072] When M > 5, the normalized ratio R / n0 is less than 1. That is, in fact, it is not compressed with respect to n0. The larger M is, the larger the compression ratio is. With the above method, the arithmetic circuit can be compressed 408. In one embodiment, the compression circuit is a serialized bit stream of data encoding the circuit representation (e.g., the simplified and / or encoded version of the original circuit as described above). In one embodiment, the serialization circuit includes a body encoding the circuit representation and a header including one or more of the following: version number, total number of wires, bit width n bit , codebook, or any combination thereof. In some examples, the codebook is selected from a plurality of codebooks, and the appropriate codebook can be selected based on querying the version number. For example, the first codebook in the list of codebooks corresponds to version 1, the second codebook in the list corresponds to version 2, and so on. The codebook may be pre-generated in one embodiment.

[0073] 5 shows a diagram 500 of an arithmetic circuit 502 and a serialization circuit 504 according to one embodiment. The serialization circuit 504 shown in FIG. 5 may be a compressed version of the arithmetic circuit generated using a set of simplification rules. A lossless compression routine may be applied to the arithmetic circuit 502 to generate the serialization circuit 504, and a lossy decompression routine may be applied to the serialization circuit 504 to perfectly (e.g., bit-for-bit accurate) reproduce the serialization circuit 504.

[0074] As shown in FIG. 5, an exemplary operation circuit may include header metadata including version information, a field N indicating the number of wires, and identifiers for the circuit's inputs (0, 1, 2) and outputs (4, 5). It should be noted that some wires may not be inputs or outputs of the circuit (e.g., they may be wires that are intermediate inputs or outputs of the circuit). The information in the header need not be encoded at the beginning of the data structure, nor need it be encoded contiguously; output data is encoded at the end of the data structure, as shown in operation circuit 502 of FIG. 5. The operation circuit further encodes data fields for the gate, followed by a set of inputs and outputs. For example, as shown in operation circuit 502, ADD 0 1 3 represents an addition gate that adds the values ​​of the wires corresponding to identifiers id0 and id1 to generate an output on the wire corresponding to identifier id3.

[0075] As a second example, MUL 1 2 4 represents a multiplication gate that multiplies the values ​​on the wires corresponding to identifiers id1 and id2 to produce a product on the wire corresponding to identifier id4. The uncompressed arithmetic circuit 502 may therefore be represented as follows: VERSION 1 N6 IN 0 1 2 ADD 0 1 3 MUL 1 2 4 MUL 3 4 5 OUT 4 5

[0076] The arithmetic circuit 502 may be compressed into the serialized circuit 504 by applying simplification rules. A first simplification rule may be that if the number of inputs is encoded, then the wire identifier of the input is not necessary. Alternatively, the number of inputs may represent the cardinal number or cardinality of the input set. For example, the inputs (0,1,2) above have a cardinality of 2. Therefore, according to this simplification rule, the arithmetic circuit is compressed as follows: VERSION 1 N6 2 ADD 0 1 3 MUL 1 2 4 MUL 3 4 5 OUT 4 5

[0077] The second simplification rule is that the wire identifier for an output gate is n ininputs Therefore, according to the first and second simplification rules, the arithmetic circuit is compressed as follows: VERSION 1 N6 ADD 0 1 MUL 1 2 MUL 3 4 4 5

[0078] A third simplification rule may be that the first input to the first gate is not needed because the first identifier is assigned to that wire by default. Thus, according to the first, second and third simplification rules, the arithmetic circuit is compressed to: VERSION 1 N6 2 ADD 1 MUL 1 2 MUL 3 4 4 5

[0079] A fourth simplification rule may be that the last output wire identifier is not needed because it is defined to be an output wire by default. Thus, according to the first, second, third and fourth simplification rules, the arithmetic circuit is compressed to: VERSION 1 N6 2 ADD 1 MUL 1 2 MUL 3 4 4

[0080] It should be noted that the serialization circuit 504 may be further compressed, for example, by using entropy coding techniques.

[0081] 6 shows a circuit serialization diagram 600. The top input arithmetic circuit 602 is represented in ASCII. The first serialization circuit 604 is, in one embodiment, w =32, and the second serialization circuit 606 is the result of applying a serialization technique where n w = 8. The solid squares represent unused bits, which in one embodiment are padded with zeros.

[0082] In one embodiment, rules for simplification of data fields and entropy coding of arithmetic operations are utilized to construct an efficient serialization of an operational circuit. The header of the data structure may include a version byte, an integer value for the number of inputs / outputs (e.g., signed or unsigned), a number of wires, a list of output wire identifiers except for the last one (the last output wire identifier may be omitted while still achieving lossless compression, as described in connection with the simplification rules), and combinations thereof. In one embodiment, the version byte embeds the configuration that is valid for a particular circuit. A receiver of a serialized circuit may use the version byte to determine how to deserialize the serialized circuit. For example, a version byte (or bytes) may be structured as follows: Bits 0 and 1: Instruction set. The instruction set defines the type of instructions that are defined for the circuit. Addition and multiplication are always defined, but addition operators may be defined according to the circuit function. For example, wire compression, wire expansion, equal to 0 and compare to 0 operators. Thus, the following constructs can be introduced: 00: An instruction set with M=2 types of operators. 01: An instruction set with M=4 types of operators. 10: An instruction set with M=8 types of operators. 11: An instruction set with M=16 types of operators.

[0083] Bits 2, 3 and 4: Number of inputs / outputs. This field specifies the bit width of the fields containing the number of inputs and the number of outputs. For example, the following configurations can be implemented: 000: 2-bit input, 2-bit output 001: 2-bit input, 4-bit output 010: 2-bit input, 8-bit output 011: 4-bit input, 2-bit output 100: 4-bit input, 4-bit output 101: 4-bit input, 8-bit output 110: 8-bit input, 4-bit output 111: 8-bit input, 8-bit output

[0084] Bits 5 and 6: Wire identifier width n w (Wire identifiers width). Depending on the number N of wires in the circuit N, a certain number of bits is allocated to encode the wire identifier. For example, the following configuration can be implemented: 00: 8-bit coded wire identifier and N 01: 16-bit coded wire identifier and N 10: 32-bit coded wire identifier and N 11: 64-bit encoded wire identifier and N

[0085] Bit 7: Bit width n bit (Bit-width). Circuits can be optimized for specific computer architectures. For example, the following configurations can be implemented: 0:32-bit architecture 1: 64-bit architecture

[0086] In some embodiments, more bytes can be reserved for version information, allowing for the definition of additional configurations and fields.

[0087] The instruction set field may be used to select the correct dictionary for entropy coding. If a specific number of dictionaries is predefined, the correct dictionary does not need to be coded in the circuit. For example, if M is a power of 2, a scheme with the above symbol probabilities can be defined. Thus, given a specific instruction set, a specific dictionary is read.

[0088] In one embodiment, the body of the circuit includes a serialized wire identifier and gate type for the input gate. In one embodiment, the size of the wire identifier is predefined and encoded into an integer number of bytes. As a result, the wire identifier is encoded first, and then the encoded gate is embedded. This results in more efficient serialization and deserialization in architectures where data fields need to be padded to the nearest full byte. Note that in at least one embodiment, advanced encoding schemes may also be applied, and the wire identifier need not be encoded into an integer number of bytes. During deserialization, the receiver knows the value of N from the header. After reading the wire identifier, the remaining bit stream represents the encoded arithmetic operation. The encoded gate does not have to be byte-aligned, but multiple gates can be embedded into a single byte using bitwise operations. For example, if two symbols a1 and a2 are independently encoded into 4 bits, a single byte b can be used to aggregate the information: b=(a1<<4)+a2

[0089] The bitwise operator "<<" is a left shift. Gates can also split into two or more bytes, depending on the specific dictionary.

[0090] In one embodiment, the entropy coder constructs the code so that the decoder can detect where each symbol code begins and ends. Thus, the correct wire identifier is assigned sequentially to each arithmetic operation, depending on the number of inputs required. For example, if the next wire is read ith in the sequence and the next operator starts at bit j in the stream, the following operations are performed: 1. Symbol a with its first bit at position jn j Detect. 2. Using information from the dictionary, we calculate the symbol size s(a j ) is calculated. 3. Symbol a i The number of input wires n(a j ) is calculated. 4. Arithmetic operations with codes and wire identifiers (i, i+1,..., i+n(a i )-1) is stored. 5. Set the pointer to the next symbol as j+s(a j ) to 6. Add the counter to the next wire to i+n(a j ) to

[0091] In one embodiment, processing ends when N wires are read. If the stream is encoded correctly, the pointer to the next symbol is at the end of the stream when the Nth wire is read. In one embodiment, the last symbol may not be byte-aligned, and no padding may be used to align the last symbol, for example using 0 padding, 1 padding, or 01 padding.

[0092] 6 shows a comprehensive example for a serialization process that considers a dictionary with M=3 and an initial operation circuit (i.e., n=8) coded in ASCII. Huffman coding may be utilized in conjunction with the serialization process. For example, with Huffman coding, the most frequently occurring operation is coded as a 1-bit value (e.g., MUL is coded as "0"), the second most frequently occurring operation is coded as a 2-bit value (e.g., ADD is coded as "10"), and so on (e.g., the third operation y is coded as "11"). The compression ratio with respect to ASCII coding is n w = 32, it is 2.44, and n w = 8, it is 8.11.

[0093] FIG. 7 illustrates a simplified block diagram of a computing device 700 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 700 can be used to implement any of the illustrated systems described above. For example, the computing device 700 can be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 7 , the computing device 700 can include one or more processors 702 that, in some embodiments, are configured to communicate with and operably coupled to a number of peripheral subsystems via a bus subsystem 704. In some embodiments, these peripheral subsystems include a storage subsystem 706, including a memory subsystem 708 and a file / disk storage subsystem 710, one or more user interface input devices 712, one or more user interface output devices 714, and a network interface subsystem 716. Such storage subsystems 706 can be used for temporary or long-term storage of information.

[0094] In some embodiments, bus subsystem 704 provides a mechanism that allows the various components and subsystems of computing device 700 to communicate with each other as intended. While bus subsystem 704 is shown generally as a single bus, alternative embodiments of the bus subsystem utilize multiple buses. In some embodiments, network interface subsystem 716 provides an interface to other computing devices and networks. Network interface subsystem 716, in some embodiments, serves as an interface for receiving data from and transmitting data to other systems from computing device 700. In some embodiments, bus subsystem 704 is utilized to communicate data such as details, search terms, etc.

[0095] In some embodiments, user interface input device(s) 712 include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touchscreen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computing device 700. In some embodiments, one or more user interface output devices 714 include a display subsystem, a printer, or a non-visual display such as an audio output device. In some embodiments, a display subsystem includes a flat-panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light-emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computing device 700. One or more user interface output devices 714 may be used, for example, to present a user interface and facilitate user interaction with applications that perform the processes and transformations described herein, when such interaction is appropriate.

[0096] In some embodiments, storage subsystem 706 provides a computer-readable storage medium that stores basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, in some embodiments provide the functionality of one or more embodiments of the present disclosure, are in embodiments stored in storage subsystem 706. These application modules or instructions can be executed by one or more processors 702. In various embodiments, storage subsystem 706 also provides a repository for storing data used in accordance with the present disclosure. In some embodiments, storage subsystem 706 includes memory subsystem 708 and file / disk storage subsystem 710.

[0097] In embodiments, memory subsystem 708 includes multiple memories, such as a primary random access memory (RAM) 718 for storing instructions and data during program execution, and / or a read-only memory (ROM) 720 in which fixed instructions may be stored. In some embodiments, file / disk storage subsystem 710 provides non-transitory persistent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0098] In some embodiments, computing device 700 has at least one local clock 724. Local clock 724, in some embodiments, represents a counter that represents the number of ticks since a particular starting date and, in some embodiments, is located internal to computing device 700. In various embodiments, local clock 724 is used to synchronize data transfers within the processor for computing device 700 and its included subsystems with a particular clock pulse, and can be used to coordinate synchronization operations between computing device 700 and other systems in a data center. In another embodiment, the local clock is a programmable internal timer. Computing device 700 may be any of a variety of types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 700, in some embodiments, may include another device connectable to computing device 700 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). In embodiments, such a device includes a port configured to receive an optical fiber connector. Thus, in some embodiments, the device is configured to convert optical signals into electrical signals that are transmitted to computing device 700 through the port connecting the device for processing. Due to the ever-changing nature of computers and networks, the description of computing device 700 shown in FIG. 7 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than the system shown in FIG. 7.

[0099] The specification and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that various modifications and changes thereto may be made without departing from the scope of the invention as set forth in the appended claims. Likewise, other variations are within the scope of this disclosure. Accordingly, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof have been shown and described above in detail. There is no intention, however, to limit the invention to the particular form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents included within the scope of the invention, as defined by the appended claims.

[0100] The terms "a," "an," "the," and similar references in the context of describing embodiments of the disclosure (particularly in the context of the claims below) are intended to cover both the singular and the plural unless the context otherwise indicates or clearly contradicts. The terms "comprising," "having," "including," "containing," and the like, should be considered open-ended (i.e., meaning "including, but not limited to") unless otherwise noted. The term "connected," when unmodified and referring to a physical connection, should be considered to be partially or wholly contained within, attached to, or joined together, even if there is no intermediary. Recitation of ranges of values ​​in this disclosure, unless otherwise noted, merely serves as a shorthand notation for individually referring to each separate value falling within the range, and each separate value should be considered to be incorporated herein as if set forth individually. Use of the term "set" (e.g., "set of items") or "subset" should be considered a non-empty set containing one or more members, unless otherwise noted or contradicted by context. Furthermore, unless otherwise specified or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set; a subset and a corresponding set may be equivalent.

[0101] Conjunctive language, such as "at least one of A, B, and C" or "at least one of A, B, and C," is generally understood in context to indicate that an item, term, etc. can be either A or B or C, or any non-empty subset of the set A, B, and C, unless otherwise specified or clearly contradicted by the context. For example, in the illustrative example of a set having three members, the conjunctive phrase "at least one of A, B, and C" or "at least one of A, B, and C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such conjunctive language is generally not intended to imply that a particular embodiment requires that at least one A, at least one B, and at least one C, respectively, be present.

[0102] The actions of the described processes can be performed in any suitable order unless otherwise specified or clearly contradicted by context. The described processes (or variations and / or combinations thereof) can be performed under the control of one or more computer systems configured with executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that cooperatively execute on one or more processors, by hardware or a combination thereof. In some embodiments, the code can be stored on a computer-readable storage medium, e.g., in the form of a computer program having a plurality of instructions executable by one or more processors. In some embodiments, the computer-readable storage medium is non-transitory.

[0103] The use of any and all examples, or exemplary language provided (e.g., "such as"), is intended merely to better elucidate embodiments of the invention and does not impose limitations on the scope of the invention unless specifically stated. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0104] Embodiments of the present disclosure have been described, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments will become apparent to those skilled in the art upon reading the foregoing description. The inventors expect those skilled in the art to take advantage of such variations as they deem appropriate, and the inventors intend for the embodiments of the present disclosure to be practiced otherwise than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Furthermore, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise indicated or otherwise clearly contradicted by context.

[0105] All references cited herein, including publications, patent applications, and patents, are herein incorporated by reference to the same extent as if each individual reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein. This includes UK Patent Application Nos. GB1719998.5, GB1718505.9, and GB1720768.9.

[0106] It should be noted that the above-described embodiments illustrate rather than limit the present invention, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses are not intended to limit the claim. The words "comprising" and "comprises", and the like, do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "having or consisting of," and "comprises" means "including or consisting of." A singular reference of an element does not exclude a plural reference of such an element, and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage. [Explanation of symbols]

[0107] 102 Arithmetic circuit 104 Serialization Circuit

Claims

1. 1. A computer-implemented method comprising: On the client node: Compiling a calculation P into an arithmetic circuit C, said arithmetic circuit C including wires that carry values ​​from a field F and connect to add and multiply gates; supplying the arithmetic circuit C and the input x to a worker node; In the worker node, executing the operation circuit C on the input x to output y, encoding a transcript of {C, x, y}, and providing the output y to the client node; validating the payment transaction at a verifier node; 20. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the operational circuit is a physical circuit having wires and logic gates.

3. 3. The computer-implemented method of claim 1, wherein the operational circuit is a DAG, and the wires are edges in the DAG.

4. 4. The computer-implemented method of claim 1, wherein a secondary program Q is generated from the arithmetic circuit C, the secondary program Q including a set of polynomials that provide a complete description of the original arithmetic circuit C, and public parameters are generated that are used by the worker node and the verifier node when executing and verifying the secondary program.

5. 5. The computer-implemented method of claim 1, wherein a valid transcript of {C, x, y} is an assignment of values ​​to circuit wires, where the value assigned to an input wire is a value of x, the intermediate values ​​correspond to the correct operation of each logic gate in C, and the value assigned to an output wire is y.

6. 6. The computer-implemented method of claim 5, further comprising deriving a public evaluation key EK and a public verification key VK using a secret value s selected by or from the client node, wherein the worker node uses the public evaluation key and the public verification key to evaluate a calculation for a particular input x.

7. 7. The computer-implemented method of claim 6, wherein the output y, internal circuit wire values, and EK are used to generate a proof-of-correctness π.

8. 8. The computer-implemented method of claim 7, wherein a proof of validity π is stored on a blockchain and is verified by the verifier node without the worker node having to individually interact with the verifier node to verify the payment transaction using the public verification key VK and the proof π.

9. 1. A system comprising: The system includes a client node, a worker node, and a verifier node, each node including a processor and a memory including executable instructions, the executable instructions being executed by the processor to provide the system with: compiling, at the client node, a computation P into an arithmetic circuit C, the arithmetic circuit C including wires carrying values ​​from a field F and connecting to an addition gate and a multiplication gate; and providing the arithmetic circuit C and an input x to a worker node; In the worker node, the operation circuit C is executed on the input x, and y is output, and a transcript of {C, x, y} is encoded, and the output y is provided to the client node; causing the verifier node to verify the payment transaction; system.

10. 10. The system of claim 9, wherein the operational circuit is a physical circuit having wires and logic gates.

11. 11. The system of claim 9, wherein the operational circuit is a DAG, and the wires are edges in the DAG.

12. A system as described in any one of claims 9 to 11, wherein a secondary program Q is generated from the arithmetic circuit C, the secondary program Q including a set of polynomials that provide a complete description of the original arithmetic circuit C, and public parameters are generated that are used by the worker node and the verifier node when executing and verifying the secondary program.

13. 13. The system of claim 12, wherein a valid transcript of {C, x, y} is an assignment of values ​​to circuit wires, where the values ​​assigned to input wires are values ​​of x, intermediate values ​​correspond to the correct operation of each gate in C, and the values ​​assigned to output wires are values ​​of y.

14. 14. The system of claim 13, further comprising deriving a public evaluation key EK and a public verification key VK using a secret value s selected by or from the client node, wherein the worker node uses the public evaluation key and the public verification key to evaluate a calculation for a particular input x.

15. 15. The system of claim 14, wherein the output y, internal circuit wire values, and EK are used to generate a proof-of-correctness π.

Images