Proof and verification of data storage

Abstract

A computer-implemented method for enabling verification of data storage, the method comprising: obtaining a plurality of data blocks, the plurality of data blocks together representing a data item to be stored by one or more respective second parties; for each respective second party, generating a respective hash root of a respective hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective set of data blocks is used to generate a respective leaf hash of the respective hash tree; and for each respective second party, submitting a respective request transaction to one or more blockchain nodes of a blockchain network, the respective request transaction being configured to require that a respective response transaction include a respective hash proof for a respective leaf hash of the respective hash tree.

Description

[Technical Field]

[0001] The present disclosure relates to methods for providing proof that data is stored and enabling verification that data is stored. [Background technology]

[0002] Broadly speaking, there are three types of storage: block storage, file storage, and object storage. Block storage stores sequences of binary bits or bytes. Block storage offers the best read / write speeds and is suitable for databases with transactional workloads. For cloud-based services, block storage usually comes with a virtual compute unit (server) attached to it. File storage operates on top of block storage; that is, block storage is abstracted by a file system. It is ideal for use cases such as large content repositories, development environments, media stores, or directories. Object storage is an alternative to file storage and operates on top of block storage, where data and metadata are stored together. It is ideal for modern applications that require scale and flexibility. It is also ideal for importing existing data stores for analytics, backup, or archiving.

[0003] A Redundant Array of Independent Disks (RAID) works by combining the space of multiple drives into a single logical drive, then scattering and / or replicating data across the array. There are several RAID configurations, each of which provides various levels of resilience (data retrievability in the event of a hard drive failure) and / or performance (read / write throughput).

[0004] Storage providers store data on behalf of clients, e.g., users or businesses. In scenarios where a client pays a storage provider to store a certain amount of data for a certain period of time, storage providers may be required to periodically provide proof that they still have the data so that they can continue to receive payment for storage services. Summary of the Invention [Means for solving the problem]

[0005] According to one aspect disclosed herein, a computer-implemented method for enabling verification of data storage is provided, the method being executed by a first party and comprising: obtaining a plurality of data blocks, the plurality of data blocks together representing a data item to be stored by one or more respective second parties; generating, for each respective second party, a respective hash root of a respective hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective set of data blocks is used to generate a respective leaf hash of the respective hash tree; and submitting, for each respective second party, a respective request transaction to one or more blockchain nodes of a blockchain network, the respective request transaction being configured to require that a respective response transaction comprise a respective hash proof for a respective leaf hash of the respective hash tree.

[0006] According to another aspect disclosed herein, a computer-implemented method for providing proof of data storage is provided, the method being executed by a second party and comprising: obtaining a plurality of data blocks, the plurality of data blocks collectively representing a data item stored by the second party; generating a hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective sets of data blocks is used to generate a respective leaf hash of the respective hash tree; obtaining a request transaction, the request transaction being a blockchain transaction configured to require that a response transaction comprise a respective hash proof for each leaf hash of the respective hash tree; generating the respective hash proofs; and submitting the response transaction to one or more blockchain nodes of a blockchain network, wherein the response transaction comprises the respective hash proofs.

[0007] This disclosure describes techniques for providing proof that a storage provider stores data and for verifying that a storage provider stores data. For each storage provider, a service provider (e.g., an oracle) generates a hash tree (e.g., a Merkle tree) based on the data. To verify that the storage provider stores the data, the service provider submits a request transaction to the blockchain network. The request transaction requires that a response transaction include hash proofs (e.g., Merkle proofs) for the leaves of the hash tree. If the storage provider stores the data, it can generate the hash proof and therefore generate a response transaction and submit it to the blockchain network. The storage provider may be challenged to provide proof that multiple copies of the data are stored.

[0008] The service provider may periodically challenge the storage provider. The challenge made by the service provider may take the form of a locking script that can be unlocked by the storage provider providing a hash proof in the unlocking script.

[0009] Data provided to a storage provider is mapped into a leaf node of a hash tree. The challenge may require the storage provider to provide a leaf node preimage and a hash proof. The leaf node may be a cryptographic hash of a data block where the memory proof includes the data block itself. The leaf node may also be a hash of an elliptic curve (EC) point generated from the data block, where the memory proof does not include the data block, but rather includes an EC signature generated from the data block.

[0010] Some embodiments of the present disclosure may be used to prevent storage providers from conspiring to provide false proof of storage of multiple copies of data while actually storing only a single copy. Embodiments enable proof of storage without having to reveal the actual data.

[0011] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded in a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of an exemplary system for storing data. [Figure 4] FIG. 10 is a sequence diagram for an exemplary process for requesting and providing a proof of memory. [Figure 5] FIG. 2 illustrates an exemplary flow for providing data to a storage provider. [Figure 6] FIG. 2 illustrates an exemplary flow for providing data to a storage provider. [Figure 7] FIG. 2 illustrates an exemplary flow for providing data to a storage provider. DETAILED DESCRIPTION OF THE INVENTION

[0013] 1. Data Storage Proof FIG. 3 illustrates an exemplary system 300 for implementing embodiments described herein. System 300 includes a first party ("service provider") 301, one or more second parties ("storage providers") 302, and a third party ("data provider") 303. In some examples, data provider 303 and service provider 301 may be the same entity. Each storage provider 302 is configured to store data, for example, in local memory or in cloud storage. Service provider 301 and each storage provider 302 may take the form of Alice 103a and / or Bob 103b, as described below with reference to FIGS. 1 and 2. That is, service provider 301 and each storage provider 302 may be configured to perform some or all of the actions described below as being performed by Alice 103a and / or Bob 103b.

[0014] From the perspective of service provider 301, service provider 301 obtains multiple data blocks. The data blocks represent data items to be stored by storage provider 302. Data provider 303 may send the data items and / or multiple data blocks to service provider 301, or service provider 301 may already have access to the data items and / or data blocks. The data items may comprise, for example, audio files, video files, documents, application files, etc.

[0015] Service provider 301 generates a respective Merkle tree for each storage provider 302 based on a respective set of data blocks. In some examples, the same set of data blocks is used to generate each Merkle tree. In this case, only one Merkle tree for each storage provider 302 may need to be generated. Alternatively, one or more respective Merkle trees may be generated based on different sets of data blocks. In some examples, each Merkle tree is generated based on a different set of data blocks.

[0016] Each data block of each set of data blocks is used to generate a respective leaf node (or leaf hash) of each Merkle tree. In some examples, each leaf node is generated by hashing the respective data block. Additional optional data, such as a random value, may be hashed along with the respective data block. In other examples, a respective public key is generated based on each respective data block, and each leaf node is generated by hashing the respective public key.

[0017] In some examples, each data block is encrypted to generate a respective encrypted data block. Some or all of the data blocks may be encrypted using the same encryption key or different encryption keys. In these examples, each respective Merkle tree is generated based on a respective set of encrypted data blocks. Each respective leaf node may be generated by hashing each respective encrypted data block. Alternatively, each respective leaf node may be generated by hashing a public key corresponding to each respective encrypted data block.

[0018] One or more leaf nodes of a given Merkle tree may be based on data other than data blocks, for example, a salt or an identifier mapped to a respective storage provider 302.

[0019] In some examples, some or all of the sets of data blocks include all of the plurality of data blocks. That is, the set of data blocks used to generate the Merkle tree may represent a complete data item. In some examples, some or all of the sets of data blocks do not include all of the plurality of data blocks. That is, the set of data blocks used to generate the Merkle tree may not represent a complete data item. For example, a data item may be divided into a sequence of data blocks, and each data block is assigned an index that indicates the data block's position within the sequence. A set of data blocks may include all data blocks with even indices or all data blocks with odd indices. As another illustrative example, a set of data blocks may include half of the plurality of data blocks, and a different set of data blocks may include the remaining data blocks.

[0020] As noted, service provider 301 generates a respective Merkle tree for each storage provider 302 based on the respective sets of data blocks. Each Merkle tree has a respective Merkle root. Service provider 301 also generates a respective request transaction for each storage provider 302. Each request transaction generated for a respective storage provider 302 is configured to require that a respective response transaction include a respective Merkle proof for a respective leaf node of the respective Merkle tree generated for that storage provider 302. That is, for a response transaction to successfully validate when executed together with a request transaction, the response transaction must include a Merkle proof for a particular leaf node of the Merkle tree. The request transaction may include the Merkle root of the Merkle tree.

[0021] As an example, a request transaction may include a locking script that enforces the requirement that a response transaction include a Merkle proof as part of the response transaction's unlocking script.

[0022] The response transaction may be required to include a preimage of the leaf node, e.g., a data block (or an encrypted data block) or a public key corresponding to the data block (or the encrypted data block). In some examples, the response transaction may be required to include a signature generated using the data block (or the encrypted data block).

[0023] Service provider 301 may send data items and / or blocks to storage provider 302. In some examples, service provider 301 may send only encrypted data items and / or encrypted data blocks to service provider 302. Service provider 301 may send each Merkle root of each Merkle tree to each storage provider 302.

[0024] Turning now to the perspective of storage provider 302, storage provider 302 obtains a plurality of data blocks representing a data item to be stored. The data blocks may be received from service provider 301, or the data item may be received based on which storage provider 302 generates the data blocks. Storage provider 302 generates a Merkle tree based on a set of data blocks from the plurality of data blocks in a similar manner that service provider 301 generates a corresponding Merkle tree for that storage provider 302. As described with respect to service provider 301, the Merkle tree may be generated based on encrypted data blocks, which may be received from service provider 301 or generated by storage provider 302.

[0025] The storage provider 302 obtains a request transaction, for example, from the service provider 301 or from the blockchain 150. As explained above, the request transaction requires that a Merkle proof be provided by a response transaction. The storage provider 302 generates a suitable Merkle proof. The Merkle proof comprises a sequence of hashes connecting a leaf node of the generated Merkle tree to the Merkle root of the Merkle tree. The storage provider 302 generates a response transaction including the Merkle proof and submits the response transaction to the blockchain network 106. The response transaction references the request transaction. The Merkle proof may be included in an unlocking script of the response transaction, where the unlocking script is included in an input that references the output of the request transaction. If necessary, the response transaction may also include a preimage of the leaf node for which the Merkle proof is provided and / or a signature generated using the data block on which the leaf node is based.

[0026] It should be noted that although the examples are described with respect to Merkle trees, any suitable type of hash tree may be used.

[0027] Further examples of the above-described embodiments are now provided.

[0028] 1.1 Data Upload and Storage Proof This section describes how one or more copies of data may be stored at multiple storage providers 302. Proof of storage may utilize digital signatures, cryptographic hash functions, or a mixture of both.

[0029] Figure 4 shows an exemplary overview of the interactions between data provider (client) 303, service provider 301, and storage provider 302. Data provider 303 issues a storage request to service provider 301. Storage terms are agreed upon. Data provider 303 sends a file to service provider 301, which maps the file into data blocks and uses the data blocks to generate a Merkle tree. The data blocks and the Merkle root of the Merkle tree are sent to storage provider 302. Storage provider 302 generates a Merkle tree using the data blocks and verifies that the Merkle root of the tree matches the received Merkle root. At a later time, service provider 301 sends a request for a storage proof to storage provider 302. Storage provider 302 responds with the requested proof.

[0030] The following example assumes that client 303 has reached an agreement with oracle 301 to store data D for duration T. Based on quality of service, there may be single or multiple copies of D. It is also assumed that secure communication channels exist between the three actors, or at least between client 303 and oracle 301 and between oracle 301 and storage provider 302.

[0031] 1.1.1 One Data Copy In this example, one storage provider (SP) 302 holds only one copy of the data. 1. Oracle 301 prepares the data to be saved and divides D into an array of data blocks. D=(d1,d2,...,d m ) 2. The oracle 301 maps the data block to a leaf of the Merkle tree, i.e., leaf i =fn(d i), compute the Merkle root rt and send the data block to the SP302 for storage. 3. SP 302 stores D after recalculating the root and verifies that it matches the value stored by oracle 301.

[0032] It should be noted that data preparation may include one or more of compressing the data, applying channel coding, and extracting data and metadata.

[0033] A Merkle tree leaf node may be given as: 1. Leaf i =Hash(d i ) 2. Leaf i =Hash(P i =d i ×G), where G, P i is an elliptic curve point.

[0034] The oracle 301 holds the Merkle root rt and the parameter m. Periodically, the oracle 301 requests a memory proof from the SP 302. The oracle 301 randomly selects i∈[1,m] and returns the memory leaf i Challenge the SP 302 to provide a proof. The proof of memory may comprise: 1. Leaf i Merkle proof for computing the tree root from 2. The original image of the leaf 3. Leaf i =Hash(P i ) only if d i A message signed by

[0035] In the first case, the leaf i =Hash i (d i ), then d i Note that the proof of storage requires that we provide the value of i=Hash(P i ), the proof of memory is the actual value d i does not reveal.

[0036] The required proof may be part of the unlocking script of the response transaction, and the validation of the Merkle path is included in the locking script of the request transaction.

[0037] As an example, assume that the data is divided into m=8 blocks and mapped to a Merkle tree as shown below.

[0038]

number

[0039] The following locking script can be unlocked by a Merkle proof that proves the unlocking script containing d3 and its link to the Merkle tree Root:

[0040] [Table 1]

[0041] [Table 2]

[0042] The script execution is shown in the table below.

[0043] [Table 3]

[0044] When a leaf is a hash of an elliptic curve point, i.e., leaf i =h i =Hash(d i ×G), the following locking script i Without needing to reveali It can be unlocked by an unlocking script that contains a signature that can be generated only from knowledge of .

[0045] [Table 4]

[0046] [Table 5]

[0047] 1.1.2 Multiple Data Copies Having multiple copies of data is a more realistic and sensible scenario for data storage. Keeping more than one copy of data and using more than one SP 302 improves resilience in cases where some copies are lost due to hardware failure, missing connections, or an SP 302 going out of business. A copy of the data may be sent to each SP 302, and the oracle 301 may periodically challenge each SP 302 for proof of storage, as described in the previous section. However, this does not prevent storage providers from colluding to claim fees for multiple copies while storing smaller amounts. To mitigate, each copy of the data may be encrypted differently to produce a different ciphertext. The challenge would require the SP 302 to provide proof of storage of the ciphertext rather than the plaintext data. The SP 302 is not given access to the encryption and decryption keys.

[0048] Another feature is that during data retrieval, one may wish to speed up retrieval by downloading from multiple SPs in parallel, e.g., the possibility to download different data blocks from different SPs. To facilitate downloading different data blocks from different SPs 302, a stream cipher may be used with different keys. Applying a block cipher such as AES with a cipher mode counter (CTR) or output feedback (OFB) makes the block cipher a stream cipher. An illustrative example with two copies is shown in FIG. 5. 1. Oracle 301 prepares the data to be saved and defines D as an array of data blocks D=(d1,d2,...,d m ) and make two copies. 2. Oracle 301 encrypts data D to generate two different ciphertexts C1 = f(D, key1) and C2 = f(D, key2). C1 and C2 are the same size, but C i =(c i1 ,c i2 ,…,c im ) and i∈[1,2]. 3. Oracle 301 converts C1 and C2 into a Merkle tree T A , T B As a result,

[0049]

number

[0050] and

[0051]

number

[0052] For the case where f() is a stream cipher and D=(d1,…,d m ), then key i If is known, then c ix From dx Note that it is possible to extract 4. SP1 and SP2 each store C1 and C2 and their Merkle tree mappings, respectively. Oracle 301 stores rt1, rt2, key1, and key2.

[0053] Similar to the single copy use case, the Merkle tree leaf nodes may be hashes of the ciphertext or hashes of EC points (generated from the ciphertext).

[0054] A tree T whose leaf nodes are hashes of ciphertexts A and T B The leaf is

[0055]

number

[0056] and

[0057]

number

[0058] where:

[0059]

number

[0060] is the bitwise XOR operation, and k 1i and k 2i is the key material generated from the function in AES-ctr mode and the symmetric key and counter setting. 1i and k 2i Both can be regenerated by the oracle.

[0061] When a leaf node is a hash of an EC point, i =Hash(c i×G)=Hash(P i ) A proof of memory for a data block may include: 1. Leaf i Merkle proof for 2. EC Point P i The original image of the leaf 3. EC point P as public key i An ECDSA digital signature that can be verified using

[0062] In some examples, during data upload, the oracle 301 creates multiple copies and then encrypts each copy with a different key, generating a Merkle tree for each ciphertext C1, C2. This method allows for the reuse of Merkle proofs within a single tree. To illustrate, consider T A The leaf is

[0063]

number

[0064] where

[0065]

number

[0066] Similarly, T B The leaf is

[0067]

number

[0068] where

[0069]

number

[0070] T AIn the Merkle proof of other leaves from

[0071]

number

[0072] A Merkle proof of

[0073] In another example, to enable the reuse of Merkle proofs across different Merkle trees, the process shown in Figure 6 is followed. During data upload, the oracle 301 first encrypts the data using one single key to produce one single ciphertext C, and then makes multiple copies. For each copy of the ciphertext, the oracle 301 modulo-adds a different secret value K1, K2 by n (add mod n). The storage provider SP Alice , S1=s 11 ,...,s 1m Save , but s 1i =c1+k 1i mod n, and T A of

[0074]

number

[0075] teeth,

[0076]

number

[0077] Similarly, the storage provider SP Bob In contrast, T B The leaf is

[0078]

number

[0079] where:

[0080]

number

[0081] Based on the Merkle proof of

[0082]

number

[0083] The Merkle proof of

[0084]

number

[0085] The oracle 301 verifies the Merkle proof as follows: 1. SP B from

[0086]

number

[0087] Get. 2.

[0088]

number

[0089] Calculate and find that

[0090]

number

[0091] in

[0092]

number

[0093] Check if it is equal to .

[0094] 1.2 Applying RAID and Encryption A RAID configuration that ensures data durability may be chosen so that data can still be stored if one copy is lost and also allows for fast access speeds so that data reads can be performed in parallel. Figure 7 shows an example of how data to be stored should be prepared. First, a RAID configuration is applied, then encryption, Merklization, and storage are applied. This example uses RAID(0+1), where data D is first peeled into two blocks D odd , D even Then each block is mirrored, resulting in four data blocks D odd , D odd , D even , D even It has.

[0095] Each block is encrypted separately to produce a respective output C1, C2, C3, C4. i is mapped into a Merkle tree, and then each C i and the mapping is sent to the SP 302. In FIG. i It uses different keys (Keyi) and different starting controls. i Also, data strip d i Note that the size of D does not have to be 128 bits. odd (and D even ) may be divided into 128-bit blocks when encrypted.

[0096] 1.3 Competition-based memorization proofs and data retrieval In the previous section, we learned that each challenge is customized to each SP, i.e., the transaction is sent to an oracle 301, i.e., a specific storage provider SP, that can unlock the transaction by providing a Merkle proof. A However, a race condition may be created by the oracle 301 between the storage providers. The first SP 302 to provide an unlocking script wins the race. Such a race transaction allows different storage providers 302 to take advantage of their bandwidth and data availability.

[0097] 1.4 Data Retrieval When a client 303 wishes to retrieve data, the oracle 301 may connect to the SP 302 to facilitate the retrieval of the data. The data can be sent off-chain or on-chain. Sending data off-chain ensures data privacy as the stored data is not encrypted and avoids having large transactions unnecessarily. Reusing previously sent Merkle proofs can allow the length of new proofs to be shortened. Rather than sending proofs for each leaf preimage, it is also possible for the SP to send a set of consecutive leaves and provide a single Merkle proof for that set.

[0098] 2. Example System Overview A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform a solution to a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through the mere publication of block headers.

[0099] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes to data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0100] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying an amount of a digital asset derivable from an evolving series of transactions. A consumable output is sometimes called a UTXO (“unspent transaction output”). The output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that specifies the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, a pair of transactions is considered, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that specifies one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0101] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions specified in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

[0102] An alternative type of transaction model is the account-based model, where each transaction specifies the amount to be transferred by reference to absolute account balances rather than by referencing backwards the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain.

[0103] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, i.e., typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 (often referred to as "miners") that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be organized as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0104] Each blockchain node 104 comprises a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0105] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, with a transaction in this context referring to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout.

[0106] Blockchain nodes 104 may be configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Blockchain nodes 104 may be configured to create blocks 151 and store respective copies of the same block chain 150 in their respective memories. Blockchain nodes 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions attempting to consume the same output.

[0107] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction onward. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and even sent to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or submission in a temporal sequence, and therefore does not necessarily preclude a transaction 152i, 152j from being created or submitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0108] Due to the resources involved in transaction validation and publishing, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may also take the form of a user terminal or a group of user terminals networked together.

[0109] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer or in a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0110] 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 agreement (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, a node 104 may focus on transaction validation and propagation or on block mining. In some examples, a blockchain node 104 may perform two or more of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0111] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as accumulating entities that accumulate copies of the blockchain 150 (e.g., obtain copies of the blockchain from blockchain nodes 104).

[0112] 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 called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It is 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 shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0113] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any actions attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

[0114] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0115] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second functionality comprises reconciling the amounts specified in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0116] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented within a set of two or more separate applications that interface via, for example, an API, or one plugged into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0117] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, to truly inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet function on each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to jointly implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0118] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance rather than by referencing backward the UTXO of a transaction that precedes it in the sequence of past transactions. The current state of every account is accumulated and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (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. In addition, an optional data field may also be signed with a transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0119] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as described above, the data fields of an account-based transaction may point backward to a previous transaction, which is equivalent to the input of an output-based transaction, referencing 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 (in which the receiving address of the account is specified) and a "value" field (in which an amount of a digital asset may be specified). Together, the recipient field and value field are equivalent to the output of an output-based transaction, which can be used to assign an amount of a digital asset to a blockchain address. Similarly, account-based transactions have a "signature" field that contains a signature for the transaction. The signature is generated using the sender's private key and verifies that the sender has authorized this transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically includes a signature for the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature can be checked to determine whether the transaction is valid and recorded on the blockchain. In an account-based blockchain, a "smart contract" refers to a transaction that includes a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) satisfying one or more conditions specified by the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions.Thus, in some examples, a smart contract may 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 specified by the locking script are satisfied by the inputs of the subsequent transaction.

[0120] 3. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0121] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, 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 the node 104.

[0122] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0123] The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence, as defined by transaction pointers specified in the transactions (e.g., which transactions point backward to which other transactions). They may be equivalently interchanged with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or the like. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (a descendant transaction or “child”) that points to a preceding transaction (an ancestor transaction or “parent”) will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, the orphan may be discarded or may be buffered for some time to wait for a parent.

[0124] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO 0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a locking script that specifies the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be valid, and therefore for the UTXO to be successfully redeemed.

[0125] A locking script (also called 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 called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume a transaction output 203, for example, Alice's signature requirements. A locking script appears in the output of a transaction. An unlocking script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0126] So, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A ]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID, TxID0. Tx1's input 202 comprises a pointer that points backward into Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P AThe data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a locking script, or by a node protocol, or a combination of these.

[0127] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions specified in the locking script (where this condition may comprise one or more criteria).

[0128] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to specific opcodes in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, can accumulate data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data in the blockchain 150. For example, the data may comprise a document that is desired to be accumulated in the blockchain.

[0129] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of 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 portion of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0130] A locking script may be referred to as a "scriptPubKey," typically referring to the fact that the locking script comprises the public key of the party to which each transaction is locked. An unlocking script may be referred to as a "scriptSig," typically referring to the fact that the unlocking script provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0131] 4. Further Special Notes Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited not by the described embodiments, but only by the appended claims.

[0132] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0133] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, issuing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the function of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be nodes of the suitable Bitcoin network 106).

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

[0135] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 104.

[0136] Some embodiments are described with respect to a blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. 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 node that is chosen is often called a validator. Blockchain nodes can look up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

[0137] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0138] Statement 1. A computer-implemented method for enabling verification of data storage, the method being performed by a first party; obtaining a plurality of data blocks, the plurality of data blocks together representing data items to be stored by one or more respective second parties; generating, for each second party, a respective hash root of a respective hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective set of data blocks is used to generate a respective leaf hash of the respective hash tree; and for each second party, submitting a respective request transaction to one or more blockchain nodes of the blockchain network, wherein each request transaction is a blockchain transaction configured to require each response transaction to include a respective hash proof for each leaf hash of a respective hash tree.

[0139] Each request transaction may have a respective hash root of a respective hash tree, for example, each request transaction's locking script may have a respective hash root.

[0140] Statement 2. The method of statement 1, wherein for each hash tree: Each respective leaf hash based on a respective data block is generated by hashing at least the respective data block, or Each respective leaf hash based on the respective data block is generated by hashing a respective public key, and the respective public key is generated based on at least the respective data block and a generator point.

[0141] Statement 3. The method of statement 2, wherein each respective hash tree is based on a different respective value such that each respective hash root is a different hash root.

[0142] Statement 4. The method of statement 1, generating one or more respective plurality of encrypted data blocks, each respective encrypted data block being generated based on a respective data block of the plurality of data blocks, and for each hash tree: Each respective leaf hash based on a respective data block is generated by hashing at least a respective encrypted data block of the respective plurality of encrypted data blocks; or Each respective leaf hash based on the respective data block is generated by hashing a respective public key, and the respective public key is generated based on at least a respective encrypted data block of the respective plurality of encrypted data blocks and a generator point.

[0143] Statement 5. The method of statement 6, wherein each respective one of the plurality of encrypted data blocks is generated based on a different encryption key.

[0144] Statement 6. The method of any preceding statement, wherein each request transaction is configured to require each response transaction to have a respective preimage to a respective leaf hash.

[0145] Statement 7. The method of any preceding statement, wherein each request transaction is configured to require each response transaction to comprise a respective signature generated using the respective data block on which the respective leaf hash is based.

[0146] Statement 8. The method of statement 4 or any statement dependent thereon, wherein each request transaction is configured to require each response transaction to comprise a respective signature generated using a respective encrypted data block on which the respective leaf hash is based.

[0147] Statement 9. The method of any preceding statement, wherein each respective request transaction comprises a respective locking script, and each respective locking script is configured to enforce a requirement that each response transaction comprises a respective hash certificate.

[0148] Statement 10. The method of any preceding statement, wherein said obtaining a plurality of data blocks comprises receiving a plurality of data blocks from a third party, or receiving a data item from a third party and generating a plurality of data blocks.

[0149] Statement 11. A method of any of the foregoing statements, comprising sending the data item and / or multiple data blocks to one or more second parties.

[0150] Statement 12. A method of any of the foregoing statements, comprising sending each hash root to a respective second party.

[0151] Statement 13. The method of statement 4 or any statement dependent thereon, comprising sending each of the plurality of encrypted data blocks to a respective second party.

[0152] Statement 14. The method of any preceding statement, wherein each respective set of data blocks of the plurality of data blocks comprises the same set of data blocks.

[0153] Statement 15. The method of statement 14, wherein each respective set of data blocks comprises all of the plurality of data blocks.

[0154] Statement 16. The method of any of statements 1-13, wherein at least two respective sets of data blocks of the plurality of data blocks comprise different sets of data blocks.

[0155] Statement 17. A computer-implemented method for providing proof of data storage, the method being performed by a second party; obtaining a plurality of data blocks, the plurality of data blocks together representing a data item stored by a second party; generating a hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective set of data blocks is used to generate a respective leaf hash of the respective hash tree; Obtaining a request transaction, the request transaction being a blockchain transaction configured to require that a response transaction comprise a respective hash proof for each leaf hash of a respective hash tree; generating each hash proof; submitting a response transaction to one or more blockchain nodes of a blockchain network, the response transaction comprising a respective hash proof.

[0156] Statement 18. The method of statement 17, wherein the request transaction is configured to require the response transaction to provide a respective preimage to a respective leaf hash, and the method further comprises: generating respective preimages, and a response transaction comprising the respective preimages.

[0157] Statement 19. The method of statement 17 or statement 18, wherein the request transaction is configured to require that the response transaction comprise a respective signature generated using the respective data block on which the respective leaf hash is based, and the method further comprises: generating respective signatures, with the response transaction comprising the respective signatures.

[0158] Statement 20. The method of statement 17 or statement 18, obtaining a plurality of respective encrypted data blocks, each respective encrypted data block being generated based on a respective data block of the plurality of data blocks; Each respective leaf hash based on a respective data block is generated by hashing at least a respective encrypted data block of the plurality of encrypted data blocks; or Each respective leaf hash based on the respective data block is generated by hashing a respective public key, the respective public key being generated based on at least a respective encrypted data block of the plurality of encrypted data blocks and a generator point; The method is configured such that the request transaction requires that the response transaction comprise a respective signature generated using a respective encrypted data block on which the respective leaf hash is based, generating respective signatures, with the response transaction comprising the respective signatures.

[0159] Statement 21. A computing device comprising: a memory having one or more memory units; and a processing device having one or more processing units, the memory storing code configured to execute on the processing device, the code configured, when on the processing device, to perform the method of any of statements 1-20.

[0160] Statement 22. A computer program embodied on computer-readable storage and configured, when executed on one or more processors, to perform the method of any of statements 1-20.

[0161] According to another aspect disclosed herein, a method may be provided that includes first and second party actions. According to another aspect disclosed herein, a system may be provided that includes first and second party computer devices. [Explanation of symbols]

[0162] 100 systems 101 Packet Switched Network 102 Computer Equipment 103 Users, Parties, and Agents 103a Alice 103b Bob 104 nodes, blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Decentralized network, blockchain network, node network, peer-to-peer (P2P) network 150 Blockchain 151 blocks, blockchain blocks 152 transactions, blockchain transactions 154 Ordered Sets, Ordered Pools 201 Header 202 Input, input field 203 Output, Output Field 300 System 301 First Party, Service Provider, Oracle 302 Second Party, Storage Provider 303 Third Parties, Data Providers, Clients

Claims

1. 1. A computer-implemented method for enabling verification of data storage, the method being performed by a first party and comprising: obtaining a plurality of data blocks, said plurality of data blocks together representing data items to be stored by one or more respective second parties; For each second party, generating a respective hash root of a respective hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective set of data blocks is used to generate a respective leaf hash of the respective hash tree; For each second party, submitting a respective request transaction to one or more blockchain nodes of a blockchain network, the respective request transaction being a blockchain transaction configured to require that a respective response transaction comprise a respective hash proof for a respective leaf hash of the respective hash tree; A method for providing the above.

2. For each hash tree, Each respective leaf hash based on a respective data block is generated by hashing at least said respective data block; or 2. The method of claim 1, wherein each respective leaf hash based on a respective data block is generated by hashing a respective public key, the respective public key being generated based on at least the respective data block and a generator point.

3. 3. The method of claim 2, wherein each respective hash tree is based on a different respective value such that each respective hash root is a different hash root.

4. generating one or more respective plurality of encrypted data blocks, each respective encrypted data block being generated based on a respective data block of the plurality of data blocks, and for each hash tree: Each respective leaf hash based on a respective data block is generated by hashing at least the respective encrypted data block of the respective plurality of encrypted data blocks; or 2. The method of claim 1, wherein each respective leaf hash based on a respective data block is generated by hashing a respective public key, the respective public key being generated based on at least the respective encrypted data block of a respective plurality of encrypted data blocks and a generator point.

5. The method of claim 6 , wherein each respective one of the plurality of encrypted data blocks is generated based on a different encryption key.

6. 6. The method of claim 1, wherein the respective request transactions are configured to require the respective response transactions to comprise a respective preimage to the respective leaf hash.

7. 7. The method of claim 1, wherein the respective request transaction is configured to require the respective response transaction to comprise a respective signature that was generated using the respective data block on which the respective leaf hash is based.

8. 5. The method of claim 4 or any claim dependent thereon, wherein the respective request transaction is configured to require the respective response transaction to comprise a respective signature that was generated using the respective encrypted data block on which the respective leaf hash is based.

9. 9. The method of claim 1, wherein each respective request transaction comprises a respective locking script, the respective locking script being configured to enforce a requirement that the respective response transaction comprises the respective hash certificate.

10. 10. The method of claim 1, wherein the step of obtaining the plurality of data blocks comprises receiving the plurality of data blocks from a third party, or receiving the data items from a third party and generating the plurality of data blocks.

11. 11. A method according to any preceding claim, comprising sending said data item and / or said plurality of data blocks to said one or more second parties.

12. 12. A method according to any preceding claim, comprising sending the respective hash root to the respective second party.

13. 5. A method according to claim 4 or any claim dependent thereon, comprising sending the respective plurality of encrypted data blocks to the respective second party.

14. 14. A method according to any preceding claim, wherein each respective set of data blocks of the plurality of data blocks comprises the same set of data blocks.

15. The method of claim 14 , wherein each respective set of data blocks comprises all of the plurality of data blocks.

16. 14. The method of claim 1, wherein at least two respective sets of data blocks of the plurality of data blocks comprise different sets of data blocks.

17. 1. A computer-implemented method for providing proof of data storage, the method being performed by a second party and comprising: obtaining a plurality of data blocks, said plurality of data blocks together representing a data item stored by said second party; generating a hash tree based on a respective set of data blocks of the plurality of data blocks, wherein each respective data block of the respective set of data blocks is used to generate a respective leaf hash of the respective hash tree; obtaining a request transaction, the request transaction being a blockchain transaction configured to require a response transaction to comprise a respective hash proof for each leaf hash of the respective hash tree; generating said respective hash certificates; submitting a response transaction to one or more blockchain nodes of a blockchain network, the response transaction comprising the respective hash proof; A method comprising:

18. the request transaction is configured to require the response transaction to comprise a respective preimage to the respective leaf hash, and the method further comprises:

18. The method of claim 17, comprising generating the respective preimages, the response transactions comprising the respective preimages.

19. wherein the request transaction is configured to require that the response transaction comprise a respective signature that was generated using the respective data block on which the respective leaf hash is based, and the method further comprises:

19. A method according to claim 17 or 18, comprising the step of generating the respective signatures, the response transaction comprising the respective signatures.

20. obtaining a plurality of respective encrypted data blocks, each respective encrypted data block being generated based on a respective data block of the plurality of data blocks; Each respective leaf hash based on a respective data block is generated by hashing at least a respective encrypted data block of the plurality of encrypted data blocks; or Each respective leaf hash based on a respective data block is generated by hashing a respective public key, the respective public key being generated based on at least the respective encrypted data block of the plurality of encrypted data blocks and a generator point; wherein the request transaction is configured to require that the response transaction comprise a respective signature generated using the respective encrypted data block on which the respective leaf hash is based, and the method further comprises:

19. A method according to claim 17 or 18, comprising the step of generating the respective signatures, the response transaction comprising the respective signatures.

21. A computer device comprising: a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to run on the processing device, the code configured to perform the method of any one of claims 1 to 20 when present on the processing device.

22. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 20 when executed on one or more processors.

Images