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 an item of data; submitting a commitment transaction to a block chain network, wherein the commitment transaction comprises the commitment of the data item; storing and / or issuing the data item and / or the commitment of the data item; and providing a storage proof to the first user to prove that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

Description

Technical Field

[0001] This disclosure relates to a method for maintaining data as part of a storage (or overlay) network, and a method for providing that data has been accepted for storage in / on the storage (overlay) network. Background Technology

[0002] Public Key Infrastructure (PKI) is a combination of different roles, policies, and procedures that support the creation, management, distribution, and revocation of digital certificates. PKI provides trust services (confidentiality, integrity, and authenticity) and facilitates the secure transmission of information across a wide range of networks. PKI binds a public key to a user's identity. This binding is established when registering with a certificate issued by a Certificate Authority (CA). Certificate revocation can occur at any time and is managed by a revocation authority (RA); typically, the CA and RA are the same entity.

[0003] A Certificate Authority (CA) may delegate necessary validity checks to a second authority, the Registration Authority (RegA), during the registration process. The RegA is responsible for accepting digital certificate requests and authenticating the requesting entity, but does not sign or issue certificates. The information verified by the RegA allows for a unique identification of the entity using its public key. The certificate is signed by the CA using its private key. Entities interacting with the authenticated entity can check the validity of the certificate by verifying the signature and whether the certificate has expired. The validity period of a certificate can be determined in different ways depending on the specific implementation of the PKI.

[0004] Blockchain can be used to provide PKI services without additional infrastructure. CAs run blockchain nodes, and when RegA notifies them that a user has been authorized, they publish a transaction storing that user's public key (or its hash). This transaction corresponds to a certificate, and its spent state determines whether the certificate remains valid.

[0005] Lightweight Directory Access Protocol (LDAP) is an open, industry-standard application protocol used for accessing and maintaining distributed directory information services over a network. Information is stored in the form of entries, each consisting 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 distinguishing name. This distinguishing name may change during the entry's lifetime.

[0006] Directory services allow the sharing of information about users, systems, networks, services, and applications (e.g., an ordered set of records with a hierarchical structure). Common LDAP operations in an LDAP session include searching and retrieving directory entries, inspecting entry attributes, and adding, deleting, or modifying entries. A client initiates an LDAP session by connecting to an LDAP server. The client then sends an operation request to the server, which returns a response. All communication is conducted over a secure communication channel (e.g., a TLS channel).

[0007] A Merkle tree is a tree whose leaves are represented by hashes of the data, and whose non-leaf nodes are represented by cryptographic hashes of combinations (e.g., cascades) of the labels of their children. Merkle trees allow for efficient and secure verification of the data contained within their leaves. This is achieved through a process called a Merkle proof. The cryptographic security provided by the hash function ensures that Merkle proofs cannot be forged.

[0008] Bitcoin SV stores blocks as Merkle trees and relies on Merkle proofs to demonstrate that a transaction has been added to the block. The root of the tree is stored in the block header. The immutability of the blockchain ensures that the Merkle proof of a transaction cannot be modified. The hash function used is a double SHA-256 hash function. Merkle trees are used to improve the efficiency of verifying whether a transaction is included in a block. Summary of the Invention

[0009] According to one aspect disclosed herein, a computer-implemented method for storing data is provided, wherein the method is performed by a storage provider, wherein the storage provider is an entity outside of blockchain nodes, and wherein the method includes: 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 includes a commitment to the data item; storing and / or publishing the data item and / or the commitment to the data item; and providing the first user with a storage certificate generated in response to the commitment transaction being submitted to the one or more blockchain nodes and generated based on the data item, the storage certificate serving to prove that the data item and / or the commitment to the data item has been accepted by the storage provider for storage.

[0010] According to another aspect disclosed herein, an aspect performed by a first user is provided, comprising: sending a data item to a storage provider; and receiving a storage certificate from the storage provider, the storage certificate being used to prove 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, a computer-implemented method is provided, the method being performed by a second user, the method comprising: receiving a data item from a storage provider and / or a first user; receiving a blockchain proof from the storage provider and / or the first user, the blockchain proof being used to prove that a commitment transaction including a commitment of the data item has been recorded on a blockchain; receiving a storage proof from the storage provider and / or the first user, the storage proof being used to prove 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 whether the commitment transaction has been recorded on the blockchain, and / or sending the blockchain proof to the second user to verify whether the commitment transaction has been recorded on the blockchain; and / or using the storage proof to verify whether 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 to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0012] Embodiments of this 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 hashes or other types of commitments) is stored by one or more storage providers. When storing data, the storage provider generates and provides a proof of data storage (e.g., a signature), which a user can use to verify or prove to different users that their data has been stored. The proof (e.g., the signature) proves that the data has been accepted by the storage provider. The commitment to the data (e.g., a hash) is also stored on a blockchain. The storage proof of the commitment on the blockchain can also be provided to the user. Attached Figure Description

[0013] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 This is a schematic block diagram of a system for implementing blockchain. Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain; Figure 3 This is a schematic diagram of a storage network utilizing blockchain. Figure 4 An exemplary overlay network is illustrated schematically; Figure 5 An exemplary data packet creation is illustrated schematically; Figure 6 An exemplary packet submission is illustrated schematically; Figure 7 An exemplary verification of the data packet is illustrated schematically; Figure 8 An exemplary retrieval of data packets is illustrated schematically; Figure 9 This is an exemplary process for the data packet lifecycle; Figure 10 This is an exemplary process for creating data packets; Figure 11 This is an exemplary flow of the merging process; Figure 12 This is an exemplary process for creating a block point; Figure 13 This is an exemplary process for covering proof verification; Figure 14 This is an exemplary process for creating a document data package. Detailed Implementation

[0014] 1. Proof of Storage The embodiments disclosed herein can be used to demonstrate that data has been stored by a storage provider (and / or has been accepted for storage). Figure 3 An exemplary system 300 for implementing the embodiments described herein is shown. System 300 includes one or more storage providers 302, one or more users 304 (or more generally referred to as “participants”), and one or more blockchain nodes 104 of a blockchain network 106.

[0015] Each storage provider 302 may be a corresponding computer (e.g., a server). Storage providers 302 are configured to communicate with each other, with one or more users 304, and with one or more blockchain nodes 104. Storage providers 302 may be connected as part of a network 306 of storage providers 302. Network 306 may be an overlay network, i.e., a network that overlays another lower-level network operating on top of it. This lower-level network may be the Internet 101 and / or a blockchain 150.

[0016] Each user's 304 can be configured to execute the following reference. Figure 1 and Figure 2 The description of any or all actions performed by Alice 103a and / or Bob 103b.

[0017] In this full disclosure, the term "storage network" may be replaced with "overlay network". Similarly, the term "storage node" may be replaced with "overlay server", and the terms "storage certificate" and "proof of storage" may be replaced with "proof of overlay". Storage providers may be operated by organizations such as governments, corporations, charities, universities, etc.

[0018] User 304 uses storage provider 302 to store their data. Typically, storage provider 302 provides proof that the user's data has been stored. The commitment to store this data is stored on blockchain 150. This commitment allows the user to prove that the data existed at the time the commitment was made. This provides an immutable record of the data / commitment being stored, along with a timestamp of the storage. Storage provider 302 also provides proof that the data has been accepted for storage on storage network 306; for example, storage provider 302 confirms that the data meets one or more requirements of storage network 306. For example, storage network 306 could be operated by a university, and the storage provider could be a university server used to verify whether a user (e.g., a student) has submitted a document that meets one or more requirements for a thesis, exam answers, etc. This provides the student with a record proving they have met the submission requirements.

[0019] A user (e.g., Alice 103a) submits a request to storage provider 302 to store their data. The request may include only the data or additional information. The data may be encrypted by Alice 103a.

[0020] Storage provider 302 generates a commitment to the data, for example, by hashing the data using a hash function (e.g., SHA256). Any suitable hash function can be used. Other types of commitments that obfuscate the data can be used, such as a Pedersen commitment. The hash can be a salted hash. That is, the data and a salt (e.g., a random value) can be input into the hash function. Storage provider 302 submits a transaction that includes the commitment to the blockchain network. This transaction is referred to herein as a “commitment transaction.” If an output-based blockchain is used, the commitment can be stored in either the scalable or unscalable output of the transaction.

[0021] In some examples, storage provider 302 performs transaction verification (i.e., verification) steps that would typically be performed by blockchain node 104; that is, the storage provider acts as blockchain node 104 to verify the committed transaction. Simply put, storage provider 302 can verify the transactions it generates. Storage provider 302 can also publish the committed transaction on blockchain 150. Alternatively, the storage provider can send the committed transaction to blockchain node 104 for verification and publication on blockchain 150. Thus, in the former case, storage provider 302 can perform certain verification steps on the data to be stored (discussed in detail below) and also create and verify the committed transaction. Storage provider 302 then sends the verified committed transaction to one or more other blockchain nodes for recording on blockchain 150, or records the verified committed transaction directly on blockchain 150 itself. Alternatively, in the latter case, storage provider 302 performs internal verification of the data and then sends the committed transaction to blockchain network 106 for blockchain node 104 to verify, which is the same as in the conventional case.

[0022] Storage provider 302 stores the data and / or the commitment. The data and / or the commitment may be stored on a storage device accessible only to storage provider 302, or on a storage device accessible to the storage provider's network 306 (e.g., cloud storage, distributed database, etc.). The data and / or the commitment may be published, making it accessible to one or more users 304.

[0023] Storage provider 302 may send a proof (“blockchain proof”) to Alice 103a, which Alice 103a can use to verify (or prove) whether a commitment to its data has been stored on blockchain 150. This proof may be a Simple Payment Verification (SPV) proof. Those skilled in the art will be familiar with SPV proofs, the content of SPV proofs, and how Alice 103a would use the proof to verify whether the committed transaction containing the commitment has been stored on blockchain 150. The blockchain proof may be sent directly to Alice 103a or, for example, published on overlay network 306. In some examples, storage provider 3002 sends the blockchain proof only upon request from Alice 103a.

[0024] Storage provider 302 sends a proof (“Storage Proof”) to Alice 103a, which Alice 103a can use to verify (or prove) that her data has been accepted by storage provider 302 for storage. This Storage Proof is generated based on the commitment that the transaction is recorded on blockchain 150 (i.e., as a condition and / or in response to this). The Storage Proof can be a digital signature generated by storage provider 302. This signature can be generated based on the data. For example, the signature can be used to sign the data. Alternatively, the private key used to generate the signature can be a function of the data. In some examples, the Storage Proof is generated based on elliptic curve block points, as discussed below. This Storage Proof differs from a blockchain proof. That is, the Storage Proof does not prove that a transaction has been recorded on blockchain 150.

[0025] In some examples, storage provider 302 may delete Alice's data after providing one or more proofs and store only the commitment and / or storage proof (and optional blockchain proof). Block points are discussed below—in some examples, storage provider 302 may delete data and store block points.

[0026] A storage network 306 can be associated with an identifier (e.g., the network's name, public key, value, etc.). A commitment transaction can include this identifier, allowing the user 304 and the storage provider to easily identify the associated transaction. A commitment transaction may not include this identifier, but instead include an obfuscated version of it, such as a hash of the identifier or a hash of the identifier and the commitment. This hash can be based on one or more additional items. The identifier can be unique within the network, but this is not required.

[0027] Committed transactions can have a version field. This identifier can be a version number associated with network 306. This version number can be associated with a specific storage provider 302. This version number can be associated with a specific type of data (e.g., driver's license, university submissions, passport, etc.).

[0028] Storage provider 302 may send the identifier (or obfuscated identifier) ​​to Alice 103a so that she can identify the committed transaction on blockchain 150. Storage provider 302 may publish the (obfuscated) identifier so that Alice 103a can access it.

[0029] Storage provider 302 may perform one or more checks on Alice's data before accepting and storing it. Storage provider 302 may check whether Alice 103a is authorized to submit data to the storage network. This may involve storage provider 302 verifying Alice's credentials. For example, storage provider 302 may verify whether Alice 103a has obtained a issued public key for authentication.

[0030] For example, storage provider 302 can verify whether Alice's data has a predetermined format and / or structure. For instance, if the data is a specific file type, has certain fields, is of a specific length, etc. Storage provider 302 can verify whether Alice's data contains one or more signatures from one or more predetermined parties. Returning to the example of university submissions, storage provider 302 can verify whether Alice's thesis is signed by Alice 103a, her supervisor, one or more reviewers, etc.

[0031] In some examples, Alice's data might be needed to obtain a set of signatures, but one or more of these signatures might be lost when the data is sent to storage provider 302. Nevertheless, obtaining proof that the data has been stored allows Alice 103a to prove that she has at least begun the process of obtaining the required signatures.

[0032] In some examples, storage provider 302 is associated with a specific data type and / or application. For example, storage provider 302 might be responsible for storing driver's license or passport information. Each storage provider 302 might be associated with a specific data type; for example, one provider 302 might correspond to each data type. In these examples, storage provider 302 might verify whether Alice's data belongs to the correct type and / or application.

[0033] Storage provider 302 may receive requests for Alice's data, such as requests from Alice 103a, different users (e.g., Bob 103b), or another storage provider 302. The request may include a storage certificate, which storage provider 302 may use to identify the relevant data and / or commitment transactions. Storage provider 302 may send one or more of the following to Alice 103a, Bob 103b, and / or one or more storage providers 302: data, commitment, blockchain certificate, and storage certificate. In some examples, for instance, a storage provider may refuse Bob's request for Alice's data if Bob does not have appropriate access rights, or if Alice's data is of a sensitive nature.

[0034] Upon receiving the blockchain proof and storage proof, Alice 103a and / or Bob 103b are configured to use these proofs to verify whether the committed transaction has been stored on blockchain 150 and whether the data has been accepted for storage by storage provider 302. Alice 103a and / or Bob 103b can verify that the commitment included in the committed transaction is a valid commitment to the data. For example, the data can be hashed to verify whether it matches the commitment. In some examples, Alice 103a and / or Bob 103b can verify whether the output of the committed transaction (e.g., the output containing the commitment) has not been spent to determine whether the data is still valid, or more generally, to determine any other information related to the data. That is, storage provider 302 can indicate that the data is no longer valid by spending the output of the committed transaction. More generally, a change in state can indicate a change in data attributes. For example, if the data packet is CBDC, a spent state can indicate that the recipient of the CBDC has provided a payment receipt.

[0035] Storage provider 302 can retrieve multiple committed transactions recorded in a given block 151 of blockchain 150. One or more of these transactions may be generated by storage provider 302. One or more of these transactions may be generated by different storage providers 302. One or more of these transactions can be retrieved by extracting one or more transactions from block 151. One or more of these transactions may be received from different storage providers 302.

[0036] Storage provider 302 can generate elliptic curve block points based on the acquired transactions. These block points are generated as follows: Each transaction commits to data items. Each data item is hashed individually to generate hashed data items. These hashed data items are summed (or otherwise aggregated or combined) to generate a summed value. A first elliptic curve point (i.e., the public key) is generated based on this summed value and a generator point. A second elliptic curve point can be generated based on a salt value. A block point is generated based on the first and second points (e.g., by summing these points). For example, if the participants are honest, the salt value and the corresponding elliptic curve point are not essential.

[0037] Storage provider 302 sends the block point to Alice 103a and / or Bob 103b. Storage provider 302 may publish the block point so that Alice 103a and Bob 103b can access it. Storage provider 302 may send a reference to the block point (e.g., its location) instead of the block point itself.

[0038] For a given commitment transaction (e.g., a transaction committing to Alice's data), the storage provider 302 or an independent party can generate a storage proof (in this case, a signature) using a private key based on the sum value, salt value (if needed), and hash of Alice's data items. This signature is then sent to Alice 103a and / or Bob 103b.

[0039] Storage provider 302 can generate and provide proof for each data item in a similar manner. As previously mentioned, storage providers can provide blockchain proof for each committed transaction.

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

[0041] 2. Government Coverage Network This section describes the architecture of a Government Overlay Network (GOvNet) that can be implemented using embodiments of this disclosure. GOvNet is an exemplary implementation of the storage network 306 described above. It should be understood that some of the features described below are optional.

[0042] The primary objective is to maintain a register containing information related to public administration and other government entities. This information can be provided by government authorities or citizens. Although the name explicitly mentions government, this type of overlay network is equally suitable for any organization wishing to migrate its administrative infrastructure to the blockchain.

[0043] GOvNet is maintained by government servers (GS), which communicate with the blockchain and approve data submitted by users. GS have the authority to create transactions on the blockchain, providing proof of data existence. User registration overlays the network. Registration relies on public key infrastructure and ensures that only authorized and recognized users can access the network's functionality. Lightweight Directory Access Protocol (LDAP) supports access to network information and data retrieval. The user experience with the network is achieved through dedicated user terminals (e.g., applications on their mobile phones) that facilitate data submission to the network.

[0044] The following section discusses two main use cases for GOvNet: document management, such as creation and distribution, and central bank digital currencies. In addition to the main use cases, key aspects of GOvNet, such as how they communicate with blockchains, how data is stored, and how user privacy is maintained, are also discussed.

[0045] 2.1 Overview GOvNet is a government-maintained overlay network that stores information relating to the government, its citizens, and other public or private entities. This information may be provided by government authorities or citizens and may include citizen information (e.g., personal documents), government information (e.g., housing registrations), and payment services (e.g., central bank digital currencies).

[0046] GOvNet is maintained by network devices called Government Servers (GS). These servers process information overlays within the network, securely store data, and share data with other devices, such as user devices, public offices, and other network equipment. Government Servers ensure data integrity and timestamping by publishing anonymized data to a blockchain. Only fingerprints of the data are published to guarantee the privacy of authorities and users.

[0047] Citizens willing to interact with GOvNet may require identification and pre-authorization. Information retrieval can be managed through LDAP services. Figure 4 The diagram shows an overview of the architecture of GOvNet.

[0048] 2.1.1 Government Server Government servers (GS) constitute GOvNet's primary hardware infrastructure. They can act as load balancers, replicating required data, or have specific functionalities. In the latter case, servers can be linked to specific use cases; for example, one or more servers might provide registry services, while others might support central bank digital currency (CBDC) transactions.

[0049] GS processes and stores information they receive from other GSs and authorized third parties. Authorized parties can then access this information to obtain relevant government services. The data is stored in an internal database, known as the GS database, and is maintained by GS.

[0050] Government servers can provide one or more of the following functions: ● GS Database: GS stores information corresponding to the government services it provides in an internal database. Data may be stored in various formats (e.g., plaintext or hashed) to protect the privacy of authorities and users.

[0051] ● Communication with other GS: GS communicate user data and other information to each other to ensure that the data is up-to-date and consistent.

[0052] ● Interaction with the Blockchain Network: GS uses blockchain technology to timestamp information and ensure the immutability and authenticity of data. GS manages all services related to transaction publishing and administration, such as creating, funding, and publishing blockchain transactions containing the required data (or its fingerprint). Publication proofs (e.g., SPV proofs) are stored in the GS database for lightweight verification.

[0053] ● Data Verification: Providing information about the status of stored data when needed by the government (e.g., verifying the validity of a driver's license). This includes proof of publication on the blockchain (e.g., SPV proof) and proof of inclusion in the GS database. The proof of inclusion in the GS database is called... Coverage proof .

[0054] ● User Access Management: Manages user services, such as verifying whether a user has the right to create and access data. When data has been added to the network, GS communicates with interested users and provides proof of publication (e.g., SPV proof and overlay proof).

[0055] 2.1.2 Government Server Database The GS database contains all the information GS needs to provide its intended government services. For each piece of information received, these databases store at least the following: ● The fingerprint of the information to be recorded (e.g., document hash).

[0056] ● Proof of publication in the blockchain (e.g., SPV proof) — also referred to as “blockchain proof” in this article.

[0057] ● Inclusion proofs (e.g., covering proofs) in GOvNet — also referred to as “storage proofs” in this paper.

[0058] Optionally, documents and other data segments can be stored in the GS database in plaintext or encrypted form. If documents are stored, GS can provide data access services (e.g., retrieving ID cards); otherwise, they only provide validity verification services (e.g., confirming that a given ID card is valid and has not expired or been revoked).

[0059] SPV proof SPV proofs are a lightweight technique used to prove that a transaction has been published on a blockchain. Typically, an SPV proof includes at least a Merkle proof of the transaction and a corresponding block header. Merkle proofs are used to prove that a given transaction has been inserted into a block. The validity of a block is verified by checking if its block ID is part of the longest honest chain.

[0060] Coverage proof A cover proof is a proof that some data has been accepted in GOvNet. Cover proofs are generated once the fingerprint of the data is added to a Bitcoin block. They can be unforgeable signatures associated with a public key derived from the data. Users can verify cover proofs independently without relying on GS.

[0061] 2.1.3 LDAP service for government servers GS can only publish data that has been authorized and verified on GOvNet. Multiple authorization checks and verifications are performed before data is published. Users are required to be authorized to publish content on GOvNet. Other requirements depend on the use case and include, for example, that the data has been approved by all relevant parties; for instance, if the data is an electronic document, it may require signature by a government-affiliated entity.

[0062] To verify this information, GOvNet can use the LDAP service. GS queries the LDAP service to check whether the information it receives has been approved and is consistent. By restricting access to government servers, user privacy can be protected: GS can check a user's permissions without inferring their identity.

[0063] 2.1.4 GOvNet users Only authorized users can participate in the network. They communicate with GOvNet using a local interface (e.g., a smartphone application or internet portal). This service allows them to access GOvNet functionality only after their identity has been verified, ensuring that only authorized parties can interact with GOvNet. Furthermore, user access management ensures the authenticity and non-repudiation of data.

[0064] GOvNet is designed to ensure users retain control over their data. Once uploaded to GOvNet, data can be shared with other users or public entities, ensuring data authenticity and consistency without disclosing unnecessary information. The user authorization system can rely on PKI protocols and uses LDAP (Lightweight Directory Access Protocol) to manage user access to information. Users inform a government-affiliated Registry (RegA) of their registration intentions. The Certificate Authority (CA) verifies user information and grants them the appropriate level of access. User authorization can be revoked at any time by the legitimate authorizing party; revocation requests are handled by the Revocation Authority (RA).

[0065] 2.1.4.1 Account Creation To access GOvNet, users may need an authorized account. During the authorization process, the user is associated with a public key (or a set of associated public keys) authorized by a government or other trusted party (e.g., a public administration body). These public keys are used to verify the user's identity when communicating with GS to publish and retrieve data. The user controls the associated private key.

[0066] Authentication may require checking a user’s documents and may grant different services to users based on their credentials (e.g., still allowing tourists with visas to use CBDC, but potentially restricting access to other network functions).

[0067] The steps required to obtain an authorized GOvNet account are as follows: 1. Alice connects to the registration terminal (e.g., an application on her smartphone).

[0068] 2. She sends her identification documents (e.g., passport information) to the Registration Authority (RegA).

[0069] 3. RegA checks her files and returns the results of the registration process.

[0070] 4. If the process is approved, RegA will notify the Certification Authority (CA).

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

[0072] 6. Once a transaction is published, a Merkel proof for that transaction is generated.

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

[0074] The described process uses blockchain to record certificates, but accounts can also be created without blockchain, for example, using a traditional CA.

[0075] Registration Authority (RegA) A RegA is a government-affiliated or delegated entity that has the right and authority to examine user information and determine whether a user is entitled to participate in the network. To distribute workload, multiple RegAs may be established in different regions. Because RegAs can access users' personal files and public keys, they are able to add data to the LDAP service. The RegA notifies the CA of its approval, and the CA then creates the user's registration transaction.

[0076] Certification bodies A CA is an organization authorized to generate and broadcast registration transactions for users who have successfully obtained authorization from a RegA. A CA can be a server communicating with a RegA, or a service maintained by several RegAs. Both approaches have their advantages, and the preferred option should depend on the use case and the maintainer's requirements. Establishing a central CA that communicates with all RegAs can prevent communication delays. Allowing RegAs to maintain independent CAs grants them greater independence (e.g., respecting the independence of local regions).

[0077] 2.1.4.2 Account Cancellation Authorized government entities may revoke user accounts at any time in accordance with appropriate legal procedures. Accounts may be revoked for at least one of the following reasons: ● Reaching the agreed expiration date—For legal or security purposes, a user's authorization may be required to expire after a certain period. Data associated with the expired address remains accessible. Once the user updates their key, they can associate their data with the new registration key.

[0078] ● Legal authorities may request revocation—If a user's behavior is improper, their authorization may be terminated prematurely. For example, this could be used to freeze the funds of users who have engaged in illegal activities.

[0079] ● User Request to Withdraw — Users have the right to exit GOvNet and deregister. Deregistration does not erase all user information, as users remain responsible for their actions.

[0080] The cancellation process can be as follows: 1. The appropriate entity notifies the revocation authority of the revocation of the user's authorization.

[0081] 2. Revoke the registration of a Registered PKI transaction by the Authority (RA), which will revoke the user's authorization.

[0082] The roles of an RA (Regulator) and a CA (Certificate Authority) are synonymous and can overlap. A CA does not destroy information about a user's public key; it only removes the permission to use those keys to publish new data. After revocation, the user retains control of their keys, but they cannot use them to broadcast new data.

[0083] 2.1.4.3 User-oriented LDAP services Users have access to the LDAP service to view information about other entities on the network. Typically, their access level is more restricted than that of the Service Controller (GS). Some of the queries they can run include: ● Retrieve the public key of a public entity.

[0084] ● Check if a given public key corresponds to a specific user.

[0085] ● Check if a given public key has a specific authorization level.

[0086] When a user connects to their terminal to access GOvNet, they can use the LDAP service. Passwords can be used as a quick way to authenticate the user.

[0087] 2.1.4.4 User Interface The user interface should improve the user experience when interacting with GOvNet. This can be achieved by using a dedicated smartphone application or web portal.

[0088] Smartphone applications can store user information and provide users with a more intuitive interface to use GOvNet. This includes distributing user data, verifying other user data, and querying LDAP services. The application can securely store user information and receive network updates.

[0089] A web platform can be deployed for interaction via computer. User sessions on this platform can be authenticated via smartphone applications or equivalent technologies.

[0090] 2.2 Data Management Documents and other data to be published on GOvNet can be converted into a predefined data structure accepted by GS, called a packet. GS is responsible for filtering and validating incoming packets and broadcasting them to other GS.

[0091] GS ensures the data integrity and timestamps of data packets by publishing obfuscated versions of the packets to a public blockchain. These anonymized data packets are called fingerprint transactions.

[0092] 2.2.1 Data Packet Data is propagated within GOvNet in the form of data packets. These packets can power various services, such as document sharing and CBDC. Data packets overlaying the network are associated with fingerprint transactions published on public blockchains.

[0093] A fingerprint transaction may not contain data packets in plaintext form, but rather its fingerprint (e.g., a hash). This fingerprint is sufficient to ensure that the data packet is associated with a transaction published on the blockchain, while guaranteeing the privacy of the parties involved. Various techniques can be used to determine which transactions in the blockchain are fingerprint transactions. One efficient method to achieve this is to use transaction versioning, whether in plaintext or using versioning puzzles (see Section 0).

[0094] 2.2.2 Transaction Version Control Transaction versioning refers to a technique in which the opcode OP_VER can be used in a locking script to create transactions that can be spent in a variety of predefined ways. UK patent application GB2308931.1 describes the use of OP_VER (and equivalent opcodes or functions) for such transaction versioning. The entire contents of GB2308931.1 are incorporated herein by reference. A locking script contains one or more ways to spend a transaction, the selected version being chosen by selecting a specific transaction version when spending the transaction. Here, "version" refers to the transaction version specified in the transaction header of the transaction being spent. OP_VER allows a locking script to force its spent transactions to have a specific version number or version number from a given set.

[0095] When a transaction is serialized, the version number is located at the beginning of the serialization. This allows GS to efficiently interpret the transaction without fully parsing it. All transactions in the overlay network can share the same version, or different services can have different versions (e.g., version number). Indicates the registry document, version. (This indicates a CBDC payment). Any device can determine whether a transaction is associated with that device by simply examining the first few bytes of the serialized transaction, which provides a more efficient way to interpret transactions than using any other type of flag.

[0096] Finally, OP_VER can be used to filter transactions. However, this is vulnerable to spoofing attacks, in which an adversary can arbitrarily set the version number of their transaction to the same number as the attacked transaction. Nevertheless, using OP_VER is superior to filtering all transactions.

[0097] 2.2.3 Data Packet Creation Users or public entities create data packets when they want to publish data on GOvNet. The data is formatted according to a predefined packet structure. Different types of packets follow different formatting rules and contain different types of data.

[0098] In the example of the document being uploaded, the data packet contains information including the document itself, its type, and its fingerprint (e.g., a hash). If the document is confidential, only the fingerprint is added. If the document requires one or more signatures (e.g., a driver's license may need to be issued by a licensing authority and include the driver's signature), digital copies need to be sent to the relevant parties for signing. All collected signatures are added to the data packet.

[0099] Figure 5 The process for creating data packets is shown in the diagram: 1. Alice sends the data to other parties who may need to sign it.

[0100] 2. Once all signatures are collected, the information is combined into a data packet.

[0101] 2.2.4 Data Packet Submission Users with authorized accounts can publish packets on GOvNet. Upon receiving a packet, the GS checks its syntax, the user's authorization level, and adds a signature (if any). After this verification, the GS forwards the packet to other GSs.

[0102] Once the above steps are completed, GS creates a fingerprint transaction and broadcasts it to the blockchain. Once the fingerprint of the data packet is added to a block, the packet is consolidated. After consolidation, an overlay proof (i.e., an inclusion proof within the overlay network) is sent to the user.

[0103] Figure 6 The process of submitting data packets is summarized in the following: 1. Alice sends a data packet to GOvNet.

[0104] 2. GOvNet checks the validity of data packets: a. Consistency check. GOvNet verifies whether the packets are consistent with the overlay network requirements and whether they represent a valid packet type.

[0105] b. Alice's authorization. If Alice does not have the required authorization, the process stops and no data packet is released (e.g., it is stored on the overlay network).

[0106] c. Signature Verification. GOvNet checks the validity of the signature and its consistency with the packet type. If the signature does not meet the requirements, the packet will not be published.

[0107] 3. GOvNet publishes the fingerprint transactions associated with the data packets to the blockchain.

[0108] 4. GOvNet accepts published proofs (e.g., SPV proofs).

[0109] 5. GOvNet's servers provide Alice with a proof of publication on the blockchain (i.e., an SPV proof) and a proof of publication on GOvNet (i.e., a cover proof).

[0110] In step 2b, GOvNet's check of Alice's authorization may rely on an LDAP service or include explicit verification of PKI registration transactions. In step 2c, an LDAP service can be used to ensure that all signatures are generated by authorized users with the correct permission levels.

[0111] 2.2.5 Data Packet Verification The owner of a data packet must always be able to prove to another user or public entity that the packet is included in GOvNet. If the packet is a document-type 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 packet has not been tampered with by its owner. Figure 7 This describes how Alice proved to Bob that her document-type data packet had been added to GovNet and that its contents had been verified: 1. Alice sends Bob a data packet, a document, an SPV certificate, and an overlay certificate.

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

[0113] 3. Bob checks whether the document corresponds to the given data packet and whether the data packet matches the fingerprint transaction, which ensures that the information in the data packet is consistent with Alice's statement.

[0114] 4. Bob checks whether the packet verification is consistent, which indicates that the packet has been added to GovNet, or at least accepted by GovNet.

[0115] Steps 2, 3, and 4 focus on different aspects of packet integrity. Step 2 only checks if the provided information is up-to-date. Step 3 checks the consistency of the documentation provided by Alice. Step 4 checks if the packet has indeed been added to GovNet. The order of these verification steps is not important.

[0116] A similar procedure can be followed for different types of data packets. For example, if Alice wants to prove to Bob that her CBDC type data packet has been added to the overlay network, the first step would be modified to include information about the CBDC transaction and verify that data.

[0117] 2.2.6 Document Retrieval Document-type data packets can support document retrieval. Users can request to retrieve their own documents or those of other users (e.g., for verification purposes). Document retrieval is only possible if the document was already included in the data packet at the time of creation.

[0118] 1. Users do not need to store documents; they only need to maintain references to the documents (e.g., hashes or overlay proofs). If a document needs to be retrieved from a non-owner user, their authorization is checked, and a verification process is performed after the retrieval (see Section 0). Document retrieval can be generalized to a wider range of packet metadata. Figure 8 The diagram illustrates the process for retrieving documents.

[0119] 2. Alice sends the overlay proof or hash of the data packet to GS.

[0120] 3. GS searches for documents.

[0121] a. GS (e.g., using LDAP) verifies whether Alice is authorized to retrieve the document. If she is not authorized, the process will be interrupted.

[0122] b. GS searches the GS database for data packets that match the hash provided by Alice.

[0123] 4. GS sends Alice the document, Merkel's proof, and (finally) the coverage proof contained in the data packet.

[0124] 5. Optionally, Alice verifies the Merkel proof and the covering proof.

[0125] 2.3 Network Topology This section describes the roles of the relevant parties in GOvNet and how they interact. It provides further details on some topics covered in previous sections.

[0126] 2.3.1 Government Server GS maintains the integrity of the overlay network. GS communicate with each other to ensure data consistency within the overlay network.

[0127] The data packet submitted to GS will go through the following steps.

[0128] 1. GS checks the correctness of data packets: This includes verifying user authorization and the consistency of data packet information.

[0129] 2. GS broadcasts data packets to other GS: Communication between GS ensures that the data propagated in the overlay network remains consistent (i.e., GS share the same view of the overlay network).

[0130] 3. GS generates fingerprint transactions: GS creates a fingerprint of the data packet and broadcasts it to the blockchain.

[0131] 4. GS Merge Data Packets: Data packets are merged when their fingerprints are added to a blockchain block. Verification information for the data packets is generated in this step.

[0132] 5. GS stores packet information and shares it with users: This includes storing packets in a private database and sharing authentication information with users.

[0133] 2.3.2 Lightweight Directory Access Protocol The LDAP service overlaying the network is an infrastructure that can be maintained by a dedicated LDAP server. The LDAP service provides network information to the GS and users and maintains network functions (e.g., user login). User interfaces for common LDAP queries can be implemented in mobile applications and internet portals (e.g., search bars with filters), while APIs can be used to run less common queries. The GS runs several routine queries to check the correctness of each packet sent to them. The type of query depends on the type of packet.

[0134] It should be noted that LDAP is just one example of an authorization service, and any other suitable authorization service can be used, such as Active Directory, OAuth / AuthO2, single sign-on, etc.

[0135] A key feature of LDAP services is that they protect privacy by ensuring that appropriate read permissions are granted to each participant accessing the overlay network. For example, a user can inspect all the data they have stored in LDAP, but cannot arbitrarily access other users' personal data. Similarly, GS has the right to inspect the authorization level of a public key, but may not be able to determine the identity of the corresponding person or entity. The specific access levels for each party in GOvNet are determined by the government operating the overlay network.

[0136] Almost all stakeholders in the overlay network can write to the LDAP database. For example, users can add information such as their password, verified phone number, or email address. Registries and deregistration authorities can add or delete parts of a user's information. Public entities can associate a user's documents with their identity, and GS can associate data packets with documents. Similar to read access, the specific details depend on the requirements of the overlay network.

[0137] 2.3.3 Interaction with Blockchain Interaction with the blockchain provides the Overlay Network with data integrity, security, and timestamping capabilities. Publishing a fingerprint transaction associates a data packet with a Bitcoin SV transaction. This provides proof of the packet's existence and a timestamp on the data. The spending status of a fingerprint transaction can be used to indicate information about the state of the associated data packet (e.g., a spending fingerprint transaction associated with a document data packet might mean the document is no longer valid). Only the GS and relevant parties know the contents of the data packets within the Overlay Network. Fingerprint transactions only contain an anonymous version of the data packet, thus revealing no information to observers.

[0138] GS can be a lightweight client or node. In the first case, they are funded by the government to generate fingerprint transactions. In the second case, they may instead rely on block rewards. GS are likely to connect directly to the blockchain network, as they must publish fingerprint transactions and retrieve and distribute Merkel proofs. Users do not need to connect to the blockchain network because they can trust GS to convey the correct block information and the correct spending status of fingerprint transactions. If they do not trust GS, they can still view information directly on the Bitcoin SV network.

[0139] The block header is broadcast to the user by the GS. The user stores the block header locally so that they do not need to rely on the GS when checking the Merkel proof of the fingerprint transaction. Furthermore, certain GOvNet-specific information (e.g., public data computed in the merging step) can also be broadcast to the user in the same way. This allows the user to verify the data packet without querying the GS. This additional information stream incurs minimal storage cost on the user's end.

[0140] 2.3.4 Users After registration, users can interact with the overlay network. RegA checks user credentials and determines the appropriate user access level. Interaction with GOvNet occurs through a user terminal (e.g., a smartphone application or web portal). This terminal should facilitate packet creation. User registration and deregistration can rely on standard PKI protocols.

[0141] 2.3.5 User Registration The complete user registration agreement is as follows: 1. Alice requests to join the network via RegA.

[0142] 2. RegA requires Alice to provide documentation to verify her credentials.

[0143] 3. Alice sent her document to RegA.

[0144] 4. RegA determines Alice's appropriate access level. This determines which network functions she can use.

[0145] 5. Alice receives her access level.

[0146] 6. Alice generates a private / public key pair.

[0147] 7. Alice transmits her public key to RegA.

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

[0149] 9. The CA authenticates the public key.

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

[0151] The following discussion provides some additional information.

[0152] ● Steps 1 through 4 can be modified so that Alice needs to register separately for each different service provided by GOvNet.

[0153] ● Step 5 could simply be a notification, informing Alice whether her request has been accepted.

[0154] ● In step 6, Alice's key can be the parent key of the HD wallet branch. When she submits the data packet, she only needs to specify which child key of the certified parent key she is using. This ensures that she does not need to reuse keys.

[0155] ● In step 8, RegA can either share the association between the public key and Alice's identity with the CA, or simply inform the CA that the key has been authorized.

[0156] ● In step 9, authentication can follow a standard PKI protocol or use a blockchain-based PKI.

[0157] ● Access to the network is not limited to individuals; it can also be extended to organizations and businesses.

[0158] ● GS can track verified keys and store them in a database to reduce the number of times the same key needs to be checked.

[0159] Traditional PKI In traditional PKI, a user's key is authenticated by a CA, where the certificate contains the CA's signature of the user's public key. The GS checks this signature of the CA and verifies with the RA whether the key has been revoked each time a data packet is submitted.

[0160] PKI using blockchain If PKI utilizes a blockchain, the CA creates a registration transaction on the blockchain containing the user's key or its fingerprint (e.g., hash). The user demonstrates their authorization to participate in GOvNet by presenting the registration transaction. The GS checks whether the registration transaction has been published by the CA and determines its spending status. If the registration transaction has not been spent, the user's key is still considered valid.

[0161] 2.3.6 User Cancellation User authorization can be revoked. There are various reasons for revocation, such as data breaches, user misconduct, or expired authorization, and multiple entities may be able to revoke the key. For example, law enforcement, a CA, or the user may be able to revoke the key.

[0162] The RA receives revocation requests and removes the authorization from the public key when the request is deemed valid. The validity of the request may depend on the requester's permissions and the purpose of the revocation. The revocation protocol depends on the version of the PKI protocol used.

[0163] Revocation does not need to be permanent. It can temporarily prevent a user from participating in the network. Temporary revocation is called suspension, and it can be achieved by first performing a full revocation and then automatically re-registering after the suspension period ends.

[0164] Traditional PKI The RA publishes and broadcasts a frequently updated revocation database that notifies the GS of all revoked public keys. This database must be updated frequently. The LDAP service grants the GS access to revocation information, including the revocation time. Therefore, even if the packet is fingerprinted before the revocation is broadcast, the packet can still be invalidated before merging.

[0165] PKI using blockchain To revoke a key, the RA only needs to spend the user registration transaction. The GS can check the spending status of the user registration transaction to prevent the revoked key from receiving data packets.

[0166] 2.3.7 Key Recovery Service Key recovery options can be provided to users. PKI recovery methods (e.g., key escrow) can be used. Users can also choose to opt out of the service.

[0167] 2.4 Data Packet Lifecycle This section describes the different types of data packets, their lifecycles, and their fingerprint transactions. Data packets are generated by users, signed by various entities, and approved by the GS. Each data packet's fingerprint exists on the blockchain, but no information about the original data packet can be recovered from these fingerprints. Figure 9 The lifecycle of the data packet is shown. For certain types of data packets, additional steps may be required.

[0168] 2.4.1 Data Packet Creation Data packets are created by the user and broadcast to the overlay network after finalization. The steps taken to create a data packet depend on the type of packet. Examples of these steps include compiling a data packet template, providing personal information, and collecting signatures. Data packets are signed by one or more entities or individuals to ensure their validity. The required number of signatures, as well as the identity and authorization level of the signers, can vary between data packets, even if they are of the same type.

[0169] One of the primary uses of a user terminal is to facilitate the creation of data packets, particularly ensuring that the packets conform to the correct syntax. In principle, users could be allowed to send data packets via an API. While this approach is not inherently wrong, it exposes users to the risk of creating malformed data packets. For the remainder of this section, it is assumed that users rely on their terminal (e.g., a smartphone application or web portal) to generate data packets. Figure 10 The data packet generation process is described in the document: 1. Alice selects the type of data packet she wants to generate.

[0170] 2. The terminal provides a data packet template.

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

[0172] 4. The terminal establishes a secure communication channel to collect signatures (if necessary) and requests signatures from relevant parties.

[0173] 5. The signer verifies the supporting data provided by Alice and adds their signature.

[0174] The protocol can be adapted to support various design choices. For example, the selection of packet types can be implemented in a user-friendly manner by relying on a search bar or filters. Not all packet types require steps 4 and 5.

[0175] After packets are created, they are submitted to GS. Packets can be submitted by the signer, owner, or terminal. Submission strategies can depend on the type of packet (e.g., identity documents must be submitted by a government agency).

[0176] 2.4.2 Data packet correctness Before a data packet begins to propagate through the overlay network, its correctness is checked. This is done by performing multiple independent checks to determine the packet's correctness.

[0177] ● Packet belongs to a valid type: This check ensures that the packet belongs to a type recognized by the network. Different types of packets may follow different requirements and syntax.

[0178] ● Complete and consistent data packets: Once the type of data packet is determined, it is necessary to check whether it contains all the necessary information, whether the information follows the correct syntax, and whether the data is consistent with each other.

[0179] ● The packet creator has the correct authorization level: If the packet is complete, it must be ensured that the packet owner has the correct authorization level to submit the packet. This verification can rely on an LDAP service or on a link provided by the user to the registration transaction.

[0180] ● The correct entity has signed the data packet: Some types of data packets require signatures from different parties who need to be authorized and authenticated to sign such packets. GS checks rely on the LDAP service to authenticate the signer's identity and authorization level. GS's LDAP permissions may prevent it from checking the identity of citizens, but still allow it to identify public institutions or companies.

[0181] The order of these checks is flexible and can be modified according to the needs of the network.

[0182] 2.4.3 Broadcast Data Packets Packets that pass the correctness check are broadcast to other GSs. The purpose of this broadcast is to ensure that all relevant GSs receive their creation notification and store it in their GS database. Depending on the network architecture, this can be achieved in various ways. Two factors need to be considered. The first factor is the data that the GS stores in its database, and the second factor is how GOvNet services are distributed among the GSs—whether they all maintain all services or each focus on a subset. The following table discusses some different scenarios: ● Only one Service Group (GS) maintains any service, and the GS database only stores data packets related to that service. In this case, GSs are essentially independent of each other and do not need to broadcast information to other servers except for archiving purposes. A single GS can maintain multiple different services.

[0183] ● Only one Service Group (GS) maintains any service, but the GS database stores all packets in the GOvNet (as well as packets unrelated to the maintained service). In this case, broadcasting is necessary, but only for informational purposes. This can be done via a secure communication channel between GSs. A single GS can maintain multiple different services.

[0184] ● Multiple (or all) Service Groups (GSs) maintain a given service. In this case, data packets need to be shared with each relevant GS to confirm that there are no conflicts, i.e., no duplication or resource reuse. If the GS database is distributed across GSs, various types of distributed SQL and NoSQL database implementations are available to achieve this result. Furthermore, a prioritization system needs to be defined to generate fingerprint transactions (e.g., GS broadcast fingerprint transactions to verify data packets), and a protocol for handling offline GSs (e.g., if a data packet is lost, the GS can recover the information after coming back online).

[0185] ● Mixed Scenario. A GS cluster can handle multiple services, but not all services. The aforementioned scenario can easily generalize to this one.

[0186] 2.4.4 Fingerprint Transactions Fingerprint transactions are P2PKH dust transactions, which store the salted hash of the corresponding data packet. Fingerprint transactions are easily recovered by the GS (Gross Dataset), but may not be identifiable by any external party. The underlying data packet cannot be recovered from a fingerprint transaction.

[0187] Because fingerprint transactions are dust transactions, their cost is minimal. Since they are associated with a packet only through a salted hash, it's impossible to infer the packet from the fingerprint transaction, but anyone who knows the packet can associate the two. The salt can be created deterministically using a secret-sharing scheme between the GS and the packet's owner.

[0188] When creating a new block, the GS does not need to search the fingerprint transactions it broadcasts (it receives the Merkel proofs of these fingerprint transactions) and does not require any additional information to identify these fingerprint transactions. However, other GSs need to scan the block to identify these fingerprint transactions or wait for the first GS to share them. They may need to be able to easily identify these fingerprint transactions, and some methods to achieve this will be discussed below.

[0189] Public Identifier The overlay network can choose a public network identifier. Clients filter transactions with the correct format and identifier. The network identifier can be stored as data after OP_RETURN, or it can be stored using the transaction version field. The latter allows fingerprint transactions to be identified by examining only the first 4 bytes.

[0190] This method is easy to implement and allows for rapid identification, but it exposes the network to DoS attacks, in which attackers create numerous fake fingerprint transactions. Attackers cannot forge packets, and clients will spend time and resources discarding the fake packets.

[0191] Identifier obfuscation Organizations supporting overlay networks may desire a higher level of privacy protection for their transactions. More specifically, they may want to ensure not only that data packets cannot be recovered from fingerprint transactions, but also that external observers cannot discern which blockchain transactions are fingerprint transactions and which are not. Clearly, previous types of identifiers are unsuitable for this task, as the transaction version number would reveal the overlay network to which the fingerprint belongs. How to obfuscate this identifier will be discussed below.

[0192] Assume the overlay network has a private network identifier known only to GS. With data packets The associated fingerprint transaction has a transaction version value. and store the hash of the data packet. Identifiers can be obfuscated by storing the obfuscated identifier within the fingerprint transaction. ,in It is a fixed function (e.g., cascade or addition).

[0193] Given a transaction with a fingerprint transaction syntax, GS can easily verify whether the transaction is indeed a fingerprint transaction associated with its network. GS will then... This is communicated to the user who possesses the data packet to allow verification of fingerprint transactions, but it does not disclose any private identifiers. Any information. The value of the outermost hash function also depends on... This allows users to verify whether the value is associated with their data packets. Knowing the value... GS and users can verify whether fingerprint transactions are consistent with data packets. Related.

[0194] Transaction version It is not necessary to include it in the obfuscated identifier; however, including the transaction version can have some benefits, especially if the GS might want to scan blocks to find the fingerprint transaction (although this is not recommended, see Section 0). For example, the GS may choose to use a transaction version. (or a set of possible transaction versions), which are used by other services in the ecosystem. This allows filtering blocks by transaction version, but does not inform any observer which transactions are GOvNet fingerprint transactions.

[0195] 2.4.5 Data Packet Merging If the packet fingerprint transaction is already included in a BSV block, the packet is merged. This section describes how merging works. Figure 11 A brief description of the process is shown below: 1. Blockchain nodes generate new blocks.

[0196] 2. GS extracts the fingerprint transaction from the newly generated block (or from a previous block).

[0197] 3. GS shares its fingerprint transactions with other GS.

[0198] 4. GS generates elliptic curve block points.

[0199] 5. GS creates an overlay certificate for the corresponding data packet.

[0200] 6. Proof of data packet coverage shared between GS and users.

[0201] 7. GS shares the SPV proof of fingerprint transactions with users.

[0202] 8. Users check whether the coverage certificate and SPV certificate are correct.

[0203] In step 2, GSs can easily retrieve which fingerprint transactions within their own fingerprint transactions are located in the new block; however, they will need to scan the block to find the fingerprints of other GSs. Therefore, step 3 may not be necessary, but it would significantly simplify the work of GSs. In fact, while scanning the entire block is always a possible method for retrieving fingerprint transactions, it is computationally intensive, and therefore alternative solutions should be preferred.

[0204] GS Protocol and Block Creation Figure 12 The diagram illustrates the process by which the GS (Global Controller) agrees on fingerprint transactions contained in blockchain blocks and calculates the same block point: 1. GS from blocks Extract all fingerprint transactions.

[0205] 2. GS determines the data packet corresponding to the extracted fingerprint.

[0206] 3. GS performs hash processing on data packets.

[0207] 4. GS Calculation That is, the sum of these hashes.

[0208] 5. GS calculates elliptic curve points ,in It is the generator of the curve.

[0209] 6. GS checks whether they all calculated the same point. If they cannot reach an agreement, they will examine a set of fingerprints to find the differences.

[0210] 7. GS will use salt point Add to In the middle. The obtained point This is called a block point, and the associated private key is... .

[0211] 8. GS will publish the covered block headers to platforms such as GOvNet.

[0212] The following are some additional notes regarding the described protocol: ● The fingerprint extraction process may be performed by a single GS. In this case, there is no need to reach an agreement on block points.

[0213] ● In step 1, GSs do not need to scan the entire block to find fingerprint transactions; they only need to wait for each GS to convey the fingerprint it has added to the block.

[0214] ● Salting blocks is done to ensure that users cannot collude to deduce the associated private key.

[0215] ● Salinity It is deterministic (e.g., it can be related to blocks). (The shared secret hash of the cascaded block header).

[0216] ● Salting blocks is done to ensure that users cannot collude to deduce the associated private key.

[0217] ● Store the block points in the appropriate columns of the GS database and publish them to the security platform or send them to users. Assuming the secp256k1 curve is used, the daily data volume is less than 5KB.

[0218] ● If each GS is responsible for a different service of GOvNet, the protocol can be modified so that each GS calculates its own salted block point. Ultimately, the final block point can be the sum of all individual block points. Alternatively, different block points can be maintained for each service.

[0219] ● Covering block header contains block point And block header.

[0220] ● The overlay block header can be broadcast to all users of GOvNet.

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

[0222] Block Data packets included The overlay proof is generated by GS. The private key associated with the data packet is the value. The proof of coverage is a signature. GS sends the overwrite proof along with a reference to the block point to the user. The user can then check... Is it a point? A valid signature is used to verify the correctness of the overlay proof. The user is unaware of the signature. The associated private key.

[0223] 2.4.6 Data Packet Storage Packets are stored in the database of the relevant Service Controller (GS). The GS database can be a distributed database or multiple databases, each maintained by some GSs. In the former case, some (potentially all) GSs have write privileges, but read privileges may be limited to their own entries; this can be a stringent requirement when different GSs process different types of packets. The advantage of a distributed database is that it automatically ensures data synchronization and resolves conflicts. When it is necessary to differentiate between the different services provided by GOvNet, using multiple independent databases may be a suitable design choice.

[0224] Some information about the data packet is mandatory to store, while others are optional and depend on the architecture. Mandatory information includes the data packet, its overlay proof, fingerprint transaction, and its SPV proof. Optionally, metadata can be stored to aid in database queries. Metadata may include redundant information already contained in some mandatory fields, such as the public key used or the type of data packet. It may be permissible to store the entire document (either in plaintext or encrypted form). In this case, the GS database provides data access services. Otherwise, they only provide proof of document validity.

[0225] 2.4.7 Data Packet Verification This section discusses how users interact with each other to verify that a data packet has been added to the overlay network. Some checks apply to all data types, while others depend on the type of data packet. For example, if the data packet is a document creation packet, it is necessary to check whether the document matches the document given in the data packet and whether the document has expired.

[0226] This section focuses on type-independent checks. These checks include verifying coverage proofs and Merkle proofs of packets. Coverage proofs are proofs of packet merging within an overlay network. Figure 13 The following describes a typical interaction between two users, where Bob wants to check the coverage proof of one of Alice's data packets: 1. Bob requests proof of coverage of Alice's data (e.g., Alice's personal information) from Alice.

[0227] 2. Alice will send the data packet. Along with proof of coverage Send it to Bob.

[0228] 3. Bob's Examination Whether it is owned by Alice. This information can be retrieved using LDAP.

[0229] 4. Bob's Calculation Point and points ,in It is a generator of the curve.

[0230] 5. Bob's verification Is it related to the point? compatible.

[0231] 2.5 Use Cases This section focuses on specific types of data packets and how to apply the steps described in the preceding sections in these cases.

[0232] 2.5.1 Document-type data packets Document-type data packets (or simply document data packets) are a general term encompassing a wide range of data packet types related to document creation, publication, and updating. Different types of documents require different types of interaction between parties and may have different structures. Some common characteristics of this type of data packet are as follows: ● Expiration Date: Documents may expire after a certain period of time, or they may expire if certain conditions are not met.

[0233] ● Document version control: Documents may need to be modified over time, such as housing registration data.

[0234] ● Multi-signature: A document may need to be signed by multiple parties, and sometimes these signatures must be generated in a specific order.

[0235] ● Editable content: Contracts and other documents may need to be editable to allow for the selective disclosure of data contained therein.

[0236] 2.5.1.1 Document type data packet information This section describes the minimum information that a document data packet should contain to be complete and valid. For verification purposes, some supplementary and optional metadata may be provided to the GS. The required metadata (if any) and supporting information (e.g., proof of coverage) for the data packet are then stored in the GS database.

[0237] Mandatory data includes: ● Document data packet flag, which identifies a data packet as containing a document.

[0238] ● Document sub-flags, which describe the document type contained in the data packet. Document sub-flags describe the structure and authentication strategy of the rest of the data packet.

[0239] ● The document's hash value. Documents can be hashed to allow for the removal of portions of their content.

[0240] ● Associated signatures. Signatures should indicate the portion of the document they reference. For example, some signers can verify not only the document's hash but also some of the already generated signatures.

[0241] The following additional information can be added to this data: ● The entire document in plain text format. This is especially useful if the GS database provides an archival solution for document recovery.

[0242] ● Information about the signer. This data is not required, as it can be inferred using LDAP services, but providing it can reduce the computational burden on GS.

[0243] ● Supports data packet references for documents. This type of information may be needed when updating documents.

[0244] 2.5.1.2 Incomplete document data package Document packets are considered complete if they contain all the required signatures of a valid document; incomplete packets lack some of these signatures. Document packets submitted to GOvNet do not need to be complete. This is allowed for several reasons: users may not know which agencies are required for certain documents, or users may need to prove they have initiated the correct processing for a document and are awaiting confirmation of their information from the relevant agencies. Therefore, generating a complete document packet may involve passing through various intermediate incomplete document packets, each with one or more signatures added.

[0245] The fact that a document data packet is incomplete can be indicated by an appropriate flag. Apart from this flag, incomplete document data packets behave like any other data packet, and therefore their lifecycle follows the same steps. If a document data packet is incomplete, a fingerprint transaction with multiple spendable outputs can be created. In this way, spending the first input indicates that the document has been received by the first signatory, spending the second input indicates that the document has been approved by the second signatory, and so on. Once all signatures have been collected and the fingerprint transaction corresponding to the incomplete data packet has been spent, the user receives a data packet containing the valid document.

[0246] According to the GOvNet strategy, the incomplete packet chain generated for a document depends on the document type. The fingerprint transactions associated with incomplete packets are no different from regular fingerprint transactions.

[0247] 2.5.1.3 Creating a document data package This section describes the creation of the document data package. As mentioned in the previous section, this process can occur multiple times before a document becomes effective. The main difference from standard data package creation is an additional step used to check whether the new document conflicts with an old document (or a copy thereof). Two documents can conflict in several ways, such as two unique identity documents associated with the same user. In this case, the focus is on GOvNet's internal consistency. Other types of conflicts are checked by the relevant authorities during the signing process.

[0248] Figure 14 An exemplary process for creating a document data package is shown.

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

[0250] 2. The terminal generates the document data package template requested by Alice.

[0251] 3. The terminal distributes the data packet template to a third party that signs the template.

[0252] 4. Once the signatures have been collected, send the completed data packet to GOvNet.

[0253] 5. GOvNet checks whether a document conflicts with other documents via LDAP service.

[0254] 6. GOvNet performs routine correctness checks on the documents.

[0255] If the new data packet conflicts with the old one, it will be returned to Alice. She can then decide whether to update the old packet or withdraw the submission. While unintentional mistakes should not be punished, users who maliciously repeat the error may have their access suspended or their authorization revoked.

[0256] 2.5.1.4 Updated Documentation The updated document contains references to data packets from previous versions of the document. Its fingerprint transaction can be spent, and the relevant authority verifies that the new and old versions of the document are consistent. Once the data packet is complete and checked by GS, the old fingerprint transaction is spent, and a new fingerprint transaction is generated.

[0257] While it would be helpful for users to provide a reference to the document they want to update, this is unnecessary, as the document can be retrieved by querying the LDAP server. If the LDAP server maintains data on the user's active document types, a new packet can replace an old one, or a new packet can be added to the commitment chain. The advantage of packet chaining is that if an expired document is referenced elsewhere on the network, a link to the latest version can be found. The main disadvantage is that this increases storage requirements.

[0258] 2.5.1.5 Document Validity A common user interaction is checking the validity of another user's document. This is essentially packet validation, but with some use case-specific modifications. Based on the discussion above, the document packet is validated through three independent steps: ● Use overlay proofs to verify whether a packet has been added to the overlay network; ● Ensure that the spending status of the fingerprint transaction indicates that the document is still valid; and ● Prove that the data packet contains the document under consideration.

[0259] The cost status of one or more outputs in a fingerprint transaction can be used to provide updates about the document's state. The meaning of the number of outputs and their cost status in a fingerprint transaction depends on the document type.

[0260] The final step in the validity check involves verifying whether the document and the data packet are consistent with each other. If the prover shares the entire document, the verifier only needs to hash the entire document and check whether it matches the hash of the document stored in the data packet.

[0261] However, document owners may prefer to share only certain relevant information with the verifier. Selective disclosure of documents is discussed in UK patent application GB2307275.4, the full text of which is incorporated herein by reference. The technology disclosed in GB2307275.4 can be summarized as follows: instead of hashing the entire document, different parts of the document are hashed and treated as leaves of a Merkel tree, with the root being the data contained in the data packet. If the document owner uses this procedure to save a fingerprint of the document, they can now disclose only portions of the document and the Merkel proof to prevent their data from being leaked.

[0262] 2.5.2 CBDC type data packets The government-covered network provides a natural framework for implementing CBDC. A CBDC transaction is essentially a data packet, and its implementation ensures it shares the same characteristics as cash transactions. GOvNet is independent of the design choices of the CBDC system. The lifecycle of CBDC-type data packets is similar to that of document-type data packets, with the main difference being in correctness checks. In fact, the correctness of CBDC data packets also includes checking whether the spender has sufficient assets to support the transaction.

[0263] The fingerprint transaction associated with the expenditure and the CBDC type data packet can be used as a way for the recipient to confirm receipt of funds.

[0264] 2.5.3 Tax Filing and Licensing Embodiments of this disclosure can be used to store tax-related data. For example, companies and / or individuals can use GOvNet to file tax returns, submit invoices, provide proof of tax payment, etc. For individuals, GOvNet can perform checks to ensure that tax-related data meets certain criteria. For example, users filing tax returns may need to provide entries for different types of taxable income: wages, bonuses, dividends, investment returns, rent, etc.

[0265] Similarly, overlay networks can be used to record licenses. For example, network nodes can be dedicated to recording television licenses or business licenses (e.g., licenses to trade certain goods). Businesses can use proof of their license storage to demonstrate to regulators that they have indeed obtained the licenses. Other types of licenses can be stored on the network, such as intellectual property licenses. Overlay servers can verify whether a license for the same IP address has not yet been granted (at least in the case of exclusive licenses).

[0266] 2.5.4 Land and Vehicle Registration Overlay networks can be used to store data related to land and / or vehicle ownership and any changes in said ownership. For example, each data packet may contain a separate land or vehicle registration, or a transfer of ownership of a piece of land or vehicle. GOvNet can perform verification steps, for example, to ensure that a piece of land is not sold twice (unintentionally or fraudulently). To do this, GOvNet may verify whether the same land is already on an overlay network indicated to be owned by someone else. Users can use evidence (stored proof) to verify whether the seller of the land or vehicle is the legal owner of that land / vehicle.

[0267] 2.5.5 Documentation Proof GOvNet can also be used to prove certain things about a document (e.g., the document exists, or the document contains certain data or meets certain requirements) without revealing the document itself.

[0268] In an example of age checks upon entering a venue (e.g., a bar, nightclub, etc.), people might want to prove they are 18 or older without revealing their actual age or any other information contained on their ID. In this case, a cover certificate can be provided at the venue entrance. Security personnel can use this certificate to verify with GOvNet whether GOvNet has accepted the document, and GOvNet can confirm the user is 18 or older without revealing any details. Because security personnel trust GOvNet, no additional checks are required. Other similar use cases include visas allowing owners entry into a country.

[0269] 3. Exemplary System Overview A blockchain is a distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely publicized. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Apart from the so-called "coinbase transaction," each transaction points to a previous transaction in a sequence that can span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is often called "mining," which involves each of the multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on a defined, ordered, and verified set of pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of a block can be achieved by publishing only the block header.

[0270] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing timestamped entries; and / or sorting index pointers by time. Additional layered functionalities on the blockchain can also be implemented. For example, blockchain protocols can allow the storage of additional user data or data indexes within transactions. There is no pre-specified limit to the maximum data capacity that can be stored in a single transaction, thus allowing increasingly complex data to be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0271] In the "output-based" model (sometimes called the UTXO-based model), a given transaction's data structure includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of digital assets, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions necessary to verify and transfer digital tokens or assets. Each input to a transaction (other than coinbase transactions) includes a pointer (i.e., a reference) to such outputs in a previous transaction and may also include an unlocking script used to unlock the locking script pointing to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets and includes a locking script defining one or more conditions for unlocking that output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0272] In this model, when a second (target) transaction is sent to the blockchain network for propagation and recording, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the conditions defined in one or more of the locking script of the first transaction. Another condition will be that the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid based on any of these conditions will not propagate the transaction (as a valid transaction, but possibly registering it as invalid) nor include it in a new block to be recorded in the blockchain.

[0273] Another transaction model is the account-based model. In this case, the amount of each transaction is not defined by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes and is continuously updated.

[0274] Figure 1 An exemplary system 100 for implementing blockchain 150 is shown. System 100 may include a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 (typically referred to as “miners”), which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0275] Each blockchain node 104 includes peer computer devices, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), as well as other devices, such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory cells that employ one or more memory media, such as magnetic media like hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0276] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Rather, blockchain 150 can be pruned as long as each blockchain node 150 stores the block header of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a specific transaction protocol throughout.

[0277] Blockchain node 104 can be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Blockchain node 104 can be configured to create block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. Blockchain node 104 can also maintain an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as a “mempool.” In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of transactions that node 104 has accepted as valid, and for that set of transactions, node 104 is forced not to accept any other transactions attempting to spend the same output.

[0278] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when the current transaction 152j is created or even sent to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0279] Due to the resources involved in transaction verification and publication, each blockchain node 104 typically takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a single user terminal or a networked set of user terminals.

[0280] Each blockchain node 104's memory stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed herein to the blockchain node 104 can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or lower layers such as the operating system layer or protocol layer, or any combination of these layers.

[0281] Any given blockchain node can be configured to perform one or more of the following operations: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node can be specialized for a particular operation. For example, node 104 can focus on transaction verification and propagation, or it can focus on block mining. In some examples, blockchain node 104 can perform more than one of these operations in parallel. Any reference to blockchain node 104 can refer to the entity configured to perform at least one of these operations.

[0282] The computer devices 102 of each of the multiple parties 103, acting as consumer users, are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities storing copies of the blockchain 150 (e.g., having already obtained a copy of the blockchain from blockchain node 104).

[0283] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be considered part of the system containing blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required for blockchain nodes. Instead, each party 103 may interact with blockchain network 106 to utilize blockchain 150 by connecting to blockchain node 106 (i.e., communicating with blockchain node 106). For illustrative purposes, parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in system 100, but are not shown for convenience. Each party 103 may be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob in this document, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document may be replaced by "first party" and "second party" respectively.

[0284] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0285] The client application 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0286] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the respondent 103 to create, authorize (e.g., sign) transactions 152 and send them to one or more Bitcoin nodes 104, which then propagate through the network of blockchain nodes 104, thus being included in blockchain 150. The other function is to report to the respondent the amount of digital assets they currently possess. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0287] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API interface or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

[0288] An instance of client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also liaise with blockchain node 104 to query blockchain 150 for any transaction in which the corresponding party 103 is the recipient (or actually to check other parties' transactions in blockchain 150, since, in this embodiment, blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transaction 152 according to a blockchain node protocol and forward transaction 152 for propagation in blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. All nodes 104 in network 106 use the same node protocol.

[0289] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the network's nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0290] Some account-based transaction models share similarities with the output-based transaction model described in this paper. For example, as mentioned above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction referencing the output point of the previous transaction. Therefore, both models support chaining between transactions. As another example, an account-based transaction includes a "recipient" field (specifying the account's receiving address) and a "value" field (specifying a certain amount of digital assets). The recipient and value fields together are equivalent to the output of an output-based transaction, which can be used to allocate a certain amount of digital assets to a blockchain address. Similarly, account-based transactions have a "signature" field, which includes the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the transaction's signature. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine if the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contract" refers to a transaction containing a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions. Therefore, in some examples, a smart contract can be viewed as equivalent to a locking script for an output-based transaction (which can be triggered by a subsequent transaction) that checks whether the inputs of the subsequent transaction satisfy one or more conditions defined in the locking script.

[0291] 4. UTXO-based model Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments. It should be noted that while an exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other example blockchain networks.

[0292] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction, as well as other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 committed to node 104.

[0293] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's New Affairs 152j is marked as " Tx 1 The new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In the middle, the previous transaction 152i is marked as " Tx 0 ". Tx 0 and Tx 1 It is just an arbitrary marker, and it does not necessarily mean Tx 0 The first transaction in Blockchain 151 and Tx 1 Subsequent transactions in pool 154. Tx 1 It can point to any previous (i.e. preceding) transaction that still has an unspent output 203 locked to Alice.

[0294] As used in the context of transaction sequences in this article, the terms "previous" and "subsequent" refer to the order of transactions in a sequence defined by the transaction pointers specified within the transaction (which transaction points to which other transaction, etc.). They can also be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") that point to a previous transaction (ancestor transaction or "parent") are not valid unless the parent transaction is valid. Children arriving at blockchain node 104 before their parents are considered orphaned. Depending on the node protocol and / or node behavior, they may be discarded or buffered for a period of time to wait for their parents.

[0295] Previous matters Tx 0 One or more outputs 203 include a specific UTXO, tagged as UTXO 0 Each UTXO includes a value representing the amount of digital assets and a locking script that defines the conditions that the unlocking script in input 202 of a subsequent transaction must meet to make the subsequent transaction valid and thus successfully redeem the UTXO.

[0296] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (with an uppercase S), which can be used by the blockchain network. The locking script specifies the information required for the transaction output 203, such as Alice's signature requirement. The locking script appears in the transaction output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0297] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for the purpose of enabling those who attempt to redeem) UTXO 0 (Subsequent transactions are valid). [Checksig P A Contains the public key from Alice's public-private key pair. PA The representation of (i.e., hash). Tx 1 Input 202 includes pointers to Tx 1 pointers (e.g., via their transaction IDs) TxID 0 In the implementation example, this refers to the entire transaction. Tx 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo UTXO 0 The index, in order to Tx 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0298] When new transactions Tx 1 Upon reaching blockchain node 104, the node applies the node protocol. This includes running the locking and unlocking scripts together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria).

[0299] It should be noted that script code is typically represented graphically (i.e., using a non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For instance, OP_RETURN is a scripting language opcode. When OP_FALSE is added before the opcode at the beginning of the locking script, the opcode creates a non-spendable output for the transaction. This output can store data within the transaction, thus immutably recording the data in the blockchain. For example, the data may include files that need to be stored in the blockchain.

[0300] Typically, the input to a transaction contains a digital signature corresponding to the public key PA. In this embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature, used to select the output to be signed (and thus fixed at the time of signing).

[0301] Locking scripts are sometimes called "scriptPubKey," referring to the fact that they typically include the public keys of the parties to whom the corresponding transaction is locked. Unlocking scripts are sometimes called "scriptSig," referring to the fact that they typically provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

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

[0303] For example, some of the embodiments described above have been based on Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 above can be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the characteristics described above for Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104.

[0304] In a preferred embodiment of the invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that other network entities (or network elements) may perform only one or some of these functions, but not all of them. That is, network entities may perform the function of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered nodes of the preferred Bitcoin network 106).

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

[0306] To put it even more colloquially, any reference above to the term "Bitcoin node" 104 can be replaced by the terms "network entity" or "network element," where such an entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element can be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0307] Some embodiments have been described based on a blockchain network used to implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is merely one type of consensus mechanism, and in general embodiments, any suitable consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is typically called a validator. Blockchain nodes can lock their tokens for a period of time to have the opportunity to become a validator. Generally, the node that locks the largest amount of tokens for the longest time is most likely to become the next validator.

[0308] It should be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided based on any one or more of the following statements.

[0309] Statement 1. A computer-implemented method for 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: Receive requests to store data items from the first user; Submitting a commitment transaction to one or more blockchain nodes in a blockchain network and / or causing the commitment transaction to be recorded on the blockchain, wherein the commitment transaction includes a commitment to the data item; Storing and / or publishing the data item and / or the commitment regarding the data item; as well as, Provide the first user with a storage proof, which is generated in response to the commitment transaction being submitted to the one or more blockchain nodes and is generated as a function of the data item, the storage proof serving to prove that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0310] The storage proof is not proof that the committed transaction has been recorded on the blockchain. For example, the storage proof is not an SPV proof. Furthermore, the storage proof is not a function of the committed transaction.

[0311] Statement 2. The method according to Statement 1, the method comprising: providing a blockchain proof to the first user, the blockchain proof being used to prove that the committed transaction has been recorded on the blockchain.

[0312] Statement 3. The method described in statement 2, wherein the blockchain proof includes a Simple Payment Verification (SPV) proof.

[0313] Statement 4. The method according to any of the preceding statements, wherein the storage proof includes 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.

[0314] Statement 5. The method according to any of the preceding statements, wherein the commitment of the data item includes at least the hash of the data item.

[0315] Statement 6. The method according to statement 5, wherein the commitment of the data item includes at least the hash of the data item and the salt.

[0316] Statement 7. The method according to any of the preceding statements, wherein the commitment of the data item includes an encrypted version of the data item.

[0317] Statement 8. The method according to any of the preceding statements, 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.

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

[0319] Statement 10. The method according to any of the preceding statements, wherein the committed transaction includes a transaction version number associated with the storage network.

[0320] Statement 11. The method described according to statements 9 and 10, wherein the obfuscated version of the identifier is generated based on the transaction version number of the committed transaction.

[0321] Statement 12. The method according to statement 10 or any of its dependent statements, the method comprising: providing the first user with at least one of the following: the identifier, the obfuscated version of the identifier, and / or information for calculating the identifier and / or the obfuscated version.

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

[0323] Statement 14. The method according to any of the preceding statements, the method comprising: verifying whether the first user is authorized to request that the data item be stored by the storage provider, and wherein the submission and / or the storage is conditional upon the verification.

[0324] Statement 15. The method described in statement 14, wherein the verification includes: verifying whether the first user is associated with the authorized public key.

[0325] Statement 16. The method according to any of the preceding statements, the method comprising: verifying whether the data item has a predefined structure, and wherein the submission and / or the storage is conditional upon the verification.

[0326] Statement 17. The method according to any of the preceding statements, the method comprising: verifying whether the data item is signed by one or more predetermined parties, wherein the submission and / or the storage is conditional upon the verification.

[0327] Statement 18. The method according to any of the preceding statements, wherein the storage provider is associated with a specific type of data and / or a data application, and wherein the method includes: verifying whether the data item is the specific type and / or application, wherein the submission and / or the storage is conditional upon the verification.

[0328] Statement 19. The method according to any of the preceding statements, the method comprising: sending the data item and / or the commitment of the data item to different users.

[0329] Statement 20. The method according to statement 8 or statement 19, wherein sending a request in response to the commitment to the data item and / or the data item, wherein the request includes the storage proof, and wherein the method includes: using the storage proof to identify the data item and / or the commitment to the data item.

[0330] Statement 21. The method according to any of the preceding statements, the method comprising: Generating elliptic curve block points, the generation process includes: Hash one or more corresponding data items to generate one or more corresponding hashed data items. The corresponding hashed data items are summed to generate a total value. The first elliptic curve point is calculated based on the sum value, and the elliptic curve block point is based on the first elliptic curve point; and, The storage proof includes a signature generated using a corresponding private key based on the sum value and the corresponding hashed data item.

[0331] Statement 22. The method according to statement 21, wherein generating the elliptic curve block points comprises: generating a second elliptic curve based on a salt value, wherein the elliptic curve points are based on the second elliptic curve points, and wherein the storage proof includes the salt value.

[0332] Statement 23. The method described according to any of the preceding statements, the method comprising: The commitment transaction is verified in accordance with one or more rules of the blockchain protocol, wherein submitting the commitment transaction to the one or more blockchain nodes and / or recording the commitment transaction on the blockchain are conditional upon verification of the commitment transaction.

[0333] Statement 24. A computer-implemented method, the method being performed by a first user, the method comprising: Send data items to the storage provider; From the storage provider, a storage certificate is received, which proves that the data item and / or the commitment to the data item has been accepted by the storage provider for storage.

[0334] Statement 25. The method according to statement 24, the method comprising: receiving a blockchain proof from the storage provider, the blockchain proof being used to prove that a commitment transaction including the commitment of the data item has been recorded on the blockchain.

[0335] Statement 26. The method described according to statement 24 or 25, the method comprising: The storage certificate is used to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage, and / or the storage certificate is sent to a second user to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0336] Statement 27. The method according to Statement 25 or any of its dependent statements, the method comprising: using the blockchain proof to verify whether the committed transaction has been recorded on the blockchain, and / or sending the blockchain proof to a second user to verify whether the committed transaction has been recorded on the blockchain.

[0337] Statement 28. The method described according to statement 24 or any of its dependent statements, the method comprising: Verify whether the data items contained in the committed transaction match the data items sent to the storage provider; and / or, Verify whether the commitment of the data item contained in the commitment transaction corresponds to the data item sent to the storage provider.

[0338] Statement 29. The method according to any one of statements 24 to 28, the method comprising: Obtain one or more corresponding signatures from one or more corresponding pre-booking parties; and, Before sending the data item to the storage provider, the one or more corresponding signatures are included as part of the data item.

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

[0340] Statement 31. A computer-implemented method, the method being performed by a second user, the method comprising: Receive data items from the storage provider and / or the first user; Receive a blockchain proof from the storage provider and / or the first user, the blockchain proof being used to prove that: the commitment transaction including the commitment of the data item has been recorded on the blockchain; Receive a storage certificate from the storage provider and / or the first user, the storage certificate being used to prove that: the data item and / or the commitment of the data item has been accepted by the storage provider for storage; The blockchain proof is used to verify whether the committed transaction has been recorded on the blockchain, and / or the blockchain proof is sent to a second user to verify whether the committed transaction has been recorded on the blockchain; and / or, The storage certificate is used to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage, and / or the storage certificate is sent to a second user to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

[0341] Statement 32. The method described according to statement 31, the method comprising: Determine the state of the committed transaction; and, Information about the data item is determined based on the state of the committed transaction.

[0342] Statement 33. The method described according to statement 32, wherein the information includes the validity of the data item.

[0343] Statement 34. The method according to any one of statements 31 to 33, the method comprising: Verify whether the data items contained in the committed transaction match the data items sent to the storage provider; and / or, Verify whether the commitment of the data item contained in the commitment transaction corresponds to the data item sent to the storage provider.

[0344] Statement 35. A computer device, said computer device comprising: The memory, comprising one or more memory cells; and, A processing apparatus comprising one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute a method according to any one of statements 1 to 34 when run on the processing apparatus.

[0345] Statement 36. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of statements 1 to 34 when run on one or more processors.

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

Claims

1. A computer-implemented method for storing data, wherein the method is performed by a storage provider, wherein the storage provider is an entity outside of a blockchain node, and wherein the method comprises: Receive requests to store data items from the first user; Submitting a commitment transaction to one or more blockchain nodes in a blockchain network and / or causing the commitment transaction to be recorded on the blockchain, wherein the commitment transaction includes a commitment to the data item; Storing and / or publishing the data item and / or the commitment regarding the data item; as well as Provide the first user with a storage certificate, which is generated in response to the commitment transaction being submitted to the one or more blockchain nodes and is generated based on the data item, the storage certificate being used to prove that the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

2. The method according to claim 1, wherein the method comprises: Provide the first user with a blockchain proof, which proves that the committed transaction has been recorded on the blockchain.

3. The method of claim 2, wherein the blockchain proof includes a Simple Payment Verification (SPV) proof.

4. The method according to any one of the preceding claims, 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 according to any one of the preceding claims, wherein the commitment of the data item includes at least the hash of the data item.

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

7. The method according to any one of the preceding claims, wherein the commitment of the data item includes an encrypted version of the data item.

8. The method according to any one of the preceding claims, wherein the storage provider is one of a plurality of storage providers maintaining a storage network, and wherein the method comprises: Send the data item and / or the commitment to 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 includes the identifier, or a confused version of the identifier generated by a hash of at least the identifier and the commitment of the data item.

10. The method according to any of the preceding claims, wherein the committed transaction includes a transaction version number associated with the storage network.

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

12. The method according to claim 10 or any dependent claim thereof, wherein the method comprises: Provide the first user with at least one of the following: the identifier, the obfuscated version of the identifier, and / or information for calculating the identifier and / or the obfuscated version.

13. The method according to any of the preceding claims, 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 according to any one of the preceding claims, wherein the method comprises: Verify whether the first user is authorized to request that the data item be stored by the storage provider, and wherein the submission and / or the storage is conditional upon the verification.

15. The method of claim 14, wherein the verification comprises: Verify whether the first user is associated with the authorized public key.

16. The method according to any one of the preceding claims, the method comprising: Verify whether the data item has a predefined structure, and wherein the submission and / or storage are conditional upon the verification.

17. The method according to any one of the preceding claims, wherein the method comprises: Verify whether the data item is signed by one or more pre-defined parties, wherein the submission and / or the storage are conditional upon the verification.

18. The method according to any one of the preceding claims, wherein the storage provider is associated with a specific type of data and / or data application, and wherein the method comprises: Verify whether the data item is of the specific type and / or application, wherein the submission and / or storage is conditional upon the verification.

19. The method according to any one of the preceding claims, the method comprising: Send the data item and / or the commitment of the data item to different users.

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

21. The method according to any one of the preceding claims, wherein the method comprises: Generating elliptic curve block points, the generation includes: Hash one or more corresponding data items to generate one or more corresponding hashed data items. The corresponding hashed data items are summed to generate a total value. The first elliptic curve point is calculated based on the sum value, and the elliptic curve block point is based on the first elliptic curve point; and The storage proof includes a signature generated using the corresponding private key based on the sum value and the corresponding hashed data item.

22. The method of claim 21, wherein generating the elliptic curve block points comprises: A second elliptic curve is generated based on the salt value, wherein the elliptic curve points are based on the second elliptic curve points, and wherein the storage proof includes the salt value.

23. The method according to any one of the preceding claims, wherein the method comprises: The commitment transaction is verified in accordance with one or more rules of the blockchain protocol, wherein submitting the commitment transaction to the one or more blockchain nodes and / or recording the commitment transaction on the blockchain are conditional upon verification of the commitment transaction.

24. A computer-implemented method, the method being performed by a first user, the method comprising: Send data items to the storage provider; From the storage provider, a storage certificate is received, which proves that the data item and / or the commitment to the data item has been accepted by the storage provider for storage.

25. The method of claim 24, wherein the method comprises: Receive a blockchain proof from the storage provider, the blockchain proof being used to prove that a commitment transaction including the commitment of the data item has been recorded on the blockchain.

26. The method according to claim 24 or 25, wherein the method comprises: The storage certificate is used to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage, and / or the storage certificate is sent to a second user to verify whether the data item and / or the commitment of the data item has been accepted by the storage provider for storage.

27. The method according to claim 25 or any dependent claim thereof, wherein the method comprises: The blockchain proof is used to verify whether the committed transaction has been recorded on the blockchain, and / or the blockchain proof is sent to a second user to verify whether the committed transaction has been recorded on the blockchain.

28. The method according to claim 24 or any dependent claim thereof, wherein the method comprises: Verify whether the data items contained in the committed transaction match the data items sent to the storage provider; And / or Verify whether the commitment of the data item contained in the commitment transaction corresponds to the data item sent to the storage provider.

29. The method according to any one of claims 24 to 28, the method comprising: Obtain one or more corresponding signatures from one or more corresponding pre-ordering parties; as well as Before sending the data item to the storage provider, the one or more corresponding signatures are included as part of the data item.

30. The method according to any one of claims 24 to 29, the method comprising: Before sending the data item to the storage provider, the data item is structured according to a predefined structure.

31. A computer-implemented method, the method being executed by a second user, the method comprising: Receive data items from the storage provider and / or the first user; Receive a blockchain proof from the storage provider and / or the first user, the blockchain proof being used to prove that a commitment transaction including the commitment of the data item has been recorded on the blockchain; Receive a storage certificate from the storage provider and / or the first user, the storage certificate being used to prove that the data item and / or the commitment of the data item has been accepted by the storage provider for storage; The blockchain proof is used to verify whether the committed transaction has been recorded on the blockchain; And / or The storage proof is used to verify whether the data item and / or the commitment to the data item have been accepted by the storage provider for storage.

32. The method according to claim 31, wherein the method comprises: Determine the status of the committed transaction; as well as Information about the data item is determined based on the state of the committed transaction.

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

34. The method according to any one of claims 31 to 33, the method comprising: Verify whether the data items contained in the committed transaction match the data items sent to the storage provider; And / or Verify whether the commitment of the data item contained in the commitment transaction corresponds to the data item sent to the storage provider.

35. A computer device, the computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 34 when run on the processing apparatus.

36. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 34 when run on one or more processors.

Images