Attestation services used with blockchain networks

Abstract

A method, at a proving node of a network, comprising: receiving a sequence of data items from one or more client nodes of the network; determining an order for the sequence of data items; and proving the order by including an indication of a respective set of one or more of the data items in each of a series of blockchain transactions, wherein each subsequent transaction includes a respective input that points to an output of a respective preceding transaction, the output of each preceding transaction including a lock script, and the input of each subsequent transaction including an unlock script including a respective signature based on a respective key in the series of keys, wherein each signature in each subsequent transaction signs at least a portion of the respective subsequent transaction including an indication of the respective set of data items.

Description

[Technical field]

[0001] The present disclosure relates to attestation services for use with blockchain networks that propagate and mine transactions for recording on a blockchain. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. The blockchain includes a chain of data blocks, with each block containing one or more transactions. Each transaction may point to a previous transaction in a sequence that may span one or more blocks. Transactions may be submitted to the network for inclusion in a new block. New blocks are created by a process known as "mining," which involves multiple mining nodes each competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Each node in the network can play any one, two, or all three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions across the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own copy of the mined blocks of the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes of the network to which it should be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor mined into a block. Assuming the transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) remains stored in each of the nodes in the P2P network as an immutable public record.

[0004] Miners who successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction, called a "generation transaction," that generates a new amount of digital assets. Because mining a block requires significant computational resources, and blocks containing double-spend attempts are unlikely to be accepted by other nodes, proof-of-work incentivizes miners not to cheat the system by including double-spend transactions in their blocks.

[0005] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any usable output includes an element that specifies the amount of a digital asset, sometimes called a UTXO ("unspent transaction output"). The output may further include a locking script that specifies the conditions for redeeming the output. Each input includes a pointer to such output in a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and includes an unlocking script to unlock the output of the first transaction.

[0006] In such a model, when a second target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the validity criteria 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, and another is that the output of the first transaction has not yet been redeemed by another prior valid transaction. A node that finds the target transaction invalid according to any of these conditions will neither propagate it nor include it for mining into the block to be recorded in the blockchain.

[0007] Traditionally, transactions in a blockchain are used to communicate digital assets, i.e., some digital tokens. However, blockchain can also be leveraged to layer additional functionality on top of the blockchain. For example, the blockchain protocol may allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum data capacity that can be stored within a single transaction, making it possible to incorporate more complex data. For example, this can be used to store electronic documents or even audio or video data on the blockchain. Summary of the Invention

[0008] It is recognized herein that it may be beneficial to determine and record a deterministic order associated with certain data items to be recorded on the blockchain. For example, consider a use case in which a database application or the like is to be implemented on the blockchain. In this case, each data item to be recorded on the chain may represent a state change to an entry in the database or the like. However, the changes may not be commutative, i.e., order matters. For example, resetting the previous value to 0 and then adding a value is not the same as adding and then resetting. If the data items are being propagated between different nodes before being mined into a block, it may be important for certain applications that the deterministic order of the data items is properly captured.

[0009] According to one aspect disclosed herein, a method for proving an order of a sequence of data items is provided. The method includes receiving, at a proving node of a network, a sequence of data items from one or more client nodes of the network, determining an order of the sequence of data items, whereby each subsequent data item in the sequence follows a previous one of the data items in the sequence, and proving the order based on the determination. Proving is performed by including an indication of a respective set of one or more data items of the data items in each of a series of blockchain transactions, where each subsequent transaction in the series of blockchain transactions follows a respective previous transaction in the series of blockchain transactions, and the set indicated in each subsequent transaction follows the set indicated in the respective previous transaction according to the order. Each subsequent transaction includes a respective input pointing to an output of the respective previous transaction, the output of each previous transaction includes a lock script, and the input of each subsequent transaction includes an unlock script including a respective signature based on a respective key in the series of keys, and the inclusion of the respective signature is a condition for unlocking the unlock script of the respective previous transaction. Each signature in each subsequent transaction signs a portion of the respective subsequent transaction that includes at least an indication of the respective set of data items. The step of proving the order further includes transmitting the transactions to be recorded on the blockchain. [Brief description of the drawings]

[0010] To aid in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2]1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 1 is a schematic diagram of an example of a hierarchical network. [Figure 4] FIG. 2 is another schematic diagram of an example of a hierarchical network. [Diagram 5] FIG. 2 is another schematic diagram of an example of layering. [Figure 6] FIG. 2 is another schematic diagram of an example of a hierarchical network. [Figure 7] 1 illustrates a schematic diagram of an exemplary attestation service implemented in a hierarchical network; [Figure 8] FIG. 1 is a schematic transaction diagram of an exemplary transaction for recording an order of data items on a blockchain. [Figure 9] 2 illustrates a schematic diagram of an exemplary indexed list for recording the order of a set of data items within a transaction. [Figure 10] 4 illustrates generally another example of an indexed list for recording the order of a set of data items within a transaction. [Figure 11] 4 illustrates generally another example of an indexed list for recording the order of a set of data items within a transaction. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 of the blockchain network 106 includes a peer's computer equipment, with different ones of the nodes 104 belonging to different peers. Each node 104 includes one or more processors, e.g., processing units including one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (FPGAs). Each node also includes a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disk drives.

[0012] The blockchain 150 includes a chain of data blocks 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a 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 typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents the amount of digital assets belonging to a user 103 that the output is cryptographically locked (requiring that user's signature to be unlocked and thereby redeemed or used). Each input points to an output of a previous transaction 152, thereby linking the transactions.

[0013] At least some of the nodes 104 assume the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 assume the role of miners 104M, which mine blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (sometimes referred to as "full copy" nodes), each of which stores a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0014] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. Although the previous transaction 152i must exist and be validated for the current transaction to be valid, the previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106. Thus, "preceding" in this specification refers to something that precedes in the logical sequence linked by the pointer, and not necessarily to the time of creation or transmission in the time sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). The previous transaction 152i is also called the antecedent transaction or a predecessor transaction.

[0015] The input of the current transaction 152j also includes the signature of the user 103a to which the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users (one of which can be the original user 103a to give the change). In some cases, the transaction can also have multiple inputs to pool amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0016] The above may be called an "output-based" transaction protocol, sometimes called an Unspent Transaction Output (UTXO) type protocol (where the outputs are called UTXOs). A user's total balance is not defined by any one number stored in the blockchain, instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are scattered across many different transactions 152 in the blockchain 151.

[0017] When a user 103 wants to make a new transaction 152j, he sends the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P validation network 106 (which today is typically a server or a data center, but could in principle be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 in question and together form a transaction model. The node protocol typically asks the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking that the cryptographic signature of the user included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i used by the new transaction, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, the condition may be defined at least in part by a custom script included in the input and / or output. Alternatively, it may be fixed solely by the node protocol, or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards it to one or more other of the nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, and so on.In this manner, the new transaction is propagated throughout the network of nodes 104.

[0018] In an output-based model, the definition of whether a given output (e.g., UTXO) has been spent is whether it has been validly redeemed by an input of another forward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of a prior transaction 152i that it is trying to spend or redeem has not yet been spent / redeemed by another valid transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double-spending, where a spender tries to spend the same transaction output multiple times.

[0019] In addition to validation, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is backed by "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a certain predefined number of leading zeros. A property of a hash function is that it has an unpredictable output for its input. This search therefore consumes a significant amount of processing resources at each node 104M trying to solve the puzzle, since it can only be performed in a brute force manner.

[0020] The first miner node 104M to solve the puzzle publishes it to the network 106, providing its solution as a proof that can be easily checked later by other nodes 104 in the network (given the solution to the hash, it is easy to check that the output of the hash satisfies the condition). The pool 154 of transactions for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's published solution at each such node. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. Proof of work helps reduce the risk of double spends, since it takes a lot of effort to create a new block 151, and since blocks containing double spends are likely to be rejected by other nodes 104, mining nodes 104M are incentivized to avoid double spends being included in their blocks. Once created, blocks 151 cannot be modified because they are known and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on the blocks 151. As transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this provides an immutable public ledger of transactions.

[0021] Pool 154 may be referred to as a "mempool." As used herein, this term is not intended to be limited to any particular blockchain, protocol, or model. It refers to a pool of transactions that a miner accepts for mining and that the miner has committed to not accepting other transactions that attempt to use the same output.

[0022] Note that different miners 104M competing to solve the puzzle at any given time may be doing so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started searching for a solution. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. Miners 104M then continue competing to create blocks from the newly defined unprocessed pool 154, and so on. There is also a protocol to resolve any "forks" that may occur if two miners 104M solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate. In essence, whichever prong of the fork grows the longest results in a deterministic blockchain 150.

[0023] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that suddenly creates a new amount of digital assets (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). The winning node is therefore said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generating" transaction. It automatically forms part of the new block 151n. This reward incentivizes the miner 104M to participate in the proof-of-work competition. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M who created the block 151n in which the transaction was included.

[0024] Due to the computational resources involved in mining, typically at least each of the miner nodes 104M takes the form of a server including one or more physical server units or takes the form of an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0025] The memory of each node 104 stores software configured to execute on the processing unit of the node 104 to perform its respective one or more roles and process transactions 152 in accordance with the node protocol. It will be understood that any action attributed to a node 104 herein 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. Also, the term "blockchain" as used herein is a generic term generally referring to this type of technology and is not limited to any particular proprietary blockchain, protocol or service.

[0026] Also connected to the network 101 are computer equipment 102 of each of a number of parties 103 acting as consuming users. They act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and its respective computer equipment 102a, and a second party 103b and its respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may exist and participate in the system, but for convenience they are not shown. Each party 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 herein to Alice or Bob may be replaced with "first party" and "second party", respectively.

[0027] The computer equipment 102 of each party 103 includes a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 includes memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. This memory may include one or more memory units using 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 on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any action attributed to a given party 103 herein may be performed using software executed on the processing device of the respective computer equipment 102. The computer equipment 102 of each party 103 includes 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 party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0028] The client application 105 may initially be provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, 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.

[0029] The client application 105 includes at least a "wallet" functionality. It has two main functions. One of these is to allow each user party 103 to create, sign, and send transactions 152 that are propagated throughout the network of nodes 104 and thereby 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 involves reconciling the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0030] It should be noted that while various client functions may be described as being integrated into a given client application 105, this is not necessarily so and instead any client functionality described herein may instead be implemented in a suite of two or more separate applications that interface, for example, via an API or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer or a lower layer such as an operating system, or any combination thereof. The following is described with respect to client application 105, but it will be understood that this is not so limited.

[0031] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P 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 one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. Each node 104 runs software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, to forward the transactions 152 for propagation throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol proceeds with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow different subtypes of transactions therein). The same node protocol is used by all nodes 104 in the network 106 (although it may process different subtypes of transactions differently according to rules defined for the subtype, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

[0032] As mentioned, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by a proof-of-work process as described above. Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order to the blocks 151. The blockchain 150 also includes a pool 154 of valid transactions waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the originating transaction) includes a pointer back to a previous transaction to define an order to the sequence of transactions (note: it is possible for a sequence of transactions 152 to branch). The chain of blocks 151 goes all the way back to the originating 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 originating block 153, not to a preceding transaction.

[0033] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using a wallet function in Alice's client application 105) according to the relevant transaction protocol. Alice then sends the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which Alice is connected. For example, this may be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions 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.

[0034] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j adds the new validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will be propagated throughout the P2P network 106 immediately.

[0035] Once admitted to the pool 154 in the copy of the blockchain 150 maintained in one or more storage nodes 104, the miner nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of the pool 154 that contains the new transaction 152. (Other miners 104M may be trying to solve the puzzle based on an old view of the pool 154, but whoever gets there first will define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j.) Once the proof-of-work is done for the pool 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 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

[0036] Because different nodes 104 may initially receive different instances of a given transaction, they may have conflicting views of which instances are "valid" before one instance is mined into block 151, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the first unmined instance it accepted.

[0037] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 contains one or more transactions 152). In the following, it will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments.

[0038] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include 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 includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the (distributed) ledger. The UTXO may also include a transaction ID of the underlying transaction, among other information. The transaction data structure may also include a header 201 that may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In 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 that is submitted to the miner 104M.

[0039] Suppose Alice 103a wishes to create a transaction 152j that transfers an amount of the digital asset to Bob 103b. In FIG. 2, Alice’s new transaction 152j begins with “Tx 1 " which takes the amount of digital assets locked in Alice in 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 "Tx 0 " Tx 0 and Tx 1 are just arbitrary labels. They are 0 is also the first transaction in blockchain 151. 1 It does not necessarily mean that Tx is the next transaction in the pool 154. 1 can point to any preceding (i.e., prior) transaction that still has unspent outputs 203 locked to Alice.

[0040] Preceding transaction Tx 0 Alice creates a new transaction Tx 1 By the time Alice creates Tx, or at least by the time she sends it to the network 106, it may already have been validated and included in the blockchain 150. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 154, in which case it will be included in a new block 151 shortly. Alternatively, Tx 0 and Tx 1 , and send them together to the network 102, or if the node protocol allows for buffering of "orphan" transactions, Tx 0 Tx 1 A transaction may even be sent after a parent transaction. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of the transactions in a sequence defined by transaction pointers (such as which transaction points to which other transaction) specified within the transaction. They may similarly be interchanged with "preceding" and "successor," or "earlier" and "later," "parent" and "child," etc. This does not necessarily imply the order of their creation, transmission to the network 106, or arrival at any given node 104. Nevertheless, a later transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for the parent or discarded, depending on the node protocol and / or minor behavior.

[0041] Preceding transaction Tx 0One of the one or more outputs 203 of the 0 Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that an unlocking script in the input 202 of the later transaction must satisfy in order for the later transaction to be validated and therefore the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions that include a condition that an unlocking script in the input of the later transaction contains a cryptographic signature of the party to whom the prior transaction is locked.

[0042] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A lock script specifies what information is needed to use the transaction output 203, e.g., the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0043] That is, in the illustrated example, Tx 0 UTXO in output 203 0 is UTXO 0 In order for the UTXO to be redeemed (strictly speaking, 0 (For the transaction to be valid, Alice must have a signature Sig P A Requires lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice’s public-private key pair. A Includes: Tx 1 The input 202 is (for example, in the embodiment, 0 The transaction ID, TxID, which is a hash of the entire transaction 0 By)Tx 1 Contains a pointer to Tx 1 The input 202 of the Tx 0 Among any other possible outputs of 0 To identify the Tx 0 Contains an index that identifies it within Tx 1 The input 202 is an unlock script containing Alice's cryptographic signature, created by Alice applying her private key from her key pair to a given piece of data (sometimes called a "message" in cryptography). <Sig P A What data (or "message") needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0044] Depending on the implementation, the required signature may be, for example, a conventional Elliptic Curve Digital Signature Algorithm (ECDSA), Digital Signature Algorithm (DSA), or Rivest-Shamir-Adleman (RSA) signature, or any other suitable form of cryptographic signature. The challenge for the signature may be implemented, for example, as a standard pay-to-public key (P2PK) or P2PK hash (P2PKH) puzzle, or alternatives such as R-puzzles may instead be implemented as the means for the signature. This example uses P2PK as an illustration.

[0045] New transaction Tx 1When the arrives at the node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that are composed in the unlock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will be executed in the same order as Tx 0 Alice's public key P as contained in the lock script in the output of A Using Tx 1 verifies that the lock script in Tx's input contains Alice's signature, who signed the expected portion of data. The expected portion of data itself (the "message") is also used by Tx to perform this authentication. 0 In an embodiment, the signed data is included in the Tx 0 (i.e., a separate element specifying the signed portion of the plaintext data need not be included, since that is already inherently present).

[0046] The details of authentication via public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the plaintext message (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the plaintext version of 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 portion of data or part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

[0047] Hashes referenced anywhere in this specification may refer to being implemented by, for example, a Secure Hash Algorithm (SHA) hash function or a hash-based message authentication code (HMAC) hash function, or any other suitable form of cryptographic hash function known in the art.

[0048] Tx 1 The unlock script in 0 If it satisfies one or more conditions specified in the lock script of (i.e., in the illustrated example, Alice’s signature is Tx 1 If the Tx 1 is valid. If it is a mining node 104M, this means adding it to the pool 154 of transactions waiting for work-of-proofs. If it is a forwarding node 104F, it considers transaction Tx 1 to one or more other nodes 104 in the network 106 to generate a transaction Tx 1 is propagated throughout the network. Tx1 Once validated and included in the blockchain, this is called Tx 0 UTXO from 0 Define Tx as used. 1 Note that Tx can only be valid if it uses an unused transaction output 203. If you try to use an output that has already been used by another transaction 152, Tx 1 Therefore, node 104 also invalidates the preceding transaction Tx 0 has already been spent (already forms a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0049] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models, and therefore such a transaction will not be propagated to block 151 or mined.

[0050] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. You cannot "leave behind" some of the amount defined in the UTXO as spent and spend another part. However, you can split the amount from the UTXO among multiple outputs of the next transaction. For example, Tx 0 UTXOs in 0 The amount defined in is Tx 1Therefore, if Alice receives a UTXO 0 If Alice does not want to give Bob the full amount defined in Tx 1 In the second output of the second transaction, the user can give the remainder to himself or herself or pay it to another party.

[0051] In practice, today, the reward for generating transactions alone is typically not enough to incentivize mining, so Alice typically also needs to include a fee for the winning miner. If Alice does not include a fee for the miner, Tx 0 will likely be rejected by the miner nodes 104M, and therefore, even if technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force miners 104M to accept a transaction 152 if they do not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically awarded to the winning miner 104. For example, the UTXO 0 A pointer to Tx 1 is the only input to the Tx 1 One output UTXO 1 Assume that we have only UTXO. 0 The amount of digital assets specified in is UTXO 1 If the miner fee is greater than the amount specified in the UTXO 203 of the transaction 152, then the difference is automatically awarded to the winning miner 104M. However, it is not necessarily excluded that the miner fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of the transaction 152 itself.

[0052] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. No number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. This can be done by querying the copy of the blockchain 150 stored in one of the storage nodes 104S, for example the storage node 104S that is closest or best connected to each party's computer device 102.

[0053] Note that script code is often expressed diagrammatically (i.e., not in a precise language). A ] and write [Checksig P A ] = OP_DUP OP_HASH160 <H(P A)> OP_EQUALVERIFY may mean OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also called "Checksig") is a scripting opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At execution time, the occurrence of the signature ("sig") is removed from the script, but additional requirements such as a hash puzzle remain for transactions that were verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for creating an unusable output of a transaction that may store metadata within the transaction, thereby immutably recording the metadata to the blockchain 150. For example, the metadata may include a document that is desired to be stored on the blockchain.

[0054] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific portion of data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs, and all or some of the transaction outputs. The specific portion of the outputs that are signed depends on the SIGHASH flag, which is a 4-byte code included at the end of the signature to select which outputs are signed (and thus fixed at the time of signing).

[0055] A lock script is sometimes referred to as a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, any condition or conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0056] Hierarchical Network Layered network structure: A layered network is an overlay network layered on top of a communication channel. For example, the communication channel may be an underlying infrastructure network such as a personal area network, a local area network (e.g., an enterprise P2P network), or a wide area network such as the Internet. In other examples, the layered network may be a network of nodes connected via wired connections. In yet other examples, the connections may be wireless connections, e.g., Bluetooth or Wi-Fi connections. In some examples, some or all of the above exemplary connections may be used to form a layered network.

[0057] Some or all of the nodes are networks and are configured to connect (i.e., join or rejoin) the layered network according to a connection protocol. The connection protocol may vary depending on the particular layer of the network to which the connecting node is connecting (i.e., joining or rejoining). Before describing the connection protocol in detail, a set of exemplary layered networks that may be created, i.e., enforced, by the connection protocol will be described. However, it will be understood that these are merely illustrative examples and that in general any layered network that follows the connection protocol may be created.

[0058] FIG. 3 shows a schematic diagram of an example of a layered network (LN) 300. In general, an LN includes a core network (or core layer) consisting of a core node 301 and a series of layers (or shells). The core layer is also referred to as the first layer of the LN. The series of layers extend outward from the core layer, starting with a second layer consisting of second nodes 302, to one or more outer layers. Each outer layer is composed of a set of external nodes 303. Although only one outer layer is shown in FIG. 3, it will be understood that an LN may include any number of outer layers. As a specific example, an example of an LN 500 including five layers is shown in FIG. 5, and an example of an LN 600 including four layers is shown in FIG. 6.

[0059] The example LN 300 of FIG. 3 includes five core nodes 301, six second nodes 302, and eight outer nodes 303. In some LNs 300, the number of nodes may increase by layer, i.e., the core layer is composed of the smallest number of nodes and the outermost layer is composed of the largest number of nodes. In other examples, one or more of the layers between the core layer and the outermost layer may be composed of the largest number of nodes. In this example, the core layer is the innermost layer of the LN 300, the second layer is the middle layer, and the outer layer, which is the only outer layer, is the outermost layer.

[0060] The core layer (network within the LN) in this example forms a complete graph, i.e., each core node 301 is connected to every other core node 301. For a core layer of five core nodes 301, in the given example, the core layer would require 10 distinct core connections (i.e., one connection between two core nodes). In other examples (e.g., FIG. 4), the core layer would not be a complete graph. The core layer may form a "near-complete graph." In a near-complete graph, at least one core node 301 is not connected to at least one other core node 301. Only one core connection may be missing. In a particular example of a near-complete graph, each core node 301 may be connected to one or more, but not all, of the other core nodes 301.

[0061] The second layer includes second nodes 302. Note that the term "second node" is used only as a label for nodes 302 located in the second layer of the LN 300 for structural reasons. Each second node 302 is connected to at least one core node 301. In some examples, each second node 302 may be connected to only one core node 301. Alternatively, some or all of the second nodes 302 may be connected to two or more core nodes 301. For example, some or all of the second nodes 302 may connect to every single one of the core nodes 301. In the example LN 300 of FIG. 3, each core node 301 is connected to two second nodes 302. However, in this example, some second nodes 302 (those shown with striped circles) are connected to one core node 301, and some second nodes 302 (those shown with white circles and those shown with shaded circles) are connected to two core nodes 301. Second nodes 302 (and external nodes 303 in the outer layer) connected to the same core node 301 are called "communities." For example, the white nodes together form one community, the striped nodes together form one community, and the shaded nodes together form yet another community. The connections between the second nodes 302 and the core nodes 301 are called "ancestor connections" and are shown with thick dashed lines.

[0062] In the example of Figure 3, each second node 302 is connected to two other second nodes 302. In some examples, some or all of the second nodes 302 may not form connections with other second nodes, e.g., some second nodes 302 may be connected to other second nodes 302, while some second nodes may be connected to other second nodes 302. These "intra-layer" connections are shown in Figure 3 as solid lines between the nodes.

[0063] The outer layer of FIG. 3 includes the outer nodes 303. Note that the term "outer" in "outer layer" here is not necessarily limited to the outermost layer of the entire LN network, per se, but is one possibility. Each outer node 303 is connected to at least one second node 302. In some examples, each outer node 303 may be connected to only one second node 302. Alternatively, some or all of the outer nodes 303 may be connected to two or more second nodes 302. For example, some or all of the outer nodes 303 may be connected to every one of the second nodes 301. In the example LN 300 of FIG. 3, each outer node 303 is connected to two second nodes 302. Some of the second nodes 302 (i.e., the striped nodes) are connected to two external nodes 303, and some of the second nodes 302 (i.e., the white nodes and the shaded nodes) are connected to three external nodes 303.

[0064] 3, each external node 303 is connected to two other external nodes 303 in the same tier. In some examples, some or all of the external nodes 303 may not form connections with other external nodes 303 in the same tier. Some or all of the external nodes 303 may form at least one connection with another external node 303 in the same tier.

[0065] Along with being connected to at least one second node 302, each external node 303 is also connected to at least one core node 301. The connections between the external nodes 303 and the core nodes 301 are called "core ancestor connections" and are shown by thin dashed lines. Each external node 303 may be connected to each of the core nodes 301 to which their ancestral second node(s) 302 are connected. As shown in FIG. 3, each external node 303 may be connected to each of the core nodes 301 to which their ancestral second node(s) 302 are connected, and would not be connected to other core nodes 301. In this case, each external node 303 belongs to a single community.

[0066] FIG. 4 shows a schematic diagram of another example of an LN 400. Similar to the LN 300 of FIG. 3, the exemplary LN 400 includes a core layer, a second layer, and an outer layer. These exemplary LNs 300, 400 share the same number of nodes (i.e., five core nodes 301, six second nodes 302, and eight outer nodes 303), but include different numbers of connections. For example, in this example, the core layer is not a complete graph because some connections between the core nodes 301 are absent. Another difference is that two communities (white and shaded nodes) include a single core node 301, whereas another community (shaded nodes) includes three core nodes 301. Yet another difference is that unlike the degree of the nodes in the outer shell of LN 300, which is two, the degree of the nodes in the outer shell of LN 400 is now one. That is, in this exemplary LN 400, each outer node 303 is connected to a single other outer node 303. Therefore, the nodes in different layers have different degrees.

[0067] FIG. 5 shows a schematic diagram of another example of an LN 500. In this example, only some core nodes 301 are connected to second nodes and external nodes 303. That is, in this example, some core nodes 301 form connections only with other core nodes 301. Thus, in this example, the LN 500 includes a single community (shaded nodes). The LN 500 in this example includes five layers: a core layer, a second layer, and three outer layers. The core layer is composed of five core nodes 301 that form a nearly complete graph. In this example of a nearly complete graph, only a single core connection is missing. The second layer is composed of a single second node 302 connected to two core nodes 301. The second layer is composed of a single second node 302 connected to two core nodes 301. The third layer is composed of a single external node 303 that is connected to the second node 302 via an ancestor connection. The third tier external node 303 is also connected to two core nodes 301 to which the second node 302 is connected. The external node 303 is connected to the two core nodes 301 via respective core ancestor connections. The fourth tier is also composed of a single external node 304. The fourth tier external node 304 is connected to the third tier external node 303 via an ancestor connection, and to the second node 302 via an ancestor connection. The fourth tier external node 304 is also connected to two core nodes 301 to which the second node 302 and the third tier external node 303 are connected. The external node 304 is connected to the two core nodes 301 via respective core ancestor connections. Finally, the fifth tier is composed of two external nodes 305. The two external nodes 305 in the fifth tier are connected to the fourth tier external node 304, to the third tier external node 303, and to the second node 302, with each connection being an ancestor connection. The two external nodes 305 are also connected to the two core nodes 301 via core ancestor connections. In this exemplary LN 500, the nodes in the second tier and the nodes in the outer tier are not connected to any other nodes in the same tier.

[0068] FIG. 6 shows a schematic diagram of another example of an LN 600. This LN includes two communities of nodes, as indicated by the white and black nodes. In this example, the core layer forms a complete graph (i.e., a network of nodes). Each community includes a separate set of three core nodes 301. This example LN 600 includes four layers: a core layer, a second layer, and two outer layers. Each node in the outer layers is connected to one node in the preceding layer. As with the example LN 500 of FIG. 5, the nodes in the second layer and the outer layers are not connected to any other nodes in the same layer.

[0069] In some embodiments, the LN 300, 400, 500, 600 (hereinafter simply referred to as “300”) may be a “blockchain hierarchical network (BLN).” The term BLN is defined herein as a blockchain network or a hierarchical network that includes at least a portion of a blockchain network, such as the blockchain network 106 described with reference to FIG. 1.

[0070] The BLN is inspired by the Mandala network and shares some similar characteristics, but is designed to enable a more flexible and desirable connection structure for services and user networks that utilize the blockchain network 106, for example.

[0071] The BLN 300 may include at least a portion of a blockchain network 106 at its core. Typically, the nodes of the hierarchical network are overlaid on an underlying infrastructure network, such as the Internet 101. Some or all of the core nodes are nodes 104 of the blockchain network 106. They may include mining nodes 104M, storage nodes 104S, or a combination thereof. In an embodiment, each of the core nodes is a mining node 104M and / or a storage node 104S (e.g., a full-copy node).

[0072] Each of the external nodes 303 (or each of the outermost external nodes) may be an end-user node including a user's computer equipment. This may be an individual user or an organization such as a company, an academic institution, or a government agency. Thus, each external node 303 may include one or more user terminals and / or a server including one or more server units at one or more sites. Each external node 303 comprises a memory including one or more memory units and a processing device including one or more processing units. These may take any of the forms of memory media and / or processors, for example, as described above in connection with other network elements or user equipment. The memory stores client software configured to be executed on the processing device, the client software being configured, when executed, to cause the node to operate as a client of a protocol that follows a connection protocol according to any of the following embodiments or similar. Optionally, one or more of the end-user nodes may include a user equipment 103 of a user 102 of the blockchain network 106, and the client software may include a blockchain wallet application 105 or the like.

[0073] Each second node 302 may take the form of a server including one or more physical server units. Each such node comprises a memory including one or more memory units and a processing device including one or more processing units. These may take any of the forms of a memory medium and / or a processor, for example as described above in relation to the other network elements. The memory stores software configured to be run on the processing device of the second node 302. The software, when executed, is configured to follow a connection protocol according to any of the following embodiments or similar. In some embodiments, the software, when executed, is configured to provide a service operating according to any of the embodiments described below or similar.

[0074] In some examples, some or all of the second nodes 302 may operate a smart contract service. The smart contract service is configured to perform certain operations in response to and based on a blockchain transaction sent to the smart contract service by one of the other nodes of the LN 300, e.g., by the external node 303. For example, the smart contract may send a blockchain transaction to the core node 301 in response to receiving a particular blockchain transaction from the external node 303.

[0075] In another example, some or all of the second nodes 302 may operate a distributed database between them. That is, each second node 302 operating a distributed database is configured to store data received from another node of the LN 300, such as an external node 303. A second node 302 that receives and stores data may be configured to propagate the data to other second nodes 302 that are also operating a distributed database.

[0076] The nodes 301, 302, 303 are configured to form connections between each other at the overlay network level. That is, the nodes 301, 302, 303 of the hierarchical network are configured to follow an overlay network protocol that specifies what connections they can and cannot form with other nodes 301, 302, 303 of the hierarchical network. Thus, although all nodes can (but do not necessarily) physically connect to each other via the underlying infrastructure (e.g., the Internet), the connections between such nodes 301, 302, 303 may be more restricted when they participate as nodes 301, 302, 303 of a hierarchical network operating according to the relevant overlay network protocol of the hierarchical network 300. A connection between two nodes 301, 302, 303 of the hierarchical network 300 means that these nodes can communicate directly, which in this context means that there is no need to perform a hop through another node 301, 302, 303 of the hierarchical network 300. In the context of an overlay network, such as a layered network, a "connection" refers to a connection (ie, an edge) at the level of the layered network 300 (ie, at the level of the overlay network protocol of the layered network).

[0077] In an embodiment where the LN 300 is a BLN, some or all of the second nodes 302 may be configured to transmit blockchain transactions to the core node 301 to which those second nodes 302 are connected. In some examples, the second nodes 302 may generate blockchain transactions and then transmit the blockchain transactions to the core node(s) 301. In other examples, the second nodes 302 may forward the blockchain transactions to the core node(s) 301. For example, the second nodes 302 may receive blockchain transactions from the external node 303 and then transmit the received blockchain transactions to the core node(s) 301. Similarly, a given second node 302 (i.e., some or all of the second nodes) may be configured to obtain blockchain transactions from the core node(s) 301 and / or the external node(s) 303 connected to the given second node 302.

[0078] Additionally or alternatively, some or all of the external nodes 303 may be configured to send blockchain transactions to the core node(s) 301 to which they are connected. The external nodes 303 may also be configured to send blockchain transactions to the second node(s) 302 to which they are connected. In some examples, the external nodes 303 may send blockchain transactions to the second node 302 and then to the core node 301.

[0079] Some or all of the external nodes 303 may be configured to send blockchain transactions to other external nodes 303, e.g., external nodes in the same tier or external nodes in a previous or next tier in an ordered set of tiers.

[0080] In an embodiment in which the core nodes 301 of the BLN 300 each act as a blockchain node 104, some or all of the second nodes 302 and / or external nodes 303 may be configured to request confirmation that a given transaction has been accepted in the pool of transactions of the mining node 104M to which the given second node 302 or external node 303 is connected. The pool 154 (sometimes called a mempool) contains transactions that have been validated according to a set of consensus rules of the blockchain network 106. If a transaction (e.g., a "first transaction") is included in the pool 154, the mining node 104M will not accept another transaction (e.g., a "second transaction") that attempts to double-spend an output referenced by an input of the first transaction. Thus, the second node 302 and / or the external node 303 can query the core node 301 to check that a transaction (e.g., a transaction submitted to the blockchain network 106 by a node 302, 303) has been accepted or to check whether a transaction (e.g., a transaction received from another node in the BLN 300) is a double spend attempt. The core node 301 is configured to send a response to the request to the requesting node 302, 303.

[0081] Additionally or alternatively, the second node 302 and / or the third node 303 may be configured to send a request to the core node 301 for a Merkle proof of a transaction mined in block 151 of the blockchain 150. Merkle proofs are well known to those skilled in the art. A Merkle proof is a sequence of hashes that trace back to a Merkle root. To verify whether a transaction was mined in block 151, the node 302, 303 takes the transaction's hash, concatenates it with the first hash in the sequence of hashes of the Merkle proof (i.e., the hash partner of the Merkle tree at the same level as the transaction's hash), and hashes the result. This process of concatenation and hashing is repeated until all of the hashes in the Merkle proof are utilized. If the resulting hash is identical to the Merkle root, the transaction must be included in the Merkle tree and therefore in block 151. The core node 301 is configured to send the Merkle proof to the requesting node 302, 303.

[0082] Additionally or alternatively, the second node 302 and / or the third node 303 may be configured to send a request to the core node 301 for a block header of a given block 151. Among other data, the block header contains the Merkle root of the transactions mined into that block 151. The core node 301 is configured to send a Merkle proof to the requesting nodes 302, 303.

[0083] In some embodiments, some or all of the core nodes 301 may be configured to send a set of transactions to some or all of the second node(s) 302 and / or some or all of the external node(s) connected to the core node 301. The transactions in the set may share a common attribute. For example, the core node 301 may send all transactions that include a particular protocol flag. The flag may be included in the output of the transaction, e.g., an unusable output. As another example, the transactions may include a particular (and same) blockchain address, e.g., the transactions may be payable to the same blockchain address. The external node 303 will have agreed with the core node 301 that the core node 301 will send any transaction payable to an address associated with the external node 303. As yet another example, the transaction may include a secondary consensus rule set. That is, the transaction may include two or more control branches in the output, each control branch specific to a respective consensus rule set. The output may include a first control branch specific to the first rule set and a second control branch specific to the second rule set (the two control branches may be included in an if-else condition). If the nodes 302, 303 are configured to implement the second rule set, the core node 301 may send the transaction to the nodes 302, 303. If the nodes 302, 303 are not configured to implement either the first or second rule set, the core node does not send the transaction to the nodes 302, 303.

[0084] A core node 301 that is a mining node 104M may include an identifier (e.g., a "Miner ID") unique to that mining node 104M in the originating transaction (also called a "coinbase" transaction) mined by that mining node 104M into a block 151. Other nodes in the BLN 300 may use the identifier to identify the mining node 104M on the network.

[0085] Another way to identify the nodes 301, 302, 303 of the LN 300 is by digital certificates. Some or all of the nodes 301, 302, 303 may be associated with digital certificates. The digital certificate includes and certifies the respective node's identifier, such as a public key associated with the node, the node's network address (e.g., IP address), etc. A node of the LN 300 may use a different node's digital certificate to connect to that node. For example, an external node 303 may obtain a digital certificate from a second node 302 and connect to the second node 302 using the second node's identification information contained in the digital certificate.

[0086] A node in a given tier may issue a digital certificate to a node in the next tier in the ordered set of tiers, i.e., core node 301 may issue a digital certificate to second node 302, which may issue a digital certificate to external node 303 in the first outer tier, and so on. In some examples, a node in a given tier may issue digital certificates to nodes in the same tier, e.g., second node 302 may issue a respective digital certificate to one or more other second nodes 302.

[0087] Connection Protocol: As mentioned above, each node connecting to the hierarchical network 300 may connect according to a connection protocol. That is, the connecting node must follow the rules of the connection protocol. The connecting node may only form connections that are permitted by the connection protocol. Other connections will not be formed. In examples, the connecting node may be a core node 301, a second node 302, or an external node 303. In some examples, each node of the LN 300 must follow the connection protocol. In other examples, only a node connecting to the LN 300 for the first time or a node rejoining the LN 300 must follow the connection protocol. Figures 3-6 show exemplary LNs 300, 400, 500, 600 established according to a connection protocol.

[0088] It should be noted that, physically speaking, each of the nodes of LN300 may be connected or capable of connecting with one another at some other level, for example, via the Internet, in some examples. The connection protocol imposes restrictions on which connections can be formed at the level of the overlay network, i.e., at the level of the layered network, and some connections do not exist or are not permitted. Each connecting node of LN300 is configured to operate according to the overlay level protocol (including the connection protocol) of LN300, which determines which connections a node can and cannot form at the overlay level. In other words, a connection is an permitted communication channel that two nodes are configured to be able to form by their protocols. If a node has a connection with another node, it can communicate with that node without hopping through another node of the layered network, but otherwise it cannot communicate and can only communicate by hopping through one or more other nodes that have a connection between them.

[0089] The connection protocol requires that the connecting node connects to at least one node in a preceding (inner) tier and to at least one core node, except in some instances where the core node cannot connect to a preceding tier because the core node may be the innermost tier. In instances where the connecting node is a second node, these two requirements are equivalent. If the connecting node is an external node in the first outer tier, the connecting node connects to at least the second node 302 and the core node 301.

[0090] The connection protocol may require an access node to connect to two or more core nodes. The connection protocol may further require an access node to connect to two or more but not all of the core nodes, e.g., all but one of the core nodes. The access node may be a second node that must connect to two or more core nodes. That is, some or all of the second nodes must connect to two or more core nodes (in some examples, but not all core nodes).

[0091] A connection protocol may require a connecting node to connect to one or more second nodes. If the connecting node is a second node, this means that the connecting (second) node must connect to one or more different second nodes. If the connecting node is an external node, the connecting (external) node must connect to one or more second nodes. The connecting external node may be an external node of the first outer layer, or an external node of the second layer, etc.

[0092] The connection protocol may require that an external node connected to a node in a preceding tier must connect to some or all of the core node(s) to which the node in the preceding tier is connected (referred to above as "core ancestors"). For example, an external node may be connected to a second node. In that case, the external node must also connect to the core node(s) to which the second node is connected. If an external node is connected to more than one second node, the connection protocol may require that the external node must connect to the core node(s) to which each of the second nodes is connected. As another example, an external node in a second outer tier may be connected to an external node in a first outer tier. In that example, the connection protocol requires that the external node in the second outer tier must connect to the core node(s) to which the external node in the first outer tier is connected.

[0093] The connection protocol may require that an external node connect to one or more (e.g., two) external nodes in the same outer tier. The connection protocol may require that each external node connect to one or more external nodes in the same tier. Alternatively, some outer tiers may include external nodes that form one or more same-tier connections, and some outer tiers may include external nodes that do not form one or more same-tier connections. The connection protocol may require that each external node in the same outer tier must connect to the same number of different external nodes in that tier. For example, each external node in a first outer tier may be required to connect to two external nodes. Each external node in a second outer tier may be required to connect to three external nodes. That is, the number of external nodes in the same tier to which an external node is connected may vary between outer tiers.

[0094] In some embodiments, an external node in the ith outer layer (e.g., the third outer layer) may be connected to an external node in the preceding (i-1)th layer (e.g., the second outer layer). The connection protocol may require that an external node in the subsequent (i+1)th outer layer (e.g., all external nodes) must connect to each node in the (i-1)th layer to which the external node in the ith outer layer is connected. For example, the external node 305 in the fifth layer in the LN 500 of FIG. 5 is connected to an external node 304 in the fourth layer, and to an external node 303 in the third layer. In some examples, the connection protocol may require that the (i+1)th outer layer must connect to each external node in each preceding layer to which the external node in the ith outer layer is connected.

[0095] In embodiments in which some or all of the nodes of LN300 are associated with digital certificates, the connection protocol may require that the connecting node must only connect to a node associated with the node associated with the respective digital certificate. In some embodiments, the connection protocol may require that the connecting node (e.g., an external node) must only connect to a respective node (e.g., a second node) if the digital certificate associated with the respective node was issued by a node in a tier preceding the respective node (e.g., a core node) or, in some examples, by a node in the same tier of the respective node (e.g., a different second node).

[0096] In some embodiments, the connection protocol may require that an accessing node can only connect to nodes that have issued the accessing node a digital certificate, i.e., connecting to a node includes receiving a digital certificate from that node.

[0097] The connection protocol allows the construction of the BLN. Similar to the Mandala network, the BLN is constructed in layers. Unlike the Mandala network, the first layer may form an incomplete graph (e.g., a nearly complete graph). Other differences between the BLN and the Mandala network are that in the BLN, the nodes in each subsequent layer may have different degrees, a node may be connected to two or more nodes in the middle layer, and / or the degree of a node may vary between layers.

[0098] Preferably, for all nodes outside the central core: (i) Each node is assigned to n nodes in the central core. 1 It is connected to m of the nodes. (ii) Each node is connected to nodes in all layers, where g is the total number of layers. (iii) Each node is a member of exactly one community. At most n 2 There are n communities, where 2 is the number of nodes in the second layer. (iv) Every node is connected to every other node with at most three hops, which is called the diameter of the graph.

[0099] In BLN, a "community" is defined as a set of nodes that share the exact same set of core ancestors. Figure 6 shows a network n 1 Figure 1 shows a BLN with θ = 6, m = 3, and g = 4, depicting two distinct communities of nodes: the black node community and the white node community. The white node community includes nodes that are all connected to three nodes on the LHS of the central core, and the black node community includes nodes that are all connected to three nodes on the RHS of the central core.

[0100] A characteristic of the Mandala network is that every node outside the core layer (i=1) is connected to exactly one core ancestor (i.e., everywhere c i= 1). This contributes greatly to the emergent properties of Mandala networks. Network size (N=Σ i n i ) has an average shortest path length that asymptotically approaches a constant as . Network size (N=Σ i n i ) becomes very sparse as it gets larger. · It is robust against random node failures.

[0101] A characteristic of a BLN is that every non-core node connects to at least one ancestor. However, the definition of a BLN corresponds to a non-core node having at most m connections to a core ancestor (i.e., wherever 1 ≤ c i ≦m). c across the BLN i = 1 to 1 ≤ c i The reason for the generalization to ≦m can be understood as an artifact of the blockchain protocol. The protocols that define a blockchain system rely on a probabilistic security model. In essence, this means that any participant (node) in the BLN that has a vested interest in having events recorded on the blockchain 150 must take the probabilistic security model into account by connecting to a minimum percentage f of the network hash power, where 100% of the total hash power is distributed among the nodes in the core layer of the BLN.

[0102] The core layer is 1 Assuming a uniform equilibrium distribution of hash power among the core nodes, the minimum percentage of nodes is: f=m / n 1

[0103] The blockchain protocol implies a lower bound on the minimum ratio of f=0.51, but network participants in larger BLNs may require a higher ratio (e.g., f=0.67) to provide increased resistance (e.g., to double-spending). A BLN may be characterized by the choice of parameter m, which specifies the probabilistic security of operations for participants in the BLN, depending on the particular use case the BLN needs.

[0104] The second layer, L, closest to the core 2 Nodes in the L layer rely most heavily on the probabilistic security model of the blockchain protocol, and this dependency is due to the fact that the layer g The connection protocol is strictly c 2 L = m core ancestors connected to 2 while all subsequent nodes in layer i>2 have a core ancestral range 1< <c i ≦m. In some instances, all subsequent layer nodes must connect to m core ancestors.

[0105] Nodes outside the central core of the BLN may have "SPV-like" connections to the core, which means that they can: a) Send the transaction to a core node. b) Ask a core node if the transaction was accepted in that mempool / candidate block. c) Obtain a Merkle proof of the transactions mined in the block. d) Find the latest list of block headers.

[0106] These simple targeted requests are designed to place as little burden as possible on the core node 301 while allowing the widest possible range of scalable solutions to be built on top of using the BLN. Many use cases only require the types of connections described above. In some instances, the second node 302 and / or the external node 303 are configured to be able to perform only actions a)-d) above. However, other solutions, typically at the enterprise level, may ask the core to proactively submit more data, such as transactions that meet certain criteria. Thus, actions a)-d) are the minimum requirements for the BLN, although in some instances additional data transfer between those nodes and the core is also possible.

[0107] For nodes running smart contracts, some may only require SPV-like actions a)-d), while others may require agreement to receive more data from the core nodes.

[0108] In some BLNs, users can run tier 3 or higher nodes, and smart contracts can be run by tier 2 or higher nodes. A user cannot realistically "listen" to the blockchain continuously for transactions with a specific output address, since this would require constantly monitoring the blockchain 150 for transactions involving the specific address. Given the ever-increasing number of transactions that can be sent to the blockchain per period, such constant monitoring is not practical for end users. While constantly monitoring the blockchain is common among some blockchain wallet architectures, it is not a scalable solution, given that both the number of transactions submitted to the blockchain per period and the number of users of the blockchain are expected to increase dramatically in the future. Consider the following example: Alice wants to make a payment to Bob. Alice creates a transaction for the desired amount with an output address that Alice knows belongs to Bob. Alice then submits this transaction to the mining network rather than submitting it directly to Bob. In order for Bob to know that his transaction has been accepted, he must "listen" to the blockchain to see if and when a transaction with his output address has appeared on the network. Bob must ask a mining node to do this on his behalf. This means that the mining node must keep a record of Bob's address and check if every transaction it receives matches this address. Note that there is no economic incentive for miners to do this. If we assume that a miner has to process 1 million transactions per second and check if they match 1 million addresses, we can see that this quickly becomes impractical.

[0109] Instead, in the BLN, Alice can be directly connected to Bob and can send transactions directly to Bob. Bob can then send the transaction to the miners in the core and ask if they accept it as valid. Since the transaction includes the miner's fee, the miners are incentivized to accept the transaction and to check if they accept it to lower the risk of building a block that will be abandoned. To make the system even more secure, Alice can send Bob Merkle proofs of Alice's inputs to the transaction. Since Bob has a copy of the block header, he can check these Merkle proofs. This assures Bob that Alice's inputs were part of the blockchain 150 at some point, and if Alice has already used them, Bob will have a proof of double spending since he has received a signature from Alice on the transaction that Alice gave to Bob. Note that Bob can be a smart contract (second node) and Alice can be a user (external node) who wants to interact with the smart contract. If the smart contract is “lite” in the sense that the smart contract operator has not made any specific agreements with mining nodes to facilitate the processing of the smart contract, it also cannot rely on listening to the blockchain 150 to receive transactions that trigger state changes: Alice must send such transactions directly to the smart contract.

[0110] A service provider may operate a node at tier 2 or higher. The case of a service provider is different from that of a user or a light smart contract. A service provider may have a commercial agreement with a core mining node or a set of core nodes, which then propagate a certain subset of transactions to the service provider node. Such transactions should be easily identifiable and meet certain criteria, for example: OP_RETURN data with specific protocol flags, such as the Metanet protocol, the tokenization protocol, or the digital certificate protocol. Output addresses match a small, specific set, e.g., an enterprise-level smart contract or address whitelist / blacklist. A secondary consensus rule set, indicated by the OP_VER control branch.

[0111] Additionally, transactions sent to the core that follow these rules or are otherwise identified as part of a community that participates in a service level agreement may have lower (or even zero) transaction fees. Any shortfall may be made up by higher transaction volume or by fiat revenue from the service level agreement.

[0112] All nodes in the BLN 300 may be associated with a semi-permanent public key associated with their identity that allows for secure communications and can provide a link to the public keys used in blockchain transactions through deterministic derivation of an identity key or by using the identity key to sign or encrypt a transaction key.

[0113] There are two ways to identify a mining core node: 1) Miner ID. A miner may choose to reveal itself by adding its identity key to the input of the coinbase transaction in each block that the miner mines. 2) Network analysis. Some miners choose to remain anonymous. However, it is still possible to identify which nodes compose blocks by analyzing the network, for example by looking at where new blocks come from.

[0114] It is important that BLN nodes are able to distinguish between both types of miners and therefore be able to poll as many miners as possible as to whether their transactions have been accepted.

[0115] Core nodes with Miner IDs can issue digital certificates to tier 2 nodes. This could be because they have a service level agreement with these nodes, or because these nodes have requested the certificates for a fee. In this sense, core nodes can act as a Certificate Authority (CA).

[0116] With or without a certificate from a core node, tier 2 nodes may ask an external CA to issue them a digital certificate. Thus, each tier 2 node may have at least one digital certificate proving their identity. They may issue certificates to other nodes in tier 2, thereby creating a web of trust between them. Nodes in tier 2 may issue certificates to nodes in tier 3, which may issue certificates to nodes in tier 4, and so on, creating a hierarchy of certificates called a public key infrastructure (PKI).

[0117] Indeed, such a PKI may be used not only for the identification of nodes in the BLN, but also to ensure that the correct BLN structure is followed: for example, a tier 3 node's certificate may be revoked if it issues certificates to too many tier 4 nodes, or if it does not ensure that it has proper connections to other nodes in the system.

[0118] These certificates themselves can be stored on the blockchain 150, making the PKI transparent and easily auditable.

[0119] Ordering and Timestamping There may be a number of applications that can be implemented using blockchain where the order of application data is important. To address this, according to embodiments of the present disclosure, one or more nodes of the network may be configured to act as a proof service that arbitrates between different data items submitted to the service to determine a deterministic order of the data items and then has that order immutably recorded on the blockchain.

[0120] The attestation service is implemented in one or more attestation nodes. In an embodiment, these are nodes of an overlay network overlaid on an underlying infrastructure network such as the Internet. However, it is not excluded that alternatively they could be infrastructure nodes of their own network, for example a private network within an organization. In any case, the one or more attestation nodes are configured to receive data items from one or more client nodes, form transactions that record the order of the received data items, and forward these transactions to one or more core nodes for recording in the blockchain 150. The core nodes are nodes 104 of the blockchain network 106. They may include mining nodes 104M, storage nodes 104S, or a combination thereof. In an embodiment, each of the core nodes is a mining node 104M and / or a storage node 104S (e.g., a full copy node).

[0121] Each of the client nodes may be an end-user node including a computer device of a user of the service. This may be an individual user or an organization such as a company, an academic institution, or a government agency. Thus, each client node may include one or more user terminals and / or a server including one or more server units at one or more sites. Each client node comprises a memory including one or more memory units and a processing device including one or more processing units. These may take any of the forms of a memory medium and / or a processor, for example, as described above in connection with other network elements or user equipment. The memory stores client software configured to be executed on the processing device, which, when executed, is configured to operate the node as a client of the attestation service provided by the attestation node(s) according to any of the following embodiments or similar. Optionally, one or more of the sending end-user nodes may include a user device 103 of a user 102 of the blockchain network 106, and the client software may include a blockchain wallet application 105 or the like. However, the attestation service may be configured to formulate at least some transactions on behalf of such end-users, and not necessarily all such transactions are formulated in the user's wallet 105.

[0122] The attestation nodes are configured to provide an attestation service that mediates between client nodes and core nodes. Each attestation node may take the form of a server including one or more physical server units. Each such node comprises a memory including one or more memory units and a processing device including one or more processing units. These may take any of the forms of memory media and / or processors, for example as described above in relation to other network elements. The memory stores attestation service software configured to run on the processing device of the attestation node. The software, when executed, is configured to provide an attestation service that operates according to any of the embodiments described below or similar. In an embodiment, the identity of each attestation node may be attested by a certificate authority such that client nodes, core nodes, and / or other attestation service nodes may verify the identity of the attestation node. The identity of each client node may be attested by a certificate authority such that the attestation service node, core nodes, and / or other client nodes may verify the identity of the client node. Interaction between such nodes to provide or use the attestation service may be subject to verification. Alternatively or additionally, node versioning may be used as an alternative mechanism for node identification in an overlay network.

[0123] In an embodiment, the above configuration may be implemented in the form of a layered network 700, such as the type described in connection with Figures 3-6 and also shown in Figure 7 by way of example. That is, the layered network includes a core network including a core node 701, at least one intermediate layer around the core, each intermediate layer including one or more intermediate layer nodes 702, and at least one outer layer around the outermost intermediate layer, each outer layer including one or more outer layer nodes 703. It should be noted that the term "outer" in "outer layer" here is not necessarily limited to the outermost layer of the overall layered network 700, per se, but is one possibility. In an embodiment, the hierarchical network 700 of FIG. 7 may be the hierarchical network 300 of FIG. 3, in which case the outer tier nodes of FIG. 7 may be the third tier nodes of FIG. 3 or FIG. 4, the middle tier nodes 702 of FIG. 7 may be the second tier nodes 302 of FIG. 3 or FIG. 4, and the core node 701 of FIG. 7 may be the core node 301 of FIG. 3 or FIG. 4.

[0124] As discussed in relation to Figures 3-6, the hierarchical network 700 may be an overlay network that is overlaid on an underlying physical or infrastructure network, such as the Internet. In such an embodiment, the nodes 701, 702, 703 are configured to form connections between each other at the overlay network level. That is, the nodes 701, 702, 703 of the hierarchical network are configured to comply with an overlay network protocol that specifies what connections they can and cannot form with other nodes 701, 702, 703 of the hierarchical network. Thus, while all nodes may be capable of physically connecting to each other via the underlying infrastructure (e.g., the Internet), the connections between such nodes 701, 702, 703 may be more restricted when they participate as nodes 701, 702, 703 of the hierarchical network operating in accordance with the hierarchical network's 700 associated overlay network protocol. A connection between two nodes 701 / 702 / 703 of a layered network 700 means that these nodes can communicate directly, which in this context means that there is no need to perform a hop through another node 701 / 702 / 703 of the layered network 700. In the context of an overlay network, "connection" means a connection (i.e., an edge) at the level of the overlay network (i.e., at the level of the overlay network protocol of the layered network).

[0125] Each intermediate tier node 702 is connected to at least one core node 701 (blockchain network node 104) in a core network. The core network includes at least a portion of the blockchain network 106. In embodiments, the core network may be a complete network in itself.

[0126] In some cases, some of the middle tier nodes 702 and / or outer tier nodes 703 may include peripheral nodes 104 of the blockchain network 106, such as forwarding nodes 104F, other than mining nodes 104M and / or storage nodes 104S. Alternatively, they may include nodes that do not have any role (mining, storing, or forwarding) in the blockchain network 106 other than as clients of the blockchain network 106.

[0127] Each outer tier node 703 is connected to at least one of the middle tier nodes in at least one middle tier. In an embodiment, each outer tier node 703 also has at least one connection to at least one core node 701 (i.e., to the blockchain network 106). In some such embodiments, one or more of the outer tier nodes 703 each have connections to two or more, but not all, of the core nodes 701. In an embodiment, the hierarchical network 700 as a whole may be a non-complete network, i.e., not all nodes 701, 702, 703 have connections to all others at the overlay network level. In an embodiment, each node in a given tier may be connected to at least one other node in the same tier. For example, each node 702 in a middle tier may be connected to one or more other nodes in the same middle tier, and / or each node 703 in an outer tier may be connected to one or more other nodes in the same outer tier. In an embodiment, connections may also be formed between different middle layer nodes 702 in different middle layers and / or between different outer layer nodes 703 in different outer layers.

[0128] In an embodiment, the hierarchical network 700 may be configured according to any of the protocol rules or structural features described in connection with Figures 3-6, where each intermediate tier of intermediate nodes 702 is a tier between the core and the outermost tier, and each outer tier of external nodes 703 is a tier outside a second tier (where the intermediate tier(s) are between the core and the outer tier(s)).

[0129] While the following embodiments are illustrated in the context of a hierarchical network, it will be understood that this is not a limitation and more generally, the attestation node(s) may be any node of any type of overlay network that mediates between one or more client nodes and one or more core nodes 104 of the blockchain network 106.

[0130] In the implementation of the hierarchical network 700, at least one of the intermediate nodes 702 in at least one intermediate tier plays the role of a proof node 702A that provides proof services. At least one of the external nodes 703 in the outer tier in at least one outer tier is a client node 703C of the proof services provided by the proof node(s) 702A. Each core node 701 is one of the nodes 104 of the blockchain network 106, preferably a miner 104M and / or a storage node 104S (e.g., a full copy node). For ease of explanation, only two client nodes 703C and two proof nodes 702A are shown in FIG. 7, but it will be understood that there may be more. In an embodiment, the client node 703C and the proof node 702A may be part of the same community as each other.

[0131] The client nodes 703C are clients at least in that they are clients of the attestation service. In an embodiment, the client software running on one or more of the client nodes 703C may be further configured to operate the node 703C as a client of one or more additional services provided by one or more second tier nodes 702, such as a database service or a smart contract service, and / or to operate the node 703C as a client of one or more core nodes 701 (e.g., 104M, 104S) of the blockchain network 106 so that the blockchain 150 can be queried.

[0132] Also, the fact that the client nodes 703C are described as clients of the attestation service (and optionally one or more other services) does not exclude the possibility that these nodes may themselves also be servers of one or more further services to one or more further entities (not shown). For example, the client nodes 703C may include computer equipment of a company that provides online services to customers. An "end user" is used herein to mean an end user of the particular service in question, and is not necessarily limited to an individual consumer at the end of a commercial supply chain (although that is certainly one possibility).

[0133] The following describes how the ordering service entity 702A may use the blockchain 150 to record the time and ordering at which data elements were received from one or more client nodes 703C. Optionally, the ordering service may also perform time stamping.

[0134] We first describe the method for a single trusted order proof node 702A, which can be modeled as a single middle-tier (e.g., second tier) node in a layered network 700 with a core of blockchain network nodes 104 / 701. In this case, users of the service can be users of outer-tier (e.g., third tier) nodes 703C that are directly connected to the service 702A and optionally also connected to the blockchain 150 (by a connection to at least one core node 701 in the core).

[0135] As data elements are received from outer tier client nodes 703C, the mid-tier timestamping service 702A collects them so that an order is established. After a certain period of time, e.g. 0.1 seconds, this ordered list of data elements is encapsulated into a transaction and sent via the core 701 to the blockchain 150, thus being immutably recorded. If a timestamp is added to the record, this also records the time as well as the order.

[0136] An example application is to define a deterministic order among updates to entries in a database or the like. In this case, each data item received from client node 703C may represent a respective state change (i.e., update) to an entry in the database. However, such updates are not necessarily commutative, i.e., order matters. For example, if there are two requests to perform a non-commutative operation on data elements, e.g., a left matrix multiplication, then order matters. In another example, one request may be to delete a file and the other to read the file. Again, the order in which these requests are applied will affect the outcome.

[0137] Another exemplary application is implementing smart contracts in an output-based (e.g., UTXO-based) blockchain model. UTXO-based transactions and the like do not inherently support smart contracts in the same way that account-based model transactions do, and therefore when smart contracts are implemented in an output-based model such as a UTXO-based model, the functionality of the smart contract needs to be layered on top of the basic transaction model. In this case, the data items to be recorded on the blockchain 150 may again represent changes in state, such as changes in ownership. Again, the order is important, as it may affect, for example, whether an attempt to assign ownership is valid.

[0138] Another exemplary application is the ordering and time-stamping of digital certificates from a Certificate Authority (CA). Digital certificates are used to authorize access rights or other electronic authorizations, for example in the SSL / TLS and HTTPS security that underpins the Internet. In 2011, a Dutch CA was compromised by an attacker, likely from Iran. Fake certificates were issued for well-known domains and log files were falsified on the CA's servers. If these log files had been stored on the blockchain using an ordering and time-stamping service as described below, it would have been impossible to modify them due to the security provided by the proof-of-work. It is noteworthy that private keys in the company's HSMs were compromised in this attack. This highlights the fact that classical cryptographic protocols alone cannot always ensure information security, and it can be beneficial to also rely on other mechanisms, such as proof-of-work, to make such attacks extremely cumbersome.

[0139] In operation, the attestation node 702A is configured to receive a number of data items from one or more client nodes 703C over the overlay network connection between the middle tier and the outer tier. The data items may be labeled D by any terminology herein. The data items may be received from the same client node 703C or different client nodes 703C, or some may be received from the same client node 703C and some may be received from different client nodes 703C. They may be received directly over the connection between the client node 703C and the attestation node 702A, or may be forwarded through one or more other nodes of the hierarchical network therebetween (i.e., may be received through two or more hops between the sending client node 703C and the attestation node 702A).

[0140] The attestation node 702A is configured to determine an order of the multiple data items D and thus a sequence of the multiple data items. In an embodiment, the determined order is the order of receipt of the data items at the attestation node 702A. However, it is not excluded that some other arbitration rules may be applied. For example, if the data items are stamped with the time of transmission or creation by the client node(s) 703C that sent them and the attestation node 702A trusts these client nodes, the order may be the reported time of transmission or creation rather than the time of receipt. As another example, the order may depend on a priority scheme that gives different weights to different data items.

[0141] Whatever the order determined, the attestation node 702A attests to this order by creating a series of blockchain transactions 152 for recording in the blockchain 150. The attestation node 702A generates a series of two or more such transactions, which are referred to herein by any term as Tx 0 , Tx 1 , Tx 2 .... The attestation node 702A includes an indication of a different set of one or more data items of data items D in the payload of each subsequent one of the transactions Tx in the series of transactions. The payload may be included in an unusable output of the respective transaction. Such an output may be made unusable by an opcode, e.g., OP_RETURN, that terminates the locking script for that output. However, in other transaction protocols, the payload may be included in other ways. The set of one or more data items indicated in each subsequent transaction comes after the set indicated in the transaction immediately preceding it in the series of transactions, according to the order of the data items determined by the attestation node 702A. That is, the order of the transactions in the series of transactions matches the order of the sets in the determined sequence of the data items.

[0142] The attestation node 702A creates or otherwise determines a corresponding set of public / private key pairs for the following set of transactions: P 1 ,P 2 ,P 3 ,…

[0143] The attestation node 702A uses the private key of each key pair to sign the corresponding transaction in the sequence of transactions: Tx 0 →Tx 1 →Tx 2 →Tx 3 →…

[0144] TransactionTx 1 Enter the unlock script in the input 1 The signature of transaction Tx 2 , P 2 Each transaction also includes a payload that includes an indication of the set of one or more data items D attested by the respective transaction, e.g., in the OP_RETURN field. This payload is signed by the respective signature (in embodiments using a scripting language, an appropriate SIGHASH flag may be used). Initial Funding Transaction Tx 0 , P 1 It can have an outpoint of 0 with a dust value. For example, Tx 1 can be constructed as shown in Figure 8. All subsequent transactions have the same structure, i.e., Tx 2 Tx 1 Tx to unlock 1 The input pointing to P 2 It contains a signature using P 3The signature can be verified by the blockchain network 106 based on the corresponding public key of the key pair. 0 may or may not include an indication of the first set of data items (the first set of data items in the sequence is Tx 0 or Tx 1 (which can be shown in

[0145] Note that the form shown in Figure 8 ignores transaction fees for simplicity, which can be accounted for by adding another input and output to the transaction (e.g., managed by a proof service).

[0146] The OP_RETURN statement returns data 1 This contains a payload called Tx 1 The data elements D submitted by the user in the set attested by the attestation service in the order attested by the attestation service, or an indication thereof (Tx 2 Data in 2 (And so on.) Each transaction signs the hash of the previous transaction, so this means that the payload data 1 , data 2 , data 3 This also means ordering such as:

[0147] Once a blockchain transaction is accepted by the blockchain network 106, it is feasibly impossible to double-spend. It also serves as a form of issuing a certified order to the attestation service provided by the attestation node 702A. This allows users of client nodes 703 to have confidence that the positions where their data elements appear in the order attested by this attestation authority cannot be retroactively changed. Once such a transaction is mined in block 151, the order is even less likely to be changed, since it is computationally expensive to replace an existing block.

[0148] In some embodiments, each transaction Tx 0 , Tx 1 , Tx 2 The set indicated in ... consists of only a single one of the data items D per transaction (i.e., each data payload indicates only a single respective D). Alternatively, the set indicated in each such transaction may include multiple data items D per transaction (each data payload indicates a different respective set of multiple different data items D). In the latter case, the payload information also specifies the order of the data items D within each transaction's local set. This may be achieved, for example, by an ordered list included in the payload (e.g., the OP_RETURN output) and / or an index indicating the order mapped to the indication of each D. Examples are shown in Figures 9-11 and described in more detail below.

[0149] When multiple data items D are indicated per transaction, some criteria is needed to determine which data items per transaction should be collected. In principle, any scheme can be used to split the data items among the transactions, but in an embodiment, this may be done based on regular time intervals. That is, all data items D received by the attesting node 702A in a first instance of the regular time interval are included in the first transaction of the sequence of transactions, then all data items D received in the next instance of the regular time interval are indicated in the next transaction of the sequence of transactions, and so on.

[0150] The exact timing of the interval between transactions can be configured by the implementation, for example, transactions can be submitted 0.1 seconds apart.

[0151] Each set of data items may be indicated in a transaction simply by explicitly including ("in the clear") the data item(s) of that set in the payload of each transaction Tx. Alternatively or additionally, they may be indicated in a hash, encrypted form, or a transformation form such as r-puzzle. Examples are described in more detail in relation to Figures 9-11. In the context of ordering proof services, at a minimum, the "indication" of a data item herein means some information that allows a query node inspecting a transaction to verify the attested order of the data items. In some cases where the explicit values ​​of data items D are not explicitly included in the transaction, it may be required that the query node has some knowledge of the values ​​of data items D and has simply inspected the transactions in the mem pool 154 of the blockchain node 104 or on-chain to confirm the expected order of those items.

[0152] In an embodiment, the attestation node 702A attests each transaction Tx in the series of transactions. 0 , Tx 1 , Tx2 ... may also include at least one timestamp in the payload. The timestamp indicates the time the respective data item(s) was received at the attestation node 702A. If there is a single data item D per transaction, this may simply be the receipt time of that data item. If there are multiple data items D per transaction Tx, each transaction payload may include a single timestamp indicating the arrival time of the set (e.g., the time interval at which they were received), or individual timestamps for each data item D in the set.

[0153] When the attestation service submits a transaction containing the user's data to the blockchain 150, in some embodiments it will also send this transaction to the client node(s) 703 that submitted the data item D. This is possible because users in the outer tier (e.g., tier 3) are directly connected to attestation nodes 702A in the middle (e.g., tier 2). In embodiments, the client nodes 703 are also directly connected to blockchain mining nodes 104M and / or storage nodes 104S in the core, so they will not be able to send the transaction Tx 0 , Tx 1 , Tx 2 ... may be independently checked to see that the order was accepted by the blockchain network 106. Thus, the client node 703A may query the mem pool 154 of the miner 104M, and / or the actual blockchain 150 records on the storage node 104S, to verify that the expected ordering has been proven. Other third party nodes may similarly verify this via any suitable connection in the blockchain network 106. In some embodiments, queries by the client node 703A may be performed via a connection between the client node 703C and the core, using only the SPV-like connectivity described above in connection with Figures 3-6.

[0154] Optionally, the attestation service may also send to the client node(s) 703C that submitted the data items the chain of transactions that preceded the transaction containing those data, so that users can be sure that there are not two conflicting chains of transactions with different orders submitted to the blockchain by the service. The length of the chain of transactions should be appropriate to the level of trust required by the user. This trust may be outsourced, for example, a certification authority may attest to the accuracy of the chain of transactions every hour.

[0155] In an embodiment, client nodes 703C in a tier may also be connected to each other and can send each other (mined) transactions, including their and corresponding Merkle proofs. In an embodiment, each outer tier (e.g., tier 3) node is independently connected to the blockchain 150 so that they can verify that the Merkle proofs are correct. This allows users in an outer tier (e.g., tier 3) to agree on data ordering with only a minimal amount of temporary trust in the timestamping service before trust in the proof of work on the blockchain is handed over.

[0156] Next, the OP_RETURN payload data 1 Let us consider this in more detail. The goal is to determine the number of data elements D 1 , D 2 , D 3 , ... were received. Note that the data elements may represent hash commits of data associated with each user. It may be at the discretion of the user whether the user chooses to make their data public or instead record a hash commit of their data.

[0157] There are several different ways in which a set of data items D and their relative ordering can be indicated within a transaction Tx. The simplest is to simply index each element, and since OP_RETURN is signed, this is attested by the timestamping service. However, there are smarter ways that provide additional evidence of ordering and allow generalization to distributed timestamping services.

[0158] Method 1.1: Hash chaining. A unique index i is assigned to each data element D i is assigned to the entry H in the hash chain. i is created. i The value of depends on the data element and the previous element in the hash chain. This means that each element in the hash chain must be created after the previous element, enforcing the order. An example hash chain is shown in the table in Figure 9. This table is included in the transaction payload (data), and optionally, an explicit D column may or may not be included in the transaction.

[0159] One advantage of not explicitly including the value of D is that the hash can be smaller than D, and therefore fewer bits need to be stored on the chain. This also means that the user does not need to reveal the actual value of D if he does not want to. In any case, whether the D value is explicitly included or not, another advantage of the hash chain is that it makes it harder to change the order. For example, say there are 1000 data items D per transaction. Then, to reorder these data items, one would need to perform 1000 hashes, which would be computationally expensive. Thus, even if the attestation node 702A is not fully trusted, this gives the user additional confidence that the data items have not been reordered.

[0160] In some embodiments, each data element D i The timestamp of receipt ofi One way to do this is to include a timestamp in the pre-image of each element of the hash chain, e.g.:

number

[0161] In this case, a column containing the time would also be added to the table in Figure 9.

[0162] OP_RETURN payload data 1 is constructed from a table as shown in Figure 9. The column "data" may be omitted to save space or to keep the data elements private. Note that in that case, the only way to prove the order of the hash chain is to know all the data elements.

[0163] Additional security can be provided by replacing the hash function with HMAC, which is described in RFC2104 and introduces a secret symmetric key into the hashing procedure, which means that only someone who knows the secret key can prove the order of the data.

[0164] Method 1.2: Hash Chaining with Merkle Trees. This is similar to hash chaining in Figure 9, but instead of exposing the entire hash chain, we turn it into a Merkle tree and expose only the root. In this case, each data item D in the set is modeled as a leaf of a Merkle tree, and the Merkle root is included as an instruction in the transaction. Note that the index of the data is implied by the order in which it appears in the leaves of the Merkle tree. The Merkle proof can later be provided to users so that they can check the existence of the data item and its position in the Merkle tree. This method saves space in the transaction, as only 256 bits are needed in the OP_RETURN payload for the Merkle root.

[0165] Additionally or alternatively, each data item may be represented in a transaction by a corresponding Merkle proof for its leaves. As is well known to those skilled in the art, a Merkle tree allows one to prove that a given data item is a member of a set, given a Merkle root and a Merkle proof for the data item (which is a chain of hashes between the root and the leaves).

[0166] Method 2.1: Chaining of signatures. In this method, a new public key is created for each data element D and the element is signed with the new public key. This complies with the requirements for the time stamping protocol outlined in RFC3161.

[0167] Consider the sequence of public keys and signatures shown in Figure 10. The idea is that each public key is generated based on the data that precedes it. As with a hash chain, each public key (and therefore signature) in the sequence can only be created with knowledge of the previous public key in the sequence, thus enforcing order.

[0168] In a variation of this method, the entries in the table may each be transactions in their own right.

[0169] Method 2.2: Chaining r-puzzles. R-puzzles are a recently disclosed form of challenge and proof. They are based on the r part of an ECDSA signature (S,R) and provide a way to prove knowledge of a secret without revealing the secret. See https: / / www.youtube.com / watch?v=9EHKvNuRc0A&t=978s and https: / / www.youtube.com / watch?v=CqqTCsLzbEA.

[0170] An ECDSA (Elliptic Curve Digital Signature Algorithm) signature is constructed from the combination (S,R), where R is the x-coordinate of the public part of the ephemeral key pair. It is possible to use the same public key for each signature, but chain the ephemeral keys together. This would result in the sequence shown in Figure 11. This could be included in the transaction payload (data) as an alternative or in addition to any of the methods above.

[0171] Here, R 1 is a random ephemeral key, 1 ,R 1i >(H(D i )) is the short-term key R 1i Using P 1 The data H(D i )

[0172] In general, any of methods 1.1, 1.2, 2.2 and / or 2.2 and / or others may be used individually or in conjunction to indicate an order among a set of data items D in a transaction's payload (data).

[0173] Distributed Case: The above has been described in a scenario where the order proof service is provided by an individual node 702 A. It is also possible to provide such a service through multiple proof nodes 702 A.

[0174] For example, consider a situation where one has a distributed attestation service that uses a hierarchical network 700 to achieve consensus, in which case two or more of the intermediate tier nodes 702 (e.g., tier 2 nodes) of Figure 7 would act as attestation nodes.

[0175] ​Assume that the majority of attestation nodes 702A behave honestly and wish to reach a consensus for ordering and time stamping of data propagated in a community (as defined above) consisting of attestation service nodes 702A and users 703C. Assume that there are N independent attestation service nodes 703A connected to the same subset of m core mining nodes 701, thus defining the community of the hierarchical network 700. Due to the fact that there are multiple middle tier (e.g., tier 2) attestation nodes 702A, many users in the outer tier(s) (e.g., tier 3) can connect to nodes 702 in the middle tier (e.g., tier 2) without the middle tier nodes becoming too loaded (too many connections).

[0176] The problem to be addressed then is how to handle such a distributed case, e.g., two data items D 1 , D 2 The question is how intermediate tier certification nodes 702A (e.g., tier 2 nodes) can agree on a consensus on their ordering, even if the , ...

[0177] One way to address this is to use threshold signatures, i.e., as mentioned above, at least M distinct signatures (M>1) are required to unlock a transaction Tx, not just one. Consider an M-of-N threshold signature system as described, applied to the attestation service node 702A. This is achieved by using a private key share a 1 ,a 2 ,…,a N This means that there are N participating nodes with M, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,

[0178] One of the attestation service nodes 702A receives an OP_RETURN payload data element D, which is an ordered list of all data elements D received within a selected time period. 1 Candidate transaction Tx containing 1 Suppose a node generates a candidate transaction M(N) from the blockchain network 106. This node may broadcast the candidate transaction to all other attestation service nodes 702A (or at least some of them) and ask for their signature shares to sign the transaction. If they receive at least M signature shares (including their own), the transaction may be submitted to the blockchain network 106 and mined into a block 151. This ensures that the ordering of the data elements is agreed upon by at least the M-of-N time stamping services in the distributed network.

[0179] How is a single attesting node 702A selected to create a transaction? The above is a summary of the candidate transaction Tx 1 We assume that there is only one attestation service node 702A that created Tx and that the other attestation nodes 702A are OK with it. But what about the next candidate transaction? There are at least two options: (i) there is always one privileged attestation node 702A that creates candidate transactions, or (ii) after each transaction is created, one of the attestation nodes 702A is randomly selected to be the next node that creates the next transaction. This could be a pre-determined random sequence, or it could be a sequence of the just-submitted transaction Tx 1 For example, the seed may be a deterministic random selection based on a seed for Tx 1 Other distributed arbitration algorithms for distributed computing may also be possible.

[0180] conclusion It will be understood that the above embodiments are described by way of example only. More generally, a method, an apparatus, or a program according to any one or more of the following statements may be provided:

[0181] Statement 1: A method of proving an order of a sequence of data items, comprising: at a proving node of a network, receiving a sequence of data items from one or more client nodes of the network; determining an order of the sequence of data items, whereby each subsequent data item in the sequence follows a preceding one of the data items in the sequence; and, based on the determination, proving the order by including in each of a series of blockchain transactions an indication of a respective set of one or more data items of the data items, whereby each subsequent transaction in the series of blockchain transactions follows a respective preceding transaction in the series of blockchain transactions, and ... based on the determination, and the sets follow the sets indicated in each preceding transaction in the order, where each subsequent transaction includes a respective input pointing to an output of the respective preceding transaction, the output of each preceding transaction including a lock script, and the input of each subsequent transaction includes an unlock script including a respective signature based on a respective key in the set of keys, the inclusion of the respective signature being a condition for unlocking the unlock script of the respective preceding transaction, and the respective signature in each subsequent transaction signs a portion of the respective subsequent transaction including at least an indication of the respective set of data items, and the step of proving the order further includes transmitting the transactions to be recorded to the blockchain.

[0182] Statement 2: The method described in statement 1, wherein the above order is the order of receipt of the data items at the proof node.

[0183] Alternatively, the order may be according to some other arbitration rule, for example order of transmission or priority.

[0184] Statement 3: A method as described in statements 1 or 2, wherein the step of proving the order further includes timestamping each of the transactions with timestamp information specifying a receipt time of at least one of the respective sets of data items, the receipt time being a receipt time at the proving node.

[0185] Statement 4: A method according to any of the preceding statements, wherein each of said sets includes a plurality of data items respectively, and the instructions included in each transaction include instructions for individual ones of the data items in the respective set, and the step of proving order includes including in each of said series of transactions information specifying an order of the data items in the respective set from a first data item in the set to one or more subsequent data items in the set.

[0186] In an embodiment, this information may be included in the disabled outputs of each transaction. Disabled outputs are disabled by including an opcode that terminates the script of the disabled output. For example, the opcode may be OP_RETURN.

[0187] Statement 5: The method of statement 4, wherein the information includes an index mapped to an indication of the individual data items in the respective set and / or an ordered list of the individual data items in the set.

[0188] Statement 6: The method of statements 4 or 5, wherein the multiple data items of each respective set are selected based on being received at the attesting node within a respective instance of a predetermined recurrence time interval.

[0189] Statement 7: The method of statements 4, 5, or 6 when subject to statement 3, wherein within each transaction, the timestamp information includes individual timestamps corresponding to each of the data items in the respective set, specifying the time of receipt at the attestation node of each of the data items.

[0190] Statement 8: A method according to any of statements 4 to 7, wherein within each transaction, the instructions for each data item include at least a hash, the instruction for a first data item includes a hash of a first preimage, the first preimage includes at least the first data item, and the instruction for each subsequent data item following the first data item includes a hash of a respective subsequent preimage, each subsequent preimage including at least the hash of its preceding one in the sequence.

[0191] Statement 9: The method of statement 8 when dependent on statement 7, wherein each of the first preimage and the subsequent preimage further includes a corresponding timestamp.

[0192] Statement 10: A method according to any of statements 4 to 9, wherein for each transaction, individual data items are modeled as leaves of a Merkle tree, and the instructions include one or both of the Merkle root of the Merkle tree and / or Merkle proofs for the individual data items.

[0193] In some embodiments, the information specifying the ordering of the data items in each set includes the Merkle root of a Merkle tree, each leaf of the Merkle tree including a respective hash of pre-images, where a first pre-image includes at least the first data item, and each subsequent leaf of the Merkle tree including a hash of a respective subsequent pre-image, where each subsequent pre-image includes at least the hash of the preceding and subsequent data items in the sequence.

[0194] Statement 11: A method as described in any of statements 4 to 10, wherein within each transaction, the instructions for each data item include at least a corresponding public key, the instructions for a first data item include a first public key generated based on the first data item, and the instructions for each subsequent data item in the set include a subsequent public key generated based on that subsequent data item and the preceding public key in the sequence.

[0195] Statement 12: The method of statement 11, wherein the signing includes including a separate signature using each of the public keys, each signing a message including a corresponding data item or a hash thereof.

[0196] Statement 13: The method of any of statements 4 to 12, wherein within each transaction, the indication of the individual data items includes an r-puzzle for the individual data items.

[0197] Statement 14: A method according to any of statements 4 to 13, wherein the indication for each data item includes the respective data item in plain text.

[0198] Statement 15: The method of any of statements 1 to 13, wherein each transaction does not include any of the data items in plaintext.

[0199] In an embodiment, at least some of the plurality of data items are received from the same client node. Alternatively or additionally, at least some of the plurality of data items are received from different client nodes.

[0200] Each data item may be received directly by a connection between the attesting node and the client node from which it is received, or alternatively, the data item may be received proxies, over two or more hops, and forwarded between the client node and the attesting node through one or more nodes of the network.

[0201] Statement 16: The method of any of the preceding statements, wherein the network includes a layering including a core tier of core nodes, one or more intermediate tiers each including a plurality of intermediate tier nodes, and one or more outer tiers each including a plurality of outer tier nodes, the core nodes including one or more nodes of the blockchain network.

[0202] In an embodiment, the core nodes include one or more mining and / or storage nodes of the blockchain network. In an embodiment, each of the core nodes is a mining and / or storage node (e.g., a full-copy node) of the blockchain network.

[0203] Statement 17: The method according to statement 16, wherein the attestation node is one of the intermediate layer nodes.

[0204] Statement 18: The method of statement 16 or 17, wherein the sending node, or at least one of the sending nodes, is one of the outer layer nodes.

[0205] Statement 19: The method of statements 16, 17, or 18, wherein the sending includes sending the transaction toward a core layer.

[0206] Statement 20: The method described in statement 19, wherein the transmitting includes transmitting at least some of the transactions directly to at least one of the core nodes via a connection between the attestation node and the core node.

[0207] Statement 21: The method described in statement 19, wherein the sending includes sending at least some of the transactions to one or more of the core nodes via further intermediate tier nodes among the intermediate tier nodes.

[0208] Statement 22: The method described in statement 21, wherein the further intermediate tier node is configured to add its own signature to each of the transactions received from the attestation node, and each unlocking script in the set of transactions conditions unlocking on the signatures of two or more of the intermediate tier nodes.

[0209] In an embodiment, the further intermediate tier node may be in the same intermediate tier as the attestation node, or alternatively, the further intermediate tier node may be in a different intermediate tier of the hierarchical network between the core tier and the tier of the attestation node.

[0210] Statement 23: A method according to any of the preceding statements, in which an indication of each data item is included in the unavailable output of the respective transaction.

[0211] Disabled outputs are disabled by including an opcode that terminates the script of the disabled output. For example, said opcode could be OP_RETURN.

[0212] Statement 24: The method described in any of the preceding statements, wherein the transaction and / or the attestation node is attested by a certification authority.

[0213] Statement 25: A computing device comprising a memory including one or more memory units, a processing device including one or more processing units, and a network interface including one or more network interface units, wherein the memory stores code configured to be executed on the processing device, and the code, when executed on the processing device, is configured to cause the computing device to operate as a proof node by performing a method as described in any of the preceding statements, the method including receiving a data item and sending a transaction via the network interface.

[0214] Statement 26: A computer program embodied on a computer readable storage and configured to perform the method of any of statements 1 to 24 when executed on one or more processors.

[0215] Statement 27: A method for determining whether a recorded order of a sequence of data items matches an expected order, comprising: determining, at a client node of a network, an indication of a respective set of one or more data items from each of a series of transactions recorded on a blockchain, wherein each subsequent transaction in the series of transactions follows a respective preceding transaction in the series of transactions; and checking, for each subsequent transaction, that the one or more data items of the respective set indicated in the subsequent transaction follow the one or more data items of the respective set indicated in the respective preceding transaction according to the expected order, wherein each subsequent transaction includes a respective input pointing to an output of the respective preceding transaction, the output of each preceding transaction including a lock script, and the input of each subsequent transaction includes an unlock script including a respective signature based on a respective key in the series of keys, wherein the including of each signature is a condition for unlocking the unlock script of the respective preceding transaction, and the method comprises verifying the signature in each subsequent transaction.

[0216] Statement 28: The method described in statement 27, in which the client node has previously sent at least one of the data items to the attestation node in order for the attestation node of the network to attest to the recorded order by creating the above series of transactions and submitting them for recording on the blockchain.

[0217] Statement 29: The method of statement 27 or 28, wherein at least a portion of the network includes a hierarchical network including a core tier of core nodes, one or more intermediate tiers each including a plurality of intermediate tier nodes, and one or more outer tiers each including a plurality of outer tier nodes, the core nodes including one or more nodes of the blockchain network, the client node being one of the outer tier nodes, and the attestation node being one of the intermediate tier nodes.

[0218] Statement 30: The method of statement 29, wherein a client node sends at least one data item to a proof node via a connection between the client node and one of the intermediate tiers, but performs reads via a direct connection between the client node and the core tier, where at least some of the nodes in the core tier maintain a copy of the blockchain.

[0219] Statement 31: A computing device comprising a memory including one or more memory units, a processing device including one or more processing units, and a network interface including one or more network interface units, wherein the memory stores code configured to be executed on the processing device, and the code, when executed on the processing device, is configured to cause the computing device to operate as a query node by executing a method according to any of statements 27 to 30, including reading the instructions via the network interface.

[0220] Statement 32: A computer program embodied on a computer readable storage and configured to perform the method of any of statements 27 to 30 when executed on one or more processors.

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

Claims

1. 1. A method of proving an order of a sequence of data items, comprising, at a proving node of a network, receiving said sequence of data items from one or more client nodes of said network; determining an order for the sequence of data items whereby each subsequent data item in the sequence follows a preceding one of the data items in the sequence; Based on the determination, proving the order by including in each of a series of blockchain transactions an instruction indicating a respective set of one or more of the data items, wherein each subsequent transaction in the series of blockchain transactions follows a respective preceding transaction in the series of blockchain transactions, and the set indicated in each subsequent transaction follows the set indicated in the respective preceding transaction according to the order; Including, each subsequent transaction includes a respective input that points to an output of the respective prior transaction, the output of the respective prior transaction including a lock script, the input of each of the subsequent transactions including an unlock script including a respective signature based on a respective key in a set of keys, the inclusion of the respective signature being a condition for unlocking the unlock script of the respective prior transaction; the respective signature in each subsequent transaction signing a portion of the respective subsequent transaction including at least the indication information indicating the respective set of data items; The step of proving the order further comprises transmitting the transaction to be recorded on a blockchain. method.

2. The method of claim 1 , wherein the order is an order of receipt of the data items at the attestation node.

3. The step of verifying the order comprises: - time stamping each of said transactions with time stamp information specifying a receipt time of at least one of said respective sets of data items, said receipt time being said receipt time at said attestation node; The method according to claim 1 or 2.

4. Each of the sets includes a plurality of the data items, and the instruction information included in each transaction includes instruction information indicating individual ones of the data items in the respective set, and the step of proving the order includes: - including in each of said series of transactions information specifying said ordering of said data items in said respective sets, from a first data item in said set to one or more subsequent data items in said set; The method according to any one of claims 1 to 3, comprising:

5. The method of claim 4, wherein the information specifying the order of the data items in the respective sets includes an index mapped to the instruction information indicating the individual data items in the respective sets, and / or an ordered list of the individual data items in the sets.

6. 6. A method according to claim 4 or 5, wherein the plurality of data items of each respective set are selected on the basis of being received at the attesting node within respective instances of a predetermined recurring time interval.

7. Within each transaction, the time stamp information includes individual time stamps corresponding to each of the data items in the respective sets and specifying the time of receipt at the attestation node of each of the data items. A method according to claim 4, 5 or 6 when dependent on claim 3.

8. Within each transaction, 8. The method of claim 4, wherein the indication information indicating individual data items includes at least a hash, the indication information indicating the first data item includes a hash of a first preimage, the first preimage includes at least the first data item, and the indication information indicating each subsequent data item following the first data item includes a hash of a respective subsequent preimage, each subsequent preimage including at least a hash of its preceding one in the sequence.

9. The method of claim 8 when dependent on claim 7, wherein the first pre-image and each of the subsequent pre-images further include a corresponding time stamp.

10. For each transaction, the individual data items are modeled as leaves of a Merkle tree, and the indication of the individual data items in the respective sets of data items comprises: the Merkle root of said Merkle tree; and / or Merkle proofs for individual data items The method of any one of claims 4 to 9, comprising one or both of the following:

11. Within each transaction, the indication information pointing to each individual data item includes at least a corresponding public key, the indication information pointing to the first data item includes a first public key generated based on the first data item, and the indication information pointing to each subsequent data item in the set includes a subsequent public key generated based on that subsequent data item and a preceding public key in the sequence; 11. The method according to any one of claims 4 to 10.

12. 12. The method of claim 11, wherein the signing includes including a separate signature using each of the public keys, each signing a message including the corresponding data item or a hash thereof.

13. 13. The method of claim 4, wherein within each transaction, the instruction information indicating a respective data item comprises an r-puzzle for the respective data item.

14. 14. A method according to any one of claims 4 to 13, wherein the indication indicating each data item comprises the respective data item in plain text.

15. 14. The method of claim 1, wherein each transaction does not include any of the data items in plaintext.

16. 16. The method of claim 1, wherein the network comprises a hierarchical network including a core tier of core nodes, one or more middle tiers each including a plurality of middle tier nodes, and one or more outer tiers each including a plurality of outer tier nodes, the core nodes comprising one or more nodes of a blockchain network.

17. The method of claim 16 , wherein the attestation node is one of the intermediate tier nodes.

18. 18. The method of claim 16 or 17, wherein the sending node, or at least one of the sending nodes, is one of the outer layer nodes.

19. 19. The method of claim 16, 17, or 18, wherein the sending comprises sending the transaction toward the core layer.

20. 20. The method of claim 19, wherein the transmitting includes transmitting at least some of the transactions directly to at least one of the core nodes via a connection between the attestation node and the core node.

21. 20. The method of claim 19, wherein the transmitting includes transmitting at least some of the transactions to one or more of the core nodes via further ones of the intermediate tier nodes.

22. 22. The method of claim 21 , wherein the further intermediate tier node is configured to add its own signature to each of the transactions received from the attestation node, and each unlock script in the set of transactions conditions its unlocking on the signatures of two or more of the intermediate tier nodes.

23. 23. A method according to any preceding claim, wherein the indicative information indicating each data item is included in an unusable output of each of the transactions.

24. 24. The method of claim 1, wherein the transaction and / or the attestation node are attested by a certificate authority.

25. 1. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units; a network interface including one or more network interface units; Equipped with 25. The method of claim 1, further comprising: receiving the data item; and transmitting the transaction via the network interface.

26. The method of claim 1, further comprising: receiving the data item and transmitting the transaction via the network interface.

27. The method of claim 1, further comprising: receiving the data item and transmitting the transaction via the network interface.

28. The method of claim 1, further comprising: receiving the data item and transmitting the transaction via the network interface. Computer equipment.

26. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 24 when executed on one or more processors.

27. 1. A method for determining whether a recorded order of a sequence of data items matches an expected order, comprising: determining the recorded order by reading, from each of a series of transactions recorded on a blockchain, indicative information indicating a respective set of one or more of the data items, wherein each subsequent transaction in the series of transactions follows a respective preceding transaction in the series of transactions; checking, for each subsequent transaction, that the one or more data items of the respective set indicated in the subsequent transaction follow the one or more data items of the respective set indicated in the respective preceding transaction according to the expected order; Including, each subsequent transaction includes a respective input that points to an output of the respective prior transaction, the output of the respective prior transaction including a lock script, the input of each of the subsequent transactions including an unlock script including a respective signature based on a respective key in a set of keys, the inclusion of the respective signature being a condition for unlocking the unlock script of the respective prior transaction; The method includes verifying the signature for each subsequent transaction. method.

28. 28. The method of claim 27, wherein the client node has previously transmitted at least one of the data items to an attestation node of the network so that the attestation node attests to the recorded order by creating the series of transactions and submitting them for recording on the blockchain.

29. 29. The method of claim 28, wherein at least a portion of the network includes a hierarchical network including a core tier of core nodes, one or more middle tiers each including a plurality of middle tier nodes, and one or more outer tiers each including a plurality of outer tier nodes, the core nodes including one or more nodes of a blockchain network, the client node being one of the outer tier nodes, and the attestation node being one of the middle tier nodes.

30. 30. The method of claim 29, wherein the client node sends at least one of the data items to the attestation node via a connection between the client node and one of the intermediate tiers, but performs the read via a direct connection between the client node and the core tier, where at least some of the nodes in the core tier maintain a copy of the blockchain.

31. 1. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units; a network interface including one or more network interface units; Equipped with 31. A computing device, the memory storing code configured to be executed on the processing device, the code being configured, when executed on the processing device, to cause the computing device to operate as a query node by executing a method according to any one of claims 27 to 30, the code comprising reading the instruction information via the network interface.

32. A computer program embodied on a computer readable storage and configured to perform the method according to any of claims 27 to 30 when executed on one or more processors.

Images