Ordered, append-only data storage

Abstract

A computer-implemented method for adding a current transaction associated with a set of transactions in a blockchain system, the method comprising: generating first state data, the first state data based on a first transaction reference to the first transaction and / or a second transaction reference to the second transaction, generating a current transaction comprising the first state data, and submitting the current transaction to the blockchain.

Description

[Technical field]

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

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

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

[0004] Nodes of a blockchain network (often called "miners") perform a decentralized transaction registration and validation process, which is described in detail below. In summary, during this process, nodes validate transactions and insert them into a block template, and the nodes attempt to identify a valid proof-of-work solution for that block template. Once a valid solution is found, a new block is disseminated to other nodes in the network, thus allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends it to one of the nodes of the network for it to be disseminated. 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 disseminated 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. 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] Therefore, it is 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 simple, fast, accurate, reliable, and secure manner that is computationally and functionally less onerous. More specifically, it is desirable to utilize the benefits of distributed ledger (blockchain) technology and 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. Furthermore, it may be desirable to group such data so that transactions can be examined according to groups or related to each other differently as they exist on the blockchain.

[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 adding a current transaction associated with a set of transactions in a blockchain system, the method comprising: generating first state data, the first state data being based on a first transaction reference to the first transaction and / or a second transaction reference to the second transaction; generating a current transaction comprising the first state data; and submitting the current transaction to the blockchain.

[0015] In a second aspect, the present disclosure proposes methods, devices and systems for tracking livestock through the use of the methods, devices and systems of the first aspect.

[0016] 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]

[0017] [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. [Figure 5A] FIG. 2 is a schematic diagram showing an overview of a chain of transactions storing log entries and the corresponding log entries; [Figure 5B] 1 is a flow diagram illustrating an example method for implementing an ordered append-only data storage system. [Figure 6] FIG. 2 is a schematic diagram illustrating the construction of a Merkle tree for use in various embodiments described herein. [Figure 7] FIG. 2 is a schematic diagram illustrating the construction of a Merkle tree for use in various embodiments described herein. [Figure 8A] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 8B] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 8C] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 8D] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 8E] 1 is a flow diagram illustrating an example method for implementing an ordered append-only data storage system. [Figure 9] FIG. 2 is a schematic diagram showing two Merkle trees based on two different protocols. [Figure 10A] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 10B] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 10C] 1 is a schematic diagram illustrating an exemplary data structure according to various embodiments. [Figure 11] FIG. 1 is a schematic diagram illustrating an overview of a platform for multiple blockchain-related services, according to an embodiment. [Figure 12] FIG. 1 is a schematic diagram illustrating components of a platform for multiple blockchain-related services, according to an embodiment. [Figure 13] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure may be implemented. [Figure 14]FIG. 2 is a schematic diagram illustrating components of a multi-service platform according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] In a first aspect, the present disclosure proposes a method for adding a current transaction related to a set of transactions in a blockchain system, the method comprising: generating first state data, the first state data being based on a first transaction reference to the first transaction and / or a second transaction reference to the second transaction; generating a current transaction comprising the first state data; and submitting the current transaction to the blockchain.

[0019] Preferably, the set of transactions is a chain of commitments as described herein.

[0020] Optionally, the first transaction reference is based on an output of the first transaction. Optionally, the first transaction reference is based on second state data of the first transaction. Optionally, the first transaction reference is a reference to a previous transaction in the set of transactions. Thus, the first transaction reference may also be referred to as a previous transaction reference. Advantageously, by basing the previous transaction reference on an output of a previous transaction in the set of transactions, a chain of backward references is established, which enables the ability for a participant to look backwards to find said previous transaction from the blockchain.

[0021] Optionally, the second transaction reference is based on a reference to an input of the second transaction. Optionally, the second transaction reference comprises an unspent transaction output point. Optionally, the second transaction reference is a reference to a next transaction in the set of transactions. The second transaction reference may therefore also be referred to as a next transaction reference. Optionally, the next transaction reference comprises an unspent transaction output point. Optionally, the unspent transaction output point is an input to the next transaction. Advantageously, by basing the next transaction reference on an input of a next transaction in the set of transactions, a chain of forward references is established, which enables the ability for a party to look forwards to find said next transaction from the blockchain.

[0022] Optionally, the first transaction reference and / or the second transaction reference are based on a reference to a sender account address and a nonce, advantageously allowing the reference to be used on an account-based blockchain, thus allowing a chain of transactions to exist either fully or partially on an account-based blockchain in a similar secure manner as described for UTXO-based blockchains.

[0023] When state data is based on both forward and backward lookups, the state data stored on the blockchain allows a participant to look forwards or backwards through a set of transactions. Thus, the data on the blockchain provides the participant with data to determine which transactions in the blockchain are part of the set of transactions. Optionally, the state data items are one or more of the "state digest(s)" embodiments as described herein.

[0024] Optionally, the first state data is of a known state size independent of the data on which the first state data is based. Optionally, the current transaction is of a known transaction size. Optionally, calculating a transaction fee for including the current transaction in the blockchain, the transaction fee is calculated exactly. Optionally, the transaction fee may be calculated exactly given the known transaction size. Advantageously, with the transaction size and transaction fee known, the amount used to fund each transaction may be determined in advance, and thus the funding inputs may be generated in advance. If the funding inputs are known in advance, they may be referenced (and thus used as a second reference as discussed above).

[0025] Optionally, the first transaction reference and / or the second transaction reference are hidden from public view on the blockchain. Advantageously, only parties with the necessary knowledge can inspect the set of transactions.

[0026] Optionally, the current transaction is indistinguishable from any other transaction on the blockchain. Optionally, the current transaction is indistinguishable from other transactions that may be part of a chain of commitments. Advantageously, this prevents any malicious third party from seeing which transactions are part of a set of transactions, and therefore the third party cannot determine any different information about the set of transactions, such as the total number, frequency, or other information.

[0027] Optionally, the first state data is based on the output of a one-way function taking as input the first transaction reference and / or the second transaction reference, advantageously preventing a malicious third party from reversing data stored on-chain to arrive at the reference, thereby further improving security.

[0028] Optionally, the first state data is PUSHDATA encoded. Advantageously, the PUSHDATA encoding keeps the script in a valid format that can be parsed by a blockchain node, so that a node will not reject a transaction for having an invalid blockchain script.

[0029] Optionally, the first state data is based on a hash-based data structure based on the first transaction reference and / or the second transaction reference. Advantageously, the hash-based data structure allows the data to be hidden (as a result of the one-way nature of the hash function) as well as to be in a known format for other parties to use when appropriate.

[0030] Optionally, the first state data is a first Merkle tree root of a state Merkle tree, and generating the first state data comprises generating a state Merkle tree. Optionally, the state Merkle tree comprises a first leaf node based on the first transaction reference and / or a second leaf node based on the second transaction reference. Advantageously, the Merkle tree root hides the contents of the Merkle tree, but allows reconstruction of the Merkle tree for verification of its contents. This therefore allows someone with a Merkle tree proof to verify that the Merkle tree was constructed using the same data.

[0031] Alternatively, the first state data is the last hash of a hash chain, the hash chain being based on the first transaction reference, the second transaction reference, the received client data, the salt, the metadata, and / or the version number.

[0032] Alternatively, the first state data is the output of a hash function and the input was a concatenation of the first transaction reference, the second transaction reference, the received client data, the salt, the metadata, and / or the version number.

[0033] Optionally, the first leaf node is generated by passing the first transaction reference through a one-way function at least once. Optionally, the first leaf node is generated by passing a reference to the first transaction through a one-way function at least twice. Optionally, the second leaf node is generated by passing the second transaction reference through a one-way function at least once. Optionally, the second leaf node is generated by passing the second transaction reference through a one-way function at least twice. Advantageously, pre-hashing the leaf nodes of the Merkle tree provides an additional layer of irreversibility to how the Merkle tree was constructed (and thus how the Merkle tree root was obtained). Using the one-way function twice prevents a malicious third party from exploiting any hash length attacks.

[0034] Optionally, the one-way function is a hash function.

[0035] Optionally, the state Merkle tree comprises a first data item as a leaf node. Optionally, the first data item is based on any one or more of the data received from the client, a set of metadata about the set of transactions, a version number, and a salt. Advantageously, by basing the state Merkle tree on the data, to reconstruct the Merkle tree (and thus the Merkle tree root), a malicious third party must also know all of the client data, metadata, version number, and / or salt. This improves the security of publicly available data.

[0036] Optionally, the first data item is a second Merkle tree root of the data Merkle tree, and generating the first data item comprises generating a data Merkle tree. Optionally, the data Merkle tree comprises a number of data leaf nodes, each of which is based on one of the items, version numbers, and / or salts from the set of metadata for the set of transactions, data received from the client. Advantageously, by basing the state Merkle tree on the further data Merkle tree (and preferably its Merkle tree root), a further layer of indirection and verifiability is achieved. In case a malicious third party needs to know not only the contents of the first and second references and the client data, but also how the Merkle tree is constructed, including all of the other metadata, salts, etc. The data Merkle tree is also verifiable using further Merkle tree proofs to allow the third party to verify that a given data (e.g., the third party's unique client data) is represented in the data Merkle tree and is also represented in a transaction in the chain of transactions.

[0037] Optionally, at least one of the data leaf nodes is based on a concatenation with a version number. Versioning a Merkle tree allows the creator of a Merkle tree to update the layout or data stored in the Merkle tree.

[0038] Optionally, the first state data is stored in the output of the current transaction. Optionally, the output is a non-consumable output. Optionally, the first state data is stored in the transaction after an OP_RETURN opcode and / or an OP_0 opcode. Advantageously, storing the data in the output of the transaction allows the data to be stored in the blockchain. The use of OP_RETURN and / or OP_0 means that the transaction output is provably untrustworthy. With the output being provably non-consumable, blockchain nodes that only store consumable UTXOs do not need to store this UTXO, thereby saving space across the broader blockchain network.

[0039] Optionally, the current transaction comprises a second data item. Optionally, the second data item is stored in an output of the current transaction. Optionally, the output is a non-consumable output. Optionally, the second data item is stored in the transaction after an OP_RETURN opcode and / or an OP_0 opcode. Optionally, the second data item is PUSHDATA encoded. Optionally, the second data item is based on the received client data. Optionally, the second data item is stored in the same output as the first state data. As discussed above, OP_RETURN and / or OP_0 make the output provably non-consumable, and the PUSHDATA encoding ensures that the blockchain script is still in a valid form for the verifier. Storing data based on client data allows a third party to prove the existence of a given data at a given time (sometimes referred to as a "proof of existence"). Optionally, this second data item is one or more of the "data digest" embodiments as described herein.

[0040] Optionally, the second data item is based on the output of passing a data item based on the received client data through a one-way function at least once. Optionally, the second data item is based on the output of passing a data item based on the received client data through a one-way function at least twice. Advantageously, the use of a one-way function prevents a third party from reversing the function to discover what the client data was. Using a one-way function more than once provides resistance to stretching attacks.

[0041] Optionally, data items based on received client data are salted. Salting any hash or one-way function provides greater resistance to malicious parties attempting to reverse the one-way function (e.g., through the use of rainbow tables).

[0042] Optionally, the data item based on the received client data is obtained by passing the received client data through a one-way function at least once. Optionally, the data item based on the received client data is obtained by passing the received client data through a one-way function at least twice. Advantageously, passing the client data again through the one-way function provides an additional layer of protection against reversing the hash, thereby improving the security of the public data stored in the blockchain.

[0043] Optionally, the one-way function is a hash function. Optionally, the second data item is a function H D :=H 2 (H 2 (D)||H 2 (SALT) is generated according to H D is the second data item, D is the client data, and H 2 is a one-way function (preferably a hash function) and SALT is the salt.

[0044] Optionally, the client data is hidden from public view on the blockchain. Advantageously, hiding the data from public view on the blockchain prevents malicious third parties from seeing it, thereby improving the security of the system. Optionally, a representation of the client data is immutably stored on the blockchain. Optionally, a second data item provides a proof of existence of the received client data. Advantageously, the immutable proof of existence of the data (which is optionally also hidden) allows the owner of the data to selectively provide proof of some aspects of their data in a secure manner and without publicly displaying the data for all to see.

[0045] Optionally, the second data item is of a known size independent of the data on which the second data item is based. Optionally, the current transaction is of a known transaction size. Optionally, the method further comprises calculating a transaction fee for including the current transaction in the blockchain, the transaction fee being calculated strictly given the known transaction size. As discussed above, knowing the transaction size (in advance) has several advantages, including allowing for an accurate determination of the fee required to include the transaction in the blockchain, as well as pre-generation of any UTXOs to fund the transaction.

[0046] Optionally, the current transaction belongs to a second set of transactions, and the third state data is generated based on the third transaction reference and / or the fourth transaction reference. Optionally, the third state data is stored in a further output of the current transaction. Optionally, the third transaction reference is in the same format as the first transaction reference. Optionally, the fourth transaction reference is in the same format as the second transaction reference. Advantageously, by belonging to the second set of transactions, the current transaction provides a way for two separate sets of transactions (or rather the logs and / or streams the sets of transactions pertain to) to atomically commit data to the blockchain across both logs / streams.

[0047] Optionally, the first state data is further based on a third transaction reference and / or a fourth transaction reference.

[0048] Optionally, the method further comprises determining a second transaction reference before the second transaction is generated. Advantageously, the second (forward) reference can refer to transactions on the blockchain before they exist through the use of a transaction exit point. Being able to create a link to a next transaction before the next transaction is known provides flexibility in that data of a current transaction can be committed immediately without having to wait for the next transaction to be generated.

[0049] Alternatively, the first transaction reference comprises data indicating that the current transaction is a first transaction in the set of transactions and / or the second transaction reference comprises data indicating that the current transaction is a last transaction in the set of transactions. Preferably, the first state data is a Merkle tree root and a Merkle tree constructed comprising one or more leaf nodes based on the third transaction reference and / or the fourth transaction reference.

[0050] Optionally, the data indicating that the current transaction is the first transaction in the set of transactions and / or the data indicating that the current transaction is the last transaction in the set of transactions is a byte string of 0. Optionally, the first transaction reference is a null reference and / or the second transaction reference is a null reference. Optionally, the null reference comprises a byte string of 0. Advantageously, the use of null references and / or known values ​​of 0 allows the state digest to represent a known end case. This is particularly important when investigating a set of transactions, because an investigator needs to know whether a transaction is at the end or the beginning of a set.

[0051] Optionally, the byte string of zeros is the same length as the first transaction reference or the second transaction reference. Optionally, the byte string of zeros is 32 bytes long. Advantageously, using the same length as the first transaction or the second transaction means that data structures used in generating the state Merkle tree do not need to accommodate the different sizes.

[0052] Optionally, the method further comprises the steps of receiving a stream creation message, the stream creation message comprising an indication of a condition for the trigger, obtaining data indicative of a state of the stream based on the trigger condition being satisfied, and generating an add transaction comprising the data indicative of the state of the stream. Preferably, the add transaction is of the same format as the current transaction as described above.

[0053] Advantageously, by providing triggers for the generation (and subsequent submission) of transactions that represent the current stream state, greater flexibility and selectability is achieved regarding how up-to-date the blockchain representation of the stream needs to be. Clients can select the aspects of the triggers according to their requirements when the event stream is created.

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

[0055] When large amounts of data are stored in an off-chain database, a trigger condition may occur multiple times, and the on-chain data set is updated when necessary by monitoring when additional trigger conditions are met.

[0056] In some embodiments, the method further comprises generating and broadcasting an initial transaction comprising at least an indication of a condition for the trigger.

[0057] In some embodiments, the trigger condition is based on any one or more of: receipt of 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.

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

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

[0060] Separating the submission of transactions to the blockchain from updates to the event stream, 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 get a rough idea of ​​the total number of events by simply counting every single on-chain append transaction and multiplying the count by 50. Depending on the smart contract involved, this may leak sensitive information to third parties. Using this embodiment mitigates this leakage by allowing the trigger to be time-based, thereby not leaking any information about the total number of events. Prevent any loops from occurring, where if an event stream were tracking its own on-chain submissions, then every event put into that event stream would trigger the creation of another event, and therefore another event transaction, and so on. Using this embodiment mitigates the above by not basing submissions to the blockchain on every single event that is received.

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

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

[0063] In a first aspect, a device is also proposed comprising a processor and a memory, the memory comprising executable instructions which, upon execution by the processor, cause the device to perform a computer-implemented method according to the above first aspect.

[0064] In a first aspect, a non-transitory computer readable storage medium is also proposed, comprising computer program code instructions executable by a computer for performing the method according to the above first aspect.

[0065] In a first aspect, a computer program is also proposed, comprising instructions which, when said program is executed by a computer, cause the computer to perform the method according to the above first aspect.

[0066] In a first aspect, a system is also proposed, comprising a device according to the first aspect as described above and a client device configured to emit data to the device such that a representation of the emitted data is included in the blockchain.

[0067] Optionally, the method according to the first aspect is for use with storing and tracking livestock related data in a blockchain and comprises receiving an event attachment message comprising an animal unique identifier and a descriptor of an event related to the animal associated with the animal unique identifier, and the first status data is based on the animal unique identifier and the event descriptor.

[0068] Preferably, the event attachment message relates to a vaccination performed on the animal associated with the animal's unique identifier. More preferably, the animal's unique identifier is determined using an RFID tag.

[0069] Optionally, the method further comprises determining an event stream associated with the animal unique identifier.

[0070] Optionally, the previous blockchain transaction reference is a reference to a transaction associated with an event stream associated with the animal referenced in the animal unique identifier.

[0071] Optionally, the method further comprises receiving a verification request comprising the animal unique identifier and the event reference, obtaining a verification proof for the event referenced by the event reference, and sending the verification proof to a sender of the verification request. Preferably, the verification proof is a Merkle proof.

[0072] Optionally, there is provided a method for verifying an event related to an animal, the method comprising the steps of obtaining event data relating to the event; obtaining a presence proof value from a transaction from a blockchain, the transaction being associated with a set of transactions, the transaction being stored in the blockchain according to a method according to any embodiment of the first aspect; obtaining a verification proof; and determining validity of the event data based on the verification proof and the presence proof value.

[0073] In a first aspect, a system for livestock management is also proposed, the system comprising a user device, a livestock management database and a blockchain interface system, the user device configured to capture a unique identifier associated with an animal during an animal-related event and transmit data regarding the event and the unique identifier to the livestock management database, the livestock management database configured to receive the unique identifier and the data regarding the event, the livestock management database further configured to transmit the unique identifier and the data regarding the event to the blockchain interface system, and the blockchain interface system configured to perform any one or more methods of the embodiments of the first aspect.

[0074] Optionally, the first state data is based on a third transaction reference, which in turn is based on a reference to a third transaction.

[0075] Preferably, the method further comprises the steps of obtaining a reference to a counting branch of the transaction; generating counting state data, the state counting data being based on a number of branches in the set of transactions and a reference to a most recent transaction in the counting branch of the transaction; generating a state counting transaction comprising the state count data; and publishing the current transaction to the blockchain.

[0076] Optionally, the first transaction reference and / or the second transaction reference are references to transactions stored or to be stored in a further blockchain, the further blockchain being different from the above blockchain. Preferably, the first transaction reference and / or the second transaction reference are references to an account-based blockchain. More preferably, the first transaction reference and / or the second transaction reference comprise an account address and a nonce.

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

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

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

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

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

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

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

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

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

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

[0087] 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 disseminates 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.

[0088] 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 the puzzle within a very short time of each other, resulting in conflicting views of the blockchain being disseminated 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.

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

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

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

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

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

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

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

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

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

[0098] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective participant 103 is a recipient (or in an embodiment, actually investigate the transactions of other participants in the blockchain 150, since the blockchain 150 is a public entity that provides credit for some transactions by virtue of its public presence). The wallet function of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward them to disseminate 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.

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

[0100] 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 by that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j disseminates 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 disseminated throughout the network 106.

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

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

[0103] 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, the 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.

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

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

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

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

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

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

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

[0111] 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 included in the locking script (in this example, a stack-based language). Preferably, the characters "<>" indicate that the content within the square brackets is PUSHDATA encoded. PUSHDATA encoding refers to using the OP_PUSHDATA opcode to add data to the stack. Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. In any case, when executed together, the scripts will push Alice's public key P, as included 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).

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

[0113] 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 disseminated 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.

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

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

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

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

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

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

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

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

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

[0123] 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 dissemination 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 functionality 353.

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

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

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

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

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

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

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

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

[0132] 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 derives Tx i Alternatively, Tx i , may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Txi locates the locking script in the referenced output of and passes it to the script engine 452.

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

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

[0135] 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 an embodiment, the application level decision engine 454 may apply one or more additional conditions before invoking either or both of these functions. For example, the decision engine may choose to publish a transaction only under the condition that the transaction is valid and has sufficient transaction fees remaining.

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

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

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

[0139] 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 functions of disseminating 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).

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

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

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

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

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

[0145] FIG. 5A shows an overview of the data structure and paradigm of an ordered append-only data storage system according to a first aspect of the disclosure. It may also be described as a data logging system. The system 500 comprises an off-chain (i.e., not on the blockchain) data storage system 504 that stores several log entries 506a-d. These log entries are reflected 502 on-chain through the use of blockchain transactions 508a-d. The off-chain data storage system is preferably a database. Those skilled in the art will appreciate that any data storage system may be used, including storage on a hard drive as an alternative.

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

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

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

[0149] Referring to FIG. 5B, an exemplary method 520 of adding a transaction to a blockchain where the transaction is part of a set of transactions, and in particular the set is a chain of commitments.

[0150] In a first step, a request to add data to a blockchain is received (522). In this particular example, the request triggers the addition of the transaction to a chain of commitments as described herein, and optionally also creates a chain of commitments if one has not already been created. Preferably, the request is from a client that wants a representation of the data to be stored on the blockchain, and more preferably, a hash of the client data will be stored on the blockchain. Alternatively, the request is from a client that wants to establish an event stream off-chain, thereby triggering an on-chain representation of the event stream in the form of a chain of commitments.

[0151] Next, references to the previous and next transactions are obtained 524. These references, as described below under the respective headings "Previous Transaction Reference" and "Next Transaction Reference", are based on the components of the transactions.

[0152] Once the reference is obtained, a transaction is generated based on the reference (526). The transaction preferably comprises a state digest, as described below under the respective heading "State Digest (S)". Optionally, the transaction comprises a "Data Digest (H)". D It is also based on data received from the client as described below under the respective headings "Client Support."

[0153] The transaction is then submitted for inclusion in the blockchain (528).

[0154] Referring to FIG. 8A, the data digest (H D) and state digest (S). Preferably, the transaction generated in step 526 as described with reference to FIG. 5B is of this form. This generic example transaction is of known size (and so are the specific examples). This is because all of the transaction components are of known, constant size. For example, the transaction input is chosen to be of a particular design and size, with a known, immutable scriptSig, and therefore immutable scriptSigLen. Similarly, the output comprises two opcodes of known size, and two hashes with known, constant size (32 bytes in this example) that are independent of the underlying data. The overall size of this generalized transaction design can be summarized according to the table below. Note that this is a general form of Bitcoin and / or Bitcoin Satoshi Vision (BSV) transaction, given by way of example only (the general transaction layout is also described at https: / / wiki.bitcoinsv.io / index.php / Bitcoin_Transactions). Other blockchains may have different formats. Those skilled in the art will appreciate that their exact values ​​and sizes may vary on different blockchains, and known sizes may be calculated for different blockchain transactions.

[0155] [Table 1]

[0156] Those skilled in the art will appreciate that this is a table of preferred transactions. In different exemplary embodiments, if a data digest is not present in the output, the scriptPubKey is OP_0 OP_RETURN n > and instead has a size of 34.

[0157] ​If the transaction size is known, the funding input can be calculated precisely and the UTXOs to fund it can be pre-generated. Thus, a funding service configured to fund transactions in a chain of commitments can generate a bank of exactly enough satoshi UTXOs to pay for the inclusion of the 274 bytes of the transaction in the blockchain.

[0158] To illustrate, if the other blockchain is an account-based blockchain, such as Ethereum, the same or similar data may be stored in that transaction, for example, through the use of an optional "data" field that allows any data to be associated with or attached to a transaction. More specifically, the "data" field of an Ethereum transaction may contain a state digest (S), and optionally a data digest (H D ) is provided.

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

[0160] where || is the concatenation of the members before and after it, and H 2 is a double hash function.

[0161] Hashing is provided as the primary example of a one-way function herein, although those skilled in the art will appreciate that other one-way functions may also be used.

[0162] Preferably, the data digest (H DIn this embodiment for Event Data, Salt, and throughout this specification, the hash function used is the SHA-256 cryptographic hash function. "Hashing" as used throughout this specification means hashing preferably at least once, and more preferably more than once. Hashing more than once provides resistance to stretching attacks. Instead of hashing twice (or more), a different hash function or method is used that is not vulnerable to stretching attacks. For example, SHA-3 and / or HMAC (optionally using the same or different salts as the key) provide such functionality. A further alternative is to generate a Merkle tree with the leaf items {Event Data, Salt}, and the data digest is the Merkle tree root.

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

[0164] Preferably, a different salt is chosen for each data item being hashed, i.e., each time even within an event stream. The salts are preferably stored for later use in data validation. As discussed below under the heading "State Digest (S)", preferably the different salts for each data item are stored in the state client data digest (H D '). Salting the hash provides resistance to pre-computed "rainbow table" based attacks, thereby providing greater security for clients wishing to store potentially sensitive data on the blockchain.

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

[0166] State Digest(S) As mentioned above, the payloads 512a-d comprise or are based on references to a series of previous and next transactions related to the event. By providing data based at least on previous and next transactions as described herein, in combination with the immutability of the blockchain, a secure, immutable, unforkable link between successive parent-child transactions is formed. Here, "unforkable" refers to the property that for a given transaction, there can be only one (or zero) next transaction and one (or zero) previous transaction in the set. It is not possible for a chain of commitments to have more than one possible next or previous transaction and / or event represented by a transaction in the set of transactions.

[0167] Preferably, the payload 512 comprises state data based on components of a previous transaction and components of a next transaction. Preferably, these components act as references and are called references, where the previous transaction refers to the transaction generated (and optionally issued) immediately before the current transaction is generated, and the next transaction refers to the transaction that will be generated and issued immediately after the current transaction is generated. Note that the next transaction may not yet be generated, and much of the content of the next transaction is unknown (as it is not possible to see into the future what a client may submit for storage in a blockchain transaction). Optionally, the state data is also based on client data represented on the blockchain. Optionally, the state data is based on a data digest (H) as described above. D Optionally, the state data is also based on metadata about the events and / or metadata about the event stream.

[0168] State Data Structure As discussed herein, the state data is based on several features, where "based on" is used herein in reference to the state data, and preferably this refers to the state data being based on a hash of all of the previous transaction reference, the next transaction reference, and the client data. More preferably, the state data is a digest, alternatively referred to as a state digest. Even more preferably, the state digest is a Merkle tree root, and the leaves of the Merkle tree are based on the previous transaction reference, the next transaction reference, and the client data.

[0169] In a preferred embodiment, the Merkle tree is generated by storing a previous transaction reference, a next transaction reference, and a state client data digest (H D The state client data digest is based on the data digest (HD ), and optionally, any metadata associated with the events and / or event stream. D These are described in more detail below under the heading "

[0170] Therefore, the state digest (S) is S:=Merklize({PREV,H D ',NEXT}) According to the formula (see the previous transaction example, the state client data digest (H D '), and the following transaction reference:

[0171] Here, the Merklize function generates Merkle roots from an ordered set of data elements as leaves, {PREV,H D ',NEXT} is an ordered set of leaves based on the elements. Each of the leaves is first double-hashed in the Merklize function. Note that due to the way hashing and Merkle trees work, the order of the set of inputs to a Merkle tree is important, and therefore the order of the inputs must be the same whenever a Merkle tree is created, recreated, or verified, so that the same tree (and therefore the same state digest) is produced for the same input data.

[0172] Optionally, the state digest is based on the version number. If a version number is specified for the call to the Merklize function as described below, then each leaf node is based on the version number. Preferably, each leaf node preimage is prepended with a version number. Alternatively, each leaf node preimage is suffixed with a version number. Preferably, the actual order of the leaf node preimages and version numbers is not important as long as it is consistent between generations and subsequent uses. Advantageously, the use of version numbers allows state digests to be tied to specific versions (as different version numbers will result in different Merkle tree roots even if the same input data is used). Preferably, changes to the version number are used in concert with any changes to the rules for how Merkle trees are constructed (e.g. new and / or different leaf nodes). Preferably, each version number is associated with a unique rule for the Merkle tree that is generated.

[0173] The Merklize function optionally takes a version number (v) as an additional argument according to the following formula: S:=Merklize({PREV,H' D ,NEXT},v)

[0174] The Merklize function is preferably as follows: Merklize({PREV,H' D ,NEXT},v): 1. If v==null: 1.1 Let T be a Merkle tree T←GenMerkleTree({PREV,H' D ,NEXT}) 1.2 Root R of a tree T T Get 1.3 R T Return 2. Otherwise: 2.1 Update each leaf in the list of leaves by prepending a version number: 2.1.1 PREV←v||PREV 2.1.2 H' D ←v||H' D 2.1.3 NEXT←v||NEXT 2.2 Generate a Merkle tree T using the updated set of leaves: T ← GenMerkleTree({PREV,H' D ,NEXT}) 2.3 Root R of a tree T T Get 2.4 R T Return

[0175] The function GenMerkleTree is preferably interpreted as meaning a standard method for generating a Merkle tree given a set of leaf data items. Preferably, the first step of GenMerkleTree is to iterate over each of the items in the leaf set (in this example {PREV,H' D ,NEXT}), and more preferably hash them twice.

[0176] Referring to FIG. 6, an exemplary generated Merkle tree 600 includes leaf nodes PREV 602, H D ' 604, and NEXT 606. The Merkle tree root 608 is the state digest (S), a value that is preferably used on the transaction. This exemplary Merkle tree is constructed as a binary tree such that each node has two children (excluding leaves). Since there are an odd number of input data items (and therefore an odd number of leaves), the last unpaired leaf node is doubled. Those skilled in the art will appreciate that it is not necessary to strictly follow this presented form of the Merkle tree, and there are other forms that may function similarly. As discussed above, each item in the input set is hashed twice (610), and each twice-hashed item is used as a leaf of the Merkle tree.

[0177] Instead of a Merkle tree structure, the state digest can be generated by hashing the pre-image, which is constructed by concatenating the objects whose state data is based on it. Thus, in the example where the state digest is based on the previous transaction reference, the state client data digest, and the next transaction reference, the formula is S:=H(PREV||H' D ||NEXT) It can be in the form:

[0178] Optionally, a salt may also be incorporated into the pre-image, for example, the salt may be concatenated to the beginning or end of the pre-image.

[0179] As a further alternative to the Merkle tree root, the state digest can be generated by using a hash chain. A hash chain is constructed such that each intermediate hash result is prepended to the item on which the state digest is based. For example, if the state digest is prepended to the previous transaction reference, the state client data digest (H D '), and based on the following transaction reference, the expression is S:=H(PREV||H(H' D ||H(NEXT))) It can be in the form:

[0180] Optionally, the salt is incorporated into the hash chain. Optionally, the salt is incorporated by prepending the salt to each intermediate preimage.

[0181] Previous transaction reference (PREV) As discussed above, the state digest is preferably based on a reference to a previous transaction. Preferably, the reference to a previous transaction in a chain of commitments is based on state data of the previous transaction being referenced. More preferably, the reference to a previous transaction is state data of the previous transaction being referenced as it was stored in the blockchain. The previous transaction reference is optionally called a parent transaction reference, of which the current transaction is a child.

[0182] If there is no previous transaction to be referenced (i.e., it is the first in the chain of commitments), the previous transaction reference may be considered a null reference. Preferably, the null reference is a string of zeros. Preferably, the size of the string of zeros is the same size as the size of the previous transaction reference if it was not null. More preferably, the string is 32 bytes long. The following table describes a preferred embodiment of the previous transaction reference.

[0183] [Table 2]

[0184] Optionally, or alternatively, the PREV pre-image may be and / or be represented using a JSON structure with the data options mentioned above. Advantageously, the use of JSON objects provides the capability as more data elements are added, as they can be easily added and referenced.

[0185] Next transaction reference (NEXT) As discussed above, the state digest is preferably based on a reference to the next transaction. Preferably, the reference to the next transaction in the chain of commitments is based on the input to the next transaction. Advantageously, many of the components of the next transaction are unknown (as a result of their existence being in the future and data being emitted by the client) and therefore cannot be used as references, but the input UTXO or UTXOs used to fund the transaction can be determined in advance and are unique only to that transaction when it is committed to the blockchain. Preferably, the input UTXO is referenced by an output point. The output point comprises the transaction id (called TxID) of the transaction to which the UTXO belongs and the index of the output of the referenced transaction (called vout). The next transaction reference is optionally called a child transaction reference, with the current transaction being the parent.

[0186] While a UTXO-based blockchain (such as Bitcoin) is used throughout as the primary illustrative example, those skilled in the art will appreciate that the present invention may work with other blockchains as well. For example, if the blockchain uses an account-based model (such as Ethereum), a transaction may be referenced based on the sender's account address and a nonce. Note that both the sender's account address and nonce may be determined prior to the transaction being generated and / or submitted to the blockchain, and further, that the sender's account address and nonce pair is unique. These two properties are essential to the UTXO-based output point referencing (OTXO) described herein. NEXT ), allowing the pair to function as a future reference similar to

[0187] Similar to the previous transaction reference, if there is no next transaction to be referenced (i.e., the current transaction is the last in the chain of commitments), the next transaction reference may be considered a null reference. Preferably, the null reference is a string of zeros. Preferably, the size of the string of zeros is the same size as the size of the next transaction reference if it were not null (i.e., the size of the transaction output point). More preferably, the string is 32 bytes long. The following table describes a preferred embodiment of the next transaction reference.

[0188] [Table 3]

[0189] Optionally or alternatively, the NEXT pre-image may be and / or be represented as a JSON structure, with the data options mentioned above. Advantageously, the use of JSON objects provides the capability as more data elements are added, since they can be easily added and referenced.

[0190] State Client Data Digest (H D ') As discussed above, the state digest is preferably based on client data, more preferably based on a hash of the client data, and even more preferably based on metadata of the events and / or event stream to which the current transaction pertains.

[0191] The following table shows the state client data digest (H D ') explains the preferred content based on that.

[0192] [Table 4]

[0193] Preferably, the data digest H D The "data digest (H D )" heading and are defined and generated in the same manner as described above.

[0194] When there are several metadata elements, they are listed as M1, M2, etc.

[0195] Exemplary metadata elements may include any one or more of the following: whenRecorded - the time the event was received from the client and / or stored in the off-chain log appVersion - the version number of the chain of commitments seed - seed value used at the beginning of the event stream generation delWriteIV - the initial value used in generating a delegated authorisation token for writing to the event stream. delWriteH0 - The last hash value used to validate the delegation authority token for writing to the event system. timeAC - the start and / or end time at which the event stream is considered accepting writes. delAuthIndex - the index of the delegation token that the client used to emit the event TxIDcreate - the transaction ID of the first transaction in the chain of commitments, and / or index - the index of the current event in the event stream (not necessarily the same as the index in the chain of commitments, since it is not mandatory that all events are recorded in the chain of commitments) nextHashSalt - hash of the salt to be used in the next event. Preferably, a salt is pre-generated for the next event in the chain of commitments, and this salt is hashed and used in generating the state-client-data-digest Merkle tree.

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

[0197] Referring to FIG. 7, the root is the state client data digest (H D 7 shows an exemplary Merkle tree 700 in which the state data Merkle tree 600 is a state data ...

[0198] Preferably, the set of leaf nodes 706, 708, 710, 712, 714 is a set of data (H D ) digests and metadata leaf nodes are interleaved with the salt. This interleaving increases the security of the data in the Merkle tree by making it prohibitively expensive for a third party to brute force the Merkle tree. If a third party were to obtain the protocol description for the chain of commitments, H D Considering that (data digests) are preferably stored publicly in the transaction, a third party can obtain the metadata values ​​M1, ...M m Their values ​​can be brute-forced, given that H can be predictable or easily counted in many cases (e.g., if one of the metadata elements is a timestamp, this may be guessable given the time the transaction was put on the blockchain, or one of the metadata elements may be a monotonically increasing index, which may be guessable given the previous state). A third party can brute-force these values ​​to obtain a value H D ' (i.e., the root of the tree) can be correctly reconstructed, then a third party can obtain the metadata values ​​M1,…M mIn some cases, these metadata can be sensitive, for example the whenRecorded or writeAccessControl.region properties are used as metadata in EventStream transactions and may be important to a malicious third party.

[0199] Preferably, the preimage on which the leaf node is based is prepended with the protocol version number.

[0200] Thus, the process of creating the exemplary Merkle tree 700 can be written as follows: DataDigestCommit(H D ,SALT,M1,…M m ,v) 1. Create m copies of SALT 2. Data items are D ,SALT,M1,SALT,…,M m ,SALT} 3. H' D ← Merklize ({H D ,SALT,M1,SALT,…,M m ,SALT},v) 4. H' D Return

[0201] Note that the same Merklize function is used here as in creating the state digest as discussed above. Since the same Merklize function is used, the preimages of leaf nodes are also optionally hashed twice.

[0202] Similar to the discussion of Merkle tree generation above, several alternatives to Merkle trees are possible, including concatenating the inputs and hashing the result, as well as generating hash chains.

[0203] State Client Data Digest H DFor the generation of ', the protocol version number is preferably used (compare with the state digest (S) discussed above, this preferably results in v=null). The state digest (S) is a multiple of the state client data digest (H D '), so H D By making H' dependent on a protocol version number (v), S also depends on v (even though it is not directly used in the creation of S). D This means that S will be different if the same input is used except for the different protocol version numbers used in the generation of ', allowing S to depend on the protocol version number without the protocol version number being used twice in the generation of the two Merkle trees.

[0204] Referring to FIG. 9, two different state client data Merkle trees 900, 902 are shown. The first state client data Merkle tree 900 comprises a Merkle tree root 904 (which is the state client data digest as used in state digest 608) based on several leaf nodes and intermediate nodes. The first Merkle tree is generated using protocol version v0. As discussed above, all preimages of leaf nodes are prepended with the protocol version number. The second Merkle tree is constructed similarly, but with a new unique specification and prepended version number v1. The second Merkle tree also comprises a new leaf node "NEW" (compared to version v0). Thus, the item of data is H D Any Merkle proof used to prove that a protocol version was used in creating 904, 906 also proves which protocol version was used to generate the chain of commitment transactions that contain the data payload. Note that this requires knowledge of the value of v when both generating and verifying such a proof.

[0205] Optionally, the client state data digest (HD Merkle trees, such as those used in generating '), can be represented using a JSON structure, and / or vice versa. This is made possible by the hierarchical nature of the JSON structure and Merkle trees, where each element of the JSON structure is a leaf node of the corresponding Merkle tree. Each element has an associated value that can be hashed, and this hashed value is a leaf node in the corresponding Merkle tree. If a JSON element has child elements (i.e., values ​​with further key-value pairs), then the JSON element has further Merkle trees associated with it. An exemplary alternative JSON object has three top-level elements: ·hashedData - H D , the hash of the blob of data associated with this dataset hashedNextSalt - the hash of the raw salt that will be used by the next chained dataset metadata - data specific to this dataset item, this can take different forms depending on the use case

[0206] Each JSON element is referenced according to its path. An example JSON might look like this: { "hashedData": "w6uP8Tcg6K2QR905Rms8iXTlksL6OD1KOWBxTK7wxPI=", "metadata": { "appVersion": "v1.0.4.30", "esId": "eyJsIjoiZnJhbmtmdXJ0IiwibyI6IjAzNzQ3NjNmMTE5YzQ2OGQ5ODY1ZjQ1NGY5ODQxMDFiIiwicyI6IkVTIiwidiI6IjEifQ", "index": 42, "sequenceNumber": false, "delegatedAuthIndex": 0, "delegatedAuth": null, "tags": [ "foo", "bar" ], "whenReceived": "2022-02-13T13:23:52Z" }, "hashedNextSalt": "oYGilj+52yoDqdrpGYnBgPLn3FmSdaST2evGeogQMs4=" }

[0207] Since metadata is a JSON element with child elements, the child elements of metadata are used in generating further sub-Merckle trees whose leaf nodes are based on the child elements of metadata (i.e. appVersion, esId, etc.) The same applies to the tags element, since it also has sub-elements.

[0208] An element's path is a dot-separated string constructed from the names of the nodes (names are also written as keys) that are examined to reach the element. Elements in an array are denoted by [] and a zero-based index into the array. Thus, we can see that several metadata elements are referenced according to the following paths: hashedData - (as used herein, H D ) · metadata.index metadata.tags[1]

[0209] Exemplary embodiments Referring to FIG. 8A, the data digest (H DA particular exemplary transaction 800 is shown with a "funding" input 818 that comprises a transaction output point (S) and state data (S). The transaction is the nth transaction in the chain of transactions stored in the blockchain. The transaction comprises a transaction id TxIDn 802. The transaction comprises a payload 804 that is stored in the transaction output using an opcode (as discussed above) so that the output is non-consumable and allows data to be stored. Preferably, two opcodes are used: OP_0 and OP_RETURN. Transaction TxIDn is funded by a "funding" input 818 that comprises a transaction output point to identify the transaction that funds it.

[0210] The payload 804 also includes a data digest H Dn and a state digest (S) Sn 810. In this embodiment, the state digest (S) is a Merkle tree root, where the Merkle tree is based on all of the previous transaction reference, the client data, and the next transaction reference (as indicated by the “M” function).

[0211] Referring to Figure 8B, three exemplary transactions 806a, 802, 808a are shown in a chain of commitments 820. As in Figure 8A, transaction TxIDn 802 comprises a funding input 818 and a data payload 804a, which includes a data digest (H Dn ) and a state digest (Sn) 810a, where the state digest is the Merkle root of a tree based on a reference 812a to the previous transaction 806a, a state client data digest 816a, and a reference 814a to the next transaction 808a. The state client data digest 816a is Dn ), salt, and the TxID of the first transaction in the chain of commitments. create) (which is example metadata for events, event streams, and / or chains of commitments), and the Merkle tree root of a Merkle tree based on other metadata as indicated by "...".

[0212] The reference to the previous transaction 812a is the state digest (S) of the previous transaction 806a. The reference to the next transaction 814a is the output point of the funding input to the next transaction 808a.

[0213] 8C, there is shown a first transaction 822 and a second transaction 808b of a chain of commitment 830. The first and second transactions comprise a funding input 818 and a payload 804b.

[0214] The payload of the first transaction is the data digest (H D ) and state digest (S) 810b because they are the first (or 0th) data digest and state digest in the chain of commitments. The state digest is the Merkle tree root, and the Merkle tree is based on the previous transaction reference, the state client data digest 816b, and the next transaction reference 814b. Since this is the first transaction, the previous transaction reference is a null reference and comprises 32 bytes of 0. As in the previous example, the next transaction reference is based on the exit point that funds the next transaction in the chain of commitments. The state client data digest is Dn ), a salt (SALT), appVersion metadata (appVersion), as well as other metadata (...).

[0215] 8D, an exemplary last transaction 842 and penultimate transaction 806b of a chain of commitments 832 are shown, both with a funding input 818 and a payload 804c.

[0216] The payload 804c of the last transaction 834 is the data digest (H D ) and state digest (S) 810c. The state digest is the Merkle tree root, and the Merkle tree is based on the previous transaction reference 812b, the state client data digest 816c, and the next transaction reference. Since this is the last transaction, the next transaction reference is a null reference and comprises 32 bytes of 0. As in the example of FIG. 8B, the previous transaction reference is the state digest of the previous transaction 806b. The state client data digest is the data digest (H Dn ), a salt (SALT), appVersion metadata (appVersion), as well as other metadata (...).

[0217] Referring to Figure 8E, an exemplary method 840 of receiving and storing a representation of client data in a blockchain through use of an embodiment of a chain of commitment as described herein is shown. The exemplary method here is a specific example of method 520 as described with reference to Figure 5B. Those skilled in the art will appreciate that it is not necessary to strictly follow the order of steps. For example, steps related to obtaining previous transaction 846 and next transaction 846 may be performed prior to receiving 842 the client data.

[0218] In a first step, a request is received, either directly or indirectly, from a client, the request comprising data, called client data, for which the client would like a representation stored in the blockchain.

[0219] Next, the client data digest (H D ) is obtained 844. Preferably, a client data digest is obtained as described above under the heading "Data Digest" such that the client data is hashed, salted, and hashed again, preferably the hashing is a double hash.

[0220] Next, the previous and next transactions are obtained (846, 848). For the previous transaction reference, the state digest (S) of the previous transaction in the chain of commitments is obtained. Optionally, this is obtained from the blockchain, or alternatively, it is stored off-chain in a database and called when needed. For the next transaction reference, the output point for funding the next transaction is obtained. Optionally, this is obtained from a funding service that manages the generation and storage of UTXOs for funding. Optionally, the funding service is the same service that is generating the chain of commitment transactions.

[0221] Client Data Digest (H D ) is obtained, the state client data digest (H D Preferably, the state client data digest (H D ') is obtained as described above under the heading "State Client Data Digest", so that a Merkle tree is constructed based on the client data digest, the salt, the protocol version number, and other metadata. D ' is the root of the Merkle tree.

[0222] State Client Data Digest (H DA state digest (S) for the transaction is generated (850) using all of the client data digest, the next transaction reference, and the previous transaction reference. Preferably, the state digest (S) is generated by constructing a Merkle tree based on the client data digest, the next transaction reference, and the previous transaction reference, the root of which is the state digest (S).

[0223] The output is the client data digest (H D ) and a state digest (S), a transaction is generated (854).

[0224] Transactions are sent to blockchain nodes for inclusion in the blockchain.

[0225] Rendezvous Transactions It may be desirable to generate transactions that exist across multiple different chains of commitments. Such transactions that exist across multiple different chains of commitments are called "rendezvous transactions". Rendezvous transactions provide a way to atomically synchronize multiple chains of commitments. This may be relevant when a single event is involved in several chains of commitments (or the event streams they represent) and the event needs to be recorded atomically across the different chains.

[0226] 10A, an exemplary rendezvous transaction 1002 is shown as part of multiple chains of commitments 1000. It can be seen that one output 1004, 1006, 1008 is used for each chain of commitments that the rendezvous transaction is part of. For example, if the rendezvous transaction is part of three chains of commitments, the rendezvous transaction will have three outputs. Each transaction output will have a payload related to a respective chain of commitments.

[0227] Preferably, each output 1004, 1006, 1008 of a rendezvous transaction is of the same format as described above with reference to a non-rendezvous chain of commitment transactions, in that the output comprises a data digest and a state digest (S) (the state digest is based on references to the previous and next transactions in the chain, as well as state client data).

[0228] Each output 1004, 1006, 1008 of the rendezvous transaction also has a corresponding funding input. Optionally, this funding input is of the same type and amount as the non-rendezvous chain of commitment transactions. Advantageously, by using the same UTXO funding input referencing method, the non-rendezvous transaction can still reference the rendezvous transaction in its next transaction reference without further modification (because the rendezvous transaction still has the funding input to the reference). Similarly, the rendezvous transaction still carries a state digest (S) on each output so that the next transaction in the chain of commitments that references the rendezvous transaction can still use the same preferred previous transaction reference.

[0229] Thus, as can be seen in the figure, each rendezvous transaction output 1004, 1006, 1008 contains a state digest (S n1-1 ,Sn2-1 ,S nk-1 ) to the corresponding previous non-rendezvous transaction 1010, 1012, 1014. Also, each rendezvous transaction output is based on a reference to the next non-rendezvous transaction reference (O n1+1 ,O n2+1 ,O nk+1 ) to the corresponding next non-rendezvous transaction 1016, 1018, 1020 using the funding input reference.

[0230] Referring to Figure 10B, an alternative way of constructing a rendezvous transaction is shown, where a single transaction input and output is used, rather than having different inputs and outputs for each chain of commitment that TxIDi belongs to (as shown in Figure 10A).

[0231] Data digest of TxIDi (H D ) is instead based on all of the client data D submitted across all of the various chains. Preferably, the data digest is a Merkle tree root, where a Merkle tree is generated and each leaf node is based on the data of each chain submitted by the client. Preferably, a hash of each client data is used. In this way, the size of the data digest as stored in the blockchain remains the same regardless of the number of chains of commitments that transaction TxIDi is part of.

[0232] Similarly, the state digest is based on all of the previous transaction references as well as all of the next transaction references. Instead of a Merkle tree having only PREV, HD, and NEXT as preimages to leaf nodes, all of the PREV references across different chains of commitments, all of the HDs across different chains of commitments, and all of the NEXT references across all of the different chains of commitments are leaf nodes. This provides a similar advantage in that the size of a single output of TxIDi is not increased even though it is based on what may be a fairly large amount of data.

[0233] Instead of a Merkle tree as described in the previous two paragraphs, all of the client data received across different chains of commitments is concatenated and hashed to give the final data digest, and all of the PREV, HD, and NEXT across all different chains of commitments are concatenated and hashed to give the final state digest.

[0234] As a further alternative to the Merkle tree described above, all of the received client data, PREV, and NEXT data across the entire chain of transactions are concatenated and hashed. Thus, the state digest may be determined according to the following expression: S:=H 2 (PREV || H' D ||NEXT||PREV_1||H D ' 1 ||NEXT_1||PREV_2||NEXT_2)

[0235] where PREV_1, NEXT_1, PREV_2, NEXT_2 are transaction references of the same form or format as described above under the headings "Previous Transaction Reference (PREV)" and "Next Transaction Reference (NEXT)", except that they point to different chains of transactions. The presence of a data digest is optional, depending on the nature of the chain of transactions being connected through rendezvous transactions.

[0236] Multi-branch chains of transactions 10C, an exemplary branch chain of transaction data structure 1050 is shown. Those skilled in the art will appreciate that the example provided in FIG. 10C is for illustrative purposes and that many different branch layouts are possible. Preferably, the branch data structure uses the same transaction layout as described under the heading "Rendezvous Transactions." For example, if transaction e11 points to both transactions e12 and e20, then either the e11 transaction has one input and one output for each branch (as described in FIG. 10A), or the e11 transaction has one state digest based on NEXT references to both e12 and e20 (as described in FIG. 10B).

[0237] Note that the branches that result in branches e11, e14, eroot (called divergent transactions) have more NEXT references than PREV references. Those skilled in the art will appreciate that this may be implemented through the use of a NULL PREV reference, through the use of the same PREV reference for both branches (e.g., e10 is used twice as a PREV reference in the e11 divergent transaction), and / or by simply not having the data structure include a second PREV reference. In the latter example, the presence of a larger number of NEXT references compared to the PREV references may be used to indicate that the current transaction is a divergent transaction.

[0238] Optionally, the multi-branch chain of transactions comprises a counting branch 1052. The counting branch branches from the eroot transaction and is used to count the number of branches the chain of transactions has. Preferably, each transaction on the counting branches e00, e01, e02 comprises data indicating the number of branches.

[0239] To illustrate how counting branches work, a description is given with respect to a branch layout as shown in FIG. 10C. Those skilled in the art will appreciate that other branch layouts may be possible. An eroot transaction is first generated with two references: a NEXT reference to e00, which is associated with the counting branch, and a NEXT reference to e10, which is associated with another chain of transactions. e00 comprises data that can be used to prove that there is only one other branch starting at e10. At some later point in time, two events occur such that the chain of transactions needs to branch at e11. A transaction e01 is generated with data that can be used to prove that there are now two branches starting from e11. Optionally, this transaction is also based on a reference to a second branch e20. At some later point in time again, an event occurs such that two more branches are needed from e14. A transaction e02 is generated with data that can be used to prove that the number of branches is now four overall.

[0240] To verify a multi-branched chain of transactions, a verifier starts with a counting branch to determine how many branches there are and where the branches began. By doing this, the verifier can ensure that each chain of transactions is unique and that there are no hidden branches or hidden versions. Counting branches therefore increases the security of the chain of transactions while still maintaining the privacy / secrecy of the layout and data stored in the blockchain.

[0241] Cross-chain blockchain reference As discussed in the section entitled "Next Transaction Lookup (NEXT)," a NEXT lookup can be made to any UTXO-based blockchain transaction (through the use of an exit point) or to any account-based blockchain transaction (through the use of the sender's account address and nonce). This concept is optionally described as a "cross-chain lookup" because a transaction on one blockchain may comprise data that is based on a reference to a transaction on a different blockchain.

[0242] It can thus be seen that the NEXT reference can point to different blockchains, including those that do not have transactions of the same format. For example, if a chain of transactions (which may be associated with an event stream) is recorded in a UTXO-based blockchain such as Bitcoin SV, then an exemplary transaction TxIDn may represent an Ethereum transaction TxID that has not yet been committed to the Ethereum blockchain (and whose transaction ID cannot yet be known). n+1 The state digest may be based on a NEXT reference referencing the sender's account address and a nonce, as discussed above. In this way, the chain of transactions can continue on a second (or any number of further) blockchains.

[0243] Preferably, TxID n+1 Transactions are also tagged with a TxID to ensure that the chain of transactions continues. n+1 is the result of a completion event and therefore ends the chain of transactions), n+2 It has a state digest based on a NEXT reference to

[0244] Optionally, when a cross-chain reference is used, the NEXT reference comprises a blockchain identifier to indicate which blockchain is being referenced. Preferably, the blockchain identifier is in the form of a three-letter identifier similar to an ISO4217 identifier. The presence of the blockchain identifier may be used to indicate that a cross-chain reference was used. Alternatively, the blockchain identifier is present in every transaction. Exemplary blockchain identifiers may be BTC for Bitcoin, BSV for Bitcoin SV, ETH for Ethereum, XMR for Monero, etc.

[0245] Alternatively, as discussed under the heading "State Data Structures", 2 The hash function can alternatively be a Merklize function that takes a list of inputs as leaf nodes. Note that the same or similar characteristics regarding salting, ordering, and other features as described under "State Data Structures" apply to state digest data structures with more than two transaction references as well.

[0246] Advantageously, cross-chain references provide great flexibility to users (and / or owners of associated event streams) creating chains of transactions.

[0247] Further advantageously, cross-chain referencing gives a chain of transactions the ability to take advantage of technical features of different blockchains. For example, if a different blockchain implements advantageous transaction types and / or improved security features, cross-chain referencing ensures that the chain of transactions remains securely linked when moving to said different blockchain. Similarly, even if a currently used blockchain forks and removes the ability to store data in the OP_RETURN opcode, cross-chain referencing can be used to maintain a secure link of the chain of transactions to a different blockchain that allows for proper data storage (like the "data" field in Ethereum or OP_RETURN in BSV).

[0248] Even more advantageously, cross-chain referencing gives a chain of transactions the ability to take advantage, even if only temporarily, of cheaper transaction fees on a different blockchain.

[0249] Further advantageously, cross-chain referencing provides the ability to reference transactions that may only be attestable or referenced on a particular blockchain. For example, if an Ethereum related event is included in the current chain of a transaction and / or needs to be securely referenced in the current chain, a reference can be made to the appropriate smart contract transaction.

[0250] Those skilled in the art will appreciate that cross-chain blockchain referencing may also be used in conjunction with rendezvous transactions and / or multi-fork chains as described herein, such that it is possible to fork a chain of transactions onto different blockchains and / or atomically relate events occurring on two chains of transactions that use different blockchains.

[0251] Blockchain data submission frequency As described herein, an example is used in which all client data received is for commitment to the blockchain, however, alternatively, different options are provided such that only a subset of the received data is sent to the blockchain.

[0252] As described herein, at least two data sets are used: off-chain storage and on-chain storage (as discussed with reference to FIG. 5A). The on-chain storage comprises a subset (but not necessarily a strict subset) of the off-chain data set. There are three different ways that a client can select to change the number of times an event is reflected in the blockchain: onFinalise, checkpoint, and onEvent.

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

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

[0255] In the onEvent method, every event that is added to the off-chain database also has data that represents it on the blockchain. 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 generates the appropriate data to add to the blockchain.

[0256] 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 a public blockchain serves this purpose.

[0257] In the checkpoint method, two exemplary embodiments of triggering conditions are provided: the first is based on time, 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.

[0258] 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 the transaction set. More transactions require more processing. This energy saving is particularly important when proof-of-work consensus mechanisms are used (such as Bitcoin and its derivatives), as the consensus mechanisms are computationally intensive and therefore energy intensive processes that can result in a large carbon footprint.

[0259] In the case where an event is triggered whenever a transaction is submitted to 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 submitted to the blockchain as the onEvent method) can result in an infinite loop. When the first transaction is submitted (regardless of what triggers it), the onEvent mechanism causes more transactions to be submitted to the blockchain, which in turn causes yet another event to be submitted to the blockchain, and so on ad infinitum, resulting in an infinite loop. This problem can be avoided by using a triggering mechanism as described below. Using any of the triggering mechanisms described below solves this problem.

[0260] A time-based triggering 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 over the lifetime of the event stream.

[0261] A time-based firing condition is optionally implemented using a language-level timer, for example, Timer and TimerTask in Java. Continuing with the Java example, a message creation is received with an indication that a timer-based firing 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 fire 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 fires, 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); }

[0262] 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()

[0263] Those skilled in the art will appreciate that there are more ways to establish timer-based execution than the two examples provided here, which are provided only as examples for those skilled in the art to understand possible ways to implement timer-based invocation.

[0264] Instead of or in addition to the timer-based triggering condition described above, a triggering 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; } }

[0265] Preferably, only one triggering condition is possible (either based on a timer or based on a number of events), alternatively, both triggering conditions can be used, in which case the on-chain data set is updated every time any of the triggering conditions is met.

[0266] The step of "obtaining data indicative of the state of the stream" in the above example preferably involves obtaining the latest events and a data digest (H D ) and a state digest (S). The steps of "generating a transaction comprising said data" and "broadcasting the transaction" preferably comprise, asynchronously with the above method and in a different thread, process, or device, the platform service sending a message to a message bus for the transaction to be put onto the blockchain. Preferably, these steps are the same as or similar to the generating step (526) and the submitting step (528) as discussed in FIG. 5B.

[0267] When the checkpoint or onFinalise methods are used, an optional checkpointNow flag is optionally used. The checkpointNow flag may optionally be set when a new event is received for storage to the off-chain dataset (and possibly to the on-chain dataset if appropriate triggering 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 triggering conditions are met. Because check overrides the checkpointing method to cause data to be added to the on-chain dataset, it may be considered an override flag.

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

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

[0270] Another advantageous use this technical feature may enable is to allow a stream to be resolved at a specific important time that the checkpoint method may not capture. For example, if the checkpoint method is used to add data to the on-chain dataset every day during the 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.

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

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

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

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

[0275] FIG. 12 provides a more coarse-grained schematic view of a number of services related to the blockchain, which may be implemented by a platform 1600 associated with an API through which one or more of the services offered may be accessed. As seen in this FIG. 12, 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 840 as described in FIG. 8E. Similarly, clients and / or third parties wishing to access data written using the embodiments described herein may use the data reader 1602b. Further details of the event stream are discussed with reference to FIGS. 4 to 8 of UK Patent Application No. 2002285.1 (filed 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 read service 1602b allows clients to submit queries that return data stored in the blockchain. This can be using filtered streams such that clients can pre-define the type of data they want to read from the blockchain ad-hoc or periodically, i.e., within a certain time frame, or the type of data related to related or unrelated events or documents being processed in the blockchain 1610. A data archive function allows access to logs of previous transactions for a specified event or contract.

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

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

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

[0279] device Turning now to FIG. 13, an exemplary simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems or methods shown and described above. For example, the computing device 2600 may be configured to be used as one or more components of the systems 1500, 1600 of FIG. 11 or FIG. 12, 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. As a further example, the computing device 2600 may be configured to perform the methods 520, 840 of FIG. 5B and FIG. 8E. Still further, the computing device 2600 may be configured to generate on-chain and off-chain structures 504, 502, 600, 700, 800, 820, 830, 832, 900, 902, 1000, 1050 as described in Figures 5, 6, 7, 8A-8D, 9, and 10A-10B. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 13, the computing device 2600 may include one or more processors with one or more levels of cache memory and memory controllers (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and persistent storage 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used for storage of information, such as details related to transactions and blocks as described in this disclosure.The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

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

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

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

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

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

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

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

[0287] Example illustrative application Financial Institutions In this example, a first bank, A, is using Blockchain A and a second bank, B, is using Blockchain B. Both banks are using one event stream (using the chain of transactions technology described herein) for one legal entity / individual to capture customer account activity for Anti-Money Laundering (AML) compliance. Alice is a customer with one account at each bank.

[0288] Through the use of cross-chain blockchain referencing, a single event stream (and therefore a single chain of transactions) can be used to track Alice's interactions with both institutions that can travel back and forth between blockchain A and blockchain B. This allows Alice to maintain unique event streams that simplify the management of her finances as well as improve the efficiency of auditability (e.g., for AML purposes) since all of Alice's relevant transactions with each bank are stored in a single chain of transactions and auditors do not need to investigate multiple blockchains, multiple accounts, and multiple event streams.

[0289] Document signing In this example, the goal is to capture a document signature as an event in a blockchain transaction. The signer is expected to include the event in the blockchain transaction. The entity requesting the signature (the requester) can prepare an event stream transaction that includes a commitment that specifies the blockchain transaction of the signer's choice. This allows the signer to choose any blockchain they prefer (perhaps in the event that the signer does not have a cryptocurrency and / or the means to generate transactions on the requester's blockchain). This example shows the flexibility that cross-chain referencing can provide to users of event streams and chains of transactions in general.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0306] Throughout the life of an animal, there are many moments where proof of an event (such as vaccination) is required. The chain of transactions provides a proof of existence for all events that have occurred related to said animal, including the vaccination event. Storing this proof of existence in the blockchain, as described herein, therefore provides an immutable and secure proof of existence. When a verifier wishes to determine the validity of a vaccination event, the verifier obtains the state digest and / or data digest associated with the vaccination event, as well as the vaccination event data itself. Preferably, the verifier obtains the vaccination data from the livestock database 1404.

[0307] A local data digest is obtained by hashing the vaccination data. By comparing the local data digest with the data digest stored in the blockchain, the verifier verifies that the received vaccination data is the same as that stored in the blockchain and that no tampering has occurred.

[0308] The same or similar process may be performed using a state digest based on the data digest. Verification using a state digest either requires a Merkle proof or, if the state digest is based on a concatenation of the values ​​being hashed, some or all of the other data used to generate the hash. Preferably, the Merkle proof or other data is provided by the livestock database 1404 and / or the processing platform 1406.

[0309] Note that the chain of transactions can also be used to show auditors that no events other than those presented have altered the stream and / or occurred related to the animals.

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

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

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

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

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

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

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

[0317] Reference to a numerical range disclosed herein (e.g., 1 to 10) also includes reference to all pertinent numbers within that range (e.g., 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9, and 10), and also to any range of pertinent numbers within that range (e.g., 2 to 8, 1.5 to 5.5, and 3.1 to 4.7), and thus all subranges of all ranges expressly disclosed herein are intended to be expressly disclosed herein. These are merely examples of what is specifically intended, and all possible combinations of numerical values ​​between the lowest and highest values ​​recited should be considered to be expressly set forth in this application in a similar manner.

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

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

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

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

[0322] 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, data services, computation services, commerce services, platform APIs 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 On-Chain Data Storage 504 Off-Chain Data Storage 506 Log Entries 508 Blockchain Transactions 510 Funding Entry 512 Data Payload 602 PREV 604H D ' 606 NEXT 608 Merkle Tree Root 706 Leaf Nodes 708 Leaf Nodes 710 Leaf Nodes 712 Leaf Nodes 714 Leaf Nodes 802 Transactions 804 Data Payload 806 Transactions 808 Transactions 810 Data and State Digests Reference 812 Reference 814 816 State Client Data Digest 818 Funding Entry 822 Transactions 830 Chain of Commitment 834 Transactions 900 state client data merkle tree 902 State Client Data Merkle Tree 904 Merkle Tree Root 906 Merkle Tree Root 1002 Rendezvous Transaction 1004 Output 1006 Output 1008 Output 1010 Non-rendezvous transaction 1012 Non-rendezvous transaction 1014 Non-rendezvous transaction 1016 Non-rendezvous transaction 1018 Non-rendezvous transaction 1020 Non-rendezvous transaction 1050 Transaction Data Structure 1052 Counting Branch 1402 Livestock Management Software Applications 1404 Livestock Database 1406 Processing Platform 1408 Processing Platform Members 1408 Blockchain 1410 Blockchain 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, Blockchain Network 2600 Computing Devices 2602 processor, cache memory 2604 Bus Subsystem 2606 Storage Subsystem 2608 Main memory, memory subsystem 2610 Persistent Storage, File Storage Subsystem 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem, Network Interface 2618 Dynamic Random Access Memory (DRAM), RAM 2620 Read-Only Memory (ROM) 2624 Clock

Claims

1. A computer-based method for adding a current transaction related to a set of transactions in a blockchain system, A step of generating first state data, wherein the first state data is based on a first transaction reference to a first transaction and / or a second transaction reference to a second transaction, and the first transaction reference and / or the second transaction reference are hidden from public view on the blockchain. A step of generating the current transaction comprising the first state data, A method comprising the step of submitting the current transaction to the blockchain.

2. The method according to claim 1, wherein the first transaction reference is based on the output of the first transaction, and the first transaction reference is based on the second state data of the first transaction.

3. The method according to claim 1, wherein the second transaction reference is based on a reference to the input of the second transaction, and / or the second transaction reference is based on a reference to a sender account address and a nonce.

4. The method according to claim 1, wherein the second transaction reference comprises an unconsumed transaction output point, and / or the first state data is a known state size independent of the data on which the first state data is based, and / or the current transaction is indistinguishable from any other transaction on the blockchain.

5. The method according to claim 1, wherein the first state data is based on the output of a one-way function that takes the first transaction reference and / or the second transaction reference as input, and the one-way function is a hash function.

6. The method according to claim 1, wherein the first state data is PUSHDATA encoded and / or the first state data is based on a hash-based data structure based on the first transaction reference and / or the second transaction reference, and / or the first state data is the first Merkle tree root of a state Merkle tree, the step of generating the first state data comprises the step of generating the state Merkle tree, and / or the first state data is stored in the output of the current transaction, the output being an unconsumable output.

7. The method according to claim 1, wherein the current transaction comprises a second data item, the second data item is stored in the output of the current transaction, the second data item is stored in the transaction after the OP_RETURN opcode and / or OP_0 opcode, the second data item is PUSHDATA encoded, and the second data item is based on received client data.

8. The method according to claim 7, wherein the second data item is based on the output of passing a data item based on the received client data through a one-way function at least once, the one-way function ensures that no third party can compute the client data from the second data item, the one-way function is a hash function, the client data is hidden from public view on the blockchain, the representation of the client data is immutably stored on the blockchain, the second data item provides proof of existence of the received client data, and the second data item has a known size independent of the data on which the second data item is based.

9. The method according to claim 1, wherein the current transaction belongs to a second set of transactions, a third state data is generated based on a third transaction reference and / or a fourth transaction reference, and / or the current transaction belongs to a second set of transactions, and the first state data is further based on a third transaction reference and / or a fourth transaction reference.

10. The method according to claim 1, further comprising the step of determining the second transaction reference before the second transaction is generated.

11. The method according to claim 1, wherein the first transaction reference comprises data indicating that the current transaction is the first transaction in the set of transactions, and / or the second transaction reference comprises data indicating that the current transaction is the last transaction in the set of transactions, and / or the first transaction reference is a null reference, and / or the second transaction reference is a null reference.

12. A device comprising a processor and memory, wherein the memory includes executable instructions that, as a result of execution by the processor, cause the device to perform the method according to any one of claims 1 to 11.

13. A non-temporary computer-readable storage medium comprising computer program code instructions for performing the method described in any one of claims 1 to 11, which are executable by a computer.

14. A computer program, which, when executed by a computer, includes instructions causing the computer to perform the method described in any one of claims 1 to 11.

15. The device according to claim 12, A system comprising a client device configured to output data to the device such that the representation of the output data is included in the blockchain.

Images