Distributed database

Abstract

To provide a distributed database implemented with a blockchain to record changes in a state to the database.SOLUTION: A method is a method to be executed in a hierarchical network 1200 including a core layer including a core node 1201 which is a node of a blockchain network, an intermediate layer including an intermediate layer node 1202 which is a database node storing at least a part of a distributed database, and an outer layer including an outer layer node 1203 which is a client node. At the database node, one or a plurality of update requests requesting to update a database entry is / are received from one or a plurality of client nodes, and for each update request, an update is applied locally or forwarded to another database node. At least one transaction comprising an indication of one or the plurality of update requests is also recorded on a blockchain of a blockchain network.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] The present disclosure relates to a distributed database implemented with a blockchain for recording state changes to the database. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a replicated copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain includes a chain of data blocks, each 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 through 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 storage. Forwarding nodes propagate transactions throughout the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own copies of mined blocks in the blockchain. To record a transaction in the blockchain, a party sends the transaction to one of the nodes in the network to 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 a large amount of computational resources and blocks containing double-spend attempts are likely not 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 specifying the amount of a digital asset, sometimes called a UTXO (or “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 an output in a prior transaction and may further include an unlocking script for unlocking 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 for unlocking 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 on the blockchain, one of the validity criteria applied at each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another, earlier valid transaction. A node that finds the target transaction invalid according to either of these conditions will neither propagate it nor include it for mining into a block to be recorded on the blockchain.

[0007] Another type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances rather than by referencing the UTXO of a previous transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by miners separate from the blockchain.

[0008] Traditionally, transactions in a blockchain are used to communicate digital assets, i.e., some digital tokens. However, blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing for the incorporation of 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

[0009] The present disclosure provides a scheme in which a distributed database is implemented across multiple nodes of a hierarchical network with a node of a blockchain network at its core, and state changes to the database are recorded on the blockchain of the blockchain network.

[0010] According to one aspect disclosed herein, there is provided a method for operating a distributed database implemented in a hierarchical network. The hierarchical network includes a core tier including one or more core nodes, one or more middle tiers each including one or more middle tier nodes, and one or more outer tiers each including one or more outer tier nodes. Each of the core nodes is a node of a blockchain network, at least some of the middle tier nodes are database nodes of a distributed database, and at least some of the outer tier nodes are client nodes of the distributed database, and each database node stores at least a portion of the distributed database. The method includes receiving, at a first database node of the database nodes, one or more update requests from one or more of the client nodes, each request to update a respective target entry in a distributed database, and for each received update request, determining whether the respective target entry is found in a portion of the database stored at the first database node, and if found, updating the update request to the respective target entry in the portion of the database stored at the first database node, or if not found, forwarding the request to another database node of the database nodes that stores a portion of the database that includes the respective target entry. Additionally, at least one transaction including an indication of the one or more update requests is also recorded on a blockchain of the blockchain network. [Brief explanation of the drawings]

[0011] To facilitate an understanding of 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. [Figure 2] 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 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. [Figure 5] FIG. 10 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] 1 illustrates schematically an exemplary indexed list for recording the order of a set of data items within a transaction. [Figure 10] 10 illustrates schematically another example of an indexed list for recording the order of a set of data items within a transaction. [Figure 11] 10 illustrates schematically another example of an indexed list for recording the order of a set of data items within a transaction. [Figure 12] 1 illustrates a schematic example of a distributed database implemented in a hierarchical network. [Figure 13] For comparison, an example of the architecture of a Cassandra database cluster is shown schematically. [Figure 14] 1 illustrates schematically different communication paths in a Cassandra cluster graph. [Figure 15] FIG. 1 is a schematic block diagram of the high-level architecture of a single Cassandra node during a write request. [Figure 16] Schematic showing the transition from a cluster of complete networks (left) to a blockchain layered network (right). [Figure 17] 1 illustrates a schematic diagram of a blockchain layered network (BLN) that includes a cluster of distributed database nodes and users of the system supported by the database. [Figure 18] 1 shows a schematic example of a BLN-implemented distributed database where PKI is implemented at least at layer i=2,3. [Figure 19] 10 illustrates a schematic diagram of an example read / write transaction for recording database update instructions on the blockchain. [Figure 20] 1 illustrates a schematic diagram of read / write paths in an exemplary architecture of a BLN-implemented distributed database (BLNiDD). [Figure 21] 10 illustrates an example of a hinted handoff transaction. DETAILED DESCRIPTION OF THE INVENTION

[0012] 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 multiple nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 in the blockchain network 106 comprises a peer's computing 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 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, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0013] 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 for each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing 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 spent). Each input points to the output of a previous transaction 152, thereby linking the transactions.

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

[0015] For a given current transaction 152j, the input (or each input) contains a pointer referencing the output of a previous transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. While 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 transmitted to the network 106. Thus, "preceding" herein refers to something that precedes it in the logical sequence linked by a pointer, 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 referred to as the antecedent transaction or predecessor transaction.

[0016] The input of the current transaction 152j also includes the signature of 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 new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to new user 103b, as defined in the output of the current transaction 152j. In some cases, a transaction 152j can have multiple outputs to divide the input amount among multiple users (one of which can be the original user 103a to provide the change). In some cases, a transaction can also have multiple inputs to combine amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0017] The above may be called an "output-based" transaction protocol, and sometimes called an unspent transaction output (UTXO) type protocol (where 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.

[0018] Another type of transaction protocol may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a previous transaction in the sequence of past transactions. The current state of every account is stored and constantly updated by miners separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0019] In either type of model, when a user 103 wishes to complete a new transaction 152j, the user sends the new transaction from the user's computer terminal 102 to one of the nodes 104 of the P2P validation network 106 (which today is typically a server or data center, but could in principle be another user terminal). The nodes 104 check 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 and collectively form the transaction model. The node protocol typically requires 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 involve checking that the user's cryptographic signature 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. This condition 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 new transaction's input points. In some transaction protocols, the condition may be defined at least in part by custom script included in the input and / or output. Alternatively, the condition may be fixed solely by the node protocol, or by a combination of these. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also function as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more additional nodes 104, and so on.In this manner, the new transaction is propagated throughout the network of nodes 104.

[0020] In an output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has been validly redeemed by the input of another prior transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the prior transaction 152i that it attempts to spend or redeem has not yet been spent / redeemable 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 user attempts to spend the same transaction output multiple times.

[0021] 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 supported 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 hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a certain, predetermined number of leading zeros. A property of a hash function is that it has an unpredictable output for its input. This search, therefore, can only be performed brute force, consuming a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0022] The first miner node 104M to solve the puzzle publishes it to the network 106, providing a proof of its solution that can later be easily checked by other nodes 104 in the network (given the solution to the hash, it is easy to check that the hash output satisfies the conditions). 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 because it takes a lot of effort to create a new block 151, and mining nodes 104M are incentivized to avoid including double spends in their blocks because blocks containing double spends are likely to be rejected by other nodes 104. Once created, blocks 151 cannot be modified because they are recognized 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. Because 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.

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

[0024] 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 began 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 unmined pool 154, and so on. Protocols also exist for resolving any "forks" that may occur if two miners 104M solve the puzzle within a very short time of each other, propagating conflicting views of the blockchain. In essence, whichever prong of the fork grows the longest results in a deterministic blockchain 150.

[0025] 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" a certain amount of digital assets. This special type of transaction is sometimes called a "producing" transaction; it automatically forms part of the new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. Often, a regular (non-producing) 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 containing that transaction.

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

[0027] The memory of each node 104 stores software configured to execute on the node's 104 processing unit 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 respective computing device's processing unit. 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. Additionally, 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.

[0028] Also connected to the network 101 are computer devices 102 for each of multiple parties 103 acting as consuming users. These 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 devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 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 will be referred to herein as Alice, and the second party 103b will be referred to as Bob; however, this is not intended to be limiting, and it will be understood that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0029] The computing equipment 102 of each party 103 includes a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing 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 memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing 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 unit. It will be understood that any action attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing 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 smartwatch. 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.

[0030] The client application 105 may initially be provided to the computer 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.

[0031] The client application 105 includes at least a "wallet" functionality, which has two primary 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 they currently own. 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.

[0032] 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; instead, any client function described herein may instead be implemented in a suite of two or more separate applications that interface via an API, or one that plugs into the other, for example. 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 description will be made with reference to client application 105, but will be understood to be non-limiting.

[0033] 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 enables the wallet functionality 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 to which the respective party 103 is a recipient (or, in embodiments, 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 functionality 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. Transaction protocols and node protocols correspond to each other; a given transaction protocol works in conjunction 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 for different subtypes of transactions within it). 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 that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0034] As noted, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process 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 for 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 for the sequence of transactions (note: the sequence of transactions 152 can diverge). The chain of blocks 151 stretches 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.

[0035] When a given party 103, such as Alice, wishes to submit 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. From her client application 105, Alice then sends the transaction 152 to one of one or more forwarding nodes 104F to which Alice is connected. For example, this may be the forwarding node 104F 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 for being "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 via 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.

[0036] 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 immediately propagate throughout the P2P network 106.

[0037] Once admitted to pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, miner nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152j. (Other miners 104M may be trying to solve the puzzle based on older views of 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 pool 154 that contains Alice's transaction 152j.) Once proof-of-work is done for pool 154 that contains new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Because each transaction 152 contains a pointer back to the previous transaction, the order of transactions is also immutably recorded.

[0038] Both mining nodes and storage nodes may perform validation as a function. In the case of mining nodes, that function may be to assist in hashing, and in the case of storage nodes, that function may be to assist in memorization.

[0039] 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 unmined instance that it originally accepted.

[0040] UTXO-based model Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following description will be given with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible implementations.

[0041] 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). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the (distributed) ledger. A UTXO may also include, among other information, the transaction ID of the underlying transaction. 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 the transaction's ID. In embodiments, 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 submitted to the miner 104M.

[0042] Suppose Alice 103a wishes to create transaction 152j to transfer an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of the digital asset locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can refer to any previous (i.e., earlier) transaction that still has unspent output 203 locked for Alice.

[0043] The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 can be created and submitted to the network 102 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions within a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may similarly be interchanged with “preceding” and “successor,” or “earlier” and “later,” “parent” and “child,” etc. This does not necessarily imply an 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 predecessor 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 its parent or discarded, depending on the node protocol and / or minor behavior.

[0044] One of the one or more outputs 203 of the prior transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script, which defines the conditions that the 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, including the condition that the unlocking script in the input of the later transaction contains the cryptographic signature of the party to whom the prior transaction is locked.

[0045] 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, for example, 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.

[0046] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a later transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A ] is Alice's public key P from her public-private key pair. ATx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A 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.

[0047] Depending on the implementation, the required signature may be, for example, a conventional Elliptic Curve Digital Signature Algorithm (ECDSA) signature, a Digital Signature Algorithm (DSA) signature, or a 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) puzzle or a P2PK hash (P2PKH) puzzle, or alternative means such as an R-puzzle may instead be implemented as the means for the signature. This example uses P2PK as an illustration.

[0048] When a new transaction Tx1 arrives at 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 ] where '||' denotes concatenation, '<...>' means to put data on the stack, and '[...]' are functions that compose 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. In either case, when executed together, the scripts will create a new lock script containing Alice's public key P as contained in the lock script in the output of Tx0. A , to authenticate that the lock script in Tx1's input contains Alice's signature, who signed the expected portion of data. The expected portion of data itself (the "message") must also be included in the Tx0 instruction to perform this authentication. In an embodiment, the signed data includes the entirety of Tx0 (i.e., a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

[0049] The details of authentication using 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 on 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, part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

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

[0051] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the node 104 considers Tx1 valid. If it is a mining node 104M, this means adding it to the pool 154 of transactions awaiting work of proof. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106 so that transaction Tx1 is propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO from Tx0 as spent. Note that Tx1 can only be valid if it uses an unspent transaction output 203. If it attempts to use an output that has already been spent by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, node 104 also needs to check whether the referenced UTXO in the prior transaction Tx0 has already been spent (already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database marking which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

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

[0053] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" a portion of the amount defined in the UTXO as spent; another portion is spent. However, it is possible to split an amount from a UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself or to pay another party in the second output of Tx1.

[0054] In practice, because the reward for generating transactions alone is typically not enough to incentivize mining today, Alice also typically needs to include a fee for the winning miner. If Alice does not include a fee for the miner, Tx0 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 transactions 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, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference is automatically awarded to the winning miner 104M. However, it is not necessarily excluded that a miner's fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0055] 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 throughout the blockchain 150. No number defining a given party's 103 total balance is stored anywhere in the blockchain 150. 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 on one of the storage nodes 104S, e.g., the storage node 104S closest to or best connected to each party's computer device 102.

[0056] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P 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 a scripting language. OP_CHECKSIG (also called "Checksig") is a script 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 runtime, the occurrence of the signature ("sig") is removed from the script, but additional requirements, such as a hash puzzle, remain for transactions verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for creating an unusable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata may include a document desired to be stored on the blockchain.

[0057] 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 signed depends on the SIGHASH flag, which is a 4-byte code included at the end of the signature (and is therefore fixed at the time of signing) to select which outputs are signed.

[0058] 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 include authenticating the signature. More generally, any condition or conditions can be defined using a scripting language. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0059] Layered 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-to-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 example connections may be used to form a layered network.

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

[0061] FIG. 3 shows a schematic diagram of an example layered network (LN) 300. Generally, an LN includes a core network (or core layer) composed of core nodes 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 composed of second nodes 302, to one or more outer layers. Each outer layer is composed of a set of external nodes 303. While only one outer layer is shown in FIG. 3, it will be understood that an LN may include any number of outer layers. As specific examples, an example LN 500 including five layers is shown in FIG. 5, and an example LN 600 including four layers is shown in FIG. 6.

[0062] The example LN 300 of Figure 3 includes five core nodes 301, six secondary nodes 302, and eight exterior nodes 303. In some LNs 300, the number of nodes may increase by layer, i.e., the core layer is composed of the fewest number of nodes and the outermost layer is composed of the greatest 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 greatest number of nodes. In this example, the core layer is the innermost layer of the LN 300, the secondary layer is the middle layer, and the only outer layer is the outermost layer.

[0063] The core layer (the 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 "nearly 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.

[0064] The second layer includes second nodes 302. Note that the term "second node" is used architecturally only as a label for nodes 302 located within the second layer of the LN 300. 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 (indicated by striped circles) are connected to one core node 301, and some second nodes 302 (indicated by white circles and shaded circles) are connected to two core nodes 301. Secondary nodes 302 (and outer 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 connection between the secondary nodes 302 and the core node 301 is called the "ancestor connection" and is shown by a thick dashed line.

[0065] 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 302 may be connected to other second nodes 302. These "intra-layer" connections are shown in FIG. 3 as solid lines between nodes.

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

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

[0068] 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 connection between an external node 303 and a core node 301 is called a "core ancestor connection" and is shown by a thin dashed line. 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 will not be connected to any other core nodes 301. In this case, each external node 303 belongs to a single community.

[0069] 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) include a single core node 301, while another community (shaded) 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.

[0070] Figure 5 shows a schematic diagram of another example of an LN 500. In this example, only some core nodes 301 are connected to secondary nodes and external nodes 303. That is, in this example, some core nodes 301 only form connections with other core nodes 301. Therefore, in this example, the LN 500 includes a single community (shaded node). 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 secondary node 302 connected to two core nodes 301. The second layer is composed of a single secondary node 302 connected to two core nodes 301. The third layer is composed of a single external node 303 connected to the secondary node 302 via an ancestor connection. The third-layer 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 layer also consists of a single external node 304. The fourth-layer external node 304 is connected to the third-layer external node 303 via an ancestor connection and to the second node 302 via an ancestor connection. The fourth layer external node 304 is also connected to two core nodes 301 to which the second node 302 and the third-layer 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 layer consists of two external nodes 305. The two external nodes 305 in the fifth layer are connected to the fourth-layer external node 304, to the third-layer external node 303, and to the second node 302, each of which is an ancestor connection. The two outer nodes 305 are also connected via core ancestor connections to the two core nodes 301. In this exemplary LN 500, the second tier nodes and outer tier nodes are not connected to any other nodes in the same tier.

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

[0072] In some embodiments, LNs 300, 400, 500, 600 (hereinafter simply referred to as "300") may be "blockchain layered networks (BLNs)." The term BLN is defined herein as a blockchain network or a layered network that includes at least a portion of a blockchain network, such as blockchain network 106 described with reference to FIG. 1.

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

[0074] The BLN 300 may include at least a portion of a blockchain network 106 at its core. Generally, the nodes of the layered 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).

[0075] Each of the external nodes 303 (or each of the outermost external nodes) may be an end-user node including a user's computing equipment. This may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, 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 includes a memory including one or more memory units and a processing device including one or more processing units. These may take the form of, for example, a memory medium and / or a processor as described above in connection with other network elements or user equipment. The memory stores client software configured to run on the processing device, and the client software, when executed, is configured to cause the node to operate as a protocol client that conforms to a connection protocol according to any of the following embodiments or similar. Optionally, one or more of the end-user nodes may include user equipment 103 of users 102 of the blockchain network 106, and the client software may include a blockchain wallet application 105 or the like.

[0076] 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, which 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. The memory stores software configured to be run on the processing device of the second node 302. When executed, the software is configured to follow a connection protocol according to any of the following embodiments or similar. In some embodiments, when executed, the software is configured to provide a service operating according to any of the embodiments described below or similar.

[0077] In some examples, some or all of the second nodes 302 may operate a smart contract service that is configured to perform certain operations in response to and based on blockchain transactions sent to the smart contract service by one of the other nodes of the LN 300, e.g., by an 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.

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

[0079] The nodes 301, 302, and 303 are configured to form connections between one another at the overlay network level. That is, the nodes 301, 302, and 303 of the hierarchical network are configured to conform to an overlay network protocol that specifies what connections they can and cannot form with other nodes 301, 302, and 303 of the hierarchical network. Thus, while all nodes may (but need not) be physically connected to one another through the underlying infrastructure (e.g., the Internet), connections between such nodes 301, 302, and 303 may be more restricted when they participate as nodes 301, 302, and 303 of a hierarchical network operating in accordance with the hierarchical network's associated overlay network protocol. A connection between two nodes 301, 302, and 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, and 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).

[0080] In embodiments 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(s) 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(s) 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.

[0081] 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(s) 302 and then to the core node 301.

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

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

[0084] Additionally or alternatively, the second node 302 and / or the third node 303 may be configured to send to the core node 301 a request 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 tracing back to the Merkle root. To verify whether a transaction was mined in block 151, the nodes 302, 303 take the transaction's hash, concatenate it with the first hash in the Merkle proof's sequence of hashes (i.e., the hash partner in the Merkle tree at the same level as the transaction's hash), and hash the result. This concatenation and hashing process is repeated until all of the hashes in the Merkle proof have been 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.

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

[0086] 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 transaction's output, e.g., an unspendable output. As another example, the transactions may include a particular (and the 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 secondary consensus rule sets. That is, the transaction may include two or more control branches in the output, each 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 nodes 302, 303 are configured to implement the second rule set, core node 301 may send the transaction to nodes 302, 303. If nodes 302, 303 are configured to implement neither the first rule set nor the second rule set, core node 301 does not send the transaction to nodes 302, 303.

[0087] 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 block 151. Other nodes in the BLN 300 may use the identifier to identify the mining node 104M on the network.

[0088] Another way to identify the nodes 301, 302, and 303 of the LN 300 is through digital certificates. Some or all of the nodes 301, 302, and 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 connect to a different node using the node's digital certificate. 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.

[0089] A node at a given tier may issue a digital certificate to a node at 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 at the first outer tier, and so on. In some examples, a node at a given tier may issue digital certificates to nodes at the same tier, e.g., second node 302 may issue a respective digital certificate to one or more other second nodes 302.

[0090] Connection Protocol: As described above, each node connecting to the layered 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 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 in the LN 300 must follow the connection protocol. In other examples, only nodes connecting to the LN 300 for the first time or rejoining the LN 300 must follow the connection protocol. Figures 3-6 show exemplary LNs 300, 400, 500, and 600 established according to a connection protocol.

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

[0092] The connection protocol requires that a connecting node connect 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 may be the innermost tier and therefore cannot connect to a preceding 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.

[0093] The connection protocol may require the connecting node to connect to two or more core nodes. The connection protocol may further require the connecting node to connect to two or more but not all of the core nodes, for example, all but one of the core nodes. The connecting 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).

[0094] The connection protocol may require the 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.

[0095] 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 two or more second nodes, 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.

[0096] 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 external tiers may include external nodes that form one or more same-tier connections, and some external 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.

[0097] 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 fifth-layer external node 305 in LN 500 of FIG. 5 is connected to the fourth-layer external node 304 and to the third-layer external node 303. In some examples, the connection protocol may require that the (i+1)th outer node must connect to each external node in each preceding layer to which the external node in the ith outer layer is connected.

[0098] In embodiments in which some or all of the nodes of LN300 are associated with digital certificates, the connection protocol may require that connecting nodes must connect only to nodes associated with the nodes associated with the respective digital certificates. In some embodiments, the connection protocol may require that connecting nodes (e.g., external nodes) must connect to respective nodes (e.g., second nodes) only 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 as the respective node (e.g., a different second node).

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

[0100] A connection protocol enables the construction of a BLN. Like a Mandala network, a BLN is constructed in layers. Unlike a Mandala network, the first layer may form an incomplete graph (e.g., a nearly complete graph). Other differences between a BLN and a Mandala network are that in a BLN, 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 degrees of nodes may vary between layers.

[0101] Preferably, for all nodes outside the central core: (i) Each node is connected to m of the n1 nodes in the central core. (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. There are at most n2 communities, where n2 is the number of nodes in the second tier. (iv) Each node is connected to every other node by at most three hops, which is called the diameter of the graph.

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

[0103] 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), which contributes significantly to the emergent properties of Mandala networks. Network size (N=Σ in 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. · Robust against random node failures.

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

[0105] Assuming that the core tier exhibits a uniform balanced distribution of hash power among its n1 core nodes, the minimum proportion of nodes is: f=m / n1

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

[0107] The nodes in the second layer, L2, closest to the core, rely most heavily on the probabilistic security model of the blockchain protocol, and this dependency is further enhanced when the layer is L g The connection protocol may require nodes in L2 to connect to exactly c2 = m core ancestors, while all subsequent nodes in layers i > 2 may connect to a range of core ancestors 1 < <c i ≤ m. In some instances, nodes in all subsequent layers must connect to m core ancestors.

[0108] Nodes outside the central core of the BLN may have "SPV-like" connections to the core, which means they can: a) Send the transaction to a core node. b) Ask the core nodes 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.

[0109] 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 it using the BLN. Many use cases require only the types of connectivity described above. In some instances, the second node 302 and / or external node 303 are configured to be able to perform only actions a) through d) above. However, other solutions, typically at the enterprise level, may require the core to proactively submit more data, such as transactions that meet certain criteria. Thus, actions a) through d) are minimum requirements for the BLN, although in some instances, additional data transfer between those nodes and the core is also possible.

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

[0111] In some BLNs, users can operate tier 3 or higher nodes, and smart contracts can be run by tier 2 or higher nodes. Users cannot realistically "listen" to the blockchain continuously for transactions with specific output addresses, since this would require constantly monitoring the blockchain 150 for transactions involving specific addresses. Given the ever-increasing number of transactions that can be sent to the blockchain per period, such constant monitoring is impractical 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 blockchain users are expected to increase dramatically in the future. Consider the following example: Alice wants to make a payment to Bob. She creates a transaction for the desired amount with an output address that she 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 every transaction it receives to see if it matches this address. Note that there is no economic incentive for miners to do this. If we assume that miners have to process 1 million transactions per second and check if they match 1 million addresses, we can see that this quickly becomes impractical.

[0112] Instead, in a BLN, Alice can be directly connected to Bob and can send transactions directly to him. Bob can then send the transaction to miners in the core and ask them if they accept it as valid. Because the transaction includes a miner's fee, miners are incentivized to accept the transaction and to confirm whether they accept it, lowering the risk of building a block that will be abandoned. To further secure the system, Alice can send Bob Merkle proofs of Alice's inputs to her transactions. 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 had already spent them, Bob has proof of the double spend because he received a signature from Alice on the transaction that Alice gave to Bob. Note that Bob could be a smart contract (the second node) and Alice could be a user (the external node) who wants to interact with that 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.

[0113] Service providers may operate nodes at tier 2 or higher. The case of service providers is different from that of users or light smart contracts. Service providers may have commercial agreements with core mining nodes or a set of core nodes, which then propagate a specific subset of transactions to the service provider nodes. 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.

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

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

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

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

[0118] Core nodes with Miner IDs can issue digital certificates to Tier 2 nodes. This may 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 Certificate Authorities (CAs).

[0119] With or without a certificate from a core node, a tier 2 node may ask an external CA to issue it 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).

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

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

[0122] Ordering and Timestamping There may be some 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 an attestation 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.

[0123] 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 they could alternatively 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).

[0124] Each of the client nodes may be an end-user node including the computing equipment of a user of the service. This may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, 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 the form of, for example, a memory medium and / or a processor as described above in connection with other network elements or user equipment. The memory stores client software configured to run on the processing device, which, when executed, causes the node to operate as a client of the attestation service provided by attestation node(s) according to any of the following embodiments or similar. Optionally, one or more of the sending end-user nodes may include user equipment 103 of users 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.

[0125] 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 the form of, for example, any of the memory media and / or processors described above in connection with other network elements. The memory stores attestation service software configured to run on the processing device of the attestation node. When executed, the software is configured to provide an attestation service that operates according to any of the embodiments described below or similar. In embodiments, the identity of each attestation node may be certified by a certificate authority so that client nodes, core nodes, and / or other attestation service nodes can verify the identity of the attestation node. The identity of each client node may be certified by a certificate authority so that the attestation service node, core nodes, and / or other client nodes can 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.

[0126] 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 FIGS. 3-6 and also shown, for example, in FIG. 7. That is, the layered network includes a core network including a core node 701, at least one intermediate layer around the core, where each intermediate layer includes one or more intermediate layer nodes 702, and at least one outer layer around the outermost intermediate layers, where each outer layer includes one or more outer layer nodes 703. Note that the term "outer" in "outer layer" here is not necessarily limited to the outermost layer of the entire layered network 700, although this 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.

[0127] As discussed in connection with FIGS. 3-6 , the layered 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, and 703 are configured to form connections between one another at the overlay network level. That is, the nodes 701, 702, and 703 of the layered network are configured to comply with an overlay network protocol that specifies what connections they can and cannot form with other nodes 701, 702, and 703 of the layered network. Thus, while all nodes may be physically connected to one another through the underlying infrastructure (e.g., the Internet), connections between such nodes 701, 702, and 703 may be more restricted when they participate as nodes 701, 702, and 703 of a layered network that operates in accordance with the layered network's 700's associated overlay network protocol. A connection between two nodes 701 / 702 / 703 of the 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).

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

[0129] 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, storage, or forwarding) in the blockchain network 106 other than as clients of the blockchain network 106.

[0130] Each outer tier node 703 is connected to at least one of the middle tier nodes in at least one middle tier. In embodiments, 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 embodiments, the tiered 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 embodiments, 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.

[0131] In an embodiment, the layered 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 layer of the intermediate nodes 702 is a layer between the core and the outermost layer, and each outer layer of the external nodes 703 is a layer outside the second layer (where the intermediate layer(s) are between the core and the outer layer(s)).

[0132] While the following embodiments are illustrated in the context of a hierarchical network, this is not limiting, and it will be understood that 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.

[0133] In an implementation of the hierarchical network 700, at least one of the intermediate nodes 702 in at least one intermediate tier acts as 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 simplicity 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.

[0134] The client nodes 703C are clients at least in that they are clients of the attestation service. In embodiments, client software executing on one or more of the client nodes 703C may be further configured to cause that node 703C to operate 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 cause that node 703C to operate as a client of one or more core nodes 701 (e.g., 104M, 104S) of the blockchain network 106 so as to be able to query the blockchain 150.

[0135] Also, the fact that client node 703C is described as a client 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 additional services to one or more additional entities (not shown). For example, client node 703C may include computer equipment of a company that provides online services to customers. "End user," as used herein, means 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).

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

[0137] 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 having a core of blockchain network nodes 104 / 701. In this case, users of this 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 connection to at least one core node 701 in the core).

[0138] As data elements are received from outer-tier client nodes 703C, the middle-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 core 701 to blockchain 150, where it is immutably recorded. If a timestamp is added to the record, this also records the time as well as the order.

[0139] An example application is to define a deterministic order among updates to entries in a database, etc. 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, such as a left-matrix multiplication, order matters. In another example, one request may be to delete a file and the other may be to read the file. Again, the order in which these requests are applied will have different results.

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

[0141] Another example application is the ordering and timestamping 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 underpin the Internet. In 2011, a Dutch CA was compromised by attackers believed to be from Iran. Fake certificates were issued for well-known domains and log files were altered on the CA's servers. If these log files had been stored on a blockchain using an ordering and timestamping service such as the one described below, the security provided by proof-of-work would have made it impossible to alter them. It is noteworthy that private keys in a company's HSM were compromised in this attack. This highlights the fact that classical cryptographic protocols alone cannot always ensure information security and that it can be beneficial to also rely on other mechanisms, such as proof-of-work, to make such attacks extremely cumbersome.

[0142] In operation, the proving node 702A is configured to receive multiple 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 multiple 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 proving node 702A, or may be forwarded via one or more other nodes in the hierarchical network therebetween (i.e., they may be received via two or more hops between the sending client node 703C and the proving node 702A).

[0143] The proving node 702A is configured to determine the order of the multiple data items D, and thus the sequence of the multiple data items. In an embodiment, the determined order is the order of receipt of the data items at the proving 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 proving 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.

[0144] Whatever the determined order, the attestation node 702A attests 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 may be labeled Tx0, Tx1, Tx2, ... by any terminology herein. 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 transaction Tx in the series of transactions. The payload may be included in the 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 data item order 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 data item sequence.

[0145] The attesting node 702A creates or otherwise determines a corresponding set of public / private key pairs for a set of transactions as follows: P1, P2, P3, …

[0146] The attesting node 702A uses the private key of each key pair to sign the corresponding transaction in the sequence of transactions: Tx0 → Tx1 → Tx2 → Tx3 → …

[0147] Transaction Tx1 includes P1's signature on the unlock script in its input, transaction Tx2 includes P2's signature, and so on. Each transaction also includes a payload containing 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 each signature (in embodiments using a scripting language, an appropriate SIGHASH flag may be used). Initial funding transaction Tx0 is constructed so that it can be unlocked by P1's signature. It may have an outpoint 0 with a dust value. As an example, Tx1 may be constructed as shown in FIG. 8. Subsequent transactions all have the same structure. That is, Tx2 includes a signature using P2 on the input pointing to Tx1 to unlock Tx1, has a lock script on the output that can be unlocked by P3's signature, and so on. The signatures may be verified by the blockchain network 106 based on the corresponding public keys of the key pairs. Funding transaction Tx0 may or may not include an indication of the first set of data items (the first set of data items in a sequence may be indicated in Tx0 or Tx1).

[0148] Note that the configuration 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).

[0149] The OP_RETURN statement contains a payload called data1, which contains, or an indication of, the data element D submitted by the user in the order attested by the attestation service within the set attested by Tx1 (and similarly for data2 in Tx2, etc.). Because each transaction signs the hash of the previous transaction, this also implies an ordering of the payloads data1, data2, data3, etc.

[0150] 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 proven 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, as it would be computationally expensive to replace an existing block.

[0151] In some embodiments, the set indicated in each transaction Tx0, Tx1, Tx2, ... 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 each D's instruction. Examples are shown in Figures 9-11 and described in more detail below.

[0152] When multiple data items D are indicated per transaction, some criteria are needed to determine which data items should be aggregated per transaction. In principle, any scheme can be used to divide the data items among transactions, but in embodiments, 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 series 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 series, and so on.

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

[0154] Each set of data items may be indicated in a transaction simply by explicitly ("in the clear") including the data item(s) of that set in the payload of each transaction Tx. Alternatively or additionally, they may be indicated in a transformed form, such as a hash, an encrypted form, or an r-puzzle. Examples are described in more detail in conjunction with Figures 9-11. In the context of an ordering proof service, at a minimum, the "indication" of a data item herein means some information that allows a query node examining a transaction to verify the attested order of the data items. In some cases where the explicit value of data item D is not explicitly included in the transaction, it may be required that the query node has some knowledge of the value of data item D and simply examines the transaction in the mempool 154 of the blockchain node 104 or on-chain to confirm the expected order of those items.

[0155] In an embodiment, the proving node 702A may also include at least one timestamp in the payload of each transaction Tx0, Tx1, Tx2... in the sequence of transactions. The timestamp indicates the time the respective data item(s) was received at the proving 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.

[0156] 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 data item D. This is possible because the user in the outer tier (e.g., tier 3) is directly connected to the attestation node 702A in the middle (e.g., tier 2). In embodiments, the client node 703 is also directly connected to the blockchain mining node 104M in the core and / or the storage node 104S, so it can independently check that transactions Tx0, Tx1, Tx2... were accepted by the blockchain network 106. Thus, the client node 703A can query the actual blockchain 150 records on the miner's 104M mempool 154 and / or the storage node 104S to confirm that the expected ordering was attested. Other third-party nodes may similarly verify this via any appropriate connection to the blockchain network 106. In some embodiments, queries by client node 703A may be performed via a connection between client node 703C and the core using only the SPV-like connectivity described above in connection with Figures 3-6.

[0157] Optionally, the attestation service can also send the client node(s) 703C that submitted the data items the chain of transactions that preceded the transaction containing those data. This is so that users can be sure that there are no 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.

[0158] In embodiments, client nodes 703C within a tier may also be connected to each other and can send each other (mined) transactions, including their and corresponding Merkle proofs. In embodiments, because each outer tier (e.g., tier 3) node is independently connected to the blockchain 150, 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 assumed.

[0159] Next, consider the OP_RETURN payload data1 in more detail. The goal is for the service to attest to the order in which data elements D1, D2, D3, ... were received within a time interval. Note that the data elements may represent a hash commit of the data associated with each user. Whether a user chooses to make their data public or instead record a hash commit of their data may be at the user's discretion.

[0160] There are several different ways in which the set of data items D and their relative order 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 timestamp service. However, there are smarter ways that provide additional evidence of ordering and allow generalization to distributed timestamp services.

[0161] 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. H 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, and the order is enforced. 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.

[0162] 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 actual value of D does not need to be disclosed if the user does not want to do so. In any case, whether the D value is explicitly included or not, another advantage of hash chains is that they make reordering more difficult. For example, suppose there are 1000 data items D per transaction. Then, to reorder these data items, 1000 hashes would need to be performed, 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.

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

number

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

[0165] The OP_RETURN payload data1 consists of a table as shown in Figure 9. The column "data" may be omitted to save space or to keep 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.

[0166] 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, meaning that only someone who knows the secret key can prove the order of the data.

[0167] Method 1.2: Hash Chaining with Merkle Trees. This is similar to the hash chain in Figure 9, but instead of publishing the entire hash chain, we turn it into a Merkle tree and publish only the root. In this case, each data item D in the set is modeled as a leaf of the 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. A 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 required in the OP_RETURN payload for the Merkle root.

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

[0169] Method 2.1: Chain 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 of the timestamp protocol outlined in RFC3161.

[0170] 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. Similar to 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.

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

[0172] 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 it. See https: / / www.youtube.com / watch?v=9EHKvNuRc0A&t=978s and https: / / www.youtube.com / watch?v=CqqTCsLzbEA.

[0173] 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 to, or in addition to, any of the methods above.

[0174] where R1 is a random ephemeral key, <S1,R 1i >(H(D i )) is the short-term key R 1i The data H(D i ) means

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

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

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

[0178] Assume that a majority of attestation nodes 702A behave honestly and wish to reach consensus for ordering and time-stamping data propagated around 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 overloaded (too many connections).

[0179] The problem to be addressed then is how, in such a distributed case, intermediate tier certification nodes 702A (e.g., tier 2 nodes) can agree on a consensus on the ordering of, for example, two data items D1, D2 submitted by two users, even if they arrive in a different order at one certification node 702A compared to another.

[0180] 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, rather than just one. Consider an M-of-N threshold signature system as described, applied to the attestation service node 702A. This is achieved by using private key shares a1, a2, ..., a N This means that there are N participating nodes with M participants. Any subgroup of M participants can generate signature shares that, when combined, give the signature of a message that unlocks the previous transaction in the chain of transactions.

[0181] Assume that one of the attestation service nodes 702A generates a candidate transaction Tx1 that includes an OP_REUTRN payload data1, which is an ordered list of all data elements D that it has received within a selected time period. 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 its 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 M-of-N timestamp-granting services in the decentralized network.

[0182] How is a single attestation node 702A selected to create a transaction? The above assumes that there is only one attestation service node 702A that created candidate transaction Tx1, 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 to create the next transaction. This may be a predetermined random sequence, or it may be a deterministic random selection based on a seed for the just-submitted transaction Tx1. For example, the seed may be taken to be Tx1. Other distributed arbitration algorithms for distributed computing may also be possible.

[0183] Distributed Database FIG. 12 illustrates an example of a distributed database implemented in a hierarchical network 1200 according to an embodiment disclosed herein.

[0184] Layered network 1200 includes a core network including one or more core nodes 1201, at least one middle tier around the core, each including one or more middle tier nodes 1202, and at least one outer tier around the outermost of the middle tiers, each including one or more outer tier nodes 1203. Again, the term "outer" in "outer layer" here is not necessarily limited to the outermost, although that is one possibility. Layered network 1200 may be an overlay network overlaid on an underlying physical or infrastructure network such as the Internet, or alternatively, may be a standalone network such as a dedicated and / or internal (e.g., private) network within an organization.

[0185] The core nodes 1201 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).

[0186] In some cases, some of the middle tier nodes 1202 and / or outer tier nodes 1203 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, storage, or forwarding) in the blockchain network 106 other than as clients of the blockchain network 106.

[0187] The intermediate nodes 1202 include multiple database nodes 1202DB across one or more intermediate tiers of the hierarchical network 1200. These database nodes 1202DB are configured to store a distributed database, with each database node 1202DB storing at least a portion of the entire database, including one or more database entries. In an embodiment, entries are replicated across two or more nodes such that at least some entries are replicated across two or more database nodes 1202DB. In some cases, each database node 1202DB may store a copy of the entire database, but in other embodiments, each database node 1202DB may store only a portion of the database, and each entry may be replicated across only some, but not all, of the database nodes 1202DB (distributed such that the database nodes 1202DB between them store the entire database).

[0188] Each database node 1202DB 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, which may take any of the forms of a memory medium and / or processor, for example, as described above in connection with other network elements. As well as the database entries themselves, the memory stores database software configured to run on the processing device of the attestation node. This software, when executed, is configured to provide a database service that operates according to any of the embodiments described below or similar.

[0189] In embodiments, the identity of each database node 1202DB may be certified by a certificate authority so that client node(s) 1203C, core node 1201, and / or other database nodes 1202DB or other middle-tier nodes (e.g., attestation service node 702A or smart contract nodes) can verify the identity of the database node 1202DB. Interactions between such nodes may be conditional on verification. For example, client node 1203C may send an update request to database node 1202DB only on the condition that it verifies its identity based on the attestation. Alternatively or additionally, node versioning may be used as an alternative mechanism for node identification in the overlay network.

[0190] Each of the client nodes 1203C may be an end-user node comprising the computing equipment of a user of the service. Again, this may be an individual user or an organization, such as a company, academic institution, or government agency. Accordingly, each client node may comprise one or more user terminals and / or a server comprising one or more server units at one or more sites. Each client node comprises a memory comprising one or more memory units and a processing device comprising one or more processing units. These may take the form of, for example, a memory medium and / or a processor as described above in connection with other network elements or user equipment. The memory stores client software configured to run on the processing device, which, when executed, causes the node to operate as a client of a distributed database provided by a database service provided by database node 1202DB according to any of the following embodiments or similar. Optionally, one or more of the sending end-user nodes may comprise user equipment 103 of users 102 of the blockchain network 106, and the client software may include a blockchain wallet application 105 or the like.

[0191] In embodiments, the identity of each client node 1203C may be certified by a certificate authority so that database node 1202DB, other intermediate nodes (e.g., attestation service node 702A or smart contract nodes), core node 1201, and / or other client nodes 1203C can be validated or the identity of the client node 1203C can be verified. Interactions between such nodes may be subject to verification. For example, database node 1202DB may receive an update request from a client node 1203C only on the condition that it has verified its identity based on the attestation. Alternatively or additionally, node versioning may be used as an alternative mechanism for node identification in an overlay network.

[0192] In embodiments, hierarchical network 1200 may be configured according to any of the protocol rules or structural features described in connection with Figures 3-6 and / or 7. When hierarchical network 1200 is an overlay network overlaid on an underlying infrastructure network such as the Internet, nodes 1201, 1202, 1203 are configured to form connections between each other at the overlay network level. That is, nodes 1201, 1202, 1203 of the hierarchical network are configured to follow an overlay network protocol that specifies what connections they can and cannot form with other nodes 1201, 1202, 1203 of the hierarchical network.

[0193] For example, in an embodiment, each middle tier node 1202 is connected to at least one core node 1201 (blockchain network node 104) in the core network. The core network includes at least a portion of the blockchain network 106. In an embodiment, the core network may itself be a complete network (i.e., a complete graph). Each outer tier node 1203 may be connected to at least one of the middle tier nodes in at least one middle tier. In an embodiment, each outer tier node 1203 also has at least one connection to at least one core node 1201 (i.e., the blockchain network). In some such embodiments, one or more of the outer tier nodes 1203 each have connections to two or more, but not all, of the core nodes 1201. In an embodiment, the tiered network 1200 as a whole may be a non-complete network, i.e., not all nodes 1201, 1202, 1203 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 1202 in a middle tier may be connected to one or more other nodes in the same middle tier, and / or each node 1203 in an outer tier may be connected to one or more other nodes in the same outer tier. In embodiments, connections may also be formed between different middle tier nodes 1202 in different middle tiers and / or different outer tier nodes 1203 in different outer tiers.

[0194] A connection between two nodes 1201 / 1202 / 1203 of a layered network 1200 means that these nodes can communicate directly, which in this context means that there is no need to perform a hop through another node 1201 / 1202 / 1203 of the layered network 1200. 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).

[0195] For simplicity of explanation, only two client nodes 1203C and two database nodes 1202DB are shown in Figure 12, but it will be understood that there may be more. In an embodiment, client node 1203C and database node 1202DB may be part of the same community as each other.

[0196] The client nodes 1203C are clients at least in that they are clients of the database service. In embodiments, client software executing on one or more of the client nodes 1203C may be further configured to cause that node 1203C to operate as a client of one or more additional services provided by one or more second-tier nodes 1202, such as an ordering proof service or a smart contract service. And / or may be configured to cause that node 1203C to operate as a client of one or more core nodes 1201 (e.g., 104M, 104S) of the blockchain network 106 so as to be able to query the blockchain 150. Also, the fact that the client nodes 1203C are described as clients of the database service (and optionally one or more other services) does not preclude the possibility that these nodes may themselves also be servers of one or more additional services to one or more additional entities (not shown). For example, the client node 1203C may include the computing equipment of a company that provides online services to customers over the web.

[0197] In some embodiments, the hierarchical network 1200 of FIG. 12 may be the hierarchical network 300 of FIG. 3 or FIG. 4, in which case the outer tier node 1203 of FIG. 12 is the third tier node 303 of FIG. 3 or FIG. 4, the middle tier node 1202 of FIG. 12 is the second tier node 302 of FIG. 3 or FIG. 4, and the core node 1201 of FIG. 12 is the core node 401 of FIG. 3 or FIG. 4.

[0198] In some embodiments, tiered network 1200 of Figure 12 may be tiered network 700 of Figure 7, where outer tier node 1203 of Figure 12 is outer tier node 703 of Figure 7, middle tier node 1202 of Figure 12 is middle tier node 702 of Figure 7, and core node 1201 of Figure 12 is core node 701 of Figure 7. In such embodiments, the attestation services of attestation node 702A may be integrated into some or all of the same middle tier nodes 702 / 1202 as database node 1202DB, and / or attestation node 702A may include separate middle tier nodes 702 / 1202 in the same and / or different middle tiers within the same and / or different communities.

[0199] During operation, database node 1202DB receives update requests from one or more of client nodes 1203C. Multiple update requests may be received from the same client node 1203C and / or different client nodes 1203C. In an embodiment, each update request may be received directly on one of the tiered network connections between the relevant outer and middle tiers (e.g., tier 2 and tier 3) between the requesting client node 1203C and the receiving database node 1202DB. Alternatively, the update request may be received indirectly via two or more hops (see below), such as by being forwarded from another of database nodes 1202DB that was the intended recipient of the request from the originating client node 1203C. If indirect, the message may propagate via connections within tiered network 1202 between middle tier nodes 1202 (in the same and / or different middle tiers).

[0200] Each update request is a request to update a specific respective target entry in the database. For each such request, the receiving database node 1202DB determines whether the request is addressed to the receiving database node 1202DB itself or to another one of the database nodes 1202DB, i.e., the respective target entry that the request intends to modify is found in a portion of the database stored locally on the receiving database node 1202DB or another database node 1202DB. Note that if a data entry is replicated across multiple database nodes 1202DB, the target entry may be found in both the receiving database node 1202DB and one or more others. It is also possible that a request may be addressed to multiple other database nodes other than the receiving database node.

[0201] Each update request includes data content, i.e., the actual update to be made. This may be expressed in absolute terms, i.e., replacement data to replace some or all of the existing content of the target entry. Alternatively, the content of the update may be expressed in the request as a delta, i.e., the modifications to apply to the respective target entry. The data content may include the full version of the final user data the user wants stored, or it may explicitly take the form of a fingerprint or compressed version of the user data rather than the full version itself. In either case, if the update is destined for the receiving database node 1202DB, the receiving database node may locally apply the requested update to a copy of the relevant target entry stored locally on the receiving node 1202DB; if the update is destined for one or more other of the database nodes 1202DB, the receiving database node 1202DB forwards the update request to the relevant database node(s) 1202DB to apply it to the copy of the target entry stored therein. Again, note that both can occur if entries are replicated across database nodes 1202. If desired, updates can be propagated between database nodes 1202, within a middle tier and / or over connections between different middle tiers.

[0202] It should also be noted that client node 1203C may send update requests to each of multiple recipient database nodes 1202DB, in which case each recipient database node 1202DB may behave as described above.

[0203] In addition to being recorded in one or more database nodes 1202DB, in accordance with the present disclosure, the indication of each update request is also recorded in the blockchain 150 via one of the connections to the core 1201. This helps build consensus among the nodes of the network to improve consistency among the database nodes 1202DB.

[0204] The instruction for the update is sent in transaction 152 to one of the core nodes 1201 to be mined into block 151 and thus recorded on the blockchain. This may be sent by the requesting client node 1203C. In this case, one or more of the database nodes 1202DB may query the blockchain 150 (or the miner's mempool 154) to check that the requested update has been recorded on the chain (or accepted by the mempool 154). For example, the database node 1202DB may apply the update only if it confirms this. The check may be performed directly on the connection in the hierarchical network 1200 between the database node 1202DB and one or more of the core nodes 1201, or alternatively, may be performed by proxy over two or more hops.

[0205] In an alternative scenario, a transaction containing an instruction for an update may be sent to the core 1201 by one of the database nodes 1202DB in response to receiving an update request. In this case, the requesting client node 1203C (or a third-party node) may check that the expected update has been recorded on the blockchain (or accepted into the miner's mempool 154). This check may be performed directly on the connection in the hierarchical network 1200 between the client node 1203C and one or more of the core nodes 1201, or alternatively, may be performed by proxy over two or more hops.

[0206] In a further alternative, a transaction containing an instruction to update may be sent to core 1201 by a third-party service in one of the intermediate tiers, such as attestation service 702A. This may be sent directly or by proxy. One or more of requesting client node 1203C and / or database node 1202DB may check that the expected update has been recorded on-chain (or accepted into mempool 154). Again, this check may be performed directly (single hop) or by proxy (two or more hops).

[0207] The "instructions" for an update to be recorded on the chain may or may not explicitly include the actual content of the update itself (in either absolute terms or deltas). Alternatively, or in addition, it may include a transformation of the update, such as a hash of a pre-image, where the pre-image contains the update. This may be called a "hash commit." If only a hash commit or the like is recorded, this allows a node to check that a known update has been recorded on the chain (or accepted into the miner's mempool 154), but a third party without knowledge of the update would not be able to see it. The hash may also be stored smaller than the content itself.

[0208] In one advantageous configuration, if a database node 1202DB is temporarily disconnected from the hierarchical network 1200, it can check for any relevant updates using the records stored on the blockchain 150 and make that / those updates when it comes back online. Again, this check may be performed directly on the connection in the hierarchical network 1200 between that database node 1202DB and one or more of the core nodes 1201, or may be performed indirectly via two or more hops.

[0209] For example, this can be used to address the potential problem of "zombie records," a term known in the art. In some distributed databases, when a node disconnects, it may miss updates in the form of deletions. If, by the time the disconnected node reconnects, all other nodes have completely erased the deleted entry, the node may re-propagate the deleted data as if it were a new entry to be added to the database. However, this can be avoided by storing a record of the deletion on-chain. In another advantageous scenario, on-chain records can be used to provide a "hinted handoff." Hinted handoff is a technical term. Here, "handoff" means providing an update to a database node when it reconnects after being disconnected for a period of time, and the hint includes the IDs of one or more database nodes that are the target of the update (i.e., that store the portion of the database containing the relevant entry or entries). It may also include other fields. Suppose database node 1202DB receives an update request that needs to be propagated to another database node 1202DB, but that other database node 1202DB is currently disconnected from hierarchical network 1200. Traditionally, the receiving database node 1202DB would have to store the update, including the hint, until the other database node 1202DB is back online. However, by recording the hint on-chain instead, the receiving database node 1202DB does not need to do this.

[0210] Another example of an instruction that may alternatively or additionally be stored on the chain is ordering information. In some scenarios, multiple update requests requesting to update the same target entry may be received at the same database node 1202DB that stores that entry. To accommodate this, database node 1202DB may be configured to apply updates to the target entry in a specified order. In some embodiments, the specified order may be based on the receipt time at the receiving database node 1202DB or a timestamp added by the sending client node 1203C or the forwarding database node 1202DB (e.g., the receipt time at the database node 1202DB that first received the request directly from the sending client 1203C). Alternatively, the specified order may be asserted in one or more of the update requests from the client, or in a message from another intermediate tier node 1202A, such as another of database node 1202DB or certification service node 702A, or from core 1201. For example, the order may be asserted in the form of an ordered list of multiple updates, or an ordinal index mapped to each update request.

[0211] In an embodiment, the specified order may be recorded on the blockchain 150, for example, by the attestation service 702A described above. In such an embodiment, the requesting client node 1203C may obtain the order from the attestation service 702A and submit it to the database node 1202DB. In this case, the order attestation service 702 records the order on the blockchain 150 and returns a message including the specified order to the requesting client node 1203C (which is also the client 703C of the attestation service 702A). When the client 1203C makes update requests to the database node 1202DB, it also submits the order obtained from the attestation service 702A in at least one of the update requests to the database node 1202DB. The database node 1202DB checks this against the order recorded on the blockchain (or in the miner's mempool 154) and then applies the updates in the specified order, provided that the order submitted by the client 1203C matches the order recorded on the blockchain 150. This check may occur directly via the connection between database node 1202DB and core 1201, or alternatively via two or more hops.

[0212] Alternatively, the updating database node 1202DB can read the order directly from the blockchain 150 and apply the order read from the blockchain 150 (or the miner's mempool 154).

[0213] In another variation, the attestation service 702A may be integrated into one or more of the database nodes 1202DB. In this case, one of the database nodes 1202DB is responsible for determining the order (and optionally adding a timestamp) and recording it in the blockchain 150. The database node 1202DB responsible for the order may propagate the specified order to other database nodes 1202DB over connections between nodes in the intermediate tier(s). The other database nodes 1202DB may check this against the order recorded in the blockchain, or alternatively, may read the order directly from the blockchain 150 (or in the miner's mempool 154). This may be done directly via a connection between the database node 1202DB and the core 1202, or alternatively, via two or more hops.

[0214] Ordering information is particularly (but not exclusively) useful in scenarios in which different update requests experience different delays as they propagate throughout the middle tier(s) of tiered network 1200. For example, consider a scenario in which a first update request is issued by a respective client node 1203C earlier than a second update request from another client node 1203C, but the second update request arrives at the database node 1202DB storing the target entry later than the first update request. For example, this may occur because the first update request must pass through a firewall that the second update request does not pass through and / or because it is sent from a geographically more distant location. Use of ordering information according to embodiments herein may be used to address such situations and ensure that the updates are applied in the order in which they were issued or in the order in which they were originally received by the immediate database node 1202DB to which they were originally submitted.

[0215] Note, however, that this is not required. More generally, it is not required that the order be the order of issuance or initial receipt, as long as there is consensus on some deterministic order. As long as some deterministic order is agreed upon, any given entry in the distributed database will have a deterministic state (at least eventually), and this order can be independently re-derived and verified in a consistent manner by any of the database nodes (or client nodes).

[0216] To illustrate some of the principles behind the disclosed scheme, a specific implementation will now be described as an example. By way of example, we will refer to a database node implemented in tier 2 and a client (user) node in tier 3, but this can be generalized to any middle tier and outer tier, respectively.

[0217] One reason for using a tiered network is that nodes in tier 2 should preferably store consistent data, but may not all be directly connected to each other. Data consistency relates to the order in which data and commands are sent and received, and therefore to how data is transformed in the data store. For example, if there are two requests to perform a non-commutative operation on data elements, such as left-matrix multiplication, the order is important. Another example might be that one request is to delete a file and the other is to read the file. Again, the order in which these requests are received is important. To prevent conflicts, it would be desirable to define an ordering for data insertion. This can be achieved with the blockchain as a central coordinator.

[0218] Incentives for transaction and data propagation may be provided by service level agreements. Database nodes will propagate transactions throughout the community to ensure that the database is consistent, just as they propagate data and transactions into Layer 2. This may be a requirement to honor their service level agreements. Users of data may propagate it into Layer 3 and include transactions and Merkle proofs as proof of authenticity and immutability.

[0219] Layer 2 nodes can be issued digital certificates. Users in layer 3 nodes can also be given digital certificates. There can be an entire PKI (Public Key Infrastructure) going down the layers, which can be on a blockchain that uses UTXOs for the PKI concept.

[0220] For comparison, a distributed database implemented in a non-hierarchical network that does not employ a blockchain and does not have a core of blockchain network nodes is referred to. An example of such a comparative database is the existing Cassandra database.

[0221] In traditional database theory, the CAP theorem (or Brewer's theorem) states that it is possible to achieve only two of the three main desirable properties of a database system: · Consistency - data read from the database always corresponds to the most recent write; Availability - data can always be read from the database on demand; and Partition Tolerance - The system continues to operate even in the event of a network partition.

[0222] The presently disclosed approach can be used to address this trilemma.

[0223] The Cassandra database management system is a highly available, partition-tolerant database architecture that satisfies two of the three aspects of the CAP theorem, but at the expense of data consistency.

[0224] The basic architecture of the Cassandra database system is a distributed set of nodes that store indexed data as part of a Cassandra node cluster. In the cluster, all nodes are considered equal, and there is no distinction between "slave" and "master" nodes as there is in other distributed systems. As a result, the Cassandra nodes in the cluster form a complete graph, and every node can identify and communicate with every other node in the network. This architecture is illustrated in Figure 13(a), which shows a Cassandra node cluster 1300 with Cassandra network connections 1399 between every pair of Cassandra nodes 1301.

[0225] Data to be stored in the database is partitioned among nodes and is typically replicated by multiple nodes to enable high availability and tolerance to node network partitions, as shown in Figure 13(b), which shows three exemplary data partitions: Data Partition 1 (1301), Data Partition 2 (1352), and Data Partition 3 (1353).

[0226] The number of Cassandra nodes to which a data item is replicated is known as the cluster's replication factor. A replication factor of 3 means that each data item is replicated on three nodes on the network.

[0227] The consistency of data stored among nodes of a Cassandra cluster is effectively the probability that the data returned by a node in response to a read request is in fact the version of the requested data most recently written to the Cassandra cluster. The consistency level of a Cassandra cluster can be set for read and write operations and can be configured to meet the needs of a particular use case.

[0228] This disclosure introduces new methods for improving the processes used to achieve higher consistency in Cassandra databases, which typically intentionally sacrifice consistency for performance.

[0229] Data Centers and Clusters: The Cassandra architecture uses two definitions for node multiplicity. Data Center - A collection of related nodes, which can be physical or virtual. A single data center may be used to maintain a complete copy of the database and may be housed in a single geographic location. Cluster - A cluster is a collection of data centers for a Cassandra database. A cluster can span multiple physical locations.

[0230] It will be seen later that data centers and clusters can be replicated using a network structure of a hierarchical network with a core of blockchain network nodes.

[0231] Write and Read Paths: In a Cassandra database system, there are generally two ways in which nodes can communicate, called inter-node communication. These are: Direct communication - In general, every node in a Cassandra cluster can communicate with every other node. This is the basis for considering a Cassandra cluster as a complete graph. Messages sent directly between any pair of nodes in this way relate to write and read requests. Gossip Protocol - A peer-to-peer communication protocol used by Cassandra nodes to exchange state messages. Messages are gossips once per second between a node and up to three other nodes in the cluster. This is used to communicate node state and therefore enables failure detection of compromised or unreachable nodes.

[0232] When a client reads or writes data using a Cassandra cluster, the client may choose to communicate with any node in the cluster as the nodes are treated promiscuous. The node selected by the client becomes the coordinator node for executing the particular read or write request being made by the client.

[0233] This involves the coordinator using the client's request to identify which nodes in the cluster need to be written / read from, and then fetching data from or writing data to those nodes accordingly.

[0234] Figure 14 illustrates different communication paths in a Cassandra cluster graph. Nodes communicate status messages via gossip (dashed line 1402) and write / read requests via direct communication (thick solid line 1401). Figure 14 shows a client 1403 sending a read or write request 1404 to a coordinator node 1301c (solid black), which then sends gossip messages to multiple replica nodes 1301r (cross-hatched).

[0235] Data Logging and Writing: Broadly speaking, the hardware components of a Cassandra node 1301 include: Disk: - Commit Log - An append-only log of all mutations made to a Cassandra node. - SSTables - Immutable data files used to persist data on disk within a Cassandra node. Memory: - Memtable - An in-memory structure where Cassandra nodes buffer data from write requests.

[0236] These components of a Cassandra node interact during the write path that is executed when the node receives a write request from the coordinator node, as shown in Figure 15. The Cassandra node 1301 comprises a disk 1501 containing a commit log 1503 and SSTables 1504, and a memory 1502 containing a Memtable 1505.

[0237] The process of FIG. 15 detailing a write request serviced by node 1301 is as follows: (S1) A write request (mutation) is recorded in the commit log 1503. (S2) The write data blob and index are stored in memory 1502. (S3) Flushes data and indexes from memory to disk 1501.

[0238] The importance of this interaction relates to the fact that the Cassandra database system is an AP (Availability, Partition Tolerance) database, which sacrifices consistency according to the CAP theorem.

[0239] As an AP system, the Cassandra database relies on an eventual consistency model, which means that the database reflects the latest mutations at a point in time after the mutations are made. The assumption in achieving eventual consistency is that the order of operations for each mutation made to the nodes in the cluster is recorded and maintained. This is done using an on-disk commit log to ensure that mutations to data stored in SSTables are made in the correct order.

[0240] This disclosure introduces methods for improving the process, examples of which are described in more detail below, in which the use of a layered network with a blockchain node core can improve the mechanism for reaching eventual consistency.

[0241] Data Removal: Removal of data from Cassandra database nodes uses a combination of the following techniques: Upsert - The Cassandra database treats a deletion as a kind of insertion (an "upsertion"), where a new version of the data is inserted with a more recent timestamp. Tombstone - In the case of a deletion, the new record that is written is called a tombstone, which is simply a deletion marker for that data. The tombstone marker has an expiration time built into it, after which the data will be deleted by compaction. Compaction - The process of compaction is a mechanism for removing data marked with tombstones. It involves taking all existing versions of that row of data and deleting all but the most recently timestamped version. Time-to-live (TTL) - A marker that can be added to data as an upsert, indicating when the data row will be marked with a tombstone and deleted accordingly.

[0242] There is a known issue inherent to Cassandra's distributed replication model known as zombie records. If a node is unreachable during the deletion of a row of data (i.e., tombstone and compaction), when that node rejoins the cluster it will treat the record as new and attempt to forward it to other replica nodes. Since other replica nodes that were online during the record deletion have already deleted the record, it is known as a zombie record.

[0243] The embodiments described herein provide methods for mitigating the possibility of zombie records in a distributed database system, examples of which are described in more detail below.

[0244] Write Repair: Repair during the write path (hinted handoff). If one (or more) of the replica nodes to which a data write should be performed is unreachable, the coordinator node for that write request may store a local copy of the missed write data as a hinted handoff. Hinted handoffs include: · Node ID of the unreachable node; · A hint ID that serves as a timestamp for the data; A message ID that identifies the Cassandra version; and A data blob of data to be written.

[0245] When an unreachable node (identified by its node ID) comes back online, the coordinator is responsible for regenerating the hint to that node and effectively forwarding write requests to that node after the fact. This necessarily imposes both disk space and processing burdens on the coordinator to update unreachable nodes when they rejoin the network.

[0246] Embodiments disclosed herein use a hierarchical network with a blockchain node core to improve this repair process by reducing the burden on the coordinator, examples of which are described in more detail below.

[0247] Integrating a Distributed Database into a Layered Network: This disclosure provides a modification to a Cassandra-type database system or the like so that the distributed database becomes part of a layered network 1200 with a cluster of blockchain network 1201 / 104 nodes at its core. This structure includes at least the following layers: Blockchain Core Layer (i=1)—The innermost layer of the hierarchical network, preferably exclusively containing blockchain network peers 104 that form a complete graph. Database Node Layer (i=2)—the layer containing nodes of a distributed database cluster that does not form a complete graph (e.g., this could be the database cluster of an over-the-top (OTT) content provider). User / Client Tier (i=3) - The tier containing users of the system or application backed by the distributed database (e.g., users of an OTT service).

[0248] For convenience, this type of network may be referred to herein as a "Blockchain Layered Network" (BLN).

[0249] Figure 16 shows how other traditional clusters can be merged to form a BLN by removing intra-shell connections (breaking the integrity of the intra-shell graph) and introducing connections from database nodes to blockchain core ancestor nodes.

[0250] The figure shows this transformation for two separate clusters of different sizes, and for simplicity the external user layer is not shown.

[0251] Figure 16 shows two examples of integrating a complete (e.g., Cassandra) node cluster (left) into a BLN (right). In the LHS, the nodes form a complete graph. In the RHS, the nodes form a sparser graph layer (i>1) coordinated by a blockchain network central core (i=1) with connections from database nodes to their set of BLN core ancestors.

[0252] An example of a complete BLN including all three tiers of the network is shown in Figure 17. The phrase BLN Implemented Distributed Database (BLNiDD) may be used generally herein to refer to a BLN in which a cluster of distributed database nodes constitutes one of the middle tiers around a core.

[0253] In a particular embodiment, the following provisions may be made regarding the behavior of Cassandra nodes in the i=2 layer of the BLN: Database nodes can use the same gossip protocol or something similar for state messages. Database nodes may also propagate transaction messages between them using the same gossip protocol or similar. Database nodes may use direct communication of write and read requests to pairs of directly connected nodes where i=2.

[0254] Communities in BLNiDD: The existing definitions of datacenters and clusters in the Cassandra architecture can be applied to BLNiDD: a datacenter is simply a set of database nodes that belong to a single community in BLNiDD, and a cluster itself is an entire tier (i=2) of database nodes from all communities in BLNiDD.

[0255] Public Key Infrastructure: To improve reliability, it would be desirable to ensure that communications between nodes in the database node cluster (i=2) and users (also nodes in the BLN graph, i=3) are trusted. This can be achieved by implementing a network-wide Public Key Infrastructure (PKI) for the BLN.

[0256] A PKI implementation for a BLN, including a database cluster and its users, may include: User PKI (i=3): - User public keys to n3 users of the database, which may be assigned by the administrator (i.e., DBA) of the database

number

number

[0257] As an extension of the above, it may be possible to implement aspects of both the user PKI and the database node PKI entirely on-chain. Using the MinerID system, the blockchain network core PKI is also on-chain, which would mean that the entire PKI implementation for this BLN architecture could be feasibly implemented on-chain. The MinerID system is disclosed, for example, at https: / / www.youtube.com / watch?v=ZSfT_WtBmyQ&feature=emb_title.

[0258] FIG. 18 shows an example of a BLN-implemented distributed database where PKI is implemented at least at layer i=2,3.

[0259] Exemplary Methods: Blockchains can be used to facilitate a more robust, auditable, and verifiable mechanism for reaching eventual consistency compared to, for example, a Cassandra database. This can be done by integrating database clusters into a BLN, as described above. For any of the following methods, the following can be used: PKI for the BLN layer, and / or A method for ordering timestamped events.

[0260] In the following methods, we outline several ways in which blockchain, and more specifically the BLN built on its core network, can be used to improve distributed database systems by solving several distinct but related problems.

[0261] Method 1 - Use of BLN to improve eventual consistency and / or mitigate zombies. The Cassandra database is an AP system, which means that it sacrifices data consistency according to the CAP theorem and instead uses an eventual consistency mechanism. In doing so, the order of operations is important, and failures can result in zombie records propagating through the database.

[0262] In a multi-node cluster, different database nodes may store replicas of the same data. When a node receives a delete request for data it stores locally, it tombstones the specified database entry and attempts to forward the tombstone to other nodes that contain replicas of the same record. However, if one replica node is currently unreachable, it will not immediately receive the tombstone and will therefore still contain a record of the previous version of the delete operation. If the "tombstoned" record was already deleted from the rest of the cluster before that node recovered, the entries on the now-recovering node may be treated as new data when it comes back online, so they may be propagated to the rest of the cluster as new additions. This is called a zombie record.

[0263] To address such issues and more, BLNiDD may be used instead of a simple Cassandra system, leveraging the blockchain core network as a central coordinator to determine the ordering of operations that leads to eventual consistency. The ordering becomes immutable and publicly verifiable. Database nodes in stratum i=2 propagate all state mutations by hash of data blobs using gossip (or other such protocols) rather than direct communication.

[0264] In other words, the order of operations may be important, and it may be desirable to reach a precise state of eventual consistency. To address this, the database cluster (incomplete graph) at layer i=2 uses the blockchain core network at i=1 to order events and guarantee eventual consistency. The concept of eventual consistency ties in nicely with the fact that the blockchain will (i.e., eventually) collapse to an immutable state after a number (e.g., six) blocks.

[0265] This is also applicable to the re-onboarding process for nodes that have temporarily left the network. Other nodes can communicate the state change using gossip or similar and provide a Merkle proof to prove to the node that the state change actually occurred / was requested. Here, the database node can be something like an SPV. With regard to re-onboarding, this demonstrates the robust properties of the BLN.

[0266] The method may operate as follows. 1. A user / client makes a read / write request to a database node. The user / client simultaneously creates and broadcasts a read / write request transaction and sends it directly to the blockchain core layer. The user / client also sends the TxID of this transaction to the coordinator database node. 2. The coordinator acts as usual by identifying the relevant nodes to which the read / write request pertains. Depending on the request type, the coordinator does the following: a. Read Request: Since no state mutation is required on any node, the coordinator operator simply forwards the request to the relevant nodes via gossip or direct communication (if directly connected). b. Write Request: Because a state mutation is required for a write, the coordinator must propagate both the request and the data to the relevant replica nodes (via gossip or direct connections). c. In either case, the coordinator also propagates the TxID of the write request to the relevant nodes as proof of the ordering of the operations. 3. Upon receiving the request and data from the peer, the replica nodes verify from the core that the request they received matches the request details in the request transaction and return an acknowledgement to the coordinator. In an embodiment, the replica nodes need only apply the updates to their own local records, subject to this check. 4. The coordinator returns: a. Success or failure message to the user / client. b. Optional: Success or failure transaction to the blockchain core layer for mining.

[0267] An exemplary read / write transaction is detailed in Figure 19 below.<request data> The packet may contain a unique request ID, the ID of the coordinator node for the request, and a key for the row of data being requested.

[0268] The new read / write path for this method is shown in Figure 20. The main differences from the standard Cassandra read / write path are: Users / clients submit their read / write requests to the database cluster and the blockchain core layer in parallel; and Nodes in a database cluster may propagate requests and data using either gossip (or something like that, i.e. indirectly) or direct communication, depending on the distance between the coordinator and the relevant replica nodes for the request.

[0269] One benefit is that it reduces the burden on the coordinator to ensure replica nodes reach the same eventual consistency by repeating the correct order of operations, which is offloaded to the Bitcoin network. Another benefit is that it reduces the possibility of zombie records, since the order of operations (including deletions) that a node misses while offline is remembered and recoverable from the blockchain.

[0270] Method 2 - Reduce the load on the coordinator node during hinted handoff. Traditionally, in distributed databases such as Cassandra, if a replica node is unreachable during the write path, a hinted handoff is written to the coordinator node. This places an additional burden on the coordinator to help the replica rejoin the network by storing the hint locally and forwarding it to the rejoining node. Hinted handoffs can also time out, violating eventual consistency of the data.

[0271] To address this using BLNiDD, hinted handoffs can be written to the blockchain by propagating them to the blockchain core layer for immutable ordering. When a node rejoins the network, it can query the blockchain core layer for hints associated with it (e.g., using its node ID and / or PKI). Optionally, at least one replica node has written the data for the write request, which the rejoining node can use to retrieve the write data blob (rather than also storing the blob on the blockchain).

[0272] The method may operate as follows. 1. A user / client makes a write request to a node (coordinator) with a replication factor, say replication factor 3. a. Optional: The user / client also sends a record of the request to the Bitcoin Core layer. 2. The coordinator identifies the three nodes to which the data should be written and forwards the write request. 3. Two of the nodes write the data and respond affirmatively to the request, but the third is unreachable. 4. The coordinator returns an acknowledgement to the user / client, writes a hinted handoff transaction (see Figure 21), and broadcasts it to the blockchain core layer for mining. The hinted handoff includes: a. The node ID of the unreachable node, ID3; b. Hint ID to timestamp the data; c.Message ID; d. The node IDs of the two replicas to which the data was successfully written, ID1 and ID2; e. The hash of the data blob to be written. f. Optional: The data itself 5. The unreachable node rejoins the network and queries its connections in the blockchain core network for an upcoming hinted handoff. Upon getting a hinted handoff, the node shall: a. Get data blobs from nodes ID1 and / or ID2; i. Optional: If the blob is included in a hinted handoff, just get the blob. b. Verify that the data blob hashes to the hash in the hinted handoff; c. Assuming no other operations were overlooked (these are also identified by their own hinted handoffs), write the data blob to its local disk.

[0273] FIG. 21 shows an example of a hinted handoff transaction.

[0274] Method 3 - Re-onboarding improves database node security. If a Cassandra node becomes compromised / partitioned from the rest of the cluster, it must be re-onboarded at a later time. This involves retrieving and implementing all local database mutations that were requested for that node while it was unreachable.

[0275] Typically, a Cassandra cluster can be considered a trusted environment where all nodes in the cluster trust each other to propagate and communicate these missed mutation requests. However, it would be desirable to improve the rejoin process for database nodes so that they do not have to trust other nodes to send the correct missed mutation requests to them.

[0276] This can be advantageous in preventing many nodes in a distributed database from being compromised by a sophisticated attacker who wishes to propagate erroneous mutations from the compromised node.

[0277] This advantageous reduction in reliance on trust may be achieved by using BLNiDD and a rejoining protocol (described below) that requires rejoining nodes to obtain missed mutation requests from signed transactions (confirmed or unconfirmed transactions may be used) obtained from the blockchain core network.

[0278] A trustless rejoin protocol could be as follows: 1. Node ID 1 is partitioned from the database cluster for a significant period of time. During this time: a. Several write requests (including upserts) are made to data replicated by ID1. b. Node ID 1 cannot be sure whether it was partitioned due to a malicious attack, which means that the node must rejoin the network, assuming that other nodes may be similarly compromised and may be under the control of the attacker. 2. When rejoining, the rejoining node retrieves the missed mutation request from the signed transaction retrieved from the blockchain core network.

[0279] This is similar to Method 1, but uses the blockchain core network to time-order events, allowing recently compromised nodes to directly query to be re-onboarded into the database cluster, rather than relying on other database nodes to provide the correct updates.

[0280] In some embodiments, Merkle proofs may be used for re-onboarding.

[0281] The benefit of the above is that the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations is reduced; this is offloaded to the blockchain network.

[0282] Method 4 - Replicate or replace the commit log on all nodes with a transaction set. A requirement for all nodes in a Cassandra cluster is that they must maintain a local copy of the commit log for every database mutation they are asked to perform. This places a hardware load on the Cassandra node, potentially limiting its performance.

[0283] In embodiments disclosed herein, the blockchain can be used as an immutable, time-stamped ledger to offload the burden of storing the commit log from the database nodes, which only need to be temporarily stored on the database nodes themselves, as the commit log can be retrieved from the blockchain as needed.

[0284] This allows every node in a database cluster to relieve itself of the burden of maintaining its own local commit log by recording it instead on the blockchain.

[0285] In embodiments, the aforementioned data timestamping method may be used to store the entire commit log on the blockchain as a set of linked transactions, both the data and the order of operations of which are immutably recorded on the blockchain by the actions of the blockchain network core layer nodes.

[0286] The Cassandra commit log, as detailed above, is an append-only log of all mutations made to a single Cassandra node. The blockchain log may be similar in that it may be an append-only event log of transactions committed to the blockchain.

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

[0288] Statement 1: A method of operating a distributed database implemented in a hierarchical network, the hierarchical network including a core tier including one or more core nodes, one or more middle tiers each including one or more middle tier nodes, and one or more outer tiers each including one or more outer tier nodes, each of the core nodes being a node of a blockchain network, at least some of the middle tier nodes being database nodes of a distributed database, and at least some of the outer tier nodes being client nodes of the distributed database, each database node storing at least a portion of the distributed database, the method comprising: receiving one or more update requests from one or more client nodes, the update requests being requests to update a target entry of a given database; and for each received update request, determining whether a respective target entry is found in a portion of a database stored at the first database node, and if found, updating the update request to the respective target entry in the portion of the database stored at the first database node, or if not found, forwarding the request to another one of the database nodes that stores a portion of the database including the respective target entry; wherein at least one transaction including an indication of the one or more update requests is also recorded on a blockchain of the blockchain network.

[0289] It will be understood that "first" in this context is merely an arbitrary label for a given one of the database nodes, and does not, in itself, necessarily imply any particular status with respect to another database node.

[0290] The update requests may be received from the same client node, from different client nodes, or some from the same client node and some from different client nodes.

[0291] Statement 2: The method described in statement 1, wherein each client node has a connection to at least one of the database nodes in the hierarchical network, and the first database node receives at least one of the update requests directly from the client node via one of the connections between the client node and the database node.

[0292] Statement 3: The method of statement 1 or 2, wherein each of the database nodes has a connection to at least one other database node among the database nodes in the hierarchical network, and at least one of the update requests is received indirectly over at least one of the connections between the database nodes via at least one other database node among the database nodes other than the first database node, and / or a respective target entry of at least one of the update requests is found in a portion of a database stored in one of the other database nodes, and wherein said forwarding includes forwarding to the other database node via at least one of the connections between the database nodes.

[0293] Statement 4: The method of any of the preceding statements, wherein the at least one transaction is formulated by at least one of the client nodes and submitted by the at least one client node to a core layer for mining onto the blockchain.

[0294] Statement 5: A method according to any of the preceding statements, wherein each client node has a connection to at least one of the core nodes in the hierarchical network, enabling the client node to check whether an update request has been recorded in the blockchain.

[0295] Statement 6: The method according to statement 5, wherein each client has connections to two or more of the core nodes in the hierarchical network.

[0296] Statement 7: The method according to statement 6, wherein each client has connections to two or more, but not all, of the core nodes in the hierarchical network.

[0297] Statement 8: A method as described in any of statements 5 to 7, wherein the at least one transaction is sent directly by at least one of the client nodes to the core layer via at least one of the connections between the client node and the core node.

[0298] Alternatively, it may be transmitted indirectly via two or more hops.

[0299] Statement 9: The method described in any of statements 1 to 3, wherein the at least one transaction is formulated by at least one other node among database nodes or intermediate layer nodes other than the first database node and sent to the core layer by the at least one other node to be mined onto the blockchain.

[0300] For example, at least one transaction may be formulated and submitted by one of the other database nodes acting as a coordinator or by another type of middle-tier node that provides an attestation service.

[0301] Statement 10: The method of any of the preceding statements, wherein the at least one transaction is formulated and sent to the core layer by at least one of the client nodes or at least one other database node other than the first database node or other intermediate layer node, and the method further includes, by the first database node, checking the blockchain to check that instructions of the one or more update requests have been recorded in the blockchain, and / or checking the mempools of one or more miners to check that the at least one transaction has been accepted.

[0302] Statement 11: The method according to statement 10, wherein performing the update is conditional on the check.

[0303] Statement 12: The method described in statement 10 or 11, wherein the first database node is configured to perform the above check directly via a connection in the hierarchical network between the first node and at least one of the core nodes.

[0304] Statement 13: The method described in any of statements 1 to 3, wherein the at least one transaction is formulated by a first database node and sent by the first database node to a core layer to be mined onto the blockchain.

[0305] Statement 14: The method of any of the preceding statements, wherein each of the database nodes has a connection to at least one of the core nodes in the hierarchical network.

[0306] Statement 15: The method of statement 14, wherein each of the database nodes has a connection to at least one, but not all, of the core nodes in the hierarchical network.

[0307] Statement 16: The method described in statement 14 or 15, wherein at least one transaction is sent by at least one of the database nodes directly to the core layer via at least one of the connections between the database and the core node.

[0308] Statement 17: The method of any of the preceding statements, wherein the indications of one or more update requests included in at least one transaction include data content of one or more updates that are updates made to the content of a respective data entry or entries.

[0309] The content of the data update may take the form of one or more values ​​that replace one or more previous values ​​in the respective target entry, and / or a delta that applies to one or more existing values ​​in the respective target entry.

[0310] Statement 18: The method of any of the preceding statements, wherein the indication of one or more update requests included in at least one transaction includes one or more hashes, each hash being a hash of a pre-image including data content of at least one of the updates.

[0311] Statement 19: A method according to any of the preceding statements, wherein the indication of one or more update requests included in at least one transaction includes the identification of one or more database nodes that store the portion of the database in which the respective target entry is found.

[0312] Statement 20: The method of any of the preceding statements, wherein the one or more update requests are a plurality of update requests, the target entry of each of at least some of the update requests is the same entry in a database found in a portion of the database stored in the first database node, and performing the updates includes performing the updates according to a specified order.

[0313] Statement 21: The method of statement 20, wherein the indication of the one or more update requests included in the at least one transaction includes a specified order of the multiple update requests.

[0314] The order may be indicated in any one or more of several different possible forms, such as: i) an ordered list of update requests; ii) an index mapped to each update request; iii) a hash chain, a chain of keys where each key is based on the previous update request in the chain; iv) a chain of r-puzzles; and / or v) a timestamp associated with each update request.

[0315] Statement 22: The method according to statement 21, wherein the at least one transaction originates from at least one of the client nodes or at least one other database node that is a database node other than the first database node or another intermediate node, and the method includes the first database node reading a specified order from a blockchain or a mempool of a miner of the blockchain network, and performing the update includes performing the update according to the order determined from the blockchain or mempool.

[0316] For example, the specified order may be determined and recorded on the chain by an ordering service implemented at one or more other of the intermediate nodes other than the first database node.

[0317] Statement 23: The method of statement 20 or 21, wherein the order is determined by at least one of the client nodes submitting to an ordering service, receiving a specification of the order from the ordering service, and including the specified order in at least one of the update requests.

[0318] The ordering service may be implemented in one or more other of the intermediate nodes other than the first database node.

[0319] Statement 24: The method of statement 20 or 21, wherein the specified order is determined by an ordering service implemented on the first database node.

[0320] Statement 25: The method of any of the preceding statements, wherein one or more entries of the database are replicated across portions of the database stored on multiple database nodes.

[0321] Statement 26: The method of statement 25, wherein the target entry of at least one of the update requests is found in both a portion of the database stored on the first database node and in another database node, such that the method includes both making the update at the first database node and forwarding the request to another of the database nodes.

[0322] Statement 27: A method according to any of the preceding statements, wherein the target entry of at least one of the update requests is found in a portion of a database stored on another database node among the database nodes other than the first database node, and wherein said forwarding includes determining whether the other database node is currently reachable on the hierarchical network, and, if determined to be reachable according to said determination, forwarding the update request to the other database node.

[0323] Statement 28: The method described in statement 27, wherein another database node is temporarily disconnected from the hierarchical network, and the above instructions in at least one transaction enable the other database node to perform updates of at least one update request when the other database node reconnects to the hierarchical network.

[0324] Statement 29: The method of any of the preceding statements, during the period in which the first database node is temporarily disconnected from the tiered network, the method further comprising, when the first database node becomes reconnected to the tiered network, the first node checking the blockchain, or the mempool of a miner of the blockchain network, for one or more further transactions recording any update requests received by one or more other database nodes while said first database node was disconnected, for each target entry in the portion of the database stored by the first database node, and making any such updates.

[0325] The instructions may include the IDs of one or more database nodes responsible for storing at least the portion of the database containing the entry to be updated. The data content of the update may be stored in and retrieved from the instructions stored in the transaction, or alternatively, may be retrieved from another one of the database nodes that stores a replica of the entry. For example, the node that stores the replica may be determined from the ID in at least one transaction.

[0326] Statement 30: A method as described in any of statements 10 to 12 or claim 29, wherein the first node is configured to perform the above check directly via a connection in the hierarchical network between the first node and at least one of the core nodes.

[0327] Alternatively, this can be done via two or more hops.

[0328] Statement 31: The method according to any of the preceding statements, wherein the core layer is complete.

[0329] That is, every core node in the core layer has a connection to every other core node in the core layer in the layered network.

[0330] Statement 32: A method according to any of the preceding statements, wherein the hierarchical network as a whole is incomplete.

[0331] That is, not all nodes in all tiers have connections to all other nodes in all other core tiers in the layered network. In some such embodiments, not all nodes in a given tier necessarily have connections to all other nodes in the same tier.

[0332] Statement 33: The method of any preceding claim, wherein each of the client nodes and / or database nodes is certified by a certificate authority.

[0333] Statement 34: 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 the first database node by performing a method as set forth in any preceding claim, the method comprising receiving an update request via the network interface.

[0334] Statement 35: A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1 to 33 when executed on one or more processors.

[0335] Statement 36: A method of using a distributed database, the method comprising: operating a distributed database implemented in a hierarchical network; the hierarchical network including a core tier including one or more core nodes; one or more middle tiers each including one or more middle tier nodes; and one or more outer tiers each including one or more outer tier nodes; each of the core nodes is a node of a blockchain network; at least some of the middle tier nodes are database nodes of a distributed database; and at least some of the outer tier nodes are client nodes of the distributed database; each database node stores at least a portion of the distributed database; and the method comprises: at a first client node of the client nodes, sending one or more update requests to one or more of the database nodes, the update requests being requests to update respective target entries in the database; and using a connection in the tiered network between the first client node and at least one of the core nodes in the core tier, directly: I) sending at least one transaction to be recorded on a blockchain of the blockchain network, where the at least one transaction includes one or more indications of the update request, and / or II) checking that at least one transaction including the one or more indications of the update request has been recorded on the blockchain or at least accepted into the mempool of miners of the blockchain network.

[0336] Statement 37: The method of statement 36, wherein the first client node is configured to communicate with at least one core node, including sending the at least one transaction and / or performing the check, using a communication protocol in which messages take the form of: a) a transaction sent from the client node to the core node; b) a query from the client node to the core node as to whether the transaction has been accepted into the miner's mempool and a corresponding response from the core node; c) a request from the client node to the core node for a Merkle proof that the transaction has been mined into a block and a response from the core node containing the Merkle proof; and / or d) a request from the client node to the core node for a list of block headers and a response from the core node containing the list of block headers.

[0337] In an embodiment, the first client node may be configured to use only a) through d) when communicating over a connection with at least one core node.

[0338] In an embodiment, the protocol may be an SPV protocol.

[0339] Statement 38: A computer 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 computer device to operate as the first client node by executing the method described in statement 36 or 37, the method including performing I and / or II via the network interface.

[0340] Statement 39: A computer program embodied on computer-readable storage and configured to perform the method of either statement 36 or 37 when executed on one or more processors.

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

Claims

1. 1. A method of operating a distributed data store implemented across a plurality of data storage nodes, the method comprising, at a first one of the data storage nodes: receiving one or more update requests from one or more requesting nodes, each update request being a request to update a respective target entry in the distributed data store; for each of the received update requests, determining whether the respective target entry is stored in the first data storage node, and if so, performing the update of the update request to the respective target entry stored in the first data storage node, and if not, forwarding the request to another one of the data storage nodes that stores the respective target entry; Including, At least one transaction including an indication of the one or more update requests is also recorded on a blockchain of the blockchain network. method.

2. 2. The method of claim 1, wherein the method is performed in a hierarchical network including a core tier including one or more core nodes, one or more middle tiers each including one or more middle tier nodes, and one or more outer tiers each including one or more outer tier nodes, each of the core nodes being a node of the blockchain network, at least some of the middle tier nodes being the plurality of data storage nodes of the distributed data store, and at least some of the outer tier nodes being the requesting node.

3. 3. The method of claim 2, wherein each client node has a connection to at least one of the data storage nodes in the hierarchical network, and wherein the first data storage node receives at least one of the update requests directly from a requesting node via one of the connections between the requesting node and the data storage node.

4. each of the data storage nodes having a connection to at least one other of the data storage nodes in the hierarchical network; at least one of the update requests is received indirectly over at least one of the connections between data storage nodes via at least one other data storage node of the data storage nodes other than the first data storage node; and / or the respective target entry of at least one of the update requests is stored in one of the other data storage nodes, and the forwarding includes forwarding to the other data storage node via at least one of the connections between the data storage nodes.

4. The method of claim 2 or 3, wherein the method is one or both of:

5. 5. The method of claim 2, wherein each requesting node has a connection to at least one of the core nodes in the hierarchical network, enabling the requesting node to check whether an update request has been recorded in the blockchain.

6. The method of claim 5 , wherein each requesting node has connections to two or more of the core nodes in the layered network.

7. The method of claim 6 , wherein each requesting node has connections to two or more, but not all, of the core nodes in the layered network.

8. 8. The method of claim 5, wherein the at least one transaction is sent by at least one of the requesting nodes directly to the core layer via at least one of the connections between the requesting node and a core node.

9. 9. The method of claim 1, wherein the at least one transaction is formulated by at least one of the requesting nodes and submitted by the at least one requesting node for recording on the blockchain.

10. 9. The method of claim 2, wherein the at least one transaction is formulated by at least one other of the data storage nodes other than the first data storage node and transmitted by the at least one other node to the core layer for recording on the blockchain.

11. The at least one transaction is formulated and sent to the core layer by at least one of the requesting nodes or at least one other data storage node of the data storage nodes other than the first data storage node, and the method includes, by the first data storage node: checking the blockchain to check that the indications of the one or more update requests have been recorded in the blockchain and / or checking one or more miner mempools to check that the at least one transaction has been accepted. The method of any of claims 2 to 10, further comprising:

12. The method of claim 11 , wherein performing the update is conditional on the check.

13. 13. The method of claim 11 or 12, wherein the first data storage node is configured to perform the check directly via a connection with at least one core node of the blockchain network.

14. 9. The method of claim 1, wherein the at least one transaction is formulated by the first data storage node and transmitted by the first data storage node for recording on the blockchain.

15. 15. The method of claim 1, wherein each of the data storage nodes has a connection to at least one core node of the blockchain network.

16. 16. The method of claim 15, wherein each of the data storage nodes has a connection to at least one, but not all, core nodes of the blockchain network.

17. 17. The method of claim 15 or 16, wherein the at least one transaction is transmitted by at least one of the data storage nodes to a core node of the blockchain network directly via at least one of the connections between the data storage node and a core node.

18. 18. The method of claim 1, wherein the indication of the one or more update requests included in the at least one transaction includes data content of the one or more updates, the updates being the updates to be made to content of a respective data entry or entries.

19. 19. The method of claim 1, wherein the indication of the one or more update requests included in the at least one transaction includes one or more hashes, each hash being a hash of a pre-image containing data content of at least one of the updates.

20. 20. The method of claim 1, wherein the indication of the one or more update requests included in the at least one transaction includes an ID of the one or more data storage nodes that store the respective target entries.

21. 21. The method of claim 1, wherein the one or more update requests are a plurality of update requests, the respective target entries of at least some of the update requests are entries in the same data store as stored in the first data storage node, and performing the updates includes performing the updates according to a specified order.

22. 22. The method of claim 21, wherein the indication of the one or more update requests included in the at least one transaction includes the specified order of the update requests.

23. The at least one transaction originates from at least one of the requesting nodes or at least one other of the data storage nodes other than the first database node, and the method includes: the first data storage node reading the specified order from the blockchain or a mempool of a miner of the blockchain network, and performing the update includes performing the update according to the order determined from the blockchain or mempool; 23. The method of claim 22.

24. 23. The method of claim 21 or 22, wherein the order is determined by at least one of the requesting nodes submitting to an ordering service, receiving a designation of the order from the ordering service, and including the designated order in at least one of the update requests.

25. 23. The method of claim 21 or 22, wherein the specified order is determined by an ordering service implemented at the first data storage node.

26. 26. The method of claim 1, wherein one or more entries of the data store are replicated across multiple data storage nodes.

27. 27. The method of claim 26, wherein the target entry for at least one of the update requests is found on both the first data storage node and the other one of the data storage nodes, such that the method includes both performing the update on the first data storage node and forwarding the request to another one of the data storage nodes.

28. the target entry of at least one of the update requests is found in another one of the data storage nodes other than the first data storage node, and the forwarding determining whether the other data storage node is currently reachable over the communications network, and, if reachable according to the determination, forwarding the update request to the other data storage node; 28. The method of any one of claims 1 to 27, comprising:

29. 29. The method of claim 28, wherein the other data storage node is temporarily disconnected from the hierarchical network, and the instructions in the at least one transaction enable the other data storage node to perform the update of the at least one update request when the other data storage node reconnects to the communication network.

30. During the period in which the first data storage node is temporarily disconnected from the communications network, the method includes, when the first data storage node is reconnected to the communications network: the first data storage node checks the blockchain, or the mempool of miners of the blockchain network, for one or more further transactions recording any update requests received by one or more other data storage nodes while the first data storage node was disconnected, for each target entry stored by the first data storage node, and making any such updates; 30. The method of any one of claims 1 to 29, further comprising:

31. 31. The method of any one of claims 1 to 30, wherein one, more, or all of the requesting node and / or data storage node are each certified by a certificate authority.

32. Computer equipment 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 The memory stores 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 the first data storage node by performing a method according to any one of claims 1 to 31, the method comprising receiving the update request via the network interface. Computer equipment.

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

34. 1. A method of using a distributed data store implemented across multiple data storage nodes, the method comprising: sending one or more update requests to one or more of the data storage nodes, each update request being a request to update a respective target entry in the distributed data store; Using a connection between the client node and at least one node of a blockchain network: I) transmitting at least one transaction to be recorded on a blockchain of the blockchain network, wherein the at least one transaction includes an indication of the one or more update requests; and / or II) checking that at least one transaction containing the one or more update request indications has been recorded on the blockchain or at least accepted into the mempool of miners of the blockchain network; To do A method comprising:

35. The client node may receive a message from: a) a transaction sent from the client node to the node of the blockchain network; b) a query from the client node to the node of the blockchain network regarding whether the transaction has been accepted into a miner's mempool, and a corresponding response from the node of the blockchain network; c) a request from a client node to a core node for a Merkle proof that a transaction has been mined into a block, and a response from the node of the blockchain network containing the Merkle proof; and / or d) a request from the client node to the node of the blockchain network for a list of block headers, and a response from the node of the blockchain network including the list of block headers.

35. The method of claim 34, wherein the method is configured to communicate with the at least one node of the blockchain network, including transmitting the at least one transaction and / or performing the check, using a communication protocol in the form of:

36. 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 The memory stores code configured to be executed on the processing device, the code being configured to cause the computing device to operate as the client node by performing the method of claim 34 or 35, the code including, when executed on the processing device, performing I) and / or II) via the network interface. Computer equipment.

37. 36. A computer program embodied on a computer readable storage and configured to perform the method of claim 34 or 35 when executed on one or more processors.

Images