Selective Existence Proofs Using Ordered Append-Only Data Storage

Abstract

A computer-implemented method is provided for generating an existence proof data structure. The method includes the steps of: (i) receiving a request comprising a data visualization path, the data visualization path referencing a node of interest in an input hierarchical data structure; (ii) obtaining an input hierarchical data structure comprising an input root node and a plurality of input nodes, each of the input nodes in the input hierarchical data structure having an associated value; and (iii) generating an output hierarchical data structure based on the data visualization path and the input hierarchical data structure, the output hierarchical data structure comprising a plurality of output nodes. A method for verifying an existence proof is also provided.

Description

[Technical field]

[0001] The present disclosure relates to methods, systems, and data structures for implementing a platform for one or more services related to a distributed ledger, i.e., blockchain, for one or more clients. More specifically, but not by way of limitation, the present disclosure relates to providing data storage and validating data storage related to blockchain. [Background technology]

[0002] Blockchain refers to a form of distributed data structure, where a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain comprises a chain of blocks of data, where each block comprises one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to the preceding transaction in the sequence, which may span one or more blocks, up to one or more coinbase transactions. Coinbase transactions are discussed below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining", which involves multiple nodes each competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated outstanding transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at the nodes, and publication of blocks may be accomplished by publishing only the block headers.

[0003] A transaction in a blockchain is used to perform one or more of the following: carry digital assets (i.e., a number of digital tokens), order a set of journal entries in a virtualized ledger or register, receive and process timestamp entries, and / or time order index pointers. A blockchain may also be utilized to overlay additional functionality onto the blockchain. Blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. Since there is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, increasingly complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data in the blockchain.

[0004] Nodes of a blockchain network (often called "miners") perform a decentralized transaction registration and validation process, which is described in detail below. In summary, during this process, nodes validate transactions and insert them into a block template, and the nodes attempt to identify a valid proof-of-work solution for that block template. Once a valid solution is found, the new block is propagated to other nodes in the network, thus allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends it to one of the nodes of the network so that it is propagated. Nodes receiving a transaction can compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into a block. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every spendable output comprises an element that specifies an amount of a digital asset that is derivable from a preceding sequence of transactions. A spendable output may be referred to as a UTXO (an “unspent transaction output”). An output may further comprise a locking script that specifies a condition for further redemption of the output. A locking script is a predicate that defines the condition required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) may comprise a pointer (i.e., a reference) to such output in a preceding transaction and further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, which we call a first transaction and a second transaction (or a “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one validity criterion applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is 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 according to any of these conditions will not disseminate the transaction (possibly not disseminate the invalid transaction as a valid transaction in order to register it) and will not include the transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored and periodically updated by a node separate from the blockchain.

[0009] One current area of ​​research is the use of blockchain for the implementation of "smart contracts". A smart contract is a computer program designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike traditional contracts, which are written in natural language, a smart contract is a machine-executable program with rules that can process inputs to produce outcomes, which can then cause actions to be performed that are dependent on those outcomes. Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Items that may be sensitive or secret can be represented with tokens that have no discernible meaning or value. Thus, the tokens act as identifiers that allow real-world items to be referenced from the blockchain.

[0010] The above mentioned examples or scenarios utilize the advantages of blockchain to provide a permanent and tamper-resistant record of events, but require the client, client entity, computing device, or terminal associated with the client to include or implement software and / or hardware, or processors / modules, such as implementing functionality for managing digital assets, e.g., a digital wallet for managing cryptographic keys for the Elliptic Curve Digital Signature Algorithm (ECDSA) used by the BSV (Bitcoin Satoshi's Vision) blockchain. In addition, it is also required that the client device is capable of constructing blockchain transactions and has access to BSV libraries. Thus, the client must not only include processing to implement such functionality, but also ensure that appropriate security measures are in place for such processing before being able to utilize the blockchain to send, receive, and view data and / or digital assets related to smart contracts or tokens representing real-world asset transactions.

[0011] Therefore, there is a need to implement a secure, uncomplicated, user-friendly, efficient, and robust technique that allows any client, regardless of its computational power, to instantly access and interact with useful applications related to blockchain in a computationally and functionally undemanding, simple, fast, accurate, reliable, and secure manner. More specifically, there is a need to utilize distributed ledger (blockchain) technology and the advantages of increased security, transparency, and reliability of records to provide a common platform or interface for multiple blockchain-related services or applications that allows any client computing device to ensure that any data, event, or digital asset related to the client can be instantly and securely mined or easily written to the blockchain, thereby providing a permanent, tamper-resistant, and auditable record thereof that can be created, written, updated, read, or viewed as needed. Furthermore, it may be desirable to group such data so that transactions can be investigated according to groups or related to each other differently as they exist on the blockchain.

[0012] Such an improved solution has been devised. The present disclosure addresses the above technical problems by proposing one or more techniques such that data or information related to a client may be written to or retrieved from a blockchain easily, securely, and instantly by methods, devices, and systems that provide an application programming interface (API) for one or more services related to the blockchain, without the client having to implement any process or functionality to use the blockchain, yet still be able to take advantage of all the benefits associated with the blockchain. [Prior art documents] [Patent documents]

[0013] [Patent Document 1] UK Patent Application No. 2204293.1 [Patent Document 2] UK Patent Application No. 2002285.1 Summary of the Invention [Means for solving the problem]

[0014] According to a first aspect, the present disclosure proposes a computer-implemented method, device, and system for providing a proof of existence, the method comprising: (i) receiving a request comprising a data reveal path, the data reveal path referencing a node of interest in an input hierarchical data structure; (ii) obtaining an input hierarchical data structure comprising an input root node and a plurality of input nodes, each of the input nodes in the input hierarchical data structure having an associated value; and (iii) generating an output hierarchical data structure based on the data visualization path and the input hierarchical data structure, the output hierarchical data structure comprising a plurality of output nodes, each of the plurality of output nodes having an associated node in the input hierarchical data structure, the plurality of output nodes comprising an output root node and an output node of interest related to the node of interest in the input hierarchical data structure, the output node of interest and each ancestor node of the output node of interest comprising a value, and every other node in the output hierarchical data structure comprising a digest based on the associated value of a corresponding node of the input hierarchical data structure.

[0015] According to a second aspect, the present disclosure proposes a computer-implemented method, device, and system for providing a proof of existence, the method comprising: (i) obtaining an input root digest from a blockchain; (ii) obtaining a data visibility path, the data visibility path referencing a node of interest in the input hierarchical data structure; (iii) obtaining an output hierarchical data structure comprising a plurality of nodes, each of the plurality of nodes corresponding to a node in the input hierarchical data structure; (iv) calculating a digest for a node of the output hierarchical data structure corresponding to the data visibility path; (v) calculating a digest associated with each ancestor of the node corresponding to the data visibility path until there are no more ancestor nodes, the topmost digest being the output root digest; and (vi) verifying a value of the node of interest based on a comparison between the input root digest and the output root digest.

[0016] According to a third aspect, the present disclosure proposes a computer-implemented method, device, and system for generating and storing a representation of a client data item related to a set of data items, the method comprising: (i) receiving a request comprising client data relating to a current state; (ii) obtaining a set of child nodes, the child nodes being based on the client data, metadata relating to the client data, a first reference to a previous data item in the set of data items, and a second reference to a next data item in the set of data items; (iii) generating a hierarchical data structure based on a plurality of child nodes, the hierarchical data structure comprising a root node, and a majority of the child nodes being obtained prior to generation of the hierarchical data structure; and (iv) storing the root node for subsequent retrieval.

[0017] Certain specific components and embodiments of the disclosed method will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numerals refer to like features and in which: [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 illustrates an exemplary system for implementing a blockchain. [Diagram 2] FIG. 2 illustrates an example transaction protocol. [Figure 3A] FIG. 2 illustrates an exemplary implementation of a client application and its interface. [Figure 3B] FIG. 2 illustrates an exemplary implementation of a client application and its interface. [Figure 4] FIG. 1 illustrates an example of node software running on each blockchain node in the network. [Diagram 5] FIG. 1 is a schematic diagram outlining a chain of transactions and corresponding log entries. [Figure 6A] 4 is an example hierarchical data structure generated in accordance with aspects described herein. [Figure 6B] 4 is an example hierarchical data structure generated in accordance with aspects described herein. [Figure 6C] 4 is an example hierarchical data structure generated in accordance with aspects described herein. [Figure 6D] 4 is an example hierarchical data structure generated in accordance with aspects described herein. [Figure 6E] 4 is an example hierarchical data structure generated in accordance with aspects described herein. [Figure 7] FIG. 2 illustrates a method for generating a hierarchical data structure. [Figure 8A] FIG. 13 illustrates a further method for generating a further hierarchical data structure. [Figure 8B] FIG. 8B illustrates an exemplary further hierarchical data structure as may be generated according to method 8A. [Figure 9] FIG. 1 illustrates an exemplary method for validating a proof of existence of a value. [Figure 10A]FIG. 1 illustrates an exemplary method for generating several different hierarchical data structures. [Figure 10B] FIG. 1 illustrates an exemplary method for generating several different hierarchical data structures. [Figure 10C] FIG. 1 illustrates an exemplary method for generating several different hierarchical data structures. [Figure 10D] FIG. 1 illustrates an exemplary method for generating several different hierarchical data structures. [Figure 11] FIG. 1 is a schematic diagram illustrating an overview of a platform for multiple blockchain-related services, according to an embodiment. [Figure 12] FIG. 1 is a schematic diagram illustrating components of a platform for blockchain-related services, according to an aspect. [Figure 13] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure may be implemented. [Figure 14] FIG. 2 is a schematic diagram illustrating components of a multi-service platform according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] According to a first aspect, the present disclosure proposes a computer-implemented method for providing a proof of existence, the method comprising: (i) receiving a request comprising a data visualization path, the data visualization path referencing a node of interest in an input hierarchical data structure; (ii) obtaining an input hierarchical data structure comprising an input root node and a plurality of input nodes, each of the input nodes in the input hierarchical data structure having an associated value; and (iii) generating an output hierarchical data structure based on the data visualization path and the input hierarchical data structure, the output hierarchical data structure comprising a plurality of output nodes, each of the plurality of output nodes having an associated node in the input hierarchical data structure, the plurality of output nodes comprising an output root node and an interesting output node related to the node of interest in the input hierarchical data structure, the interesting output node and each ancestor node of the interesting output node comprising a value, and all other nodes in the output hierarchical data structure comprising a digest based on the associated value of a corresponding node of the input hierarchical data structure.

[0020] Advantageously, the output hierarchical data structure provides a structure that reveals only values ​​of interest and not other values, but still allows for proof that the values ​​were the values ​​used in creating the input hierarchical data structure. Hiding the other values ​​improves the security of the overall system, as some of the other metadata components may be sensitive (e.g., may include information such as which user submitted the data or when the data was submitted).

[0021] Optionally, the digest associated with the input root node and the digest associated with the output root node are the same. Optionally, the validity of the node of interest is determined based on a comparison of the input root node and the output root node.

[0022] Advantageously, the values ​​associated with each root node are the same, allowing for easy comparison and therefore verification. Furthermore, having both digests allows for a smaller data footprint when storing the input root nodes. This is especially important when storing input root node digests in the blockchain, where transaction size is directly related to cost and processing time.

[0023] Optionally, the method further comprises recording data based on the input root node in the blockchain. Preferably, the data based on the root node of the input hierarchical data structure is a digest based on the input root node.

[0024] Advantageously, storing data based on the input root node in the blockchain allows a third party in a trustless environment to trust that said data based on the input root node has not changed since it was recorded in the blockchain (i.e., when the original client data was received and the input hierarchical data structure was created), thereby increasing the security and reliability of the system with respect to verification. Blockchain provides an immutable, persistent, tamper-resistant storage system for any data.

[0025] Optionally, the output node corresponding to the data visualization path, and all ancestor nodes of the output node corresponding to the data visualization path in the output hierarchical data structure, further comprise a salt. Preferably, the salt is based on a randomly generated value.

[0026] Advantageously, salting the data provides resistance to "rainbow table" attacks, thereby increasing the security of the data structure and the data stored therein. Salting based on a randomly generated value provides additional security by making rainbow tables more difficult to build. Given that the salt is known and predicted, the rainbow can be calculated using the known or predicted salt value. Using the same salt for the entire input hierarchical data structure saves storage space on the off-chain data store.

[0027] Preferably, each salt is based on the path of its associated node. More preferably, each salt is a digest based on a randomly generated value and the path of its associated node. Preferably, the salt is based on the path and / or a randomly generated value in a non-reversible manner such that the randomly generated value cannot be reversed.

[0028] Advantageously, making each salt path-based provides a way to add further defense against rainbow attacks, since even if a malicious third party somehow manages to reverse one of the hashes in the output hierarchical data structure (which is highly unlikely) to obtain the value and pathSalt, the malicious party would not know the salt and would need to reverse further hashes to obtain the salt. This therefore adds security to the data structure by making it more difficult to reverse any element of the data structure. During selective disclosure, salts (and especially pathSalts) can be revealed without exposing undisclosed nodes to brute force attacks. For example, if there is a single salt for the entire structure, an attacker can combine that salt with guessed values ​​for nodes that only have revealed digests until he finds a match.

[0029] Optionally, the step of generating an output hierarchical data structure comprises a step of walking through the input data structure starting at a root node of the input hierarchical data structure, and for each node in the walked input hierarchical data structure, if the node is a node of interest and / or an ancestor thereof, a value based on the node of the input hierarchical data structure is inserted in the output hierarchical data structure at the same corresponding position, and otherwise a digest based on the node of the input hierarchical data structure is inserted in the output hierarchical data structure at the same corresponding position.

[0030] Optionally, the step of generating the output hierarchical data structure comprises starting with a root node of the input hierarchical data structure as a current node, (a) determining whether the current node is a node of interest and / or an ancestor of the node of interest, and if so, generating a node in the output hierarchical data structure comprising a value associated with the current node and performing step (a) above for each child of the current node as the current node of the next iteration, and if not, generating a node in the output hierarchical data structure comprising a digest based on the value associated with the current node.

[0031] Optionally, generating the output hierarchical data structure comprises, for each given node in the input data structure, starting with the root node, performing: (i) based on a determination that the given node is a node of interest and / or an ancestor thereof, inserting a value based on the given node at a position in the output hierarchical data corresponding to the position of the given node in the input data structure; or (ii) based on a determination that the given node is a node of interest and / or an ancestor thereof, inserting a digest based on the value of the given node at a position in the output hierarchical data corresponding to the position of the given node in the input data structure.

[0032] Advantageously, shrinking the input data structure in this manner provides protection from traffic analysis of the output data.

[0033] Advantageously, the method discussed above provides a one-pass method for creating an output hierarchical data structure. The method is one-pass in that each node is accessed / traversed / visited only once to create the tree structure. This provides an efficient method for creating the data structure.

[0034] Optionally, the request comprises one or more data visualization paths, each data visualization path referencing a node of interest, each node of interest and all ancestors of the node of interest in the output hierarchical data structure comprising a value, and all other nodes in the output hierarchical data structure comprising a digest.

[0035] Advantageously, requests with multiple data visibility paths provide a way to reduce network traffic since multiple requests are no longer needed. Furthermore, for using an output hierarchical data structure for validation, the total number of digests that need to be computed to compute the root is likely to be smaller. This is because the same digest for the same node is likely to be computed multiple times when multiple output hierarchical data structures are used, whereas a node only needs to be computed once if it is in one data structure.

[0036] Optionally, the hierarchical data structure and / or the output hierarchical data structure are represented using JSON objects, preferably having a canonical format.

[0037] Advantageously, JSON provides a defined / prescribed, flexible, native hierarchical data format for representing hierarchical data structures. Furthermore, JSON provides a method for serializing said hierarchical data structures so that they can be transmitted and received in a given format. Providing a canonical format for JSON (or any data format used to represent hierarchical data structures) ensures that the same digest calculation is done with the correct data type / format. This is important because, like validation, the same digest needs to be generated for verification. Canonicalization provides a method to ensure that this happens every time, eliminating the need to try different data types to arrive at the correct format used in generation.

[0038] Optionally, each node of the output hierarchical data structure is a Merkle tree root, where a digest for each node, except for leaf nodes, may be computed based on the digests of its child nodes.

[0039] Optionally, the value of an ancestor node of an output node of interest is based on its child nodes. Optionally, the value of an ancestor node of an output node of interest is, comprises, or has an associated digest based on its child nodes. More preferably, the digest is based on a Merkle root hash encoded with all the strings of the digests of its child nodes. Optionally, the value of an ancestor node of an output node is a digest that is a Merkle root hash encoded with all the strings of the digests of its child nodes based on its child nodes, or a representation of its child nodes such that a digest can be computed.

[0040] Advantageously, the Merkle tree root for each non-leaf node provides a method for selectively discovering any arbitrary depth and / or path from the input hierarchical data structure, thereby increasing the flexibility of the system.

[0041] Optionally, the method further comprises the step of transmitting the output hierarchical data structure. Preferably, the output hierarchical data structure is transmitted to the sender of the request.

[0042] Advantageously, providing an output hierarchical data structure allows third parties to validate given data without having to rely on any other parties, even the party that generates the output hierarchical data structure.

[0043] Optionally, the digest of each node in the output hierarchical data structure comprises a digest that erases or redacts values ​​and / or data associated with the node.

[0044] Advantageously, digests allow the provider of the output hierarchical data structure to hide any arbitrary data from users receiving the output hierarchical data structure, thereby increasing the security and flexibility of the system without reducing the ability of verifiers to securely verify and trust the creator of the output hierarchical data structure.

[0045] Also according to a first aspect, the present disclosure proposes a device configured to perform the method of the first aspect.

[0046] According to a first aspect, the present disclosure also proposes a computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method of the first aspect.

[0047] Also according to a first aspect, the present disclosure proposes a system comprising a client device and a device according to the device of the first aspect discussed above, the client device being configured to generate a request comprising a data visibility path and send it to said device.

[0048] Preferably, the client device is as described in relation to the second aspect.

[0049] Optionally, the request further comprises an animal unique identifier and an event description.Optionally, obtaining the input hierarchical data structure is based on the animal unique identifier and the event description.

[0050] Optionally, the first data visibility path relates to livestock related data. Preferably, the first data visibility path relates to an animal vaccination event. According to a second aspect, a computer-implemented method for verifying a proof of existence is provided, the method comprising: (i) obtaining an input root digest from a blockchain; (ii) obtaining a data visibility path, the data visibility path referencing a node of interest in the input hierarchical data structure; (iii) obtaining an output hierarchical data structure comprising a plurality of nodes, each of the plurality of nodes corresponding to a node in the input hierarchical data structure; (iv) calculating digests for nodes of the output hierarchical data structure corresponding to the data visibility path; (v) calculating digests associated with each ancestor of the node corresponding to the data visibility path until there are no more ancestor nodes, the highest digest being the output root digest; and (vi) verifying a value of the node of interest based on a comparison of the input root digest and the output root digest.

[0051] Advantageously, this method allows a verifier to verify that the values ​​in the data visibility path were the same values ​​that were used in generating the input root digest. This can be done in a manner that does not require trust to be established with the provider of the output hierarchical data structure. If any value other than the real number 1 is given, the verification will come back as invalid. This provides a high level of security without requiring a high level of trust in the parties storing the data.

[0052] Optionally, the data visualization path is transmitted to a server and an output hierarchical data structure is received from the server comprising values ​​associated with the data visualization path.

[0053] Advantageously, this provides flexibility in the system in that the called party can arbitrarily choose what data it wishes to request.

[0054] Optionally, the input root digest is obtained from the blockchain. Preferably, the value of the input root is stored in a transaction output of the transaction stored in the blockchain. More preferably, the method further comprises verifying that the transaction has been stored in the blockchain.

[0055] As discussed above, blockchain further enhances the security of the system by providing immutable, persistent, and tamper-resistant data storage.

[0056] Preferably, verifying that the transaction has been stored on the blockchain comprises obtaining a Merkle proof comprising data based on the transaction, and verifying using the Merkle proof that the transaction has been stored on the blockchain.

[0057] Similar to the above point, security can be further improved through the use of Merkle proofs of inclusion to determine that correct data has been stored in the blockchain, which only require the block header to verify that a given transaction is part of the blockchain, thereby reducing the overall space required on the verification device.

[0058] Optionally, the digest for each node is based on the node's value and a salt.

[0059] As discussed above, salting the digests increases the overall security of the system by making it more resistant to rainbow attacks.

[0060] Also according to a second aspect, the present disclosure proposes a device configured to perform the method of the second aspect.

[0061] According to a second aspect, the present disclosure also proposes a computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method of the second aspect.

[0062] Also according to a second aspect, the present disclosure proposes a system comprising a client device according to the second aspect and a further device (preferably according to the first aspect), wherein the client device is configured to generate a request comprising a data visibility path and to send it to the further device.

[0063] Optionally, the data visualization path relates to a livestock related event.Preferably, the data visualization path relates to an animal vaccination event.

[0064] According to a third aspect, there is provided a computer-implemented method for generating and storing a representation of a client data item associated with a set of data items, the method comprising: (i) receiving a request comprising client data relating to a current state; (ii) obtaining a set of child nodes, the child nodes based on the client data, metadata relating to the client data, a first reference to a previous data item in the set of data items, and a second reference to a next data item in the set of data items; (iii) generating a hierarchical data structure based on the plurality of child nodes, the hierarchical data structure comprising a root node, and a majority of the child nodes being obtained prior to generation of the hierarchical data structure; and (iv) storing the root node for subsequent retrieval.

[0065] Optionally, a majority of the child nodes are obtained prior to receipt of client data.

[0066] Advantageously, by recognizing that certain child nodes (and / or their values) may be predetermined, much of the content of the hierarchical data structure can be pre-generated, so that when the time-critical portion of the generation of the root node needs to occur, much of the data is already there, saving overall time, thereby improving the overall data throughput of the system.

[0067] Optionally, the hierarchical data structure is based on a Merkle tree.

[0068] Advantageously, the use of a Merkle tree allows child nodes to be prepared through hashing their associated values, which makes the final step of generating the root node just the collection of said digests and the calculation of the root, thereby ensuring that the synchronization point of the method is as short as possible.

[0069] Optionally, the set of child nodes comprises nodes based on a secret value of a current transaction. Optionally, the set of child nodes comprises nodes based on a secret value of a next transaction.

[0070] Advantageously, the use of current and next value secrets provides an additional way to chain transactions together on the blockchain: using the next secret (secretN+1) on the current transaction allows an extra validation step to ensure that the next transaction in a set of transactions is correct and valid.

[0071] Optionally, the set of child nodes comprises a node based on a transaction output point of the next transaction. Preferably, the set of child nodes comprises a node based on an index of the transaction output point of the next transaction and a node based on a transaction id of the transaction output point of the next transaction.

[0072] Advantageously, using the transaction output point as a reference to the next transaction allows the next transaction to be referenced even if the client data for creating the transaction is not yet known. This allows this step to occur before any next client data, or even before the current client data. As discussed above, performing more steps before the final synchronization point that creates the root node allows for improved processing speed.

[0073] Optionally, the set of child nodes comprises a node based on a root digest of a previous hierarchical data structure associated with a previous transaction.

[0074] Advantageously, this can also be pre-computed and, since it is already a digest, does not even need to be hashed again for inclusion in the hierarchical data structure, thereby speeding up processing of current transactions even further.

[0075] Optionally, the set of child nodes comprises nodes based on a hash of the client data.

[0076] Advantageously, use of the data representing the client data in creating the hierarchical data structure allows the hierarchical data structure to be subsequently verified by interested parties. Preferably, the data representing the client data is structured as a Merkle tree, thereby allowing selective disclosure of any element in the tree as described in relation to the first and second aspects.

[0077] Optionally, the method further comprises generating a root node of the hierarchical data structure, the generating of the root node of the hierarchical data structure being a synchronization point.

[0078] Optionally, obtaining each child node in the set of child nodes is performed concurrently. Preferably, obtaining comprises obtaining corresponding input data for each node and processing said corresponding data. Preferably, processing comprises preparing a digest based on said processed data.

[0079] Advantageously, constructing the hierarchical data structure such that each node is independent of each other (or at least as independent as possible of each other), allows each node to be retrieved concurrently. Concurrent and independent processing allows for more effective horizontal scaling, thereby providing an easier way to increase data throughput.

[0080] Optionally, multiple requests comprising client data are received and an output hierarchical data structure is generated for each request.

[0081] Horizontal scaling improvements through the design and recognition of independent child data entries (which still allow chains of commitment as described herein to operate securely and correctly) not only allow for more concurrent processing of child nodes for a single received request, but also allow for concurrent processing across multiple received requests. Thus, processing may already have begun for a second received request even if the first received request has not yet completed (e.g., except for references to previous transactions that require a digest of the previous request).

[0082] Optionally, the root node is stored in the blockchain.

[0083] As previously described, storing the root node (which for the first and second aspects is the input root node) in the blockchain provides an immutable data store for trustless validation.

[0084] Optionally, the child node is a child of the root node.

[0085] According to a third aspect, the present disclosure also proposes a device configured to perform the method of the third aspect.

[0086] According to a third aspect, the present disclosure also proposes a computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method of the third aspect.

[0087] According to a third aspect, the present disclosure also proposes a system comprising a device according to the third aspect and a client device, the client device being configured to transmit client data to the device.

[0088] According to a fourth aspect, the present disclosure proposes a method, a system and a device for secure verification of livestock related data using the methods, devices and systems of the first, second and third aspects. Preferably, the fourth aspect provides a system for secure verification of livestock related data, comprising a verifier device according to the second aspect and a server according to the first aspect, the verifier device configured to receive an output hierarchical data structure from the server, the output hierarchical data structure comprising data relating to livestock management.

[0089] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may consist of a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a number of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0091] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of a number of blockchain nodes 104 in a distributed network or blockchain network 160. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as assets, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and redeem or spend). Each input points to the output of a preceding transaction 152, thereby linking those transactions together.

[0092] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0093] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, so that the transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 154 is often referred to as a "memory pool." This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0094] For a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, which specifies that this output is to be redeemed or "consumed" in the current transaction 152j. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152i is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by the pointer, and does not necessarily refer to the time of creation or transmission in the temporal order, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below on orphan transactions). The preceding transaction 152i may also be referred to as an ancestor transaction or a predecessor transaction.

[0095] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the amount of the input among multiple users or entities (one of which can be the original user or entity 103a to give the remaining amount). In some cases, the transaction can also have multiple inputs to collect together amounts from multiple outputs of one or more preceding transactions and redistribute one or more outputs of the current transaction.

[0096] According to an output-based transaction protocol such as Bitcoin, when an entity 103, such as a user or a machine, wants to perform a new transaction 152j, it sends the new transaction from its computer terminal 102 to a recipient. The entity or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are usually servers or data centers, but in principle could be other user terminals). It is not excluded that the entity 103 performing the new transaction 152j can send it to one or more of the blockchain nodes 104 and in some instances not to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may comprise verifying that a cryptographic signature or other authorization of the entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction assigns, which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is chained. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or it may be by a combination of these.In any event, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0097] In an output-based model, the definition of whether a given output (e.g., UXTO) is allocated is whether it has already been validly redeemed by the input of another forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that the transaction attempts to allocate or redeem has not yet been allocated / redeemed by another transaction. Again, if not valid, the transaction 152j is not disseminated (unless it is flagged as invalid and disseminated for a warning) or recorded in the blockchain 150. This protects against double spending, such as when a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any given time.

[0098] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, aided by "proof of work", in a process commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered set 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by trying to solve a cryptographic puzzle. Typically, this comprises looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered set 154 of transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain number of leading zeros. Note that this is just one specific type of proof of work puzzle, other types are not excluded. The nature of a hash function is that it has an unpredictable output with respect to its input. This search therefore consumes a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle, as it can only be performed by brute force.

[0099] A first blockchain node 104 that attempts to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that the output of the hash thereby satisfies the conditions). The first blockchain node 104 propagates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The large amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution is an indication of the first node's 104 intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0100] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be competing to solve the puzzle based on different snapshots of the ordered set of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current set of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined outstanding ordered set of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may arise, which are situations in which two blockchain nodes 104 solve a puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. That is, whichever tip of the fork has grown longer will be the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0101] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an allowable amount of digital assets in a new special type of transaction that distributes a defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction", but can also be called an "initiation transaction". It usually forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow the protocol rules that allow this special transaction to be redeemed later. The blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is discussed below.

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

[0103] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 according to the blockchain node protocol. It will be understood that any activity attributable to this specification for the blockchain nodes 104 may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0104] Also connected to the network 101 are computer devices 102 of each of a number of participants 103 acting as consuming users. These users may interact with the blockchain network but do not participate in the validation, construction, or propagation of transactions and blocks. Some of these users or agents 103 may act as senders or recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0105] Some or all of the participants 103 may be connected as part of a different network, for example a network superimposed on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system including the blockchain network. However, these users are not blockchain nodes 104, as they do not perform the role required of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150, by connecting to (i.e., communicating with) the blockchain nodes 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0106] The computing device 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing device 102 of each participant 103 further comprises a memory in the form of a non-transitory computer readable medium, i.e. computer readable storage. This memory may comprise one or more memory units utilizing one or more memory media, e.g. magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing device. It will be understood that any activity attributable to this specification for a given participant 103 may be performed using software executed on the processing device of the respective computing device 102. The computing device 102 of each participant 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given participant 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

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

[0108] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, approve (e.g. sign) and send transactions 152 to one or more Bitcoin nodes 104 so that they can be disseminated across the network of blockchain nodes 104 and included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered across the blockchain 150 that belong to the party in question.

[0109] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example interfacing via an API or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described with respect to client application 105, but it will be understood that this is not limiting.

[0110] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective participant 103 is a recipient (or in an embodiment, actually investigate the transactions of other participants in the blockchain 150, since the blockchain 150 is a public entity that provides credit for some transactions by virtue of its public presence). The wallet function of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward them for propagation of the transactions 152 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol, and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0111] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the new transaction 152j according to the blockchain node protocol and its respective role. This comprises first verifying whether the newly received transaction 152j satisfies some condition for being "valid", an example of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0112] Provided that the newly received transaction 152j passes the test to be considered as valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the network 106.

[0113] Once granted access to the ordered set of transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each ordered set 154 of transactions, including the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different ordered sets 154 of transactions, but whoever gets there first defines the ordered set of transactions contained in the latest block 151. Eventually, the blockchain nodes 104 solve the puzzle for the part of the ordered set 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the ordered set 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0114] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it accepts it and discards (i.e., treats as invalid) the instance it first accepted (i.e., the instance not published in block 151).

[0115] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored and periodically updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0116] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a basic data structure of the blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0117] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO comprises a value that specifies an amount of a digital asset. It represents a set number of tokens on the distributed ledger. The UTXO may also comprise, among other information, a transaction ID for the transaction from which the UTXO originates. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 issued to the node 104.

[0118] Suppose Alice 103a wants to create a transaction 152j that transfers a target amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". Tx1 takes 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 it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor do they mean that Tx1 is the immediate next transaction in the pool 154. Tx1 may point to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0119] The predecessor transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates the new transaction Tx1, or at least when she sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or even Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (such as which transaction points to which other transaction). They may be equally replaced by "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or node behavior.

[0120] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labelled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the following transaction for the following transaction to be validated, and thus for the redemption of the UTXO to be successful. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the following transaction comprises a cryptographic signature of the party to which the preceding transaction is locked.

[0121] A locking script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume the transaction output 203, e.g., requirements for Alice's signature. An unlocking script appears in the output of a transaction. An unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0122] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 is provided with a locking script [Checksig PA] that requires Alice's signature SIG PA in order for UTXO0 to be redeemed (or more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). [Checksig PA] includes a representation (i.e., a hash) of the public key PA from Alice's public-private key pair. Input 202 of Tx1 is provided with a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Input 202 of Tx1 is provided with an index that identifies UTXO0 within Tx0 in order to identify UTXO0 among all other possible outputs of Tx0. Input 202 of Tx1 is further provided with an unlocking script that comprises Alice's cryptographic signature, which is created by Alice applying her private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography).<Sig PA> The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0123] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script satisfies the conditions defined in the locking script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig PA> <pa>||[Checksig PA] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function contained in the locking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. In either case, when executed together, the scripts use Alice's public key PA, as contained in the locking script in the output of Tx0, to authenticate that the unlocking script in the input of Tx1 contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

[0124] The details of public-private cryptographic authentication are familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as the signature onto the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or transaction, etc., in embodiments means signing a hash of that data or transaction piece.

[0125] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to the ordered set of transactions 154. The blockchain node 104 also forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that it is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines the UTXO0 from Tx0 as being consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, a blockchain node 104 also needs to ascertain whether a referenced UTXO in a prior transaction Tx0 has already been spent (i.e., whether it has already formed valid inputs into another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for the blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent therein, but ultimately what defines whether a UTXO is spent is whether the UTXO has already formed valid inputs into another valid transaction in the blockchain 150.

[0126] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is also grounds for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0127] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" part of the amount defined in the UTXO as being spent while another part is being spent. However, the amount from the UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTX0s in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give the remaining amount of the second output of Tx1 to herself or to pay another party.

[0128] In practice, Alice is usually required to include a fee for the Bitcoin node that publishes her transaction 104. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus not disseminated and included in the blockchain 150, even though it is technically valid (the node protocol does not force the blockchain node 104 to accept the transaction 152 if it does not want to do so). In some protocols, the transaction fee does not require a unique separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that publishes the block containing UTXO1. However, it is not necessarily precluded that, alternatively or in addition, the transaction fee may be visibly specified in its own UTXO of transaction 152's UTXOs 203.

[0129] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, the assets of a given party 103 are spread across the UTXOs of various transactions 152 across the blockchain 150. There is no one number stored anywhere on the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function of the client application 150 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, further transaction. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0130] Note that script code is often expressed generally (i.e., without using a strict language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, produces a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

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

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

[0133] As shown in FIG. 1, the client applications of each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of a third party) a separate side channel 301 with Bob 103b. The side channel 301 allows for the exchange of data apart from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transactions 152 being registered (yet) in the blockchain network 106 or progressing towards the chain 150 until one of them chooses to broadcast the transactions 152 to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0134] The side channel 301 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 301 referred to elsewhere herein may comprise any one or more links, over one or more networking technologies or communication media, for exchanging data "off-chain," i.e., separately from the blockchain network 106. If more than one link is used, the bundle or collection of off-chain links may be referred to as a side channel 301 as a whole. Thus, when Alice and Bob are said to exchange some information or data, etc., over the side channel 301, this does not necessarily imply that all these data must be transmitted over exactly the same links, or even over the same type of network.

[0135] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing an embodiment of the scheme disclosed herein. The client application 105 comprises a transaction engine 351 and a user interface (UI) layer 352. The transaction engine 351 is configured to implement transaction-related functions behind the client 105, such as orchestrating transactions 152, receiving and / or sending transactions and / or other data via a side channel 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106, according to the schemes discussed above and as will be discussed in more detail shortly. According to the embodiments disclosed herein, the transaction engine 351 of each client 105 comprises a function 353.

[0136] The UI layer 352 is configured to render a user interface via the user input / output (I / O) means of the computing device 102 of each user, including outputting information to the respective user 103 via the user output means of the device 102 and receiving input from the respective user 103 via the user input means of the device 102. For example, the user output means may comprise one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means may comprise, for example, an input array of one or more touch screens (same or different as used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or audio input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0137] Note: although various functions are sometimes described herein as being integrated into the same client application 105, this is not necessarily limiting and instead they may be implemented in a series of two or more separate applications, e.g. one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 351 may be implemented in a separate application from the UI layer 352, or the functionality of a given module such as the transaction engine 351 may be split between more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is merely an example and that more generally the described functionality may be implemented in any form of software.

[0138] 3B provides a mock-up of an example user interface (UI) 360 that may be rendered by the UI layer 352 of client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b, or a client on any other participant's device.

[0139] 3B shows the UI 360 from Alice's perspective. The UI 360 may comprise one or more UI elements 362, 362, 363 that are rendered as separate UI elements via user output means.

[0140] For example, the UI elements may comprise one or more user-selectable elements 362, which may be various on-screen buttons, or various options in a menu, etc. User input means are adapted to allow a user 103 (in this case Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen, or by speaking the name of the desired option (the term "manual" as used herein is intended only to contrast with automatic and is not necessarily limited to using hands).

[0141] Alternatively or additionally, the UI element may comprise one or more data entry fields 362 through which the user can.... These data entry fields may be rendered via a user output means, e.g. on a screen, and data may be entered into the fields via a user input means, e.g. a keyboard or touch screen. Alternatively, data may be received verbally, e.g. based on speech recognition.

[0142] Alternatively or additionally, the UI element may comprise one or more output information elements 363 for outputting information to the user. For example, this / these may be rendered on a screen or audibly.

[0143] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not tangible. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 360 shown in FIG. 3 is only a schematic mockup, and that in reality it may comprise one or more additional UI elements, which are not shown for the sake of brevity.

[0144] Node Software FIG. 4 illustrates an example of node software 450 executed at each blockchain node 104 of the network 106 in the example of the UTXO-based or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 of the network 106, i.e., without performing the activities required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 351 is typically configured to recognize various fields of the transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UXTO) of transaction 152j (Tx j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlocking script in Tx j Based on the pointer in the input of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx i Alternatively, Tx i , may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Tx i locates the locking script in the referenced output of and passes it to the script engine 452.

[0145] Therefore, the script engine 452 executes the Tx i Locking script and Tx i 2. For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same could apply to any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes putting data onto the stack 453 and popping data off the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0146] By executing the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script "unlocks" the output in which the locking script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, it returns the result "true". Otherwise, it returns the result "false".

[0147] In an output-based model, a "true" result from the script engine 452 is one of the conditions for a transaction to be valid. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied. j the total value of the Digital Assets specified in the output of Tx will not exceed the total value indicated by the input; i The protocol engine 451 evaluates the results from the script engine 452 together with one or more protocol-level conditions and starts the transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j is actually validated, the decision engine 454 determines whether Tx j The consensus module 455C may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to Tx for incorporation into block 151. j 4 to the respective ordered sets 154 of the transaction nodes, and a propagation module 455P j to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before invoking either or both of these functions. For example, the decision engine may choose to publish a transaction only under the condition that the transaction is valid and has sufficient transaction fees remaining.

[0148] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or negative outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (where both individual outcomes are true, the overall outcome is considered to indicate true).

[0149] Other variations or uses of the disclosed techniques may be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the disclosure is limited only by the appended claims, not by the described embodiments.

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

[0151] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) performing only one or some but not all of these functions, i.e., network entities may perform the function of propagating and / or storing blocks without creating and publishing them (it is not to be recalled that these entities are not considered to be preferred Bitcoin network 106 nodes).

[0152] In non-preferred embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not precluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but not store and / or disseminate those blocks 151 to other nodes.

[0153] Also more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, disseminating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with respect to the blockchain node 104.

[0154] Ordered, append-only data storage The use of blockchain for high-volume, data-centric applications has grown significantly in recent years. This growth has correspondingly increased the demand for robust Layer 2 protocols for structuring, encoding, and formatting data payloads published to the blockchain. Here, Layer 2 refers to secondary protocols, frameworks, data structures, etc. that are built on top of one or more existing blockchain systems. The aspects described herein are considered to be Layer 2 protocols. Layer 1 refers to the blockchain technology behind Bitcoin, Bitcoin SV, or others.

[0155] Blockchain-based applications involving large amounts of data typically require a data schema or structuring mechanism that allows multiple data carrier transactions to be chained together. This is particularly relevant for applications (e.g., in a supply chain) where multiple events and / or data may need to be chained together in a linear sequence.

[0156] Maintaining and tracking sequences of events and / or ordered data items may be aided by unique references, such that one data carrier transaction unambiguously references another data carrier transaction, and these two transactions can be reliably associated with each other by an observer of the blockchain.

[0157] FIG. 5 shows an overview of the data structure and paradigm of an ordered append-only data storage system according to an embodiment of the present disclosure. It may also be described as a data logging system. The system 500 includes an off-chain (i.e., not on the blockchain) data storage system 504 that stores several log entries 506a-d. These log entries are reflected 502 on the chain through the use of blockchain transactions 508a-d. The off-chain data storage system is preferably a database. Those skilled in the art will appreciate that any data storage system may be used, including storage on a hard drive as an alternative. Preferably, the off-chain data log tracks the state of the system, smart contracts, and / or state machines, so the system of FIG. 5 may also be described as a state storage system or state tracking system.

[0158] The system 500 of FIG. 5 is preferably used as part of an event stream system for logging events and / or inputs to a state machine associated with the event stream. Mapping each event to a transaction is shown as an example. Optionally, only a subset of the events in the append-only log are mapped to blockchain transactions. As an example, an event stream is used throughout this specification for illustrative purposes. In particular, FIGS. 11-13 provide specific examples of various servers and services operating within an event stream system that receive client data, construct transactions, and submit them to the blockchain. Those skilled in the art will understand that the proposed embodiments described herein can be used with any client data item, not just those related to event streams. Those skilled in the art will understand that the in-order, append-only, blockchain-based logging (or data storage) method and system can be used for other purposes as well.

[0159] Each event 506a-d in the off-chain data storage 504 is mapped to a blockchain transaction 508a-d, and the sequence of blockchain transactions is ordered and chained together using a "chain of commitments." A chain of commitments may be considered to be a set of transactions that comprise information such that the transactions can be securely and verifiably related to one another and / or inspected. As described herein, the set of transactions is constructed as a "chain," in that each transaction comprises (or comprises data based on) a reference to a previous transaction and a reference to a next transaction. Preferably, it is the payload 512a-d of each transaction that comprises or is based on the reference to the previous transaction and the reference to the next transaction.

[0160] Each transaction preferably comprises a "funding" input 510a-d that is to be paid for the transaction to be mined into a block on the blockchain. Each transaction preferably comprises a data payload 512a-d. The data payload is held in the non-consumable output of the transaction. Preferably, the output is prepended with an OP_RETURN opcode and / or an OP_0 opcode. This is a Script opcode that can be used to write arbitrary data to the blockchain and also to mark the transaction output as invalid (i.e., non-consumable), thereby immutably recording the data on the blockchain. Optionally, the data payload is prepended with both the OP_0 opcode and the OP_RETURN Script opcode.

[0161] Optionally, the aspects and embodiments described herein are used in addition to and / or as an augment to a chain of commitment as discussed with reference to Figures 5A to 13 of UK Patent Application No. 2204293.1 (filed in the name of nChain Holdings Limited on March 25, 2022 and incorporated herein by reference). Alternatively, the embodiments are instead used alone, without coordination with the embodiments of the above-referenced patent application.

[0162] Optionally, each payload 512a-d comprises a data item based on the respective associated event 506a-d as received from a client and optionally stored off-chain. Preferably, the event data has been received from a client wishing to store a representation of the event in the blockchain for later verification and / or proof of the existence of the event. Preferably, the data items based on the associated events are based on a hash of data related to each event. The data items may therefore also be described as data digests. Preferably, the data digest is salted. More preferably, the event data is hashed twice. Advantageously, hashing twice provides protection against the expansive nature of hash functions. Even more preferably, the event data is hashed twice and a pre-image is generated based on the twice-hashed event data and the salt. Preferably, the salt is hashed, more preferably hashed twice. The pre-image is then hashed. Even more preferably, said pre-image is hashed twice. Thus, most preferably, the data digest is Data Digest N := H 2 (H 2 (D)||H 2 (SALT) It is in the form:

[0163] where || is the concatenation of the members before and after it, and H2 is a double hash function.

[0164] Hashing is provided as the primary example of a one-way function herein. Hashing is also provided as the primary exemplary method of generating a digest. Those skilled in the art will appreciate that other one-way functions may also be used, and other methods for generating a digest may also be used. Preferably, in this embodiment, as well as throughout this specification, the hash function used is the SHA-256 cryptographic hash function. "Hashing" as used throughout this specification means hashing, preferably at least once, and more preferably more than once. Hashing more than once provides resistance to stretching attacks. Instead of hashing twice (or more), a different hash function or method is used that is not vulnerable to stretching attacks. For example, SHA-3 and / or HMAC (optionally each item is hashed using a single salt as a key against the entire current state, or a different salt for each item being hashed as a key is used) provide such functionality.

[0165] Salting a hash preferably means using a "salt" (along with the data being hashed) as part of the input to the hash function, which is any random data. Preferably, the salt is concatenated with the other inputs to the hash function. Optionally, the salt is random.

[0166] Preferably, a different salt is chosen for each event in the event stream. Preferably, the salt is stored for later use in data validation. Salting the hashes provides resistance to pre-computed "rainbow table" based attacks, thereby providing greater security for clients wishing to store potentially sensitive data on the blockchain.

[0167] A data digest can be thought of as a unique fingerprint for an item of client data (which in the prime example is being put out into an event stream). By storing the data digest (relative to the client data itself), a client using this system can store a proof of existence of a known and consistent size (independent of the size of the client data) on the blockchain without revealing what the contents of the client data are.

[0168] Referring to FIG. 6A, a first exemplary hierarchical data structure 600 associated with an on-chain representation of each event is shown. Preferably, the hierarchical data structure 600 is a Merkle tree. The data structure comprises several leaf nodes based on a set of inputs: NEXT 602, CURRENT 604, and PREV 606. Here, the NEXT input comprises or is based on a reference to the next transaction in the chain, the CURRENT input comprises or is based on the current event state including received client event data and / or other metadata regarding the current event state, and the PREV input comprises data or is based on a reference to the previous transaction in the chain. Thus, it can be seen that there is a set of child nodes based on client data and / or current state metadata regarding the current state, a first reference to the previous transaction, and a second reference to the next transaction. The three nodes shown in FIG. 6A are for illustrative purposes only. For example, there may be several nodes based on current state data (e.g., one based on client data and one for the current state metadata).

[0169] In this specification, a hierarchical data structure may also be viewed as an existence proof for a data structure.

[0170] The root 608 of the first exemplary data structure 600 is a state digest for the current state (referred to throughout this specification as StateDigest). N or S N , referred to as NEXT, CURRENT, and PREV). Preferably, the digest associated with the root is stored in the transaction's data payload as discussed above. This exemplary Merkle tree is constructed as a binary tree where each node has two children (except for the leaves). Since there are an odd number of input data items (and an odd number of leaves), the last unpaired leaf node is doubled. Those skilled in the art will appreciate that it is not necessary to strictly follow this presented form of a Merkle tree, and there are other forms that may function similarly. Each item in the input set {NEXT, CURRENT, and PREV} is hashed twice (610), and each twice-hashed item is used as a leaf of the Merkle tree. Preferably, the Merklize function is used to generate the Merkle tree of FIG. 6A. The function Merklize is preferably taken to mean a standard method for generating a Merkle tree given a set of leaf data items. The Merklize function is stateDigestN := Merklize({PREV,CURRENT,NEXT}) It can be used like this:

[0171] The Merklize function generates Merkle roots from an ordered set of data elements as leaves. As mentioned above, each of the leaves that have not yet been hashed is first double-hashed (610) in the Merklize function. Optionally, all of the leaves are double-hashed. Due to the principles by which hashing and Merkle trees work, the order, layout, and format of the set of inputs to a Merkle tree are important. Note that the order and layout of the inputs must therefore be the same whenever a Merkle tree is created, recreated, or validated, so that the same tree (and therefore the same state digest) is generated for the same input data.

[0172] Instead of a Merkle tree structure as described with reference to this embodiment and other embodiments described herein, the state digest can be generated by hashing a pre-image, where the pre-image is constructed by concatenating the objects whose state data is based on it. Thus, in an example where the state digest is based on a previous transaction reference, current client state data, and a next transaction reference, the formula is stateDigestN := H(PREV||CURRENT||NEXT) It can be in the form:

[0173] As a further alternative to the Merkle tree structure as described with reference to this embodiment and other embodiments described herein, the state digest may be generated by using a hash chain. The hash chain is constructed such that each intermediate hash result is prepended with the item on which the state digest is based. For example, the state digest may be based on a previous transaction reference, current state data, and a next transaction reference, and the expression may be of the form: stateDigestN := H(PREV||H(CURRENT||H(NEXT)))

[0174] Referring to FIG. 6B, a second exemplary hierarchical data structure 620 is shown that is associated with the on-chain representation of each event. The same or similar reference numbers are used to refer to the same or similar objects across the current and previous examples. Preferably, the hierarchical data structure 620 is a Merkle tree. In the current exemplary embodiment, several inputs 622, 624, 626, 628, 630, 632, 634 are shown. These inputs are provided in this example such that they are associated with the NEXT 602, CURRENT 604, and PREV 606 inputs as in the previous exemplary hierarchical data structure 600 described with reference to FIG. 6A. The NEXT input is the transaction id (utxoTxid) of the output point of the next transaction 622 for the current transaction. N+1 ), the transaction output index (utxoIndex) of the output point of the next transaction for the current transaction 624 N+1 ), and the next state digest (StateDigest N+1 The next secret to be used in the generation of N+1 ). The current input is attestedData, which preferably comprises or is based on the submitted client data and other metadata related to that client data (more preferably also comprises or is based on metadata of the event stream, and even more preferably is based on data structures such as those described below with reference to Figures 6C and 6D). N 628, index of current state 630 N ), and the current secret 632 (secret N The PREV input is the state digest 634 (S N-1 ) Those skilled in the art will appreciate that not all of the input nodes presented above are required, but rather a subset of them may be selected.

[0175] The exact structure of the Merkle tree is preferably consistent, or at least known across different state digests, so that it can be reconstructed according to the same structure at a later date. This is important for (or at least makes) validation easier as discussed below under the heading "Existence Proofs Using Ordered Append-Only Data Storage".

[0176] Preferably, any input to a leaf node that is not itself a digest is hashed 610 when included as a leaf node of the Merkle tree. N 628 and the previous state digest (S N-1 ) 634 is a digest and therefore their values ​​can be included directly (636) without the need for any further hashing. As discussed above with reference to this embodiment and the previous embodiment of FIG. 6A, the state digest (which includes the previous state digest) is already a digest since it is the Merkle tree root. As shown below with reference to FIGS. 6C and 6D, attestedData N is also a Merkle tree root, and therefore a digest.

[0177] For the hierarchical data structure 620 of FIG. 6B, the Merklize function may preferably be used as follows:

number

[0178] Here again the Merklize function is a standard method for generating a Merkle tree from an ordered set of inputs. Preferably the inputs are hashed if they are not already hashed, and optionally all of the inputs are hashed.

[0179] Referring to FIG. 6C, a third exemplary hierarchical data structure 640 is shown that is associated with an on-chain representation of each event. Preferably, the third exemplary hierarchical data structure is a Merkle tree. The third exemplary hierarchical data structure is a “attestedData N ” since the root may be used to validate any data contained in the third exemplary hierarchical data structure.

[0180] Preferably, the third exemplary hierarchical data structure 640 comprises several nodes 642, 644, 646, 648, 650, 652, 654 that are descendants of a root node and are each based on several inputs 656, 658, 660, 662, 664. Preferably, each of the nodes has an associated digest. Preferably, the associated digest of each leaf node is based on the corresponding input data. More preferably, each of the nodes is based on a hash of each of the inputs. Non-leaf nodes (parent nodes) also have associated digests that are based on their child nodes. Each non-leaf node has an associated value that represents the parent of those child nodes.

[0181] So we know that each node has an associated digest and an associated value. For example, hashedData N The node 642 is based on the client data 656 itself. N is obtained by hashing the client data 656. As can be seen in FIG. N The digest associated with is salted based on the pathSalt. Similarly, the appVersion node 646 is based on the corresponding appVersion entry value 658, and the esid node 648 is based on the corresponding esid entry value 664.

[0182] As shown for signature node 650, the present embodiment provides for arbitrary hierarchical levels (also referred to as layers) within the third hierarchical data structure 640. Each non-leaf node of the hierarchical data structure is preferably a Merkle root node that is itself based on the values ​​and / or digests of its children. Signature node 650 comprises its own child nodes, namely sig node 652 and alg node 654, that are based on a signature string and a string representing the algorithm used to generate the signature, respectively. The sig and alg nodes are themselves based on sig input values ​​660 and alg input values ​​660. Thus, signature node 650 is also based on sig input values ​​and alg input values. Those skilled in the art will appreciate that other nodes with different input values ​​and different depth levels in the third hierarchical data structure are possible.

[0183] To generate the third hierarchical data structure 640 of FIG. 6C, the Merklize function is preferably used to handle multi-layer hierarchical data structures.

[0184] Turning to Code Block 1 below, exemplary input data in a particular format is shown. Code Block 1 below provides a specific example that may have been used to generate the third hierarchical data structure 640 of FIG. 6C. Thus, the content of Code Block 1 may be considered to be a representation of and / or comprising a hierarchical data structure. With respect to the JSON of the codebook as used herein, each JSON object (comprising a key-value pair) is or represents a node.

[0185] Code Block 1 and the third hierarchical data structure have four layers: the top layer, "root", a first child layer comprising "hashedData" and "metadata", a second child layer comprising "appVersion", "signature", and "esid", which are all children of "metadata", and finally a third child layer comprising "sig" and "alg", which are children of "signature".

[0186] Preferably, a normalized JSON scheme is used so that the same JSON string or representation is generated when JSON objects have the same content and / or are based on the same received client data. Normalization concerns preserving data types (e.g., storing any integer as an integer except a string that represents an integer, or using the same encoding such as Base64 for all hashes, etc.) as well as preserving the order of objects (e.g., the content of "signature" in the example below should always be canonically represented as "alg" then "sig"). Comparison of a calculated value (as used in validation) with a received expected value (e.g., as stored in a hierarchical data structure and / or root) is somewhat type-dependent. Some types (string, number, boolean, null) have well-defined JSON formats and thus have industry-standard means of comparison. Other types, such as binary data, dates, or out-of-range numbers, may need to have an encoding agreed upon by all devices using the systems and methods disclosed herein. For example, standards such as base64 for binary data representation and ISO8601 for data representation may be used. The exact chosen format and structure used in the normalization is not strictly important, as long as it is consistent across platforms and implementations.

[0187] Ellipses ("...") are used herein in code blocks to represent omitted data within the value of a key-value pair. Those skilled in the art will appreciate that the exact content of the data is only exemplary, and that the data can be filled with other content, and that still other keys with other data may be used.

[0188] Although JSON is given here as a specific example, those skilled in the art will appreciate that there are other ways to encode hierarchical data, including (among others) XML, YAML, and BSON.

[0189] Code Block 1 inputToAttestedData = { "hashedData": "w6uP8Tcg6K2QR905Rms8iXTlksL6OD1KOWBxTK7wxPI=", "metadata": { "appVersion": "v1.0.4.30", "signature": { "alg": "ECDSA", "sig": "cac18b730f6f68b6 ... ac36287d8093" }, "esid": "eyJsIjoiZnJhb ... kVTIiwidiI6IjEifQ" } stateDigestN := MerklizeHierarchical(inputToAttestedData)

[0190] An exemplary method for executing the MerklizeHierarchical function is described with reference to FIG. 10A.

[0191] As discussed above, the input hierarchical data structure has or is a canonical format, and more preferably the canonical format is normalized JSON. Preferably the input to the Merklizehierarchical function also has a canonical scheme (i.e. the order and format is consistent). This is important because the order in which the input is provided to the Merklize function needs to be consistent across creation and validation in order to be validated as valid. Preferably, given that two different implementations implement any of the Merklization related features, normalization ensures consistency.

[0192] Instead of each node's digest being based on its value (i.e., as an alternative to algDigest=H("ECDSA")), each node's digest is based on both the node's value and its depth.

[0193] Preferably, the digest of a node is a hash of a normalized JSON string of an object with the following structure: { path: "<string encoded path> ", value:<value of node> , }

[0194] More preferably, the digest of a node is also based on the version number, such that the digest of a node is a hash of a normalized JSON string of an object with the following structure: { path: "<string encoded path> ", value:<value of node> , version:<version number> , }

[0195] If a node has children (such as "metadata" in Code Block 1), the associated value of the node is a digest based on the node's children. Preferably, the digest is a Merkle root hash encoded with all of the strings of its child node's digests. Alternatively, and / or in other hierarchical data structures and / or other representations of hierarchical data structures, the associated value of the node is a representation of its children. Optionally, both are used.

[0196] Preferably, nodes that have children (parent nodes) are represented by JSON objects and / or arrays of JSON objects with JSON object key-value pairs (like "metadata" in Code Block 1). Preferably, nodes with no children (leaf nodes) are represented by non-object JSON types (i.e., string, number, boolean, null, or arrays thereof).

[0197] A path is or comprises a value that is related to the path of a node in the tree. Preferably, a path is a string that represents the position of the node in the tree. Preferably, dot notation is used to point to nodes in the path. Dot notation is similar to the notation used in JSON. For example, "metadata.signature.sig" points to the sig node in Code Block 1. The XML-style format " <path>< / path> Alternative path formats or schemes are also possible, such as:

[0198] 6D, a fourth exemplary hierarchical data structure 670 is shown. The fourth exemplary hierarchical data structure comprises some of the same components, including the same nodes 642, 644, 646, 648, 650, 652, 654, and input values ​​656, 658, 660, 662, 664 as the third hierarchical data structure 640. Like the third hierarchical data structure, this fourth exemplary hierarchical data structure has corresponding input data as described in Code Block 1. Unlike the third hierarchical data structure, the digest associated with each node of the fourth exemplary hierarchical data structure is further based on a pathSalt 672.

[0199] pathSalt 672 is based on the path and salt of the node. Preferably, the salt is based on the current attestedData N The digest of a node is the same for each node for the tree and is different compared to other attestedData trees (e.g., N+1, N-1). Thus, since every single node has a different path, it can be seen that every single node has a different pathSalt, even though they all have the same salt. This advantageously allows each node in a hierarchical data structure to be salted (and all the associated benefits, such as resistance to rainbow table attacks) without disclosing the salt itself to any party during validation. Thus, the digest of a node is a hash of a normalized JSON string of an object with the following structure: { pathSalt: "<string encoded path salt> ", value:<value of node> , }

[0200] Optionally, the digest of a node is also based on its version, as discussed above. Preferably, the pathSalt672 is computed by taking a hash of a normalized JSON string of an object with the following structure: { path: "<path to node> ", salt: "<string encoded salt> ", }

[0201] 6E, a fifth hierarchical data structure 680 is shown, comprising the second hierarchical data structure 620 and the fourth hierarchical data structure 670. The second hierarchical data structure is rooted at the fourth hierarchical data structure 628 and includes the attestedData of the second hierarchical data structure. N Using it as node 628 provides a fourth hierarchical data structure. The same reference numbers are used between Figures 6B, 6D, and 6E to indicate that the same or similar features are represented across each figure.

[0202] Referring to Fig. 7, an exemplary method 700 for constructing any of the data structures 600, 620, 640, 670, 680 as described with reference to Figs. 6A to 6E. Preferably, the method is configured for constructing a hierarchical data structure related to data received from a client. More preferably, the method is configured for constructing a hierarchical data structure for storing a value based on at least the received client data on the blockchain, and even more preferably, the value based on the client data is the root of the hierarchical data structure. Even more preferably, the client data belongs to a set of other data items previously received and optionally received in the future.

[0203] Although some steps of the method 700 are shown as being sequential, as discussed below, this is for ease of illustration only. As discussed below, some steps may be performed in different orders and / or concurrently with one another.

[0204] In a first step 702, client data is received. The client data is for use in generating the hierarchical data structure. As mentioned above, the client data preferably belongs to a set of data items, more preferably the set is an ordered set of data, even more preferably the set is a chain of data items, and most preferably the set of data is a chain of commitments associated with an event stream, and the client data are events.

[0205] In a next step 704, a set of child nodes is obtained for use in generating the hierarchical data structure, including nodes based on the received client data, metadata associated with the received client data, data representing a previous data item in the set of data items, and data representing a next data item in the set of data items.

[0206] Preferably, the data representing the previous and next data items in the set of data items are references to said data items.

[0207] The reference to the next data item is or comprises a reference to the next transaction related to the next data item. As described with reference to Figures 6B and 6E, the reference to the next transaction may be the transaction id (utxoTxid) of the UTXO that funds the next transaction. N+1 ), and the index of the UTXO that will fund the next transaction (utxoIndex N+1 Additionally or alternatively, the reference to the next transaction may include the next secret. N+1 ) is provided.

[0208] As described with reference to Figures 6B and 6E, the reference to the previous data item is or comprises a state digest of the previous data item. Preferably, the state digest is a value stored in the blockchain in a transaction related to the previous data item. This provides an on-chain way to verify that the previous transaction is correct.

[0209] The metadata associated with the received client data preferably comprises metadata associated with the event stream. The metadata may be any one or more of the following: index - the index of the current event in the event stream (not necessarily the same as the index in the chain of commitments, since it is not necessary that all events are recorded in the chain of commitments) secretN - the secret to be used whenRecorded - the time when the event was received from the client and / or stored in the off-chain log appVersion - the version number of the chain of commitments seed - seed value used at the beginning of the event stream generation signature - the client / submitter's signature and, optionally, a value for the algorithm used to generate the signature delWriteIV - the initial value used in generating a delegated authorisation token for writing to the event stream. delWriteH0 - the last hash value used to validate the delegation authority token for writing to the event stream timeAC - the start and / or end time at which the event stream is considered accepting writes. delAuthIndex - the index of the delegation token that the client used to emit the event TxIDcreate - the transaction ID of the first transaction in the commitment chain

[0210] Those skilled in the art will appreciate that other metadata elements may also be used.

[0211] Preferably, the index and secret N and, more preferably, any number of the other metadata items listed above, as described with reference to Figures 6C to 6E. N Used in nodes.

[0212] The child node based on the client data is preferably a Merkle tree root according to the third hierarchical data structure 640 of FIG. 6C, and more preferably according to the fourth hierarchical data structure 670 of FIG. 6D. The hierarchical data structure is based on the received client data. The received client data is used to create an input hierarchical data structure in a format as described with reference to Code Block 1. The same or similar steps are then performed to obtain a Merklized hierarchical data structure from the input hierarchical data. Thus, several Merklize and / or HierarchicalMerklize steps are required to obtain the child node based on the client data (and optionally also based on other metadata).

[0213] In step 706, a hierarchical data structure is generated. Preferably, the hierarchical data structure is a Merkle tree, so that it consists of a number of nodes that all have (or are provided with) associated digests based on their children and / or the input data. More preferably, the hierarchical data structure is any one or more forms of hierarchical data structure as described with reference to Figures 6A to 6E. Different tree structures may be used depending on what data is to be included. Preferably, the data on which a leaf node of the Merkle tree is based is hashed to generate said leaf node. For example, the utxoIndex N+1 622 (which is an integer) is hashed (610) and the result is the associated utxoIndex N+1 The data is stored in the node.

[0214] Once the hierarchical data structure is created, a root node is obtained, which is stored for later retrieval (708), preferably in a blockchain.

[0215] As new client data items are received, the method 700 described above is performed a certain number of times.

[0216] The creation of a hierarchical data structure (particularly for the purpose of obtaining the root node of the hierarchical data structure) is a synchronization point. This step is considered a synchronization point because the creation of the root node digest can be done only by a single thread that takes all of the child nodes of the root node as input to the root node digest.

[0217] It should be noted that the metadata associated with the received client data, the data representing the previous data item in the set of data items, and a portion of the data representing the next data item in the set of data items may be obtained prior to receipt of the client data. Furthermore, since the data on which the nodes are based may be obtained in advance, the data may also be pre-processed. Here, the secret N , index N , secret N+1 , utxoTxid N+1 ,utxoIndex N+1 The processing for involves hashing these items.

[0218] Furthermore, because all of the child nodes are selected to be independent of one another (i.e., no child node input is dependent on any other child node or its inputs), all of the child nodes can be generated concurrently.

[0219] It can thus be seen that by selecting which data is provided as input to the child nodes, the child nodes can be processed in advance and concurrently with each other, thus greatly increasing the overall processing speed of generating the hierarchical data structure (and thus obtaining its root).

[0220] With particular reference to the systems described with reference to Figures 11 and 12, the identified improvements of this embodiment allow for the processing of hundreds or thousands of client data requests per second per server, whereas without such features it may be tens of times per second per server. Furthermore, the selection and / or identification of which data may be computed concurrently / independently also allows the systems of Figures 11 and 12 (and any other systems using this embodiment) to scale more efficiently horizontally.

[0221] Proof of Existence Using Ordered Append-Only Data Storage Referring to FIG. 8A, an exemplary method 800 for generating a proof-of-existence hierarchical data structure 800 is shown.

[0222] In a first step 802, a request is received comprising a data visualization path. A data visualization path is a path that points to a node in an input hierarchical data structure. Preferably, the request or path comprises a reference to a particular input hierarchical data structure. Preferably, the reference to the input hierarchical data structure is or comprises a unique identifier. Here, the term "input" in the input hierarchical data structure is used to refer to the fact that it is used as an input to the generation step when generating the output hierarchical data structure.

[0223] Next, an input hierarchical data structure is obtained (804). The input hierarchical data structure is preferably obtained from an off-chain database, preferably the off-chain database 504 as described in the system 500 of FIG. 5. More preferably, the off-chain database is as described in the data archive of the data service 1602 and is accessed via the data reader 1602b as described with reference to FIG. 12. The input hierarchical data structure is preferably in the form of the third hierarchical data structure 640, the fourth hierarchical data structure 670, or the fifth hierarchical data structure 680 as disclosed in FIG. 6C to FIG. 6E, and has an associated data implementation format as described with reference to Code Block 1.

[0224] An output hierarchical data structure is generated or obtained (806) based on the input hierarchical data structure and the data visualization path. The output hierarchical data structure preferably has the same or similar structure in that it comprises the same or similar nodes. Preferably, each node of the output hierarchical data structure has a corresponding node in the input hierarchical data structure. Preferably, the input hierarchical data structure has previously been Merkle-ized, and the root node of said input hierarchical data structure has been stored for later retrieval. An exemplary method 1020 of generating an output hierarchical data structure is described in more detail with respect to FIG. 10B.

[0225] Optionally, the request comprises multiple paths each pointing to a node of interest, and thus the request comprises multiple nodes of interest, where instead of revealing multiple nodes an output hierarchical data structure is generated.

[0226] Nodes in the output hierarchical data structure that correspond to the data visibility path, and all of their ancestor nodes, are provided with the value associated with the corresponding node in the input hierarchical data structure. As used herein, "reveal" refers to the underlying data associated with the node being provided to the recipient of the output hierarchical data structure (such as the actual signature as described in the examples used throughout). Preferably, the values ​​of the corresponding nodes in the data visibility path are the same between the input and output hierarchical data structures. All of the other nodes in the output hierarchical data structure are provided with digests and no values. The digests are used so that the node's value itself can be erased and / or redacted while its value can later be used for verification purposes. The digests are the result of a one-way function so that any party with access to the output hierarchical data structure cannot reverse the digest and obtain the underlying value, or at least it would be prohibitively expensive to do so.

[0227] Referring to FIG. 8B, an exemplary output hierarchical data structure 820 is shown. The exemplary output hierarchical data corresponds to an input hierarchical data structure according to the examples shown in the third, fourth, or fifth hierarchical data structures as described in FIG. 6C-6E. The same or similar reference numbers are used for the same similar node values ​​and / or digests. In this exemplary output hierarchical data structure, the data visualization path points to the "sig" node. Optionally, the data visualization path is in the form of "metadata.signature.sig".

[0228] The exemplary output hierarchical data structure 820 includes several nodes 642, 672, 654, 648 with only their corresponding digests. The "sig" node 650 includes its corresponding value 660. All ancestor nodes of the node of interest include their respective pathSalts 682. Note that all of the information needed to recreate the root node 628 is included in the output hierarchical data structure. The recreation of the root node 628 is part of the validation process, which is discussed in more detail with respect to FIG. 9.

[0229] The corresponding JSON object used to represent the exemplary output hierarchical data structure 820 is shown below in Code Block 2.

[0230] Code Block 2 outputDataRevealTree = { "hashedData": { "digest": "qKmdAXmm7yl5 ... rh+lLhvxNc="}, "metadata": { "value": { "appVersion": { "digest": "26snJY ... ayKM="}, "signature": { "value": { "alg": { "digest": "Y887L ... XaxLvg="}, "sig": { "value": "cac18b730f ... 7d8093", "pathSalt": "VrTHytB ... V8I5D7U=" } }, "pathSalt": "sZL5UTdmMe ... 7BSXWF7z8=" }, "esid": { "digest": "q5jL ... 74Ro="}, }, "pathSalt": "wm0eEGCQwWhDYs0gqe3ydiIi49+0xTH6MmwswekqXq4=" }, }

[0231] It can be seen that outputDataRevealTree is a representation of the Merkle tree proof represented using a JSON object. The JSON object may be transmitted as a string. Note that each node may be represented according to an associated "value" and "pathSalt" or associated "digest". Here, the value may comprise the revealed data or the value may be based on the child nodes. For example, the "signature" value is based on the "alg" and "sig" nodes, with the "sig" node comprising the revealed data "cac18b730f ... 7d8093". As mentioned above, the value of "signature" is the Merkle root hash of the "alg" and "sig" nodes, preferably the Merkle root hash of the string-encoded Merkle root hashes of the "alg" and "sig" nodes. And additionally and / or alternatively, the value is a JSON representation comprising its child nodes.

[0232] The output hierarchical data structure is preferably used to verify that the value located in the data visualization path was part of the input hierarchical data structure when it was created. The verification is performed by comparing the root node of the input hierarchical data structure (which was preferably stored somewhere when it was created, more preferably stored in the blockchain and / or stored data based on the root node on the blockchain) with the root node of the output hierarchical data structure. Verification is discussed in more detail below with reference to FIG. 9.

[0233] Returning to the method of Figure 8A, preferably the output hierarchical data structure is transmitted to the sender of the request (808). Optionally, the output hierarchical data structure is provided to a party interested in verifying the existence of values ​​located in the data visibility path. Even more preferably, a JSON string representing the output data structure is transmitted.

[0234] Optionally, a further proof is also provided to show that the outputDataRevealTree root node is included in the Merkle tree used in generating stateDigestN. Alternatively, the outputDataRevealTree also comprises a layer above attestedDataN 628, such that digests of nodes one layer higher are also included in the outputDataRevealTree (e.g., child nodes 638 of the second hierarchical data structure 620 as described with reference to FIG. 6B). In such a configuration, stateDigestN may be provided in a similar manner as described in verification method 900 with reference to FIG. 9.

[0235] 9, an example method 900 for providing the presence of a value is shown. The terms "input" and "output" are used with respect to the method in a manner consistent with the preceding embodiment.

[0236] In a first step 902, an output hierarchical data structure is obtained. Preferably, the output hierarchical data structure is in accordance with data structure 820 described with reference to Fig. 8B. The output hierarchical data structure is obtained from a device that created the input hierarchical data structure and / or comprises the input hierarchical data structure.

[0237] Next, an input root digest is obtained 904. The input root digest is the digest root of the input hierarchical data structure that is used to create the output hierarchical data structure. More preferably, the input hierarchical data structure is in accordance with any one or more of the first through fifth hierarchical data structures 600, 620, 640, 670, 680 as described with reference to Figures 6A through 6E.

[0238] In particular, only the output hierarchical data structure and the root input hierarchical data structure are needed to verify that the values ​​of interest were (or were not) the same values ​​as when the input hierarchical data structure was created (i.e., to verify that the values ​​have not been tampered with or altered in any other way).

[0239] Preferably, the input root digest is obtained from an immutable and / or append-only source, for example from a blockchain. By using an immutable source for the input root digest, one can obtain assurance that the value published therein was always said value.

[0240] To obtain the output hierarchical data structure, a request is preferably sent to a device, the request comprising a path to the node of interest. Preferably, the request is sent to a device performing method 800 as described with reference to Figure 8A. The device replies with an output hierarchical data structure having the node of interest referenced by the revealed path.

[0241] Given the input root digest and the output hierarchical data structure, the root of the output hierarchical data structure is obtained or identified 906. Preferably, the root node of the output hierarchical data structure is obtained or identified according to a method 1020 as described with reference to FIG.

[0242] The verification is based on a comparison of the root node of the input hierarchical data structure and the root node of the output hierarchical data structure 908. Preferably, the two root nodes should have the same associated digest for the verification to be considered successful.

[0243] Optionally, if the input root node is obtained from the blockchain, the transaction with said input root node is also verified to exist on the blockchain. Preferably, the device providing the output hierarchical data structure provides a Merkle proof that the transaction is included in a particular block. The verifier only needs to download the headers of the block and / or retrieve them from its own storage and use Merkle tree proofs to ensure that the transaction was actually recorded on the blockchain. This transaction verification method can use and / or is a system similar to Simplified Payment Verification SPV (https: / / wiki.bitcoinsv.io / index.php / Simplified_Payment_Verification). In SPV, a client with access to the header can verify that a particular transaction (in our case, the transaction with the input hierarchical node) was recorded on the blockchain without downloading anything other than the header of the blockchain. Alternatively, the verifier can use a unique blockchain data store to look for the input root node. The device providing the output hierarchical data structure may also provide metadata about the transaction and the block it belongs to (such as transaction id and block height) to enable easier lookup.

[0244] 10A, 10B, 10C, and 10D, methods 1000, 1020, 1040, 1060 are shown that may be used to: (1000, 1020) a MerklizeHierarchical function for constructing any one or more of the first to fifth hierarchical data structures 600, 620, 640, 670 as described with reference to Figures 6A to 6E; (1040) a PartialMerklizeHierarchical function for creating an output hierarchical data structure as described with reference to FIG. 8B; and / or (1060) a MerklizeHierarchical function that uses the output hierarchical data structure as described with reference to FIG. 8B for the purpose of validating (900) the root node as described with reference to FIG. 9;

[0245] It should be noted that the PartialMerklizeHierarchical function is similar to MerklizeHierarchical, except that any values ​​that are not of interest are removed and / or are not generated. It should be noted that all of the above mentioned methods 1000, 1020, 1040, 1060 are for different interrelated purposes, but all of them are for constructing at least a portion of a hierarchical data structure as described herein for the purpose of obtaining / producing a root node (or enabling another part to obtain / produce a root node). In the first method 1000, the root node is stored in an immutable and / or trusted storage, in the second method 1020, the hierarchical data structure with the root node is for selective disclosure of values, and in the third method 1040, the generated / obtained root node is for comparison with the root node of (A) for verification purposes.

[0246] These methods 1000, 1020, 1040, 1060 are provided for illustrative purposes only, and those skilled in the art will appreciate that although the method steps are presented in a particular order, strict conformity to that order is not required and some steps may be performed in a different order and / or concurrently.

[0247] 10A, a first method 1000 is shown in which a MerklizeHierarchical function receives an input hierarchical data structure 1002.

[0248] Then, starting at the root node, the following steps are performed (1004):

[0249] Determine 1006 whether the node has any children. If the node does not have children, generate a digest based on the node's associated data. Preferably, the digest is a hash of the following normalized JSON structure: { pathSalt: "<string encoded path salt> ", value:<associated data of node> , version:<chain of commitments version> }

[0250] If the node has children, generate a digest based on the node's children. Preferably, the digest is a hash of the following normalized JSON structure, where the value is the string-encoded Merkle root hash of the digests of all its children: Thus, all of the digests associated with the children of the current node need to be determined, and the method continues by recursively taking each child node as input (1004). { pathSalt: "<string encoded path salt> ", value:<Merkle root hash based on child node's digests> , version:<chain of commitments version> }

[0251] 10B, a second method 1020 is presented as an alternative to the first method 1000. Here, a MerklizeHierarchical function receives an input hierarchical data structure (1022). Then, all of the nodes that have child nodes are found (1024). These nodes are parent nodes.

[0252] All leaf nodes (i.e., nodes with no children) are hashed 1026 using their values ​​as input.

[0253] The parent nodes are then ordered 1028 according to their depth (where depth is the distance from the root node).

[0254] Starting 1030 with the deepest parent node (which contains only leaf nodes as children), the ordinary Merklize function mentioned earlier is used to create a Merkle tree root, so that each parent node has an associated digest that represents that node. This digest is then used as part of any further Merklize functions on other parent nodes.

[0255] The root node and / or the entire constructed Merkle tree is returned to the caller (1032).

[0256] Thus, using the inputToAttestData referred to in Code Block 1 as an input to the example MerklizeHierarchical function above entails the following: (A) Identify all of the parent nodes of the input object. These are the root, "metadata", and "signature". (B) Identify the remaining nodes in the input object as leaf nodes. These are: 'esid', 'appVersion', 'sig', 'alg', and 'hashedData'. (C) Hash the leaf nodes to get their digests. Thus, esidDigest = H( "eyJ... ifQ" ), appVersionDigest = H( "v1.0.4.30" ), sigDigest = H( "cac... 093" ), algDigest = H( "ECDSA" ), and hashedDataDigest = H( "w6u... PI=" ) (D) Order the parent nodes according to their depth, from deepest to shallowest. These are "signature", "metadata", and the root. (E) For each parent in the ordered list of parents, Merkle-ize their children and compute their digest. So, in this example, for "signature", signatureDigest = Merklize({sigDigest, algDigest}) And for "metadata", metadataDigest = Merklize({appVersionDigest, signatureDigest, esidDigest}) and finally for the root, rootDigest = Merklize({hashedDataDigest, metadataDigest}) It is. (F) Return the rootDigest, which in this example is used as attestedDataN as described in Figure 6C.

[0257] Note that the deeper the Merkle tree root, the earlier it needs to be computed so that the digests of the Merkle tree root can be used in their parent Merkle tree nodes (such as the signatureDigest) (as can be seen for the metadataDigest, which requires the deeper signatureDigest to be computed first, since the metadataDigest is based on the signatureDigest).

[0258] The above exemplary method steps (A) through (F) are given only as simplified examples. Those skilled in the art will appreciate that other embodiments may also be used herein. For example, the hash in steps (C) and (E) is preferably also based on the associated pathSalt. As another example, the input data structure for the hash in steps (C) and (E) is also preferably a normalized JSON structure (instead of a string or digest), as described with reference to methods 1000, 1040, 1060 of Figures 10A, 10C, and 10D.

[0259] Those skilled in the art will also appreciate that the same algorithm can be used with different input data layouts with different nesting and values. The above is provided only as an example of how to Merkle input hierarchical data.

[0260] Those skilled in the art will also appreciate that the method 1000 discussed above is merely an example. Other methods of performing the MerklizeHierarchical function may also be used. These other methods may include (a) a recursive function invocation of MerklizeHierarchical, where MerklizeHierarchical is invoked on each node encountered while traversing the tree until a leaf node is reached, or (b) starting by iterating over each node in the leaf node layer and hashing them, and for each leaf node with a parent and running MerklizeHierarchical on said parent node, continuing the same process for each layer above the leaf node until the root node is reached.

[0261] 10C, an exemplary method 1040 for generating an output hierarchical data structure that reveals one or more nodes referenced by a data visualization path is shown. Preferably, the output hierarchical data structure generated by this exemplary method conforms to the structure 820 shown in FIG. 8B.

[0262] First, an input hierarchical data structure and at least one data visualization path are received (1042).

[0263] Next, starting from the root node of the hierarchical data structure (1044), It is determined (1046) whether the node is referenced in one of the paths and / or is an ancestor of one of the nodes. If the node is referenced in one of the paths and / or is not an ancestor of it, Generate 1048 a node in the output hierarchical data structure that stores the value and pathSalt (preferably in the form immediately below), and proceed to decision step 1046 for each child node of the current node. { pathSalt: "<string encoded path salt> ", value:<value of node> , } If the node is not referenced in one of the paths and / or is not an ancestor of it, Generate 1050 a node in an output hierarchical data structure that stores only the digest that represents the node (preferably in its immediately descendent form), and follow with decision step 1046 for each sibling node. { digest: "<digest string> ", }

[0264] The method ends when all of the nodes of interest have been "uncovered" and therefore the output hierarchical data structure is ready for transmission.

[0265] To help illustrate the method discussed above, the first few steps are described using the example of Code Block 1 as the input to this method 1040, and again using "metadata.signature.sig" as the path of interest.

[0266] The root node of any input hierarchical data structure is an ancestor of the node of interest, so after the first iteration the output hierarchical data structure looks the same as it did when it started. Then take the children "hashedData" and "metadata" of the root node. "hashedData" is not an ancestor of the node of interest, so it is replaced with its digest (based on its value and its pathSalt). Since "metadata" is an ancestor of the node of interest, an output is obtained with a value and a pathSalt. The value is based on the digests of all of its children, preferably the Merkle tree root based on the digests of its children. The method continues for each child node of "metadata" and until all of the nodes are exhausted.

[0267] Again, this method is exemplary and other steps may be taken instead to achieve the same output hierarchical data structure. Other methods may include getting all of the nodes and iterating over each node instead of traversing the tree as discussed in the exemplary method 1040.

[0268] 10D, an exemplary method 1060 for populating an output hierarchical data structure and verifying the digest of its root node is shown. Note that the method 1060 is similar to the creation of the output hierarchical data structure method 1040.

[0269] The first difference in this method 1060 is that a first step 1062 is to receive an output hierarchical data structure that comprises at least one revealed node value.

[0270] Another difference in this method 1060 is that the method is configured to start at a revealed node (1064), move up the tree toward the root, and calculate (1068) digests based on determining whether the node is a data visualization path or an ancestor of the node (1066), and / or use pre-computed digests along the way (1070).

[0271] Once all of the digests for the tree have been determined, the digest of the root node is obtained, which is preferably used for verification as discussed with reference to FIG.

[0272] Illustrative Examples As a further illustrative example to show how different data layouts may work with the method and system, the following input hierarchical data in Code Block 3 is used to illustrate this as it comprises an additional layer of nodes. In the current example, the input hierarchical data structure comprises a "rendezvousInstructions" node, the contents of which the operators of the system do not wish to disclose.

[0273] Code Block 3 { "hashedData": "w6uP8Tcg6K2QR905Rms8iXTlksL6OD1KOWBxTK7wxPI=", "metadata": { "appVersion": "v1.0.4.30", "esid": "eyJsIjoiZnJhbm ... cyI6IkVTIiwidiI6IjEifQ", "rendezvousInstruction": { "ref": "qux", "delegate": 0, "tags": ["foo","bar","baz"], "appendIf": null, "validFrom": null, "validUntil": "2022-02-17T11:58:21Z" }, "signature": { "alg": "ECDSA", "sig": "cac18b730f6f68b ... c36287d8093" }, "whenReceived": "2022-02-13T13:23:52Z" }

[0274] With the input hierarchical data, its root node is determined (preferably using method 1000 described with reference to FIG. 10A) and a corresponding hierarchical data structure is created in accordance with FIG. 6E such that a final stateDigestN digest is determined and stored in a blockchain transaction that is then sent for inclusion in the blockchain.

[0275] Later, a third party wants to verify that a user signed the data for a given event in the event stream. The signature data is stored in the path "metadata.signature.sig". The third party sends said path and an identifier that identifies the particular event.

[0276] The device receives the request, retrieves the associated input hierarchical data structure, and builds an output hierarchical data structure based on the input hierarchical data structure and the received path (preferably using method 1040 described with reference to FIG. 10C). The output hierarchical data structure has a JSON representation according to Code Block 4 below. A further Merkle proof configured to certify the output hierarchical data structure as well as the stateDigest is sent to a third party. Optionally, the output hierarchical data structure is transmitted to a third party based on the stateDigest. N It also contains the digest required to prove

[0277] Code Block 4 { "hashedData": { "digest": "qKmdAXm ... 4phZrh+lLhvxNc="}, "metadata": { "value": { "appVersion": { "digest": "26snnt ... p6CKM="}, "esId": { "digest": "g5jL3efi ... J774Ro="}, "rendezvousInstruction": {"digest": "xOqz ... JFUs="}, "signature": { "value": { "alg": { "digest": "Y887L ... G0UXaxLvg="}, "sig": { "value": "cac18b730f ... ac36287d8093" "pathSalt": "VrTHytBM ... MibV8I5D7U=" } }, "pathSalt": "sZL5UT ... XW3syF7z8=" }, "whenReceived": { "digest": "TFr4rtG ... xReemLCo="} }, "pathSalt": "wm0eEGCQwWhDYs0gqe3ydiIi49+0xTH6MmwswekqXq4=" }, }

[0278] Using the output hierarchical data structure, the third party verifies the root node digest (herein referred to as attestedDataN) of the output hierarchical data structure. Further attestations are used to obtain / verify the stateDigestN value. This calculated stateDigestN value is compared to the one obtained from the blockchain. If these two values ​​are the same, then the value revealed in "metadata.signature.sig" is the same as when it was originally recorded on-chain.

[0279] Note that a third party not only does not see any values ​​other than the values ​​of interest, but also does not see any other structure in the hierarchical data structure: even the names of the values ​​are not revealed under "rendezvousInstruction".

[0280] Event Stream Platform System According to a further aspect, any one or more of the preceding embodiments may be used in conjunction with a platform processor as described below to provide on-chain and off-chain data storage and / or validation of on-chain and off-chain data storage. This further aspect may be the provision of Platform as a Service (Paas) and Software as a Service (Saas) that advantageously enables rapid real-world useful business and technology applications, such as management of software-controlled technology systems or smart contracts, using a blockchain network such as the BSV blockchain.

[0281] An overview of the Platform Services can be seen in Figure 11, which shows a high level schematic diagram of the system. The Platform Services has a platform processor 1500 that provides an API 1508 through which the services can be accessed by one or more clients.

[0282] The platform services 1500 as shown in this figure consist of three groups of services, which aim to enable users and organizations to easily and securely take advantage of the benefits provided by the inherent properties of blockchain without actually implementing any blockchain-based software, knowledge, or libraries on the client side. A data service 1502 aimed at simplifying the use of the chain as a commodity data ledger. Preferably, the data service uses the data structures and methods provided herein to implement writing and reading of data to and from the blockchain. · Computation services 1504 aimed at providing a generalized computation network backed by digital assets such as Bitcoin SV. · Commerce services providing enterprise-class capabilities to conduct transactions using digital assets, such as Bitcoin SV1506.

[0283] Since the API is implemented as a web service, requests may be received from clients at the API via or using the HTTPS protocol. The requested service is then implemented by one or more service modules or processing resources 1502-1506 using background software 1510 for implementing implementations of resources, libraries, and / or key management wallets related to the blockchain, i.e., for creating, processing, and submitting transactions related to the blockchain. Once processed, the transactions may be submitted to the blockchain network 1512 (on behalf of a client implementing any such functionality or transaction library). At most, the client may or can implement a digital wallet or the like related to cryptocurrency or some other digital asset, although this is not required since the platform services 1500 may also be capable of providing and managing digital assets for the client.

[0284] FIG. 12 provides a more coarse-grained schematic view of a number of services related to the blockchain, which may be implemented by a platform 1600 related to APIs through which one or more of the services offered may be accessed. As seen in this FIG. 12, the data services 1602 may include a data writing service 1602a and a data reading service 1602b. The event stream and / or data writer optionally implement the method 700 as described in FIG. 7. Similarly, clients and / or third parties who wish to access data they have written using the embodiments described herein may use the data reader 1602b. Further details of the event stream are discussed with reference to FIGS. 4 to 8 of UK Patent Application No. 2002285.1 (filed on February 19, 2020 in the name of nChain Holdings Limited and incorporated herein by reference). The data writing service 1602a allows clients to write data to the blockchain in an easy, secure and optimized manner. The data read service 1602b allows clients to submit queries that return data stored in the blockchain. This can be using filtered streams such that clients can pre-define the type of data they want to read from the blockchain ad-hoc or periodically, i.e., within a certain time frame, or the type of data related to related or unrelated events or documents being processed in the blockchain 1610. A data archive function allows access to logs of previous transactions for a specified event or contract.

[0285] Computation services 1606 of platform 1600 include smart contract related applications 1606a and frameworks 1606b, which in some embodiments may be represented as state machines in a blockchain 1610. Computation services 1606 interact with data services 1602 because data needs to be input and results need to be provided to clients for any such computation.

[0286] The commerce services 1604 are responsible for providing enterprise-class capabilities via the enterprise wallet 1604a to explore the blockchain 1610 based on best-in-class security practices and technologies. For example, in some embodiments, the enterprise wallet may implement functionality to enable blockchain transaction processing when more than one person or user or account may need to approve a transaction that meets defined criteria, i.e., criteria related to large value cryptocurrencies that exceed predefined limits. The enterprise wallet may also include functionality to implement a threshold number of signatures and / or types of signatures for transferring large amounts of digital assets, such as cryptocurrencies or tokens that represent another resource. Transfers of these assets may then be represented on the blockchain according to criteria-based processing applied by such enterprise wallet implementations.

[0287] SPV service 1608 (simplified payment verification) is an example application that does not run a miner node and therefore requires information from the blockchain but does not include a direct link to it. Such an SPV service 1608 allows lightweight clients to verify that a transaction is included in the blockchain without downloading the entire blockchain 1610.

[0288] device Turning now to FIG. 13, an exemplary simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems or methods shown and described above. For example, the computing device 2600 may be configured to be used as one or more components in the systems 1500, 1600 of FIG. 11 or FIG. 12, or the computing device 2600 may be configured as a client entity, platform processor, and / or database manager associated with a given user that makes database requests and / or submissions. As a further example, the computing device 2600 may be configured to perform the methods 700, 800, 900, 1000, 1020, 1040 of FIG. 7, FIG. 8A, FIG. 9, FIG. 10A, FIG. 10B, and FIG. 10C. Still further, the computing device 2600 may be configured to generate, receive, and / or otherwise process on-chain and off-chain structures 504, 502, 600, 620, 640, 670, 680, 820 as described in Figures 5, 6A-6E, and 8B. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 13, the computing device 2600 may include one or more processors with one or more levels of cache memory and a memory controller (collectively labeled 2602), which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and persistent storage 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used for storage of information, such as details related to transactions and blocks as described in this disclosure.The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0289] The processor 2602 may also be in communication with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0290] The bus subsystem 2604 may provide a mechanism for allowing various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0291] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from and transmitting data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network such that the data technician may be able to transmit data to and receive data from the device while at a remote location, such as a data center.

[0292] The user interface input devices 2612 may include one or more user input devices such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0293] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection, or other display device. In general, use of the term "output device" is intended to include any possible type of device and mechanism for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used to present a user interface, for example, to aid in user interaction with applications that execute the described processes and variations thereof, when such interaction may be appropriate.

[0294] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives with associated removable media (e.g., CD-ROM or DVD or Blue-Ray), and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in this disclosure, as well as data related to transactions and blocks as described in this disclosure.

[0295] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through ports that connect the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 13 is intended only as a specific example intended to illustrate a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 13.

[0296] Exemplary Illustrative Use - Livestock Tracking An exemplary application of the ordered, append-only data storage as described herein with reference to Figures 5A to 13 is for use in livestock tracking. Secure tracking of all livestock ownership, use, and other management is required to comply with the rules and regulations of international livestock markets. In particular, the perceived risk of existing animal diseases and the emergence of new diseases highlights the importance of improving the security of livestock management in general. It can therefore be seen that advantageously using the ordered, immutable blockchain-based data storage and verification system described herein can assist anyone involved in the management, sale, purchase, and use of livestock in verifying that the information related to any animal they are dealing with is correct and immutable.

[0297] Vaccination status and ownership tracking are particularly important, and tamper-resistant and privacy-preserving sequential event recording (as described herein) can achieve or help achieve secure vaccination status tracking. The order in which events occur needs to be maintained to prove temporal ordering and dependencies or interferences in event occurrence.

[0298] Turning to a specific example of the system, FIG. 14 provides a schematic diagram 1400 of some possible data flows and processes as performed by different members in the system. As can be seen, a processing platform member 1408 performs actions 1420, 1422, 1424, 1426, 1428, 1430 based on some event stream (ES) blockchain writes. The event stream is provided here as a specific example of an API processing layer of interaction with the blockchain. Those skilled in the art will understand that other APIs may be possible that similarly maintain an ordered append-only list of events and store them in the blockchain according to the embodiments described herein. The processing platform 1408 may also be described as a blockchain interface system or server. Also shown is a blockchain-based validation process 1434 that uses blockchain data in coordination with any or all of the blockchain 1408, the processing platform 1406, and the livestock database 1404.

[0299] The proposed livestock tracking system 1400 comprises several hardware and software elements. A user of the system has a smartphone with a livestock management software application 1402. This application is configured to communicate with a livestock database (or other server) 1404. The livestock database is configured to interact with a processing platform 1406, referred to in the figure as the nChain platform. The processing platform is configured to record proof data in a blockchain 1408 according to a chain of transactions as described herein.

[0300] Each animal has an associated identification tag that uniquely identifies each animal among the livestock. The identification tag preferably has a unique identifier associated with and / or stored on the tag.

[0301] The identification tag is preferably in the form of an RFID (Radio Frequency Identification) tag implanted in the animal. Alternatively, the identification tag is a physical cattle ear tag with a QR code printed on it, which encodes a unique identifier and the QR code.

[0302] Preferably, Ultra High Frequency (UHF) RFID is used, which has a reading distance of 1m to 12m. UHF-RFID tags are passive, which means they do not require an additional power source. Passive tags are less expensive and therefore more affordable for farmers.

[0303] A livestock database 1404 is provided that comprises all unique identifiers associated with each animal and preferably stores additional information associated with each animal. For example, the owner of a given animal with its associated unique identifier is stored in the livestock database. Each owner is also identified by a unique account ID. Other information associated with each animal unique identifier is sex, condition, weight, and other descriptions. More preferably, linking to the unique identifiers of the animal's parents is possible in a hierarchical and / or relational manner (such as when using a relational database management system or the like via a foreign key).

[0304] In the proposed livestock tracking system, a smartphone application 1402 (or other hardware device comprising the same or similar application code as the smartphone application) is also provided that is configured to interact with or comprises an identification tag reader (such as an RFID scanner as discussed above) and configured to interact with a livestock database system.

[0305] 14 illustrates several events 1420, 1422, 1424, 1426, 1428, 1430 that use the processing platform 1406 to store data in a blockchain 1410 for later verification 1432. Preferably, the data stored in the blockchain is stored in a data digest (H) format as described herein. D ) and / or state digest (S). Said data stored on the blockchain acts as an on-chain "signature" and / or "notarization." These terms are used to describe the function of the data digest and / or state digest to provide a proof of existence for a verifier to verify data related to an event associated with an animal.

[0306] Several events 1420, 1424, 1426, 1428, 1430 comprise, use, or are associated with append events. Append events preferably involve the process of storing a transaction in the blockchain such that the transaction is associated with a chain of transactions as described herein. Create events 1422 preferably involve the creation of an event stream and / or the creation of a chain of transactions as described herein.

[0307] Preferably, the registration 1420 of a user with the livestock database platform triggers the storage of data in the blockchain 1408. The livestock database generates 1404 an account for the user and an associated unique account ID. The notarized data of the user's account creation is stored in the blockchain. In this way, the account ID and any associated metadata are stored with the account in an immutable and secure manner. Optionally, the account also has an event stream (and therefore a chain of transactions) associated with it so that any events involving the user can be tracked.

[0308] When a new animal, such as a cow, is registered (1422), a new event stream is generated so that any further information about the animal can be securely associated on the blockchain for later verification.

[0309] Exemplary events that may also be stored on the blockchain include performing a dipping (1424, 1430) and performing a vaccination of an animal (1426). Notarized data representing these events are stored on the blockchain and associated with the event stream for the same animal through the use of "append events" as described in FIG.

[0310] When ownership of an animal is transferred 1428 from one party to another (e.g., through a sale), another append event can be used to record the proof of ownership data of the new owner. Optionally, if the owner has an associated event stream, a rendezvous transaction is used to ensure that the event streams associated with the seller, buyer, and animal are all atomically synchronized on the blockchain, and that there is never a moment in the transaction history where an animal has two owners, no owner, or any other incorrect intermediate state in terms of the data stored on the blockchain.

[0311] If the animal does not need to be tracked any further by the livestock database 1404, a completion event is provided to the processing platform 1406. With a completion event, the event is completed and the last transaction stored in the blockchain has a null NEXT reference so that no further events can be appended.

[0312] Throughout an animal's life, there are many moments where proof of an event (such as vaccination) is required. The chain of transactions provides a proof of existence for all events that have occurred related to said animal, including vaccination events. Storing this proof of existence on a blockchain, as described herein, therefore provides an immutable and secure proof of existence.

[0313] Preferably, the verification process is as described under the heading "Proof of Existence Using Ordered Write-Only Data Storage". Preferably, the verifier 1410 performs the method described with reference to Figure 9 so as to be able to verify the livestock related data. Preferably, the processing platform 1406 and / or the livestock database 1404 are configured to perform the method described with reference to Figures 7 and 8A.

[0314] The verification process described herein allows a third party to verify various events related to any livestock being tracked. Through the use of the data visibility path, the livestock owner has control over what data can be presented to the verifier. For example, the verifier 1410 may only be interested in vaccination information for an animal, and specifically, the animal owner may prepare the data visibility path to only reveal information regarding vaccination status. In this way, any other information that the animal owner wishes to remain hidden (such as price, location, or any other private information) remains hidden, even if other information is stored in the same event.

[0315] The various methods described above may be implemented by a computer program. The computer program may include computer code adapted to instruct a computer to perform one or more functions of the various methods described above. The computer program and / or code for performing such methods may be provided to an apparatus such as a computer in one or more computer readable media, or more generally in a computer program product. The computer readable medium may be transitory or non-transitory. The one or more computer readable media may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system or propagation medium for data transmission, for example, for downloading code via the Internet. Alternatively, the one or more computer readable media may take the form of one or more physical computer readable media, such as a semiconductor or solid state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk such as a CD-ROM, a CD-R / W, or a DVD.

[0316] In some implementations, the modules, components, and other features described herein may be implemented as discrete components or may be integrated into the functionality of a hardware component, such as an ASIC, FPGA, DSP, or similar device.

[0317] A "hardware component" or "hardware module" is a tangible (e.g., non-transient) physical component (e.g., a set of one or more processors) capable of performing an operation and may be configured or arranged in a physical manner. A hardware component may include dedicated circuitry or logic that is permanently configured to perform an operation. A hardware component may be or include a dedicated processor, such as a field programmable gate array (FPGA) or ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform an operation.

[0318] Thus, the phrase "hardware component" or "hardware module" should be understood to encompass a tangible entity that may be physically constructed and permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein.

[0319] In addition, the modules and components may be implemented as firmware or as functional circuitry within a hardware device. Further, the modules and components may be implemented in any combination of hardware devices and software components, or in software alone (e.g., code stored or otherwise embodied on a machine-readable medium or transmission medium).

[0320] Unless specifically stated otherwise, and as will be apparent from the discussion that follows, throughout the description, discussions utilizing words such as "determining," "providing," "calculating," "calculating," "identifying," "combining," "establishing," "transmitting," "receiving," "storing," "estimating," "ascertaining," "obtaining," and the like will be understood to refer to the activities and processing of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electrical) quantities in the computer system's registers and memory into other data that is similarly represented as physical quantities in the computer system's memory or registers or other such information storage, transmission, or display device.

[0321] The term "comprising" as used in this specification and the claims means "consisting at least in part of." When interpreting each statement in this specification and the claims that includes the term "comprising," features other than those following the term may also be present. Related terms such as "comprise" and "comprises" should be interpreted in the same manner.

[0322] As used herein, the term "and / or" means "and" or "or" or both.

[0323] As used herein, "(s)" after a noun refers to the plural and / or the singular form of the noun.

[0324] The reference of an element in the singular does not exclude the reference of such elements in the plural and vice versa.

[0325] It should be understood that the above description is intended to be illustrative, not restrictive. Many other implementations will become apparent to those skilled in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to certain exemplary implementations, it will be recognized that the present disclosure is not limited to the described implementations, but can be practiced with modifications and alterations within the scope of the appended claims. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. The scope of the present disclosure should therefore be determined in conjunction with the appended claims, along with the full scope of equivalents to which such claims are entitled. [Explanation of symbols]

[0326] 100 Systems 101 Packet-switched networks, the Internet 102 Computer equipment, computer terminals 102a Alice's computer equipment, Alice's device 102b Bob's computer equipment, Bob's device 103 Users, Entities, Parties, and Agents 103a User, Entity, First Party, Alice 103b User, Entity, Second Party, Bob 104 Blockchain nodes, 1st node, Bitcoin node, transactions 105 Client Applications, Software, Clients 105a Client Applications 105b Client 106 Peer-to-Peer (P2P) Network, Blockchain Network, Bitcoin Network 150 Blockchain, Client Applications, Bitcoin Blockchain 151 blocks, blockchain 151n-1 Block 151n Block 152 Transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Transactions, and Pools 155 Block Pointer 160 Blockchain Network 201 Header 202 Input, input field 203 Output Fields, Transaction Outputs, and UTXOs 301 Side Channel 351 Transaction Engine, Protocol Engine 352 User Interface (UI) Layer 353 Features 360 User Interface (UI) 362 UI Elements, User Selectable Elements, Data Entry Fields 363 UI elements, information elements 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Memory Module 500 Systems 502 On-Chain Data Storage 504 Off-Chain Data Storage 506 Log Entries 508 Blockchain Transactions 510 Funding Entry 512 Data and References 600 Data Structures 602 NEXT 604 CURRENT 606 PREV 608 Root 622 Input 624 Input 626 Input 628 Input 630 Input 632 Input 634 Input 638 child nodes 640 Hierarchical Data Structure 642 nodes 644 nodes 646 nodes 648 nodes 650 nodes 652 nodes 654 nodes 656 Input 658 Input 660 Input 662 Input 664 inputs 672 pathSalt 682 pathSalt 820 Output hierarchical data structure 1500 Platform Services 1502 Data Services 1504 Calculation Services 1506 Commerce Services 1508 API, Platform API 1510 Blockchain Node Software 1512 Blockchain Network 1600 Platform 1602 Data Services 1602a Data writing service, data writer 1602b Data reading service, data reader 1604 Commerce Services 1604a Corporate Wallet 1606 Computational Services 1606a Application, Smart Contract Application 1606b Framework, Smart Contract Framework 1608 SPV Service 1610 Blockchain, Blockchain Network 2600 Computing Devices 2602 Cache memory and memory controller, processor 2604 Bus Subsystem 2606 Storage Subsystem 2608 Main memory, memory subsystem 2610 Persistent Storage, File Storage Subsystem 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 Dynamic Random Access Memory (DRAM) 2620 Read-Only Memory (ROM) 2624 Clock< / pa>

Claims

1. A computer-based method for providing proof of existence, A step of receiving a request comprising a data visualization path, wherein the data visualization path references a node of interest in an input hierarchical data structure. A step of obtaining an input hierarchical data structure comprising an input root node and a plurality of input nodes, wherein each of the input nodes in the input hierarchical data structure has a corresponding value, A step of generating an output hierarchical data structure based on the data visualization path and the input hierarchical data structure, wherein the output hierarchical data structure comprises a plurality of output nodes, Each of the aforementioned multiple output nodes has a related node in the input hierarchical data structure, The plurality of output nodes comprises an output root node and an output node of interest related to the node of interest in the input hierarchical data structure, The output node of interest and each ancestor node of the output node of interest have values, and all other nodes in the output hierarchy data structure have digests based on the relevant values ​​of the corresponding nodes in the input hierarchy data structure. method.

2. The method according to claim 1, wherein the digest associated with the input root node and the digest associated with the output root node are the same.

3. The method according to claim 1, wherein the effectiveness of the node of interest is determined based on a comparison of the input root node and the output root node.

4. The method according to claim 1, further comprising the step of recording data based on the aforementioned input root node onto a blockchain.

5. The method according to claim 4, wherein the data based on the root node of the input hierarchical data structure is a digest based on the input root node.

6. The method according to claim 1, wherein all ancestor nodes of the output node corresponding to the data visualization path and the output node corresponding to the data visualization path of the output hierarchical data structure further comprise salts.

7. The method according to claim 6, wherein the salt is based on a randomly generated value.

8. The method according to claim 6, wherein each salt is based on the path of its associated node.

9. The method according to claim 8, wherein each salt is a digest based on the path of a randomly generated value and its associated node.

10. The step of generating the output hierarchical data structure is, For each given node in the input data structure, starting from the root node, Based on the determination that the given node is a node of interest and / or its ancestor, the steps include inserting a value based on the given node into the output hierarchy data at a position corresponding to the position of the given node in the input data structure, or Steps to insert a digest based on the value of the given node at a position in the output hierarchy data corresponding to the position of the given node in the input data structure, based on the determination that the given node is not the node of interest and / or its ancestor: The method according to claim 1, comprising the step of performing

11. The method according to claim 1, wherein the request comprises one or more data visualization paths, each data visualization path refers to a node of interest, each node of interest and all ancestors of the node of interest in the output hierarchical data structure comprises values, and all other nodes in the output hierarchical data structure comprise digests.

12. The method according to claim 1, wherein the hierarchical data structure and / or the output hierarchical data structure are represented using JSON objects.

13. The method according to claim 12, wherein the JSON object has a canonical format.

14. The method according to claim 1, wherein each node of the output hierarchical data structure, excluding leaf nodes, is a Merkle tree root such that a digest for each node can be calculated based on the digests of its child nodes.

15. The method according to claim 1, further comprising the step of transmitting the output hierarchical data structure.

16. The method according to claim 15, wherein the output hierarchical data structure is transmitted to the sender of the request.

17. The method according to claim 1, wherein the digest of each node in the output hierarchical data structure, which includes a digest, deletes or edits values ​​associated with the node.

18. The method according to claim 1, wherein the value of the ancestor node of the output node of interest is based on its child nodes.

19. The value of the ancestor node of the output node is A digest based on a Merkle root hash encoded with all the strings of the aforementioned digest of that child node, or Representation of its child nodes such that the aforementioned digest can be calculated The method according to claim 18, wherein the method is or comprises the method.

20. A device configured to perform the method described in any one of claims 1 to 19.

21. A computer program comprising, when the program is executed by a computer, an instruction causing the computer to perform the method described in any one of claims 1 to 19.

Images