Computer implemented methods and systems related to arithmetic coding for serialized arithmetic circuits

Abstract

The techniques described herein can be used to implement methods and systems for losslessly compressing and serializing arithmetic circuits into bitstreams using compression techniques such as arithmetic coding. Arithmetic coding can be used to compress arithmetic circuits representing smart contracts, thereby generating compressed arithmetic circuits that can be stored or broadcast to a blockchain network using fewer computing resources (e.g., data storage resources) than would otherwise be required to store the arithmetic circuits. Based on the frequency of elements in a data structure (e.g., arithmetic operator types), entropy coding can be used to efficiently compress arithmetic circuits. Instructions for deserialization and decompression can also be embedded in the bitstream and can be used (e.g., by another computer system) to reconstruct the original circuit in a lossless manner.

Description

Technical Field

[0001] The present invention generally relates to techniques for reducing the data footprint used by arithmetic circuits (e.g., when the arithmetic circuits are stored on disk or in memory), and more specifically to techniques for generating serialized circuits by utilizing compression techniques (i.e., arithmetic coding techniques described herein). Arithmetic circuits can be compressed in a lossless manner to produce serialized circuits that can be used to perfectly recreate the original circuits at a later point in time. Arithmetic circuits can be used to generate programs, the execution of which can be delegated to one or more nodes of a distributed computing environment. A protocol can be used to ensure the correct execution of a program, wherein a first computer system delegates the execution of a program to a second computer system. The present invention is particularly suitable for, but not limited to, use in a blockchain network. Background Art

[0002] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers (ledgers). These include consensus-based blockchain and transaction chain technologies, licensed and unlicensed ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Although Bitcoin may be mentioned herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention. The term "Bitcoin" is intended herein to include any protocol derived from the Bitcoin protocol or a variation thereof.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be “validated”. Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this validation work on the unspent transaction output (UTXO) by executing its locking script and unlocking script. If the execution of the locking script and unlocking script evaluates to true (TRUE), then the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction – if the transaction is validated, the node relays it to other nodes in the network; ii) the transaction is added to a new block built by miners; and iii) the transaction is mined, that is, added to the public ledger of past transactions.

[0005] Although blockchain technology is widely known for its implementation using cryptocurrencies, digital entrepreneurs have begun exploring new systems using both the cryptographic security system that Bitcoin is based on and the data that can be stored on the blockchain. It would be very advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such a solution would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while having more versatility in its applications.

[0006] One area of ​​current research is the use of blockchain to implement “smart contracts.” These are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Unlike traditional contracts written in a natural language, a smart contract is a machine-executable program that includes rules that can process inputs in order to produce results, which can then cause actions to be performed based on those results. Summary of the invention

[0007] Therefore, it is desirable to implement a verifiable computing framework (e.g., using the Bitcoin network) in which a client computer system generates a smart contract represented as an arithmetic circuit and uses encoding techniques (i.e., arithmetic coding) to compress the arithmetic circuit to generate a compressed arithmetic circuit that can be used to reduce the storage space requirements for storing and / or executing the smart contract. In turn, the compressed arithmetic circuit can be broadcast to the blockchain network and stored (e.g., stored in a node of the blockchain network) instead of the uncompressed arithmetic circuit. A worker computer system can retrieve the compressed arithmetic circuit and 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 computing protocols.

[0008] Such an improved scheme has now been devised.

[0009] Thus, according to the present invention, there is provided a system and method as defined in the appended claims.

[0010] According to the present invention, a computer-implemented method for a node of a blockchain network can be provided, the computer-implemented method comprising: obtaining a symbol set based on an arithmetic circuit representing a smart contract; reducing the amount of data used to store the arithmetic circuit by at least the following steps: mapping a subset of the symbol set to a range of encoding values, selecting an encoding value within the range of encoding values, and representing a first subset of the symbol set with the encoding value in a compressed arithmetic circuit; and storing the compressed arithmetic circuit on a node of the blockchain network.

[0011] Preferably, the compressed arithmetic circuit includes a header, wherein the header encodes information that can be used to map a set of symbol sets to different ranges of encoded 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 can be non-overlapping ranges so that a particular encoded value corresponds to exactly one symbol or set of symbols.

[0012] Preferably, the encoded value is a binary fraction, for example a binary value greater than or equal to zero and also less than one.

[0013] The coded value may be selected based on the coded value represented by a threshold number of bits. For example, between two different binary decimals within a range, the binary decimal represented by fewer bits may be selected as the coded value.

[0014] Selecting the coded values ​​may include: mapping different subsets of the set of symbols to sub-ranges of the range of coded values; selecting the coded values ​​from the sub-ranges of the range of coded values; and wherein both the first subset and the second subset of symbols are represented by the coded values ​​in the compressed arithmetic circuit.

[0015] The method may also include: obtaining a symbol set based on an arithmetic circuit representing the smart contract; receiving a request for a serialized input file, the input file comprising multiple lines of code representing the arithmetic circuit; scanning at least a portion of the multiple lines of code and adding symbols in the symbol set to a data structure; and wherein the symbol set is obtained from the data structure.

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

[0017] Preferably, the arithmetic circuit comprises operators and wire identifiers, further wherein the symbol set is the operators and the wire identifiers are respectively encoded according to an arithmetic coding scheme.

[0018] The method may further include obtaining the symbol set by parsing a file encoding the arithmetic circuit to obtain identification of a set of operators and a set of parameters for at least a portion of the set of operators.

[0019] Preferably, the range of the coded values ​​corresponds to the probability of the subset appearing in a certain pattern. For example, between two symbol sets, the symbol set with a greater probability of appearing has a relatively larger corresponding range of coded values.

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

[0021] Preferably, the compressed arithmetic circuit is broadcast to the blockchain network instead of the arithmetic circuit.

[0022] Preferably, a node of the blockchain network that receives the compressed arithmetic circuit is able to determine the arithmetic circuit from the compressed arithmetic circuit.

[0023] It is also desirable to provide a system comprising: a processor; and a memory comprising executable instructions, the executable instructions causing the system to perform any of the claimed methods due to execution by the processor.

[0024] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon, which, due to being executed by one or more processors of a computer system, cause the computer system to perform at least any of the claimed methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] These and other aspects of the invention will become apparent from and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0026] Figure 1 Serialization and deserialization of an arithmetic circuit in an embodiment of the present disclosure are shown;

[0027] Figure 2 A schematic diagram is shown, which shows an example of a swim diagram of verifiable computation and actors involved in an embodiment of the present disclosure;

[0028] Figure 3 An example of a workflow from a domain specific language (DSL) code to a quadratic arithmetic program (QAP) according to an embodiment of the present disclosure is shown;

[0029] Figure 4 A diagram showing visualization of arithmetic coding of a symbol sequence according to an embodiment of the present disclosure;

[0030] Figure 5An illustrative example of a process for compressing an arithmetic circuit using arithmetic coding according to an embodiment of the present disclosure is shown;

[0031] Figure 6 A diagram showing various schemes for implementing serialization of arithmetic circuits based on the compression property of arithmetic coding in an embodiment according to at least one embodiment;

[0032] Figure 7 An illustrative example of a process for managing serialization of an arithmetic circuit using a buffer according to an embodiment is shown;

[0033] Figure 8 A diagram showing a multi-symbol representation of a visualized symbol sequence utilizing properties of a dictionary based arithmetic circuits according to an embodiment;

[0034] Fig. 9 A diagram showing multi-symbol encoding according to an embodiment; and

[0035] Fig.10 A diagram showing compression of an arithmetic circuit by aggregating identifiers resulting in a serialized circuit that can be further compressed. DETAILED DESCRIPTION

[0036] We now provide an illustration of how the present invention can be put into practice according to one embodiment. The present invention can be implemented in the context of a distributed computing environment, wherein a first computing entity utilizes an arithmetic circuit to generate a program, the execution of which can be delegated to a computing entity of the distributed computing environment (e.g., a node of a blockchain network). In addition, the correct execution of the program is computationally verifiable, enabling a client computing entity to delegate the execution of a program generated at least in part based on an arithmetic circuit, which client computing entity can verify that the program is correctly executed by a worker computing entity. In this way, various efficiencies of a distributed computing environment can be achieved, including enabling a client computing entity to delegate the execution of a program to a computer system and verify the execution of the program under the control of another entity.

[0037] As described in more detail below, we describe a possible implementation of compressing and serializing an arithmetic circuit into a binary stream of data using arithmetic coding. The binary stream of data can be deserialized and decompressed in a lossless manner. Various advantages of serialized circuits can be achieved, such as reducing the data storage footprint of the circuit (e.g., by storing the serial circuit instead of storing the arithmetic circuit). For example, in the context of a blockchain network, an arithmetic circuit or a program derived from the arithmetic circuit can be at least partially encoded into the ledger of the blockchain network. By using the techniques described herein to reduce the data storage footprint of the arithmetic circuit, the amount of data stored in the blockchain ledger can be reduced. Even a small reduction in the data storage footprint of the data stored in the blockchain is appreciated because the blockchain ledger can be recreated by some or even all nodes of the blockchain network.

[0038] Specific structure or building block (building block) can be used to promote this conversion.In one or more embodiments, this representation can be regarded as the first step of building a comprehensive pipeline that can provide distributed verifiable computing.The building block presented in this example is not intended to be an exhaustive list of all possible high-level language constructs that embodiments of the present invention process.In addition, an alternative implementation of the example presented can be provided.These fall into the scope of those skilled in the art.

[0039] We now provide an illustrative embodiment of the present invention. However, it is important to note that this is an example of an application in which the present invention can be used. The skilled person will understand that the present invention can be used advantageously in other contexts and applications.

[0040] For our example, consider a protocol that allows users to generate applications using a domain-specific language (DSL). Once the application has been generated, its execution can be outsourced to untrusted parties (called "workers" or "provers"), while its correctness can be publicly verified. The protocol utilizes cryptographic primitives that ensure the following:

[0041] Completeness, i.e. if the protocol is followed correctly, an honest verifier will be confident of the validity of the output;

[0042] Soundness, i.e. a cheating prover cannot convince an honest verifier of the truth of the output;

[0043] Zero knowledge, i.e. a cheating validator would not learn anything other than the validity of the output.

[0044] Some benefits of this agreement may include:

[0045] Prevents man-in-the-middle attacks, as no communication between participants is required.

[0046] Due to the use of blockchain technology, it is difficult for malicious nodes to tamper with data.

[0047] Avoid using trusted third parties, such as trusted hardware devices.

[0048] Contract validation does not mean the code is re-executed. The computation is not replicated by every node in the network. Instead, evidence of honest execution is stored in the public blockchain for verification purposes only.

[0049] Such a system will be able to handle various types of applications corresponding to various tasks and products. Due to its decentralized and distributed nature, the (Bitcoin) blockchain provides a suitable environment for resolving agreements between two (or more) parties.

[0050] Such a system needs to provide and promote programmability in a decentralized cryptocurrency system. However, it has been recognized in the art that smart contract programming is 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.

[0051] Therefore, it would be advantageous to be able to use a DSL that makes applications easier to write and read by programmers, thereby reducing errors, reducing time, effort, cost and resources during the programming process. Ideally, non-professional programmers would be able to write various types of applications without having to implement cryptography. Instead, the compiler / interpreter would automatically compile the source code into a cryptographic protocol between the user and the blockchain. These are among the technical problems solved by the present invention.

[0052] Figure 1100 is an illustrative diagram of an embodiment that can be implemented according to the present disclosure. The technology described herein can be used to serialize and deserialize arithmetic circuits used in the execution of a computer program. According to an embodiment, an arithmetic circuit can be used to construct a quadratic arithmetic problem (QAP) that is compiled into a set of encryption routines for a client (e.g., key generation and verification) and a prover (e.g., calculation and evidence generation). The client and the prover can delegate the execution of the program to the prover using a protocol in a manner that allows the client to effectively verify that the prover executes the program correctly. By reducing the required computing resources (e.g., hard disk space) associated with the arithmetic circuit, the operation of the computer system can be improved using a serialized circuit. In an embodiment, the arithmetic circuit includes information represented as a symbol set (e.g., arithmetic gates and values), which is compressed to produce a serialized circuit including a code set, wherein the symbol set can be derived from the code set in a lossless manner. The transmission of the compressed circuit can improve the effective data transmission bandwidth of the computer system by enabling a greater number of circuits to be transmitted. For example, if the compressed circuit reduces the size of the arithmetic circuit by 50%, the effective data transmission bandwidth can be doubled because up to twice the compressed arithmetic circuit can be transmitted using the same number of bytes (it should be noted that the actual data transmission bandwidth improvement may be less than two times because data overhead such as packet headers that may not be compressed is taken into account). Reducing the data footprint of the arithmetic circuit can reduce the computer hardware requirements associated with the use of the arithmetic circuit (e.g., reducing the amount of short-term memory (e.g., RAM) data storage) and / or the data bandwidth utilized by a computer system that uses, stores, or otherwise interacts with the circuits described herein. The transmission of the compressed circuit can improve the effective data transmission bandwidth of the computer system by enabling a greater number of circuits to be transmitted. For example, if the compressed circuit reduces the size of the arithmetic circuit by 50%, the effective data transmission bandwidth can be doubled because up to twice the compressed arithmetic circuit can be transmitted using the same number of bytes (it should be noted that the actual data transmission bandwidth improvement may be less than two times because data overhead such as packet headers that may not be compressed is taken into account). Reducing the data footprint of arithmetic circuits can reduce computer hardware requirements associated with the use of arithmetic circuits (e.g., reducing the amount of short-term memory (e.g., RAM) data storage) and / or the data bandwidth utilized by a computer system that uses, stores, or otherwise interacts with the circuits described herein.

[0053] Typically, arithmetic circuits Includes wires carrying values ​​from field F and connected to logic and / or arithmetic gates. In an embodiment, the circuit The circuit may be represented by a set of data fields including arithmetic gates, input lines, and output lines. The circuit may also include a header including information such as a version number, the total number of lines, and a bit-width that allows optimization to be performed according to the target execution environment (e.g., processor architecture). bit Compression of the arithmetic circuit may be achieved by removing data fields that are determinable from other fields, applying an entropy coding scheme, and combinations thereof. Various types of simplification rules may be used as part of the compression routine based on the format of the encoded arithmetic circuit. For example, certain information may not be needed, such as line identifiers for inputs, line identifiers for output gates, first inputs to first gates, and last output line identifiers that may be compressed (e.g., not explicitly encoded as part of the serialization circuit), or any combination thereof.

[0054] In various embodiments, entropy coding or a coding scheme is applied to an arithmetic circuit or a portion thereof (e.g., based on the above-described simplification rules). Entropy coding can be used to generate a variable length code table for serialization of source symbols. Huffman coding can be used to generate a code table in which a shorter code is used to encode source symbols with a higher frequency of occurrence, and a longer code is used to encode source symbols with a lower frequency of occurrence—the length of the code can be inversely proportional to the frequency of occurrence of the source symbol or sequence. Using these techniques, an arithmetic circuit can be compressed into a serialized circuit that requires less computing resources for storage in long-term data storage media (e.g., hard disk drives) and short-term data storage (e.g., random access memory).

[0055] As described above, Huffman codes can be used to generate code tables. Huffman codes refer to a specific type of optimal prefix code that can be used to achieve lossless data compression. The output of the Huffman algorithm can be a variable length code table (e.g., a codebook) for encoding source symbols (e.g., characters or commands) in a file. In an embodiment, the algorithm derives a table from the estimated or measured probability or frequency (weight) of each possible value from the source symbol: more common symbols are usually represented using fewer bits than uncommon symbols. In an embodiment, Huffman coding can be effectively implemented to find a code in a time that is linearly related to the number of input weights, where the input weights are in sorted order. Among the methods for encoding symbols individually, this strategy may be the best. Huffman coding can use a specific method for selecting a representation for each symbol to generate a prefix code, that is, a bit string representing a particular symbol is never a prefix of a bit string representing any other symbol.

[0056] Given a set of size n and weights {p0,p1,…,p n-1} usually with probability proportional to the set of symbols {a0,a1,…,a n-1}, a tree with minimum weighted path length starting from the root is required. Output code C(P) = {c0, c1, ..., c n-1} is the tuple of binary codewords with minimum weighted path length L(C).

[0057] As defined by Shannon's source coding theorem, every symbol a with non-null probability i The information content h (in bits) is h(a i )=log2(1 / p i ). Entropy H (in bits) is the number of bits across the nodes with non-zero probability p i All symbols of a i The weighted sum of the information content of each symbol of :

[0058]

[0059] Entropy is a measure of the minimum codeword length that is theoretically possible for a given alphabet with associated weights. In general, Huffman codes need not be unique: the set of Huffman codes for a given probability distribution is a non-empty subset of the codes that minimize L(C) for that probability distribution.

[0060] The serialized circuit can be used to derive the original arithmetic circuit in a lossless manner using an expansion or decompression routine. It should be noted that in this context, "lossless" refers to a type of compression algorithm in which the source data is perfectly derived from the compressed data. In the context of digital compression, lossless compression can refer to each bit of the source bit stream can be derived from the compressed data including the symbol set. In contrast, lossy compression can refer to a compression algorithm in which the compressed data cannot be derived from each bit of the source bit stream - an example of lossy compression is the MP3 audio encoding format.

[0061] Figure 2 2 is a diagram showing an example of a verifiable computation and an actor's movement graph 200 involved in an embodiment of the present disclosure. Figure 2 As shown in , the graph 200 of verifiable computation may include a client node 240, a worker (e.g., a prover) node 250, and a verifier node 260 involved in executing the steps in the verifiable computation protocol in an embodiment of the present disclosure. In an embodiment, one or more of the client node 240, the worker node 250, or the verifier node 260 is a node in a blockchain network.

[0062] In an embodiment, the establishment phase involves writing the contract in a domain specific language (DSL). An interpreter, which may be a client node 240, takes the source code as input and generates an arithmetic circuit The arithmetic circuit Made up of "wires" that carry data from fields The arithmetic circuit is a directed acyclic graph (DAG) rather than a hardware circuit, and the wires can be edges in the DAG. However, it is contemplated that the arithmetic circuit can be implemented in a physical circuit with wires and logic gates. In 202, the client node 240 writes a computational program written in a general purpose language (GPL) to the client node 240. Compile to arithmetic circuit In this embodiment, the client node 240 converts the arithmetic circuit and input Provided to worker node 250.

[0063] The embodiments of the present disclosure can be implemented from the circuit Generate a quadratic program Q, which includes a set of polynomials that provide a Public parameters may then be generated for use by worker nodes 250 and verifier nodes 260 in executing and verifying the secondary program.

[0064] In 204, worker node 250 inputs Execution circuit or quadratic procedure , and claims that the output is In some embodiments, it is expected that the worker node 250 (ie, the certifier) ​​obtains Therefore, in 206, the worker node 250 encodes the transcript. In some examples, is an assignment of the value of the circuit line so that the value assigned to the input line is The intermediate value corresponds to The correct operation of each gate in , and the value assigned to the (one or more) output lines is If the claimed output is incorrect (i.e. ),but A valid copy of does not exist.

[0065] In 208, the worker node 250 will output Provided to client node 240. In an embodiment, a secret value s selected by or from client node 240 is used to derive a public evaluation key EK and a public verification key VK. In an embodiment, worker node 250 uses these public keys to evaluate a particular input In the embodiment, the output The value of the internal circuit line and EK are used to generate a proof-of-correctness π. Proof π can be stored on the blockchain and verified by multiple parties (e.g., verifier node 260) without requiring worker node 250 to interact with each party separately. In this way, verifier node 260 can use the public verification key VK and proof π to verify the payment transaction in 210, thereby verifying the contract.

[0066] Verifiable computation is a technique that allows the generation of proofs of computation. In an embodiment, a client uses this technique to evaluate an input The function f is outsourced to another computational entity (referred to herein as a worker). In some cases, the client is computationally constrained, so it is not feasible for the client to perform the evaluation of the function (e.g., the expected runtime of the computation using the computational resources available to the client exceeds a maximum acceptable threshold), although this is not necessarily the case. In general, the client can delegate the evaluation of the input based on any appropriate criteria (e.g., computational runtime, computational cost (e.g., the financial cost of allocating computational resources to perform the evaluation of the function), etc.). Evaluation of the function f.

[0067] In an embodiment, a worker is any suitable computing entity, such as a blockchain node as described in more detail elsewhere in this disclosure. In an embodiment, a worker (e.g., a blockchain node) evaluates input The proof (which may also be referred to as an argument) can be verified much faster than performing the actual computation - thus, the correctness of the proof can be verified by verifying the correctness of the proof rather than recomputing the input. Using a function f on a worker to determine the correctness of the output generated by the worker can reduce computational overhead (e.g., reducing power overhead and the costs associated with powering and running computing resources). In zero-knowledge verifiable computation, a worker provides an attestation to a client: the worker knows an input with a particular property.

[0068] An efficient variant of zero-knowledge proofs of knowledge is zk-SNARK (Succinct Non-Interactive Argument of Knowledge). In an embodiment, all pairing-based zk SNARKs include the following process: the worker uses a common group operation to compute multiple group elements, and the verifier uses multiple pairing product equations to check the proof. In an embodiment, the linear interactive proof works on a finite field, and the worker's message and the verifier's message include, encode, reference, or otherwise include information that can be used to determine the vector of field elements.

[0069] In embodiments, the systems and methods described herein allow miners (e.g., nodes) of a blockchain to perform a computation (e.g., evaluate a computation involving an input f), and generates 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 the function. In this context, the cost (i.e., how expensive) of operations and tasks can refer to the computational complexity of performing the operation or task. In embodiments, computational complexity refers to the average computational cost or the worst-case computational cost of performing a sorting algorithm—for example, both the heap sort algorithm and the quick sort algorithm have an average computational cost of O(n log n), but the worst-case computational cost of quick sort is O(n log n). 2 ), while the worst-case computational cost of heap sort is O(n log n). In an embodiment, evaluating the input The average computational cost and / or the worst case computational cost of the function f is worse. Thus, use of the systems and methods described herein is highly advantageous and may, for example, allow more computationally expensive contracts to be run because such contracts do not proportionally increase the time required to verify the blockchain. Further advantages may include reducing the power consumption of the verifier system, thereby increasing the efficiency of the verifier computer system and reducing the energy costs associated with running such a verifier computer system when evaluating the correctness of a proof.

[0070] In an embodiment, the verification key V K Or part of it can be extracted from the public parameters and input / output data generated in the setup phase of the zero-knowledge protocol and used with the proof π, which is used to verify the so-called proof of correctness of the computation provided by the worker. For example, as described above and in more detail below, the system and method that allows the locking script to prevent the verification key V K The validity of the proof π is changed and checked, thereby allowing the execution of zero-knowledge protocols on the blockchain during transaction verification. Therefore, the present disclosure proposes systems and methods for performing the verification phase using a blockchain script (e.g., in a Bitcoin-based network) that is used to store elements used in the verification of the computation.

[0071] Figure 3 An example 300 of a workflow from a domain-specific language (DSL) code to a quadratic arithmetic program (QAP) according to an embodiment of the present disclosure is shown. Specifically, Figure 3Depicted is DSL code 302 converted by converter 304 to GPL code 306. GPL precompiler 308 (also referred to as a preprocessor) merges external libraries 310 referenced by GPL code 306 to produce GPL preprocessed code 312. GPL preprocessed code 312 is converted to arithmetic circuits 314, which are optimized to produce simplified arithmetic circuits 316, which are compressed to produce serialized circuits 320 from which QAP polynomials 318 are derived.

[0072] In an embodiment, the domain specific language (DSL) code 302 is an application program written in a formal language with precise semantics. In an embodiment, the DSL code 302 includes a set of conditions, and the result of the DSL code 302 depends on the fulfillment of the set of conditions. An example of an application program (e.g., a smart contract) is an insurance contract that takes as input an insurance premium of an insured and potential compensation from the insurer to the insured. If the insured suffers a loss during the smart contract period (e.g., fulfilling the first condition), the execution of the smart contract will allocate the premium to the insurer and the compensation for the loss to the insured. On the other hand, if the insured does not suffer a loss during the smart contract period, the execution of the smart contract will allocate the premium to the insurer and return the potential compensation to the insurer.

[0073] In an embodiment, converter 304 is a software program that receives a set of conditions (e.g., DSL code 302 written in DSL) and converts the DSL code into GPL source code (e.g., GPL code 306) due to execution. In an embodiment, GPL code 306 is a GPL program (e.g., a C++ program) that contains the code defined in DSL code 302. In some examples, a general programming language or "general language" (GPL) is more widely applicable than a DSL. 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++, which may be cited in the embodiments of the present disclosure, is a general-purpose programming language with imperative, object-oriented, and general-purpose programming features, while also providing facilities for low-level memory manipulation. It should be noted that in Figure 3In the context of , "code" may refer alternatively to executable code (eg, object code), source code, both, either or a combination of the two, depending on the context being described.

[0074] In an embodiment, GPL precompiler 308 is a computer executable program that processes GPL code 306 and required external libraries 310 to produce standalone GPL preprocessed code 312. In an embodiment, GPL precompiler 308 evaluates constant expressions and registers symbols found in GPL code 306.

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

[0076] In an embodiment, the GPL preprocessed 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 to (==), greater than or equal to (>=), etc.), conditional statements (e.g., if-then (?, :)), or logical operators (e.g., and (&&), or (||), not (!), exclusive or (⊕), etc.). In some embodiments, the main function is generated to have a predetermined name and format.

[0077] In an embodiment, arithmetic circuit 314 is a DAG over a set of variables. In an embodiment, each node of the DAG with an in-degree of zero is a node representing a variable (e.g., x i ), and every other node of the DAG is either an addition gate (+) or a multiplication gate (×). In an embodiment, the out-degree of each gate (node) is 1, so the underlying graph is a directed tree. In an embodiment, arithmetic circuit 314 has two complexity measures: size and depth. In some examples, the "size" of the arithmetic circuit is based on the number of gates within arithmetic circuit 314. In some examples, the "depth" of the arithmetic circuit is based on the length of the longest directed path within the arithmetic circuit.

[0078] In an embodiment, the simplified arithmetic circuit 316 is a simplified or minimized directed acyclic graph (DAG) that can be used to determine the result of a set of conditions (e.g., those specified in the DSL code 302) given a set of inputs. In some embodiments, the simplified arithmetic circuit 316 is a minimized (i.e., reduced to a minimum) arithmetic circuit. In some embodiments, the optimal arithmetic circuit may not necessarily be the smallest arithmetic circuit (e.g., depending on the number and type of arithmetic operations in the circuit, some larger arithmetic circuits may be evaluated faster than larger arithmetic circuits), and in such embodiments, the simplified arithmetic circuit 316 is optimized (e.g., for maximum speed, less memory usage, most efficient processor utilization, etc.), but not necessarily a minimized arithmetic circuit. The simplified arithmetic circuit 316 can be generated using the techniques described in UK patent application number GB 1718505.9.

[0079] Arithmetic circuits such as simplified arithmetic circuit 316 may be compressed according to the techniques described herein to generate serialized circuit 320. Serialized circuit 320 may be used in situations where code templates or standard applications need to be stored and retrieved. By utilizing serialized circuit 320, parties may avoid the need to create circuit instances from the GPL each time a new application is created, thereby increasing the efficiency of the protocol in which clients and provers reuse certain code templates or portions thereof. Serialized circuit 320 may be generated using entropy encoding of the most frequent elements in a data structure (e.g., arithmetic operator types). Instructions for deserialization and decompression (e.g., a codebook for mapping serialized codes to source symbols) may be embedded in a serialized bitstream that enables a recipient of the serialized circuit to reconstruct the source circuit.

[0080] In an embodiment, QAP polynomial 318 is one or more expressions including variables and coefficients expressed as a mathematical formula that provides a mathematical representation of the original arithmetic circuit (e.g., Figure 3 A complete description of the arithmetic circuit 314 of FIG. 314 is provided. In an embodiment, the polynomials of the QAP polynomials are defined according to their evaluations at the roots of arithmetic circuits, such as those described in Gennaro, R. et al., Quadratic Span Programs and Succinct NIZKswithout PCPs (2013). In an embodiment, the QAP polynomials are encoded into a locking script of a blockchain transaction as a representation of a smart contract. In an embodiment, the locking script receives a set of parameter values ​​when executed (e.g., as a result of executing the locking script), which are input as variables into the QAP polynomial to result in determining the outcome of the smart contract.

[0081] In an embodiment, GPL precompiler 308 generates GPL preprocessed code 312, which may be an arithmetic circuit including arithmetic gates. However, please note that the complex arithmetic circuit also embeds logic submodules due to conditional and flow control statements.

[0082] Figure 4 A diagram 400 is shown of an arithmetic encoding of a visualization symbol sequence according to an embodiment of the present disclosure. Figure 4 The process for generating an arithmetic code for a sequence of symbols is performed by using the diagram shown. Arithmetic coding is a type of entropy coding used in lossless data compression. Symbol sets are usually represented using a fixed number of bits per symbol, as in ASCII code, and frequently used symbols can be stored with fewer bits. Unlike Huffman coding, arithmetic coding encodes the entire message into an arbitrary precision range [x, y), for example, a range between zero and one (0 ≤ x <y<1)。

[0083] For example, Figure 4 The arithmetic coding of the symbol sequence {a1, a2, a1} is shown, which can be encoded using an arbitrary range of precision. In an embodiment, the symbol is encoded in the range between 0 and 1 (e.g., inclusive and / or exclusive). In an embodiment, the symbol is encoded in the range between 0 and 2 n In the range between, including the endpoints and / or excluding the endpoints. Figure 4 , examples include a set of value ranges corresponding to the first symbol in the sequence. For example, the value in the range [0, x1) corresponds to the first symbol as a0, the value in the range [x1, y1) corresponds to the first symbol as a1, and the value in the range [y1, 1) corresponds to the first symbol as a2. In an embodiment, each value range can be further divided into values ​​corresponding to the second symbol in the symbol sequence. For example, according to Figure 4 , let x1<w2<x2<y2=y1. Then, for this example, it follows that the following two symbol sequences are encoded using the following value ranges:

[0084] <![CDATA[a1a0]]> <![CDATA[[x1,w2)]]> <![CDATA[a1a1]]> <![CDATA[[w2,x2)]]> <![CDATA[a1a2]]> <![CDATA[[x2,y1)]]>

[0085] In various embodiments, for a character from alphabet A of size n with probability p i Any given set of symbols a i , the arithmetic encoder can produce almost optimal output, where the optimal value is -log2p iThe data model can be defined by predicting which patterns will be found in the symbols of the message: accurate prediction ensures near-optimal output. In an embodiment, the adaptive model changes its estimate of the current probability of a symbol based on previous symbols. In an embodiment, the decoder utilizes the same model as the encoder.

[0086] The encoding and decoding of symbols may be performed using various techniques described in more detail below: At each step j of the encoding process, the current interval [x j ,y j ] and the current probability p j The new symbol is encoded (as described elsewhere in this disclosure, embodiments excluding the endpoint and / or including the endpoint are considered within the scope of this disclosure). According to various embodiments, at step j, p j (a i ) is limited to a i In an embodiment, the universal symbol p is iff the adaptive model is not used. i Valid. The encoder divides the current interval into subintervals, each of which represents a portion of the current interval proportional to the probability of that symbol. With probability p j (a i ) input symbol a i The subinterval of becomes the updated interval [x j+1 ,y j+1 ]:

[0087]

[0088] y j+1 =x j+1 +(y j -x j ) j (a i )

[0089] Once all symbols of the sequence have been encoded, the resulting interval corresponds to (e.g., unambiguously identifies) the entire sequence of symbols. Figure 4 As shown, the value falls within the interval marked as "final range" (e.g., including and / or excluding the endpoints). For example, in an embodiment, the following table can reflect the sequence of symbols and the corresponding range representing the sequence:

[0090]

[0091]

[0092] In addition, it should be noted that Figure 4 The intervals or value ranges shown in are not necessarily to scale. Figure 4Nor does it imply a ratio of some intervals to other intervals. In an embodiment, the intervals are proportional or substantially proportional to the probability of the symbol occurring (e.g., proportional to a certain precision threshold due to rounding values). In an embodiment, the probability of a symbol at step j+1 depends on the previous symbol at step j. In an embodiment, the probability of a symbol occurring at step j has a memoryless property, where the distribution of the symbols occurring at j+1 does not depend on the value of any previous symbol.

[0093] In an embodiment, the symbol sequence can be reconstructed knowing the interval (or any fractional number in the interval) and the probability model. If the stream is not terminated internally, for example using a probability model with its own probability p EOS The EOS (end of stream) symbol a EOS , an external mechanism can be used to interrupt the decoding process. In some cases, different equally-short decimal fractions can be used to represent the same interval. Therefore, according to an embodiment, a binary representation with fewer bits can be selected to maximize the compression factor. For example, two decimals in the range [0.65, 0.67) can be represented with very different numbers of bits, thereby affecting the compression factor of the sequence:

[0094] Decimal Binary decimals 0.65 0.10100110011001100110011001100110011... 0.6666259765625 0.1010101010101

[0095] Therefore, in an embodiment, techniques are utilized to reduce (or minimize) the number of bits used to encode a sequence of symbols. In embodiments where an integer number of bits is used in the binary encoding, the arithmetic encoder may introduce a maximum overhead of 1 bit in the size of the compressed message. The arithmetic encoder may operate under a fixed precision limit ψ that the decoder is able to match, and round decimals to the nearest equivalent value at that precision. For example, three symbols with equal probability p=1 / 3 require infinite precision to correctly represent three intervals in [0,1). In an embodiment, a precision value may be selected, such as ψ=8 bits, and used to calculate the binary range at that precision, as follows:

[0096]

[0097] In an embodiment, when one or more numbers are shared between the two limits of the current encoding range, those numbers are appended to the output stream and discarded. The remaining numbers in the encoding range are shifted to the left, and new numbers are added to the right: one for the upper limit and zero for the lower limit. Thus, the system maintains the work on ψ bits of precision by excluding bits that no longer contribute to the calculation precision.

[0098] As for the upper bound of compression, given a message of size L and an alphabet A, the symbol frequency f(a j ), you can use LC bits to represent encoded decimals with infinite precision:

[0099]

[0100] L C Dividing by L gives the self-entropy of the message, i.e., the arithmetic coding asymptotically encodes to approach the entropy:

[0101]

[0102] Therefore, arithmetic coding can substantially approximate the entropy of a probability model whose symbol probability is the same as that of the input message.

[0103] It should be noted that arithmetic coding does not compress one symbol at a time, so it can get arbitrarily close to the entropy limit. In contrast, Huffman coding does not reach the entropy limit unless all symbol probabilities are powers of 2. Consider the following example: two symbols {0,1} with low entropy (p0=0.95, p1=0.05). Although Huffman coding assigns 1 bit to each value, resulting in a code that is the same length as the input, arithmetic coding approaches the optimal compression rate:

[0104]

[0105] Figure 5 An illustrative example of a process 500 for compressing an arithmetic circuit using arithmetic coding according to an embodiment of the present disclosure is shown. Figure 4 The techniques described herein may be used to perform some or all of process 500 (or any other process described herein, or variations and / or combinations thereof). Process 500 illustrates steps that may be implemented to generate a serialized circuit from an arithmetic circuit. As a result of serializing the arithmetic circuit using the arithmetic coding techniques described herein, a compressed representation of the arithmetic circuit may be stored instead of storing the arithmetic circuit—for example, in an embodiment, the serialized circuit may be broadcast to nodes of a blockchain network instead of broadcasting the arithmetic circuit to nodes of the blockchain network, thereby reducing data storage requirements for nodes of the blockchain network (e.g., those nodes that maintain a copy of the blockchain ledger).

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

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

[0108] In an embodiment, the system obtains 504 a mapping of symbols to sub-ranges of the interval range. The initial interval range may span a global minimum and a global maximum (eg, all encoded symbols fall within the global minimum / maximum). Unless otherwise noted, the above and below herein are combined Figure 5 The endpoints described may be inclusive or exclusive (e.g., the range may include the lower bound and exclude the upper bound). In an embodiment, the global minimum is 0 (inclusive) and the global maximum is 1 (exclusive) so that the entire range of values ​​can be represented by a binary fraction with a value less than 1. The mapping may refer to a mapping table that divides the initial interval range into a set of non-overlapping sub-ranges so that the sub-ranges together cover the entire initial interval range. In an embodiment, each sub-range is mapped to a symbol or a symbol set. In an embodiment, the system determines 506 the next interval range based on the mapping and the previous one or more symbols. In an embodiment, the system determines by finding a mapping table entry corresponding to the previous one or more symbols, and selects the sub-range corresponding to the previous one or more symbols as the next interval range. In an embodiment, if the mapping fails (e.g., there is no mapping table entry for the previous one or more symbols), the process terminates prematurely with an error. For example, if the global range is [0, 1), the following mapping table may exist for the symbol set:

[0109] <![CDATA[a1]]> [0,0.3) 30％ <![CDATA[a2]]> [0.3,0.8) 50％ <![CDATA[a3]]> [0.8,1) 20％

[0110] In an embodiment, the system determines 508 whether there are more symbols to encode after determining the sub-range for the previous one or more symbols. In an embodiment, the determination is made by determining whether there are additional symbols in the data structure (e.g., after popping the previous one or more symbols from the data structure). If there are additional symbols, then in an embodiment, the system obtains a mapping of the symbols to the previously determined sub-ranges. In an embodiment, the sub-range is proportionally the same as the previous range, such as in the following cases:

[0111] <![CDATA[a2a1]]> [0.3,0.45) 30％ <![CDATA[a2a2]]> [0.45,0.7) 50％ <![CDATA[a2a3]]> [0.7,0.8) 20％

[0112] In an embodiment, the system uses the second mapping to determine an interval range corresponding to the symbols processed so far for a second set of one or more symbols. In an embodiment, these steps are repeated until no more symbols remain (the data structure storing the symbols is empty, the end of the file is reached, etc.), so that the last sub-range is retained and used to encode the value. For example, continuing with the previous example, if the entire symbol set is a2a3, the final interval range is [0.7, 0.8). Therefore, in this example, any binary decimal value between 0.7 (inclusive) and 0.8 (exclusive) can be used to represent the symbol a2a3.

[0113] Once the final interval range is obtained, the system encodes the symbol using the 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 Examples of invalid values ​​for encoding a2a3 include: 0.8. Since there may be multiple suitable values ​​for encoding the symbol set, a binary representation with fewer bits can be chosen to maximize the compression factor.

[0114] In an embodiment, an operator and / or a line identifier (or a portion thereof) may be used as described in accordance with Figure 5 The resulting serialized circuit may be stored 514, for example, on a blockchain ledger, rather than the arithmetic circuit being stored, for example, on a blockchain ledger, thereby reducing the storage requirements for encoding the represented smart contract.

[0115] In an embodiment, Figure 6 600 illustrates various schemes that can be implemented to serialize arithmetic circuits based on the compression properties of arithmetic coding according to at least one embodiment. In an embodiment, the serialization process is performed by providing a buffer (in Figure 6 In an embodiment, the bit buffer temporarily stores the data before it is transferred to a permanent storage support or sent over a network. Figure 6 As shown, the buffer can be accessed using (at least) the following methods: put() function, which is used to insert input data x into the buffer, in an embodiment, using n b bits to store x; send() function, which is used to flush the buffer and transfer data to the output stream out.

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

[0117] In an embodiment, a third abstraction layer is provided by a function such as scan() that reads a line by line from an input (e.g., Figure 6 602) reads the data and calls the underlying method to write the typed data. Figure 6 The scan() function shown corresponds to the following routine: if the routine is called, it checks whether each command in the file can be mapped to one of the underlying methods. In an embodiment, an error in the mapping (e.g., due to detection of an unrecognizable command, an incorrect signature format, an incorrect (e.g., deprecated) function version, etc.) may cause the entire encoding process to fail.

[0118] In an embodiment, the serialise() function of the highest abstraction layer reads compressed information from an input file including circuit information and sends the compressed information to an output stream. In an embodiment, the output stream is a file or a network resource.

[0119] In an embodiment, the line of the file including the circuit has the following format, where P is the number of parameters for the operator OP. In an embodiment, the operator requires a specific number of parameters. In an embodiment, the parameters can be classified into in parameters (input parameters), out parameters (output parameters), in-out parameters (parameters that provide input values ​​to the operation and are used as storage results of the operation), etc. In an embodiment, a separate data structure is used to compress the operator and the parameters. In an embodiment, different compression techniques are used for different data structures. In an embodiment, any appropriate data (e.g., queues, stacks, vectors, etc.) can be used to implement the data structure. In an embodiment, the operators in the operator queue are required to have a fixed number of parameters and / or fixed size parameters (e.g., variable length data blobs are not supported). For example, the "addition (ADD)" operation stored on the data structure may just require two input parameters and one output parameter. It should be noted that the operations stored in the queue may be different from those at a higher level of abstraction, for example, and in general, addition operations (e.g., a+b+c+...) can be performed on any number of input parameters. In an embodiment, the data structure has multiple variations of operations to accommodate different function signatures—for example, the data structure may support an "ADD2" operation that supports two inputs and an output that represents the sum of the two inputs, and an "ADD3" operation that supports three inputs and an output parameter for the sum of the three inputs, etc. Thus, in an embodiment, multiple addition operations with a fixed number of inputs may be used to chain together sums of an arbitrary number of inputs.

[0120] In an embodiment, a data field with a dynamic (e.g., variable) size may be embedded in a serialized packet. As an illustrative example, consider the case of serializing 4 compressed data blocks [data1, data2, data3, data4] of the same size (16 bits). In an embodiment, the following encoding scheme may be used to compress the data blocks: a first field of constant size, which includes the size (e.g., in bits) of a field reserved for the number of data packets in the payload; a second field of constant size (e.g., the same or different size as the first field), which includes the size in bits of a field reserved for the data packets in the payload; a third field, which includes the number of data packets in the payload; and the remaining fields, which include the data packets. This is merely an illustrative example of how to embed a dynamic data field. In an embodiment, in a nested and / or sequential mode, a first data field encodes the size of a first data structure following the first data field, which in turn may include a second data field, which encodes the size of a second data structure following the second data field, and so on.

[0121] In an embodiment, a header for a serialization circuit includes one or more encoded fields, such as those described in detail below. In an embodiment, a version field provides information about how to interpret and / or construct the rest of the header and may have a fixed size (e.g., 1 byte). In an embodiment, the header includes a parameter M that indicates the number of symbols used for an operation. In an embodiment, the parameter is encoded using a fixed number of bits that is determined based on the maximum number of operators supported by the serialization circuit. In an embodiment, the number of input lines (IN), the number of output lines (OUT), the size of the encoding of the line identifier (n) may be encoded, for example, using a hard-coded number of bits. w ) and the encoding size of the parameters (n params ) is encoded. In an embodiment, the total number of lines N has n w It should be noted that the header need not necessarily be located at the beginning or header of the serialization circuit data file. In embodiments, the header need only be located at some point in the serialization circuit before the data related to the header information - for example, if the header includes a parameter for the total number of lines N, then in embodiments, the header information N is encoded at any suitable point in the serialization circuit so that it is read before the data encoding the line identifier.

[0122] In an embodiment, the header includes an embedded dictionary. In an embodiment, the maximum encoding size for Huffman coded symbols is added first, and then each pair (symbol size, symbol) is added using the maximum encoding size of the first element. In an embodiment using arithmetic coding, n params is an optional parameter of the header (e.g., it can be omitted). In an embodiment, the probability of each symbol (using the encoding size n) can be directly prob ), or a probabilistic scheme may be provided and the entire set may be represented using multiplication coefficients. For example, consider the case where 4 symbols are used with the following probabilities: p1=0.1, p2=0.4, p3=0.1, p4=0.4, then the entire set [1,4,1,4] may be represented using multiplication coefficients. In an embodiment, these coefficients are encoded separately (e.g., using a code size n coeff ) or represented as a scheme template with a unique identifier (e.g., using an encoding size n pid In an embodiment, the header also includes n prob And / or encode a table mapping symbols to identifiers.

[0123] In an embodiment, arithmetic coding uses a range of values ​​to represent a sequence of operators according to the probabilities encoded in the header. In an embodiment, the operator may be represented as described elsewhere in this disclosure, for example in combination with Figure 4The associated description is used to calculate the precision of the encoding range. In embodiments, such as those using Huffman coding, each compressed symbol corresponding to an operator is sequentially added to the payload.

[0124] In an embodiment, each line identifier is sequentially added to the payload, such as when Huffman coding is used. In an embodiment, different strategies may be used to encode the line identifiers using arithmetic coding, such as one or more of the following: sequential encoding (e.g., according to Huffman coding), arithmetic coding (e.g., according to an operator), aggregation of identifiers (e.g., as in the following combination Figure 8 described in more detail).

[0125] Figure 7 An illustrative example of a process 700 for managing serialization of an arithmetic circuit using a buffer is shown in accordance with an embodiment. Figure 5 and Figure 6 The described techniques may be used to perform some or all of process 700 (or any other process described herein, or variations and / or combinations thereof).

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

[0127] In an embodiment, a smart contract is written in a domain-specific language (DSL) code with precise semantics - in an embodiment, a smart contract includes a set of conditions and one or more results, the fulfillment of which depends at least in part on the evaluation of the condition set based on one or more inputs. In an embodiment, the DSL code is converted into a 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 an embodiment, a GPL precompiler uses an external library to process GPL code to produce an independent GPL-preprocessed smart contract. In an embodiment, arithmetic circuits are constructed by representing symbols using lines connected to basic arithmetic gates.

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

[0129] In an embodiment, different numbers of bits may be used to encode 708 different types of variables, depending on the specific configuration of the encoder. The encoding technique may be based on a combination of Figure 5Those techniques described in more detail. For example, the encoding of header data, operator data, and line identifier data can each utilize different techniques such as arithmetic coding techniques to encode data. Different encoding techniques can be used for different types of operations. In an embodiment, once the data has been encoded, the data is inserted into a buffer. In an embodiment, the command for inserting 710 data into the buffer is a command to write a specific number of bits of data to the output stream. Then, the system can determine 712 whether the end of the file has been reached (for example, by detecting whether a bit or character sequence has been reached at the end of a specific file). In an embodiment, if there are more commands for the file to be processed, the system sequentially scans the file to obtain the second line, the third line, the fourth line, etc. of the file, and processes it according to the above steps 704-710. These steps can be repeated until the end of the file is detected, at which time the system can flush 714 the buffer and transfer all data to the output stream or file, thereby generating a serialization circuit.

[0130] Figure 8 A diagram 800 is shown that visualizes a multi-symbol representation of a symbol sequence that exploits the properties of a dictionary based arithmetic circuit and can be used in conjunction with other compression techniques described herein to reduce the size of arithmetic circuits stored on a computer system or computer network (e.g., a node of a Bitcoin network).

[0131] In an embodiment, the size of the dictionary is limited (e.g., due to limitations on available computing resources), and the occurrences of symbols are correlated (e.g., lack independent probabilistic properties). Therefore, in an embodiment, the arithmetic range used for compression includes aggregating symbols of the functions of the individual primitives, such as Figure 8 shown.

[0132] As an illustrative example, consider the following circuit or portion (e.g., subcircuit) of a circuit, where the first two parameters of each operation are input identifiers and the last parameter is an output identifier:

[0133] ADD 4 5 6

[0134] ADD 1 6 7

[0135] ADD 1 7 8

[0136] In an embodiment, the above addition operation can be compressed into the following form:

[0137] ADD3 4 5 1 1 8

[0138] In embodiments, the degree to which data can be compressed is affected by various factors, such as whether the dictionary size is limited and / or to what extent the dictionary size is limited (probability range fragmentation is not convenient for optimization of binary representation of decimals); whether primitives are encoded separately (probability ranges assigned to aggregate symbols); and providing a minimum number of aggregate symbols (fewer aggregate symbols are associated with more efficient probability range allocation). In embodiments, an estimate of compression performance can be determined based on the assumption that all arithmetic operations have the same number of inputs (e.g., α). In embodiments, the aggregate symbol OP built on the N primitive operators is N Generates new bits for the compressed output stream at an average rate N times slower than the corresponding primitive operator. In addition, N–1 input identifiers may be spared. If the initial circuit size for the operation and the identifier is size OPS +size IDS , then the best compression method is given as follows:

[0139]

[0140] The probability range of the aggregated symbol can be fixed or can be automatically adjusted based on the previous symbol. In the case of fixed probability, we define the symbol sequence {s1,s2,…s β} Define the following aggregation probability P(s1,s2,…s β )

[0141]

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

[0143] In an embodiment, the symbol depth β is dynamically modified during the encoding phase, depending on the content of the input stream. In an embodiment, a number of emitted symbols N* is used to establish when a new range allocation is performed. In an embodiment, the multi-symbol ranges across two consecutive windows of N* emitted symbols may be different. Furthermore, a different aggregate symbol depth β may be defined for each of the n* multi-symbol ranges defined in the current window. i (1≤i≤n*), such as Fig. 9 In an embodiment, N* is constant and / or defined in a header of the serialized data.

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

[0145] In an embodiment, the setting of the β vector for a given current coding window is based on the setting of the previous coding window. Different weights w may be assigned to previous windows, for example:

[0146]

[0147] Therefore, in the embodiment, for the symbol s i The aggregate symbol depth at step j (i.e., β j (s i )) can be approximately represented as the previous step β j-1 (s i ) to the nearest integer of the weighted sum between the average symbol depth in the previous j-2 steps. Using this formula, both the encoder and the decoder are able to synchronize their symbol probability ranges. Multiple weights can also be defined as:

[0148]

[0149] All weights are real numbers in the range [0, 1] and their sum must equal 1.

[0150] In an embodiment, we establish how to calculate the aggregation symbol depth, and establish what a given aggregation symbol represents. Figure 8 In the previous example of , we defined s1 to be the repetition of symbol [a], s2 to be the repetition of symbol [b], and so on. If the dictionary is small enough (e.g., less than 10 symbols), then the entire set of combinations can be pre-arranged. For example, the set of aggregate symbol combinations can be mapped to identifiers as follows:

[0151] Identifier Aggregation symbol combination 0 [a,a,a,…] 1 [a,b,a,b,a,b,…] 2 [a,b,b,a,b,b,a,b,b,…] 3 [a,c,a,c,a,c,…] … …

[0152] Fig.10 Diagram 1000 is shown in which an arithmetic circuit 1002 is compressed using an arithmetic coding technique to aggregate identifiers, thereby producing a serialized circuit 1004 that can be further compressed (e.g., compared to a system in which the identifiers are not aggregated). In an 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 operators and a second queue for identifiers). Fig.10An exemplary serialization of an identifier according to at least one embodiment is shown. In an embodiment, a compression process using an arithmetic coding technique is applied to an arithmetic circuit 1002 to generate a serialized circuit 1004 that is smaller in size (e.g., uses fewer bits of data to store) than the arithmetic circuit 1002. In an embodiment, the average size of the serialized circuit 1004 (e.g., determined based on a population of arithmetic circuits or expected circuit operations / values) is smaller than the arithmetic circuit 1002. In an embodiment, arithmetic coding is a lossless compression that, if applied to the arithmetic circuit 1002, produces a result (i.e., the serialized circuit 1004) that can perfectly reproduce (e.g., bit-by-bit accuracy) the arithmetic circuit 1002 by applying a lossless decompression routine.

[0153] In an embodiment, whether to utilize an entropy scheme to encode a circuit or a 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 symbol, or a combination thereof. For example, in some embodiments, an entropy scheme is not used to encode the identifier due to the randomness of identifier generation and / or the size of the symbol. Generally speaking, larger circuits have more identifiers, thereby increasing the size of the symbol.

[0154] In an embodiment, aggregation of identifiers may exploit locality of identifiers as part of a compression scheme, which may be suitable for use based on data locality, that is, identifiers used in the same portion of a circuit tend to have similar values. It should be noted that this is not true for all circuits, and aggregation of identifiers may be performed based on a determination of whether to perform the aggregation techniques described in more detail below (e.g., analysis of the circuit prior to serialization).

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

[0156] As an illustrative example, consider the following circuit or portion of a circuit:

[0157] ADD 4 5 6

[0158] ADD 1 6 7

[0159] ADD 1 7 8

[0160] Identifiers can be encoded as follows:

[0161] ADD 4 1 6

[0162] ADD -4 5 7

[0163] ADD -5 6 8

[0164] 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 an embodiment, one of the advantages of this scheme is easy to understand in the case of large circuits with many identifiers (e.g., large identifiers require additional bits of data to encode the absolute identifier value). On average, if n bits are required to encode the identifier, less than n / 2 bits are required to encode the difference. In an embodiment, the input lines can be rearranged so as to reduce and / or minimize the value of the difference (e.g., fewer bits are required to encode it in a lossless and perfectly reproducible manner):

[0165] ADD 4 1 6

[0166] ADD -4 0 7

[0167] ADD 5 1 8

[0168] Taking into account the extra bits needed to represent the sign, the first solution requires 14 bits to encode the 5 encoded input identifiers [1,-4,5,-5,6], while the second solution only requires 10 bits to encode the encoded identifier [1 -4 0 5 1]. The inputs to each line can be rearranged during circuit creation to minimize the total number of bits required.

[0169] Therefore, the description and drawings should be considered illustrative rather than restrictive. However, it is obvious that various modifications and changes can be made thereto without departing from the scope of the invention as set forth in the claims. Similarly, other variations are also within the scope of the present disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, some of its illustrated embodiments are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the present invention to one or more specific forms disclosed, but on the contrary, the present invention is intended to cover all modifications, alternative constructions and equivalent forms that fall within the scope of the invention as defined in the appended claims.

[0170] In the context of describing the disclosed embodiments (particularly in the context of the appended claims), unless otherwise stated or clearly contradicted by the context, the use of the terms "one" and "a kind of" and similar references should be interpreted as covering both singular and plural forms. Unless otherwise stated, the terms "comprising", "having", "including" and "containing" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" should be understood as partially or completely contained, attached or connected together when it is unmodified and refers to a physical connection, even if there are some intervening objects. Unless otherwise noted, the description of the numerical range in the present disclosure is intended only to be used as a shorthand method of referring to each individual value falling within the range, and each individual value is incorporated into the specification as if it were listed separately. Unless otherwise stated or contradicted by the context, the use of the term "set" (e.g., "a set of items") or "subset" should be interpreted as a non-empty set including one or more members. Furthermore, unless otherwise indicated or contradicted by the context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but rather, the subset and the corresponding set may be equal.

[0171] Unless expressly stated otherwise or clearly contradicted by context, combined language such as phrases of the form “at least one of A, B, and C” or “at least one of A, B, and C” is generally understood using the context to indicate an item, term, or the like that may be A or B or C, or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set having three members, the combined phrases “at least one of A, B, and C” and “at least one of A, B, and C” refer to any one of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such combined language is generally not intended to imply that certain embodiments require the presence of at least one A, at least one B, and at least one C. Furthermore, unless stated otherwise or clear from the context, the phrase “based on” means “based at least in part on” rather than “based solely on.”

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

[0173] The use of any and all examples or exemplary language (e.g., "such as") provided is intended merely to better illustrate embodiments of the invention and does not limit the scope of the invention unless otherwise required. No language in the specification should be construed as indicating any non-claimed element is essential to the practice of the invention.

[0174] Embodiments of the present disclosure are described, including the best mode known to the inventor for carrying out the present invention. Variations of those embodiments will become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventor expects that skilled technicians will appropriately adopt such variations, and the inventor hopes that the embodiments of the present disclosure can be practiced in a manner different from that specifically described. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter recorded in the appended claims as permitted by applicable law. Moreover, unless otherwise noted or clearly contradictory to the context, any combination of the above elements in all possible variations thereof is covered by the scope of the present disclosure.

[0175] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in parentheses shall not be interpreted as limiting the claims. The words "comprise" and "comprising" etc. do not exclude the presence of elements or steps other than those listed in any claim or in the entire specification. In this specification, "comprise" means "include or consist of...", and "comprising" means "including or consist of...". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present invention can be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be implemented by one and the same item of hardware. The fact that certain measures are recorded in mutually different dependent claims does not mean that a combination of these measures cannot be used advantageously.

Claims

1. A computer-implemented method comprising: Obtaining a symbol set based on an arithmetic circuit representing a smart contract by: parsing a file encoding the arithmetic circuit to identify a set of operators and a set of line identifiers for at least a portion of the set of operators, wherein the line identifiers are inputs and / or outputs of the operators, and wherein the symbol set is the operators and / or the line identifiers; The amount of data used to store the arithmetic circuit is reduced by at least the following steps: Map a subset of the symbol set to a range of coded values; Select a code value within a range of code values; as well as representing a first subset of the symbol set using the coded values ​​in a compressed arithmetic circuit, wherein the operator and the line identifier are separately coded according to an arithmetic coding scheme; as well as The compressed arithmetic circuits are stored on the nodes of the blockchain network.

2. A method according to any one of the preceding claims, wherein: The compressed arithmetic circuit includes header encoding information that can be used to map the set of symbol sets to different encoding value ranges.

3. A method according to any one of the preceding claims, wherein: The coded value is a binary number.

4. A method according to any one of the preceding claims, wherein: The coded value is selected based on coded values ​​representable using a threshold number of bits.

5. A method according to any one of the preceding claims, wherein: Selecting the encoding value includes: Mapping different subsets of the symbol set to subranges of the encoding value range; selecting the code value from a sub-range of a range of code values; and Therein, both the first subset and the second subset of symbols are represented by said encoded values ​​in the compressed arithmetic circuit.

6. The method according to any one of the preceding claims, further comprising: receiving a request to serialize an input file, the input file comprising a plurality of lines of code representing the arithmetic circuit; scanning at least a portion of the plurality of lines of code and adding symbols from a symbol set to a data structure; as well as Wherein, the symbol set is obtained from the data structure.

7. The method according to any one of the preceding claims, further comprising: A symbol of a symbol set is encoded as a difference between the symbol and another symbol of the symbol set.

8. A method according to any one of the preceding claims, wherein: The range of encoded values ​​corresponds to the probability that the subset occurs in the pattern.

9. A method according to any one of the preceding claims, wherein: A subset of the symbol set is a symbol.

10. A method according to any one of the preceding claims, wherein: The compressed arithmetic circuit is broadcasted to the blockchain network instead of the arithmetic circuit.

11. A method according to any one of the preceding claims, wherein: A node of the blockchain network that receives the compressed arithmetic circuit is able to determine the arithmetic circuit from the compressed arithmetic circuit.

12. A system comprising: processor; as well as A memory comprising executable instructions which, due to being executed by a processor, cause the system to perform the computer-implemented method of any one of claims 1 to 11.

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

Images