Outsourcing of calculations using blockchain

Abstract

A computer implementation method for outsourcing computations using blockchain, comprising: obtaining one or more respective secondary computations, each of which is performed using respective inputs based on each part of a primary computation and each verification algorithm, thereby generating the respective results of each part of a primary computation and each verification output of each verification algorithm; obtaining a plurality of respective inputs to a primary computation; generating each outsourcing transaction for each secondary computation, each of which is locked to a respective lock value based on its respective verification output; making each outsourcing transaction available to each computational party; and making both each secondary computation or its encrypted version and each input or its encrypted version available to each computational party.

Description

[Technical Field]

[0001] This disclosure relates to a method for outsourcing computations (for example, training neural networks) using blockchain technology. [Background technology]

[0002] Artificial intelligence (AI), machine learning (ML), and neural networks (NN) have proven capable of assisting with everyday tasks, and in some cases, even outperforming humans. However, improvements in computing power come with economic and computational costs, as well as ethical and legal issues.

[0003] Advances in ML reduce economic and computational costs by providing models better suited to specific tasks. However, large corporations can provide more training data and deploy more resources, and are likely to outperform smaller companies and research institutions, regardless of any breakthroughs. Decentralized AI is a comprehensive definition that covers a wide range of different machine learning techniques and architectures that share the characteristic of being able to distribute parts of AI across different parties and devices. Decentralized (or distributed) machine learning (DML) is a subfield of ML that investigates the training and execution of distributed AI. The main line of research in DML is known as federative learning (FL), which assumes decentralization of training data. Decentralization can be achieved by different means (e.g., increasing the parallelization of models), and therefore FL is not the only form of DML.

[0004] The explainability of AI is a thriving topic, often devoted to investigating the "thought processes" of AI. However, the availability of powerful neural networks such as ChatGPT and Dall-E has created a new urgency in this discussion, which is incompatible with the required research time. As a result, topics such as auditing AI are becoming increasingly popular.

[0005] A shared common characteristic of ML techniques is their reliance on a set of data to execute optimization algorithms that improve the performance of neural networks. This is generally referred to as the training phase. DL investigates how to decentralize the training phase. Decentralization of the training phase can be achieved in several different ways. For example, FL decentralizes the training data. More specifically, this invention studies how a global model can be trained using local models distributed across multiple devices, relying on local, independent data.

[0006] The internal parameters of the neural network are adjusted based on the output of the training phase. The expected result of training is improved performance on data similar to the training set.

[0007] The recent improvements in neural network performance are due to three distinct factors: algorithmic innovation, increased data availability, and improved computing power. Algorithmic innovation is difficult to track and measure, and in any case, is not the focus of this application. The other two factors are closely related: more data leads to larger models and longer training times, thus requiring higher computing power. Similarly, higher computing power allows for the training of larger models that depend on larger datasets.

[0008] Increasing model size and training time leads to increased costs for training and using neural networks.

[0009] Businesses and individuals rely on AI in many different areas every day. However, improvements over the past few years have raised concerns and sparked debate about how deployed AI can be audited for harm by third parties. Auditing processes are beneficial to both users and deployers. The former are protected from potential harm, while the latter can use proactive audits to identify dangerous behavior and intervene in a timely manner. In fact, once AI is trained and deployed, tracing the causes of these behaviors and correcting them is difficult, and sometimes even impossible. [Overview of the Initiative] [Means for solving the problem]

[0010] The disclosure of this application provides technology for implementing a protocol for distributing computation (e.g., programs or algorithms) across different devices using a blockchain, such as an unused transaction output (UTXO) blockchain. The additional benefits that blockchain can bring to existing DL protocols are described below. These include the economic scalability of model training and improved transparency in model auditing. In fact, training and maintaining models (such as neural networks) on a blockchain may in the near future be the only scalable way that enables smaller companies and research institutions to generate valuable and competitive AI with less computing power.

[0011] While the embodiments described herein are particularly advantageous for use cases involving AI, ML, and NN, it should be noted that they can more generally be used to distribute any type of computation that can be divided into multiple sub-computations (e.g., split, partitioned, or unpacked).

[0012] More generally, it should be noted that the embodiments described are not necessarily split into multiple components, but can be used to outsource any computation; that is, the entire computation can be outsourced as a whole.

[0013] According to one aspect disclosed herein, a computer implementation method for outsourcing computations using blockchain is provided, the method being performed by a coordinating party, and comprising: obtaining one or more respective secondary computations, each of which is performed using its respective inputs, based on each part of a primary computation and each verification algorithm, thereby generating the respective results of each part of a primary computation and each verification output of each verification algorithm; obtaining a plurality of respective inputs to a primary computation; generating each respective outsourcing transaction for each secondary computation, each of which is locked to its respective lock value based on its respective verification output; making each respective outsourcing transaction available to each computation party; and making both each secondary computation or its encrypted version and each respective input or its encrypted version available to each computation party.

[0014] One aspect disclosed herein provides a computer implementation method for outsourcing computations using a blockchain, the method being performed by a coordinating party, and comprising: obtaining one or more respective secondary computations, each of which is performed using its respective inputs based on each part of a primary computation and each verification algorithm, thereby generating the respective results of each part of a primary computation and each verification output of each verification algorithm; obtaining a plurality of respective inputs to a primary computation; generating each respective outsourcing transaction for each secondary computation, each of which is locked to its respective lock value based on its respective verification output; making each respective outsourcing transaction available to each computation party; and making both each secondary computation or its encrypted version and each respective input or its encrypted version available to each computation party.

[0015] Embodiments of the present disclosure include, for example, outsourcing computations to one or more computing parties that may have more available computing power than the outsourcing party. This may include having more computing power in general (e.g., better hardware) or having more computing power at the time of outsourcing (e.g., due to an increased but temporary demand for computing power).

[0016] In some embodiments, the coordinating party and the outsourcing party are the same entity. In other embodiments, the coordinating party and the outsourcing party are different entities. In any case, the coordinating party obtains the primary computation to be outsourced (i.e., an algorithm such as training a neural network). For example, by splitting the primary computation into component parts, one or more secondary (or sub, or micro) computations are generated. Each secondary computation includes a verification algorithm, for example, the verification algorithm is combined with the secondary computation. The coordinating party can generate the secondary computation, or the secondary computation can be sent to the coordinating party by the outsourcing party. Execution of the secondary computation (e.g., a combination of a part of the primary computation and the verification algorithm) generates two outputs, namely, the result of the primary computation or a part of the primary computation and a verification value. The verification value can be realistically obtained only by executing the secondary computation. For example, executing the secondary computation to obtain the verification value is only economically advantageous.

[0017] For each secondary computation, a transaction is sent to the blockchain, whereby the transaction (e.g., the output of the transaction in the case of a UTXO blockchain) is locked to a lock value based on the corresponding verification value. The lock value can be, for example, part of a hash puzzle. To unlock the transaction (output), the computing party must execute the secondary computation to obtain the verification value. By doing so, the calculator also obtains the result of the primary computation (part). The result is provided to the coordinating party. By unlocking the transaction (output), the coordinating party can be confident that the computing party should have executed the secondary computation, and thus, can be confident that the provided result is the result of the primary computation (part).

[0018] The exemplary use cases described below involve three actors: an outsourcer (Olivia), an authorized central service (ReCeS), and a user (Ulysses) willing to lend computing power. Olivia is a researcher training a large NN. She has designed the network architecture and prepared the training and test sets, but her computing power is limited, and she knows that it may take a lot of time to train it using her local resources. ReCeS is a service provided by her university to borrow computing power from idle campus machines, registered university staff, and users. A thread-level parallelism (or other suitable type of parallelism) protocol can be implemented in ReCeS to split the computation. There is a reward for lending computing power.

[0019] Further advantages of the described embodiments are provided in the following section XX.

[0020] To assist in understanding the embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings.

Brief Description of the Drawings

[0021] [Figure 1] It is a schematic block diagram of a system for implementing a blockchain. [Figure 2] It is a diagram schematically showing some examples of transactions that can be recorded on a blockchain. [Figure 3] It is a schematic block diagram of a system for outsourcing computation.

Modes for Carrying Out the Invention

[0022] 1. Computation to be Outsourced Figure 3 shows an exemplary system 300 for implementing a protocol for outsourcing computations. System 300 includes a coordinating party ("Coordinator") 301, an outsourcing party ("Outsourcer"), and one or more computing parties ("Users") 103a. Although shown separately, in some examples, the Coordinator 301 may be the same entity as the Outsourcer 302. Although only two users 103 are shown in Figure 3, in general, system 300 may include any number of users. Note that the computing parties 103 are referred to as "Users," but can take any form, such as individual users, groups of users, or machines. For simplicity, the first user ("User A") is referred to as Alice 103a, and the second user ("User B") is referred to as Bob 103b. However, any user may be configured to perform any of the actions described below, as performed by Alice 103a and / or Bob 103b, with reference to Figures 1 and 2. The same applies to the coordinator 301 and the outsourcer 302. Note that unless required by context, “first,” “second,” etc., are used simply as distinguishing labels and do not necessarily imply a specific order.

[0023] As an example, an embodiment will be described with respect to an outsourcer 302 separate from the coordinator 301. However, it should be understood that any action described as being performed by the outsourcer 302 may be performed instead by the coordinator 301, unless the context should imply otherwise.

[0024] Outsourcer 302 sends a computation ("primary computation") to coordinator 301. Outsourcer 302 may also send the source code, or representation, or description of the primary computation, or even an image of the primary computation (for example, showing a circuit with gates). The primary computation can be any type of computation, i.e., a calculation, algorithm, process, etc.

[0025] Outsourcer 302 also sends one or more inputs to coordinator 301 for the primary computation. The inputs can take any form, such as numbers, strings, or a combination of the two. In some examples, the inputs are training data for a neural network. The inputs may be sent in an encrypted form. For example, the inputs may be encrypted with the coordinator's public key, or with an encrypted key separately sent from outsourcer 302 to coordinator 301.

[0026] Coordinator 301 generates one or more secondary calculations based on a primary calculation. In some examples, multiple secondary calculations are generated. In these examples, each secondary calculation includes a part of the primary calculation (i.e., a component, section, etc.). Furthermore, each secondary calculation also includes a verification algorithm. Alternatively, a single secondary calculation includes the entire primary calculation. Each secondary calculation may include the same verification algorithm or different verification algorithms. Secondary calculations can be generated in any suitable way. For example, a primary calculation may first be split into component parts, and then each component part may be combined with a verification algorithm. Here, "combined" can include other operations that generate a secondary calculation based on a part of the primary calculation and a verification algorithm, not limited to concatenation, for example. In another example, one or more verification algorithms may first be combined with a primary calculation, and then the resulting combinations may be split into multiple secondary calculations.

[0027] In some embodiments, the outsourcer 302 generates secondary computations and sends them to the coordinator 301. The secondary computations may be sent in plaintext or encrypted. For example, the secondary computations may be encrypted with the coordinator's public key or with an encrypted key separately sent from the outsourcer 302 to the coordinator 301.

[0028] Performing a component part of a computation based on one or more inputs produces the result of that part of the computation ("partial result"). Performing a verification algorithm based on one or more inputs produces a verification output. In other words, performing a quadratic computation based on one or more inputs produces a partial result and a verification output. A quadratic computation is produced such that a component part of the computation must be performed in order to perform a verification algorithm and obtain a verification output. Typically, the computation and its component part are more difficult to perform (i.e., require more processing power or resources) than the verification algorithm. In some examples, a quadratic computation is compiled such that it is not possible (or at least not easy) to obtain the component part of the computation and the verification algorithm separately.

[0029] In some examples, an identifier is assigned to each component part of each quadratic or primary computation. The verification algorithm for a given quadratic computation may be a function of the assigned identifier. The verification algorithm may, additionally or alternatively, be a function of a seed provided by outsourcer 302. For example, each verification algorithm may be based on a hash of the identifier and the seed.

[0030] For each quadratic computation, Coordinator 301 generates an outsourced transaction that is locked to a “lock value” based on the verification output generated by executing the verification algorithm for the quadratic computation. When implemented on a UTXO-based blockchain such as Bitcoin, it is the output of the outsourced transaction that is locked to the lock value. Embodiments may instead use an account-based blockchain. Here, “locked to a lock value” means that in order to be unlocked, either the verification output or a value based on the verification output (e.g., a hash) must be provided in a consuming transaction (input) that references the outsourced transaction (output). For example, a smart contract may determine whether an input based on the verification output has been provided.

[0031] The lock value can be at least the hash (or double hash) of the verification output. The lock value can be the hash (or double hash) of the verification output and user 103's public key, or a function thereof such as addition or concatenation. In these examples, the outsourced transaction may include a script (e.g., a locking script) configured to implement a hash puzzle based on the lock value.

[0032] In some cases, an outsourced transaction (e.g., the output of an outsourced transaction) may be locked to user 103's public key. That is, a signature generated using the private key corresponding to user 103's public key must be provided to unlock the outsourced transaction (or its output). Additionally or alternatively, an outsourced transaction (e.g., the output of an outsourced transaction) may be locked to coordinator 301's public key. This may be used, for example, to allow coordinator 301 to recover any digital assets locked by the outsourced transaction if user 103 fails to provide results for a secondary computation (detailed below).

[0033] Each outsourcing transaction may include at least a hash of the corresponding quadratic computation.

[0034] In some examples, instead of creating a separate outsourcing transaction for each quadratic computation, a given outsourcing transaction may contain multiple outputs, each locked to a different verification output of a verification algorithm used to generate a different quadratic computation.

[0035] Coordinator 301 submits the outsourcing transaction to the blockchain network 106. Additionally or alternatively, the outsourcing transaction may be sent to one or more users 103, for example, an outsourcing transaction locked to a user's public key may be sent to that user 103. For example, as shown in Figure 3, one outsourcing transaction is sent to Alice 103a and another outsourcing transaction is sent to Bob 103b.

[0036] Coordinator 301 also sends secondary computations to one or more users 103. In some examples, a given secondary computation is sent only to user 103 whose public key is used to lock the outsourcing transaction associated with that secondary computation. The secondary computation may be sent in an encrypted form. For example, any suitable encryption method may be used with the user's public key or a dedicated encryption key. In some examples, instead of sending the secondary computation directly to user 103, coordinator 103 may include in the associated outsourcing transaction a link or reference to a storage location where the secondary computation is stored, such as cloud storage.

[0037] Next, we move to the perspective of user 103, configured to perform the outsourced computation. The user, for example, Alice 103a, obtains the first quadratic computation. It should be noted that "first," etc., are used simply as labels, and therefore "first quadratic computation" does not necessarily mean the initial quadratic computation to be created or distributed, or that it does not necessarily contain the initial part of the main computation. Alice 103a may obtain the first quadratic computation directly from coordinator 301. Alternatively, Alice 103a may obtain the first quadratic computation from a storage location, for example, cloud storage, using a link or reference to the storage location. The link or reference may be included in the first outsourcing transaction. The first outsourcing transaction may include a hash of the first quadratic computation. Alice 103a may hash the obtained first quadratic computation and compare it to the hash found in the first outsourcing transaction. Alice 103a first obtains the encrypted version of the first quadratic computation, and then, using the decryption key, can reveal the first quadratic computation. Similarly, Alice 103a obtains the first input to the first quadratic computation, i.e., the input that is input to the component part of the main computation on which the first quadratic computation is based. Alice 103a obtains the first outsourced transaction from blockchain 510 itself or from coordinator 301.

[0038] Using the first input, Alice 103a performs a first quadratic computation. As described above, this produces two outputs: a partial output of the main computation ("Result") and an output of the verification algorithm ("First Verification Output"). Alice 103a generates a first result transaction that references the first outsourcing transaction. The first result transaction includes an "unlock value" based on the first verification output. The unlock value may be the first verification output itself, or at least a hash of the first verification output, depending on the form of the lock value of the first outsourcing transaction. If necessary, Alice 103a signs the first outsourcing transaction. Alice 103a then sends the first result transaction to blockchain 150 and / or coordinator 301.

[0039] Alice 103a sends the result to Coordinator 301. Alternatively, Alice 103a may include a link or reference to the result within the first result transaction. Alice 103a may first encrypt the result.

[0040] Alice 103a can perform similar actions for multiple quadratic calculations. Bob 103a can also perform similar actions for one or more quadratic calculations.

[0041] The coordinator 301 retrieves multiple results, for example, directly from user 103 or from a link provided in the result transaction. The coordinator 301 may send the multiple results to the outsourcer 302, or it may generate a combined result based on the multiple results and send the combined result to the outsourcer 302. In some examples, an identifier associated with each quadratic calculation is used to generate an overall result based on the multiple results.

[0042] 1.1 Outsourcing Calculation This section describes an exemplary protocol that implements the embodiments described above. Continuing the previous example, this protocol has three main actors: an outsourcer (Olivia) 302, a recognized central service (ReCeS) 301, and a computing party (Ulysses) 103.

[0043] Transactions can be used to perform computations, but in some cases, this can be inefficient and costly. Instead, to ensure data integrity, transactions can be created that include a link to the computation to be outsourced and a cryptographic hash of its contents. These transactions are referred to as outsourced transactions.

[0044] Validation scripts are computationally lightweight features added to outsourced calculations. The exemplary validation scripts described in this section are computed deterministically using a seed agreed upon between Olivia and ReCeS.

[0045] P U K=H is the public key of Ulysses, PR is the public key of ReCeS, VO is the output of the verification script, f is a known function, H is the cryptographic hash function, K=H 2 (f(P U ,V O )) and H 2 This means that a double hash is applied. Below is an example of a verification script written in Script SV (OP_ is omitted initially). 1 <P U > <P R >2 CHECKMULTISIGVERIFY SHA256 <k>EQUAL。

[0046] The unlocking script is H(f(P U ,V O )) and is a signature generated using the private key corresponding to P U . Additional data D (such as the hash of the input) can be added by appending OP_RETURN < D > at the end of the script.

[0047] The outsourcing transaction is sent from ReCeS to its registered user. Ulysses has the verification output necessary to use the transaction when he completes the calculation. If he disconnects before finishing the calculation or does not provide an answer, ReCeS can cancel the transaction and rebroadcast the calculation.

[0048] The verification script should preferably be computationally lightweight, depend on the input of the calculation, and ensure that the verification output has a certain degree of randomness. Let H1 and H2 be two different cryptographic hash functions, and S be the seed of a pseudo-random number generator (PRNG).

[0049] 1. Use the RNG to generate a random positive integer n. Let H ← H1. 2. Use the RNG to select a random input i and a random integer a. V O = H(H(i)+H(a)). 3. If n is odd, update H (if H is H1, set this to H2, or if H is H2, set this to H1), and use the RNG to select a random input j and a random integer b. Let V = H(H(j)+H(b)). Let r be the remainder when n is divided by 4. a. If r = 0, V O ← H1(V O ) b. If r = 1, V O ← V O XOR V c. If r = 1, V O ←H2(V O ) If dr=3, V O ←NOT(V O XOR V) 4.

number

[0050] Providing the source code of a computation exposes ReCeS to a malicious party that could extract only the verification script but still unlock the transaction. Conversely, providing an executable file exposes Ulysses to malicious attacks and unintended denial of service. To address these issues, ReCeS may provide a domain-specific programming language that can describe a wide range of computations but is sufficiently restricted to ensure that no malicious or dangerous code can be injected. ReCeS sends the executable file to Ulysses within the outsourcing transaction.

[0051] Encrypting the inputs that Ulysses receives is convenient and often necessary (for example, when dealing with sensitive data). Data decryption can be performed by an executable file.

[0052] To prevent Ulysses from sharing the manipulated results or eavesdroppers from manipulating them, the output data may be encrypted before being sent to ReCeS. To verify the calculations, ReCeS may decrypt the data and check that the verified output is consistent.

[0053] The high-level description of the source code used to generate the executable file is as follows: 1. Load the necessary inputs and seeds into the verification script and decrypt them. 2. Execute the necessary calculation and verification scripts to generate outputs O1 and O2, respectively. 3. Encrypt the total output O=(O1,O2) and share it with ReCeS. 4. Show the verification output in plain text format to Ulysses.

[0054] Once the calculation is complete, ReCeS may check that the encrypted verification code corresponds to the unencrypted one, and therefore the data has not been manipulated. At this point, it may send a reward transaction to Ulysses. The reward transaction may be a standard P2PKH transaction to a Ulysses address that has a reference to the calculation being referenced.

[0055] Therefore, the total reward Ulysses receives is split between two different transactions, and he can only receive the full reward if both parties agree to perform the calculation correctly. Splitting the total reward into two transactions partially protects all parties from financial loss in the event of an attack; that is, if Ulysses is acting in good faith and a third party manipulates the results, he will still receive a partial reward, and if the calculation is incorrect, ReCeS will not create a reward transaction.

[0056] 1.2 Training artificial intelligence using UTXO-based blockchain This section describes an exemplary outsourcing protocol that uses the embodiments described above to train a neural network. Training paradigms such as DL and FL, which already assume fragmentation during the training phase, are particularly well-suited to this protocol.

[0057] 1. Olivia describes the NN architecture and training algorithm using a domain-specific language provided by ReCeS. 2. Olivia sends the source code, training set, secret seed S, and encryption key E to ReCeS. 3. ReCeS uses its task parallelization protocol to unpack computations into smaller parts. 4. ReCeS assigns a sequential identification number C to each of the smaller transactions. i and total reward T i Assign T i This is split into two values: one is used for outsourcing transactions and the other for reward transactions. 5. ReCeS is transaction C i The seed used to create the verification script is H(S+C i Set to ), where H is the cryptographic hash function. 6. ReCeS encrypts the transaction inputs and generates source code. Then it compiles and obfuscates them. 7. ReCeS creates a Proof of Existence (PoE) for encrypted inputs and executable files. 8. ReCeS distributes computations to Ulysses using outsourced transactions. 9. Ulysses checks the executable file and the provided input to ensure data integrity. 10. Ulysses executes the executable file. The calculation results and verification outputs are encrypted and shared with ReCeS. The verification output is sent to Ulysses. 11. Ulysses spends on outsourced transactions. 12. ReCeS verifies the correctness of the results by decrypting what Ulysses shared and checking that the verification output is consistent. 13. If verification is successful, ReCeS sends the reward transaction to Ulysses. 14. When Ulysses disconnects from the service, ReCeS will spend its outsourcing transaction. 15. Once the model is trained, ReCeS sends it to Olivia.

[0058] The following provides further details about the protocol described. 1. Universities are encouraged to support services like ReCeS for economic reasons. Idle machines on campus can be used instead of dedicated hardware. Users can pay with tokens. 2. In Step 2, Olivia could aim to reduce the economic costs of computation time or outsourcing. She could pay for this service by relying on the token economy provided by ReCeS. 3. The PoE of data used by ReCeS to distribute computations may be stored on the chain so that Ulysses can verify that it is running the correct program with the correct inputs. 4. All information provided in the outsourced transaction link may be deleted after the computation is complete. To ensure that the computation can be reconstructed, it is sufficient to have the ReCeS version Olivia interacted with, the data she shared with it, and all transactions on the chain. This makes it possible to audit the NN. The data may be combined in a Merkle tree structure to allow selective disclosure. 5. Additional partial information, such as training steps, can be stored in the PoE. This can help researchers and institutions investigate specific behaviors. 6. This protocol is particularly well-suited to FL. It can be modified to allow training models on local data provided by Ulysses. To do this, Ulysses must first store the data's Proof of Enforcement (PoE) and then share it with ReCeS so that validation outputs and outsourced transactions can be computed. 7. The outsourced transaction locking script is linked to the Ulysses address, so a replay attack is not possible. 8. Having a trustworthy institution behind ReCeS eliminates the risk of transaction malleability.

[0059] 1.3 Advantages of distributed learning using blockchain This section will explain some of the advantages of using blockchain to outsource computations, for example, to train AI.

[0060] 1.3.1 Decentralization and Privacy The advantages of training AI on a blockchain are its inherent decentralization and privacy. Blockchain allows existing DL and FL models to integrate local training data while maintaining user privacy and data confidentiality. Despite all this, it is still possible to audit the data at a later stage, preventing data poisoning by holding users accountable for the data they provide.

[0061] 1.3.2 Data Integrity Users willing to lend computing power need to be able to autonomously verify that the data they are using is not corrupted. Checking for data Proof of Entitlement (PoE) is an easy way to achieve this.

[0062] 1.3.3 Selective Disclosure Selective disclosure of sensitive data can be achieved via Proof of Entitlement (PoE). A simple way to do this is to store PoEs for all different clearance levels on the blockchain, but this can be a slow process (especially for large amounts of data). A better approach is to use a Merkle tree, because this relies on Merkle proofs to guarantee data integrity and requires the data to be stored only once.

[0063] 1.3.4 Auditing Capabilities Data integrity and selective disclosure are fundamental blocks that make blockchain a natural framework for AI auditing capabilities. The outsourcing protocols described herein store information regarding parameter initialization and training sets on the blockchain. Additional information requested by the auditing party may be stored as needed. All intermediate training steps can be stored on the blockchain as transactions. If a party provides training data, a Proof of Enforcement (PoE) may be required so that the data integrity can be verified before the service uses the data. All this information can be stored on the blockchain by storing only the root of the Merkle tree. Internal and external audits require only the original data and their Merkle proofs to guarantee data integrity. Not only AI training, but also execution can be handled via microtransactions. These microtransactions create a stream of trusted information about AI usage that can be used to develop appropriate legal coverage for businesses and individuals.

[0064] 2. Overview of the Exemplary System A blockchain is a form of decentralized data structure in which copies of the blockchain are maintained and widely shared on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points back to a preceding transaction in a sequence that may span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be explained further below. Transactions submitted to the blockchain network are included in a new block. A new block is created by a process often referred to as "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, pending transaction waiting to be included in a new block of the blockchain. It should be noted that a blockchain may be pruned on some nodes, and the publication of a block can be achieved simply by publishing the block header.

[0065] Transactions within a blockchain can be used for one or more of the following purposes: carrying digital assets (i.e., several digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or chronologically arranging index pointers. Blockchains can also be used to layer additional functionality on top of them. For example, a blockchain protocol can enable the storage of additional user data or indices for data within a transaction. There is no predetermined limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data within a blockchain.

[0066] In the “output-based” model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Each consumable output includes an element specifying the amount of digital asset that can be derived from the transaction's progression sequence. Consumable outputs are sometimes referred to as UTXOs (“unspent transaction outputs”). Outputs may further include a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction, and may further include an unlocking script to unlock the locking script of the pointed output. Thus, we consider a pair of transactions, which we will call the first and second transactions (or “target” transactions). The first transaction includes at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input containing a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0067] In such a model, when a second target transaction is sent to the blockchain network and propagated and recorded on the blockchain, one of the validity criteria applied at each node is that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by any other previous valid transaction. A node that finds a target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) and will not include it in a new block recorded on the blockchain.

[0068] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring to the UTXO of a preceding transaction in a sequence of past transactions, but rather by referring to the absolute account balance. The current state of all accounts is stored and constantly updated by a node separate from the blockchain.

[0069] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may include a packet-switched network 101, a wide-area internetwork, typically the internet. The packet-switched network 101 includes multiple blockchain nodes 104 (often referred to as "miners") which can be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0070] Each blockchain node 104 includes the computer equipment of its peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes processing equipment, including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. Memory may include one or more memory units using one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives.

[0071] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within a decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 may be pruned, as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0072] A blockchain node 104 may be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. A blockchain node 104 may be configured to create block 151 and store each copy of the same blockchain 150 in its own memory. A blockchain node 104 may also maintain an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool.” This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as valid, which obligates the node 104 not to accept other transactions attempting to use the same output.

[0073] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output will be redeemed or “spended” in the current transaction 152j. Spending or redeeming does not necessarily mean the transfer of a financial asset, but it is certainly one general application. More generally, spending can be described as consuming the output, or allocating it to one or more outputs in other subsequent transactions. Generally, a preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Therefore, "preceding" as used herein refers not necessarily to the time of creation or transmission in a temporal sequence, but to the preceding in a logical sequence linked by pointers, and thus does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted out of order (see the following explanation of orphan transactions). Preceding transaction 152i may also be referred to as the preceding or preceding transaction.

[0074] Due to the resources involved in transaction validation and publication, each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0075] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and process transaction 152, in accordance with the blockchain node protocol. It will be understood herein that any action attributable to the blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or at lower layers such as the operating system layer or protocol layer, or any combination thereof.

[0076] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104; that is, a node may specialize in a particular operation. For example, node 104 may focus on transaction validation and propagation, or on block mining. In some examples, blockchain node 104 may perform two or more of these operations in parallel. Any reference to blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0077] Network 101 is also connected to the computer devices 102 of several parties 103, each acting as a consuming user. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may function as senders and receivers in transactions. Other users may interact with blockchain 150 without necessarily functioning as senders or receivers. For example, some parties may function as storage entities that store copies of blockchain 150 (e.g., retrieving copies of the blockchain from blockchain node 104).

[0078] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as “clients”) are sometimes said to be part of the system, including the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the necessary roles for blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. For illustrative purposes, two parties 103 and their respective devices 102 are shown, namely, the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b. It should be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to herein as Alice, and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob herein may be replaced with “the first party” and “the second party,” respectively.

[0079] Each party 103's computer equipment 102 includes one or more processors, each processing unit including, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer equipment 102 further includes memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. This memory may include one or more memory units using one or more memory media, for example, magnetic media such as hard disks, SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer equipment 102 stores software including each instance of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed to party 103 as given herein may be performed using software running on the processing unit of each computer equipment 102. Each party 103's computer equipment 102 includes at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of the given party 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0080] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example, by being downloaded from a server or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0081] The client application 105 includes at least a “wallet” function, which has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign), send a transaction 152 to one or more Bitcoin nodes 104, and then propagate it throughout the network of blockchain nodes 104, thereby enabling it to be included in blockchain 150. The other is to report to each party the amount of digital assets he or she currently owns. In an output-based system, this second function includes matching the amounts defined in the outputs of various 152 transactions belonging to the party in question, distributed throughout blockchain 150.

[0082] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily an limitation. Instead, it should be noted that any client function described herein may instead be implemented in a set of two or more separate applications that interface via an API, for example, or one of which is a plug-in to the other. More generally, client functions may be implemented in the application layer, or in a lower layer such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not an limitation.

[0083] Each instance of a client application or software 105 on each computer device 102 is operablely coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for any transaction in which each party 103 is the recipient (or, in an embodiment, actually inspect the transactions of other parties within blockchain 150, as blockchain 150 is a public facility that provides trust in transactions, partly through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and forward transaction 152 to propagate it throughout the blockchain network 106. The transaction protocol and node protocol correspond to each other, and a given transaction protocol proceeds together with a given node protocol, jointly implementing a given transaction model. The same transaction protocol is used for all 152 transactions within the blockchain 150. The same node protocol is used by all 104 nodes within the network 106.

[0084] An alternative type of transaction protocol, operated by several blockchain networks, may be referred to as an “account-based” protocol as part of an account-based transaction model. In the account-based model, each transaction is defined not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored separately from the blockchain and constantly updated by the nodes of that network. In such a system, transactions are ordered using the account’s running transaction tally (also called a “position” or “nonce”). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an arbitrary data field may also be signed in the transaction. This data field may, for example, point back to a previous transaction if the previous transaction ID is included in the data field.

[0085] Several account-based transaction models share some similarities with the output-based transaction models described herein. For example, as mentioned above, the data fields of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction that references the output point of the previous transaction. Thus, both models allow for linking between transactions. As another example, an account-based transaction includes a “Recipient” field (where the receiving address of the account is specified) and a “Value” field (where the amount of the digital asset may be specified). Together, the recipient and value fields are equivalent to the output of an output-based transaction that can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction has a “Signature” field that contains the signature of the transaction. The signature is generated using the sender’s private key and confirms that the sender authorized this transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically contains the signature of the transaction. Once both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a “smart contact” refers to a transaction containing a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) that satisfy one or more conditions defined by the smart contact’s script. A smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by subsequent transactions.Therefore, in some cases, a smart contract can be considered equivalent to a locking script for an output-based transaction that can be triggered by a subsequent transaction, checking whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0086] 3. UTXO-based models Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it may be equally implemented on other exemplary blockchain networks.

[0087] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may have an unused transaction output (UTXO), which may be used as a source for the inputs 202 of other new transactions (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents the number of tokens set on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction in which it originated. The transaction data structure may also include a header 201 which may contain an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0088] Suppose Alice 103a wants to create transaction 103j to transfer the amount of the target digital asset to Bob 152b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., preceding) transaction that still has the unused output 203 locked in Alice.

[0089] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence defined by transaction pointers specified within a transaction (such as which transaction points to which other transaction). They can be replaced with “preceding” and “successor,” or “preceding” and “successor,” “parent” and “child,” etc. It does not necessarily mean the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a successor transaction (successor transaction or “child”) that points to a preceding transaction (preceding transaction or “parent”) will not be validated until the parent transaction is validated, and unless validated. A child that arrives at blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain period of time to wait for its parent, depending on the node protocol and / or node behavior.

[0090] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, here labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a locking script defining the conditions that must be met by the unlocking script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed.

[0091] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is referred to as “script” (uppercase S) used by blockchain networks. The locking script specifies what information is needed to use transaction output 203, for example, the request for Alice's signature. The locking script appears in the transaction output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information necessary to satisfy the locking script criteria. For example, it might include Bob's signature. The unlocking script appears in the transaction input 202.

[0092] Therefore, in the illustrated example, UTXO0 in output 203 of Tx0 is signed by Alice Sig P for UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem UTXO0 to be valid). A Locking script that requires [Checksig P A ] includes. [Checksig P A ] is the public key P from Alice's public-private key pair. A The input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer to Tx1 (for example, by its transaction ID, TxID0, which in this embodiment is a hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 and identifies it from other possible outputs of Tx0. The input 202 of Tx1 includes an unlocking script, which contains Alice's cryptographic signature, created by Alice, applying her private key from a key pair to a given portion of the data (sometimes referred to as a "message" in cryptography). <Sig P A >Furthermore, the data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, by the node protocol, or a combination thereof.

[0093] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves executing the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (these conditions may include one or more criteria).

[0094] It should be noted that script code is often expressed in a general way (i.e., without using precise language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates a transaction-unusable output that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may include documents that are desired to be stored on the blockchain.

[0095] Typically, the input to a transaction is the public key P A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the output it signs depend on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature (and thus fixed at signing) to select which outputs are signed.

[0096] A locking script is sometimes called a "scriptPubKey," which typically refers to the fact that each transaction contains the public key of the counterparty to which it is locked. An unlocking script is sometimes called a "scriptSig," which typically refers to the fact that it supplies the corresponding signature. However, more generally, it is not required in all blockchain applications that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0097] 4. Side Channels As shown in Figure 1, each client application of Alice and Bob's computer devices 102a and 120b may include further communication capabilities. This further capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either the parties or a third party). The side channel 107 enables the exchange of data separately from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this could be used to exchange transaction 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing to chain 150 until one of the parties chooses to broadcast the transaction to network 106. Sharing a transaction in this way is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively, or further, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0098] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively, or further, side channel 301 may be established via a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even via a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, side channel 107 as referred to anywhere in this specification may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., independently of the blockchain network 106. If two or more links are used, the bundle or collection of off-chain links may be referred to as side channel 107 as a whole. Therefore, when it is said that Alice and Bob exchange certain information or data etc. via side channel 107, it should be noted that this does not necessarily mean that all of this data must be transmitted via exactly the same link or the same type of network.

[0099] 5. Further Notes Other variations or use cases of the disclosed technology may become apparent to those skilled in the art once the disclosure herein is given. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0100] For example, some of the embodiments described above have been explained in relation to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104. However, it will be understood that Bitcoin Blockchain is one specific example of Blockchain 150, and the above description may be applied in general to any blockchain. That is, the present invention is by no means limited to Bitcoin Blockchain. More generally, any above reference to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104 may be replaced with reference to Blockchain Network 106, Blockchain 150, and Blockchain Node 104, respectively. Blockchains, Blockchain Networks, or Blockchain Nodes, or any combination thereof, may share some or all of the described characteristics of Bitcoin Blockchain 150, Bitcoin Network 106, and Bitcoin Node 104, as described above.

[0101] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, issuing, propagating, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (it should be noted that these entities are not considered nodes of the preferred Bitcoin network 106).

[0102] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more of the functions of creating, issuing, propagating, and storing blocks 151 of blockchain 150, but not all of them. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and issue blocks 151 but not to store and / or propagate those blocks 151 to other nodes.

[0103] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0104] Several embodiments have been described in relation to blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any suitable consensus mechanism of any type, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time, may be used. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often referred to as a validator. Blockchain nodes can lock their tokens for a certain period of time in order to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0105] It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided by any one or more of the following appendices.

[0106] [Note 1] A computer implementation method for outsourcing calculations using blockchain, wherein the method is performed by the coordinating parties, Obtaining one or more quadratic calculations, each of which is performed using its respective inputs based on its respective parts of the primary calculation and its respective verification algorithm, thereby generating and obtaining the respective results of the respective parts of the primary calculation and the respective verification outputs of the respective verification algorithms. Obtaining each of the multiple inputs to the aforementioned first-order calculation, For each quadratic calculation, Each outsourcing transaction is generated, and each outsourcing transaction is locked to its respective lock value based on its respective verification output. To make each of the aforementioned outsourcing transactions available to the respective computing parties, Making both the respective secondary calculation or its encrypted version, and the respective input or its encrypted version, available to the respective computing parties, A method that includes this.

[0107] [Note 2] The method according to Appendix 1, wherein making each of the aforementioned outsourcing transactions available to each of the aforementioned computing parties includes transmitting each of the aforementioned outsourcing transactions to one or more blockchain nodes of the blockchain network.

[0108] [Note 3] Making each of the secondary calculations or their encrypted versions, and each of the inputs or their encrypted versions, available to each of the calculation parties is the method of Appendix 1 or Appendix 2, which includes including a link or reference to each of the secondary calculations or their encrypted versions, and each of the inputs or their encrypted versions, in each of the outsourcing transactions.

[0109] [Note 4] The method according to any one of the appendices 1 to 3, comprising making available to each of the computational parties the decryption keys for each of the aforementioned secondary computations and / or each of the aforementioned inputs.

[0110] [Note 5] Each of the aforementioned outsourcing transactions includes at least the hash of the secondary calculation, as described in any one of the methods described in Appendix 1 to 4.

[0111] [Note 6] Each of the aforementioned outsourcing transactions is locked to the respective public keys of the respective computing parties, according to any one of the methods described in Appendix 5.

[0112] [Note 7] Each of the aforementioned lock values ​​is determined by the method described in any one of the appendices 1 to 6, based on at least the hash of each of the aforementioned verification outputs.

[0113] [Note 8] Each of the aforementioned lock values ​​is determined by the method described in Appendix 6 or Appendix 7, based on at least the respective verification output and the hash of the respective public key.

[0114] [Note 9] The method according to any one of the appendices 1 to 8, wherein each of the aforementioned outsourcing transactions is configured to be unlocked by the coordinating party.

[0115] [Note 10] The method described above is the method according to any one of the appendices 1 to 9, which includes obtaining the primary calculation from the outsourcing party.

[0116] [Note 11] The method described in Appendix 10, wherein obtaining each of the aforementioned inputs includes receiving each of the aforementioned inputs from the outsourcing party.

[0117] [Note 12] The method according to Appendix 10 or Appendix 11, wherein receiving the primary calculation includes receiving the source code of the primary calculation.

[0118] [Note 13] Obtain the result of each of the quadratic calculations, Based on the respective results of each of the quadratic calculations, an overall result of the aforementioned primary calculation is generated. The method described in any one of the appendices 1 to 12, including the method described in appendices 1 to 12.

[0119] [Note 14] The method of Appendix 13, wherein obtaining the respective results of each of the quadratic calculations, or their encrypted versions thereof, includes receiving the respective results, or their encrypted versions thereof, from the respective calculation parties.

[0120] [Note 15] The method according to Appendix 13 or Appendix 14, wherein for each outsourcing transaction, the blockchain includes a result transaction, each result transaction includes the result, or its encrypted version, or a link or reference thereof, and obtaining the result of each quadratic calculation includes obtaining the result, or its encrypted version thereof, from the result transaction or the link or reference.

[0121] [Note 16] The method according to any one of the appendices 13 to 15, comprising making the overall result of the aforementioned primary calculation available to the outsourcing party.

[0122] [Note 17] The method comprising assigning each identifier to its respective quadratic calculation, wherein each verification output is based on the respective identifier and is determined by any one of the methods described in Appendix 1 to 16.

[0123] [Note 18] The method according to Appendix 17, wherein each of the identifiers is used to generate the overall result of the primary calculation based on the respective results of the respective secondary calculations.

[0124] [Note 19] The method according to any one of the appendices 1 to 18, wherein obtaining the one or more of the aforementioned secondary calculations includes splitting the primary calculation into the one or more of the aforementioned parts.

[0125] [Note 20] The aforementioned first-order calculation is the method described in any one of the appendices 1 to 19, including a neural network.

[0126] [Note 21] The method described in Appendix 20, wherein the input is training data for the neural network.

[0127] [Note 22] A computer implementation method for performing outsourced computations using blockchain, wherein the method is performed by a first computational party, The process involves obtaining a first quadratic calculation, wherein the first quadratic calculation includes a primary calculation or a first part of the primary calculation and a first verification algorithm. Obtaining the first input to the aforementioned primary calculation, The process involves obtaining a first outsourcing transaction, wherein the first outsourcing transaction is locked with a first lock value based on a first verification output obtainable by inputting the first input into the first verification algorithm. The process involves performing a first quadratic calculation using the first input, wherein the execution generates a first result based on the first quadratic calculation or the first part of the first quadratic calculation and the first verification output. Making the aforementioned first result, or its encrypted version, available to the coordinating parties, To generate a first result transaction, wherein the first result transaction references the first outsourcing transaction and includes an unlock value based on the first verification output. Making the aforementioned first result transaction available to one or more nodes in the blockchain network, Methods that include...

[0128] [Note 23] Making the first result available to the coordinating party is the method described in Appendix 22, which includes including the first result, or a link or reference to the first result, or an encrypted version thereof, in each of the outsourcing transactions.

[0129] [Note 24] The method according to Appendix 22 or Appendix 23, wherein obtaining the first outsourcing transaction includes obtaining the first outsourcing transaction from the coordinating party or from the blockchain.

[0130] [Note 25] The first outsourcing transaction includes a link to or reference to the first secondary computation, or an encrypted version thereof, and / or a link to or reference to the first input, or an encrypted version thereof. Obtaining the aforementioned first quadratic calculation or its encrypted version includes using the aforementioned link or reference to obtain the aforementioned first quadratic calculation or its encrypted version, and / or Obtaining the first input or its encrypted version includes obtaining the first input or its encrypted version using the link or reference. The method described in Appendix 22 or Appendix 23.

[0131] The method may include obtaining one or more decryption keys from the coordinating party and decrypting the first quadratic calculation and / or the input using the one or more decryption keys. The method may also include obtaining an encryption key from the coordinating party and encrypting the first result using the encryption key. This may include making available to each of the parties to the computation the decryption key for each of the aforementioned secondary computations and / or each of the aforementioned inputs.

[0132] [Note 26] The method according to any one of the appendices 22 to 25, wherein the first outsourcing transaction is locked to the first public key of the first computing party, and the first resulting transaction includes a signature generated using the private key corresponding to the first public key.

[0133] [Note 27] Computer equipment, Memory including one or more memory units, A processing apparatus comprising one or more processing units, wherein the memory stores code configured to be executed on the processing apparatus, and the code, when on the processing apparatus, is configured to perform the method described in any one of the items 1 to 26, Computer equipment including...

[0134] [Note 28] A computer program, which is embodied on computer-readable storage and, when executed on one or more processors, is configured to perform the actions described in any one of the items in Appendix 1 to 16.

[0135] Another embodiment disclosed herein may provide a method including actions of the coordinating party and the outsourcing party. Another embodiment disclosed herein may provide a system including computer equipment of the coordinating party and the outsourcing party.< / k>

Claims

1. A computer implementation method for outsourcing calculations using blockchain, wherein the method is performed by the coordinating parties, Obtaining one or more quadratic calculations, each of which is performed using its respective inputs based on its respective parts of the primary calculation and its respective verification algorithm, thereby generating and obtaining the respective results of the respective parts of the primary calculation and the respective verification outputs of the respective verification algorithms. Obtaining each of the multiple inputs to the aforementioned first-order calculation, For each quadratic calculation, Each outsourcing transaction is generated, and each outsourcing transaction is locked to its respective lock value based on its respective verification output. To make each of the aforementioned outsourcing transactions available to the respective computing parties, Making both the respective secondary calculation or its encrypted version, and the respective input or its encrypted version, available to the respective computing parties, A method that includes this.

2. The method according to claim 1, wherein making each of the outsourcing transactions available to each of the computing parties comprises transmitting each of the outsourcing transactions to one or more blockchain nodes of the blockchain network.

3. The method according to claim 1, wherein making each of the secondary calculations or their encrypted versions, and each of the inputs or their encrypted versions, available to each of the calculation parties includes including a link or reference to each of the secondary calculations or their encrypted versions, and each of the inputs or their encrypted versions, in each of the outsourcing transactions.

4. The method according to claim 1, comprising making available to each of the computational parties a decryption key for decrypting each of the aforementioned secondary computations and / or each of the aforementioned inputs.

5. The method according to claim 1, wherein each of the outsourcing transactions includes at least the hash of the secondary calculation.

6. The method according to claim 1, wherein each of the outsourcing transactions is locked to the respective public keys of the respective computing parties.

7. The method according to claim 1, wherein each of the aforementioned lock values ​​is based on at least the hash of each of the aforementioned verification outputs.

8. The method according to claim 6, wherein each of the lock values ​​is based on at least the respective verification output and the hash of the respective public key.

9. The method according to claim 1, wherein each of the aforementioned outsourcing transactions is configured to be unlocked by the coordinating party.

10. The method according to claim 1, further comprising obtaining the primary calculation from the outsourcing party.

11. The method according to claim 10, wherein obtaining each of the aforementioned inputs includes receiving each of the aforementioned inputs from the outsourcing party.

12. The method according to claim 10, wherein receiving the primary calculation includes receiving the source code of the primary calculation.

13. Obtain the result of each of the quadratic calculations, Based on the respective results of each of the quadratic calculations, an overall result of the aforementioned primary calculation is generated. The method according to claim 1, including the method described in claim 1.

14. The method of claim 13, wherein obtaining the respective result of each of the quadratic calculations, or the encrypted version thereof, includes receiving the respective result, or the encrypted version thereof, from the respective calculation party.

15. The method according to claim 13, wherein for each outsourcing transaction, the blockchain includes a result transaction, each result transaction includes the result, or its encrypted version, or a link or reference thereof, and obtaining the result of each quadratic calculation includes obtaining the result, or its encrypted version thereof, from the result transaction or the link or reference.

16. The method according to claim 13, comprising making the overall result of the primary calculation available to the outsourcing party.

17. The method according to claim 1, comprising assigning each identifier to each quadratic calculation, wherein each verification output is based on each identifier.

18. The method according to claim 13, comprising assigning each identifier to each secondary calculation, wherein each verification output is based on the respective identifier, and the respective identifier is used to generate the overall result of the primary calculation based on the respective results of the respective secondary calculation.

19. The method according to claim 1, wherein obtaining each of the one or more quadratic calculations includes splitting the primary calculation into each of the one or more parts.

20. The method according to claim 1, wherein the aforementioned first-order calculation includes a neural network.

21. The method according to claim 20, wherein the input is training data for the neural network.

22. A computer implementation method for performing outsourced calculations using blockchain, wherein the method is performed by a first computing party, The means of obtaining a first quadratic calculation, wherein the first quadratic calculation includes a primary calculation or a first part of the primary calculation and a first verification algorithm. To obtain the first input to the aforementioned primary calculation, The first outsourcing transaction is obtained, wherein the first outsourcing transaction is locked with a first lock value based on a first verification output obtainable by inputting the first input to the first verification algorithm. The process involves performing a first quadratic calculation using the first input, wherein the execution generates a first result based on the first quadratic calculation or the first part of the first quadratic calculation and the first verification output. Making the aforementioned first result, or its encrypted version, available to the coordinating parties, To generate a first result transaction, wherein the first result transaction refers to the first outsourcing transaction and includes an unlock value based on the first verification output. Making the aforementioned first result transaction available to one or more nodes in the blockchain network, Methods that include...

23. The method according to claim 22, wherein making the first result available to the coordinating party includes including the first result, or a link or reference to the first result, or an encrypted version thereof, in each of the outsourcing transactions.

24. The method according to claim 22, wherein obtaining the first outsourcing transaction includes obtaining the first outsourcing transaction from the coordinating party or from the blockchain.

25. The first outsourcing transaction includes a link to or reference to the first secondary calculation, or an encrypted version thereof, and / or a link to or reference to the first input, or an encrypted version thereof. Obtaining the first quadratic calculation or its encrypted version includes using the link or reference to obtain the first quadratic calculation or its encrypted version, and / or Obtaining the first input or its encrypted version includes obtaining the first input or its encrypted version using the link or reference. The method according to claim 22.

26. The method according to claim 22, wherein the first outsourcing transaction is locked to the first public key of the first computing party, and the first resulting transaction includes a signature generated using the private key corresponding to the first public key.

27. Computer equipment, A memory containing one or more memory units, A processing apparatus comprising one or more processing units, wherein the memory stores code configured to be executed on the processing apparatus, and the code, when on the processing apparatus, is configured to perform the method described in any one of claims 1 to 21, Computer equipment including...

28. A computer program that is implemented on computer-readable storage and, when executed on one or more processors, is configured to perform the method according to any one of claims 1 to 21.

29. Computer equipment, A memory containing one or more memory units, A processing apparatus comprising one or more processing units, wherein the memory stores code configured to be executed on the processing apparatus, and the code is configured to perform the method described in any one of claims 22 to 26 when it is on the processing apparatus, Computer equipment, including...

30. A computer program that is embodied on computer-readable storage and, when executed on one or more processors, is configured to perform the method according to any one of claims 22 to 26.

Images