Computer-implemented methods and systems relating to arithmetic coding for serialized arithmetic circuits

Abstract

To provide methods and systems for lossless compression and serialization of arithmetic circuits into a bit stream using compression techniques such as arithmetic coding.SOLUTION: An arithmetic circuit representing a smart contract may be compressed using arithmetic coding, thereby generating a compressed arithmetic circuit that can be stored in or broadcast to a blockchain network using less computational resources (e.g., data storage resources) than would otherwise be needed to store the arithmetic circuit. The arithmetic circuit can be efficiently compressed using entropy coding based on the frequency of elements in a data structure, e.g., of arithmetic operator types. Instructions for deserialization and decompression can also be embedded in a bit stream, and can be used (e.g., by another computer system) to reconstruct the original circuit 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 in particular to techniques for generating serialized circuits using compression techniques, i.e., arithmetic coding techniques described herein. The computational circuits may be compressed in a lossless manner to generate serialized circuits that can be used at a later time to completely reconstruct 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 programs 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] Therefore, it is desirable to implement a verifiable computation framework (e.g., using the Bitcoin network) in which a client computer system generates a smart contract represented as an arithmetic circuit and uses an encoding technique, i.e., arithmetic coding, to compress the arithmetic circuit, thereby generating a compressed arithmetic circuit that can be used to reduce the storage space requirements for storing and / or executing the smart contract. The compressed arithmetic circuit can then be broadcast to a blockchain network and stored (e.g., on nodes of the blockchain network) in place of the uncompressed arithmetic circuit. A working computer system may obtain the compressed arithmetic circuit, obtain an executable version of the smart contract (e.g., by decompressing the compressed arithmetic circuit), and execute the smart contract on behalf of the client computer system according to various verifiable computation protocols.

[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, comprising: obtaining a symbol set based on an arithmetic circuit representing the smart contract; To store the arithmetic circuitry, at least the following: mapping a subset of the symbol set to a range of encoded values; selecting an encoding value within the range of encoding values; representing a first subset of said set of symbols having said encoded values ​​in a compression arithmetic circuit; reducing the amount of data by Storing the compression operation circuit in a node of a blockchain network; A method may be provided that includes:

[0011] Preferably, the compression operation circuit includes a header encoding information that can be used to map the set of symbols to different ranges of coded values, for example a first symbol maps to the range [0-0.3), a second symbol maps to the range [0.3, 0.7), and a third symbol maps to the range [0.7, 1). The different ranges may be non-overlapping ranges, so that a particular coded value corresponds to exactly one symbol or set of symbols.

[0012] Preferably, the coded value is a binary number, such as a binary value greater than or equal to 0 and less than 1.

[0013] The encoded value may be selected based on the encoded value being representable by a threshold number of bits, for example, a binary value that can be represented by fewer bits may be selected as the encoded value, such as between two different binary values ​​in a range.

[0014] The step of selecting the encoded value comprises: mapping different subsets of the set of symbols to subranges of the range of encoded values; selecting the encoded value from within the sub-range of the encoded value range; may include The first and second subsets of symbols are represented in the compression operation circuit by the coded values.

[0015] The method includes obtaining a symbol set based on an arithmetic circuit representing the smart contract; receiving a request to serialize an input file, the input file including a plurality of lines of code representing the operational circuit; scanning at least a portion of the plurality and adding symbols in the symbol set to a data structure; and The symbol set is obtained from the data structure.

[0016] The method may further include encoding a symbol in the set of symbols as the difference between the symbol and another symbol in the set of symbols.

[0017] Preferably, the arithmetic circuit includes an operator and a write identifier, the symbol set being the operator and the write identifier being separately coded according to an arithmetic coding scheme.

[0018] The method may further include obtaining the symbol set by parsing a file encoding the operational circuit to identify an operator set and a parameter set for at least a portion of the operator set.

[0019] Preferably, the range of coded values ​​corresponds to the probability that the subset occurs within the pattern, e.g., between two symbol sets, a symbol set with a higher probability of occurrence has a relatively larger corresponding range of coded values.

[0020] Preferably, said subset of said symbol set is one symbol.

[0021] Preferably, the compression operation circuit is broadcast to the blockchain network on behalf of the operation circuit.

[0022] Preferably, a node of the blockchain network that receives the compressed operation circuit can determine the operation circuit from the compressed operation circuit.

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

[0024] 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]

[0025] 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 illustrates serialization and deserialization of an arithmetic circuit in accordance with one embodiment of the present disclosure. [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 shows a diagram visualizing the arithmetic coding of a sequence of symbols according to one embodiment of the present disclosure; [Figure 5] FIG. 1 shows an illustration of a process for compressing arithmetic circuits using arithmetic coding, according to one embodiment of the present disclosure. [Figure 6] In one embodiment, a diagram is shown in which various solutions to serialization of arithmetic circuits may be implemented based on the compression properties of arithmetic coding, according to at least one embodiment. [Figure 7] 1 shows an illustration of a process for controlling serialization of an arithmetic circuit using a buffer, according to one embodiment. [Figure 8] 1 shows a diagram visualizing a multi-symbol representation of a symbol sequence utilizing the properties of a dictionary based on arithmetic circuits, according to one embodiment. [Figure 9] 1 shows a diagram of multi-symbol encoding according to one embodiment. [Figure 10] 10 shows a diagram in which an arithmetic circuit is compressed by aggregating identifiers, resulting in the creation of a more compressible serialization circuit. DETAILED DESCRIPTION OF THE INVENTION

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

[0027] As described in more detail below, a possible implementation is described for compressing and serializing an arithmetic circuit into a binary data stream using arithmetic coding. 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 arithmetic circuit). For example, in the context of a blockchain network, the arithmetic circuit or a program derived from the arithmetic circuit may be at least partially encoded into the blockchain network's ledger. Reducing the data storage footprint of the arithmetic 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 a small reduction in the data storage footprint of data stored in the blockchain is highly valued.

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

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

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

[0031] Some advantages of the protocol may include: 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.

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

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

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

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

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

[0037] 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).

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

[0039] 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).

[0040] 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

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

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

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

[0044] 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 directed acyclic graph (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 a general-purpose language (GPL) into the operation circuit C. In an embodiment, the client node 240 provides the operation circuit C and the input x to a worker node 250.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] In one embodiment, the computation circuit 314 is a DAG for a set of variables. In one embodiment, all nodes of a zero in-degree 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 out-degree 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.

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

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

[0062] In one embodiment, the QAP polynomial 318 is one or more expressions having variables and coefficients expressed in a mathematical expression that provides a complete description of the original arithmetic circuit (e.g., the arithmetic circuit 314 in FIG. 3). In an embodiment, the polynomials among the QAP polynomials are defined from the perspective of their evaluation at the roots of the arithmetic circuit. For example, as described in Gennaro, R. et al., Quadratic Span Programs and Succinct NIZKs without PCPs (2013). In an embodiment, the QAP polynomial is encoded as a smart contract representation within the lock script of a blockchain transaction. In an embodiment, the lock script receives a set of parameter values when executed (e.g., as a result of the execution of the lock script). The set of parameter values is input as variables to the QAP polynomial to determine the result of the smart contract.

[0063] In an embodiment, the GPL polynomial 308 generates the GPL preprocessing code 312 which may be an arithmetic circuit having arithmetic gates. However, note that complex arithmetic circuits also embed logical submodules with conditional and flow control statements.

[0064] FIG. 4 shows a diagram 400 visualizing the arithmetic coding of a symbol sequence according to an embodiment of the present disclosure. In one embodiment, the process of generating the arithmetic coding for a symbol sequence can be executed in conjunction with the diagram shown in FIG. 4. Arithmetic coding is a type of entropy coding used in lossless data compression. The symbol set is typically represented using a fixed number of bits per symbol, such as ASCII codes, and frequently used symbols may be stored with fewer bits. Different from Huffman coding, arithmetic coding encodes the entire message into an arbitrary precision range [x, y) such as a range between 0 and 1 (0 ≦ x < y < 1).

[0065] For example, FIG. 4 shows the arithmetic coding of a symbol sequence {a1, a2, a1} that can be encoded for use within any accuracy range. In one embodiment, the symbols are encoded in a range between 0 and 1 (for example, including and / or excluding the endpoints). In one embodiment, the symbols are encoded in a range between 0 and 2, including and / or excluding the endpoints. According to FIG. 4, an example includes a set of value ranges corresponding to the first symbol in the sequence. For example, values within the range [0, x1) corresponding to the first symbol are a0, values within the range [x1, y1) corresponding to the first symbol are a1, and values within the range [y1, 1) corresponding to the first symbol are a2. In one embodiment, each of the value ranges can be further divided to correspond to the second symbol in the symbol sequence. For example, and according to FIG. 4, let x1 < w2 < x2 < y2 = y1. Then, according to this example, the following two-symbol sequences can be encoded using the following value ranges. n According to FIG. 4, an example includes a set of value ranges corresponding to the first symbol in the sequence. For example, values within the range [0, x1) corresponding to the first symbol are a0, values within the range [x1, y1) corresponding to the first symbol are a1, and values within the range [y1, 1) corresponding to the first symbol are a2. In one embodiment, each of the value ranges can be further divided to correspond to the second symbol in the symbol sequence. For example, and according to FIG. 4, let x1 < w2 < x2 < y2 = y1. Then, according to this example, the following two-symbol sequences can be encoded using the following value ranges. [Table 1]

[0066] In various embodiments, the arithmetic coder can generate a near-optimal output for any given symbol set a from an alphabet A having size n with probability p. i Here, the optimal value is -log2p. The data model can be defined by predicting what patterns are found among the symbols of the message. An accurate prediction guarantees a near-optimal solution. In one embodiment, an adaptive model changes those estimates of the current probabilities of the symbols based on the previous symbol. In one embodiment, the decoder utilizes the same model as the encoder. i Here, the optimal value is -log2p. The data model can be defined by predicting what patterns are found among the symbols of the message. An accurate prediction guarantees a near-optimal solution. In one embodiment, an adaptive model changes those estimates of the current probabilities of the symbols based on the previous symbol. In one embodiment, the decoder utilizes the same model as the encoder. i Here, the optimal value is -log2p. The data model can be defined by predicting what patterns are found among the symbols of the message. An accurate prediction guarantees a near-optimal solution. In one embodiment, an adaptive model changes those estimates of the current probabilities of the symbols based on the previous symbol. In one embodiment, the decoder utilizes the same model as the encoder.

[0067] The encoding and decoding of symbols can be performed using various techniques described in detail below. At each step j of the encoding process, the new symbol is the current interval [x j , y j (As described elsewhere in this specification, embodiments excluding and / or including endpoints are considered within the scope of the present disclosure) and the current probability pj According to various embodiments, p j (a i ) is the symbol probability a i The general notation p i is valid in one embodiment if and only if an adaptive model is not used. The encoder divides the current interval into subintervals, each subinterval representing a portion of the current interval proportional to the probability of that symbol. j (a i ) with input symbol a i The subintervals of are updated intervals [x j+1 ,y j+1 ] becomes:

number

[0068] When all symbols of a sequence are encoded, the resulting interval corresponds to (e.g., unambiguously identifies) the entire symbol sequence. As shown in Figure 4, values ​​encompassed by the interval are marked as "end range" (e.g., including and / or excluding the endpoints). For example, the following table, in one embodiment, reflects a symbol sequence, with corresponding ranges representing said sequence: [Table 2]

[0069] Additionally, it should be noted that the intervals or value ranges shown in Figure 4 are not necessarily to scale, and Figure 4 does not imply that particular intervals are proportional to other intervals. In one embodiment, the intervals are proportional or substantially proportional to the occurrence probability of the symbols (e.g., to a particular precision threshold as a result of rounding values). In one embodiment, the probability of a symbol at step j+1 depends on the preceding symbol at step j. In one embodiment, the symbol occurrence probability at step j has a memoryless probability, where the symbol occurrence distribution at j+1 does not depend on the value of any preceding symbol.

[0070] In one embodiment, the symbol sequence can be reconstructed by knowing the interval (or any part that lies within the interval) and a probability model. If the stream has, for example, probability p EOS EOS (end of stream) symbol a EOS An external mechanism may be used to interrupt the decoding process if it does not terminate internally using . In some cases, different equally short decimal fractions can be used to represent the same interval. Therefore, a binary representation with fewer bits can be selected to maximize the compression factor, according to one embodiment. For example, two fractions in the range [0.65, 0.67) can be represented by a significantly different number of bits, thereby affecting the compression factor of the sequence: [Table 3] Therefore, in one embodiment, techniques are utilized to reduce (or minimize) the number of bits used to encode a symbol sequence. In embodiments where an integer number of bits are used in binary encoding, the arithmetic encoder may introduce a maximum overhead of 1 bit, over the size of the compressed message. The arithmetic coder may operate with a fixed limit of precision ψ that the decoder can accommodate, and round fractions to the nearest equivalent value at that precision. For example, those symbols with equal probability p=1 / 3 require infinite precision to correctly represent the three intervals in [0,1). In one embodiment, a precision value is selected, e.g., ψ=8 bits, that can be used to calculate the binary range at that precision, as shown below: [Table 4] In one embodiment, when one or more digits are shared between two limits of the current encoding range, these digits are appended to the output stream and discarded. The remaining digits in the encoding range are shifted to the left, while new digits are appended to the right: 1 at the upper bound and 0 at the lower bound. Thus, the system continues to operate with ψ-bit precision by discarding bits that no longer contribute to the precision of the calculation.

[0071] For the upper limit of compression, for size L and alphabet A, the symbol frequency f(a j ), the infinite precision encoding part is C can be represented by bits:

number

[0072] Dividing LC by L gives the self-entropy of the message, i.e. arithmetic coding gives a coding that is asymptotically close to entropy:

number

[0073] Thus, arithmetic coding allows coding that is essentially close to the entropy of a probability model in which the symbol probabilities are the same as those of the input message.

[0074] Note that arithmetic coding does not compress one symbol at a time, and therefore can get arbitrarily close to the entropy limit. In contrast, Huffman coding does not approach the entropy limit unless the overall symbol probability is a power of two. Consider the following example: two symbols {0,1} with low entropy (p0=0.95, p1=0.05). Huffman coding assigns one bit to each value, resulting in a code of the same length as the input, while arithmetic coding approaches the optimal compression ratio:

number

[0075] FIG. 5 shows an illustrative example of a process 500 for compressing an operational circuit using arithmetic coding, according to one embodiment of the present disclosure. Some or all of process 500 (or any other process described herein, or variations and / or combinations thereof) may be performed according to the techniques described in connection with FIG. 4. Process 500 is an illustration of steps that may be performed to generate a serialized circuit from arithmetic coding. As a result of serializing the operational circuit using the arithmetic coding techniques described herein, a compressed representation of the operational circuit may be stored in place of the operational circuit. For example, in one embodiment, the serialized circuit is broadcast to nodes of a blockchain in place of the operational circuit, thereby reducing data storage requirements for nodes of the blockchain network (e.g., nodes that maintain copies of the blockchain ledger).

[0076] In one embodiment, the system takes an operational circuit (e.g., represented as line code in a data file) and parses the operational circuit to identify operators and wire identifiers that are inputs and / or outputs of the operators. In one embodiment, the operators and identifiers are pushed to and stored in different data structures. The process 500 shown in FIG. 5 may be suitable for encoding different types of circuit data as described above. In one embodiment, the process 500 is performed separately for operators and identifiers (e.g., input identifiers).

[0077] In one embodiment, the system obtains 502 a first one or more symbols of an arithmetic circuit representing a smart contract. In some cases, the process involves selecting one symbol at a time and mapping the individual symbol to a range, while in other cases, multiple symbols are collected and the multiple symbols are collectively mapped to a particular interval range. In one embodiment, the symbols are all of a particular type (e.g., all operators, all input wires).

[0078] In one embodiment, the system obtains 504 a mapping of symbols to subranges of the interval range. The initial interval range may span from a global minimum to a global maximum (e.g., all coding symbols fall within the global min / max range). Unless otherwise noted, endpoints described herein above and below in connection with FIG. 5 may be inclusive and / or exclusive (e.g., a range may include a lower limit and exclude an upper limit). In one embodiment, the global minimum is 0 (inclusive) and the global maximum is 1 (exclusive), and thus the entire value range is represented by a binary decimal with a value less than 1. The mapping represents a mapping table that divides the initial interval range into a set of non-overlapping subranges. Thus, the subranges collectively cover the entire initial interval range. Each of the subranges, in one embodiment, is mapped to a symbol or set of symbols. In one embodiment, the system determines 506 a next interval range based on the mapping and the first one or more symbols. In one embodiment, the system makes this determination by finding the mapping table entry corresponding to the first one or more symbols and selects the subrange corresponding to the first one or more symbols to become the next interval range. In one embodiment, if the mapping fails (e.g., no mapping table entry exists for the first one or more symbols), the process terminates early with an error. For example, if the global range is [0,1), the following mapping table may exist for the symbol set: [Table 5] In one embodiment, after determining the sub-range of the first one or more symbols, the system determines 508 whether there are more symbols to encode. In one embodiment, the determination is made by determining whether there are additional symbols in the data structure (e.g., after the first one or more symbols are popped from the data structure). If there are additional symbols, the system, in one embodiment, obtains a mapping of symbols to sub-ranges of the previously determined sub-range. In one embodiment, a sub-range is proportionally the same as the previous range, such that: [Table 6] In one embodiment, the system uses this second mapping to determine, for a second set of one or more symbols, the interval range corresponding to the symbols processed so far. In one embodiment, these steps are repeated until no symbols are left (the data structure storing the symbols is empty, the end of the file is reached, etc.). As a result, the last subrange is retained and used to encode the value. For example, continuing with the previous example, if the entire symbol set is a2a3, the last interval range is [0.7,0.8). Thus, in this example, any binary decimal number between 0.7 (inclusive) and 0.8 (exclusive) can be used to represent the symbol a2a3.

[0079] Once the final interval range is obtained, the system encodes the symbol using a value within the final interval range 512. Any value within the interval range is suitable for encoding the symbol. For example, continuing with the previous example, examples of valid values ​​for encoding a2a3 include 0.7, 0.75, and 0.7979.... Examples of invalid values ​​for encoding a2a3 include 0.6969.... Because there may be multiple suitable values ​​for encoding the symbol set, a binary representation with fewer bits can be selected to maximize compression.

[0080] In one embodiment, the operator and / or wire identifier (or portions thereof) may be serialized as described in accordance with Figure 5. The resulting serialized circuitry is stored 514 in place of the operational circuitry, e.g., in a blockchain ledger, thereby reducing the storage requirements for encoding the proposed smart contract.

[0081] FIG. 6 illustrates a diagram 600 in which various solutions for serializing arithmetic circuits may be implemented based on the compression properties of arithmetic coding, according to at least one embodiment. In one embodiment, the serialization process is managed by a buffer that provides bit-by-bit operations, see FIG. 6. In one embodiment, the bit buffer temporarily stores data before the data is transferred to supported permanent storage or sent over a network. As shown in FIG. 6, the buffer is accessible by (at least) the following methods: a put() function that inserts input data x into the buffer. In one embodiment, x is stored using nb bits, and a send() function flushes the buffer and transfers the data to an output stream out.

[0082] One or more interfaces may be provided that act as abstraction layers for typed operations. In one embodiment, the low-level method put() may be called by different high-level methods such as writeInt(), writeUnit(), and writeStr(), which may be used to write integers, unsigned integers, and strings, respectively (e.g., to a buffer).

[0083] In one embodiment, a third abstraction layer is provided by a function such as scan() that invokes underlying methods to read data line by line from an input (e.g., input file 602 shown in FIG. 6) and write typed data. In one embodiment, the scan() function shown in FIG. 6 corresponds to a routine that, when invoked, checks that each command in the file can be mapped to one of the underlying methods. In one embodiment, errors in the mapping, for example as a result of detecting an unrecognized command, an incorrect signature format, or an incorrect (e.g., deprecated) function version, cause the entire encoding process to fail.

[0084] In one embodiment, at the highest abstraction layer, the serialise() function reads from an input file containing circuit information and sends the compressed information to an output stream, which in one embodiment is a file or a network resource.

[0085] In one embodiment, a line in a file containing a circuit has the following format: where P is the number of parameters for the operator OP. In one embodiment, an operator requires a specific number of parameters. In one embodiment, parameters can be categorized as in-parameters (input parameters), out-parameters (output parameters), inout-parameters (parameters that provide input values ​​to an operation and are used to store the results of the operation), etc. In one embodiment, separate data structures are used for compressing operators and parameters. In one embodiment, different compression techniques are used for different data structures. The data structures, in one embodiment, may be implemented using any suitable data structure, such as a queue, stack, vector, etc. In one embodiment, operators in an operator queue must have a fixed number of parameters and / or fixed-size parameters (e.g., variable-length data blobs are not supported). For example, an “ADD” operation stored in the data structure may require exactly two input parameters and one output parameter. It should be noted that the operations stored in the queue may differ from operations at a higher level of abstraction. For example, and in general, an addition operation can be performed on any number of input parameters (e.g., a+b+c+...). In one embodiment, the data structure has multiple variants of the operation corresponding to different function signatures. For example, the data structure may support an "ADD2" operation that supports two inputs and one output representing the sum of the two inputs, an "ADD3" operation that supports three inputs and an output parameter for the sum of the three inputs, etc. Thus, in one embodiment, sums of any number of inputs can be chained together using multiple addition operations with a fixed number of inputs.

[0086] In one embodiment, data fields having dynamic (e.g., variable) sizes can be embedded in serialized packets. As an illustrative example, consider the case where four blocks of compressed data [data1, data2, data3, data4] having the same size (16 bits) are serialized. In one embodiment, the data blocks can be compressed using the following encoding scheme: a first field having a fixed size contains the size (e.g., in bits) of the field reserved for the number of data packets in the payload; a second field having a fixed size (e.g., the same or different size as the first field) contains the size (in bits) of the field reserved for the data packets in the payload; a third field contains the number of data packets in the payload; and the remaining fields contain the data packets. This is merely an illustrative example of how to embed dynamic data fields. In one embodiment, the first data field encodes the size of a first data structure that follows the first data field. Meanwhile, the data structure can include a second data field that encodes the size of a second data structure that follows the second data field, and so on, in a nested and / or sequential pattern.

[0087] In one embodiment, the header of the serialization circuit includes one or more encoding fields as described in more detail below. In one embodiment, the version field provides information on how to interpret and / or construct the remainder of the header and is a fixed size (e.g., 1 byte). In one embodiment, the header includes a parameter M indicating the number of symbols for the operation. In one embodiment, this parameter is encoded using a fixed number of bits determined based on the maximum number of operations supported by the serialization circuit. In one embodiment, the header includes the number of input wires (IN), the number of output wires (OUT), the encoded size of the wire identifier (n w ), and the encoding size of the parameters (n params ) is encoded, for example, using a hard-coded number of bits. In one embodiment, the total number of wires, N, is encoded using the encoding size n wIt should be noted that the header does not necessarily have to be located at the beginning or beginning of the serialized data file. In one embodiment, the header need only be placed at a particular point in the serialization circuit before the data to which the header information pertains. For example, if the header includes a parameter for the total number of wires, N, then in one embodiment, the header information, N, is encoded at any suitable point in the serialization circuit so that it is read before the data encoding the wire identifiers.

[0088] In one embodiment, the header includes an embedded dictionary. In one embodiment, the maximum encoding size of a symbol for Huffman coding is summed first, and then each pair (symbol size, symbol) is summed with the maximum encoding size of the first element of the pair. In one embodiment, if arithmetic coding is not used, n params is an optional parameter of the header (e.g., it can be omitted). In one embodiment, the probability of each individual symbol is calculated as (encoding size n prob Alternatively, a probability scheme can be provided, where multiplication coefficients can be used to represent the entire set. For example, consider the case where four symbols are used with the following probabilities: p1=0.1, p2=0.4, p3=0.1, p4=0.4. Then multiplication coefficients can be used to represent the entire set [1,4,1,4]. In one embodiment, these coefficients are used (e.g., for an encoding size n coeff ) or (using encoding size n pid In one embodiment, the header is represented as a scheme template by a unique identifier (using prob and / or a table mapping symbols to identifiers.

[0089] In one embodiment, arithmetic coding uses value ranges to represent a sequence of operations according to probabilities coded in the header. In one embodiment, the precision of the coding ranges can be calculated as described elsewhere in this disclosure, for example, in conjunction with the description shown in FIG. 4. In one embodiment, using Huffman coding in this manner, each compressed symbol corresponding to an operation is added sequentially to the payload.

[0090] In one embodiment, the wire identifiers are each added sequentially to the payload, such as when Huffman coding is used. In one embodiment, different strategies can be used to encode the wire identifiers using arithmetic coding, such as one or more of sequential coding (e.g., with Huffman coding), arithmetic coding (e.g., with an operator), and aggregation of identifiers (e.g., as described in more detail below in connection with FIG. 8).

[0091] 7 shows an illustration of a process 700 for controlling serialization of operational circuits using a buffer, according to one embodiment. Some or all of process 700 (or any other process described herein, or variations and / or combinations thereof) may be performed according to the techniques described in connection with FIGS. 5 and 6.

[0092] In one embodiment, the serialization process 700 is managed using a set of interfaces that provide an abstraction layer between different operations and operation types. In one embodiment, at a first abstraction layer, a computer system executing the process 700 receives 702 a command to serialize an operational circuit representing a smart contract. In one embodiment, the command is an application programming interface (API) command that includes a reference to a data file containing the operational circuit to be serialized. In one embodiment, the data file is an uncompressed data file (e.g., not compressed using arithmetic coding techniques). In one embodiment, the command also identifies an output stream that stores the serialized result of the operational circuit.

[0093] In one embodiment, smart contracts are written in domain-specific language (DSL) code with precise semantics. In one embodiment, smart contracts include a set of conditions and one or more outcomes, where satisfaction of the one or more outcomes depends at least in part on evaluating the set of conditions based on one or more inputs. In one embodiment, the DSL code is converted into general-purpose language (GPL) code. Non-limiting examples of general-purpose 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. In one embodiment, a GPL pre-compiler processes GPL code using external libraries to generate standalone GPL pre-processed smart contracts. In one embodiment, computational circuits are constructed by representing symbols with wires that connect to elemental computational gates.

[0094] In one embodiment, the system scans the first line of an input file containing an operational circuit 704. In one embodiment, each line of the read input file corresponds to a command, which may correspond to one or more executable instructions (e.g., assembly instructions). In one embodiment, scanning the file includes obtaining a command from the first or next line of the file and mapping the command to an underlying method. In one embodiment, the system determines the mapping 706 by determining a typed operation associated with the command. In one embodiment, different data types supported include integers, unsigned integers, and strings (e.g., strings terminated with a null terminator special character).

[0095] In one embodiment, depending on the particular configuration of the encoder, different types of variables are encoded using different numbers of bits 708. The encoding technique may follow the techniques detailed in connection with FIG. 5. For example, the encoding of header data, operator data, and wire identifier data may each utilize different techniques, such as arithmetic encoding techniques for data encoding. Different encoding techniques may be used for different types of operations. In one embodiment, once the data is encoded, it is inserted into a buffer. In one embodiment, the command to insert data into a buffer 710 is a command to write a specific number of bits of data to the output stream. The system may then determine whether the end of the file has been reached (e.g., by detecting whether a specific end-of-file sequence of bits or characters has been reached) 712. In one embodiment, if there are more commands for the file to be processed, the system sequentially scans through the file to obtain the second, third, fourth, etc. lines of the file and processes them according to steps 704-710 described above. These steps may be repeated until the end of the file is detected. At the end of the file, the system flushes the buffer and transfers all the data to the output stream or file, thereby creating a serialization circuit 714 .

[0096] FIG. 8 shows a diagram 800 visualizing a multi-symbol representation of a symbol sequence that can be used in conjunction with other compression techniques described herein to take advantage of dictionary properties based on arithmetic circuits and reduce the size of arithmetic circuits stored in a computer system or computer network, such as a node in the Bitcoin network.

[0097] In one embodiment, the dictionary size is limited (e.g., due to constraints on available computational resources) and the occurrences of symbols are correlated (e.g., lack independent probability properties). Thus, in one embodiment, the arithmetic range for compression includes symbols that aggregate functions of individual primitives, as shown in FIG.

[0098] As an illustrative example, consider the following circuit or portion of a circuit (eg, subcircuit): where the first two parameters of each operation are input identifiers and the last parameter is an output identifier. ADD 4 5 6 ADD 1 6 7 ADD 1 7 8

[0099] The above addition operation can be compressed into the following form in one embodiment: ADD3 4 5 1 1 8

[0100] In one embodiment, various factors affect the degree to which data can be compressed. For example, whether and / or how much the dictionary size is limited (fragmentation of probability ranges does not facilitate optimizing binary representation of fractional numbers), whether primitives are coded individually (probability ranges are assigned to aggregated symbols), and whether a minimum number of aggregated symbols is provided (less aggregated symbols correlate to more efficient probability range assignments). In one embodiment, an estimate of the compression parameter can be determined based on the assumption that all arithmetic operations have the same number of inputs (e.g., α). In one embodiment, an aggregated symbol OP constructed based on N primitive operators is N generates new bits for the compressed output stream at an average rate N times slower than the corresponding primitive operators. In addition, it saves N-1 input identifiers. The initial circuit size for the operations and identifiers is size OPS +size IDS If , the optimal compression is given by:

number

[0101] The probability range of an aggregate symbol can be fixed or can be automatically adjusted depending on the previous symbol. In the case of fixed probability, the sequence of symbols {s1, s2, ..., s β}, the following aggregate probability P(s1, s2,..., s β ) to define:

number

[0102] Note that there are β! (i.e., the factorial of β) different permutations of β consecutive symbols available. Note that a symbol sequence may contain one or more symbol repetitions. Due to the commutative property of multiplication, each permutation is characterized by the same aggregate symbol probabilities.

[0103] In one embodiment, the symbol depth β is dynamically changed during the encoding stage according to the content of the input stream. * is used to establish when a new range allocation is performed. * The multi-symbol range over two consecutive windows of emitted symbols can be different. Furthermore, different aggregate symbol depths βi (1≦i≦n * ) is the n defined in the current window, as shown in Figure 9. * For each of the N multi-symbol ranges, * is a constant and / or defined in the header of the serialized data.

[0104] Diagram 900 shows an illustrative example of multi-symbol encoding where stream [a,a,a] is transformed into multi-symbol s1, stream [b,b] is transformed into s2, and symbol c is transformed into s3. In this example, the aggregate symbol depths are β1=3, β2=2, and β3=1, respectively, and n * =3.

[0105] The setting of the β vector for a given current coding window is, in one embodiment, based on the setting of the previous coding window. Different weights w are assigned to the previous window:

number

[0106] Therefore, the symbol s i For step j, the aggregate symbol depth, i.e., β j (s i ) is, in one embodiment, the previous step β j-1 (s i ) and the average symbol depth of the previous j-2 steps. Using this formula, both the coder and decoder can synchronize their symbol probability ranges. Multiple weights can also be defined as follows:

number

[0107] All weights must be in the real range [0,1] and their sum must equal 1.

[0108] In one embodiment, we establish how to calculate the aggregate symbol depth and what a given aggregate symbol represents. In the previous example of Figure 8, we defined s1, symbol repeat [a], s2, symbol repeat [b], etc. If the dictionary is small enough (e.g., less than 10 symbols), the complete set of combinations can be pre-configured. For example, the set of aggregate symbol combinations may be mapped to identifiers in the following way: [Table 7]

[0109] FIG. 10 illustrates a diagram 1000 in which an operation circuit 1002 is compressed using arithmetic coding techniques to aggregate identifiers, resulting in a serialized circuit 1004 that is more compressible (e.g., compared to a system in which the identifiers are not aggregated). In one embodiment, the operators and identifiers are encoded separately, e.g., encoded using different techniques, and stored using different data structures (e.g., a first queue for the operators and a second queue for the identifiers). FIG. 10 illustrates an exemplary serialization of identifiers, according to at least one embodiment. In one embodiment, a compression process utilizing arithmetic coding techniques is applied to the operation circuit 1002 to generate a serialized circuit 1004 that is smaller in size (e.g., stored using fewer bits of data) than the operation circuit 1002. In one embodiment, the serialized circuit 1004 is smaller in size, on average (e.g., as determined based on the overall population of operation circuits or expected circuit behavior / values), than the operation circuit 1002. In one embodiment, arithmetic coding is a type of lossless compression that, when applied to the arithmetic circuit 1002, produces a result (i.e., the serialization circuit 1004) that can be perfectly (e.g., bit-for-bit accurate) reproduced by applying a lossless decompression routine to the arithmetic circuit 1002.

[0110] In one embodiment, whether an entropy scheme is utilized to encode a circuit or portion of a circuit (e.g., whether to encode an identifier, whether to encode an operator) is determined based on how the data is generated, the size of the symbols, or a combination thereof. For example, in some embodiments, identifiers are not encoded using an entropy scheme due to the random nature of their generation and / or the size of the symbols. Generally, larger circuits have more identifiers, increasing the size of the symbols.

[0111] In one embodiment, identifier aggregation can take advantage of identifier locality as part of the compression scheme. This may be suitable for use based on data locality, i.e., identifiers used in the same part of a circuit tend to have similar values. Note that this may not be the case for all circuits, and identifier aggregation may be performed based on a decision (e.g., analysis of the circuit prior to serialization) on whether to perform aggregation techniques, which are described in more detail below.

[0112] As part of the aggregation technique, the difference between two identifiers is encoded, rather than their absolute value. In one embodiment, this scheme applies to input identifiers, but not to output identifiers. In one embodiment, the output identifiers are incremental and are not needed during the encoding process, but can be removed and reconstructed based on the order in which the operations are serialized.

[0113] As an illustrative example, consider the following circuit or portion of a circuit: ADD 4 5 6 ADD 1 6 7 ADD 1 7 8

[0114] The identifier can be encoded as follows: ADD 4 1 6 ADD -4 5 7 ADD -5 6 8

[0115] The first input (4) is encoded normally. The second input is encoded as the difference between the second input and the previous input. In other words, 5 - 4 = 1. The next identifier is the output and is ignored for aggregation purposes. Continuing with the second addition operation, the third input is encoded as the difference between the third input and the second input: 1 - 5 = -4, and so on. In one embodiment, one of the advantages of this scheme is immediately realized in the context of large circuits with a large number of identifiers (e.g., a large number of identifiers requires additional data bits to encode the absolute identifier value). On average, if n bits are required to encode the identifier, fewer than n / 2 bits are required to encode the difference. In one embodiment, the input wires can be reconfigured to reduce and / or minimize the difference values ​​(e.g., fewer bits are required to encode them in a lossless and fully reproducible manner). ADD 4 1 6 ADD -4 0 7 ADD 5 1 8

[0116] Consider adding additional bits to represent the code. The first solution requires 14 bits to encode the five encoding input identifiers [1, -4, 5, -5, 6], while the second solution requires only 10 bits to encode the encoding identifier [1, -4, 0, 5, 1]. The inputs for each row can be rearranged during circuit generation to minimize the total bits required.

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

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

[0119] 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. Further, unless otherwise specified or otherwise clear from the context, the phrase "based on" means "based at least in part on" and not "based only on."

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

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

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

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

Claims

1. 1. A computer-implemented method comprising: using Domain Specific Language (DSL) code; converting the DSL code into General Purpose Language (GPL) code using a converter; precompiling the GPL code using a GPL precompiler and an external library to generate GPL preprocessor code; converting the GPL preprocessing code into an arithmetic circuit; optimizing the arithmetic circuit to generate a reduced arithmetic circuit; compressing the reduced arithmetic circuit to generate a serialized circuit; 20. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the operational circuit is a directed acyclic graph (DAG) for a set of variables.

3. The computer-implemented method of claim 2 , wherein the reduced arithmetic circuit is a minimal arithmetic circuit.

4. The computer-implemented method of claim 1 , further comprising deriving a QAP polynomial from the serialization circuit.

5. The computer-implemented method of claim 1 , wherein the DSL code includes a set of conditions, and the outcome of the DSL code depends on the satisfaction of the set of conditions.

6. 6. The computer-implemented method of claim 5, wherein the DSL code represents an insurance policy that takes as input an insured's premium and possible compensation for the insured by an insurance company.

7. 2. The computer-implemented method of claim 1, wherein the external library includes pre-written subroutines, functions, classes, containers, values, and / or variable types that are utilized by the GPL code through calls.

8. The computer-implemented method of claim 1 , further comprising deserializing and decompressing the arithmetic circuit.

9. 1. A system comprising: a processor; a memory containing executable instructions that, upon execution by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 8; A system including:

10. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least the computer-implemented method of any one of claims 1 to 8.

Images