Storage overlay network

Abstract

A computer-implemented method of storing data, wherein the method is performed by a storage provider and comprises: receiving a request, from a first user, to store a data item; submitting a commitment transaction to a blockchain network, wherein the commitment transaction comprises a commitment of the data item; storing and / or publishing the data item and / or the commitment of the data item; and providing, to the first user, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

Description

[0001] STORAGE OVERLAY NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a method of maintaining data as part of a storage (or overlay) network and to a method of providing that data has been accepted for storage in / on the storage (overlay) network.

[0004] BACKGROUND

[0005] A public key infrastructure (PKI) is a combination of different roles, policies, and procedures that supports the creation, management, distribution, and revocation of digital certificates. PKI provides trust services (confidentiality, integrity, and authenticity) and facilitates secure transfer of information for a wide range of network. A PKI binds public keys with identities of users. The binding is established at the moment of registration with a certificate issued by the certificate authority (CA). Revocation of the certificate can happen at any moment and is managed by a revocation authority (RA); often, CA and RA are the same entity.

[0006] The CA may delegate to a second authority, a registration authority (RegA), to carry out the necessary validity checks during the registration process. The RegA is responsible for accepting requests of digital certificates and authenticating the requesting entity, but does not sign or issue certificates. The information verified by the RegA allows unique identification of entities by their public keys. Certificates are signed by the CA using their private keys. Entities interacting with a certified entity can check the validity of the certificate by verifying the signature and that the certificate did not expire. The expiration of the certificate can be determined in different ways accordingly with the specific implementation of the PKI.

[0007] The blockchain can be used to provide PKI services without the need for additional infrastructure. The CA runs a blockchain node, and when they are notified by the RegA that a user has been authorized, they publish a transaction that stores the public key of the user (or its hash). This transaction corresponds to the certificate, and its spent status determines whether the certificate is still valid. The Lightweight Directory Access Protocol (LDAP) is an open industry standard application protocol for accessing and maintaining distributed directory information services over a network. Information is saved as entries, which consist of a set of attributes, determined by a name (its type or description) and one or more values. Each entry has a unique identifier: its distinguished name. The distinguished name may change over the lifetime of the entry. Directory services allow for the sharing of information about users, systems, networks, services, and applications (e.g., organized set of records with hierarchical structure). Common LDAP operations in an LDAP session are searching and retrieving directory entries, checking the attributes of an entry, and adding, deleting, or modifying entries. Clients start an LDAP session by connecting to an LDAP server. The client then sends an operation request to the server, and a server sends a response in return. All communication happens through secure communication channels (e.g., TLS channels).

[0008] Merkle trees are trees with leaves labelled by hashes of data, while non-leaf nodes are labelled by the cryptographic hash of a combination (e.g., concatenation) of the labels of its child nodes. Merkle trees allow for efficient and secure verification of the data contained in the leaves. This is achieved by the process known as Merkle proof. The cryptographic security provided by the hash function ensures that Merkle proofs cannot be falsified. Bitcoin SV stores blocks as Merkle tree and relies on Merkle proof to prove that transaction have been added to blocks. The root of the tree is stored in the block header. Immutability of the blockchain grant that the Merkle proof of a transaction cannot be modified. The hash function used is the double SHA-256 hash function. Merkle trees are used to improve the efficiency of verifying that a transaction is contained in a block.

[0009] SUMMARY

[0010] According to one aspect disclosed herein, there is provided a computer-implemented method of storing data, wherein the method is performed by a storage provider, wherein the storage provider is an entity other than a blockchain node, and wherein the method comprises: receiving a request, from a first user, to store a data item; submitting a commitment transaction to one or more blockchain nodes of a blockchain network, wherein the commitment transaction comprises a commitment of the data item; storing and / or publishing the data item and / or the commitment of the data item; and providing, to the first user, a storage proof, the storage proof being generated in response to the commitment transaction being submitted to the one or more blockchain nodes and as a function of the data item, the storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0011] According to another aspect disclosed herein, there is provided performed by a first user and comprising: sending a data item to a storage provider; receiving, from the storage provider, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method performed by a second user and comprising: receiving a data item from a storage provider and / or a first user; receiving, from the storage provider and / or the first user, a blockchain proof proving that a commitment transaction comprising a commitment of the data item has been recorded on the blockchain; receiving, from the storage provider and / or the first user, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage; using the blockchain proof to verify that the commitment transaction has been recorded on the blockchain and / or sending the blockchain proof to a second user for verifying that the commitment transaction has been recorded on the blockchain; and / or using the storage proof to verify that the data item and / or the commitment of the data item has been accepted by the storage provider for storage and / or sending the storage proof to the second user for verifying that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0013] Embodiments of the present disclosure provide a mechanism for proving that data has been accepted for storage on a storage network. The storage network may be maintained by a network of storage providers (e.g. nodes, servers, etc.). Data (or a hash or other type of commitment) is stored by the storage provider(s). Upon storing the data, the storage provider generates and provides a proof (e.g. a signature) of data storage which a user may use to verify, or prove to a different user, that their data has been stored. The proof (e.g. signature) proves that the data was accepted by the storage provider. A commitment (e.g. a hash) of the data is also stored on the blockchain. A proof of storage of the commitment on the blockchain may also be provided to the user.

[0014] BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

[0016] Figure 1 is a schematic block diagram of a system for implementing a blockchain,

[0017] Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain,

[0018] Figure 3 is a schematic block diagram of a storage network that utilises the blockchain, Figure 4 schematically illustrates an example overlay network,

[0019] Figure 5 schematically illustrates an example data packet creation,

[0020] Figure 6 schematically illustrates an example data packet submission,

[0021] Figure 7 schematically illustrates an example verification of a data packet,

[0022] Figure 8 schematically illustrates an example retrieval of a data packet,

[0023] Figure 9 is an example flow of a data packet lifecycle,

[0024] Figure 10 is an example flow of a data packet creation,

[0025] Figure 11 is an example flow of a consolidation process,

[0026] Figure 12 is an example flow of a block point creation,

[0027] Figure 13 is an example flow of an overlay proof verification, and Figure 14 is an example flow of a document data packet creation.

[0028] DETAILED DESCRIPTION OF EMBODIMENTS

[0029] 1. STORAGE PROOFS

[0030] Embodiments of the present disclosure may be used to prove that data has been stored (and / or accepted for storage) by a storage provider. Figure 3 illustrates an example system 300 for implementing the embodiments described herein. The system 300 comprises one or more storage providers 302, one or more users 304 (or "parties", more generally), and one or more blockchain nodes 104 of a blockchain network 106. Each storage provider 302 may be a respective computer, such as a server. The storage providers 302 are configured to communicate with one another, with the one or more users 304, and with the one or more blockchain nodes 104. The storage providers 302 may be connected as part of a network 306 of storage providers 302. The network 306 may be an overlay network, i.e. a network that operates overlaid on top of another, lower-level network. The lower-level network may be the internet 101 and / or the blockchain 150.

[0031] Each user 304 may be configured to perform any or all of the actions described below, with reference to Figures 1 and 2, as being performed by Alice 103a and / or Bob 103b.

[0032] The term "storage network" may be replaced with "overlay network" throughout the present disclosure. Similarly, the term "storage node" may be replaced with "overlay server", and the terms "storage proof" and "proof of storage" may be replaced with "overlay proof". The storage providers may be operated by an organisation, such as a government, a company, a charity, a university, etc.

[0033] Users 304 use the storage providers 302 to store their data. In general, the storage providers 302 provide proof that the user's data has been stored. A commitment of the data is stored on the blockchain 150. Storing a commitment of the data enables users to prove that the data existed at the time the commitment was stored. This provide an immutable record of the data / commitment being stored, along with a timestamp of the storage. The storage providers 302 also provide proof that the data has been accepted for storage on the storage network 306, e.g. that the storage provider 302 acknowledges the data satisfies one or more requirements of the storage network 306. For example, the storage network 306 may be operated by a university, and the storage providers may be university servers that verify that the user (e.g. a student) has provided a document that satisfies one or more requirements of a dissertation, exam answer, etc. This provides the student with a record that they have fulfilled the submission requirements.

[0034] A user (e.g. Alice 103a) submits a request to a storage provider 302 to store her data. The request may comprise only the data or it may include additional information. The data may be encrypted by Alice 103a. The storage provider 302 generates a commitment of the data, e.g. by hashing the data with a hash function, such as SHA256. Any suitable hash function may be used. Other types of a commitment may be used that obfuscate the data. An example is a Pederson commitment. The hash may be a salted hash. That is, both the data and a salt (e.g. a random value) may be input to the hash function. The storage provider 302 submits a transaction to the blockchain network that includes the commitment. The transaction is referred to herein as a "commitment transaction". The commitment may be stored in a spendable or unspendable output of the transaction, if an output-based blockchain is used.

[0035] In some examples, the storage provider 302 performs the transaction verification (i.e. validation) steps that would normally be performed by a blockchain node 104, i.e. the storage provider act as a blockchain node 104 to validate the commitment transaction. Put simply, the storage provider 302 may validate the transactions that it produces. The storage provider 302 may also publish the commitment transaction on the blockchain 150. Or, the storage provider may send the commitment transaction to a blockchain node 104 for validation and publishing on the blockchain 150. So, in the former case, the storage provider 302 may perform certain verification steps (discussed in detail below) on the data to be stored and also create and validate a commitment transaction. Then, the storage provider 302 either sends the validated commitment transaction to other blockchain node(s) for recording on the blockchain 150 or records the validated commitment transaction on the blockchain 150 itself. Or in the latter case, the storage provider 302 completes their own internal verifications on the data, and then sends the commitment transaction to the blockchain network 106 for the blockchain nodes 104 to validate the commitment transaction, as is traditionally the case.

[0036] The storage provider 302 stores the data and / or the commitment. The data and / or commitment may be stored in storage accessible only by the storge provider 302, or in storage accessible by the network 306 of storage providers, e.g. cloud storage, a distributed database, etc. The data and / or commitment may be published such that it is accessible by the one or more users 304. The storage provider 302 may send, to Alice 103a, a proof (a "blockchain proof") that Alice 103a can use to verify (or use to prove) that the commitment of her data has been stored on the blockchain 150. The proof may be a simplified payment verification (SPV) proof. The skilled person will be familiar with SPV proofs, the content of an SPV proof and how Alice 103a would use the proof to verify the commitment transaction containing the commitment has been stored on the blockchain 150. The blockchain proof may be sent directly to Alice 103a or published, e.g. on the overlay network 306. In some examples, the storage provider 3002 only sends the blockchain proof if it is requested by Alice 103a.

[0037] The storage provider 302 sends, to Alice 103a, a proof (a "storage proof") that Alice 103a can use to verify (or use to prove) that her data has been accepted by the storage provider 302 for storage. The storage proof is generated based on (i.e. as a condition of and / or in response to) the commitment transaction being recorded on the blockchain 150. The storage proof may be a digital signature generated by the storage provider 302. The signature may be generated based on the data. For example, the signature may sign the data. As another example, the private key used to generate the signature may be a function of the data. In some examples, the storage proof is generated based on an elliptic curve block point, as discussed below. The storage proof is not the same as the blockchain proof. That is, the storage proof does not prove that a transaction has been recorded on the blockchain 150.

[0038] In some examples, the storage provider 302 may, after providing the proof(s), delete Alice's data and store only the commitment and / or the storage proof (and optionally the blockchain proof). Block points are discussed below - in some examples the storage provider 302 may delete the data and store the block point instead.

[0039] The storage network 306 may be associated with an identifier (e.g. a name of the network, a public key, a value, etc.). The commitment transaction may contain the identifier, enabling users 304 and storage providers to easily identify relevant transactions. Rather than containing the identifier, the commitment transaction may contain an obfuscated version of the identifier, e.g. a hash of the identifier, or a hash of the identifier and the commitment. The hash may be based on one or more additional items. The identifier may be unique to the network, however that is not essential.

[0040] The commitment transaction may have a version field. The identifier may be a version number associated with the network 306. The version number may be associated with a particular storage provider 302. The version number may be associated with a particular type of data, e.g. driving licenses, university submissions, passports, etc.

[0041] The storage provider 302 may send the identifier (or obfuscated identifier) to Alice 103a so that she can identify the commitment transaction on the blockchain 150. The storage provider 302 may publish the (obfuscated) identifier so that it is accessible to Alice 103a.

[0042] The storage provider 302 may perform one or more checks on Alice's data before accepting her data for storage. The storage provider 302 may check that Alice 103a has authorisation to submit data to the storage network. This may involve the storage provider 302 verifying Alice's credentials. For example, the storage provider 302 may verify that Alice 103a has been issued with a certified public key.

[0043] As another example, the storage provider 302 may verify that Alice's data has a predetermined format and / or structure. For instance, if the data is a particular file type, has certain fields, is a certain length, etc. The storage provider 302 may verify that Alice's data contains one or more signatures from one or more predetermined parties. Returning to the university submission example, the storage provider 302 may verify that Alice's dissertation is signed by Alice 103a, her supervisor, one or more reviewers, etc.

[0044] In some examples, Alice's data may be required to obtain a set of signatures but one or more of those signatures may be missing at the time of sending the data to the storage provider 302. Still, obtaining a proof of the data being stored allows Alice 103a to prove that she has at least started the process for obtaining the required signatures.

[0045] In some examples, the storage provider 302 is associated with a particular data type and / or application. For example, the storage provider 302 may be responsible for storing driving licenses or passport information. Each storage provider 302 may be associated with a particular data type, e.g. one provider 302 per data type. In these examples, the storage provider 302 may verify that Alice's data is of the correct type and / or application.

[0046] The storage provider 302 may receive a request for Alice's data, e.g. from Alice 103a, a different user (e.g. Bob 103b) or a different storage provider 302. The request may include the storage proof, and the storage provider 302 may use the storage proof to identify the relevant data and / or commitment transaction. The storage provider 302 may send one or more of the data, the commitment, the blockchain proof and the storage proof to Alice 103a, Bob 103b and / or one or more storage providers 302. In some examples, the storage provider may deny Bob's request for Alice's data, e.g. if Bob does not have the appropriate access rights, or if Alice's data is of a sensitive nature.

[0047] Alice 103a and / or Bob 103b, having received the blockchain proof and storage proof, are configured to use the proofs to verify that the commitment transaction has been stored on the blockchain 150 and that the data was accepted for storage by the storage provider 302. Alice 103a and / or Bob 103b may verify that the commitment, included in the commitment transaction, is a valid commitment of the data. For example, the data may be hashed to verify that it matches the commitment. In some examples, Alice 103a and / or Bob 103b may verify that an output of the commitment transaction (e.g. an output containing the commitment) is unspent in order to determine if the data is still valid or more generally any other information relating to the data. That is, the storage provider 302 may signal that the data is no longer valid by spending the output of the commitment transaction. A change in status may more generally signal a change in properties of the data. For example, if the data pack is a CBDC, then a spent status may signal that the receiver of the CBDC provided a payment receipt.

[0048] The storage provider 302 may obtain multiple commitment transactions recorded in a given block 151 of the blockchain 150. One or more of the transactions may have been generated by the storage provider 302. One or more of the transactions may have been generated by different storage providers 302. One or more of the transactions may be obtained by extracting the transaction(s) from the block 151. One or more of the transactions may be received from a different storage provider 302.

[0049] The storage provider 302 may generate an elliptic curve block point based on the obtained transactions. The block point is generated as follow. Each transaction commits to a data item. Each data item is hashed, separately, to generate a hashed data item. The hashed data items are summed (or otherwise aggregated or combined) to generate a summed value. A first elliptic curve point (i.e. a public key) is generated based on the summed value and a generator point. A second elliptic curve point may be generated based on a salt value. The block point is generated based on the first and second points, e.g. by summing those points. The salt value and corresponding elliptic curve point is not essential, e.g. if the participants are honest.

[0050] The storage provider 302 sends the block point to Alice 103a and / or Bob 103b. The storage provider 302 may publish the block point so that it is accessible to Alice 103a and Bob 103b. rather than sending the block point itself, the storage provider 302 may send a reference (e.g. a location) of the block point.

[0051] For a given commitment transaction (e.g. the transaction committing to Alice's data), the storage provider 302, or a separate party, may generate the storage proof (in this case a signature) using a private key based on the summed value, the salt value (if required), and the hash of Alice's data item. The signature is sent to Alice 103a and / or Bob 103b.

[0052] The storage provider 302 may generate and provide proofs for each data item in a similar way. As before, the storage provider may provide blockchain proofs for each commitment transaction.

[0053] Alice 103a and / or Bob 103b may obtain the block point and storage proof, and use them to verify that Alice's data has been accepted for storage. To do so, a third elliptic curve point is generated based on a hash of the data, and a fourth elliptic curve point is generated based on the block point and the third elliptic curve point, e.g. by subtracting the third point from the block point. Alice 103a and / or Bob 103b then verify that the signature (i.e. the storage proof) is valid for the fourth elliptic curve point (which is a public key). Alice 103a and / or Bob 103b may also check that there is a particular relationship between the elliptic curve points, e.g. that the third elliptic curve point and the fourth elliptic curve point sum to the block point.

[0054] 2. GOVERNMENT OVERLAY NETWORK

[0055] This section describes the architecture for a Government Overlay Network (GOvNet) that may be implemented using embodiments of the present disclosure. GOvNet is an example implementation of the storage network 306 described above. It will be appreciated that some of the features described below are optional.

[0056] The main goal is to maintain a register with information relating to public administration and other governmental entities. This information can be produced by government authorities or citizens. Despite the name explicitly referring to government, this type of overlay network is equally suitable for any organisation that wishes to move their administrative infrastructure on a blockchain.

[0057] GOvNet is maintained by government servers (GSs) which communicate with the blockchain and approve the data that users submit to the GOvNet. GSs have the power to create transactions on a blockchain that provide proof-of-existence of the data. Users of the overlay network register to join. The registration relies on public key infrastructure and ensures only authorized and recognized users access the functionalities of the network. A lightweight directory access protocol (LDAP) supports access to network information and retrieval of data. User experience with the network is mediated by a dedicated user terminal (e.g., an app on their phone) that helps them submitting data to the network. In the following, two main use cases for GOvNet are discussed: document management such as creation and distribution, and central bank digital currencies. Beside the main use cases, the essential of GOvNet are discussed, for instance, how they communicate with the blockchain, how data is stored, and how users' privacy is maintained.

[0058] 2.1 General overview GOvNet is an overlay network maintained by a government that stores information relating to the government, its citizens, and other public or private entities This information can be produced by government authorities or citizens and can include citizen information (e.g., personal documents), governmental information (e.g., housing register), and payment services (e.g., Central Bank Digital Currencies).

[0059] GOvNet is maintained by network devices, called Government Servers (GSs). These servers process information within the overlay network, securely store data, and share it with other devices, such as users' devices, public offices, and other network devices. Government Servers guarantee data integrity and timestamping by publishing anonymised data to a blockchain. Only fingerprints of the data are published, to guarantee the privacy of authorities and users'.

[0060] Citizens willing to interact with GOvNet may be required to be identified and preauthorised. Information lookup may be managed through an LDAP service. An overview of the architecture of a GOvNet is shown in Figure 4.

[0061] 2.1.1 Government Servers

[0062] Government Servers (GSs) are the main hardware infrastructure of a GOvNet. They can work as load balancers, replicating the required data, or have specific functionalities. In the latter case servers can be linked to specific use cases, for example one or more of them can offer registry office services, while others can support central bank digital currency (CBDC) transactions.

[0063] GSs process and store the information they receive from other GSs and authorised third parties. This information can be subsequently accessed by authorised parties for government-related services. Data are stored in internal databases, called GS Databases, maintained by the GSs.

[0064] Government Servers may offer one or more of the following functionalities: • GS Database: GSs store the information corresponding to the government services they offer in internal databases. Data can be stored in various forms (e.g., plaintext or hashed) to accommodate authorities and users' privacy.

[0065] • Communication with other GSs: GSs communicate users' data and other information with each other to ensure that data is up to date and consistent.

[0066] • Interaction with the blockchain network: GSs use blockchain technology to timestamp information and guarantee data immutability and authenticity. GSs manage all the services relative to transaction publishing and management, such as creating, funding, and publishing blockchain transactions containing the required data (or their fingerprints). A proof of publication (e.g., an SPV proof) is stored in the GS Database for lightweight verification.

[0067] • Data validation: provide information on the status of data stored, when required for governmental usages (e.g., verify the validity of a driving licence). This includes proof of publication on the blockchain (e.g., SPV proof) and a proof of inclusion in a GS Database. The proof of inclusion in a GS database is referred to as an overlay proof.

[0068] • User Access Management: manage user services, such as verifying that users are authorized to create and access data. GSs communicate to interested users when the data has been added to the network and provide publication proofs (e.g., SPV proofs and overlay proofs).

[0069] 2.1.2 Government Servers Databases

[0070] GS Databases contain all the information required for a GS to offer its intended governmental services. For each piece of information received, the minimal information to be stored in these databases is:

[0071] • Fingerprint of the information to be recorded (e.g., a document hash).

[0072] • Proof of publication in the blockchain (e.g., SPV proof) - also referred to herein as a "blockchain proof".

[0073] • Proof of inclusion in GOvNet (e.g., overlay proof) - also referred to herein as a "storage proof". Optionally, documents and other pieces of data can be stored in the GS Database, either in plaintext or encrypted. If the document is stored, then GSs can offer data access services (e.g., retrieval of an identity card), otherwise they offer only proof of validity services (e.g., confirmation that a given identity card is legitimate, and not expired or revoked).

[0074] SPV proof

[0075] An SPV proof is a lightweight technique used to prove that a transaction is published on the blockchain. Usually, SPV proofs contain at least the Merkle proof of the transaction and the corresponding block header. The Merkle proof is used to prove that a given transaction is inserted in the block. The validity of the block is verified by checking that the block ID is part of the longest honest chain.

[0076] Overlay proof

[0077] An overlay proof is a proof that some data has been accepted in GOvNet. Overlay proofs may be generated once the fingerprint of the data is added to a Bitcoin block. They may be unforgeable signatures associated to a public key derived from the data. Users can verify overlay proofs independently without relying on GSs.

[0078] 2.1.3 LDAP service for Government Servers

[0079] GSs may only publish data which have been authorized and verified on GOvNet. Multiple authorisation checks and verifications are performed before data publication. A requirement is that the user is authorised to publish content on GOvNet. Other requirements depend on the use-case and include, for example, that the data have been approved by all the relevant parties, e.g., if the data is an electronic document, a government affiliated entity may be required to sign.

[0080] To verify this information, GOvNet may use an LDAP service. GSs query the LDAP services to check if the information they receive is approved and consistent. Users' privacy can be preserved by limiting the access permission of the Government Servers: GSs can check the users' permission without deducing their identity.

[0081] 2.1.4 GOvNet Users Only authorised users can participate in the network. They communicate with GOvNet using a local interface, such as a smartphone app or an internet portal. This service allows them to access GOvNet functionalities once their identity has been verified, this guarantees that only authorised parties interact with GOvNet. Moreover, user access management guarantees data authenticity and non-repudiation.

[0082] GOvNet is designed to ensure that users maintain control of their data. Once uploaded on GOvNet, data can be shared with other users or public entities, guaranteeing data authenticity and consistency, without disclosing non-essential information. The user authorization system may rely on a PKI protocol, using LDAP (Lightweight Directory Access Protocol) to manage user access to information. Users communicate their desire to register to a Registration Authority (RegA), an entity linked to the government. A Certification Authority (CA) checks the user information and grants appropriate level of access to them. Users' authorization can be revoked at any time by legally authorized parties, the revocation request is carried over by the Revocation Authority (RA).

[0083] 2.1.4.1 Account creation

[0084] To access GOvNet, users may need to have an authorised account. During the authorisation process, users are linked to a public key (or set of linked public keys) authorised by the government or another trusted party (e.g., a public administration). These public keys are used to prove the users' identity when communicating with the GSs to publish and retrieve data. Users control the associated private keys.

[0085] An authentication may require a check of the user's documents, and different services can be granted to different users based on their credentials (e.g., a tourist with a visa can still be allowed the use of CBDC, but maybe have restricted access to other network functionalities).

[0086] The steps required to obtain an authorised GOvNet account are as follows:

[0087] 1. Alice connects to a registration terminal (e.g., an app on her smartphone).

[0088] 2. She sends her identification documents (e.g., passport details) to the

[0089] Registration Authority (RegA). 3. The RegA checks her documents and returns the result of the registration process.

[0090] 4. If the process is approved, the RegA informs the Certification Authority (CA).

[0091] 5. The CA creates a PKI registration (e.g., using a blockchain transaction).

[0092] 6. Once the transaction is published, a Merkle proof of the transaction is generated.

[0093] 7. The CA sends the registration transaction ID and its Merkle proof to Alice.

[0094] The process described uses blockchain to record a certificate, but accounts can be created also without blockchain, for example using traditional CAs.

[0095] Registration Authority (RegA)

[0096] A RegA is a government affiliated entity or a delegated entity that has the right and authority to check user information and to decide whether users have the right to participate to the network. There may be multiple RegAs spread across the territory to distribute the workload. Since RegAs have access to users' personal documents and public keys, they have the ability to add data to the LDAP service. RegAs communicate their approval to the CA, who then proceed to create the user's registration transaction.

[0097] Certification Authority

[0098] The CA is an authority that has the power to generate and broadcast registration transactions for users that have been successfully authorized by the RegA. The CA may be a server that communicates with the RegAs or a service maintained by some RegAs. Both solutions have advantages, and the preferred choice should depend on the use case and on the requirements of the maintainer. Having a central CA that communicates with all the RegAs prevents communication delays. Having RegAs maintaining independent CAs grants more independence to RegAs (e.g., to respect the independence of local regions).

[0099] 2.1.4.2 Account revocation

[0100] User accounts can be revoked at any time by authorized government entities following the appropriate legal procedure. Accounts may be revoked for one of at least the following reasons: • The agreed expiry date is reached - it may be required for legal or security purposes that users' authorization expires after a certain period of time. The data linked to an expired address can still be accessed. Once users update their key, they can link their data to the new registered keys.

[0101] • A legal authority requested revocation - if users misbehave, it is possible to enforce an early expiration of their authorization. This can be used, for instance, to freeze the funds of a user that is acting illicitly.

[0102] • The user requested revocation - users have the right to opt out of GOvNet and deregister. User deregistration is not cancelling all user's information since they are still liable for their behaviour.

[0103] The revocation process may be as follows:

[0104] 1. An appropriate entity notifies the revocation authority about the revocation of a user authorization.

[0105] 2. The revocation authority (RA) spends the registration PKI transaction, which revokes the user authorisation.

[0106] The RA has a role that is synonymous to the CA's role, and the two can coincide. The CA does not destroy information on the users' public keys, it only removes the permission to use those keys to publish new data. After the revocation, users still control their keys, but they cannot broadcast new data using those keys.

[0107] 2.1.4.3 LDAP service for Users

[0108] Users have access to the LDAP service to check information about other entities in the network. Generally, their level of access is more limited than the access of GSs. Some of the queries they are allowed to run are the following:

[0109] Retrieve the public keys of a public entity.

[0110] Check if a given public key corresponds to a certain user.

[0111] Check if a given public key has a certain level of authorization. The LDAP service may be used when the user connects to the user's terminal to access GOvNet. A password can be used as a quick way to verify users' identity.

[0112] 2.1.4.4 User interface

[0113] The user interface should improve the user experience when interacting with GOvNet. This may be achieved using a dedicated smartphone applications or web portals.

[0114] The smartphone application can store users' information and grant the user a more intuitive interface to use GOvNet. This includes, distributing user data, verifying other users' data and querying the LDAP service. The app can securely store user information and receive network updates.

[0115] A web platform may be deployed to facilitate interaction from a computer. User's sessions on the platform can be authenticated using the smartphone application or equivalent techniques.

[0116] 2.2 Data management

[0117] Data such as documents to be published on GOvNet may be converted to a predefined data structure accepted by GSs, called a data packet. GSs are responsible for filtering and verifying incoming data packets and broadcasting them to other GSs.

[0118] GSs guarantee data integrity and timestamping of data packets by publishing an obfuscated version of them to a public blockchain. These anonymised packets are called fingerprint transactions.

[0119] 2.2.1 Data packets

[0120] Data circulates in GOvNet in the form of data packets. Data packets can provide support for different services, for example document sharing and CBDC. Data packets in the overlay network are linked to fingerprint transactions published on a public blockchain.

[0121] Fingerprint transactions may not contain the data packet in its plaintext form, but its fingerprint (e.g., a hash). The fingerprint is enough to ensure that the data packet is linked to the transaction published on the blockchain, guaranteeing the privacy of the parties involved at the same time. To determine which transactions in the blockchain are fingerprint transaction, several techniques can be used. An efficient way to achieve this is by using transaction versioning, either in clear form or using versioning puzzles (see Section 0).

[0122] 2.2.2 Transaction versioning

[0123] Transaction versioning refers to a technique where the opcode OP_VER may be used in the locking script to create transactions that can be spent in multiple predefined ways. UK patent application GB2308931.1 describes the use of OP_VER (and equivalent opcodes or functions) for such transaction version. The contents of GB2308931.1 are incorporated herein in entirety. One or more ways to spend a transaction are included in a locking script, the version chosen is chosen when the transaction is spent, by selecting a specific transaction version. Here the version refers to the transaction version specified in the transaction header of the spending transaction. OP_VER allows for a locking script to enforce its spending transaction to have a particular version number or a version number from a given set.

[0124] When a transaction is serialised, the version number is at the beginning of the serialisation. It allows for GSs to efficiently interpret a transaction, without fully parsing the transaction. All transactions in the overlay network can share the same version, or different services can have different versions (e.g., version 1 implies registry office documents, version 2 implies CBDC payment). Any device can determine if a transaction is of interest for them by simply checking the first bytes of a serialised transaction, this provides a more efficient way to interpret a transaction than using any other types of flags.

[0125] Finally, OP_VER can be used to filter transactions. However, this is subject to spoofing attack where adversary can freely set their transactions to the same version number as the attacked version. Nonetheless, using OP_VER is better than filtering through all transactions.

[0126] 2.2.3 Data packets creation

[0127] Data packets are created by users or public entities when they want to publish data on GOvNet. Data are formatted according to the predefined data packet structure. Different types of data packet follow different formatting rules and contains different types of data. In the example of a document being uploaded, the information in the data packet includes the document, its type, and its fingerprint (e.g., hash). If the document is confidential, only the fingerprint is added. If the document requires one or more signatures (e.g., a driving licence may require be published by a licensing agency, with the driver signature), a digital copy needs to be sent to the relevant parties to be signed. All the collected signatures are added to the data packet.

[0128] The process for creating a data packet is shown in Figure 5:

[0129] 1. Alice sends the data to the other parties that may need to sign it.

[0130] 2. Once all the signatures are collected, the information is grouped together in the data packets.

[0131] 2.2.4 Data packet submission

[0132] Users with an authorised account can publish data packets on GOvNet. When GSs receive data packets, they check their syntax, the user's authorization level, and additional signatures (if there are any). After this verification, GSs send the data packet to other GSs.

[0133] Once the above steps have been completed, GSs create the fingerprint transaction and broadcast it to the blockchain. The data packet is consolidated once its fingerprint had been added to a block. After consolidation, the overlay proof (i.e., the proof of inclusion in the overlay network) is sent to users.

[0134] The data packet submission process is summarized in Figure 6:

[0135] 1. Alice sends the data packet to GOvNet.

[0136] 2. GOvNet checks data packet validity: a. Consistency check. GOvNet verifies that the data packet is consistent with the overlay network requirements, and it represents a valid type of data packet. b. Authorization of Alice. If Alice doesn't have the required authorisation, the process stops, and the data packet is not published (e.g. stored on the overlay network). c. Signature verification. GOvNet checks signature validity and their consistency with the type of data packet. If the signatures do not match the requirements, the data packet is not published.

[0137] 3. GOvNet publishes a fingerprint transaction associated to the data packet to the blockchain.

[0138] 4. GOvNet receives a proof of publication (e.g., SPV proof).

[0139] 5. GOvNet's servers provide Alice the proof of publication on the blockchain (i.e., SPV proof) and on GOvNet (i.e., overlay proof).

[0140] The GOvNet checks of Alice's authorization in Step 2b may rely on the LDAP service or include an explicit verification of the PKI registration transaction. In Step 2c, the LDAP service may be used to ensure that all the signatures have been generated by authorized users with the correct permission level.

[0141] 2.2.5 Data packet verification

[0142] The owner of a data packet must be always able to prove to another user or public entity that the data packet has been included in GOvNet. If the data packet is a document-type data packet, they must also be able to prove that the document is legitimate and valid (i.e., not expired or revoked). This requires multiple verifications to ensure that the data packet was not manipulated by the owner of the data packet. Figure 7 describes how Alice can prove to Bob that her document-type data packet had been added to GovNet and verifies its content:

[0143] 1. Alice sends the data packet, the document, the SPV proof, and the overlay proof to Bob.

[0144] 2. Bob checks that the fingerprint transaction published on the blockchain is valid (e.g., it is an unspent transaction) - this ensures that the document is up to date and has not expired.

[0145] 3. Bob checks that the document corresponds to the given data packet and that the data packet matches the fingerprint transaction - this ensures that the information in the data packet is consistent with Alice's claim.

[0146] 4. Bob checks the data packet verification is consistent - this shows that the data packet has been added to GovNet, or at least accepted by GovNet. Step 2, Step 3, and Step 4 focus on different aspects of integrity of the data packet. Step 2 checks only if the information provided is up to date. Step 3 checks the consistency of the documentation provided by Alice. Step 4 checks if the data packet had indeed been added to GovNet. The order of these verification steps is not relevant.

[0147] For different types of data packets, it is possible to follow a similar procedure. For example, if Alice wants to prove to Bob that its CBDC-type data packet had been added to the overlay network, the first step is modified to include information about the CBDC transaction, and the verifications are done on this data.

[0148] 2.2.6 Document retrieval

[0149] Document-type data packet can support document retrieval. Users can require retrieving their own documents or other users' documents (e.g., for verification purposes). Document retrieval is only possible if the document was included in the data packet at the time of creation.

[0150] 1. Documents do not need to be stored by users, they only need to maintain a reference to the document (e.g., a hash or the overlay proof). If the document is required from a user that is not the owner, its authorization is checked and the retrieval is followed by a verification process (Section 0). Document retrieval is generalizable to a broader scope of data packet metadata. The process for retrieving a document is shown in Figure 8.

[0151] 2. Alice sends the overlay proof of the data packet or the hash of the data packet to the GSs.

[0152] 3. The GS looks up the document. a. The GS verifies (e.g. using LDAP) that Alice has the authorisation to retrieve the document. If she's not authorised the process is interrupted. b. The GS looks in the GS database for the data packet that coincide with the hash Alice provided.

[0153] 4. The GS sends Alice the document contained in the data packet, the Merkle proof, and (eventually) the overlay proof. 5. Optionally, Alice verifies the Merkle proof and the overlay proof.

[0154] 2.3 Network topology

[0155] This section describes the role of the various parties involved in GOvNet and how they interact with each other. This section gives more details of some of the topics of the previous sections.

[0156] 2.3.1 Government servers

[0157] GSs maintain the integrity of the overlay network. GSs communicate with each other to ensure that the data in the overlay network are consistent.

[0158] Data packets submitted to GSs go through the following steps.

[0159] 1. GSs check data packet correctness: this includes verifying the user's authorization and consistency of the data packet information.

[0160] 2. GSs broadcast the data packet to other GSs: communication between GSs ensure that the data circulating in the overlay network are consistent (i.e., the GSs share the same view of the overlay network).

[0161] 3. GSs generate the fingerprint transaction: the GSs create a fingerprint of the data packet and broadcast it to the blockchain.

[0162] 4. GSs consolidate data packet: data packets are consolidated when their fingerprint is added to a blockchain block. Verification information of data packets is generated during this step.

[0163] 5. GSs store the data packet information and share it with users: this includes storing the data packet in the private database and sharing verification information with users.

[0164] 2.3.2 Lightweight Directory Access Protocol

[0165] The LDAP service of the overlay network is an infrastructure which may be maintained by a dedicated LDAP server. The LDAP service provides network information to GSs and users and maintains network functionalities (e.g., users' login). A user interface for common LDAP queries can be implemented in the mobile app and internet portal (e.g., a search bar with filters), while an API can be used to run uncommon queries. GSs run multiple routine queries to check the correctness of each data packet that is sent to them. The type of queries depend on the type of data packet.

[0166] Note that LDAP is merely one example of an authorisation service, and any other suitable authorisation service may be used instead, such as Active Directory, OAuth / AuthO2, Single Sign On, etc.

[0167] A feature of the LDAP service is the protection of privacy, by ensuring appropriate reading rights to each actor accessing the overlay network. For instance, a user can check all his data saved on the LDAP but cannot access other users' personal data freely. Similarly, GSs have the right to check the authorization level of a certain public key but may not be able to learn the identity of the corresponding person or entity. The specific access level of various parties of GOvNet is decided by the government running the overlay network.

[0168] Almost all the parties involved in the overlay network can write onto the LDAP database. For instance, users can add information such as their password or their verified telephone number or email address. The registration authority and the revocation authority can add some of the users' information or delete it. Public entities can link users' documents to their identity and GSs can link data packets to documents. Similar to reading access, the specifics depend on the requirements of the overlay network.

[0169] 2.3.3 Interaction with the blockchain

[0170] Interaction with the blockchain provides the overlay network with data integrity, security, and timestamping. Publishing fingerprint transaction links data packets to a Bitcoin SV transaction. This enables a proof of existence of the data packets and a timestamp on the data. The spending status of fingerprint transactions can be used to represent information on the status of the linked data packet (e.g., a spent fingerprint transaction linked to a document data packet may imply that the document is not valid anymore). Only GSs and involved parties know the content of the data packets in the overlay network. Fingerprint transactions have only an anonymized version of data packets and thus do not leak any information to observers. GSs can be lightweight clients or nodes. In the first case, they are funded by the government to generate fingerprint transactions. In the second case, they may rely on the block reward instead. GSs are likely to be directly connected with the blockchain network, since they have to publish fingerprint transactions, and retrieve and distribute Merkle proofs. Users need not be connected to the blockchain network, as they can trust the GSs to communicate the correct block information and the correct spending status of a fingerprint transaction. If they do not trust GSs, they can still check the information directly on the Bitcoin SV network.

[0171] Block headers are broadcasted by GSs to users. Users save them locally so that they do not need to rely on GSs when checking the Merkle proof of fingerprint transactions.

[0172] Additionally, some GOvNet-specific information (e.g., public data computed during the consolidation step) can be broadcasted to users in the same way. This allows for users to verify data packets without having to query GSs for data. This additional information flow comes with minimal storage cost on the users' side.

[0173] 2.3.4 Users

[0174] Users can interact with the overlay network after registration. The RegA checks the user credentials and determines the appropriate user access level. Interactions with GOvNet are mediated by a user terminal (e.g., a smartphone app or a web portal). This terminal should facilitate the creation of data packets. User registration and revocation can rely on a standard PKI protocol.

[0175] 2.3.5 User Registration

[0176] The complete user registration protocol is as follows:

[0177] 1. Alice requests to join the network through the RegA.

[0178] 2. The RegA asks Alice to provide the documentation to verify her credentials.

[0179] 3. Alice sends her documents to the RegA.

[0180] 4. The RegA determines the right access level for Alice. This determines which functionalities of the network she can use.

[0181] 5. Alice receives her access level.

[0182] 6. Alice generates a private / public key pair. 7. Alice communicates to the RegA her public key.

[0183] 8. The RegA communicates the key and the access level to CA.

[0184] 9. The public key is certified by the CA.

[0185] 10. Optionally, the CA sends the certificate to Alice.

[0186] Some additional remarks are discussed below.

[0187] • Steps 1 to 4 can be modified in such a way that Alice needs to register separately for each different service offered by GOvNet.

[0188] • Step 5 can be just a notification that let Alice know if her request has been accepted or not.

[0189] • Alice's key in Step 6 can be a parent key of an HD wallet branch. When she submits a data packet, she has only to specify which child key of the certified parent key she is using. This ensures that she does not need to reuse keys.

[0190] • In Step 8, the RegA can share the link between the public key and Alice's identity to the CA, or only let the CA know that the key is authorized.

[0191] • In Step 9, the certification can follow a standard PKI protocol or a PKI using blockchain.

[0192] • Access to the network is not limited to individuals but can be extended to organizations and businesses.

[0193] • GSs can keep track of the verified keys and store them in a database to reduce the number of times they have to check the same key.

[0194] Traditional PKI

[0195] In traditional PKI, a user's key is certified by the CA, where the certificate contains a signature by the CA over the user's public key. GSs check this signature by the CA and verify with the RA whether the key has been revoked each time a data packet is submitted.

[0196] PKI using blockchain

[0197] If the PKI utilises blockchain, the CA creates a registration transaction on the blockchain containing the user's key or it's fingerprint (e.g., a hash). Users show their authorization to participate in GOvNet by showing the registration transaction. GSs checks that the T1 registration transaction had been issued by the CA and determines its spent status. The user's key is deemed still valid if the registration transaction is unspent.

[0198] 2.3.6 User Revocation

[0199] User authorizations can be revoked. There are multiple revocation reasons, such as data leaks, user misbehaviour, or expiration of the authorization, and there may be multiple entities that can revoke a key. For example, law enforcement, the CA, or the user may be able to revoke a key.

[0200] The RA receives revocation requests and removes the authorization from public keys if the request is deemed valid. Request validity may depend on the authority of the requestor and the purpose of the revocation. The revocation protocol depends on the PKI protocol version used.

[0201] The revocation does not need to be permanent. It is possible to temporarily prevent users from participating to the network. Temporary revocation is called suspension and can be implemented as a full revocation followed by an automated registration after the suspension time has passed.

[0202] Traditional PKI

[0203] The RA publishes and broadcasts a frequently updated revocation database that informs GSs of all the revoked public keys. This database must be updated frequently. The LDAP service grant GSs access to the revocation information, including the time of the revocation. Therefore, even if a data packet is fingerprinted before the revocation has been broadcast, it is still possible to invalidate the data packet before consolidation.

[0204] PKI using blockchain

[0205] To revoke a key, the RA simply spends the user registration transaction. GSs can check the spending status of the user registration transaction to prevents data packets being received by revoked keys.

[0206] 2.3.7 Keys recovery services It is possible to provide users with key recovery options. A PKI recovery method (e.g., key escrow) can be used. It is possible to opt out of this service.

[0207] 2.4 Data packets lifecycle

[0208] This section describes the different types of data packets, their lifecycle, and their fingerprint transactions. Data packets are generated by users, signed by various entities, and approved by GSs. A fingerprint of each data packet exists on the blockchain, but no information on the original data packet can be recovered from those fingerprints. Figure 9 shows the lifecycle of a data packet. For specific types of data packets, there may be additional steps to execute.

[0209] 2.4.1 Data packet creation

[0210] Data packets are created by users and broadcast to the overlay network once they have been finalized. The steps taken to create a data packet depend on the type of data packet. Examples of these steps include compile a data packet template, provide personal information, and collect signatures. Data packets are signed by one or more entities or individuals to ensure their validity. The number of signatures required, and the identity and authority level of the signers can change between data packets, even if the data packets are of the same type.

[0211] One of the main uses of the users' terminal is to facilitate users to create data packets, particularly ensuring that the data packets respect the correct syntax. In principle, users may be allowed to send data packets via an API. While there is nothing wrong with this approach, it exposes users to the creation of data packets having an incorrect format. In the rest of the section, it is assumed that users rely on their terminal (e.g., a smartphone app or web portal) to generate data packets. The data packet generation flow is described Figure 10:

[0212] 1. Alice selects the type of data packet she wants to generate.

[0213] 2. The terminal provides the data packet template.

[0214] 3. Alice completes the template providing her required personal information.

[0215] 4. The terminal establishes secure communication channels to collect signatures (if needed) and requests the signatures to the relevant parties. 5. The signing parties verify the supporting data provided by Alice and add their signature.

[0216] The protocol can be adapted to support various design choices. For instance, the selection of data packet type can be implemented in a user-friendly way relying on search bars or filters. Steps 4 and 5 are not required for all types of data packets.

[0217] After data packets are created, they are submitted to the GSs. Data packets can be submitted by one of the signers, the owner, or the terminal. The submission policy can depend on the type of data packet (e.g., an identity document must be submitted by a governmental agency).

[0218] 2.4.2 Data packet correctness

[0219] Data packets are checked for correctness before they start circulating in the overlay network. The correctness of a data packet is determined by multiple independent checks.

[0220] • The data packet is of a valid type: this check ensures that the data packet is of a type that is recognized by the network. Different types of data packets may follow different requirements and syntax.

[0221] • The data packet is complete and consistent: once the type of data packet is determined, it is necessary to check that it contains all the information required, that those information follows the correct syntax, and that the data are consistent with each other.

[0222] • The author of the data packet has the right authorization level: if the data packet is complete, it is important to ensure that the owner of the data packet has the correct authorization level to submit it. This verification can either rely on the LDAP service or on the user providing a link to the registration transaction.

[0223] • The correct entities have signed the data packet: some types of data packets require signatures from different parties, and these parties need to be authorized and certified to sign such a data packet. GSs checks rely on the LDAP service to certify the identity and the level of authority of the signers. The LDAP permissions of GSs may prevent them from checking the identity of citizens, but still allow them to identify public institutions or companies. The order of these checks is flexible and can be modified according to the needs of the network.

[0224] 2.4.3 Broadcasting data packets

[0225] Data packets that have passed the correctness check are broadcasted to other GSs. The aim of the broadcasting is to ensure that all the relevant GSs are notified of its creation and can store it in their GS database. Depending on the architecture of the network, this can work in various ways. There are two factors to consider. The first factor is the data that GSs store in their databases, the second factor is how GOvNet services are distributed amongst GSs, i.e., do they all maintain all services, or does each focus on a subset. Some different situations are discussed in the list below:

[0226] • Exactly one GS maintains any service, and the GS database stores only data packets related to that service. In this case, GS are essentially independent from each other and there is no need to broadcast information to the other servers except for archive purposes. A single GS may maintain multiple different services.

[0227] • Exactly one GS maintains any service, but the GS database stores all data packets in GOvNet (also the ones not relating to the maintained service). In this case, broadcasting is necessary, but it is only for informative purposes. It can be done using secure communication channel between GSs. A single GS may maintain multiple different services.

[0228] • Multiple (or all) GSs maintain a given service. In this case, data packets need to be shared to each relevant GSs to confirm that there are no conflicts, i.e., it is not a duplicate and there are no resources that were used multiple times. If the GS database is distributed across GSs, there are various types of distributed SQL and NoSQL database implementations that can be suitable to achieve this result. Additionally, it is necessary to define a priority system to generate fingerprint transactions (e.g., the GS that verified the data packet broadcast the fingerprint transactions) and a protocol to deal with offline GSs (e.g., the data packet is missed, and the GS can recover the information once they are back online). Hybrid situations. Clusters of GSs may deal with multiple services, but not with all of them. The previous cases easily generalize to this situation.

[0229] 2.4.4 Fingerprint transactions

[0230] Fingerprint transactions are P2PKH dust transactions that store a salted hash of the corresponding data packet. Fingerprint transactions are easily recovered by GSs but may not be identifiable by any external party. From the fingerprint transaction is not possible to recover the underlying data packet.

[0231] Since the fingerprint transaction is a dust transaction, its cost is minimal. Since it is linked to the data packet only via a salted hash, it is impossible to deduce the data packet from the fingerprint transaction, but any party that knows the data packet can link the two. The salt can be created in a deterministic way using a secret sharing scheme between the GSs and the owner of the data packet.

[0232] When new blocks are created, a GS does not need to search for the fingerprint transactions he broadcasted (he receives their Merkle proof), and he does not need any additional information to identify them. However, other GSs need either to scan the block to identify them or wait for the first GS to share them. They may need to be able to easily identify them, some of the approaches to achieve this are discussed below.

[0233] Public identifier

[0234] The overlay network can choose a public network identifier. Clients filter transactions that have the correct format and identifier. The network identifier can be stored as data after OP_RETURN or using the transaction version field. The latter allows for identification of fingerprint transactions by checking only the first 4 bytes of the transaction.

[0235] This approach is simple to implement and allows for fast identification but exposes the network to DoS attacks where the attacker creates many fake fingerprint transactions. The attacker is not able to falsify data packets, the clients will spend time and resources discarding false data packets.

[0236] Identifier obfuscation It is possible that the institution supporting the overlay network desires a higher level of privacy for their transaction. More specifically, this institution may want to ensure not only that the data packet is not recoverable from the fingerprint transaction, but also that no external observer has a way to understand which blockchain transactions fingerprint transactions and which are not. Clearly, the previous type of identifier is not suitable for this job, as the version number of the transaction is revealing the overlay network the fingerprint belongs to. We discuss how this identifier can be obfuscated.

[0237] Assume that the overlay network has a private network identifier I, which is known only by the GSs. The fingerprint transaction linked to the data packet D has a transaction version value V, and stores the hash of the data packet H D). The identifier can be obfuscated by saving in the fingerprint transaction also the obfuscated identifier *

[0238] 7), where * is a fixed function (e.g., concatenation or addition).

[0239] Given a transaction that has the syntax of a fingerprint transaction, GSs can verify easily if it is indeed a fingerprint transaction relative to their network. GSs communicate the value

[0240] * / ) to the user that owns the data packet to allow for verification of the fingerprint transaction, but this is not disclosing any information on the private identifier I. The value of the outermost hash function depends also on so that the user can verify that is linked to its data packet. GSs and users that know the value * / ) can verify the fingerprint transaction is linked to the data packet D.

[0241] The transaction version V does not need to be included in the obfuscated identifier, however, including it may have some benefits, especially if the GSs may want to scan blocks to find fingerprint transactions (despite this is not recommended, see Section 0). For instance, GSs may choose to use a transaction version V (or a set of possible transaction versions) that is used by other services in the ecosystem. This allow for blocks to be filtered by transaction version but does not inform any observers on which transactions are GOvNet fingerprint transaction.

[0242] 2.4.5 Data packet consolidations A data packet is consolidated if the data packet fingerprint transaction had been included in a BSV block. This section describes how consolidation works. A high-level description of the process is shown in Figure 11:

[0243] 1. A blockchain node generates a new block.

[0244] 2. The GSs extract fingerprint transactions from the newly generated block (or from a certain prior block).

[0245] 3. GSs share their fingerprint transactions with other GSs.

[0246] 4. GSs generate an elliptic curve block point.

[0247] 5. GSs create the overlay proof for the corresponding data packets.

[0248] 6. GSs share the overlay proof of the data packet with the users.

[0249] 7. GSs share the SPV proof of the fingerprint transaction with the users.

[0250] 8. The users check that the overlay proof and the SPV proof are correct.

[0251] In Step 2, GSs can easily retrieve which of their own fingerprint transactions are in new block, however, they would need to scan the block to find fingerprints from other GSs. Thus, Step 3 may not be necessary, but it greatly simplify the work of GSs. Indeed, scanning the entire block, while it is always a possible way to retrieve fingerprint transaction is computationally intensive and alternative solutions should be preferred.

[0252] GSs agreement and block point creation

[0253] The process to ensure that the GSs agrees on the fingerprint transactions included in a blockchain block and compute the same block point is described in Figure 12:

[0254] 1. GSs extract all the fingerprint transactions from the block B.

[0255] 2. GSs determine the data packets corresponding to the extracted fingerprints.

[0256] 3. GSs hash the data packets.

[0257] 4. GSs compute SB, the sum of these hashes.

[0258] 5. GSs compute the elliptic curve point SBG, where G is the generator of the curve.

[0259] 6. GSs check that they have all computed the same point SBG. If they do not agree, they check the set of fingerprints to find the discrepancy.

[0260] 7. GSs add the salt point sG to SBG. The resulting point PB= SBG + sG is called the block point, the associated private key is KB= SB+ s. 8. GSs publish the overlay block header, e.g, on GOvNet.

[0261] Some additional remarks on the described protocol are:

[0262] • It is possible that the fingerprint extraction process is carried out by a single GS. In this case, there is no need to reach agreement on the block point.

[0263] • In Step 1, GSs do not need to scan the entire block to find the fingerprint transactions, they can just wait for each GS to communicate their own fingerprint added to the block.

[0264] • The block point is salted to ensure that users are not able to collude to deduce the associated private key.

[0265] • The salt value s is deterministic (e.g., it can be the hash of a shared secret concatenated with the header of the block B).

[0266] • The block point is salted to ensure that users are not able to collude to deduce the associated private key.

[0267] • The block point is saved in an appropriate column in the GS database and published on a secure platform or sent to users. Assuming the secp256kl curve is used, this amount to less than 5KB of data per day.

[0268] • If each GS takes care of different services of GOvNet, the protocol can be modified so that each GS computes its own salted block point. Eventually, the final block point can be the sum all the individual block points. It is also possible to maintain a different block point for each service.

[0269] • The overlay block header contains the block point PBand the block header.

[0270] • The overlay block header can be broadcasted to all the users of GOvNet.

[0271] Overlay proof creation

[0272] The overlay proof of a data packet is a signature associated to a public key that depends on the data packet and on the Bitcoin SV block that contains its fingerprint. The signature scheme used can be any elliptic curve digital signature scheme (e.g., ECDSA or EdDSA).

[0273] The overlay proof of a data packet D included in the block B is generated by the GSs. The private key associated to the data packet is the value KD= SB+ s — The overlay proof is a signature SigK(O'). GSs send the overlay proof to users together with a reference to the block point. Users can check the correctness of the overlay proof by checking that Sigl<DD) is a valid signature for the point PB— H(D)G. Users do not know the private key associated to the signature SigKD(D).

[0274] 2.4.6 Data packet storage

[0275] Data packets are stored in the databases of the relevant GSs. The GS database can be a distributed database or multiple databases, each maintained by some GSs. In the former case, some (possibly all) GSs have writing privilege, but reading privilege may be limited to their own entries; this may be a strict requirement when different GSs deal with different types of data packets. The advantage of a distributed database is that this automatically ensures synchronization of the data and resolution of conflict. Multiple independent databases can be a suitable design choice when there is a need to separate different services offered by GOvNet.

[0276] There is some information about the data packet that is required to be stored, while other information can be optional and depend on the architecture. The necessary information is the data packet, its overlay proof, the fingerprint transaction, and its SPV proof. Optionally, metadata can be stored to aid querying the database. The metadata can include redundant information that is already contained in some of the mandatory fields, e.g., the public key used or the type of data packet. It is possible to allow the storage of entire documents (either in plaintext or encrypted). In this case, the GS database provides data access services. Otherwise, they only offer proof of validity of documents.

[0277] 2.4.7 Data packet verification

[0278] This section discusses how users interact with each other to prove that a data packet has been added to the overlay network. Some checks apply to all data types, while others are dependent on the type of data packet. For example, if the data packet is a documentcreation data packet, then it is required to check that the document matches the document given in the data packet and that it is not expired.

[0279] This section focuses on agnostic checks. These are the verification of the overlay proof and of the Merkle proof of the data packet. The overlay proof is a proof of consolidation of a data packet in the overlay network. Figure 13 describes a typical interaction between two users, where Bob wants to check the overlay proof of one of Alice's data packets:

[0280] 1. Bob asks Alice the overlay proof of her data (e.g., Alice's personal information).

[0281] 2. Alice sends the data packet D with the overlay proof SigK[)(D to Bob.

[0282] 3. Bob checks that D is owned by Alice. The LDAP can be used to retrieve this information.

[0283] 4. Bob computes the point H D)G and the point PB— H D)G, where G is the generator of the curve.

[0284] 5. Bob verifies that SigK[)(D is compatible with the point PB— H D)G.

[0285] 2.5 Use cases

[0286] This section focuses on specific types of data packets, and how the steps we described in the previous sections are applied in these situations.

[0287] 2.5.1 Document-type data packet

[0288] Document-type data packet (or document data packet for short) is an umbrella term that covers a broad range of data packet types that are related to document creation, publication, and updates. Different types of documents require different types of interactions between parties and may have different structures. Some common features this type of data packets share are.

[0289] • Expiry dates: Documents may expire after a certain amount of time, or if certain conditions have not been followed.

[0290] • Document versioning: Documents may need to be modified over time e.g., housing registry data.

[0291] • Multiple signatures: Documents may need to be signed by multiple parties, and sometimes these signatures must be created in a specific order.

[0292] • Redactable content: Documents such as contracts may be required to be redactable, allowing for selective disclosure of the data contained within.

[0293] 2.5.1.1 Document-type data packet information This section describes the minimal information that a document data packet should contain to be complete and valid. Some complementary and optional metadata can be provided to the GSs, for verification purposes. The data packet required metadata (if any) and supporting information (e.g., the overlay proof) are then stored in the GS databases. Mandatory data include:

[0294] • The document data packet flag, which identifies the data packet as a data packet containing a document.

[0295] • The document sub-flag, which describes the type of document the data packet contains. The document sub-flag describes the structure of the rest of the data packet and the verification policy.

[0296] • The hash of the document. The document can be hashed so that it is possible to redact parts of the document.

[0297] • The associated signatures. Signatures should present a reference to which parts of the document they are referring to. For instance, some signers may validate not only the hash of the document, but also some of the signatures already generated.

[0298] More information that can be added to these data can be:

[0299] • The entire document in clear format. This is especially useful if the GS databases provide an archive solution to recover documents.

[0300] • Information on the signers. These data are not necessary, as the LDAP service can be used to deduce the information but providing this can reduce the computational burden for the GSs.

[0301] • Data packet references for supporting documents. This type of information may be required when updating documents.

[0302] 2.5.1.2 Incomplete document data packets

[0303] Document data packets are complete if they are valid documents with all the required signatures, while incomplete documents are missing some of the signatures. Document data packets submitted to GOvNet do not need to be completed. There are multiple reasons why this behaviour should be allowed: users may not know which authorities are required for certain documents, or users may need a proof that they started the correct bureaucracy for a document and are just waiting for the authorities to confirm their information. Thus, generating a completed document data packet may pass through various intermediate incomplete document data packets, each adding one or more signatures.

[0304] The fact that a document data packet is incomplete can be signalled by an appropriate flag. Except for the flag, incomplete document data packets are just data packets like any other, so their lifecycle follows the same steps. If a document data packet is incomplete, it is possible to create a fingerprint transaction that has multiple spendable outputs. In this way, spending the first input signals that the document has been received by the first signing party, spending the second input signals that has been approved by the second signing party, and so on. Once all signatures have been collected, and the corresponding incomplete data packet fingerprint transactions are spent, the user receives a data packet with the valid document.

[0305] The chain of incomplete data packets generated for a document depends on the type of document, accordingly to GOvNet policy. The fingerprint transaction associated to incomplete data packet is not different from a regular fingerprint transaction.

[0306] 2.5.1.3 Creating document data packets

[0307] In this section, we describe the creation of documents data packets. As discussed in the previous section, before a document is valid, it can go through this process multiple times. The main difference with respect to the standard data packet creation is one additional step to check that the new document is not in conflict with (or a duplicate of) an old document. There may be multiple ways two documents can conflict, e.g., two unique identity documents linked to the same user. In this instance, we focus on the internal consistency of GOvNet. Other types of conflict are checked by authorities during the signing process.

[0308] Figure 14 shows an example flow of document data packet creation

[0309] 1. Alice initiates the data packet creation on the terminal.

[0310] 2. The terminal generates the document data packet template requested by Alice. 3. The terminal distributes the data packet template to third parties who sign the template.

[0311] 4. Once the signatures have been collected, the completed data packet is sent to GOvNet.

[0312] 5. GOvNet check with the LDAP service that the document is not conflicting with other documents.

[0313] 6. GOvNet proceed with the routine correctness check on the document.

[0314] If the data packet conflicts with older data packets, the new data packet is bounced back to Alice. She can decide to update the old data packet instead or withdraw her submission.

[0315] While honest mistakes should not be punished, users that maliciously repeatedly made this mistake can be suspended, or their authorization can be revoked.

[0316] 2.5.1.4 Updating a document

[0317] An updated document contains a reference to a data packet of a previous version of a document. Its fingerprint transaction can be spent and authorities verify that the content of the old and new version of the document is consistent. Once the data packet has been completed and checked by GSs, the old fingerprint transaction is spent, and the new fingerprint transaction is generated.

[0318] While it is helpful if users provide references to the document they want to update, it is not necessary to do so, since the document can be retrieved by querying the LDAP server. If the LDAP server maintains data on the type of active documents of a user, the new data packet can replace the old data packet, or the new data packet can be added to a commitment chain. The advantage of a chain of data packets is that if the expired document is referred to in some other part of the network, a link to the most recent version can be found. The main disadvantage is the increase in storage requirements.

[0319] 2.5.1.5 Validity of documents

[0320] A common user interaction is the check of the validity of another user's document. This is essentially data packet verification with some case-specific modifications. Following the discussion above, document data packets are verified in three independent steps: • verify using the overlay proof that the data packet has been added to the overlay network,

[0321] • ensure that the spending status of the fingerprint transaction shows that the document is still valid; and

[0322] • prove that the data packet contains the document being considered.

[0323] The spending status of one or more outputs in the fingerprint transaction can be used to provide updates on the document status. The number of outputs in the fingerprint transaction and the meaning of their spent status depends on the type of document.

[0324] The final step of the validity check involves the verification that the document and the data packet are consistent with each other. If the proving party shares the entire document, then the verifying party has only to hash the entire document and check that it coincides with the hash of the document saved in the data packet.

[0325] However, the owner of the document may prefer to share only some partial relevant information to the verifier. Selective disclosure of documents is discussed in UK patent application GB2307275.4, the contents of which are incorporated herein in entirety. The techniques disclosed in GB2307275.4 paper can be summarised as follows: instead of hashing the entire document, different pieces of the document are hashed and considered the leaves of a Merkle tree, the root of the tree is the data that is contained in the data packet. If the owner of the document saved a fingerprint of the document using this procedure, they are now able to disclose only parts of the document and a Merkle proof to prevent leaks of their data.

[0326] 2.5.2 CBDC-type data packet

[0327] A government overlay network provides a natural framework to implement CBDC. CBDC transactions are just a type of data packet, and CBDC transactions can be implemented ensuring that they share the same properties as cash transactions. GOvNet is agnostic to the design choices regarding the CBDC system. CBDC-type data packets have a lifecycle similar to the lifecycle of document-type data packets, with the main difference being the check for correctness. Indeed, the correctness of a CBDC data packet also includes a check that the spending party owns enough asset to support the transaction.

[0328] Spending the fingerprint transaction associated to a CBDC-type data packet can be used as a means for the paid party to acknowledge they received the payment.

[0329] 2.5.3 Tax reporting and licensing

[0330] Embodiments of the present disclosure may be used to store tax-related data. For instance, companies and / or individuals may use GOvNet to file tax returns, submit invoices, provide evidence of tax payments, etc. For individuals, GOvNet may perform checks to ensure that the tax-related data satisfies certain criteria. For example, a user submitting a tax return may be required to provide entries for different types of taxable income: salary, bonuses, dividends, investment returns, rent, etc.

[0331] Similarly, the overlay network may be used for recording licenses. For instance, a node of the network may specialise in recording television licences, or business licenses (e.g. licenses to trade certain goods). A business may use a storage proof of their license to prove to regulators and the like that they have indeed been granted a license. Other types of licenses may be stored on the network, such as intellectual property licenses. The overlay servers may verify that a license for the same piece of IP has not already been granted (in the case of exclusive licenses, at least).

[0332] 2.5.4 Land and vehicle registries

[0333] The overlay network may be used to store data related to ownership of land and / or vehicles and any change in said ownership. For instance, each data packet may contain a separate land or vehicle registration, or a transfer of ownership of a piece of land or vehicle. GOvNet may perform validation steps, e.g. to ensure that a piece of land is not being (inadvertently or fraudulently) sold twice. To do so GOvNet may verify that the same land is not already on the overlay network indicated as being owned by someone else. A user may use the proof of inclusion (storage proof) to verify that a seller of land or vehicle is the rightful owner of that land / vehicle. 2.5.5 Document proofs

[0334] GOvNet may also be used to prove something about a document (e.g. that a document exists, or that a document contains certain data or fulfils certain requirements) without revealing the document itself.

[0335] In the example of age check to a venue (such a pub, night club, etc.), one might what to prove they are over 18 without revealing their actual age or any other information which happens to be included on their ID document. In this context, one could give an overlay proof at the entrance to the venue, the security may use the proof to check with GOvNet that GOvNet has accepted the document and GOvNet may confirm that the user is over 18, without revealing any details. Since the security staff trust GOvNet, there is no need for any additional checks. Other similar uses cases include visas that permit the owner to enter a country.

[0336] 3. EXAMPLE SYSTEM OVERVIEW

[0337] A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below.

[0338] Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.

[0339] The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data.

[0340] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of 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.

[0341] In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be 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 not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0342] An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

[0343] Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.

[0344] Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. 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 comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive.

[0345] The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.

[0346] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.

[0347] In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

[0348] Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0349] The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.

[0350] 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, 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, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations.

[0351] Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. 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 recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104).

[0352] Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the 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 equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is 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.

[0353] The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer 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 computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

[0354] The client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. 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 a removable optical drive, etc.

[0355] The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0356] Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

[0357] The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing 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 the nodes 104 in the network 106.

[0358] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

[0359] Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are 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 that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0360] 4. UTXO-BASED MODEL

[0361] Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

[0362] 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), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.

[0363] Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled " TxT. It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “ Txo" in Figure 2. TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0364] The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent 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. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour. One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

[0365] The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.

[0366] So in the example illustrated, UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0367] When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria).

[0368] Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain.

[0369] Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

[0370] The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

[0371] 5. FURTHER REMARKS

[0372] Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims. For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and 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 by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.

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

[0374] In other embodiments of the 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, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0375] Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104. Some embodiments have been described in terms of the 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 particular example, proof- of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator.

[0376] It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements.

[0377] Statement 1. A computer-implemented method of storing data, wherein the method is performed by a storage provider, wherein the storage provider is an entity other than a blockchain node, and wherein the method comprises: receiving a request, from a first user, to store a data item; submitting a commitment transaction to one or more blockchain nodes of a blockchain network and / or causing the commitment transaction to be recorded on the blockchain, wherein the commitment transaction comprises a commitment of the data item; storing and / or publishing the data item and / or the commitment of the data item; and providing, to the first user, a storage proof, the storage proof being generated in response to the commitment transaction being submitted to the one or more blockchain nodes and as a function of the data item, the storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage. The storage proof is not a proof of the commitment transaction being recorded on the blockchain. For example, the storage proof is not an SPV proof. Moreover, the storage proof is not a function of the commitment transaction.

[0378] Statement 2. The method of statement 1, comprising providing, to the first user, a blockchain proof proving that the commitment transaction has been recorded on the blockchain;

[0379] Statement 3. The method of statement 2, wherein the blockchain proof comprises a simplified payment verification (SPV) proof.

[0380] Statement 4. The method of any preceding statement, wherein the storage proof comprises a digital signature generated based on the data item and / or the commitment of the data item and verifiable using a public key associated with and / or generated by the storage provider.

[0381] Statement 5. The method of any preceding statement, wherein the commitment of the data item comprises a hash of at least the data item.

[0382] Statement 6. The method of statement 5, wherein the commitment of the data item comprises a hash of at least the data item and a salt.

[0383] Statement 7. The method of any preceding statement, wherein the commitment of the data item comprises an encrypted version of the data item.

[0384] Statement 8. The method of any preceding statement, wherein the storage provider is one of a plurality of storage providers maintaining a storage network, and wherein the method comprises sending the data item and / or the commitment of the data item to one, some or all of the plurality of storage providers.

[0385] Statement 9. The method of statement 8, wherein the storage network is associated with an identifier, and wherein the commitment transaction comprises the identifier or an obfuscated version of the identifier generated based on a hash of at least the identifier and the commitment of the data item.

[0386] Statement 10. The method of any preceding statement, wherein the commitment transaction comprises a transaction version number associated with the storage network.

[0387] Statement 11. The method of statement 9 and statement 10, wherein the obfuscated version of the identifier is generated based on the transaction version number of the commitment transaction.

[0388] Statement 12. The method of statements 10 or any statement dependent thereon, comprising providing, to the first user, at least one of: the identifier, the obfuscated version of the identifier and / or information for computing the identifier and / or the obfuscated version.

[0389] Statement 13. The method of any preceding statement, wherein the data item and / or the commitment of the data item is stored in an internal database and / or a distributed database.

[0390] Statement 14. The method of any preceding statement, comprising verifying that the first user is authorised to request the data item to be stored by the storage provider, and wherein said submitting and / or said storing is conditional on said verification.

[0391] Statement 15. The method of statement 14, wherein said verifying comprising verifying the first user is associated with an authorised public key.

[0392] Statement 16. The method of any preceding statement, comprising verifying the data item has a predefined structure, and wherein said submitting and / or said storing is conditional on said verification. Statement 17. The method of any preceding statement, comprising verifying that the data item is signed by one or more predetermined parties, wherein said submitting and / or said storing is conditional on said verification.

[0393] Statement 18. The method of any preceding statement, wherein the storage provider is associated with a particular type of data and / or data application, and wherein the method comprises verifying that the data item is of the particular type and / or application, wherein said submitting and / or said storing is conditional on said verification.

[0394] Statement 19. The method of any preceding statement, comprising sending the data item and / or the commitment of the data item to a different user.

[0395] Statement 20. The method of statement 8 or statement 19, wherein said sending is in response to a request for the data item and / or the commitment of the data item, wherein said request comprises the storage proof, and wherein the method comprises using the storage proof to identify the data item and / or the commitment of the data item.

[0396] Statement 21. The method of any preceding statement, comprising: generate an elliptic curve block point, said generating comprises: hashing one or more respective data items to generate one or more respective hashed data items, summing the respective hashed data items to generate a summed value, computing a first elliptic curve point based on the summed value and, wherein the elliptic curve block point is based on the first elliptic curve point; and wherein the storage proof comprises a signature generated with a respective private key based on the summed value, and the respective hashed data item;

[0397] Statement 22. The method of statement 21, wherein generating the elliptic curve block point comprises generating a second elliptic curve based on a salt value, wherein the elliptic curve point is based on the second elliptic curve point, and wherein the storage proof comprises the salt value. Statement 23. The method of any preceding statement, comprising: validating the commitment transaction according to one or more rules of a blockchain protocol, wherein said submitting of the commitment transaction to the one or more blockchain nodes and / or said causing of the commitment transaction to be recorded on the blockchain is conditional on said validating of the commitment transaction.

[0398] Statement 24. A computer-implemented method performed by a first user and comprising: sending a data item to a storage provider; receiving, from the storage provider, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0399] Statement 25. The method of statement 24, comprising receiving, from the storage provider, a blockchain proof proving that a commitment transaction comprising a commitment of the data item has been recorded on the blockchain.

[0400] Statement 26. The method of statement 24 or statement 25, comprising: using the storage proof to verify that the data item and / or the commitment of the data item has been accepted by the storage provider for storage and / or sending the storage proof to the second user for verifying that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0401] Statement 27. The method of statement 25 or any statement dependent thereon, comprising using the blockchain proof to verify that the commitment transaction has been recorded on the blockchain and / or sending the blockchain proof to a second user for verifying that the commitment transaction has been recorded on the blockchain

[0402] Statement 28. The method of statement 24 or any statement dependent thereon, comprising: verifying that the data item comprised by the commitment transaction matches to the data item sent to the storage provider; and / or verifying that the commitment of the data item comprised by the commitment transaction corresponds to the data item sent to the storage provider.

[0403] Statement 29. The method of any of statements 24 to 28, comprising: obtaining one or more respective signatures from one or more respective predetermined parties; and including the one or more respective signatures as part of the data item prior to sending the data item to the storage provider.

[0404] Statement 30. The method of any of statements 24 to 29, comprising structuring the data item according to a predefined structure prior to sending the data to the storage provider.

[0405] Statement 31. A computer-implemented method performed by a second user and comprising: receiving a data item from a storage provider and / or a first user; receiving, from the storage provider and / or the first user, a blockchain proof proving that a commitment transaction comprising a commitment of the data item has been recorded on the blockchain; receiving, from the storage provider and / or the first user, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage; using the blockchain proof to verify that the commitment transaction has been recorded on the blockchain and / or sending the blockchain proof to a second user for verifying that the commitment transaction has been recorded on the blockchain; and / or using the storage proof to verify that the data item and / or the commitment of the data item has been accepted by the storage provider for storage and / or sending the storage proof to the second user for verifying that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0406] Statement 32. The method of statement 31, comprising: determining a status of the commitment transaction; and determining information regarding the data item based on the status of the commitment transaction.

[0407] Statement 33. The method of statement 32, wherein the information comprises a validity of the data item.

[0408] Statement 34. The method of any of statements 31 to 33, comprising: verifying that the data item comprised by the commitment transaction matches to the data item sent to the storage provider; and / or verifying that the commitment of the data item comprised by the commitment transaction corresponds to the data item sent to the storage provider.

[0409] Statement 35. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 34.

[0410] Statement 36. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 34.

[0411] According to another aspect disclosed herein, there may be provided a method comprising the actions of any combination of the storage provider, the first user and the second user. According to another aspect disclosed herein, there may be provided a system comprising the computer equipment of any combination of the storage provider, the first user and the second user.

Claims

CLAIMS1. A computer-implemented method of storing data, wherein the method is performed by a storage provider, wherein the storage provider is an entity other than a blockchain node, and wherein the method comprises: receiving a request, from a first user, to store a data item; submitting a commitment transaction to one or more blockchain nodes of a blockchain network and / or causing the commitment transaction to be recorded on the blockchain, wherein the commitment transaction comprises a commitment of the data item; storing and / or publishing the data item and / or the commitment of the data item; and providing, to the first user, a storage proof, the storage proof being generated in response to the commitment transaction being submitted to the one or more blockchain nodes and as a function of the data item, the storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

2. The method of claim 1, comprising providing, to the first user, a blockchain proof proving that the commitment transaction has been recorded on the blockchain;3. The method of claim 2, wherein the blockchain proof comprises a simplified payment verification (SPV) proof.

4. The method of any preceding claim, wherein the storage proof comprises a digital signature generated based on the data item and / or the commitment of the data item and verifiable using a public key associated with and / or generated by the storage provider.

5. The method of any preceding claim, wherein the commitment of the data item comprises a hash of at least the data item.

6. The method of claim 5, wherein the commitment of the data item comprises a hash of at least the data item and a salt.

7. The method of any preceding claim, wherein the commitment of the data item comprises an encrypted version of the data item.

8. The method of any preceding claim, wherein the storage provider is one of a plurality of storage providers maintaining a storage network, and wherein the method comprises sending the data item and / or the commitment of the data item to one, some or all of the plurality of storage providers.

9. The method of claim 8, wherein the storage network is associated with an identifier, and wherein the commitment transaction comprises the identifier or an obfuscated version of the identifier generated based on a hash of at least the identifier and the commitment of the data item.

10. The method of any preceding claim, wherein the commitment transaction comprises a transaction version number associated with the storage network.

11. The method of claim 9 and claim 10, wherein the obfuscated version of the identifier is generated based on the transaction version number of the commitment transaction.

12. The method of claims 10 or any claim dependent thereon, comprising providing, to the first user, at least one of: the identifier, the obfuscated version of the identifier and / or information for computing the identifier and / or the obfuscated version.

13. The method of any preceding claim, wherein the data item and / or the commitment of the data item is stored in an internal database and / or a distributed database.

14. The method of any preceding claim, comprising verifying that the first user is authorised to request the data item to be stored by the storage provider, and wherein said submitting and / or said storing is conditional on said verification.

15. The method of claim 14, wherein said verifying comprising verifying the first user is associated with an authorised public key.

16. The method of any preceding claim, comprising verifying the data item has a predefined structure, and wherein said submitting and / or said storing is conditional on said verification.

17. The method of any preceding claim, comprising verifying that the data item is signed by one or more predetermined parties, wherein said submitting and / or said storing is conditional on said verification.

18. The method of any preceding claim, wherein the storage provider is associated with a particular type of data and / or data application, and wherein the method comprises verifying that the data item is of the particular type and / or application, wherein said submitting and / or said storing is conditional on said verification.

19. The method of any preceding claim, comprising sending the data item and / or the commitment of the data item to a different user.

20. The method of claim 8 or claim 19, wherein said sending is in response to a request for the data item and / or the commitment of the data item, wherein said request comprises the storage proof, and wherein the method comprises using the storage proof to identify the data item and / or the commitment of the data item.

21. The method of any preceding claim, comprising: generate an elliptic curve block point, said generating comprises: hashing one or more respective data items to generate one or more respective hashed data items, summing the respective hashed data items to generate a summed value, computing a first elliptic curve point based on the summed value and, wherein the elliptic curve block point is based on the first elliptic curve point; andwherein the storage proof comprises a signature generated with a respective private key based on the summed value, and the respective hashed data item;22. The method of claim 21, wherein generating the elliptic curve block point comprises generating a second elliptic curve based on a salt value, wherein the elliptic curve point is based on the second elliptic curve point, and wherein the storage proof comprises the salt value.

23. The method of any preceding claim, comprising: validating the commitment transaction according to one or more rules of a blockchain protocol, wherein said submitting of the commitment transaction to the one or more blockchain nodes and / or said causing of the commitment transaction to be recorded on the blockchain is conditional on said validating of the commitment transaction.

24. A computer-implemented method performed by a first user and comprising: sending a data item to a storage provider; receiving, from the storage provider, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

25. The method of claim 24, comprising receiving, from the storage provider, a blockchain proof proving that a commitment transaction comprising a commitment of the data item has been recorded on the blockchain.

26. The method of claim 24 or claim 25, comprising: using the storage proof to verify that the data item and / or the commitment of the data item has been accepted by the storage provider for storage and / or sending the storage proof to the second user for verifying that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

27. The method of claim 25 or any claim dependent thereon, comprising using the blockchain proof to verify that the commitment transaction has been recorded on theblockchain and / or sending the blockchain proof to a second user for verifying that the commitment transaction has been recorded on the blockchain28. The method of claim 24 or any claim dependent thereon, comprising: verifying that the data item comprised by the commitment transaction matches to the data item sent to the storage provider; and / or verifying that the commitment of the data item comprised by the commitment transaction corresponds to the data item sent to the storage provider.

29. The method of any of claims 24 to 28, comprising: obtaining one or more respective signatures from one or more respective predetermined parties; and including the one or more respective signatures as part of the data item prior to sending the data item to the storage provider.

30. The method of any of claims 24 to 29, comprising structuring the data item according to a predefined structure prior to sending the data to the storage provider.

31. A computer-implemented method performed by a second user and comprising: receiving a data item from a storage provider and / or a first user; receiving, from the storage provider and / or the first user, a blockchain proof proving that a commitment transaction comprising a commitment of the data item has been recorded on the blockchain; receiving, from the storage provider and / or the first user, a storage proof proving that the data item and / or the commitment of the data item has been accepted by the storage provider for storage; using the blockchain proof to verify that the commitment transaction has been recorded on the blockchain; and / or using the storage proof to verify that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

32. The method of claim 31, comprising:determining a status of the commitment transaction; and determining information regarding the data item based on the status of the commitment transaction.

33. The method of claim 32, wherein the information comprises a validity of the data item.

34. The method of any of claims 31 to 33, comprising: verifying that the data item comprised by the commitment transaction matches to the data item sent to the storage provider; and / or verifying that the commitment of the data item comprised by the commitment transaction corresponds to the data item sent to the storage provider.

35. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 34.

36. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 34.

Images