Computer-implemented system and method for serialization of arithmetic circuits
By removing some data fields of the arithmetic circuit and applying entropy encoding, a compressed arithmetic circuit is generated, which solves the problem of large data space occupancy when arithmetic circuit is stored, and efficient data storage and lossless reverse serialization are achieved.
Patent Information
- Application Number
- CN201980022664.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2018-03-27
- Filing Date
- 2019-03-15
- Publication Date
- 2025-03-18
- Estimated Expiration
- 2039-03-15
AI Technical Summary
The prior art is difficult to effectively reduce the data footprint of arithmetic circuits when storing, especially in blockchain networks.
The compressed arithmetic circuit is generated by removing a subset of data fields related to the arithmetic circuit and applying an entropy encoding scheme to a subset of the remaining data fields. The compression circuit can be stored as data and realizes lossless reverse serialization and decompression by embedding decompression instructions.
The effect of reducing the data footprint of arithmetic circuits is achieved, data storage efficiency is improved, and the original circuit can be rebuilt losslessly when needed.
Smart Images

Figure CN111919390B_ABST
Abstract
Description
Technical Field
[0001] The present invention generally relates to techniques for reducing the data footprint used by arithmetic circuits (e.g., when stored on disk or in memory), and more specifically, to techniques for generating serialized circuits from arithmetic services by utilizing the compression techniques described herein. Arithmetic circuits can be compressed in a lossless manner to generate serialized circuits that can be used to perfectly regenerate the original circuits at a later point in time. Arithmetic circuits can be used to generate programs, the execution of which can be delegated to one or more nodes of a distributed computing environment. A protocol can be used to ensure the correct execution of a program, wherein a first computer system delegates the execution of a program to a second computer system. The present invention is particularly suitable for, but not limited to, use in a blockchain network. Background Art
[0002] In this article, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, licensed and unlicensed ledgers, shared ledgers and variants thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although Bitcoin may be referred to herein for convenience and illustration purposes only, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention. The term "Bitcoin" is intended herein to include any protocol derived from the Bitcoin protocol or its variants.
[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so that blocks are linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its creation. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.
[0004] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid and invalid transactions are rejected by the network. The software client installed on the node performs this validation work on unspent transactions (UTXO) by executing their lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true (TRUE), the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must be: i) validated by the first node that receives the transaction - if the transaction is validated, the node forwards it to other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transactions.
[0005] Although blockchain technology is best known for its implementation using cryptocurrencies, digital entrepreneurs have begun exploring the use of cryptographically secure systems based on Bitcoin and data that can be stored on blockchains to implement new systems. It would be very advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such a solution would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof recording of events, distributed processing, etc.) while being more versatile in its application.
[0006] One area of current research is the use of blockchain to implement "smart contracts." These are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike a traditional contract, which would be written in a natural language, a smart contract is a machine-executable program that includes rules that can process inputs in order to produce results, which can then cause actions to be performed based on those results. Summary of the invention
[0007] Therefore, it is desirable to provide a model for losslessly compressing and serializing arithmetic circuits into a bitstream. Serialized circuits can provide various advantages in the context of circuit templates (e.g., reusable circuits or subcircuits) or standard circuits that need to be stored and retrieved. In this way, an encoding, computing entity can achieve improved performance by eliminating the need to repeatedly create instances of circuits or subcircuits for multiple programs with shared circuits or subcircuits. By using entropy coding for the most frequent elements in a data structure (such as arithmetic operator types), arithmetic circuits can be effectively compressed. Instructions for deserialization and decompression can also be embedded in the bitstream, allowing the recipient of the serialized circuit to reconstruct the original circuit in a lossless manner.
[0008] Such an improved solution has now been devised.
[0009] Thus, according to the present invention, there is provided a system and method as defined in the appended claims.
[0010] According to the present invention, a computer-implemented method for a node of a blockchain network can be provided, the computer-implemented method can be used to reduce the data footprint of an arithmetic circuit and includes: removing a first subset of data fields in a set of data fields associated with the arithmetic circuit, wherein the first subset of data fields can be obtained from a second subset of data fields in the set of data fields, the first subset and the second subset being disjoint sets; and applying an entropy coding scheme to the second subset to generate a compressed arithmetic circuit. The resulting compressed arithmetic circuit can be stored as data in a volatile memory (e.g., RAM), a data storage system (e.g., a hard drive), etc.
[0011] Preferably, the first subset of the data field comprises an identifier of a set of inputs to the arithmetic circuit and the second subset comprises a cardinality of the set of inputs. The cardinality of the set (alternatively, the cardinality number of the set) may refer to the number of inputs in the set of inputs. Thus, a compressed circuit may be represented using fewer data bits than an uncompressed circuit.
[0012] Preferably, the first subset of the data field comprises an identifier of a set of gate outputs of the arithmetic circuit.Thus, fewer data bits may be used to represent the compressed circuit than an uncompressed circuit.
[0013] Preferably, the second subset includes a set of gates and the first subset includes a first input of a first gate in the set of gates. The order of the gates may be defined based on the order in which the gates are evaluated. Thus, the compressed circuit may be represented using fewer data bits than an uncompressed circuit.
[0014] Preferably, the second subset includes a set of gates; the first subset includes a last input of a last gate in the set of gates. The order of the gates may be defined based on the order in which the gates are evaluated. Thus, the compressed circuit may be represented using fewer data bits than the uncompressed circuit.
[0015] Applying the entropy coding scheme to the second subset may include: determining a set of symbols from the second subset; assigning a corresponding code to each symbol in the set of symbols. In many cases, the size (e.g., in bit representation) of a symbol in the set of symbols is larger than the corresponding code for the symbol, but this need not be the case—for example, in Huffman codes, symbols that occur with low frequency may have corresponding codes of larger size.
[0016] Preferably, a symbol in the set of symbols is repeated at least twice in the second subset.For example, the symbol may be a series of bitwise OR operations that occur more than once in the circuit.
[0017] Preferably, the length of the code is inversely proportional to the frequency of the symbol to which the code corresponds. The codes generated by the entropy coding scheme may have variable lengths (eg, some codes are larger than others), and shorter codes may be assigned to symbols that occur at higher frequencies.
[0018] A code corresponding to the symbol is generated according to an optimal prefix code such as a Huffman code.
[0019] Preferably, the method further comprises generating a serialization circuit comprising: a result based at least in part on applying the entropy encoding scheme to the second subset; and a header data structure. The header data structure may include a version number and a total number of lines.
[0020] Preferably, the header data structure further comprises a bit width, the bit width being operable to implement execution optimizations based at least in part on a target architecture.
[0021] Preferably, the version number indicates an encoding scheme that can be used to determine the symbol from the code.
[0022] Advantageously, unlike known interpreters and compilers, the present invention provides an architecture-independent solution. Furthermore, it can be executed without the use of a virtual machine (VM). Architecture-independent circuits may refer to representations of circuits that are not arranged to operate or be used with a specific hardware or software architecture or platform. This is in contrast to prior art compilers and interpreters that are architecture-specific or require the use of a VM.
[0023] It is also desirable to provide a system comprising: a processor; and a memory comprising executable instructions, the executable instructions, which due to execution by the processor, cause the system to perform any of the claimed methods.
[0024] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon, which, due to execution by one or more processors of a computer system, cause the computer system to perform at least any of the claimed methods. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:
[0026] Figure 1 A diagram showing an arithmetic circuit and a serialization circuit that can be used to generate the arithmetic circuit;
[0027] Figure 2 is a diagram showing an example of a verifiable computation and a participant's game graph involved in an embodiment of the present disclosure;
[0028] Figure 3 An example of a workflow from a domain specific language (DSL) code to a quadratic arithmetic program (QAP) is shown according to an embodiment of the present disclosure;
[0029] Figure 4 A process for reducing the size of an arithmetic circuit according to an embodiment is shown;
[0030] Figure 5 A diagram showing an arithmetic circuit and a corresponding serialization circuit according to an embodiment;
[0031] Figure 6 A diagram illustrating serialization of a circuit according to at least one embodiment;
[0032] Figure 7 A computing device is shown that can be used to practice at least one embodiment of the present disclosure. DETAILED DESCRIPTION
[0033] We now provide an illustration of how the present invention may be put into practice according to one embodiment. The present invention may be implemented in the context of a distributed computing environment, wherein a first computing entity utilizes an arithmetic circuit to generate a program, the execution of which may be delegated to a computing entity of the distributed computing environment (e.g., a node of a blockchain network). In addition, the correct execution of the program is computationally verifiable, such that a client computing entity that delegates the execution of a program generated at least in part based on an arithmetic circuit is able to verify that the program is correctly executed by a worker computing entity. In this manner, various efficiencies to a distributed computing environment may be achieved, including enabling a client computing entity to delegate and verify the execution of a program to a computer system under the control of another entity.
[0034] As described in more detail below, we describe a possible implementation for compressing and serializing an arithmetic circuit into a binary data stream. The binary data stream can be deserialized and decompressed in a lossless manner. Various advantages of serialized circuits can be achieved, such as reducing the data storage footprint of the circuit (e.g., by storing the serialized circuit instead of the arithmetic circuit). For example, in the case of a blockchain network, the arithmetic circuit or a program derived from the arithmetic 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 desirable because the blockchain ledger can be replicated by some or even all nodes of the blockchain network.
[0035] Specific structural blocks or building blocks can be used to promote this conversion. In one or more embodiments, this statement can be regarded as the first step of building a comprehensive 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 embodiments of the present invention process. In addition, alternative implementations of the presented examples can be provided. These all fall within the scope of those skilled in the art.
[0036] We now provide an illustrative embodiment of the present invention. However, it is important to note that this is an example of an application in which the present invention can be used. The skilled person will understand that the present invention can be used to advantage in other situations and applications.
[0037] For our example, consider a protocol that allows users to generate applications using a Domain Specific Language (DSL). Once the application has been generated, its execution can be outsourced to untrusted parties (called "workers" or "provers") while its correctness can be publicly verified. The protocol leverages cryptographic primitives to ensure that:
[0038] Completeness, i.e., if the protocol is followed correctly, an honest verifier will be confident of the validity of the output;
[0039] Soundness, i.e., a non-cheating prover can convince an honest verifier of the authenticity of the output;
[0040] Zero-knowledge, i.e., any cheating verifier learns nothing other than the validity of the output.
[0041] The main benefits of this agreement are:
[0042] · Prevents man-in-the-middle attacks since no communication between participants is required.
[0043] Due to the use of blockchain technology, it is difficult for malicious nodes to tamper with data.
[0044] • Trusted third parties such as trusted hardware devices are avoided.
[0045] Contract verification does not mean code re-execution. The computation is not replicated by every node in the network. Instead, the proof of honest execution is stored in the public blockchain and is used only for verification purposes.
[0046] Such a system would be able to handle various types of applications corresponding to various types of tasks and products. Due to its decentralized and distributed nature, the (Bitcoin) blockchain provides a suitable environment for resolving agreements between two (or more) parties.
[0047] Such a system needs to provide and promote programmability in a decentralized cryptocurrency system. However, it has been recognized in the art that smart contract programming is an error-prone process. See Delmolino, K., et al. (2015). Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab, and Juels, A., et al. (2013). The Ring of Gyges: Using Smart Contracts for Crime.
[0048] Therefore, it would be advantageous to be able to use a DSL that makes applications easier to write and read by programmers, thus reducing errors, time, effort, cost, and resources during the programming process. Ideally, non-professional programmers would be able to write various types of applications without having to implement cryptography. Instead, a compiler / interpreter would automatically compile the source code into a cryptographic protocol between the user and the blockchain. These are the technical problems that this invention solves.
[0049] Figure 1100 is an illustrative diagram of an embodiment that can be implemented according to the present disclosure. The technology described herein can be used to serialize and deserialize arithmetic circuits utilized in the execution of a computer program. According to an embodiment, a quadratic arithmetic problem (QAP) can be constructed using an arithmetic circuit, which is compiled into a set of encryption routines for a client (e.g., key generation and verification) and a prover (e.g., calculation and proof generation). The client and the prover can utilize a protocol to delegate the execution of the program to the prover in a manner that allows the client to effectively verify that the prover correctly executes the program. By reducing the required computing resources (e.g., hard disk space) associated with the arithmetic circuit, the operation of the computer system can be improved using a serialized circuit. In an embodiment, the arithmetic circuit includes information represented as a set of symbols (e.g., arithmetic gates and values), which is compressed to produce a serialized circuit including a set of codes, wherein the set of symbols can be derived from the set of codes in a lossless manner. The transmission of the compressed circuit can be transmitted by enabling a greater number of circuits, improving the effective data transmission bandwidth of the computer system. For example, if the compression 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 data transmission bandwidth improvement may be less than two times, which accounts for data overhead such as packet headers that may not be compressed). Reducing the data footprint of the arithmetic circuit can reduce computer hardware requirements associated with the use of the arithmetic circuit, such as 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 circuit as described herein. The transmission of the compressed circuit can be transmitted by enabling a greater number of circuits, improving the effective data transmission bandwidth of the computer system. For example, if the compression 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 data transmission bandwidth improvement may be less than two times, which accounts for data overhead such as packet headers that may not be compressed). Reducing the data footprint of arithmetic circuits can reduce computer hardware requirements associated with the use of arithmetic circuits, such as 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.
[0050] Typically, arithmetic circuits The circuit includes wires that carry values from field F and connect to logic gates and / or arithmetic gates. A circuit may be represented by a collection of data fields, including arithmetic gates, input wires, and output wires. The circuit may also include a header that includes information such as a version number, the total number of wires, and the bit width n that allows optimization to be performed according to the target execution environment (e.g., processor architecture). bit Compression of arithmetic circuits may be achieved by removing identifiable data fields from other fields, applying entropy coding schemes, and combinations thereof. Various types of simplification rules may be used as part of the compression routine based on the format in which the arithmetic circuits are encoded. For example, certain information such as line identifiers for inputs, line identifiers for output gates, first inputs to first gates, and last output line identifiers that may be compressible (e.g., not explicitly encoded as part of the serialized circuit), or any combination thereof, may not be required.
[0051] In various embodiments, entropy coding or coding scheme is applied to arithmetic circuit or a part thereof (e.g., based on the above-mentioned simplification rule). Entropy coding can be utilized to generate variable length code tables for serialization of source symbols. Huffman coding can be utilized to generate code tables, wherein shorter codes are used to encode source symbols with a higher frequency of occurrence, and longer codes are used to encode source symbols with a lower frequency of occurrence-the length of the code can be inversely proportional to the frequency of occurrence of source symbols or sequences. Using these techniques, arithmetic circuits can be compressed into serialized circuits, which require less computing resources to be stored in long-term data storage media (e.g., hard disk drives) and short-term data storage (e.g., random access memory).
[0052] As described above, a code table can be generated using Huffman codes. Huffman codes refer to a specific type of optimal prefix code that can be used to achieve lossless data compression. The output from the Huffman algorithm can be a variable length code table (e.g., a codebook) for encoding source symbols (e.g., characters or commands) in a file. In an embodiment, the algorithm derives a table from an estimated or measured frequency or probability of occurrence (weight) of each possible value from the source symbol: more common symbols are typically represented using fewer bits than less common symbols. In an embodiment, Huffman coding can be effectively implemented to find a code that is linearly related to the number of input weights in a timely manner, where the input weights are in sorted order. This strategy can be optimal in methods that encode symbols separately. Huffman coding can use a specific method to select a representation for each symbol, thereby generating a prefix code, that is, a bit string representing a particular symbol is never a prefix of a bit string representing any other symbol.
[0053] Given an alphabet A of size n and weights {p0,p1,…,p n-1The set of symbols {a0,a1,…,a n-1} is usually proportional to the probability and requires a tree with the minimum weight path length from the root. Output code C(P) = {c0,c1,…,c n-1} is the tuple of binary code words with minimum weight path length L(C).
[0054] According to Shannon's source coding theorem, every symbol a with non-empty probability i The information content h (in bits) is h(a i )=log2(1 / p i ). Entropy H (in bits) is the information content of each symbol with non-zero probability p i All symbols of a i The sum of weights:
[0055]
[0056] Entropy is a measure of the minimum codeword length that is theoretically feasible for a given letter and its associated weights. In general, Huffman codes need not be unique: the set of Huffman codes for a given probability distribution is a non-empty subset of the codes that minimizes L(C) for that probability distribution.
[0057] The serialized circuit can be used to derive the original arithmetic circuit in a lossless manner using an expansion or decompression routine. It should be noted in this context that "lossless" refers to a class of compression algorithms in which the source data can be perfectly derived from the compressed data. In the case of digital compression, lossless compression can refer to each bit of the source bit stream being derivable from the compressed data including a set of symbols. In contrast, lossy compression can refer to a class of compression algorithms in which the compressed data cannot derive each bit of the source bit stream from the compressed data - an example of lossy compression is the MP3 audio encoding format.
[0058] Figure 2 2 is a diagram showing an example of a verifiable computation and a participant's movement graph 200 involved in an embodiment of the present disclosure. Figure 2 As shown in , in an embodiment of the present disclosure, a graph 200 of a verifiable computation may include a client node 240, a worker (e.g., a prover) node 250, and a verifier node 260 involved in the execution steps in the verifiable computation protocol. 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.
[0059] In an embodiment, the setup phase involves writing the contract in a domain specific language (DSL). The interpreter may be a client node 240 that takes the source code as input and generates an arithmetic circuit. The arithmetic circuit consists of "wires" that carry data from the fields The value of and connected to the addition and multiplication gates. Note that the arithmetic circuit itself can be a DAG, not a hardware circuit, and the wires can be edges in the DAG. However, it is conceivable that the arithmetic circuit can be embodied in a physical circuit with wires and logic gates. In 202, the client node 240 writes the computation written in GPL Compile into arithmetic circuits In an embodiment, the client node 240 converts the arithmetic circuit And input x is supplied to the worker node 250 .
[0060] From the circuit The embodiments of the present disclosure can generate a quadratic program The secondary procedure consists of providing A set of polynomials that fully describe . Then, public parameters can be generated for use by worker node 250 and verifier node 260 to execute and verify the quadratic program.
[0061] At 204, the worker node 250 executes the circuit on the input x or quadratic procedure and claims that the output is In some embodiments, it is desired that the worker node 250 (ie, the prover) obtain Therefore, in 206, the worker node 250 encodes the script. In some examples, An effective script for the assignment of values to the circuit lines is such that the value assigned to the input line is x, and the intermediate values correspond to The correct operation of each gate in , and the value assigned to the output line is If the claimed output is incorrect (i.e. ),but No valid script exists for .
[0062] In 208, the worker node 250 outputs Provided to client node 240. In an embodiment, a public evaluation key EK and a public verification key VK are derived by using a secret value s selected by or from client node 240. In an embodiment, worker node 250 uses these public keys to evaluate the computation on a particular input x. In an embodiment, output The value of the internal circuit line, and EK are used to generate a correctness proof π. The proof π can be stored on the blockchain and verified by multiple parties (e.g., the verifier node 260) without the need for the worker node 250 to interact with the multiple parties separately. In this way, the verifier node 260 can use the public verification key VK and the proof π to verify the payment transaction in 210, thereby verifying the contract.
[0063] 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 of an input x to another computational entity referred to herein as a worker. In some cases, a client is computationally constrained such that the client cannot perform the function evaluation (e.g., the expected computation runtime using the computational resources available to the client exceeds a maximum acceptable threshold), although this is not always the case. Generally speaking, a client can delegate the evaluation of a function f of an input x based on any suitable criteria, such as computational runtime, computational cost (e.g., the financial cost of allocating computational resources to perform the function evaluation), etc.
[0064] In an embodiment, a worker is any suitable computing entity, such as a blockchain node as described in more detail elsewhere in this disclosure. In an embodiment, a worker (e.g., a blockchain node) evaluates a function f of an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by other computing entities, such as clients and / or other nodes of the blockchain network as described above. Verification of the proof (which may also be referred to as an argument) is faster than actual computation - therefore, the correctness of the output generated by the above worker can be determined by verifying the correctness of the proof rather than recomputing the function f of the input x, reducing computational overhead (e.g., reducing power overhead and costs associated with powering and running computing resources). In zero-knowledge verifiable computation, a worker provides a client with evidence that the worker knows an input with specific properties.
[0065] An efficient variant of zero-knowledge proofs of knowledge is zk_SNARK (succinct non-interactive argument of knowledge). In an embodiment, all pairing-based zk-SNARKs include a process where the worker uses a general group operation to compute multiple group elements, and the verifier uses multiple pairing product equations to verify the proof. In an embodiment, the linear interactive proof works on a finite field, and the worker and verifier's messages include information that encodes, references, or otherwise includes information that can be used to determine the field element vector.
[0066] In an embodiment, the systems and methods described herein allow miners (e.g., nodes) of a blockchain to perform a computation (e.g., evaluation of a function f on an input x) once and generate a proof that can be used to verify the correctness of the output, where evaluating the correctness of the proof is computationally cheaper than evaluating the function. In this context, the cost of an operation or task (i.e., how expensive it is) 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, e.g., both the heap sort algorithm and the quick sort algorithm have an average computational cost of O(n log n), but the worst-case computational cost of quick sort is O(n log n). 2 ), while the worst-case computational cost of a heap sort is O(n log n). In an embodiment, the average computational cost and / or the worst-case computational cost of evaluating a function f for an input x is worse than the average computational cost and / or the worst-case computational cost of evaluating the correctness of a proof. 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 will not increase the time required to verify a blockchain proportionally. Further advantages may include reducing power consumption of a verifier system, thereby increasing the efficiency of a verifier computer system, and reducing energy costs associated with running such a verifier computer system when evaluating the correctness of a proof.
[0067] In an embodiment, the verification key VK or a portion thereof may be extracted from the public parameters generated in the setup phase of the zero-knowledge protocol and used together with the proof π and the input / output data to verify the claimed proof of correctness computation provided by the working party. For example, as described above and in more detail below, systems and methods that allow locking scripts to prevent the verification key VK from being altered and to check the validity of the proof π allow the zero-knowledge protocol to be executed on the blockchain during transaction verification. Thus, the present disclosure proposes systems and methods for executing the verification phase using a blockchain script (e.g., in a Bitcoin-based network) that is used to store elements used in the verification of the computation.
[0068] Figure 3 An example 300 of a workflow from a domain specific language (DSL) code to a quadratic arithmetic program (QAP) according to an embodiment of the present disclosure is shown. Specifically, Figure 3Depicted is the conversion of DSL code 302 into GPL code 306 by converter 304. GPL precompiler 308 (also referred to as preprocessor) contains external library 310 referenced by GPL code 306 to generate GPL preprocessed code 312. GPL preprocessed code 312 is converted into arithmetic circuit 314, arithmetic circuit 314 is optimized to generate simplified arithmetic circuit 316, arithmetic circuit 316 is compressed to generate serialized circuit 320, and QAP polynomial 318 is derived from serialized circuit 320.
[0069] In an embodiment, the domain specific language (DSL) code 302 is an application program written in a formal language with precise semantics. In an embodiment, the DSL code 302 includes a set of conditions, and the result of the DSL code 302 depends on the satisfaction of the set of conditions. An example of an application program (e.g., a smart contract) is an insurance contract that takes as input the insurance premium of the insured and the potential compensation of the insurer to the insured. If the insured suffers a loss during the smart contract period (e.g., the first condition is satisfied), the execution of the smart contract allocates the insurance premium to the insurer and the compensation for the loss to the insured. On the other hand, if the insured does not suffer a loss during the smart contract period, the execution of the smart contract allocates the insurance premium to the insurer and returns the potential compensation to the insurer.
[0070] In an embodiment, converter 304 is a software program that, upon execution, receives a set of conditions, such as DSL code 302 written in a DSL, and converts the DSL code into a GPL source code, such as GPL code 306. In an embodiment, GPL code 306 is a GPL program, such as a C++ program, that contains the code defined in DSL code 302. In some examples, a general purpose programming language or "general purpose language" (GPL) is widely applicable, as opposed to a DSL. Examples of general-purpose programming languages include Ada, ALGOL, assembly language, BASIC, Boo, C, C++, C#, Clojure, COBOL, Crystal, D, Dart, Elixir, Erlang, F#, Fortran, Go, Harbour, Haskell, Idris, Java, JavaScript, Julia, Lisp, Lua, Modula-2, NPL, Oberon, Objective-C, Pascal, Perl, PHP, Pike, PL / I, Python, Ring, RPG, Ruby, Rust, Scala, Simula, Swift, and Tcl. C++, which can be consulted in the embodiments of the present disclosure, is a general-purpose programming language with imperative, object-oriented, and general-purpose programming features, while also providing convenience for low-level memory manipulation. Figure 3 It should be noted that in the context of the present invention, "code" may alternatively refer to executable code (e.g., object code), source code, both, either or a combination thereof, depending on the context being described.
[0071] In an embodiment, GPL precompiler 308 is a computer executable program that processes GPL code 306 and required external libraries 310 to generate independent GPL preprocessed code 312. In an embodiment, GPL precompiler 308 evaluates constant expressions and registers symbols found in GPL code 306.
[0072] In an embodiment, external library 310 is a collection of pre-written subroutines, functions, classes, containers, values, and / or variable types that are used by calling GPL code 306. For example, by calling external library 310, GPL code 306 obtains the functionality of the library without having to implement the functionality itself.
[0073] In an embodiment, the GPL preprocessing code 312 includes a set of expressions and operators. The operators may include arithmetic operators (e.g., addition (+), multiplication (*), etc.), comparison operators (e.g., less than (<), equal to (==), greater than or equal to (>=), etc.), conditional statements (e.g., if-then (?, :)), or logical operators (e.g., AND (&&), OR (||), NOT (!), XOR, etc.). In some embodiments, the generated main function has a predefined name and format.
[0074] In an embodiment, arithmetic circuit 314 is a DAG over a set of variables. In an embodiment, each node of the DAG with in-degree zero is a node representing a variable (e.g., x i ), and every other node of the DAG is either a sum gate (+) or a product gate (×). In an embodiment, the out-degree of each gate (node) is 1, so the underlying graph is a directed tree. In an embodiment, arithmetic circuit 314 has two complexity measures: size and depth. In some examples, the "size" of the arithmetic circuit is based on the number of gates within arithmetic circuit 314. In some examples, the "depth" of the arithmetic circuit is based on the length of the longest directed path within the arithmetic circuit.
[0075] In an embodiment, the simplified arithmetic circuit 316 is a simplified or minimized directed acyclic graph (DAG) that can be used to determine the results of a set of conditions, such as the conditions specified in the DSL code 302 under a given set of inputs. In some embodiments, the simplified arithmetic circuit 316 is a minimized (i.e., simplified to a minimum) arithmetic circuit. In some embodiments, the optimal arithmetic circuit may not necessarily be the smallest arithmetic circuit (e.g., some larger arithmetic circuits may be evaluated faster than larger arithmetic circuits depending on the number and type of arithmetic operations in the circuit), and in such embodiments, the simplified arithmetic circuit 316 is optimized (e.g., for maximum speed, less memory usage, most efficient processor utilization, etc.), but not necessarily a minimized arithmetic circuit. The simplified arithmetic circuit 316 may be generated using the techniques described in UK patent application number GB1718505.9.
[0076] Arithmetic circuits such as simplified arithmetic circuit 316 may be compressed according to the techniques described herein to generate serialized circuit 320. Serialized circuit 320 may be used in situations where code templates or standard applications need to be stored and retrieved. By utilizing serialized circuit 320, parties may avoid the need to create circuit instances from the GPL each time a new application is created, thereby increasing the efficiency of the protocol where the client and the proving party reuse certain code templates or portions thereof. Serialized circuit 320 may be generated using entropy encoding of the most frequent elements in a data structure, such as arithmetic operator types. Instructions for deserialization and decompression (e.g., a codebook for mapping serialized code to source symbols) may be embedded in the serialized bitstream, which enables a recipient of the serialized circuit to reconstruct the source circuit.
[0077] In an embodiment, QAP polynomial 318 is one or more expressions including variables and coefficients expressed in a mathematical formula that provides a mathematical representation of the original arithmetic circuit (e.g., Figure 4 A complete description of the arithmetic circuit 314 of FIG. 314 is provided. In an embodiment, the polynomials of the QAP polynomial are defined in terms of their evaluations of roots in arithmetic circuits, such as described in Gennaro, R. et al., Quadratic Span Programs and Succint NIZKs without PCPs (2013). In an embodiment, the QAP polynomial is encoded into a locking script of a blockchain transaction as a representation of a smart contract. In an embodiment, the locking script receives a set of parameter values when executed (e.g., as a result of executing the locking script), and the set of parameter values is input as variables into the QAP polynomial to cause the result determination of the smart contract.
[0078] In an embodiment, GPL precompiler 308 generates GPL preprocessed code 312, which may be an arithmetic circuit including arithmetic gates. However, please note that the complex arithmetic circuit also embeds logic submodules due to conditional and flow control statements.
[0079] Figure 4A process 400 for reducing the size of an arithmetic circuit is shown. In an embodiment, the arithmetic circuit has a header encoded with or associated with the body. In an embodiment, the body of the circuit contains a line identifier and a gate type for the gate. The header may include information such as metadata associated with the body. In an embodiment, the arithmetic circuit is converted into a binary data stream characterized by a measure of entropy approaching the theoretical limit defined by Shannon's source coding theorem. In some cases, the serialized circuit refers to a binary data stream and has an entropy value that is higher than the entropy value of the arithmetic circuit. "Entropy" as described in the present disclosure refers to entropy according to the principles of information theory described in Shannon, C., A Mathematical Theory of Communication (1955).
[0080] Process 400 may be performed by any suitable computer system, such as in conjunction with Figure 2 The computer system described in this specification can be composed of Figure 2 The client described in , or another computing entity (such as a worker tasked with serializing an arithmetic circuit) performs compression and optimization. Given a generic circuit, the system will identify a list of global parameters. The sender and receiver in the serialization scheme can exchange the following information: a version number, which in some embodiments includes additional information, such as the encoding scheme or codebook used to serialize the circuit; the total number of lines N; the bit width n bit ; and their combinations.
[0081] In an embodiment, a system implementing process 400 includes a memory storing executable code that, if executed by one or more processors, causes the system to obtain 402 an arithmetic circuit that can be represented by a set of data fields. In an embodiment, the set of data fields includes gates or operators, and lines representing inputs and outputs. It should be noted that a line can be an output of a first gate and an input of another gate at the same time. A line can also be an input and an output of a gate.
[0082] The system can use simplification rules to remove the data fields of the arithmetic circuit 404. The simplification rules can be used to remove the first subset of the data fields of the arithmetic circuit that can be derived from the remaining data fields, and the first subset of the data fields can be referred to as the second subset of the data fields of the arithmetic circuit. Based on the characteristics of the data fields of the arithmetic circuit, the first subset and the second subset can be disjoint sets that do not have common elements. Each data field of the arithmetic circuit can be classified as a calculation field or a storage field, so that the calculation field is assigned to the first subset and the storage field is assigned to the second subset. It may be the case that the data field may not be characterized as a calculation field and a storage field at the same time. In an embodiment, a calculation field refers to a data field that can be derived from one or more storage fields. In general, an illustrative example can be used to explain this concept: if there are data fields storing the start time, the end time, and the duration of the time interval, the end time can be identified as a calculation field, and the start time and the duration are storage fields, because the end time can be determined from one or more storage fields (for example, the end time = the start time + the duration). Of course, in this example, the duration can also be represented as a calculation field, and the start time and the end time can be represented as storage fields (for example, the duration = the end time - the start time). As described above, no field is both a calculated field and a stored field, but rather a calculated field or a stored field based on a representation that may be selected programmatically (eg, by executing an algorithm) or by a user.
[0083] In an embodiment, the system identifies one or more data fields in the set of data fields that can be removed based at least in part on determining whether the data field is derivable from other data fields in the set. As a first example, the simplification rule may allow the removal of an input line identifier because, starting with id0, the first n inputs identifiers are reserved for input. Therefore, the value n inputs It is sufficient to determine the number of The identifiers of the inputs are automatically incremented so that the first input is assigned id0, the second input is assigned id1, and so on.
[0084] There may be other simplification rules. As a second example, the line identifier of the output gate may be removed so that Starting with , each wire identifier of an output gate is automatically incremented. For example, if the circuit consists of only two gates, the output of the first gate begins with is characterized by the fact that the output of the second gate is The order of the gates can be determined by, for example, Figure 2The order of arithmetic operations specified by the interpreter described. The interpreter can be implemented using the techniques described in UK Patent Application No. GB 1801753.3. As a third example, by default, the first input of the first gate (e.g., in the order determined by the interpreter) is assigned as id0. As a fourth example, the last output line identifier is not required because given the total number of lines N, id N-1 defaults to the output line. Embodiments may not implement any of the described example simplification rules, or may implement all or part of the described example simplification rules. Figure 5 An example of an arithmetic circuit applying the described simplification rules is shown. It should be noted that the simplification rules described above are merely illustrative, and various embodiments may implement some or all of the simplification rules, and other simplification rules may be known to those skilled in the art.
[0085] Entropy coding can be applied to the arithmetic circuit to reduce the amount of data required to encode highly repetitive parts of the circuit (e.g., arithmetic operations). In some cases, the system can determine a 406 codebook that maps a set of data fields to a set of codes. Huffman coding can be used to generate a variable-length code table for serialization of source symbols. Generally, given a set of M different source symbols, which may include the types of operations defined for the arithmetic circuit, a probability p i is specified for each symbol i, 0 ≤ i < M. In an embodiment, a binary tree is generated that takes the two least likely symbols and combines them to form a new symbol. For example, if p a and p b are the two least likely symbols, they form a new symbol p ab , such that p ab = p a + p b . This process is repeated until there is only one symbol. The tree can be read backwards to assign different codes to different branches. The codes can be assigned according to the Huffman coding scheme. It should be noted that the generated tree may contain leaf nodes with different tree depths - in this case, generally, symbols with higher probabilities are closer to the root than symbols with relatively lower probabilities. In this way, compared to symbols with lower occurrence frequencies, fewer bits can be used to encode symbols with higher occurrence frequencies. In other words, in an embodiment, the length of the code is inversely proportional to the frequency of the symbol.
[0086] The binary tree and symbol codes can vary according to the value of M and the individual symbol probabilities p i , 0 ≤ i < M. For example, if M is a power of 2, then p i = 2p i+1 and p M-2 = pM-1 = 2 -M+1 , and the total number of bits S required to encode the arithmetic operation ops is as follows:
[0087]
[0088] Therefore, the compression ratio R for encoding the arithmetic operation is as follows:
[0089]
[0090] Due to the linear relationship between p and ω, i.e., ω M-2 = ω M-1 = 1 and ω i = 2ω i+1 , 0 ≤ i < M – 1, the above equation can be simplified as follows:
[0091]
[0092] When M > 5, the normalized ratio R / n0 is less than 1, i.e., we do not actually compress n0. The larger M is, the higher the compression ratio. In the above manner, 408 arithmetic circuits can be compressed. In an embodiment, the compression circuit is a serialized data stream that encodes the representation of the circuit (e.g., the simplified and / or encoded version of the original circuit as described above). In an embodiment, the serialized circuit includes a body that encodes the representation of the circuit and a header that includes one or more of the following: version number, total number of wires, bit width n bit , codebook, or any combination thereof. In some cases, the codebook can be selected from multiple codebooks, and the appropriate codebook can be selected based on the query version number. For example, the first codebook in the codebook list can correspond to version 1, the second codebook in the list corresponds to version 2, and so on. In an embodiment, the codebook can be pre-generated.
[0093] Figure 5 FIG. 500 showing an arithmetic circuit 502 and a serialized circuit 504 according to an embodiment. Figure 5 The serialized circuit 504 shown in can be a compressed version of the arithmetic circuit generated using a set of simplification rules. A lossless compression routine can be applied to the arithmetic circuit 502 to generate the serialized circuit 504; a lossless decompression routine can be applied to the serialized circuit 504 to perfectly regenerate the serialized circuit 504 (e.g., bit-by-bit precision).
[0094] As Figure 5As shown, an example arithmetic circuit may include header metadata including: version information, a field N indicating numbered wires, and identifiers for inputs (0, 1, 2) and outputs (4, 5) of the circuit. It should be noted that some wires are neither inputs nor outputs of the circuit (e.g., wires that are intermediate inputs or outputs of the circuit). The information in the header need not be encoded at the header of the data structure, or even consecutively, such as Figure 5 , where the output data is encoded at the end of the data structure. The arithmetic circuit also encodes the data field of the gate, followed by a collection of inputs and outputs. For example, as shown in arithmetic circuit 502:
[0095] add
[0096] It refers to an addition gate that adds the values of the lines corresponding to the identifiers id0 and id1 and generates an output for the line corresponding to the identifier id3. As a second example, "multiply 1 2 4" refers to a multiplication gate that multiplies the values of the lines identified as the identifiers id1 and id2 and produces the product at the line identified by id4. Therefore, the uncompressed arithmetic circuit 502 can be represented as:
[0097] Version 1
[0098] N6
[0099] enter
[0100] add
[0101] Multiply 1 2 4
[0102] Multiply 3 4 5
[0103] Output 4 5
[0104] The arithmetic circuit 502 can be compressed into a serialized circuit 504 by applying simplification rules. A first simplification rule may be that if the number of inputs is encoded, then the line identifiers of the inputs are not needed. The number of inputs may alternatively refer to the cardinal number or cardinality of the set of inputs. For example, the cardinality of the inputs (0, 1, 2) described above is 2. Thus, following the simplification rules, the arithmetic circuit is compressed into the following:
[0105] Version 1
[0106] N6 2
[0108] add
[0109] Multiply 1 2 4
[0110] Multiply 3 4 5
[0111] Output 4 5
[0112] A second simplification rule may be that the line identifier does not require an output gate, since it can be obtained from n inputs Start automatically increasing the line identifier of the output gate. Therefore, following the first simplification rule and the second simplification rule, the arithmetic circuit is compressed to the following:
[0113] Version 1
[0114] N6
[0115] add
[0116] Multiply 1 2
[0117] Multiply 3 4 4 5
[0119] The third simplification rule may be that the first input to the first gate is not required because the first identifier is assigned to the line by default. Therefore, following the first simplification rule, the second simplification rule, and the third simplification rule, the arithmetic circuit is compressed to the following:
[0120] Version 1
[0121] N6 2
[0123] Add 1
[0124] Multiply 1 2
[0125] Multiply 3 4 4 5
[0127] The fourth simplification rule may be that the last output line identifier is not required, because the last line identifier is defined as the output line by default. Therefore, following the first simplification rule, the second simplification rule, the third simplification rule and the fourth simplification rule, the arithmetic circuit is compressed to the following:
[0128] Version 1
[0129] N6 2
[0131] Add 1
[0132] Multiply 1 2
[0133] Multiply 3 4 4
[0135] It should be noted that the serialization circuit 504 may be further compressed, such as by using entropy coding techniques.
[0136] Figure 6 600 shows a circuit serialization. The top input arithmetic circuit 602 is represented in ASCII. In an embodiment, the first serialization circuit 604 is applied where n w =32 serialization technology, the second serialization circuit 606 is applied with n w = 8. The solid black boxes represent unused bits, which are filled with zeros in an embodiment.
[0137] In an embodiment, rules for simplifying data fields and entropy encoding arithmetic operations are used to construct an efficient serialization of an arithmetic circuit. The header of the data structure may include: a version byte, an integer (e.g., signed or unsigned) value of the number of inputs / outputs, the number of lines, a list of output line identifiers other than the last (as described in conjunction with the simplification rules, the last output line identifier may be omitted while still achieving lossless compression), and combinations thereof. In an embodiment, the version byte embeds a configuration that is valid for a particular circuit. The recipient of the serialized circuit may use the version byte to determine how to deserialize the serialized circuit. For example, the structure of the version byte (or bytes) may be as follows:
[0138] Bits 0 and 1: Instruction set. The instruction set defines the types of instructions defined for the circuit. Addition and multiplication are always defined, but additional operators can be defined depending on the circuit functionality, for example, line compression, line expansion, equal to zero operator, and compare zero operator. Therefore, the following configurations can be introduced:
[0139] 00: M = instruction set of 2 types of operators.
[0140] 01: M = instruction set of 4 types of operators.
[0141] · 10: M = instruction set of 8 types of operators.
[0142] · 11: M = instruction set of 16 types of operators.
[0143] Bits 2, 3 and 4: Number of inputs / outputs. This field specifies the bit width of the field containing the number of inputs and the number of outputs. For example, the following configuration can be introduced:
[0144] 000: 2-bit input, 2-bit output.
[0145] 001: 2-bit input, 4-bit output.
[0146] 010: 2-bit input, 8-bit output.
[0147] 011: 4-bit input, 2-bit output.
[0148] 100: 4-bit input, 4-bit output.
[0149] 101: 4-bit input, 8-bit output.
[0150] 110: 8-bit input, 4-bit output.
[0151] 111: 8-bit input, 8-bit output.
[0152] Bits 5 and 6: Line identifier width n w Depending on the number of wires N in the circuit, a specific number of bits can be allocated to encode the wire identifier. For example, the following configuration can be introduced:
[0153] 00: Line identifier, N is encoded in 8 bits.
[0154] 01: Line identifier, N is encoded in 16 bits.
[0155] 10: Line identifier, N is encoded in 32 bits.
[0156] 11: Line identifier, N is encoded in 64 bits.
[0157] Bit 7: Bit width n bit The circuit can be optimized for a specific computer architecture. For example, the following configuration can be introduced:
[0158] 0: 32-bit architecture.
[0159] 1: 64-bit architecture.
[0160] In some embodiments, more bytes may be reserved for version information, allowing additional configurations and fields to be defined.
[0161] The instruction set field can be used to select the correct dictionary for entropy encoding. If a specific number of dictionaries is predefined, then the correct dictionary does not need to be encoded in the circuit. For example, if M is a power of 2, then the scheme with symbol probabilities specified above can be defined. Thus, given a specific instruction set, a specific dictionary can be retrieved.
[0162] In an embodiment, the body of the circuit contains the gate type and the serial line identifier of the input gate. In an embodiment, the size of the line identifier is predefined and encoded in an integer byte, so the line identifier is encoded first and then the encoded gates are embedded. This can result in more efficient serialization and deserialization, such as in architectures where data fields may need to be padded to the nearest complete byte. It should be noted that according to at least one embodiment, advanced encoding schemes may also be applied and the line identifier does not need to be encoded in the form of an integer byte. During deserialization, the receiver knows the value of N from the header. After reading the line identifier, the remaining bit stream represents the encoded arithmetic operation. The encoded gates may not be aligned to bytes, however bitwise operations can be used to embed multiple gates into a single byte. For example, given two symbols a1 and a2 encoded independently in 4 bits, a single byte b can be used to summarize the information:
[0163] b=(a1<<4)+a2
[0164] The bitwise operator "<<" is a left shift. It is also possible to split a gate between two or more bytes according to a specific dictionary.
[0165] In an embodiment, the entropy encoder constructs the code in a way that enables the decoder to detect where each symbol code begins and ends. Therefore, the correct line identifier sequence is assigned to each arithmetic operation depending on the number of inputs required. For example, if the next line to be read is the i-th in the sequence, and the next operator starts at the j-th position in the stream, then the following is performed:
[0166] 1. Detect symbol a with the first bit of position j j .
[0167] 2. Compute the symbol size s(a) using information from the dictionary j ).
[0168] 3. Calculate the symbol a i The number of input lines n(a j ).
[0169] 4. Store the data with code a i and line identifiers (i,i+1,…,i+n(a i )-1) is an arithmetic operation.
[0170] 5. Move the indicator to j+s(a j ) next symbol.
[0171] 6. Move the counter to i+n(a j )'s next line.
[0172] In an embodiment, the process ends when N lines have been read. If the stream has been correctly encoded, the pointer to the next symbol is the end of the stream when the Nth line is read. In an embodiment, the last symbol may not be byte aligned, and padding may be used to align the last symbol, for example using zero padding, one padding, or zero-one padding.
[0173] Therefore, in an embodiment, Figure 6 A comprehensive example for the serialization process is shown, where we consider a dictionary with M=3 and a text file in ASCII (i.e., n o =8) encoded initial arithmetic circuit. Huffman codes can be used in conjunction with the serialization process. For example, according to the Huffman code, the most frequent operation is encoded as a one-bit value (e.g., multiplication (MUL) is encoded as "0"), the second most frequent operation is encoded as a two-bit value (e.g., addition (ADD) is encoded as "10"), and so on (e.g., the third operation is encoded as "11"). If n w =32, the compression ratio relative to ASCCI coding is 2.44, and if n w =8, the compression ratio is 8.11.
[0174] Figure 7 is an illustrative simplified block diagram of a computing device 700 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 700 can be used to implement any of the systems shown and described above. For example, the computing device 700 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Figure 7 As shown, computing device 700 may include one or more processors 702, which in an embodiment are configured to communicate with and operably couple to a plurality of peripheral subsystems via bus subsystem 704. In some embodiments, these peripheral subsystems include: storage subsystem 706, including memory subsystem 708 and file / disk storage subsystem 710; one or more user interface input devices 712; one or more user interface output devices 714; and network interface subsystem 716. Such storage subsystem 706 may be used for temporary or long-term storage of information.
[0175] In some embodiments, bus subsystem 704 provides a mechanism that enables the various components and subsystems of computing device 700 to communicate with each other as expected. Although bus subsystem 704 is schematically shown as a single bus, alternative embodiments of the bus subsystem utilize multiple buses. In some embodiments, network interface subsystem 716 provides interfaces with other computing devices and networks. In some embodiments, network interface subsystem 716 is used as an interface for receiving data from other systems and sending data from computing devices to other systems. In some embodiments, bus subsystem 704 is used to convey data such as details, search terms, etc.
[0176] In some embodiments, the user interface input device 712 includes: one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen included in a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 700. In some embodiments, the one or more user interface output devices 714 include a display subsystem, a printer, or a non-visual display such as an audio output device, etc. In some embodiments, the display subsystem includes a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 700. When such interaction may be appropriate, for example, one or more user interface output devices 714 may be used to present a user interface to facilitate user interaction with an application that performs the described processes and variations therein.
[0177] In some embodiments, the storage subsystem 706 provides a computer-readable storage medium for storing basic programs and data structures that provide the functions of at least one embodiment of the present disclosure. In some embodiments, when an application program (program, code module, instruction) is executed by one or more processors, the functions of one or more embodiments of the present disclosure are provided, and in an embodiment, the application program is stored in the storage subsystem 706. These application modules or instructions can be executed by one or more processors 702. In various embodiments, the storage subsystem 706 additionally provides a repository for storing data used according to the present disclosure. In some embodiments, the storage subsystem 706 includes a memory subsystem 708 and a file / disk storage subsystem 710.
[0178] In embodiments, memory subsystem 708 includes a plurality of memories, such as a primary random access memory (RAM) 718 for storing instructions and data during program execution and / or a fixed read-only memory (ROM) 720 in which instructions may be stored. In some embodiments, file / disk storage subsystem 710 provides non-temporary persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive and associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, removable media cartridges, or other similar storage media.
[0179] In some embodiments, computing device 700 includes at least one local clock 724. In some embodiments, local clock 724 is a counter that indicates the number of ticks that have occurred since a specific start date, and in some embodiments, local clock 724 is entirely located within computing device 700. In various embodiments, local clock 724 is used to synchronize data transfers in processors of computing device 700 and subsystems included therein with specific clock pulses, and can be used to coordinate synchronous operations between computing device 700 and other systems in a data center. In another embodiment, the local clock is a programmable interval timer.
[0180] The computing device 700 can be any of a variety of types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, in some embodiments, the computing device 700 can include other devices that can be connected to the computing device 700 via one or more ports (e.g., USB, headphone jack, lightning connector, etc.). In an embodiment, such a device includes a port configured to accept a fiber optic connector. Thus, in some embodiments, the device is configured to convert optical signals into electrical signals that are transmitted through the port connecting the device to the computing device 700 for processing. Due to the ever-changing nature of computers and networks, for the purpose of illustrating preferred embodiments of the device, Figure 7 The description of computing device 700 depicted in FIG. 7 is intended only as a specific example. Figure 7 Many other configurations are possible with more or fewer components of the depicted systems.
[0181] Therefore, the description and the drawings should be considered in an illustrative rather than a restrictive sense. However, it will be apparent that various modifications and changes may be made thereto without departing from the scope of the invention as set forth in the claims. Likewise, other variations are also within the scope of the present disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, some of its illustrated embodiments are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the present invention to one or more specific forms disclosed, on the contrary, the present invention is intended to cover all modifications, alternative constructions and equivalents falling within the scope of the present invention, as defined in the appended claims.
[0182] In the context of describing the disclosed embodiments (particularly in the context of the attached claims), the use of the terms "one" and "the" and similar references should be interpreted as covering singular and plural forms, unless otherwise stated or clearly contradictory to the context. Unless otherwise stated, the terms "include", "have", "include" and "contain" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connection" should be understood as being partially or completely contained, attached or joined together when it is not modified and relates to a physical connection, even if there is some intervention. Unless otherwise noted, the narration of the value range in the present disclosure is only intended to be used as a shorthand method to refer to each individual value falling within the range, and each individual value is incorporated into the specification as if it is narrated separately. Unless otherwise indicated or contradictory in the context, the use of the term "set" (e.g., "item set") or "subset" should be interpreted as a non-empty set including one or more members. In addition, unless otherwise indicated or contradictory in the context, the term "subset" of the corresponding set does not necessarily represent a suitable subset of the corresponding set, but a subset and a corresponding set can be equal.
[0183] Unless expressly stated otherwise or clearly contradicted by context, conjunction 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 otherwise understood in context as generally used to indicate that an item, term, or the like, may be A or B or C, or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set having three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunction language is not generally intended to imply that certain embodiments require the presence of at least one of A, at least one of B, and at least one of C.
[0184] The operations of the described processes may be performed in any suitable order unless otherwise indicated or clearly contradicted by the context. The described processes (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors by hardware or a combination thereof. In some embodiments, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program that includes a plurality of instructions executable by one or more processors. In some embodiments, the computer-readable storage medium is non-transitory.
[0185] The use of any and all examples or exemplary language (e.g., "such as") provided is intended merely to better illustrate embodiments of the invention and does not constitute a limitation on the scope of the invention unless otherwise required. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.
[0186] Embodiments of the present disclosure are described, including the best mode known to the inventor for implementing the present invention. By reading the foregoing description, variations of those embodiments will become apparent to those of ordinary skill in the art. The inventor expects that skilled technicians will appropriately adopt such variations, and the inventor hopes that the embodiments of the present disclosure can be practiced in a manner different from the specific description. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter recorded in the attached claims as allowed by applicable law. In addition, unless otherwise noted or clearly contradictory to the context, any combination of the above-mentioned elements in all possible variations thereof is covered by the scope of the present disclosure.
[0187] All references cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein. This includes UK patent application numbers: GB 1719998.5, GB 1718505.9, GB 1720768.9.
[0188] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals placed in brackets shall not be interpreted as limiting the claims. The words "comprises" and "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, "comprises" means "including or consisting of..." and "comprising" means "including or consisting of...". The singular form of an element does not exclude the plural form of such an element, and vice versa. The present invention may be implemented by hardware comprising a plurality of different elements and by a suitably programmed computer. In a device claim enumerating a plurality of means, several of these means may be embodied by one and the same hardware. The fact that certain measures are recorded in mutually different dependent claims does not mean that the combination of these measures cannot be used to benefit.
Claims
1. A computer-implemented method comprising: Reducing the data footprint of an arithmetic circuit, the arithmetic circuit comprising information represented by a set of symbols for generating a program, the execution of which is delegated to one or more nodes of a blockchain network, wherein the arithmetic circuit comprises the following information: a total number of line identifiers, line identifiers for inputs and outputs of the arithmetic circuit, a gate, and line identifiers for inputs and outputs of the gate, wherein the footprint is reduced by at least the following steps: identifying a first subset of at least one line identifier to apply a simplification rule, wherein the simplification rule comprises removing the first subset of line identifiers from the arithmetic circuit to generate the serialized circuit, wherein the first subset of line identifiers is derivable from at least one of: remaining line identifiers, and a total number of inputs to the arithmetic circuit; and applying an entropy coding scheme to the serialized circuit to generate a compressed arithmetic circuit; and causing the compressed arithmetic circuit to be stored.
2. The computer-implemented method of claim 1 , wherein: Arithmetic circuits are text files that include: Version information, The total number of line identifiers, indicates the number of the line identifier for the input of the arithmetic circuit, an ordered list of at least one gate, each gate comprising an operator, a line identifier of at least one input and a line identifier of an output, and Indicates the number of the line identifier used for the output from the arithmetic circuit.
3. The computer-implemented method of claim 2, wherein: The first subset of line identifiers includes line identifiers of all inputs to the arithmetic circuit, and the simplification rule further includes inserting the total number of inputs to the arithmetic circuit.
4. A computer-implemented method according to claim 2 or 3, wherein: The first subset of line identifiers includes line identifiers of outputs of the gate.
5. A computer-implemented method according to any one of claims 2 to 3, wherein: The first subset includes the first input of the first gate in the ordered list.
6. A computer-implemented method according to any one of claims 2 to 3, wherein: The first subset includes the line identifier with the largest number removed from the output of the arithmetic circuit.
7. The computer-implemented method of any one of claims 1 to 3, wherein: The entropy coding scheme applied to serialized circuits includes: determining a set of symbols from the serialized circuit; and A corresponding code is assigned to each symbol in the set of symbols.
8. The computer-implemented method of claim 5, wherein: Symbols in the set of symbols are repeated at least twice in the serialization circuit.
9. The computer-implemented method of claim 7, wherein: The length of a code is inversely proportional to the frequency of the symbols corresponding to the code.
10. The computer-implemented method of claim 7, wherein: Generates a code corresponding to a symbol based on the Huffman code.
11. The computer-implemented method of any one of claims 2 to 3, wherein: The serialization circuit includes: a body comprising an ordered list of gates and serialized line identifiers of the gates; and Header data structure, the header data structure includes a version number and the total number of line identifiers.
12. The computer-implemented method of claim 11, wherein: The header data structure also includes a bit width that can be used to implement execution optimizations based at least in part on a target architecture.
13. The computer-implemented method of any one of claims 9 to 10, wherein: The version number indicates the encoding scheme that can be used to determine the symbol from the code.
14. The computer-implemented method of any one of claims 1 to 3, wherein: The arithmetic circuits are independent of the architecture.
15. A system comprising: processor; as well as A memory comprising executable instructions which, due to execution by a processor, cause the system to perform a computer-implemented method according to any one of claims 1 to 14.
16. A non-transitory computer-readable storage medium storing executable instructions, the executable instructions causing the computer system to perform at least the computer-implemented method according to any one of claims 1 to 14 when executed by a processor of the computer system.
Citation Information
Patent Citations
Computer-implemented system and method
GB201718505D0
Computer-implemented system and method
GB201801753D0