COMPUTER-IMPLEMENTED METHOD AND SYSTEM

Abstract

The present disclosure relates to a computer-implemented method for validating a blockchain-stored representation of a dataset, the method comprising obtaining a dataset reference to an on-chain dataset, the on-chain dataset comprising data stored on the blockchain and carrying transactions, each data carrying a transaction comprising data indicative of an event stored in an off-chain dataset, the method includes examining the on-chain dataset, determining for each data carrying a transaction in the on-chain dataset that data indicative of an event in the off-chain dataset is associated with an event in the off-chain dataset, and verifying that the on-chain dataset and the off-chain dataset correspond to each other.

Description

[Technical field]

[0001] The present disclosure relates to methods and systems 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 in the network for it to be 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 area of ​​current research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the execution of machine-readable contracts or terms of agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs with rules that can process inputs to produce outcomes, and the rules allow actions to be performed depending on those outcomes. Another area of ​​blockchain-related interest is the use of "tokens" (or "colored coins") to represent and transfer real-world entities through the blockchain. Potentially sensitive or secret items can be represented by tokens, which have no discernible meaning or value. Thus, tokens act as identifiers that allow real-world items to be referenced from the blockchain. [Prior art documents] [Patent documents]

[0010] [Patent Document 1] UK Patent Application No. 2013929.1 [Patent Document 2] UK Patent Application No. 2102217.3 [Patent Document 3] UK Patent Application No. 2106950.5 [Patent Document 4] UK Patent Application No. 2102314.8 [Patent Document 5] UK Patent Application No. 2002285.1 Summary of the Invention [Problem to be solved by the invention]

[0011] The above mentioned examples or scenarios, while taking advantage of the benefits of blockchain to provide a permanent and tamper-resistant record of events, require the client, client entity, computing device, or terminal associated with the client to include or implement software and / or hardware, or a processor / module, such as a digital wallet to implement functionality for managing digital assets, for example 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 performing the construction of blockchain transactions and has access to the BSV library. Thus, the client not only needs to include processing to implement such functionality, but also needs to ensure that appropriate security measures are in place for such processes before the blockchain network can be utilized to send, receive, and view data and / or digital assets related to tokens representing smart contracts or real-world asset transactions.

[0012] It is therefore desirable to implement a secure, uncomplicated, user-friendly, efficient, and robust technique that allows any client, regardless of computational power, to instantly access and interact with useful blockchain-related applications in a computationally and functionally less onerous, easy, fast, accurate, reliable, and secure manner. More specifically, it is desirable to utilize the benefits of distributed ledger (blockchain) technology and the 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 of data that can be created, written, updated, read, or viewed as needed.

[0013] Such an improved solution has been devised. The present disclosure addresses the above technical problems by proposing one or more techniques whereby data or information related to a client may be easily, securely, and instantly written to or retrieved from a blockchain by methods, devices, and systems that provide an application programming interface (API) for one or more services related to the blockchain, without the need for such clients to implement any processing or functionality to use the blockchain, while still being able to leverage all the benefits associated with the blockchain. [Means for solving the problem]

[0014] In a first aspect, the present disclosure proposes a method, device, and system for maintaining the status of a stream on a blockchain. More specifically, the method of the first aspect includes receiving a stream creation message, where the stream creation message comprises an indication of a condition for a trigger, and based on the trigger condition being satisfied, obtaining data indicative of a state of the stream, and generating an append transaction comprising the data indicative of the state of the stream.

[0015] In a second aspect, the present disclosure proposes a method, device, and system for validating a representation stored in a blockchain of a dataset. More specifically, the method of the second aspect comprises the steps of obtaining a reference to an on-chain dataset, the on-chain dataset being stored in a blockchain and comprising data carrying transactions, each data carrying a transaction comprising data indicative of an event in an off-chain dataset, examining the on-chain dataset, determining for each data carrying a transaction in the on-chain dataset that the data indicative of the event in the off-chain dataset is associated with a data item in the off-chain dataset, and validating that the on-chain dataset and the off-chain dataset correspond to each other.

[0016] In a third aspect, the present disclosure proposes a method, device and system for creating and validating a blockchain-stored representation of a dataset. More specifically, the method of the third aspect comprises generating an on-chain dataset using the method according to the first aspect and validating the on-chain dataset according to the second aspect.

[0017] Certain specific components and embodiments of the disclosed method will now be described by way of example 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 user interface. [Figure 3B] FIG. 2 illustrates an exemplary implementation of a client application and its user interface. [Figure 4] FIG. 1 illustrates an example of node software running on each blockchain node in the network. [Diagram 5] 1 is a schematic diagram illustrating a platform processor, a database, and the submission of event data to a blockchain network. [Figure 6A] 1 is a flowchart illustrating a method for publishing the current state of an event stream to a blockchain. [Figure 6B] FIG. 1 is a sequence diagram illustrating data and / or process flow associated with a timer condition being satisfied. [Figure 7A] FIG. 1 is a schematic diagram showing a chain of transactions. [Figure 7B] FIG. 2 is a schematic diagram of an example transaction. [Figure 7C] FIG. 2 is a schematic diagram of an example transaction. [Figure 8] FIG. 1 is a schematic diagram illustrating validation of a dataset represented in a blockchain. [Figure 9] 1 is a flowchart illustrating a method for validating an on-chain data set with an off-chain stored event stream. [Figure 10] FIG. 1 is a schematic diagram illustrating an overview of a platform for multiple blockchain-related services, according to an embodiment. [Figure 11]FIG. 1 is a schematic diagram illustrating components of a platform for multiple blockchain-related services, according to an embodiment. [Figure 12] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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 respective 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.

[0024] 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.

[0025] 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.

[0026] 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 entity 103 included in the input of new transaction 152j matches a condition defined in the output of a preceding transaction 152i that the new transaction assigns, which condition typically comprises at least verifying that a cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of a 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 preceding transaction 152i.

[0027] Alternatively, it may simply be fixed by the blockchain node protocol alone, or it may be by a combination of these. In either case, 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 way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0028] In an output-based model, the definition of whether a given output (e.g., UTXO) 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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).

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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 throughout 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 the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0040] 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.

[0041] 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 party 103 is a recipient (or in an embodiment, actually investigate the transactions of other parties 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.

[0042] 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.

[0043] 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.

[0044] 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 1511. 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.

[0045] 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).

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labelled UTX00. 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 in order 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.

[0052] 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.

[0053] Thus, in the example shown, UTXO0 in Tx0's output 203 must have Alice's signature SIG P A Locking script that requires [Checksig PA ]. [Checksig P A ] is the public key P from Alice’s public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID. Tx1's input 202 comprises a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. Tx1's input 202 further comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A 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.

[0054] 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 P A > <P A >||[Checksig P A ] Here, "||" 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. Either way, when executed together, the scripts will create a lock that contains Alice's public key P, as contained in the locking script in the output of Tx0. A is used to authenticate that the unlocking script in Tx1's input 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 (so there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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, a transaction fee may be explicitly specified in its own UTXO 203 of transaction 152.

[0060] 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.

[0061] 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.

[0062] Typically, the input for a transaction is a public key P AIn 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 normally 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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 embodiments disclosed herein, the transaction engine 351 of each client 105 comprises a function 353.

[0067] 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.

[0068] 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.

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

[0070] 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.

[0071] 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).

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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 ) 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 may generate 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 Txi locates the locking script in the referenced output of and passes it to the script engine 452.

[0076] Therefore, the script engine 452 executes the Tx i Locking script and Tx j 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).

[0077] 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".

[0078] 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; iThe 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 embodiments, 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 the transaction only under the condition that the transaction is valid and has sufficient transaction fees remaining.

[0079] 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).

[0080] 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, and not by the described embodiments.

[0081] 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.

[0082] 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).

[0083] 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.

[0084] 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.

[0085] Blockchain storage of event streams A first aspect of the present disclosure generally relates to providing blockchain storage of event streams as part of a platform that provides a number of blockchain-related services, the platform being implemented by at least one platform processor that performs a method and is provided for a number of clients and that is associated with an application programming interface (API).

[0086] The method includes the steps of receiving a stream creation message, the stream creation message comprising an indication of a condition for a trigger, and, based on the trigger condition being satisfied, obtaining data indicative of a state of the stream, and generating an additional transaction comprising the data indicative of the state of the stream.

[0087] The method preferably comprises after generating the add transaction, a step is performed of preparing the add transaction for broadcast to the blockchain.

[0088] Advantageously, by providing triggers for the generation (and subsequent submission) of transactions that represent the current stream state, greater flexibility and choice is achieved regarding how new the blockchain representation of the stream needs to be. When a client creates an event stream, they can choose the aspect of the trigger depending on their requirements.

[0089] In some embodiments, the method further comprises monitoring for a reoccurrence of the trigger condition.

[0090] For longer term event streams, the trigger condition may occur multiple times, and the on-chain data set is updated as needed by monitoring when additional trigger conditions are met.

[0091] In some embodiments, the method further comprises generating (and optionally broadcasting) an initial transaction comprising at least data based on an indication of a condition for the trigger. In some embodiments, the data based on the indication of a condition for the trigger is stored in an output of the initial transaction. In some embodiments, the additional transaction comprises an input that consumes an output of the initial transaction or a previous additional transaction. Preferably, the data based on the indication of a condition for the trigger is an indication of a condition for the trigger.

[0092] Advantageously, by consuming the output of the preceding append transaction in the initial or append transaction, the order in which each event occurs is preserved on the blockchain. A transaction cannot be included in the blockchain if it originates from a transaction that is not yet part of a block, or at least not part of the same block. Preservation of order is advantageous in that if a participant is interested in knowing the current state of the event stream, they only need to look up the consuming chain until the end. No further checks are required to determine if the transaction with the unconsumed output is the last transaction, thus saving computational resources.

[0093] A further benefit of such a consumption relationship is the exploreability of on-chain datasets, as discussed below under the heading “Exploring on-chain datasets.”

[0094] In some embodiments, data indicative of the state of the stream is stored at the output of the append transaction. Preferably, the OP_RETURN opcode is used. More preferably, the data is stored after the OP_RETURN opcode.

[0095] Advantageously, repurposing existing features of blockchain transactions (such as the above-mentioned use of transaction outputs and the use of the OP_RETURN opcode) means that miners or other blockchain processing devices associated with the blockchain do not require any technical capabilities beyond what they already have.

[0096] In some embodiments, the trigger condition is based on any one or more of receiving a message indicating that the stream is complete, an elapsed time, a comparison of the elapsed time to a threshold time, and / or a comparison of the number of events received to a threshold number of events.

[0097] Advantageously, different trigger systems can be provided for different client needs and selected by the client.

[0098] In some embodiments, the elapsed time is based on the time since a preceding trigger condition was met and / or the time since the create message was received. In some embodiments, the create message further comprises a threshold time.

[0099] Decoupling transaction submission to the blockchain from event stream updates, preferably using the features described above, provides several advantages, including: Concealing the exact number of events that have occurred. For example, if it is known that a stream is updated on-chain every 50 events, a third party can simply count every on-chain append transaction and multiply that count by 50 to get a rough idea of ​​the total number of events. Depending on the smart contracts involved, this may leak sensitive information to third parties; and Prevent any loops from occurring, where an event stream tracks its own on-chain submissions, and any event emitted into the event stream triggers the creation of another event, and therefore another event transaction, and so on.

[0100] In some embodiments, the number of events received is based on the number of events received since a preceding trigger condition was met and / or the number of events received since the create message was received. In some embodiments, the create message comprises a threshold number of events. In some embodiments, the threshold number of events is one. In some embodiments, the threshold number of events is greater than one.

[0101] In some embodiments, the trigger condition is based solely on a comparison of an elapsed time to a threshold time.In some embodiments, the trigger condition is based solely on a comparison of a number of received events to a threshold number of events.

[0102] In some embodiments, the state of the stream comprises a hash of a pre-image of the latest event of the stream. In some embodiments, the state of the stream comprises a pre-image of the latest event of the stream. In some embodiments, the state of the stream comprises data indicative of data of the latest event of the stream. In some embodiments, the data indicative of data of the latest event of the stream comprises a hash of data of the latest event of the stream. In some embodiments, the data indicative of data of the latest event of the stream is data of the latest event of the stream. Preferably, the pre-image comprises metadata of the latest event of the stream.

[0103] The advantages of these technical features are given generally, but specifically, under the heading "Current State of the Stream."

[0104] In some embodiments, the stream creation message comprises an indication of the format of data indicating the state of the stream.

[0105] Advantageously, by providing an indication of the format of the stream state data as it is always recorded on the blockchain itself, a third party wishing to validate, audit, or read the data as it is stored on the blockchain only needs to find the initial transaction to properly read the remainder of the on-chain dataset, without the need to decrypt any further information or communicate with other parties, data stores, or devices beyond what is present on the blockchain.

[0106] In some embodiments, the method further comprises updating an off-chain database with metadata of the appended transaction, in some embodiments, the metadata is used to identify the transaction on the blockchain, to verify the existence of the transaction in a block on the blockchain, or to construct a proof of inclusion of the transaction in the blockchain.

[0107] Preferably, the metadata comprises any one or more of the transaction id of the add transaction, a subset of the inputs to the add transaction, a block header of the block in which the add transaction is contained, a block id of the block in which the add transaction is contained, a timestamp associated with the add transaction, and an array of sibling hashes for the transaction id of the add transaction. More preferably, the metadata comprises the transaction id of the add transaction, a block header of the block in which the add transaction is contained, and an array of sibling hashes for the transaction id.

[0108] In some embodiments, the method further comprises receiving a request to add an event to the stream, the request comprising the event data and an override flag; generating a further append transaction comprising data indicative of the event data; and preparing the append transaction to be broadcast to the blockchain.

[0109] Advantageously, storing the proof of existence on the blockchain increases security and provides auditors with an easier means to verify that data exists when it should be in the on-chain dataset.

[0110] According to a first aspect, a device comprises a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform the computer-implemented method described above.

[0111] Also according to a first aspect, a system comprises a platform processor according to the above device described above, and a client device configured to emit event data to the platform processor.

[0112] Advantageously, the methods, devices, and systems as described above in the first aspect allow clients to choose how much information, how frequently, and what information they want to store in the blockchain. The benefits and advantages of each different method and data type of storage are described below.

[0113] 5 relates to a system 500 according to a first aspect of the present disclosure for enabling event data to be stored in a database and data indicative of the event data to be stored in a blockchain. Optionally, the representation is the event data itself, a digest of the event data, and / or a reference to the event data. The event data in this embodiment relates to an event stream.

[0114] An event stream provides a log of a strict sequence of events executed in sequence and is implemented at least partially on a blockchain. In some embodiments, the event stream is implemented using a blockchain and / or in an off-chain database. An event stream may represent or track a finite state machine (FSM), such as a deterministic finite automaton (DFA), a well-known computing term that represents a system with a finite number of states, which may be in only one state at a given time, with transition functions or trigger events to transition from one state to the next. In some embodiments, such event streams are useful for representing control measures or techniques for technological processes.

[0115] The disclosure related to this aspect provides a smart contract, which may be an FSM, as a usage of the event stream, as discussed immediately below, which is given as an example and others will be apparent to one of ordinary skill in the art.

[0116] An event stream represents a machine-readable contract or smart contract on a blockchain, advantageously an immutable record of the smart contract's past and current inputs is written to the blockchain. When these inputs are replayed, it results in a deterministic state of the smart contract. Thus, an event stream is associated with a smart contract and / or vice versa. An event stream may also be associated with an ordered data logger, a tracker for an off-chain, real-world, process with a fixed set of states, or a sequence of inputs (optionally with the results of said inputs) provided to a real-world off-chain process. Those skilled in the art will appreciate that other systems besides smart contracts may also advantageously use immutable FSMs or DFAs.

[0117] The system 500 comprises a client 502 configured to interact with a platform processor 504 associated with an API for a service. The platform processor 504 is described herein as a monolithic server for ease of illustration. Those skilled in the art will appreciate that it may be implemented as a single server, a mainframe, a collection of servers, microservices, a collection of microservices, cloud services, any combination of the preceding and / or other computing platforms.

[0118] The client 502 communicates 510 with the platform processor 504 via the platform processor's API. In this example of this aspect, the client 502 is configured to at least create, update, and complete the event stream. UK Patent Application No. 2013929.1, filed on September 4, 2020 by nChain Holdings Ltd, provides an illustrative example of a platform processor that may be used to manage smart contracts and / or any other application using the event stream.

[0119] The platform processor 504 is associated with a snapshot instance database 506 configured to store, update, provide, and / or represent the current state of the smart contracts as recorded in their respective event streams at any given time. There is only one event stream per smart contract associated with a given client of the multiple clients. In some embodiments, each client of the multiple clients may be associated with an account or identifier that may be used to identify a particular smart contract associated with the respective client. The platform processor 504 is configured to communicate 512 with the database 506 to at least store, access, and update the recorded event data associated with each event stream.

[0120] The platform processor 504 is configured to store a representation of the event stream in the blockchain. Accordingly, the platform processor 504 is configured to communicate (514) with the blockchain network 101. The blockchain network 101, an example of which is described above with reference to FIG. 1, stores the transaction's associated event data (or data representing said event data) in the blockchain. An example transaction is described above with reference to FIG. 2.

[0121] The platform processor 504 is configured to both put data onto the blockchain network 101 and read data from the blockchain network 101. Optionally, the platform processor 504 maintains its own private copy of the blockchain (optionally pruned) so that it does not have to ask network nodes for blockchain data.

[0122] 6A, a method 600 for maintaining a representation of an off-chain dataset in an on-chain dataset is shown. A dataset is a set of events, where the source of each of the events is the client that creates it and / or any party to which authority has been delegated by the client.

[0123] The dataset used as an example in this aspect and with reference to Figure 6A is preferably stored entirely in an off-chain database or other data store means. In a preferred embodiment, the data represents a subset of the events stored in the blockchain. Each transaction stored in the blockchain preferably represents a state of the stream, and more preferably, the state of the stream refers to the most recent event.

[0124] This method is preferably executed by the platform processor 504 and is executed each time a client desires to create a new event stream. Preferably, the method operates as long as the event stream is active. The client 502 optionally provides an indication to the platform processor 504 as to when to complete and close the event stream.

[0125] First, an event stream is created (602) when a message to create an event stream is received. This message is optionally in the form of an API request and originates from a client 502. The create message comprises an indication of the conditions when data should be stored in the blockchain and in what format the data should be stored. These conditions may also be thought of as "conditions for triggering" or "trigger conditions" since they trigger at some point.

[0126] Optionally, an initial transaction is created and submitted to the blockchain at this point. The initial transaction 660 is preferably in the format as described with reference to Figure 7C. The conditions for the trigger and the type of data to be stored are stored in the initial transaction.

[0127] When a trigger condition is met (604), either by creating a stream or receiving a create stream message, the transaction is added to the blockchain. Optionally, the method waits until the trigger condition is met. "Waiting" in this context preferably relates to a suspend system so that the process does not have to actively look for the condition to be met. Alternatively or additionally, waiting relates to using polling to see if the condition has been met.

[0128] When the trigger condition is met, the current state of the event stream is obtained 606. The format and content of the current state of the stream and / or the data indicative of the current state of the stream are described in further detail below under the heading "Current State of the Stream."

[0129] An add transaction is generated (608), which comprises data indicative of the current stream state. The add transaction is preferably in a format as described with reference to Figure 7B, and the data indicative of the current state of the stream is stored in a payload output of the add transaction. The add transaction further comprises an input that consumes an output of a previous transaction that is emitted to a blockchain for the current event stream as discussed with reference to Figures 7A and 7B. Thus, the generating step further comprises obtaining a reference to the latest transaction in the chain of transactions, which reference is preferably the dust output point of the preceding transaction.

[0130] The append transaction is arranged to be broadcast to the blockchain network 101 for addition to the blockchain (610). Arranging for the broadcast of the append transaction in this manner preferably comprises sending the append transaction to a further thread, process, or device configured to submit data to a blockchain node for inclusion in the blockchain. This transmission is preferably performed using a message bus as described with reference to FIG. 6B.

[0131] The generating and appending steps are optionally performed asynchronously in separate threads, processes or devices, for example using a message bus as described with reference to Figure 6B.

[0132] The method then loops back to the beginning and waits for the trigger condition to be satisfied again. Optionally, the method additionally waits for a completion message to be received and / or for a completion condition to be satisfied. The completion condition is optionally included in the create message, just like the trigger condition.

[0133] 6B relates to an example process 612 of the present aspect. In this example embodiment, a timer-based trigger condition is used. The example process 612 shown may be executed or performed by the platform processor 504.

[0134] Prior to the process as shown, a timer is established such that when the timer starts, the process is awakened in step 614. The current stream state is then obtained (616). This is obtained from the database 506. Optionally, the current stream state is processed.

[0135] The current stream state is published to the blockchain via a message bus 618. Publish messages on the message bus allow additional services or processes to ingest the stream state data and put it out onto the blockchain.

[0136] Optionally, once a transaction with a stream state has been included in a block and / or confirmed on the blockchain (confirmation typically means that six blocks have been added after the inclusion of the transaction), transaction metadata and / or the transaction itself are obtained (620). Transaction metadata is described in more detail below under the heading "Updating Off-Chain Datasets with On-Chain Metadata."

[0137] Metadata for the transaction is stored in a database 622. Optionally, if the stream state is the latest event in the event stream, the event database entry is updated with the transaction metadata and / or the event database entry is tagged as submitted to and / or confirmed on the blockchain.

[0138] If the most recent event has already been published to the blockchain when the trigger condition is met again, the same most recent event is published to the blockchain again.

[0139] Alternatively, the presence of tags and / or transaction data in the database is used such that if the trigger condition is met and there is no new event data and the current most recent event is tagged as already on the blockchain, then no new transaction is created and the process waits for a further trigger.

[0140] Chains of Dust Referring to FIG. 7A, an exemplary chain of transactions 638 (also known as a "chain of dust") is shown. The chain of transactions comprises several transactions 660, 640, 640a, 640b, 662 that are related to each other. The first transaction 660 is the initial transaction and comprises metadata about the chain. The chain also comprises several additional transactions 640, 640a, 640b, preferably comprising data indicative of event data stored in an off-chain database. The additional transactions 640, 640a, 640b, and the last transaction 662 also comprise inputs related to outputs from transactions that precede them, thus establishing a consuming relationship (represented as arrows in FIG. 7A). The input is in the form of an output point, which is a transaction id and an index of the output. The input consumes a transaction output from a previous transaction. As an example, with respect to the Bitcoin protocol, as described above under the heading "UTXO-Based Model" and with reference to Figure 2, outputs are unspent transaction outputs (UTXOs) and inputs comprise references to UTXOs. Thus, each transaction (except the first) comprises a back-reference to a previous transaction in the dust chain via a spend relationship. The initial transaction comprises an input with a back-reference to a funding UTXO, as described below with reference to Figure 7C. This funding UTXO is not considered to be part of the dust chain because it does not store data or metadata about the dust chain.

[0141] A chain of dust is an unbroken chain of Bitcoin inputs and outputs, which is used here to impose a spending dependency of each blockchain transaction in a sequence on the transaction immediately preceding it. "Dust" in the context of blockchain transactions in this disclosure is understood to be a spendable transaction for a digital asset or cryptocurrency that has a low or very small value output, i.e., the value can be much less than the fee for mining the output in the blockchain.

[0142] The use of dust outputs in transactions is advantageous and important to maintain an immutable, sequential record of all transactions as they occur for an ordered, append-only data storage system such as an Event Stream. The reason is that by posting a transaction to the blockchain, all blockchain transactions are time-stamped and remain in a particular order when confirmed on or added to the blockchain, but this does not guarantee the preservation of their sequential order. This is because transactions may be mined into blocks at different times and / or the transactions may be out of order even within the same block. The use of dust outputs that are consumed by the first input of the next transaction in the sequence advantageously ensures that the order of transactions is tracked over time, creating a tamper-resistant record of both the events themselves and the sequential order of the events. This is because, once mined into a block, the payment of dust from the previous transaction to the next transaction in the sequence ensures that, according to Bitcoin protocol rules, the sequence of embedded data-carrying elements, called payloads and discussed below, cannot be reordered and no insertion or deletion can occur that could change the sequence without it being immediately apparent that the event stream has been compromised. In some embodiments, the double-spend prevention mechanism inherent in the Bitcoin protocol ensures that the movement of cryptocurrency (e.g., dust) between different transaction inputs and outputs remains in topological order. The chaining of dust transactions exploits the topological ordering to result in the preservation of the order of transactions (and thus associated events and data) between and within blocks. This therefore increases the integrity of the ordered, append-only data item storage. Furthermore, dust is the smallest output that miners are willing to process.If a malicious third party were to possess the private key for a given user, it would not be possible for that third party to fork the Dust chain, as any attempt to split the Dust outputs (e.g., 273 satoshis for each output) would be ignored by miners.

[0143] Thus, the blockchain transactions 638 form a directed graph of transactions. Note that the direction of the graph can be considered to be unidirectional, from the previous transaction in the sequence to the next transaction, as indicated by the edges (shown as arrows in FIG. 7A , in particular the arrows indicate the direction in which the references are pointing, i.e. Tx n+1 Tx n (This is the opposite direction of how time and data are moving forward.) This graph is created by the consumption relationships between transactions. These consumption relationships can be thought of as being a type of reference.

[0144] 7B and 7C, exemplary blockchain transaction formats are shown for data append transactions 640a, 640b, initial transaction 660, and final transaction 662. As these are blockchain transactions, they are similar in structure to transactions 152i, 152j described with reference to FIG. 2, but with certain components relevant to this aspect of the invention. The exact order of inputs and outputs is not specific and alternative orders may be used. This order is preferably consistent on a given chain.

[0145] Data related to each event is stored in a payload as part of each transaction. The data payload and / or other data to be "stored" in the transaction (such as trigger conditions for the initial transaction) is held in the transaction's non-consumable OP_RETURN output, which is a Script opcode that can be used to write arbitrary data to the blockchain and also to mark transaction outputs as invalid. As another example, OP_RETURN is a Script language opcode for creating a non-consumable output of a transaction that can store data such as metadata in the transaction, thereby immutably recording the metadata on the blockchain.

[0146] 7B shows two data append transactions 640a, 640b. These exemplary data append transactions 640a, 640b arrive consecutively in time and in the dust chain. The dust output 644a of the first transaction 640a is referenced in (i.e., consumed by) the dust input 646b of the second transaction 640b. The dust input 646b of the second transaction 640b's reference to the dust output 644a of the first transaction 640a comprises both the transaction id 648a of the first transaction and the index of the UTXO, which in this exemplary case is 0 (because it is the first in the list and zero indexing is used).

[0147] All of the transactions 640a, 640b, 660, 662 comprise funding inputs 648a, 648b, 648c, 648d. These funding inputs 648a, 648b, 648c, 648d are provided by a computing device that manages, creates, and submits these transactions to the blockchain. The total value of the funding input is selected to include a transaction fee (sometimes called a miner's fee) to help miners ensure that they pick the transaction and include it in a block. The funding service may provide one or more inputs to ensure that the total value is sufficient for the input. The transaction fee is variable and depends on the load of the network. The transaction fee may be in units of satoshis (or any coin / token used by the blockchain system) per byte (a satoshi is 1 / 100 millionth of a bitcoin). Thus, if the payload is large, the fee must be large and the funding input is adjusted accordingly. As a result of the UTXO model, the total fee paid depends on the value of both the UTXO referenced in the input and the UTXO of the output. Optionally, the remaining balance, including transaction fees, is returned via balance outputs 650a,b,c,d to the same computing device that manages, creates, and submits these transactions to the blockchain. Funding inputs and remaining amounts attributable to said funding inputs act as floating balances and are managed by the funding service.

[0148] The first transaction 660 and the last transaction 662 also include stream metadata 664, 666. The first stream metadata includes values ​​related to maintaining the chain of dust. The metadata 666 of the last transaction 662 includes information to indicate that this transaction is the last in the chain. Preferably, the metadata 666 of the last transaction also includes the transaction id 648c of the first transaction 660.

[0149] Both data append transactions 640a and 640b comprise payloads 642a, 642b, respectively. In some embodiments of the present aspect, the payload 642b of the n+1 transaction 640b comprises a reference to the payload 642a of the preceding n transaction 642a.

[0150] The current state of the stream As discussed above with reference to Figure 6A, the current state of the stream and / or data indicative of the current state of the stream is stored at the output of the append transaction. Preferably, the current state of the stream is represented using the latest event in the event stream. In one embodiment, the data indicative of the latest event is in the form of the following payload: This is provided as an illustrative example, and several embodiments with modifications are discussed below. Payload n =[preimage n ][streamDigest n ][...] Here, lowercase n is used to represent the current transaction and n-1 is the previous transaction. Preferably, the payload is stored in the script at the output of the transaction in the following format: OP_FALSE OP_RETURN OP_PUSHDATA1 <preimage> 0x20 <streamdigest>[0x20 <data digest> | OP_PUSHDATAN <data>]

[0151] The pre-image comprises metadata of the current transaction, event, or event stream state, and the previous transaction, event, or event stream state. For illustrative purposes, the state of the event stream is used below. Those skilled in the art will appreciate that a preceding transaction, a previously received event, or a previous state of the event stream may also be used, and optionally all of them may be the same.

[0152] "Previous state of the stream" or "previous state of the stream" is used, which refers to the event stream state as recorded in an off-chain dataset. Optionally, this may also be the same as the on-chain dataset, in case all events / updates to the stream state are recorded on-chain.

[0153] The preimage optionally comprises any one or more of the following fields: txidcreate: a reference to the first transaction in the chain, preferably the transaction id of the first transaction in the chain, index: the index of the data or event, whenRecorded: the time associated with the creation of the transaction and / or data item, DataDigest n a hash of the event data as stored off-chain (and optionally stored in the transaction in the event data representation of the payload ([...])), and ·streamDigest n-1 : a hash of a pre-image of the previous state of the event stream (also written as the stream digest, or stream digest reference, of the previous state of the event stream) or the seed of the first transaction (if the transaction is the second in a chain because the first transaction does not have a streamDigest).

[0154] The stream digest is a hash of the preimage.

[0155] Optionally, the streamDigest is also salted. A unique value, the salt, may be randomly generated for each transaction associated with the event stream. The salt is optionally stored off-chain. Salting the data has the advantage that it does not reveal anything and prevents brute force preimage attacks such as brainwallet attacks.

[0156] Further example features and uses of salted hashes are discussed throughout the specification of UK Patent Application No. 2102217.3, filed on February 17, 2021 in the name of nChain Holdings Limited.

[0157] The event data representation section ([...]) of the payload optionally contains data items to be stored in the blockchain. The data itself to be stored on the blockchain, hashing of data, A subsection of the data to be stored on the blockchain, or · Empty and / or empty It may be one of the following.

[0158] In particular, a preimage comprises both a hash of the event data (a dataDigest) and a streamDigest of the preceding state of the event stream. Thus, a chain of hashes is constructed such that if data from preceding events in the event stream (not just the previous event, but any preceding events including transaction creation) is tampered with in any way, a different preimage results, and therefore a different streamDigest. Because a different streamDigest causes the next event item to also have a different preimage, and therefore a different streamDigest, cascading changes in all of the following streamDigests result from any modification of an earlier event item. Thus, the back-referencing of streamDigests in the preimages provides a mechanism for identifying if someone has tampered with a preceding event item, since the streamDigests need to be recomputed and updated.

[0159] Combining this feature with the fact that transactions on the blockchain are immutable once confirmed, it is possible to determine if any event items have been modified since the transaction was confirmed. A further advantage of the mechanism is that the complete event is not required, only the streamDigest of the event. Furthermore, the entire data set is not required to detect tampering of a previous event. Simply taking the streamDigest of every event stored on the blockchain and comparing it to an off-chain database is sufficient to determine if any event has been modified before the transaction with the streamDigest was confirmed on the blockchain. Validation is further explained under the heading "Event Stream Blockchain Validation".

[0160] The type of data stored in the event data representation section of the payload depends on the configuration of the event stream. The message creation comprises the method and data storage type the client wishes to select. There are three different methods the client can choose from: onFinalise, checkpoint, and onEvent. These different methods regulate how frequently data is put onto the blockchain and are discussed further under the heading "Trigger Conditions".

[0161] At least for the onEvent method, three different data storage types are possible: attest, notarise, and publicise. attest provides a minimal amount of data so that the event can be found and / or verified with data stored in the database or by the client. Preferably, attest stores only the streamDigest. The notarise data storage type does not store any data, but stores both the dataDigest (i.e., hash or salted hash) and the streamDigest. In some embodiments, a preimage may also be present. The publicise data storage type stores the event data itself, and if the data is large, stores it across two or more transactions. The checkpoint method does not store data in the blockchain. Preferably, the checkpoint method stores the streamDigest. In some embodiments, a preimage is also present. Alternatively, the checkpoint method also uses three different data types. The table below gives an overview of the above:

[0162] [Table 1]

[0163] Trigger Condition As mentioned above, the three different methods vary how frequently data is put onto the blockchain: At least two datasets are created: an off-chain dataset that comprises all of the events (and event data) in the event stream, and an on-chain dataset or at least a subset of the off-chain dataset that comprises data representing the subset.

[0164] The onFinalise method does not put any transactions on the blockchain except for transaction creation and transaction completion. Therefore, the trigger condition for the onFinalise method is the receipt of a message to end the stream. Therefore, the on-chain dataset only comprises two items:

[0165] In situations where events in the event stream should not be made public (such as in a voting system that spans only a short time period), the onFinalise method may be used. The onFinalise method does not store any event-related data in the blockchain other than the transaction creation and transaction completion. Upon termination, the final transaction may include metadata or statistics about votes (such as totals). The final streamDigest at transaction completion can be used to verify that the entire chain has not been tampered with, as discussed above.

[0166] In the onEvent method, every event that is added to the off-chain database also has data that represents it on the blockchain. The type of data stored on the blockchain depends on the data storage type as discussed above. In onEvent, the triggering condition is the receipt of an event. Thus, every time an event is received or created, or whenever the event stream is updated, it triggers the platform processor to add the event to the blockchain. The platform processor looks at the data type (attest, notarise, and publicise) and generates the appropriate data to add to the blockchain. The on-chain dataset for this onEvent embodiment comprises every item that is also present in the off-chain dataset. However, the same data may not exist. For example, if the attest data type is used, the actual event data does not exist on-chain, only the streamDigest of each event.

[0167] The onEvent method may be used when the existence of an event occurrence and / or the actual content of the event is of public importance. An exemplary use of this method is the honest tender process. In this exemplary case, it is in the public interest to know if a bid was made and by whom. The presence of the event in the public blockchain serves this purpose. Optionally, depending on the data type to be stored, the content of the event may also be present, thus making the bid event more public. If the bid needs to be kept secret, notarise and / or attest data types may be used to hide the content of the event.

[0168] In the checkpoint method, two exemplary embodiments of trigger conditions are provided: the first is based on time (as briefly discussed in the example of FIG. 6B), and the second is based on the number of events received (not different from the onEvent method, except that it is every nth event instead of every event). The on-chain dataset in this embodiment comprises at least some (or optionally all) of the items in the off-chain dataset. However, the same data may not exist. For example, the data storage type of the checkpoint method does not comprise the actual event data, but includes a streamDigest of each event. In some cases, a preimage may be included.

[0169] Not storing the data, or even a representation of the data, reduces the size of the transactions put on the blockchain. Since transaction fees are typically calculated based on the size of the transaction, this saves the platform processor and / or client money, while also providing the benefit of the event stream being at least partially represented on an immutable blockchain, as described throughout this specification. Similarly, putting only a portion of the events on the blockchain provides the same benefit of reducing the overall transaction, the overall data stored on the blockchain, and saving money for all parties involved.

[0170] In addition to the above, reducing the size of transactions and putting data into the blockchain less frequently, for example at checkpoints or onFinalise, results in a reduction in the associated carbon footprint of said transactions. Larger transaction sizes require more processing. This energy saving is particularly important when proof-of-work consensus mechanisms are used (such as Bitcoin and its derivatives), as said consensus mechanisms are computationally intensive and therefore energy intensive processes that can result in a large carbon footprint.

[0171] In the case where an event triggers whenever a transaction is put on the blockchain, using the onEvent method (and / or when the checkpoint method is configured with a threshold of 0 or 1, which causes the same or similar data to be put on the blockchain as the onEvent method) can result in an infinite loop. When the first transaction is put on the blockchain (regardless of what triggers it), the onEvent mechanism causes more transactions to be put on the blockchain, which causes yet another event to be put on the blockchain, and so on ad infinitum, resulting in an infinite loop. This problem can be avoided by using a trigger mechanism as described below. By using either of the trigger mechanisms described below, this problem is avoided entirely.

[0172] Further advantages of all of the methods (onEvent, checkpoint, and onFinalise) are revealed with respect to validation as described below under the heading "Event Stream Blockchain Validation."

[0173] A time-based trigger condition is a condition where the blockchain event stream is updated at a given time interval. The time interval is set by the client and is a parameter in the message creation. Preferably, the time interval is a constant and does not change throughout the life of the event stream.

[0174] Time-based trigger conditions are optionally implemented using language-level timers, e.g., Timer and TimerTask in Java. Continuing with the Java example, a message creation is received with an indication that a timer-based trigger condition should be used and that there is also a specific time to wait between event submissions to the blockchain (e.g., every minute). A Timer is established to trigger at a period according to the specific time to wait between event submissions. A TimerTask is also established to obtain the current event stream state and cause the current event stream state to be published to the blockchain. Each time the Timer triggers, the TimerTask is executed. An example pseudo-Java code may be as follows: final long period = 1000L * 60L; / / 1 minute from message creation public void updateBlockchain_timerBasedTrigger() { TimerTask repeatedTask = new TimerTask() { public void run() { / / Get data indicating the state of the stream / / Create a transaction with the above data / / Broadcast the transaction to the blockchain }; } Timer timer = new Timer("Event Stream Update"); timer.scheduleAtFixedRate(repeatedTask, new Date(), period); }

[0175] Alternatively, an operating system level scheduler such as cron is used. An example crontab to set it to run every 5 minutes might look like this: * / 5 * * * * / usr / bin / java MyClass.TimerTask()

[0176] Those skilled in the art will appreciate that there are further ways to establish timer-based execution beyond the two examples provided herein, which are merely provided as examples for those skilled in the art to understand possible ways to implement timer-based triggering.

[0177] Instead of or in addition to the timer-based trigger condition above, a trigger condition based on the number of events received is used. A given number of events is set in the message creation (e.g., 10). This given number is considered to be the threshold number of events for triggering an update to the blockchain. Each time an event is received, the total number of events received since the previous on-chain stream update (or since the message creation was received if an on-chain stream update has not yet occurred) is compared to the threshold number of events. Based on the comparison, the on-chain dataset is updated. This comparison is preferably based on whether the number of events received is equal to or greater than the threshold number of events. An exemplary pseudo-Java code may be as follows (where numberOfEventsBasedTrigger is called each time an event is received or the event stream is otherwise updated): final int thresholdEventReceived = 10; / / From message creation static int numberEventsReceived = 0; public void numberOfEventsBasedTrigger() { Task repeatedTask = new Task() { public void run() { / / Get data indicating the state of the stream / / Create a transaction with the above data / / Broadcast the transaction to the blockchain }; }; numberEventsReceived += 1; if (numberEventsReceived >= thresholdEventReceived) { repeatedTask.run(); numberEventsReceived = 0; } }

[0178] Preferably, only one trigger condition is possible (based on a timer or based on a number of events), alternatively, both trigger conditions can be used, so that the on-chain data set is updated every time any of the trigger conditions are met.

[0179] The step of "obtaining data indicative of the state of the stream" in the above example is preferably to obtain the latest events and extract or generate a streamDigest, and in some embodiments also a preimage of the latest event stream. The steps of "generating a transaction comprising said data" and "broadcasting the transaction" preferably comprise the platform service sending a message to a message bus for the transaction to be put on the blockchain, asynchronously and in a different thread, process, or device, from the above method. These steps are substantially the same as or similar to the steps of the method as described with reference to FIG. 6A and are provided as an example of said method.

[0180] Optionally, if the checkpoint method also has data formatting options (attest, notarise, and publicise), the data is formatted according to the appropriate scheme.

[0181] Updating off-chain datasets with on-chain metadata Once a transaction is broadcast on the blockchain and / or confirmed on the blockchain, an off-chain database is optionally updated with the transaction's metadata, so that users with verified access to the database can more easily find the dataset as represented on the blockchain, which can be useful for validation purposes.

[0182] Optionally, the metadata is used to verify the existence of the transaction in a block on the blockchain. Optionally, the metadata is used to construct a proof that the transaction is included in the blockchain.

[0183] The transaction metadata may be any one or more of the following: the transaction id of the add transaction, a subset of the inputs to the add transaction, the block header in which the add transaction is stored, the block id in which the add transaction is stored, a timestamp associated with the add transaction, and an array of sibling hashes for the transaction id of the add transaction.

[0184] Preferably, the proof of containment is a Merkle tree proof. A Merkle tree proof is a known authenticated data structure organized as a tree. A hash of each data block is stored at the node on the base layer or leaf, and at every interior node of the tree or branch, containing a cryptographic hash calculated from the hashes of its two child nodes. The top node of the tree and the Merkle root uniquely identify from which data set the tree was built. Thus, Merkle trees enable efficient proofs of containment, where a miner or prover node indicates to a submitter or verifier node that a data block is part of an authenticated data set by sending the submitter or verifier node a proof along with an audit path. The audit path contains the node hashes necessary to recalculate the Merkle root without requiring the submitter to reveal the entire data set. In Bitcoin SV, transactions contained in a block are stored in a Merkle tree.

[0185] Preferably, the transaction metadata comprises a transaction identifier (TxID) of the append transaction, a block header of the block in which the blockchain transaction is included, and an array of sibling hashes for the transaction identifier (TxID). The array of sibling hashes is included in the proof as it is used to construct the audit path. The hashes are called Merkle Proofs of Containment.

[0186] Preferably, the block headers are sourced independently from the proof of inclusion (i.e., using the blockhash that is part of the proof of inclusion). The headers are available independently from the blockchain itself, or by using the Headers Client described in UK Patent Application No. 2106950.5, filed May 14, 2021.

[0187] Auditors should ensure that the headers shown are in fact part of the longest chain.

[0188] Further exemplary features and uses of the proof of content are discussed throughout the specification of UK Patent Application No. 2102217.3, filed on February 17, 2021 in the name of nChain Holdings Limited.

[0189] Checkpoint Now When the checkpoint or onFinalise methods are used, the optional checkpointNow flag is optionally used. The checkpointNow flag may be optionally set when a new event is received for storage to the off-chain dataset (and possibly to the on-chain dataset if appropriate trigger conditions are met). If the flag is set, it causes data associated with the received event to be stored in the on-chain dataset regardless of whether the trigger conditions are met. Since check overrides the checkpointing method to cause data to be added to the on-chain dataset, it may be considered an override flag.

[0190] Thus, when an event is received to be added to the event stream, if the flag is set, the event data, or data based on the event data, is added to the on-chain dataset.

[0191] The type of data that should be included in the on-chain dataset depends on the data format options (attest, notarise, and publicise).

[0192] Advantageously, this gives clients putting data into the event stream more freedom to allow or request that important data or events be committed to an on-chain dataset for auditing. Important events may include passing a particular milestone for the event stream, such that the data being stored results in reaching a particular state in an associated finite state machine or smart contract.

[0193] Another advantageous use this technical feature may enable is to allow a stream to be resolved at a specific critical time that the checkpoint method may not capture. For example, if the checkpoint method is used to add data to the on-chain dataset during the day every day, but the client wants the current event to be recorded at midnight on the last day of the fiscal year (for accounting reporting purposes), the client simply adds a checkpointNow flag to the last event issued before midnight, which will be added to the on-chain dataset for inspection by auditors, regardless of any previous checkpoint trigger conditions that may have been set.

[0194] Event Stream Blockchain Validation A second aspect of the present disclosure generally relates to a computer-implemented method of validating on-chain and off-chain data sets as part of a platform providing a number of blockchain related services, the platform being provided for a number of clients and implemented by at least one platform processor associated with an application programming interface (API).

[0195] A computer-implemented method for validating a blockchain-stored representation of a dataset comprises obtaining a reference to an on-chain dataset, the on-chain dataset comprising data stored on the blockchain and carrying transactions, each data carrying a transaction comprising data indicative of an event stored in an off-chain dataset; examining the on-chain dataset; determining, for each data carrying a transaction in the on-chain dataset, that data indicative of an event in the off-chain dataset is associated with an event in the off-chain dataset; and verifying that the on-chain dataset and the off-chain dataset correspond to each other.

[0196] Preferably, the blockchain is a public blockchain. Advantageously, a public blockchain and / or a blockchain with the ability to allow third parties to read the blockchain allows any interested party, whether they originated the data, stored the data, or are a complete third party, to audit the on-chain and off-chain data sets to ensure that they correspond to each other. In particular, the method of the present invention provides a way for third parties to verify data in a trustless manner. The immutability of the blockchain itself provides a way to store data indicative of events such that it is nearly impossible to alter the event-related data after submission to the blockchain.

[0197] In some embodiments, a data item in the off-chain dataset comprises at least a preimage and a digest of the preimage. Preferably, the data indicative of data in the off-chain dataset comprises a digest of a preimage of the data item in the off-chain dataset. More preferably, determining that the data indicative of a data item in the off-chain dataset is associated with a data item in the off-chain dataset comprises finding the data item in the off-chain dataset with the same digest of the preimage of the on-chain data item.

[0198] Preferably, the pre-image comprises associated event metadata associated with each data item.

[0199] Advantageously, the digest of the preimage serves as a proof of existence for the off-chain data. Using only the digest of the preimage (referred to as streamDigest throughout the description), an interested third party can attempt to find corresponding events whose preimages hash to said digest. Since the digest used here is a one-way digest, it is computationally prohibitively difficult for a malicious client or memory provider to find and substitute "bad" event data with the same digest as the intended "good" event data. If such an event with a matching digest can be found, the auditor can be confident about the validity of the absence of tampering. The immutability of the blockchain further enhances this security, as it constrains the ability of malicious blockchain miners to tamper with historical data.

[0200] An additional advantage can be found in being able to verify the entirety of the event data using only a digest, which is much smaller in size compared to the event data itself, which conserves data and processing power on the blockchain, thus reducing the carbon footprint of any associated blockchain devices or processes that operate on or store event-related transactions.

[0201] In some embodiments the data indicative of the data item in the off-chain dataset additionally comprises an inverse image of the data item in the off-chain dataset. Preferably, the step of determining that the data indicative of the data item in the off-chain dataset is associated with the data item in the off-chain dataset comprises finding a data item in the off-chain dataset that has the same inverse image as the on-chain data item.

[0202] In some embodiments the data indicative of the data item in the off-chain dataset further comprises a hash of the event. Preferably, determining that the data indicative of the data item in the off-chain dataset is associated with the data item in the off-chain dataset comprises finding a data item in the off-chain dataset that has the same hash of the event.

[0203] Advantageously, the presence of pre-images of events and / or hashes of the events themselves allows for finer-grained verification of on-chain and off-chain data sets: while the pre-image digests can confirm whether data has been tampered with, by using the pre-images and / or hashes of the events, a verifier can verify which parts of the on-chain events have been tampered with.

[0204] In some embodiments the data indicative of the data item in the off-chain dataset further comprises an event and / or a subsection of an event. Preferably, determining that the data indicative of the data item in the off-chain dataset is associated with a data item in the off-chain dataset comprises finding data items in the off-chain dataset that have the same event and / or subsection of an event.

[0205] Advantageously, the event data itself allows a verifier to verify any smart contracts, finite state machines, or other processes that use said event data. Not only can the verifier verify that the data is valid, but it can also use the data in a similar or identical way that the client that wrote the data wants to use it. The same advantages as above for finer-grained verification also apply.

[0206] In some embodiments, the pre-image comprises a digest of the pre-image of a preceding data item in the off-chain dataset.

[0207] Advantageously, this chained storage of hashes provides an additional strength against malicious actors attempting to modify past data: with each pre-image depending on a preceding event, modification of a past event propagates to modifications of the pre-images of any and all subsequent events stored. This propagation manifests itself as a change in digests throughout the entire chain, from the point at which the event was changed onwards.

[0208] In some embodiments, each transaction in the on-chain dataset comprises a reference to a further transaction, thus forming a chain of transactions. Preferably, investigating the on-chain dataset comprises obtaining a given transaction in the on-chain dataset and obtaining the further transaction based on a first reference in the given transaction or based on a second reference in the further transaction. Optionally, the reference to the on-chain dataset is a reference to a first or last transaction in the chain of transactions. Optionally, the reference to the on-chain dataset comprises a transaction id of the first or last transaction in the chain of transactions. Optionally, the reference to the on-chain dataset comprises a block id of the first transaction.

[0209] Advantageously, the existence of each transaction reference in a chain-like manner to one another enforces a spending order on the transactions. This ordering can be used for validation purposes, for example, to ensure that on-chain events are in the same order as off-chain events. A further advantage is the inspectability of the chain of transactions: these transactions can be inspected using only the transaction information (i.e., the spending output points) without any further indexing information or other additional information.

[0210] In some embodiments the method comprises obtaining a data item in the off-chain dataset, hi some embodiments each data item of the off-chain dataset is obtained by accessing a database and / or by accessing data storage that substantially mirrors the database.

[0211] Advantageously, by having access to data storage that substantially mirrors the database, auditors do not need to overload a database that may currently be in use with data access calls to verify historical data.

[0212] Also according to a second aspect, a device comprises a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method as described above.

[0213] Also according to a second aspect, the system comprises a device as described above configured to audit the on-chain and off-chain datasets, and a third party device configured to receive results of the audit.

[0214] Referring to Figure 8, a system 800 according to a second aspect is shown with components the same or similar to those described with reference to Figure 5. Where important, the same reference numbers are used in Figures 5 to 8 to indicate that the same or similar devices or communication channels are used. The client device 502 is in communication with the platform processor 504 (510), in communication with the blockchain network 101 (802), and in communication with the client database 804 (806). The platform processor 504 is in communication with the blockchain network 101 (514), and in communication with the platform database 506 (514).

[0215] The client 502 is in communication 802 with the blockchain network 101 so that it can download and / or ask nodes in the network about blocks and / or transactions in the blockchain. Optionally, the client 502 stores a local copy of the blockchain. While the client 502 is in communication with the blockchain network 101, for the purposes of this embodiment, the client 502 is not configured to emit data for inclusion in the blockchain.

[0216] The client 502 is optionally in communication 806 with a client database (or data store) 804 to store data submitted to the platform processor 504. In this case, the event dataset is stored in at least two places: the client database 804 and the platform services database 506. Furthermore, the blockchain also stores an on-chain representation of the event dataset, which is optionally a full replica of the database. Optionally, the dataset is not stored in its entirety by the client 504 in the client database 804, and each event in the off-chain dataset is retrieved via the platform processor 504.

[0217] Referring to FIG. 9, a method 900 for validating an event dataset is shown. This method may also be considered as a method for auditing an event dataset. The dataset is a set of events, and the source of each event is the client that creates it and / or any party delegated authority by the client. Although the validation is presented as being done by the client, those skilled in the art will understand that the method can be done by any party, including the client, the platform processor, and other third parties, as long as they have read access to both the blockchain (which is usually public, but not always) and the off-chain dataset. The third parties have access to the dataset provided by the client via delegated read access to the platform processor's database (via the platform processor's API) and / or from their own storage of the dataset. The third parties are optionally auditors.

[0218] In a first step 902, the client obtains a reference to an on-chain dataset that it wishes to validate with an off-chain dataset. The on-chain dataset is preferably stored as a chain of transactions, such that each transaction comprises a reference to adjacent transactions. Preferably, the reference to the on-chain dataset is the transaction id of one of the transactions in the chain of transactions. More preferably, the reference to the on-chain dataset is a reference to the first or last transaction in the chain of transactions. Preferably, the chain of transactions is as described with reference to Figures 7A, 7B and 7C above.

[0219] Alternatively, the reference to the on-chain dataset is a reference to a list of transaction references.

[0220] Once a reference to the on-chain dataset has been obtained, transactions that are part of the on-chain dataset are examined (904) or otherwise obtained. The method of examination depends on the structure in which the transactions are stored. Further details are provided below under the heading "Examining the On-Chain Dataset."

[0221] Each data carrying a transaction in the on-chain dataset comprises data indicative of an event to be stored in the off-chain database. A preferred method of how these on-chain representations are stored in the blockchain is described above under the heading "Blockchain Storage of Event Streams", and each data carrying a transaction is an append transaction as described above with reference to FIG. 7B. In this example, a subset of all events is represented in the on-chain dataset. As described above, the append transaction may comprise different types of data indicative of an event in the off-chain dataset, such as any one or more of a hash of a preimage, a preimage, a hash of event data, and event data. The different data types and structures are described in more detail under the heading "Data Indicative of Events Stored in an Off-Chain Dataset".

[0222] For each data carrying a transaction in the on-chain dataset, a determination is made that the data present in the on-chain transaction is associated with an event in the off-chain dataset. This step may be considered as a validation step, since it amounts to verifying whether the transaction and / or the data contained within the transaction legitimately represents an event in the off-chain dataset. The validation / association step comprises confirming that an event corresponding to the data present in the on-chain transaction is present in the off-chain dataset and that it is legitimate for said off-chain event. Validation optionally includes comparing data, comparing timestamps, and / or comparing any other available metadata.

[0223] In particular, the method is only verifying that all of the on-chain stored events are valid, since not all off-chain events are always represented in on-chain transactions. For example, when the checkpoint method is used as described above, trigger conditions are optionally set such that not all of the events are represented in the on-chain dataset.

[0224] Based on at least these on-chain dataset validations, a determination as to whether the entire on-chain dataset represents the off-chain dataset. This may also be described as validating that the on-chain dataset and the off-chain dataset correspond to each other. Preferably, in some embodiments, for an on-chain dataset to legitimately represent an off-chain dataset, all of the on-chain data carrying transactions have associated events in the off-chain dataset that are legitimately represented by on-chain transactions.

[0225] Preferably, in other embodiments, i.e. time-based (triggered) checkpoints, an on-chain transaction may not have a direct off-chain event. In this case, the on-chain transaction may be associated with the last written event. However, if no new events are added between successive time periods, the on-chain streamDigest is not changed. This implies that there is no activity during that period. Because the streamDigest encompasses every bit of the stream, whenever a StreamDigest is written on-chain, it protects the integrity of all data written before that time.

[0226] Validating the on-chain and off-chain datasets 906 may also comprise comparing metadata stored in the on-chain dataset with the off-chain dataset. Preferably, the metadata of the on-chain dataset is stored in the first and / or last transaction in the on-chain dataset. For example, the completion times may be compared between the two datasets to ensure they are the same or reasonably close. The total number of events may be stored in the last transaction, which may be compared to the total number in the off-chain dataset.

[0227] Any interested party can use the methods and systems described herein to ascertain any one or more of the following, depending on various use cases and data types: Does the data set contain only the elements that should be included? · Does the data set contain all the elements that should be included? · Is the data for each element recorded faithfully? · Is the sequence of events faithfully recorded? · Are the times of each event recorded faithfully?

[0228] Preferably, the validation step 906 comprises validating any one or more of the following for both the on-chain and / or off-chain data sets: The dataset contains only elements that should be included, The dataset contains all elements that should be included, The data from each data set is recorded correctly relative to each other, The events in the dataset are in the correct order, and The time for each event in the dataset is correct.

[0229] Preferably, the off-chain dataset comprises all of the events and the on-chain dataset comprises a subset of the events.

[0230] Preferably, the verifying step comprises the steps of examining the off-chain dataset and verifying that all events that should be recorded in the on-chain dataset are recorded therein.

[0231] In some embodiments, the interrogation of the on-chain dataset may occur in response to finding an off-chain event that should have a corresponding on-chain event. That is, when iterating over the off-chain dataset to verify that there is a value that should be included on-chain, this triggers said interrogation of the on-chain dataset to find said event. This interrogation may be incremental, such that order as well as any other validation steps (such as data integrity or time) are additionally checked, or may start from the beginning of the on-chain dataset to check for each event present in the on-chain dataset.

[0232] In other embodiments, for on-chain exploration, it may be preferable for the blockchain to be fully indexed in advance and for transactions in the stream to be fetched one by one.

[0233] In embodiments, if the preimage is not written on-chain, as may be the case for some embodiments of the checkpoint method and (salted) notarization, i.e., notarise, there may be insufficient on-chain data to perform computations that prove that the expected data has been properly accounted for. This means that an auditor or verifier may have to obtain the missing information from the platform, i.e., the metadata that comprises the preimage. n stream seed, streamDigest n , whenRecorded n , event index n, delegatedWriter index, salt n , and optionally event data n Preferably, the auditor entity does not need to read any of the blockchain transactions.

[0234] Advantageously, in some embodiments, the platform may provide the complete transaction data, a Merkle Proof of Containment (array of hashes), and a blockhash of the header of the block that contains the complete transaction data. The complete transaction data always includes at least a streamDigest in one of its outputs.

[0235] In this case, the audit or verification process may comprise the following steps. A. Fetch the off-chain record of every event from scratch. Recording is event metadata n plus a copy of the on-chain transaction (txn n ), the output index used for OP_RETURN (out i ), and Merkle Inclusion Certificate (P n ) (if any). B. Prepare the original data to be sent to the EventStream for use in constructing a preimage. H n :=sha256(data n |salt) CH n and use the information returned by the platform to preimage n (Metadata element whenRecorded n , delegated writer index, event index n) and streamDigest n-1 from the previous preimage computation. For preimage0, streamDigest n-1 is replaced by the "seed" value (also returned in the metadata). ·streamDigest n Calculate. Calculated streamDigest n metadata n Compare the resulting streamDigest to the one provided in If they are the same, this is the streamDigest n The data that caused the creation of n and can be taken as proof that the entire stream from index 0 to n-1 is unchanged. DP n If it contains, streamDigest n We then proceed to validate that the token is recorded on-chain. ·txn n Out i The data carrier output held in the streamDigest e ) to extract the The format is op_false op_return 0x20 <streamDigest e >It is. Calculated streamDigest n The extracted streamDigest e Compare with. If they are the same, this is the streamDigest n TXN n This may be taken as evidence that the E. Calculate the Merkle root. H D :=sha256(sha256(data n )) to calculate Merkle root R n :=merkle(H D ,P n Calculate the number of nodes. F. Get the block header. metadata n Send the .blockhash to the Headers Client to generate the actual header H B Get the. metadata n .blockhash is a SHA256(H B ) or sha256(sha256(H B In other words, blockhash can use any hash function, sha256 or sha256(sha256(header)) are examples. G.H. B (merkleRoot) to R n Compare with. If they are the same, it is txn n is part of a block whose hash matches blockhash. Therefore, this is data n was provably added to the EventStream at the specified index and time.

[0236] Preferably, when the verification step comprises verifying that the on-chain dataset comprises all of the events that it should contain, the method comprises finding the off-chain events with on-chain metadata and verifying for each event that the metadata correctly corresponds to the on-chain transaction that represents the event. Preferably, the metadata comprises a proof of inclusion in the blockchain. More preferably, the verification step comprises verifying that the proof is correct. In some examples, as mentioned above (see step of audit process), in fact the user obtains a certificate from the platform processor, which certificate includes their transactions, transaction IDs, corresponding block IDs, Merkle roots and the inclusion proof. If this information is stored off-chain, it will be possible to independently verify it by checking whether the Tx ID and the Merkle inclusion proof provided the same Merkle root as the Merkle root of the block in which the transaction is said to be.

[0237] Preferably, the metadata and / or proof of inclusion are as described with reference to the discussion under the heading "Updating Off-Chain Datasets with On-Chain Metadata."

[0238] This method 900 is optionally used to validate event streams off-chain and on-chain, such as those created by method 500 described above.

[0239] When verifying that data indicative of events stored on-chain are stored off-chain, the verification device also retrieves the off-chain dataset. The verifier (client 502, platform processor 504, or third-party auditor) retrieves each item in the off-chain dataset one by one, or retrieves the dataset as a whole. Typically, the client 502 has read access to the off-chain dataset to which it has previously written. Optionally, before or during the verification process, the client retrieves the entire off-chain dataset so that the verification step can be performed such that multiple requests to the platform processor 504 are not necessary, thus saving time and bandwidth. Alternatively, for each on-chain transaction that the verifier wants to verify, a request is made to the platform processor 504 for events stored off-chain related to the current on-chain transaction.

[0240] Additionally or alternatively to the above, if the client 502 was the one writing to the platform processor 504 (and / or the data was visible to the client 502 because it was being sent to the platform processor 504), then the client 502 stores the data as it was written, and the client 504 maintains its own version of the database in its database 804. In this way, no additional messages need to be sent to the platform processor 504. If the client 502 wants a third party to verify the data, it can provide its own stored version (if it has one) or delegate read access to the third party.

[0241] Finally, the verifier optionally transmits a decision made regarding whether the on-chain dataset legitimately represents the off-chain dataset, which decision is transmitted to the party that requested the validation and / or any other interested parties.

[0242] Exploring on-chain datasets In the investigation step 904 discussed above in the verification method 900, the on-chain dataset is investigated. The investigation method depends on the type and format in which the on-chain dataset is stored. In the following, some exemplary embodiments for various on-chain formats and possible methods of investigating them are provided. Those skilled in the art will understand that investigation methods for various data structures may be possible.

[0243] As discussed above, on-chain transactions are preferably in a chain such that each transaction comprises references to adjacent transactions, and more preferably, the references can be followed in either direction. That is, if transaction A comprises a reference to transaction B, in addition to following the reference from transaction A to transaction B, the reference can be followed (backwards) from transaction B to transaction A. Even more preferably, the transactions form a chain of dust as described above under the heading "Chain of Dust". Each transaction in this chain of dust (except the first) comprises a back reference in the form of consuming the output point of the previous transaction.

[0244] To walk forward through the chain, the output points of the "dust outputs" 644a,b,c are taken and the transaction that consumes that output becomes the next transaction to operate on. This step is repeated until the end of the chain is reached.

[0245] To look backwards up the chain, the output point stored in the "dust inputs" 646a,b,d is taken. The transaction id in that output point is the transaction id of the previous transaction in the chain. The transaction with that id is found. These steps are repeated until the beginning of the chain is reached.

[0246] Thus, if the on-chain dataset is in the form of a chain of transactions, exploring the on-chain dataset comprises following the references that each transaction comprises until all of the on-chain transactions have been explored. As shown above, from any transaction in the chain, it is possible to explore forwards or backwards by following the references. Thus, it is possible to explore the entire chain from any starting point. If the references to the on-chain dataset are transactions in the middle of the chain, to explore the entire set, the verifier explores in one direction until it reaches the first or last transaction, and then explores again in the other direction from the same transaction in the middle of the chain.

[0247] Alternatively, when the reference to the on-chain dataset is a reference to a list of transactions relating to an event stored off-chain, preferably the transaction reference is the transaction id, and more preferably the block id and transaction id, of each transaction on the on-chain dataset.

[0248] Using only the transaction id, a transaction can be found by iterating through all of the transactions in the blockchain (or using a blockchain service that has already indexed all the transactions). Using the block id, a client only needs to find the appropriate block, and then iterate only through the transactions in that block, rather than the entire history of transactions. Thus, investigating the on-chain dataset comprises looking up each transaction via its transaction id.

[0249] Further exemplary features of Dust chains, and how to investigate them, are discussed throughout the specification of UK Patent Application No. 2102314.8, filed on February 18, 2021 in the name of nChain Holdings Limited. These Dust chain features include "change-out and change-in transactions" that carry no data, and "rendezvous transactions" that carry data (as well as data on other event streams). Methods for investigating these types of transactions are also disclosed in the specification.

[0250] Data representing the event stored in an off-chain dataset As discussed above, a transaction in the on-chain dataset comprises data indicative of an event in the off-chain dataset such that it can uniquely identify the event and preferably provides information that allows for verification that the data and / or metadata associated with the event has not been modified since being submitted to the platform processor 504 or the blockchain. In particular, once a transaction comprising data indicative of an event is confirmed on the blockchain, the data is considered immutable due to the immutable nature of blockchain transactions.

[0251] Preferably, the data indicative of the event in the off-chain dataset is in the form of one of the embodiments as described above under the heading "Current State of the Stream." Thus, the data indicative of the event may be any one or more of the following types. In some embodiments, this may include all possible combinations of one or more of: preimage, StreamDigest, H(data), and data. · [streamDigest n ] · [streamDigest n ][H(data n )] · [streamDigest n ][data n ] · [preimage n ][streamDigest n ] · [preimage n ][streamDigest n ][H(data n )] · [preimage n ][streamDigest n ][data n ] · [preimage n ][streamDigest n ][split(data n ), 1 of 2] · [preimage n ][streamDigest n ][split(data n ), 2 of 2]

[0252] This may also be described in the following manner: Optionally, the data indicative of the event comprises a streamDigest of the event, where the streamDigest is a hash of a preimage of the event. Optionally, the data indicative of the event further comprises a preimage of the event. Optionally, the data indicative of the event further comprises a hash of data related to the event. Additionally or alternatively, the data indicative of the event comprises the event data. Optionally, if the event data is too large for a single transaction, the event data is split into two or more transactions.

[0253] Preferably, the verifier is configured to identify the format in which the data is stored and use appropriate steps to validate the data with the data present. Exemplary steps taken to validate various data types are described below.

[0254] If the data indicative of an event only comprises a streamDigest, this is still sufficient to uniquely identify the event. In some embodiments, this involves identifying the original data, when it was recorded, and its location in the stream relative to events that came before and after. To find events related to this data indicative of the event, look in the off-chain dataset to find events with the same streamDigest. Preferably, the off-chain dataset stores the streamDigest for each event. Alternatively, the off-chain dataset does not store this information, and a preimage of each event in the event stream is constructed (if it does not already exist) and hashed to determine whether it has the same or a different streamDigest. The streamDigest may be considered a form of "proof of existence" for the event.

[0255] As explained above, the streamDigest is a hash of the preimage, which in turn comprises the hash of the data. Finding an event with the same streamDigest also serves as a verification that the event data has not been modified, since if the data had been modified, the streamDigest would have changed as well. Furthermore, the preimage also comprises the streamDigest of the previous event. Given this chain of hashes, verifying a given transaction and event also verifies that the data of all previous events has not been tampered with.

[0256] These steps can be used for any data type that exists, since all of the data types have at least a streamDigest.

[0257] Finding off-chain events can be easier if the data type comprises a preimage in addition to the streamDigest. The preimage comprises the index of the event in the stream. Thus, instead of finding events with the same streamDigest (a process that may involve building a preimage and hashing it to find the streamDigest for each event in the off-chain dataset), a more time- and computationally efficient method is used to iterate and count each event until the event at the index provided in the preimage is found (notably, no comparisons are necessary, just counting the index). If events are stored in an array and / or indexed database, the event does not need to be iterated over and the verifier can jump directly to its index, since its location in memory is directly computable and / or already known.

[0258] The preimage may include further details to verify that the on-chain data legitimately represents the off-chain event. For example, the whenRecorded member of the preimage is optionally compared to when the event was recorded in the database. These times should be the same or similar enough.

[0259] If the data type comprises a hash of data or the data itself (whether split into two or more transactions), this is also verified by the verifier, so the same data exists on-chain as it is off-chain.

[0260] In an alternative embodiment, the present disclosure relates to verifying that a stream of events is faithfully represented on-chain, without reference to the chain of dust mentioned above. In this case, using the above-described "attest" or "notarise" without a preimage minimizes the transaction size, and therefore the transaction cost (i.e., miner fees). Such a minimal transaction has a single funding input and a single OP_RETURN output. Since the transaction size is known in advance, it is possible to pre-arrange the UTXO funding value as it becomes available, such that a "balance" output is not needed. Such an embodiment may not require synchronization of the construction of each transaction. In cases where the preimage is not on-chain, as in some instances of attest and notarise. Since the preimage metadata can be obtained from an off-chain source, this can be used for verification of the order of events in this alternative embodiment.

[0261] Platform System According to a further aspect, any one or more of the methods and systems of the preceding aspects may be used in conjunction with a platform processor as described below to provide on-chain and off-chain data storage as described in the first aspect and / or validation of on-chain and off-chain data storage in the second aspect. This further aspect may be a Platform as a Service (Paas) and Software as a Service (Saas) offering 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.

[0262] An overview of the Platform Services can be seen in Figure 10, 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.

[0263] 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 that provide enterprise-class capabilities to conduct transactions using digital assets such as Bitcoin SV1506. 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.

[0264] FIG. 11 provides a more coarse 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. 11, the data service 1602 may include a data writing service 1602a and a data reading service 1602b. The event stream and / or the data writer optionally implement the method 600 as described in FIG. 6A. Similarly, clients and / or third parties wishing to access the data archive (such as the verification method 900 as described in FIG. 9) 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 in the name of nChain Holdings Limited on February 19, 2020), which is 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 reading 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 archiving function allows access to logs of previous transactions for a specified event or contract.

[0265] 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.

[0266] 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.

[0267] 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.

[0268] Platform Devices Turning now to FIG. 12, 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 of the systems 500, 800 of FIG. 5 or FIG. 8, or the computing device 2600 may be configured as a client entity associated with a given user, a client entity that makes database requests and / or submissions, a platform processor, and / or a database manager. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 12, 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 dynamic random access memory (DRAM) 2618 and 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.

[0269] 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 .

[0270] 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.

[0271] 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.

[0272] 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.

[0273] 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.

[0274] 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.

[0275] 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. 12 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. 12.

[0276] Example - Device Activity Log A manufacturer of high-end equipment would like to have access to a log of important activity on its customers' equipment. This may be part of a warranty or service delivery agreement. By analyzing the log, the manufacturer may be able to take preventative steps to ensure that the equipment is operating at maximum efficiency. The manufacturer may configure an individual Event Stream for each product family using the checkpoint method. The equipment will automatically log important events from registration onwards for the life of the product. The manufacturer can remotely monitor all activity including heartbeat, operating hours, replacement of critical parts, use of suitable materials, etc.

[0277] Using the checkpoint method, large amounts of data can be stored in an off-chain database for access of individual data points of interest, and an on-chain data set is used as a heartbeat monitor so that the manufacturer can verify that the data is being updated, but is not interested in the data itself.

[0278] 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.

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

[0280] In addition, the modules and components may be implemented as firmware or 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).

[0281] 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.

[0282] 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.

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

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

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

[0286] Enumerated Embodiments The following clauses are provided as examples related to the present disclosure and to aid in a further understanding of the present disclosure.

[0287] 1. A computer-implemented method for verifying a blockchain-stored representation of a dataset, comprising: obtaining a dataset reference to an on-chain dataset, the on-chain dataset comprising data stored on a blockchain and carrying transactions, each data carrying a transaction comprising data indicative of an event stored in an off-chain dataset; examining the on-chain dataset, and for each record in the on-chain dataset that carries a transaction, determining that data indicative of an event in the off-chain dataset is associated with an event in the off-chain dataset; and verifying that the on-chain data set and the off-chain data set correspond to each other.

[0288] 2. The computer-implemented method according to clause 1, wherein the data items in the off-chain dataset comprise at least a preimage and a digest of the preimage.

[0289] 3. The computer-implemented method according to clause 2, wherein the data indicative of data in the off-chain dataset comprises a digest of a preimage of a data item in the off-chain dataset.

[0290] 4. Determining that data indicative of a data item in the off-chain dataset is associated with a data item in the off-chain dataset, 4. The computer-implemented method according to clause 3, comprising finding a data item in the off-chain dataset that has the same digest as a preimage of the on-chain data item.

[0291] 5. The computer-implemented method according to any one or more of clauses 2 to 4, wherein the data indicative of the data items of the off-chain dataset additionally comprises a preimage of the data items of the off-chain dataset.

[0292] 6. Determining that data indicative of a data item in the off-chain dataset is associated with a data item in the off-chain dataset, 6. The computer-implemented method according to clause 5, comprising finding a data item in an off-chain dataset that has the same preimage as the on-chain data item.

[0293] 7. The computer-implemented method according to any one or more of clauses 2 to 6, wherein the data indicative of the data items of the off-chain dataset further comprises a hash of the event.

[0294] 8. The step of determining that data indicative of a data item in the off-chain dataset is associated with a data item in the off-chain dataset, 8. The computer-implemented method according to clause 7, comprising finding a data item in the off-chain dataset that has the same hash of the event.

[0295] 9. The computer-implemented method according to any one or more of clauses 2 to 8, wherein the data indicative of the data items of the off-chain dataset further comprises events and / or subsections of events.

[0296] 10. The step of determining that data indicative of a data item in the off-chain dataset is associated with a data item in the off-chain dataset, 8. The computer-implemented method according to clause 7, comprising finding data items in the off-chain dataset that have the same event and / or subsection of an event.

[0297] 11. The computer-implemented method according to any one or more of clauses 2 to 10, wherein the preimage comprises a digest of a preimage of a preceding data item in the off-chain dataset.

[0298] 12. A computer-implemented method according to any one or more of the preceding clauses, wherein each transaction in the on-chain dataset comprises a transaction reference to a further transaction such that a chain of transactions is formed.

[0299] 13. The step of investigating the on-chain dataset comprises: Obtaining a given transaction in an on-chain dataset; and obtaining the further transaction based on the first transaction reference in the given transaction or based on the second transaction reference in the further transaction.

[0300] 14. The computer-implemented method according to clause 12 or 13, wherein the dataset reference to the on-chain dataset is a reference to the first or last transaction in a chain of transactions.

[0301] 15. A computer-implemented method according to any one or more of clauses 12 to 14, wherein the dataset reference to the on-chain dataset comprises the transaction id of the first or last transaction in the chain of transactions.

[0302] 16. A computer-implemented method according to any one or more of clauses 12 to 15, wherein the dataset reference to the on-chain dataset comprises the block id of the initial transaction.

[0303] 17. A computer-implemented method according to any one or more of the preceding clauses, further comprising obtaining a data item in an off-chain dataset.

[0304] 18. A computer-implemented method according to any one or more of the preceding clauses, wherein each data item of the off-chain dataset is obtained by accessing a database and / or by accessing data storage that substantially mirrors the database.

[0305] 19. A device comprising a processor and a memory, the memory containing executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method according to any one or more of the preceding clauses.

[0306] 20. A device as set forth in clause 19 configured to audit on-chain and off-chain data sets; and a third party device configured to receive results of the audit.

[0307] It should be understood that the above description is intended to be illustrative, not limiting. 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 with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. [Explanation of symbols]

[0308] 100 Systems 101 Packet switching network, blockchain network 102 Computer terminals, computer equipment 103 Users and related parties 104 Blockchain nodes 105 Client Applications 106 Peer-to-Peer (P2P) Networks 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 201 Header 202 Input Field 203 Output Fields 301 Side Channel 351 Transaction Engine 352 User Interface (UI) Layer 360 User Interface (UI), Client Application 362 UI 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 502 Client 504 Platform Processor 506 Database 644 Dust Output 646 Dust Input 648 Funding Entry 650 Remaining balance output 660 First Transaction 662 Last Transaction 664 Stream Metadata 666 Stream Metadata 1500 Platform Processor, Platform Services 1502 Data Services 1504 Calculation Services 1506 Commerce Services 1508 Platform API 1510 Blockchain Node Software 1512 Blockchain Network 1600 Platform 1602 Data Services 1604 Commerce Services 1606 Computational Services 1608 SPV Service 1610 Blockchain 2600 Computing Devices 2602 Processor 2604 Bus Subsystem 2606 Storage Subsystem 2608 Main memory, memory subsystem 2610 File Storage Subsystem, Persistent Storage 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< / data> < / streamdigest> < / preimage>

Claims

1. 1. A computer-implemented method for verifying a representation of a dataset stored on a blockchain, comprising: obtaining a dataset reference to an on-chain dataset, the on-chain dataset comprising data stored on the blockchain and carrying transactions, each data carrying a transaction comprising data indicative of an event stored in an off-chain dataset; examining the on-chain dataset; and for each data carrying a transaction in the on-chain dataset, determining that the data indicative of an event in the off-chain dataset is associated with an event in the off-chain dataset; verifying that the on-chain data set and the off-chain data set correspond to each other; A method comprising:

2. 2. The computer-implemented method of claim 1, wherein data items in the off-chain dataset comprise at least a pre-image and a digest of the pre-image.

3. 3. The computer-implemented method of claim 2, wherein the data indicative of the data of the off-chain dataset comprises a digest of a preimage of a data item in the off-chain dataset.

4. determining that the data indicative of the data item in the off-chain dataset is associated with a data item in the off-chain dataset, 4. The computer-implemented method of claim 3, comprising finding a data item in the off-chain dataset that has the same digest as the preimage of the on-chain data item.

5. 3. The computer-implemented method of claim 2, wherein the data indicative of the data items of the off-chain dataset additionally comprises an inverse image of a data item of the off-chain dataset.

6. determining that the data indicative of the data item in the off-chain dataset is associated with a data item in the off-chain dataset, 6. The computer-implemented method of claim 5, comprising finding a data item in the off-chain dataset that has the same preimage as the on-chain data item.

7. 3. The computer-implemented method of claim 2, wherein the data indicative of the data items of the off-chain dataset further comprises a hash of an event.

8. determining that the data indicative of the data item in the off-chain dataset is associated with a data item in the off-chain dataset, 8. The computer-implemented method of claim 7, comprising finding data items in the off-chain dataset that have the same hash of an event.

9. 3. The computer-implemented method of claim 2, wherein the data indicative of the data items of the off-chain dataset further comprises the events and / or subsections of the events.

10. determining that the data indicative of the data item in the off-chain dataset is associated with a data item in the off-chain dataset, 8. The computer-implemented method of claim 7, comprising finding data items in the off-chain dataset that have the same event and / or subsection of the event.

11. 3. The computer-implemented method of claim 2, wherein the pre-image comprises a digest of the pre-image of a predecessor data item in the off-chain dataset.

12. 2. The computer-implemented method of claim 1, wherein each transaction in the on-chain dataset comprises a transaction reference to further transactions such that a chain of transactions is formed.

13. investigating the on-chain dataset, obtaining a given transaction in the on-chain dataset; obtaining a further transaction based on a first transaction reference in the given transaction or based on a second transaction reference in the further transaction; 13. The computer-implemented method of claim 12, comprising:

14. 13. The computer-implemented method of claim 12, wherein the dataset reference to the on-chain dataset is a reference to a first or last transaction in the chain of transactions.

15. 13. The computer-implemented method of claim 12, wherein the dataset reference to the on-chain dataset comprises a transaction id of the first or last transaction in the chain of transactions.

16. 13. The computer-implemented method of claim 12, wherein the dataset reference to the on-chain dataset comprises a block id of the initial transaction.

17. 10. The computer-implemented method of claim 1, further comprising obtaining a data item in the off-chain dataset.

18. 2. The computer-implemented method of claim 1, wherein each data item of the off-chain data set is obtained by accessing a database and / or by accessing data storage that substantially mirrors the database.

19. 19. A device comprising a processor and a memory, the memory containing executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method according to any one of claims 1 to 18.

20. 20. The device of claim 19, configured to audit the on-chain and off-chain data sets; a third party device configured to receive results of said audit; A system comprising:

Images