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

Abstract

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

Description

[0001] This application is a divisional application of a patent application with Chinese Application No. 201980022069.5 (PCT International Application No. PCT / IB2019 / 052112), a filing date of March 15, 2019, and a title of "Computer-Implemented Methods and Systems Related to Arithmetic Coding for Serializing Arithmetic Circuits". Technical Field

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

[0003] In this document, 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 unpermissioned ledgers, shared ledgers, and their variants. Although specific blockchains may be mentioned herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with a particular blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention.

[0004] A blockchain is a peer-to-peer electronic ledger that is implemented as a computer-based decentralized distributed system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of digital asset control rights among participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash value of the previous block, and in addition, the blocks are linked together to create a permanent, immutable 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 some platforms, these scripts are written using a stack-based scripting language.

[0005] In order to write a transaction to the blockchain, it must be "verified". Network nodes (mining nodes) 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 verification work on the unspent transaction outputs (UTXOs) by executing its locking script and unlocking script. If the execution evaluation of the locking script and unlocking script is true (TRUE), the transaction is valid and the transaction is written to the blockchain. Therefore, in order to write a transaction to the blockchain, it is necessary to: i) verify the transaction by the first node receiving the transaction - if the transaction is verified, the node relays it to other nodes in the network; ii) add the transaction to a new block built by the mining nodes; and iii) the transaction is mined, that is, added to the public ledger of past transactions.

[0006] Digital entrepreneurs have started to explore the use of both cryptographic security systems and data that can be stored on the blockchain to implement new systems. It would be highly beneficial if the blockchain could be used for automated tasks and processes. Such a scenario would be able to utilize the benefits of the blockchain (e.g., permanence of events, tamper-proof records, distributed processing, etc.) while having more uses in its applications.

[0007] One area of current research is the use of the blockchain to implement "smart contracts". These are computer programs designed to automatically execute machine-readable contract or protocol terms. Different from traditional contracts written in natural language, smart contracts are machine-executable programs that include rules that can process inputs to produce results, and then actions can be prompted to be executed based on these results. Summary of the Invention

[0008] Therefore, it is desirable to implement a verifiable computing framework 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, which can be used to reduce the storage space requirements for storing and / or executing the smart contract. Furthermore, the compressed arithmetic circuit can be broadcast to the blockchain network and stored instead of the uncompressed arithmetic circuit (e.g., stored in the nodes of the blockchain network). A worker computer system can obtain 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.

[0009] Now such an improved solution has been designed.

[0010] Therefore, according to the present invention, there are provided some systems and methods.

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

[0012] Preferably, the compressed arithmetic circuit includes a header, wherein the header encodes information available for mapping sets of symbol sets to different ranges of encoded values - for example, a first symbol is mapped to the range [0 - 0.3), a second symbol is mapped to the range [0.3, 0.7), and a third symbol is mapped to the range [0.7, 1). The different ranges can be non-overlapping ranges such that a particular encoded value corresponds exactly to one symbol or set of symbols.

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

[0014] The encoded value can be selected based on the encoded value represented by a threshold number of bits. For example, between two different binary fractions within the range, the binary fraction represented by fewer bits can be selected as the encoded value.

[0015] Selecting the encoded value can include: mapping different subsets of the symbol set to sub-ranges of the range of encoded values; selecting an encoded value from within the sub-range of the range of encoded values; and wherein both a first subset and a second subset of the symbols are represented by the encoded value in the compressed arithmetic circuit.

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

[0017] The method can further include: encoding a symbol of the symbol set as a difference between the symbol and another symbol of the symbol set.

[0018] Preferably, the arithmetic circuit includes operator and wire identifiers, and further, wherein the symbol set is the operator and the wire identifiers are encoded separately according to an arithmetic coding scheme.

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

[0020] Preferably, the range of the encoding values corresponds to the probability of a subset occurring in a certain pattern. For example, between two symbol sets, the symbol set with a higher occurrence probability has a relatively larger corresponding range of encoding values.

[0021] Preferably, the subset of the symbol set is a symbol.

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

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

[0024] According to the present invention, a computer-implemented method can be provided for managing the serialization process of an arithmetic circuit using a buffer. The method includes: receiving a command to serialize an arithmetic circuit representing a smart contract, where the command is an application programming interface (API) command that includes a reference to a data file, and the data file includes the arithmetic circuit to be serialized: (i) scanning the first line of the data file including the arithmetic circuit, where each line read from the data file corresponds to a command corresponding to one or more executable instructions, (ii) determining a mapping by determining a typed operation associated with the command, (iii) encoding variables based on type, where different types of variables are encoded using different numbers of bits, and (iv) inserting the encoded variables into the buffer; sequentially scanning the data file to obtain other lines of the data file and processing the other lines according to steps (i) to (iv) until the last line of the data file is detected; and flushing the buffer to transfer data to an output stream or file, thereby generating a serialized circuit.

[0025] Optionally, scanning the file includes: obtaining a command from the first line or the next line of the data file and mapping the command to an underlying method.

[0026] Optionally, inserting the encoded variables into the buffer is a command to write a specific number of bits of data to the output stream.

[0027] Optionally, detecting the last line of the data file includes: determining whether the end of the file has been reached by detecting whether a specific end-of-file bit or character sequence has been reached.

[0028] Optionally, different types of variables are encoded using different numbers of bits at least partially based on the settings of the encoder.

[0029] Optionally, the encoding of the header data, operator data, and wire identifier data each uses a different technique (such as arithmetic coding techniques) for data encoding.

[0030] Optionally, the data file is an uncompressed data file.

[0031] Optionally, the command identifies the output stream for storing the serialization result of the arithmetic circuit.

[0032] Optionally, the 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 set of conditions based on one or more inputs.

[0033] Optionally, the smart contract is written in a domain-specific language (DSL) code, and the DSL code is converted into a general-purpose language (GPL) code.

[0034] There is also a desire to provide a system that includes: a processor; and a memory including executable instructions that, when executed by the processor, cause the system to perform any of the claimed methods.

[0035] There is also a desire to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that, when 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

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

[0037] Figure 1 shows the serialization and deserialization of an arithmetic circuit in an embodiment of the present disclosure;

[0038] Figure 2 shows a schematic diagram that shows an example of a swim diagram of verifiable computing and actors involved in an embodiment of the present disclosure;

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

[0040] Figure 4 shows a diagram for visualizing arithmetic coding of a symbol sequence according to an embodiment of the present disclosure;

[0041] Figure 5Illustrative examples of a process for compressing an arithmetic circuit using arithmetic coding according to embodiments of the present disclosure are shown;

[0042] Figure 6 Diagrams showing various schemes in which serialization of an arithmetic circuit based on the compression properties of arithmetic coding can be implemented according to at least one embodiment are shown;

[0043] Figure 7 Illustrative examples of a process for managing serialization of an arithmetic circuit using a buffer according to an embodiment are shown;

[0044] Figure 8 Diagrams showing a multi-symbol representation of a visual symbol sequence that utilizes the properties of a dictionary based on an arithmetic circuit according to an embodiment are shown;

[0045] Figure 9 Diagrams showing multi-symbol coding according to an embodiment are shown; and

[0046] Figure 10 Diagrams showing compression of an arithmetic circuit by aggregating identifiers, resulting in the generation of a serialized circuit that can be further compressed are shown. Detailed Description

[0047] Now we provide an illustration of how to put the present invention into practice according to one embodiment. The present invention can be implemented in the context of a distributed computing environment, where a first computing entity uses an arithmetic circuit to generate a program, and the execution of the program can be delegated to computing entities in the distributed computing environment (e.g., nodes of a blockchain network). Additionally, the correct execution of the program is computationally verifiable, such that a client computing entity can delegate the execution of a program generated at least in part based on an arithmetic circuit, and the client computing entity can verify that the program is correctly executed by a worker computing entity. In this way, various efficiencies of the 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.

[0048] As described in more detail below, we describe a possible implementation of using arithmetic coding to compress and serialize an arithmetic circuit into a binary stream of data. The binary stream of data can be deserialized and decompressed in a lossless manner. Various advantages of the serialized circuit can be realized, such as 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, 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 appreciable, as the blockchain ledger can be recreated by some or even all of the nodes of the blockchain network.

[0049] Specific structures or building blocks can be used to facilitate this transformation. In one or more embodiments, the representation can be considered as the first step in building an integrated pipeline that can provide distributed verifiable computing. The building blocks presented in this example are not intended to be an exhaustive list of all possible high-level language constructs that the embodiments of the present invention can handle. Additionally, alternative implementations of the presented examples can be provided. These fall within the scope of those skilled in the art.

[0050] Now we provide illustrative embodiments of the present invention. However, it is important to note that this is an example of an application where the present invention can be used. Those skilled in the art will understand that the present invention can be advantageously used in other contexts and applications.

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

[0052] · Integrity, i.e., if the protocol is correctly followed, an honest verifier will be convinced of the validity of the output;

[0053] · Soundness, i.e., a cheating prover cannot convince an honest verifier of the authenticity of the output;

[0054] · Zero knowledge, i.e., a cheating verifier will not learn anything other than the validity of the output. Some benefits of the protocol can include:

[0055] · Protection against man-in-the-middle attacks, as no communication between participants is required.

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

[0057] · Avoid using a trusted third party, such as a trusted hardware device.

[0058] · The contract coming into effect does not mean that the code is re-executed. The calculation is not redone (replicated) through each node in the network. Instead, evidence of honest execution is stored in the public blockchain and is only used for verification purposes.

[0059] 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, blockchain provides a suitable environment for resolving agreements between two (or more) parties.

[0060] Such a system needs to provide and promote programmability in a decentralized 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, and Juels, A., et al. (2013), The Ring of Gyges: Using Smart Contracts for Crime.

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

[0062] Figure 1FIG. 100 is an illustrative diagram of an embodiment that can be implemented in accordance with the present disclosure. The techniques described herein can be used to serialize and deserialize arithmetic circuits used in the execution of computer programs. According to an embodiment, an arithmetic circuit can be used to construct a quadratic arithmetic program (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). The client and the prover can delegate the execution of the program to the prover in a manner that allows the client to efficiently verify that the prover has correctly executed the program. By reducing the required computational resources (e.g., hard disk space) associated with the arithmetic circuit, serialized circuits can be used to improve the operation of a computer system. In an embodiment, the arithmetic circuit includes information represented as a set of symbols (e.g., arithmetic gates and values) that is compressed to produce a serialized circuit that includes a set of codes, where the set of symbols can be derived from the set of codes in a lossless manner. Transmission of the compressed circuit can improve the effective data transmission bandwidth of a 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 as many compressed arithmetic circuits can be transmitted using the same number of bytes (it should be noted that the actual improvement in data transmission bandwidth may be less than twice because data overheads such as packet headers that may not be compressed are 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. Transmission of the compressed circuit can improve the effective data transmission bandwidth of a 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 as many compressed arithmetic circuits can be transmitted using the same number of bytes (it should be noted that the actual improvement in data transmission bandwidth may be less than twice because data overheads such as packet headers that may not be compressed are 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.

[0063] Generally, an arithmetic circuit includes wires that carry values from a field F and are connected to logical and / or arithmetic gates. In an embodiment, the circuit It can be represented by a set of data fields, which includes arithmetic gates, input lines, and output lines. The circuit may also include a header that includes information such as a version number, the total number of lines, and a bit-width n that allows for optimization according to the target execution environment (e.g., processor architecture). bit The compression of the arithmetic circuit can be achieved by removing data fields that can be determined from other fields, applying an entropy coding scheme, and combinations thereof. Various types of simplification rules can be used as part of the compression routine for the format of the encoded arithmetic circuit. For example, certain information may not be required, such as the line identifier for the input, the line identifier for the output gate, the first input of the first gate, and the last output line identifier that can be compressed (e.g., not explicitly encoded as part of the serialized circuit), or any combination thereof.

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

[0065] As mentioned above, Huffman codes can be used to generate the code table. 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 the table from the estimated or measured probabilities or frequencies (weights) of occurrence of each possible value from the source symbols: more common symbols are typically represented using fewer bits compared to less common symbols. In an embodiment, Huffman coding can be efficiently implemented to find the codes in a time that is linear with the number of input weights, where the input weights are in sorted order. Among the methods of encoding symbols individually, this strategy may be optimal. Huffman coding can use a specific method of selecting representations for each symbol, resulting in a prefix code, i.e., the bit string representing a particular symbol is never a prefix of the bit string representing any other symbol.

[0066] Given a set of symbols {a0, a1, …, a} of size n from an alphabet A and whose weights {p0, p1, …, p n-1} are typically proportional to the probabilities n-1}, a tree with the minimum weighted path length starting from the root. The output code C(P) = {c0, c1, …, c n-1}, is a tuple of binary codewords with the minimum weighted path length L(C).

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

[0068]

[0069] Entropy is a measure of the minimum codeword length, which is theoretically possible for a given alphabet with associated weights. Generally, the Huffman code does not have to 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.

[0070] A serialization 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 where the source data is perfectly derivable from the compressed data. In the context of digital compression, lossless compression can mean that each bit of the source bitstream can be derived from the compressed data including the symbol set. In contrast, lossy compression can refer to a compression algorithm where the compressed data cannot be used to derive each bit of the source bitstream - an example of lossy compression is the MP3 audio coding format.

[0071] Figure 2 is a diagram showing an example of the swim - graph 200 of verifiable computations and actors involved in an embodiment of the present disclosure. As Figure 2 shown, the swim - graph 200 of verifiable computations can include a client node 240, a worker (e.g., prover) node 250, and a verifier node 260 involved in performing 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.

[0072] In an embodiment, the setup phase involves writing a contract in a domain - specific language (DSL). An interpreter, which can be the client node 240, takes the source code as input and produces 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.

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

[0074] In 204, worker node 250 inputs Upper 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.

[0075] 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 values of the internal circuit wires and EK are used to generate a proof-of-correctness π. The proof π can be stored on a blockchain and verified by multiple parties (e.g., verifier nodes 260) without the worker node 250 having to interact with the multiple parties separately. In this way, the verifier nodes 260 can use the public verification key VK and the proof π to verify the payment transaction in 210, thereby verifying the contract.

[0076] Verifiable computation is a technique that allows for the generation of proofs of computation. In an embodiment, a client utilizes this technique to outsource the evaluation of a function f over an input to another computing entity (referred to herein as a worker). In some cases, the client is computationally constrained, and thus it is infeasible for the client to perform the evaluation of the function (e.g., the expected runtime of the computation using the computing resources available to the client exceeds a maximum acceptable threshold), although this is not necessarily the case. Generally speaking, the client can delegate the evaluation of the function f over an input based on any suitable criteria (such as, for example, computation runtime, computation cost (e.g., the financial cost of allocating computing resources to perform the evaluation of the function), etc.).

[0077] In an embodiment, the worker is any suitable computing entity, such as a blockchain node described in more detail elsewhere in this disclosure. In an embodiment, the worker (e.g., a blockchain node) evaluates the function f over an input and generates an output y and a proof π of the correctness of the output y, which can be verified by other computing entities (e.g., the client and / or other nodes of the blockchain network as described above). Compared to performing the actual computation, the proof (which can also be referred to as an argument) can be verified much more quickly - and thus, by verifying the correctness of the proof rather than recomputing the function f over the input to determine the correctness of the output generated by the worker as described above, the computational overhead can be reduced (e.g., reducing the power overhead and the costs associated with powering and operating the computing resources). In zero-knowledge verifiable computation, the worker provides an attestation to the client that the worker knows an input with a particular property.

[0078] An efficient variant of the zero-knowledge proof 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 generic group operations to compute multiple group elements, and the verifier uses multiple pairing product equations to check the proof. In an embodiment, linear interactive proofs operate over finite fields, and the messages of the worker and the verifier include, encode, reference, or otherwise include information that can be used to determine vectors of field elements.

[0079] In embodiments, the systems and methods described herein allow a node (e.g., a mining node) of a blockchain to perform a computation (e.g., evaluate a computation related to 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 an embodiment, 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(nlogn), but the worst-case computational cost of quick sort is O(nlogn). 2 ), while the worst-case computational cost of heap sort is O(nlogn). 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.

[0080] 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 a system and method for executing the verification phase using a blockchain script that is used to store elements used in the verification of the calculation.

[0081] 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 3Depicts DSL code 302 that is converted by converter 304 into GPL code 306. The GPL pre-compiler 308 (also referred to as a pre-processor) incorporates external libraries 310 referenced by the GPL code 306 to produce GPL pre-processed code 312. The GPL pre-processed code 312 is converted into an arithmetic circuit 314, which is optimized to produce a simplified arithmetic circuit 316, which is compressed to produce a serialized circuit 320 from which the QAP polynomial 318 is derived.

[0082] In an embodiment, a domain-specific language (DSL) code 302 is an application 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 that set of conditions. An example of an application (e.g., a smart contract) is an insurance contract that takes as input the insured's premium and the insurer's potential compensation to the insured. If the insured suffers a loss during the smart contract period (e.g., the fulfillment of a first condition), then the execution of the smart contract allocates 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, then the execution of the smart contract allocates the premium to the insurer and returns the potential compensation to the insurer.

[0083] In an embodiment, the converter 304 is a software program that, upon execution, 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). In an embodiment, the GPL code 306 is a GPL program (e.g., a C++ program) that contains the code defined in the DSL code 302. In some examples, a general-purpose programming language or "general language" (GPL) is widely applicable compared to 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++ that may be referenced in embodiments of the present disclosure is a general-purpose programming language with imperative, object-oriented, and general programming features, while also providing facilities for low-level memory manipulation. It should be noted that in Figure 3In the context of, the "code" can alternatively refer to executable code (e.g., object code), source code, both, either of them, or a combination thereof, based on the described context.

[0084] In an embodiment, the GPL pre-compiler 308 is a computer-executable program that processes the GPL code 306 and the required external libraries 310 to produce a stand-alone GPL pre-processed code 312. In an embodiment, the GPL pre-compiler 308 evaluates constant expressions and registers symbols found in the GPL code 306.

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

[0086] In an embodiment, the GPL pre-processed code 312 includes a collection of expressions and operators. The operators can 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, a main function is generated to have a predetermined name and format.

[0087] In an embodiment, the 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 an input gate representing a variable (e.g., x i )), and each other node of the DAG is 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, the arithmetic circuit 314 has two measures of complexity: size and depth. In some examples, the "size" of the arithmetic circuit is based on the number of gates within the 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.

[0088] 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 the minimum extent) 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 can 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 techniques described in UK Patent Application No. GB 1718505.9 can be used to generate the simplified arithmetic circuit 316.

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

[0090] In an embodiment, the QAP polynomial 318 is one or more expressions including variables and coefficients represented by a mathematical formula that provides a complete description of the original arithmetic circuit (e.g., Figure 3 arithmetic circuit 314). In an embodiment, the polynomials of the QAP polynomial are defined according to their evaluation at the root of the arithmetic circuit, such as those described in: Gennaro, R. et al., Quadratic Span Programs and Succinct NIZKs without PCPs (2013). In an embodiment, the QAP polynomial is encoded into the 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 (e.g., as a result of executing the locking script) at execution, and these parameter values are input as variables into the QAP polynomial to cause determination of the result of the smart contract.

[0091] In an embodiment, the GPL pre-compiler 308 generates GPL pre-processed code 312, which may be an arithmetic circuit including arithmetic gates. However, note that due to conditional and flow control statements, complex arithmetic circuits also embed logic sub-modules.

[0092] Figure 4 FIG. 400 shows arithmetic coding of a visual symbol sequence according to an embodiment of the present disclosure. In an embodiment, the process for generating arithmetic coding for a symbol sequence can be performed in conjunction with Figure 4 the figures shown. 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, as in ASCII code, and frequently used symbols can be stored with fewer bits. Different from 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).

[0093] For example, Figure 4 FIG. shows the arithmetic coding of the symbol sequence {a1, a2, a1}, which can be encoded using an arbitrary precision range. In an embodiment, the symbols are encoded in a range between 0 and 1 (e.g., including endpoints and / or excluding endpoints). In an embodiment, the symbols are encoded in a range between 0 and 2 n including endpoints and / or excluding endpoints. According to Figure 4 , examples include a set of value ranges corresponding to the value range of the first symbol in the sequence. For example, values in the range [0, x1) correspond to the first symbol being a0, values in the range [x1, y1) correspond to the first symbol being a1, and values in the range [y1, 1) correspond to the first symbol being a2. In an embodiment, each value range can be further divided to correspond 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 can be followed that the following two symbol sequences are encoded using the following value ranges:

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

[0095] In various embodiments, for any given symbol set a of size n from an alphabet A with probability p i , the arithmetic encoder can produce an output that is almost optimal, where the optimal value is -log2p i 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.

[0096] The encoding and decoding of symbols can 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 can be used to encode a new symbol (as described elsewhere in this disclosure, embodiments that exclude endpoints and / or include endpoints are contemplated within the scope of this disclosure). According to various embodiments, at step j, p j (a i ) is defined as the symbol probability of a i . In an embodiment, the general symbol p i is valid if and only if an adaptive model is not used. The encoder divides the current interval into sub-intervals, each sub-interval representing a portion of the current interval proportional to the probability of that symbol. The sub-interval for the input symbol a j with probability p i (a i ) becomes the updated interval [x j+1 , y j+1 :

[0097]

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

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

[0100] <![CDATA[a0..]]> 0–0.5 <![CDATA[a1a0..]]> 0.5–0.75 <![CDATA[a1a1..]]> 0.75–0.85 <![CDATA[a1a2a0]]> 0–0.5 <![CDATA[a1a2a1]]> 0–0.5 <![CDATA[a1a2a2]]> 0–0.8 <![CDATA[a2..]]> 0.7–1

[0101] In addition, it should be noted that Figure 4 the intervals or ranges of values shown in Figure 4Nor does it imply a ratio of certain intervals to other intervals. In an embodiment, the intervals are proportional or substantially proportional to the probability of symbol occurrences (e.g., proportional to a certain precision threshold due to a rounding value). 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 symbol occurring at j+1 does not depend on the value of any previous symbol.

[0102] In an embodiment, the symbol sequence can be reconstructed given the intervals (or any fraction located within the intervals) and the probability model. If the stream does not terminate internally, e.g., using an EOS (end of stream) symbol a with its own probability p EOS then an external mechanism can be utilized to interrupt the decoding process. In some cases, different equally-short decimal fractions can be used to represent the same interval. Thus, according to an embodiment, a binary representation with fewer bits can be selected to maximize the compression factor. For example, two fractions within the range [0.65, 0.67) can be represented with vastly different numbers of bits, thus affecting the compression factor of the sequence: EOS

[0103] Decimal fraction Binary fraction 0.65 0.10100110011001100110011001100110011... 0.6666259765625 0.1010101010101

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

[0105]

[0106] In an embodiment, when one or more digits are shared between the two limits of the current coding range, those digits are appended to the output stream and discarded. The remaining digits within the coding range are shifted to the left while new digits are added to the right: one for the upper bound and zero for the lower bound. Thus, the system maintains the ψ bits of precision by excluding the bits that no longer contribute to the computational precision.

[0107] Regarding the upper bound of compression, given a message of size L and the symbol frequencies f(a j ) of the alphabet A, it can be with L​C bits to represent a coded fraction with infinite precision:

[0108]

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

[0110]

[0111] Thus, arithmetic coding can essentially approach the entropy of a probability model whose symbol probabilities are the same as those of the input message.

[0112] It should be noted that arithmetic coding does not compress one symbol at a time, so it can approach the entropy limit arbitrarily closely. 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 length equal to the input, arithmetic coding approaches the optimal compression rate:

[0113]

[0114] Figure 5 An illustrative example of process 500 for compressing an arithmetic circuit using arithmetic coding according to an embodiment of the present disclosure is shown. Some or all of the steps in process 500 can be performed according to the techniques described in conjunction with Figure 4 (or any other process described herein, or their variations and / or combinations). Process 500 illustrates that a serialized circuit step can be generated from an arithmetic circuit. As a result of serializing an arithmetic circuit using the arithmetic coding techniques described herein, a compressed representation of the arithmetic circuit can be stored instead of storing the arithmetic circuit - for example, in an embodiment, the serialized circuit is broadcast to the nodes of a blockchain network instead of broadcasting the arithmetic circuit to the nodes of a blockchain network, thereby reducing the data storage requirements for the nodes of the blockchain network (e.g., those nodes that maintain a copy of the blockchain ledger).

[0115] In an embodiment, the system obtains an arithmetic circuit (e.g., represented as a 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 and stored in different data structures. As described above, Figure 5 the process 500 shown can be suitable for encoding different types of circuit data. In an embodiment, process 500 is performed separately for the operators and identifiers (e.g., input identifiers).

[0116] In an embodiment, the system obtains 502 the first one or more symbols of the arithmetic circuit representing the 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 the multiple symbols are jointly mapped to a specific range of intervals. In an embodiment, the symbols are all of a particular type (e.g., all are operators, all are input lines).

[0117] In an embodiment, the system obtains 504 a mapping of symbols to sub-ranges of the range of intervals. The initial range of intervals can span the global minimum and the global maximum (e.g., all encoded symbols fall within the global minimum / maximum). Unless otherwise specified, the endpoints described above and below herein Figure 5 can be inclusive or exclusive (e.g., the range can 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), such that the entire range of values can be represented by binary fractions with values less than 1. The mapping can refer to a mapping table that divides the initial range of intervals into a set of non-overlapping sub-ranges such that the sub-ranges together cover the entire initial range of intervals. In an embodiment, each sub-range is mapped to a symbol or a set of symbols. In an embodiment, the system determines 506 the next range of intervals based on the mapping and the previous one or more symbols. In an embodiment, the system makes the determination by finding the mapping table entry corresponding to the previous one or more symbols and selecting the sub-range corresponding to the previous one or more symbols as the next range of intervals. 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 a set of symbols:

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

[0119] In an embodiment, after the system has determined the sub-range for the previous one or more symbols, the system determines 508 whether there are more symbols to be encoded. 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-range. In an embodiment, the sub-range is proportionally the same as the previous range, such as in the following cases:

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

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

[0122] Once the final interval range is obtained, the system encodes the symbols using the values within the final interval range 512. Any value within the interval range is suitable for encoding the symbols - for example, continuing 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 selected to maximize the compression factor.

[0123] In an embodiment, the operator and / or the wire identifier (or a part thereof) can be serialized as described according to Figure 5 The resulting serialized circuit can be stored 514 on, for example, a blockchain ledger, rather than the arithmetic circuit being stored on, for example, a blockchain ledger, thereby reducing the storage requirements for encoding the smart contract for the representation.

[0124] In an embodiment, Figure 6 FIG. 600 shows various schemes that can implement the serialization of an arithmetic circuit for the compression properties based on arithmetic coding according to at least one embodiment. In an embodiment, the serialization process is managed by a buffer (referred to as bitbuffer in Figure 6 that provides bit-by-bit operations. In an embodiment, the bitbuffer temporarily stores the data before it is transferred to the permanent storage support or sent over the network. As Figure 6 shown, the buffer can be accessed using (at least) the following methods: the put() function, which is used to insert the input data x into the buffer, and in an embodiment, n b bits are used to store x; the send() function, which is used to flush the buffer and transfer the data to the output stream out.

[0125] One or more interfaces serving as an abstraction layer can be provided to a typed operation. In an embodiment, a low-level method put() can be called by different high-level methods such as writeInt(), writeUint(), and writeStr(), which can be utilized to write (e.g., to a buffer) an integer, an unsigned integer, and a string, respectively.

[0126] In an embodiment, a third abstraction layer is provided by a function such as scan(), which reads data line by line from an input (e.g., Figure 6 the input file 602 shown in) and calls underlying methods to write typed data. In an embodiment, Figure 6 the scan() function shown corresponds to the following routine: if 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 detecting an unrecognized command, an incorrect signature format, an incorrect (e.g., deprecated) function version, etc.) causes the entire encoding process to fail.

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

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

[0129] In an embodiment, a data field having a dynamic (e.g., variable) size can be embedded in a serialized packet. As an illustrative example, consider the case of serializing 4 compressed data blocks [data1, data2, data3, data4] having the same size (16 bits). In an embodiment, the following encoding scheme can be used to compress the data blocks: a first field of a constant size, which includes the size of the field reserved for the number of data packets in the payload (e.g., in bits); a second field of a constant size (e.g., the same or different size from the first field), which includes the size in bits of the 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, where the data structure can in turn include a second data field, which encodes the size of a second data structure following the second data field, and so on.

[0130] In an embodiment, the header of the serialization circuit includes one or more encoded fields, such as those described in detail below. In an embodiment, the version field provides information on how to interpret and / or construct the remainder 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, a fixed number of bits is used to encode this parameter, and the fixed number of bits is determined based on the maximum number of operators supported by the serialization circuit. In an embodiment, for example, the number of input lines (IN), the number of output lines (OUT), the encoded size of the line identifier (n w ) and the encoded size of the parameter (n params ) are encoded. In an embodiment, the total number of lines N has the encoded size of n w . It should be noted that the header does not necessarily have to be at the beginning or head of the serialization circuit data file. In an embodiment, the header only needs to be at some point before the data related to the header information in the serialization circuit - for example, if the header includes a parameter for the total number of lines N, then in an embodiment, the header information N is encoded at any suitable point in the serialization circuit such that it is read before the data encoding the line identifier.

[0131] In an embodiment, the header includes an embedded dictionary. In an embodiment, first, the maximum encoded size of the symbols for Huffman coding is added, and then each pair (symbol size, symbol) is added using the maximum encoded 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 individual symbol probabilities (using the encoding size n prob ) can be directly encoded, or a probability scheme can be provided, and a multiplicative coefficient can be used to represent the entire set. For example, consider the case of using 4 symbols with the following probabilities: p1 = 0.1, p2 = 0.4, p3 = 0.1, p4 = 0.4, then the entire set [1,4,1,4] can be represented using multiplicative coefficients. In an embodiment, these coefficients are encoded individually (e.g., using the encoding size n coeff ) or represented as a scheme template with a unique identifier (e.g., using the encoding size n pid ). In an embodiment, the header also encodes n prob and / or the table mapping symbols to identifiers.

[0132] In an embodiment, arithmetic coding uses a range of values to represent an operator sequence based on the probabilities encoded in the header. In an embodiment, it can be as described elsewhere in this disclosure, for example, in combination with Figure 4Calculate the precision of the encoding range using the associated description. In an embodiment, such as those using Huffman coding, each compressed symbol corresponding to an operator is sequentially added to the payload.

[0133] In an embodiment, such as in the case of using Huffman coding, each wire identifier is sequentially added to the payload. In an embodiment, different strategies can be utilized to encode wire identifiers using arithmetic coding, such as one or more of the following: sequential coding (e.g., according to Huffman coding), arithmetic coding (e.g., according to operators), aggregation of identifiers (e.g., as described in more detail below Figure 8 .

[0134] Figure 7 An illustrative example of a process 700 for using a buffer to manage serialization of an arithmetic circuit according to an embodiment is shown. Some or all of the process 700 (or any other process described herein, or its variations and / or combinations) can be performed according to the techniques described in conjunction with Figure 5 and Figure 6 .

[0135] In an embodiment, a set of interfaces is used to manage the serialization process 700, and the set of interfaces provides 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 arithmetic coding techniques). In an embodiment, the command also identifies an output stream for storing the serialized result of the arithmetic circuit.

[0136] In an embodiment, a smart contract is written in domain-specific language (DSL) code with precise semantics—in an embodiment, the 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 set of conditions based on one or more inputs. In an 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 an embodiment, a GPL pre-compiler uses external libraries to process the GPL code to produce a stand-alone GPL pre-processed smart contract. In an embodiment, an arithmetic circuit is constructed by using wires connected to elementary arithmetic gates to represent symbols.

[0137] In an embodiment, system scanner 704 scans the first line of an input file that includes an arithmetic circuit. In an embodiment, each line of the input file that is read corresponds to a command, which can correspond to one or more executable instructions (e.g., assembly instructions). In an embodiment, scanning the file includes obtaining a 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 the typed operation associated with the command. In an embodiment, the different types of data supported include: integers, unsigned integers, and strings (e.g., arrays of characters ending with a null-terminator special character).

[0138] In an embodiment, depending on the specific settings of the encoder, different numbers of bits can be used to encode 708 different types of variables. The encoding technique can be based on the combination Figure 5Those techniques described in more detail. For example, the encoding of the header data, operator data, and wire identifier data can each utilize different techniques such as arithmetic encoding techniques for data encoding. 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 data into the buffer 710 is a command to write a specific number of bits of the data to an output stream. Then, the system can determine 712 whether the end of the file has been reached (e.g., by detecting whether a specific bit or character sequence indicating the end of the file has been reached). 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, third line, fourth line, etc. of the file and processes them according to the above steps 704-710. These steps can be repeated until the end of the file is detected, at which point the system can flush 714 the buffer and transfer all the data to the output stream or file, thereby generating a serialized circuit.

[0139] Figure 8 FIG. 800 shows a visualization of a multi-symbol representation of a symbol sequence that utilizes the properties of a dictionary based on an arithmetic circuit and can be used in combination with other compression techniques described herein to reduce the size of the arithmetic circuit stored on a computer system or computer network.

[0140] In an embodiment, the size of the dictionary is restricted (e.g., due to limitations in available computing resources), and the occurrence of symbols is correlated (e.g., lack of independent probability properties). Thus, in an embodiment, the arithmetic range for compression includes symbols that aggregate the functionality of individual primitives, e.g., as Figure 8 shown.

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

[0142]

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

[0144] ADD3 4 5 1 1 8

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

[0146]

[0147] The probability ranges of the aggregated symbols can be fixed or can also be adjusted automatically according to the previous symbols. In the case of fixed probabilities, we define the following aggregated probability P(s1, s2, … s β ) for the symbol sequence {s1, s2, … s β}

[0148]

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

[0150] In an embodiment, the symbol depth β is modified dynamically during the encoding phase according to the content of the input stream. In an embodiment, multiple emitted symbols N* are used to establish when to perform a new range assignment. In an embodiment, the multi-symbol ranges of two consecutive windows across N* emitted symbols can be different. Additionally, a different aggregated symbol depth β i (1 ≤ i ≤ n*) can be defined for each of the n* multi-symbol ranges defined in the current window, as Figure 9 shown. In an embodiment, N* is constant and / or is defined in the header of the serialized data.

[0151] Figure 900 shows an illustrative example of multi-symbol coding, in which the stream [a,a,a] is converted to the multi-symbol s1, the stream [[b,b] is converted to s2, and the 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.

[0152] 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 can be assigned to the previous window, for example:

[0153]

[0154] Thus, in an embodiment, at step j for symbol s i the aggregate symbol depth (i.e., β j (s i )) can be the closest integer to the weighted sum represented as the previous step β j-1 (s i ) and 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:

[0155]

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

[0157] In an embodiment, we establish how to calculate the aggregate symbol depth and what a given aggregate symbol represents. In the Figure 8 previous example, we defined s1 as a repetition of the symbol [a], s2 as a repetition of the 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 in the following way:

[0158] Identifier Aggregate 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, …] … …

[0159] Figure 10 Figure 1000 is shown, in which the arithmetic coding technique is used to compress the arithmetic circuit 1002 to aggregate identifiers, resulting in a serialized circuit 1004 that can be further compressed (e.g., compared to a system where the identifiers are not aggregated). In an embodiment, the operators and identifiers are encoded separately - for example, encoded using different techniques and stored using different data structures (e.g., a first queue for operators and a second queue for identifiers). Figure 10Illustrates an exemplary serialization of identifiers according to at least one embodiment. In an embodiment, a compression process using arithmetic coding techniques is applied to an arithmetic circuit 1002 to generate a serialization circuit 1004, which is smaller in size (e.g., stores using fewer bits of data) than the arithmetic circuit 1002. In an embodiment, the average size of the serialization 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, which, if applied to the arithmetic circuit 1002, produces a result (i.e., the serialization circuit 1004) that can perfectly reproduce (e.g., bit-by-bit precision) the arithmetic circuit 1002 by applying a lossless decompression routine.

[0160] In an embodiment, it is determined whether to use an entropy scheme to encode a circuit or a part of a circuit (e.g., whether to encode an identifier, whether to encode an operator) based on how the data is generated, the size of the symbols, or a combination thereof. For example, in some embodiments, due to the randomness of identifier generation and / or the size of the symbols, an entropy scheme is not used to encode the identifiers. Generally, larger circuits have more identifiers, thus increasing the size of the symbols.

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

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

[0163] As an illustrative example, consider the following circuit or part of a circuit:

[0164]

[0165] The identifiers can be encoded as follows:

[0166]

[0167] The first input (4) is typically encoded. 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, in the case of a large circuit with many identifiers (e.g., large identifiers require additional bits of data to encode the absolute identifier value), one of the advantages of this scheme is readily understood. On average, if n bits are required to encode an identifier, fewer than n / 2 bits are required to encode the difference. In an embodiment, the input lines can be rearranged 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):

[0168]

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

[0170] Accordingly, the specification and drawings are to be regarded as 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. Similarly, other variations are within the scope of the disclosure. Thus, although the disclosed technology is susceptible to various modifications and alternative constructions, certain of its illustrated embodiments have been shown in the drawings and have been described in detail above. However, it should be understood that it is not the intention to limit the invention to the one or more specific forms disclosed, but on the contrary, the invention is intended to cover all modifications, alternative constructions, and equivalent forms falling within the scope of the invention.

[0171] In the context of describing the disclosed embodiments (particularly in the context of the appended claims), unless otherwise specified or clearly contradicted by the context, the use of the terms "a" and "an" and similar referents shall be construed to cover both the singular and the plural forms. Unless otherwise specified, the terms "comprising," "having," "including," and "containing" shall be construed as open-ended terms (i.e., meaning "including but not limited to"). The term "connected," when unmodified and referring to a physical connection, shall be understood to mean partially or wholly incorporated, attached, or joined together, even if there are some intermediaries. Unless otherwise indicated, the recitation of a numerical range in this disclosure is merely intended to be a shorthand method for referring separately to each individual value falling within that range, and each individual value is incorporated into the specification as if it were recited separately. Unless the context otherwise requires or is inconsistent therewith, the use of the term "set" (e.g., "a set of items") or "subset" shall be construed to include a non-empty set of one or more members. Further, unless the context otherwise requires or is inconsistent therewith, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, but rather the subset and the corresponding set may be equal.

[0172] Unless otherwise expressly specified or clearly contradicted by the 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 in the context to mean the items, terms, etc., that the combined language can be A or B or C, or any non-empty subset of the set of A and B and C. For example, in an illustrative example of a set with 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. Further, unless otherwise specified or clear from the context, the phrase "based on" means "at least partially based on" rather than "based solely on."

[0173] Unless otherwise specified or clearly contradicted by the context, the operations of the described process may be performed in any suitable order. The described process (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) executed jointly on one or more processors by hardware or a combination thereof. In some embodiments, the code may be stored, for example, in a computer-readable storage medium 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.

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

[0175] Embodiments of the present disclosure are described that include the best mode known to the inventors 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 inventors expect skilled artisans to appropriately employ such variations, and the inventors desire that the embodiments of the present disclosure may be practiced in a manner different from that specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter permitted by applicable law. Moreover, unless otherwise indicated or clearly contradicted by the context, any combination of the above elements in all possible variations thereof is covered by the scope of the present disclosure.

[0176] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention. In the claims, any reference signs in parentheses shall not be construed as limiting the claim. The words "comprise", "comprising", etc. do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprise" means "include or consist of", and "comprising" means "including or consisting of". The singular form of an element does not exclude the plural form of such element, and vice versa. The present invention can be implemented by hardware including several different elements and by 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 fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously.

Claims

1. A computer-implemented method for managing the serialization process of an arithmetic circuit using a buffer, the method comprising: Receiving a command to serialize an arithmetic circuit representing a smart contract, wherein the command is an application programming interface (API) command that includes a reference to a data file, the data file including the arithmetic circuit to be serialized: (i) Scanning a first line of the data file that includes the arithmetic circuit, wherein each line of the data file read corresponds to a command corresponding to one or more executable instructions; (ii) Determining a mapping by determining a typed operation associated with the command; (iii) Encoding variables based on type, wherein different types of variables are encoded using different numbers of bits; and (iv) Inserting the encoded variables into a buffer; Sequentially scanning the data file to obtain other lines of the data file and processing the other lines according to steps (i) to (iv) until the last line of the data file is detected; and Flushing the buffer to transfer data to an output stream or file, thereby generating a serialized circuit.

2. The computer-implemented method according to claim 1, wherein, Scanning the file includes: obtaining a command from the first line or the next line of the data file and mapping the command to an underlying method.

3. The computer-implemented method according to claim 1 or 2, wherein, Inserting the encoded variables into the buffer is a command to write a specific number of bits of data to the output stream.

4. The computer-implemented method according to any one of the preceding claims, wherein, Detecting the last line of the data file includes: determining whether the end of the file has been reached by detecting whether a specific end-of-file bit or character sequence has been reached.

5. The computer-implemented method according to any one of the preceding claims, wherein, Encoding different types of variables using different numbers of bits is at least partially based on the settings of an encoder.

6. The computer-implemented method according to any one of the preceding claims, wherein, Encoding of header data, operator data, and wire identifier data each uses a different technique, such as arithmetic coding techniques, for data encoding.

7. The computer-implemented method according to any one of the preceding claims, wherein, The data file is an uncompressed data file.

8. A computer-implemented method according to any one of the preceding claims, wherein, The command identifies the output stream for storing the serialization result of the arithmetic circuit.

9. The computer-implemented method according to any one of the preceding claims, wherein, The 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 set of conditions based on one or more inputs.

10. The computer-implemented method according to any one of the preceding claims, wherein, The smart contract is written in domain-specific language (DSL) code, and the DSL code is converted to general-purpose language (GPL) code.

11. A system, comprising: A processor; And A memory including executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 10.

12. A non-transitory computer-readable storage medium storing 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 10.

Images