Distributed database

Abstract

The method is performed in a layered network. The layered network includes a core layer comprising one or more core nodes, one or more intermediate layers each comprising one or more intermediate layer nodes, and one or more outer layers each comprising one or more outer layer nodes. Each core node is a node of the blockchain network. At least some intermediate layer nodes are database nodes. At least some outer layer nodes are client nodes. Each database node stores at least a portion of the distributed database. The method includes the step of receiving one or more update requests requesting to update database entries from one or more client nodes; and for each update request, applying the update locally and / or forwarding it to another database node. At least one transaction containing indications of one or more update requests is also recorded on the blockchain of the blockchain network.

Description

Technology Field

[0001] The present disclosure relates to a distributed database implemented in conjunction with a blockchain to record state changes in a database. Background Technology

[0002] A blockchain refers to a form of distributed data structure in which replicas of the blockchain are maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain comprises a chain of blocks of data, each containing one or more transactions. Each transaction can point a preceding transaction backward in a sequence that may span one or more blocks. Transactions can be submitted to the network to be included in new blocks. New blocks are generated by a process known as "mining," which involves multiple mining nodes competing to perform a "proof of work"—that is, to solve a cryptographic puzzle based on a pool of pending transactions waiting to be included in blocks.

[0003] Each node in the network may have any one, two, or all of the three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions across the nodes of the network. Mining nodes perform the mining of transactions into blocks. Storage nodes store their own copies of the mined blocks of the blockchain. To record a transaction on the blockchain, a party sends the transaction to one of the nodes in the network to be propagated. Mining nodes that receive the transaction may compete to mine the transaction into a new block. Each node is configured to comply with the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions will not be mined into blocks or propagated. Assuming a transaction is validated and thus accepted on the blockchain, the transaction (including arbitrary user data) is accordingly maintained as an immutable public record stored on each node of the P2P network.

[0004] Miners who successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction called a "generation transaction," which creates a new amount of digital assets. Since proof-of-work requires a large amount of computing resources to mine a block and blocks containing double-spending attempts are highly likely not to be accepted by other nodes, it incentivizes miners not to cheat the system by including double-spending transactions in blocks.

[0005] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies an amount of digital asset, sometimes referred to as a UTXO ("unspent transaction output"). An output may further include a locking script that specifies conditions for redeeming the output. Each input includes a pointer to such output in a preceding transaction and may further include an unlocking script to unlock the locking script of the indicated output. Thus, a pair of transactions are considered and are referred to as the first and second transactions (or "target" transactions). The first transaction includes at least one output that specifies an amount of 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 an unlocking script to unlock the output of the first transaction.

[0006] In this model, when a second target transaction is transmitted to a P2P network and propagated and recorded on the blockchain, one of the validity criteria applied by each node would be that the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another would be that the output of the first transaction has not already been redeemed by another previous valid transaction. Any node that discovers the target transaction is invalid based on one of these conditions will not propagate it, nor will it be excluded from being mined as a block to be recorded on the blockchain.

[0007] An alternative type of transaction model is the account-based model. In this case, each transaction defines the amount to be transferred by referencing the absolute account balance rather than referencing the UTXO of the preceding transaction backward in the sequence of past transactions. The current state of all accounts is stored by miners independently of the blockchain and is continuously updated.

[0008] Traditionally, blockchain transactions are used to transfer digital assets, namely multiple digital tokens. However, blockchains can also be utilized to overlay additional functionality on top of them. For example, blockchain protocols can allow the storage of additional user data in the output of a transaction. Modern blockchains are increasing the maximum data capacity that can be stored within a single transaction, enabling the integration of more complex data. For instance, this can be used to store electronic documents or even audio or video data.

[0009] The present disclosure provides a method in which a distributed database is implemented across a plurality of nodes of a layered network having nodes of a blockchain network in their cores, and changes in the state of the database are recorded on the blockchain of the blockchain network.

[0010] According to one aspect disclosed herein, a method for operating a distributed database implemented in a layered network is provided. The layered network comprises a core layer including one or more core nodes, one or more intermediate layers each including one or more intermediate layer nodes, and one or more outer layers each including one or more outer layer nodes. Each core node is a node of a blockchain network, at least some of the intermediate layer nodes are database nodes of a distributed database, at least some of the outer layer nodes are client nodes of a distributed database, and each database node stores at least some of the distributed database. The method comprises: at a first database node among the database nodes:

[0011] The method comprises the steps of: receiving one or more update requests from one or more client nodes — each of the one or more update requests is a request to update an individual target entry in a distributed database — and for each of the received update requests, determining whether the individual target entry is found in a part of the database stored in the first database node, and if so, performing an update of the update request for the individual target entry in the part of the database stored in the first database node, and if not, forwarding the request to another database node among the database nodes storing the part of the database containing the individual target entry. Furthermore, at least one transaction including an indication of one or more update requests is also recorded on the blockchain of the blockchain network. Brief explanation of the drawing

[0012] Reference to the accompanying drawings is made merely as an example to aid in understanding the embodiments of the present disclosure and to show how such embodiments can be practiced. Figure 1 is a schematic block diagram of a system for implementing a blockchain. Figure 2 schematically illustrates some examples of transactions that can be recorded on a blockchain. Figure 3 is a schematic representation of an example of a layered network. Figure 4 is another schematic representation of an example of a layered network. Figure 5 is another schematic representation of an example of a layered network. Figure 6 is another schematic representation of an example of a layered network. Figure 7 schematically illustrates an exemplary proof service implemented in a layered network. Figure 8 is a schematic transaction diagram of an exemplary transaction for recording the order of data items on a blockchain. FIG. 9 schematically illustrates an exemplary indexed list for recording the order of data items of a set within a transaction. FIG. 10 schematically illustrates another example of an indexed list for recording the order of data items of a set within a transaction. FIG. 11 schematically illustrates another example of an indexed list for recording the order of data items of a set within a transaction. Figure 12 schematically illustrates an example of a distributed database implemented in a layered network. Figure 13 schematically illustrates an example of the architecture of a Cassandra database cluster by comparison. Figure 14 schematically illustrates different communication paths of a Cassandra cluster graph. Figure 15 is a schematic block diagram of the high-level architecture of a single Cassandra node during a record request. Figure 16 schematically illustrates the transition from a complete network cluster (left) to a blockchain layered network (right). FIG. 17 schematically illustrates a blockchain layered network (BLN) including a cluster of distributed database nodes and users of the system underpinned by the database. FIG. 18 schematically illustrates an example of a distributed database implemented with BLN having a PKI implemented at least at layer i=2,3. FIG. 19 schematically illustrates an example of a read / write transaction for recording a database update indication on the blockchain. FIG. 20 schematically illustrates the read / write path of an exemplary architecture of a BLN-implemented distributed database (BLNiDD). Figure 21 schematically illustrates an example of a hinted handoff transaction. Specific details for implementing the invention

[0013] Exemplary System Overview

[0014] FIG. 1 illustrates an exemplary system (100) for implementing a blockchain (150). The system (100) includes a packet-switched network (101), typically a wide-area internetwork such as the Internet. The packet-switched network (101) includes a plurality of nodes (104) arranged to form a peer-to-peer (P2P) overlay network (106) within the packet-switched network (101). Each node (104) of the blockchain network (106) includes the computer equipment of the peers, and different nodes among the nodes (104) belong to different peers. Each node (104) includes a processing device including one or more processors, e.g., 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., a computer-readable storage in the form of a non-transient computer-readable medium or media. The memory may include one or more memory units using one or more memory media, such as a magnetic medium like a hard disk; an electronic medium like a solid-state drive (SSD), flash memory, or EEPROM; and / or an optical medium like an optical disc drive.

[0015] A blockchain (150) comprises a chain (151) of blocks of data, and individual copies of the blockchain (150) are maintained at each of the multiple nodes of a P2P network (160). Each block (151) of the chain contains one or more transactions (152), where in this context, a transaction refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will typically use one specific transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction (152) includes at least one input and at least one output. Each output specifies an amount representing the amount of digital assets belonging to a user (103) whose output is cryptographically locked (requiring the user's signature to unlock and thus redeem or spend). Each input points backward to the output of a preceding transaction (152), thereby linking the transactions.

[0016] At least some of the nodes (104) act as forwarding nodes (104F) that forward and thus propagate transactions (152). At least some of the nodes (104) act as miners (104M) that mine blocks (151). At least some of the nodes (104) act as storage nodes (104S) (sometimes also referred to as "full-copy" nodes) that each store individual copies of the same blockchain (150) in their own 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.

[0017] In a given current transaction (152j), its (or each) input includes a pointer that references the output of a preceding transaction (152i) in a sequence of transactions, specifying that such output is "spent" or redeemed in the current transaction (152j). Generally, the preceding transaction may be any transaction in the pool (154) or any block (151). The preceding transaction (152i) does not necessarily have to exist when the current transaction (152j) is created or even transmitted to the network (106), but the preceding transaction (152i) will need to exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to the predecessor of a logical sequence linked by pointers, not necessarily the time of transmission or creation of a temporal sequence, and therefore does not necessarily exclude the transactions (152i, 152j) from being transmitted or created out of order (see discussion below regarding orphan transactions). The preceding transaction (152i) can be referred to as the antecedent transaction or the predecessor transaction.

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

[0019] The above may be referred to as an "output-based" transaction protocol, and sometimes also as an unspent transaction output (UTXO) type protocol (where outputs are referred to as UTXOs). The user's total balance is not defined by any single number stored in the blockchain; instead, the user requires a special "wallet" application (105) to compare the values ​​of all of the user's UTXOs scattered across multiple different transactions (152) of the blockchain (151).

[0020] An alternative type of transaction protocol can be referred to as an "account-based" protocol as part of the account-based transaction model. In the case of account-based transactions, each transaction defines the amount to be transferred by referencing the absolute account balance rather than referencing the UTXO of the preceding transaction in the sequence of past transactions. The current state of all accounts is stored by miners independently of the blockchain and is continuously updated. Transactions are ordered using the total of active transactions in an account (also called a "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, an optional data field can also sign the transaction. This data field can point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0021] In any type of model, when a user (103) wishes to enact a new transaction (152j), the user transmits the new transaction from their computer terminal (102) to one of the nodes (104) of the P2P validation network (106) (which are typically servers or data centers in recent times, but in principle may be other user terminals). This node (104) checks whether the transaction is valid according to the node protocol applied to each of the nodes (104). The details of the node protocol correspond to the type of transaction protocol used in the corresponding blockchain (150) and together form the entire transaction model. The node protocol typically requires the node (104) to check whether the cryptographic signature of the new transaction (152j) matches the expected signature, which depends on the previous transaction (152i) in the ordered sequence of transactions (152). In the case of an output-based method, this involves checking whether the user's cryptographic signature included in the input of the new transaction (152j) matches a condition defined in the output of the preceding transaction (152i) that the new transaction spends, wherein the condition typically includes checking that the cryptographic signature of the input of the new transaction (152j) unlocks the output of the previous transaction (152i) that the input of the new transaction points to. In some transaction protocols, the condition may be at least partially defined by a custom script included in the input and / or output. Alternatively, this may be fixed simply by the node protocol or due to a combination thereof. In either case, if the new transaction (152j) is valid, the current node forwards it to one or more other nodes among the nodes (104) of the P2P network (106).At least some of these nodes (104) also act as forwarding nodes (104F), applying the same test according to the same node protocol and accordingly forwarding a new transaction (152j) to one or more additional nodes (104). In this way, the new transaction is propagated throughout the network of nodes (104).

[0022] 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 forward transaction (152j) according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction (152i) attempting to spend or redeem has not already been spent / redeemed by another valid transaction. Again, if it is invalid, the transaction (152j) will not be recorded or propagated on the blockchain. This guards against double-spending, where the spender attempts to spend the output of the same transaction more than once.

[0023] In addition to validation, at least some of the nodes (104M) also compete to be the first to create blocks of transactions in a process known as mining, which is backed by "proof of work." At the mining nodes (104M), new transactions that have not yet appeared in a block are added to the pool of valid transactions. Then, the miners 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 retrieving a nonce value such that when the "nonce" is concatenated with the pool of transactions (154) and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has a predetermined number of leading zeros. A characteristic of the hash function is that the hash function has an unpredictable output for its input. Therefore, this search can only be performed by brute force, and accordingly, each node (104M) attempting to solve the puzzle consumes a significant amount of processing resources.

[0024] A first miner node (104M) that intends to solve the puzzle publishes it to the network (106) and provides the solution as proof, which can then be easily checked by other nodes (104) in the network (it is simple to check that, given a solution for a hash, the solution causes the output of the hash to satisfy the conditions). A pool (154) of transactions in which the winner has solved the puzzle is 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 the winner's published solution being checked at each such node. A block pointer (155) is also assigned to a new block (151n) that points backward from a previously created block (151n-1) in the chain. Proof of work helps reduce the risk of double spending because it requires a large amount of effort to create a new block (151), and since any block containing double spending is likely to be rejected by other nodes (104), mining nodes (104M) are encouraged not to allow double spending to be included in their blocks. Once created, the block (151) cannot be modified because it is recognized and maintained at each of the storage nodes (104S) of the P2P network (106) according to the same protocol. The block pointer (155) also imposes a sequential order on the blocks (151). Since transactions (152) are recorded in ordered blocks at each of the storage nodes (104S) of the P2P network (106), this accordingly provides an immutable public ledger of transactions.

[0025] The pool (154) is sometimes referred to as a “mempool.” In this document, the term is not intended to be limited to any specific blockchain, protocol, or model. It refers to a pool of transactions that a miner accepts to mine and commits to not accept any other transaction that the miner attempts to spend the same output.

[0026] Note that different miners (104M) competing to solve a puzzle at any given time solve the puzzle based on different snapshots of the unmined transaction pool (154) at any given time, depending on when the search for a solution began. The person who solves their respective puzzle first defines which transactions (152) are included in the next new block (151n), and the current pool (154) of unmined transactions is updated. Then, the miners (104M) continue to compete to create a block from the newly defined unsolved pool (154), and so on. There is also a protocol to resolve any "fork" that may occur—which is a case where two miners (104M) solve their puzzles within a very short time of each other, causing conflicting views of the blockchain to propagate. In short, the longest-growing branch of the fork becomes the deterministic blockchain (150).

[0027] In most blockchains, the winning miner (104M) is automatically rewarded with a special type of new transaction that generates a new quantity of digital assets from somewhere unknown (in contrast to general transactions that transfer an amount of digital assets from one user to another). Thus, the winning node is considered to have "mined" a certain quantity of digital assets. This special type of transaction is sometimes referred to as a "generation" transaction. It automatically forms a portion of a new block (151n). This reward provides an incentive for miners (104M) to participate in the proof-of-work competition. Often, the general (non-generation) transaction (152) will also specify an additional transaction fee in one of its outputs to further reward the winning miner (104M) who generated the block (151n) containing that transaction.

[0028] Due to the computational resources involved in mining, typically at least each of the miner nodes (104M) takes the form of a server comprising one or more physical server units, or even 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) may take the form of a user terminal or a group of user terminals networked together.

[0029] The memory of each node (104) stores software configured to be executed on the processing unit of the node (104) to perform its respective role or functions and process transactions (152) according to the node protocol. It will be understood herein that any action attributed to the node (104) may be performed by software executed on the processing unit of its respective computer equipment. Node software may be implemented in one or more applications at lower layers, such as the application layer, the operating system layer, or the protocol layer, or any combination thereof. Additionally, the term “blockchain” as used herein is a general term referring to a type of technology and is not limited to any specific proprietary blockchain, protocol, or service.

[0030] Additionally, the network (101) is connected to computer equipment (102) of each of the multiple parties (103) acting as consuming users. These act as payers and payees in transactions, but are not required to participate in mining or propagating transactions on behalf of other parties. They are not required to execute a mining protocol. Two parties (103) and their individual equipment (102), namely the first party (103a) and his / her individual computer equipment (102a) and the second party (103b) and his / her individual computer equipment (102b), are illustrated for illustrative purposes. It will be understood that many more of these parties (103) and their individual computer equipment (102) may exist and participate in the system, but for convenience, they are not illustrated. Each party (103) may be an individual or an organization. For the sake of example, the first party (103a) is referred to herein as Alice and the second party (103b) as Bob, but it will be recognized that this is not limiting and any reference to Alice or Bob in the present invention may be replaced with "first party" and "second party," respectively.

[0031] The computer equipment (102) of each party (103) comprises individual processing units comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer equipment (102) of each party (103) further comprises memory, i.e., a computer-readable storage in the form of a non-transient computer-readable medium or media. This memory may comprise one or more memory units using one or more memory media, e.g., a magnetic medium such as a hard disk; an electronic medium such as a solid-state SSD, flash memory, or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment (102) of each party (103) stores software comprising individual instances of at least one client application (105) arranged to be executed on the processing unit. It will be understood that any operation attributed to the party (103) given herein may be performed using software executed on the processing unit of the individual computer equipment (102). The computer equipment (102) of each party (103) includes at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment (102) of a given party (103) may also include one or more other networked resources, such as cloud computing resources accessed through the user terminal.

[0032] For example, a client application (105) that is 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, etc., may be initially provided to the computer equipment (102) of any given party (103) on a suitable computer-readable storage medium or media.

[0033] The client application (105) includes at least a “wallet” function. It has two main functionalities. One of these is to enable an individual user party (103) to create, sign, and transmit transactions (152) that are propagated across a network of nodes (104) and thus included in the blockchain (150). The other is to report back to the individual party the amount of digital assets they currently own. In an output-based system, this second functionality includes comparing amounts defined in the outputs of various transactions (152) belonging to the party scattered across the blockchain (150).

[0034] Note: Various client functions may be described as being integrated into a given client application (105), but this is not necessarily limited thereto. Instead, any client function described herein may be implemented as a set of two or more separate applications, for example, by interfacing via API or by one being plugged into another. More generally, client functions may be implemented in the application layer, or in a lower layer such as an operating system, or any combination thereof. The following will be described in terms of the client application (105), but it will be noted that this is not limited thereto.

[0035] An instance of a client application or software (105) on each computer equipment (102) is operably coupled to at least one of the forwarding nodes (104F) of the P2P network (106). This enables the wallet function of the client (105) to transmit transactions (152) to the network (106). The client (105) may also contact one, some, or all of the storage nodes (104) to query the blockchain (150) for any transactions to which an individual party (103) is the recipient (or, in the embodiments, to inspect the transactions of other parties on the blockchain (150), since the blockchain (150) is a public facility that partially provides trust in the transactions through its public visibility). The wallet function on each computer equipment (102) is configured to formulate and transmit transactions (152) according to the 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 transactions (152) across the network (106). The transaction protocol and the node protocol correspond to each other, and a given transaction protocol follows a given node protocol to implement a given transaction model together. The same transaction protocol is used for all transactions (152) of the blockchain (150) (however, the transaction protocol may allow transactions of different subtypes within it). The same node protocol is used by all nodes (104) of the network (106) (however, this may handle transactions of different subtypes differently according to rules defined for the corresponding subtype, and different nodes may assume different roles and accordingly implement different corresponding aspects of the protocol).

[0036] As mentioned, the blockchain (150) comprises a chain of blocks (151), wherein each block (151) comprises a set of one or more transactions (152) generated by a proof-of-work process as previously discussed. Each block (151) also comprises a block pointer (155) that points backward to a previously generated block (151) in the chain to define a sequential order for the blocks (151). The blockchain (150) also comprises a pool (154) of valid transactions waiting to be included in a new block by a proof-of-work process. Each transaction (152) (excluding the generated transaction) comprises a back pointer to a previous transaction to define an order for a sequence of transactions (note that the sequence of transactions (152) is allowed to branch). The chain of blocks (151) traces back completely to the genesis block (Gb) (153), which was the first block of the chain. One or more original transactions (152) at the beginning of the chain (150) pointed to the genesis block (153) which was not a preceding transaction.

[0037] When a given party (103), such as Alice, wishes to send a new transaction (152j) to be included in the blockchain (150), she formulates the new transaction according to the relevant transaction protocol (using the wallet function of her client application (105)). Then, she sends the transaction (152) from the client application (105) to one or more forwarding nodes (104F) to which she is connected. For example, this may be the forwarding node (104F) closest to or best connected to Alice's computer (102). When any given node (104) receives the new transaction (152j), the given node processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction (152j) satisfies specific conditions for being "valid," examples thereof will be discussed in more detail shortly. In some transaction protocols, conditions for validation may be configured on a transaction-by-transaction basis by scripts included in the transactions (152). Alternatively, the condition can be simply an embedded feature of the node protocol, or defined as a combination of the script and the node protocol.

[0038] Any storage node (104S) receiving the transaction (152j) will add the new validated transaction (152) to a pool (154) of copies of the blockchain (150) maintained at that node (104S), provided that the newly received transaction (152j) is considered valid and passes the test (i.e., is "validated"). Additionally, any forwarding node (104F) receiving the transaction (152j) will forward the validated transaction (152) to one or more other nodes (104) of the P2P network (106). Since each forwarding node (104F) applies the same protocol, assuming the transaction (152j) is valid, this means that it will be propagated across the entire P2P network (106).

[0039] When a pool (154) of copies of the blockchain (150) maintained by one or more storage nodes (104) is granted, miner nodes (104M) will begin to compete to solve a proof-of-work puzzle in the latest version of the pool (154) containing a new transaction (152) (other miners (104M) may still attempt to solve the puzzle based on the old view of the pool (154), but whoever reaches it first will define where the next new block (151) ends and the new pool (154) begins, and eventually someone will solve the puzzle for the part of the pool (154) containing Alice's transaction (152j)). Once the proof-of-work for the pool (154) containing the new transaction (152j) is completed, it becomes an immutable part of one of the blocks (151) of the blockchain (150). Each transaction (152) includes an inverse pointer to the previous transaction, so the order of the transactions is also immutably recorded.

[0040] Both mining and storage nodes can perform validation as a function. For mining nodes, this function may be auxiliary for hashing, and for storage nodes, this function may be auxiliary for storage.

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

[0042] UTXO-based model

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

[0044] In a UTXO-based model, each transaction ("Tx") (152) includes a data structure comprising one or more inputs (202) and one or more outputs (203). Each output (203) may include an unspent transaction output (UTXO) that can be used as a source for the input (202) of another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents the number of tokens set on the (distributed) ledger. The UTXO may also include, among other information, the transaction ID of the transaction in which it occurred. The transaction data structure may also include a header (201) that may include an indicator of the size of the input field(s) (202) and output field(s) (203). The header (201) may also include the transaction ID. In the embodiments, the transaction ID is the 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 miners (104M).

[0045] Let's assume Alice (103a) wants to create a transaction (152j) to transfer an amount of the corresponding digital asset to Bob (103b). In FIG. 2, Alice's new transaction (152j) is labeled "Tx1". This takes an amount of the digital asset locked to Alice from the output (203) of the preceding transaction (152i) in the sequence and transfers at least a portion of it to Bob. The preceding transaction (152i) is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain (151) or that Tx1 is the very next transaction in the pool (154). Tx1 can point to any preceding (i.e., earlier) transaction that still has an unspent output (203) locked to Alice.

[0046] The preceding transaction (Tx0) may already be validated and included in the blockchain (150) by the time Alice creates her new transaction (Tx1), or at least by the time she transmits 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 soon be included in a new block (151). Alternatively, Tx0 and Tx1 may be created and transmitted together to the network (102), or if the node protocol allows buffering of "orphan" transactions, Tx0 may be transmitted after Tx1. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transactions (where a transaction points to another transaction, and thus continues). These may be equivalently substituted with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are generated, transmitted to the network (106), or reach any given node (104). Nevertheless, a subsequent transaction (descendant transaction or "child") pointing to a preceding transaction (predecessor transaction or "parent") will not be validated until the parent transaction is validated, and unless it is validated. A child reaching the node (104) before its parent is considered an orphan. It may be buffered for a certain period of time or discarded to wait for the parent, depending on the node protocol and / or miner behavior.

[0047] One or more outputs (203) of a preceding transaction (Tx0) includes a specific UTXO labeled herein as UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a lock script defining conditions that must be satisfied by an unlock script in the input (202) of the subsequent transaction for the subsequent transaction to be validated and thus for the UTXO to be successfully redeemed. Typically, the lock script locks the amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script defines unlock conditions that typically include a condition in which the unlock script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the preceding transaction is locked.

[0048] A lock script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of this language is called "Script" (uppercase S). The lock script specifies what information is required to spend the transaction output (203), for example, Alice's signature requirement. Unlock scripts appear in the output of the transactions. An unlock script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the lock script criteria. For example, this may include Bob's signature. Unlock scripts appear in the input (202) of the transactions.

[0049] Therefore, in the example illustrated, UTXO0 of the output (203) of Tx0 is Alice's signature Sig P for UTXO0 to be redeemed (strictly speaking, for a subsequent transaction attempting to redeem UTXO0 to be valid). A Lock script requiring [Checksig P A Includes ]. [Checksig P A ] is the public key P from Alice's public-private key pairA Includes. The input (202) of Tx1 includes a pointer pointing backward to Tx1 (e.g., in the embodiment, by its transaction ID TxID0, which is the hash of the entire transaction Tx0). The input (202) of Tx1 includes an index identifying UTXO0 within Tx0, identifying it among any other possible outputs of Tx0. The input (202) of Tx1 includes an unlock script containing Alice's cryptographic signature. <Sig P A It further includes, which is generated by Alice applying her private key from a key pair to a predefined part of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, a node protocol, or a combination thereof.

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

[0051] When a new transaction Tx1 reaches the node (104), the node applies the node protocol. This includes executing the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (these conditions may include one or more criteria). In embodiments, this involves linking the two scripts.

[0052] <Sig P A > < P A > || [Checksig P A ]

[0053] Here, "||" represents a link, "<...>" signifies placing data on a stack, and "[...]" is a function constructed by an unlock script (in this example, a stack-based language). Equivalently, instead of linking scripts, they can be executed sequentially using a common stack. In either case, when executed together, the scripts have Alice's public key P, as included in the lock script of Tx0's output. A Using, authenticate that the lock script of the input to Tx1 includes Alice's signature signing the expected portion of the data. To perform this authentication, the expected portion of the data itself ("message") also needs to be included in Tx0. In the embodiments, the signed data includes the entire Tx0 (accordingly, a separate element specifying the signed portion of the data in plaintext (in-the-clear) needs to be included because it already exists by nature).

[0054] The details of authentication by public-private encryption will be familiar to those skilled in the art. Basically, if Alice signs a message by encrypting it with her private key, other entities such as Node (104) can authenticate that the encrypted version of the message must have been signed by Alice, taking into account Alice's public key and the plaintext of the general message (unencrypted message). Signing typically involves hashing the message, signing the hash, and tagging the plaintext version of the message as a signature, thereby enabling any holder of the public key to authenticate the signature. It is noted that any reference in the invention to signing a specific piece of data or part of a transaction means signing the hash of said piece of data or part of a transaction in the embodiments.

[0055] The hash mentioned anywhere in this invention may be implemented by, for example, a SHA (Secure Hash Algorithm) hash function, or an HMAC (hash-based message authentication code) hash function, or any other suitable form of cryptographic hash function known in the art.

[0056] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (accordingly, in the shown example, if Alice's signature is provided and authenticated in Tx1), the node (104) considers Tx1 to be valid. If it is a mining node (104M), this means it will be added to the pool (154) of transactions waiting for proof of work. If it is a forwarding node (104F), it will forward transaction Tx1 to one or more other nodes (104) in the network (106) so that the transaction will be propagated across the network. When Tx1 is validated and included in the blockchain (150), it defines UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it spends an unspent transaction output (203). If it attempts to spend an output that has already been spent by another transaction (152), Tx1 will not be valid even if all other conditions are satisfied. Therefore, the node (104) also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (whether it has already formed a valid input for another valid transaction). This is one reason why imposing a defined order on the transactions (152) is important for the blockchain (150). In practice, a given node (104) may maintain a separate database marking the UTXOs (203) that have been spent by the transactions (152), but ultimately, what defines whether a UTXO has been spent is whether a valid input for another valid transaction in the blockchain (150) has already been formed.

[0057] Additionally, 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 for invalidation in most transaction models. Therefore, such transactions will not be mined or propagated into blocks (151).

[0058] Note that in a UTXO-based transaction model, a given UTXO must be spent in its entirety. As other fractions are spent, the fraction of the amount defined in the UTXO as spent cannot be "left behind." However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Therefore, if Alice does not wish to give the entire amount defined in UTXO0 to Bob, she can use the remainder from the second output of Tx1 to give herself change or to pay another party.

[0059] In fact, the Alice would also generally need to include a fee for the winning miner, because recently, the reward for the generated transaction alone is generally not sufficient to incentivize mining. If the Alice does not include a fee for the miner, Tx0 would likely be rejected by the miner nodes (104M), and consequently, even if technically valid, it would still not be propagated and included in the blockchain (150) (the miner protocol does not force the 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., a separate UTXO is not required). Instead, any difference between the total amount indicated by the input(s) (202) of a given transaction (152) and the total amount specified in the output(s) (203) is automatically given to the winning miner (104). For example, let us assume that a pointer to UTXO0 is the only input to Tx1 and Tx1 has only one output, UTXO1. If the amount of digital assets assigned to UTXO0 is greater than the amount assigned to UTXO1, the difference is automatically transferred to the winning miner (104M). However, alternatively or additionally, it is not necessarily excluded that the miner fee may be explicitly assigned to its own UTXO among the UTXOs (203) of the transaction (152).

[0060] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transactions (152) at any location on the blockchain (150). Thus, typically, the assets of a given party (103) are scattered across UTXOs of various transactions (152) throughout the blockchain (150). There is no number at any location on the blockchain (150) that defines the total balance of a given party (103). The role of the wallet function in the client application (105) is to compare together the values ​​of all the various UTXOs that are locked to individual parties and have not yet been spent in other forward transactions. This can be done by querying a copy of the blockchain (150) as stored in any of the storage nodes (104S), for example, the storage node (104S) closest to or best connected to the individual party's computer equipment (102).

[0061] Note that script code is often expressed schematically (i.e., not in precise language). For example, [Checksig P A ] = OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY to mean OP_CHECKSIG [Checksig P A] can be written. "OP_..." refers to a specific opcode in the script language. OP_CHECKSIG (also called "Checksig") is a script opcode that takes two inputs (signature and public key) and uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to verify the validity of the signature. At runtime, any random occurrence of the signature ('sig') is removed from the script, but additional requirements, such as hash puzzles, are retained in the transaction verified by the 'sig' input. As another example, OP_RETURN is a script language opcode for generating an inconsumable output of the transaction that stores metadata within the transaction and thus allows the metadata to be written immutably to the blockchain (150). For example, the metadata may include documents to be stored in the blockchain.

[0062] Signature P A is a digital signature. In the embodiments, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific piece of data. In the embodiments, for a given transaction, the signature will sign part of the transaction inputs and all or part of the transaction outputs. The specific parts of the outputs to be signed depend on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature to select which outputs are signed (accordingly, fixed at the time of signing).

[0063] A lock script is sometimes referred to as "scriptPubKey," indicating that it contains the public key of the party to which the individual transaction is locked. An unlock script is sometimes referred to as "scriptSig," indicating that it provides a corresponding signature. However, more generally, it is not mandatory for all applications of the blockchain (150) for a condition for a UTXO to be redeemed to include authenticating a signature. More generally, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0064] Layered network

[0065] Layered Network Structure: A layered network is an overlay network layered on top of a communication channel. For example, the communication channel can be an underlying infrastructure network such as a personal area network, a local area network (e.g., a peer-to-peer network between companies), or a wide-area network like the Internet. In another example, the layered network can be a network of nodes connected via wired connections. In yet another example, the connection can be a wireless connection, such as Bluetooth or Wi-Fi. In some examples, some or all of the exemplary connections mentioned above can be used to form a layered network.

[0066] It is a network in which some or all of the nodes are configured to connect (i.e., join or rejoin) to a layered network according to a connection protocol. The connection protocol may vary depending on the specific layer of the network to which the connecting nodes attempt to connect (i.e., join or rejoin). Before describing the connection protocol in detail, a series of exemplary layered networks that may be created or enforced by the connection protocol will be described. However, it will be noted that these are merely exemplary examples, and generally, any layered network following a connection protocol can be created.

[0067] FIG. 3 illustrates a schematic representation of an example of a layered network (LN) (300). Generally, the 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 layers of the series extend outward from the core layer in order from a second layer composed of second nodes (302) to one or more outer layers. Each outer layer consists of a set of outer nodes (303). Although only one outer layer is illustrated in FIG. 3, it will be noted that the LN may include any number of outer layers. As a specific example, FIG. 5 illustrates an example of an LN (500) containing five layers, and FIG. 6 illustrates an example of an LN (600) containing four layers.

[0068] The exemplary LN (300) of FIG. 3 includes five core nodes (301), six second nodes (302), and eight outer nodes (303). In some LNs (300), the number of nodes may increase with each layer, that is, the core layer consists of the fewest number of nodes, and the outermost layer consists of the most number of nodes. In other examples, one or more of the layers between the core layer and the outermost layer may consist of the most number of nodes. In this example, the core layer is the innermost layer of the LN (300), the second layer is the middle layer, and the outer layer, which is the only outer layer, is the outermost layer.

[0069] In this example, the core layer (network within the LN) forms a complete graph, that is, each core node (301) is connected to a different core node (301). For a core layer of 5 core nodes (301), in the given example, the core layer requires 10 distinct core connections (i.e., connections between 2 core nodes). In other examples (e.g., FIG. 4), the core layer may not be a complete graph. The core layer may form a "nearly complete graph." In a nearly 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 specific example of a nearly complete graph, each core node (301) may be connected to one or more of the other core nodes (301), rather than all of them.

[0070] The second layer includes a second node (302). It is noted that the term "second node" is used only as a label for a node (302) located in the second layer of the LN (300), depending on the configuration. 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 more than one core node (301). For example, some or all of the second nodes (302) may be connected to each of all core nodes (301). In the exemplary LN (300) of FIG. 3, each core node (301) is connected to two second nodes (302). However, in this example, some second nodes (302) (drawn as striped circles) are connected to one core node (301), whereas some second nodes (302) (drawn as white circles and drawn as shaded circles) are connected to two core nodes (301). The second nodes (302) connected to the same core node (301) (and the outer nodes (303) of the outer layer) are referred to as a "community." For example, each white node forms one community together, each striped node forms a community together, and each shaded node forms another community together. The connection between the second nodes (302) and the core node (301) is referred to as an "ancestor connection" and is drawn with a wide dashed line.

[0071] In the example of FIG. 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 a connection with other second nodes, for example, some second nodes (302) may be connected to other second nodes (302), while some second nodes may be connected to other second nodes (302). These "intra-layer" connections are shown as solid lines between the nodes in FIG. 3.

[0072] The outer layer of FIG. 3 includes outer nodes (303). It is noted that the term “outer” in “outer layer” herein is not necessarily limited to the outermost layer of the LN network in itself, but is a possibility. Each outer node (303) is connected to at least one second node (302). In some examples, each outer node (303) may be connected to only one second node (302). Alternatively, some or all of the outer nodes (303) may be connected to more than one second node (302). For example, some or all of the outer nodes (303) may be connected to each and each of all second nodes (301). In the exemplary LN (300) of FIG. 3, each outer 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).

[0073] In the example of FIG. 3, each external node (303) is connected to two other external nodes (303) of the same layer. In some examples, some or all of the external nodes (303) may not form any connection with other external nodes (303) of the same layer. Some or all of the external nodes (303) may form at least one connection with other external nodes (303) of the same layer.

[0074] In addition to 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 the external node (303) and the core node (301) is referred to as 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 ancestor's 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 ancestor's second node(s) (302) are connected, and may not be connected to any other core node (301). In this case, each external node (303) belongs to a single community.

[0075] FIG. 4 illustrates a schematic representation of another example of LN (400). Like the LN (300) in 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., 5 core nodes (301), 6 second nodes (302), and 8 outer nodes (303)), but include a different number of connections. For example, in this example, the core layer is not a complete graph because some connections between the core nodes (301) do not exist. Another difference is that two communities (white nodes and shaded nodes) contain a single core node (301), whereas the other community (shaded nodes) contains three core nodes (301). Another difference is that, unlike the degree of the nodes within the outer shell of LN (300) being 2, the degree of the nodes within the outer shell of LN (400) is now 1. That is, in this exemplary LN (400), each outer node (303) is connected to a single other outer node (303). Thus, nodes of different layers have different degrees.

[0076] FIG. 5 illustrates a schematic representation of another example of LN (500). In this example, only some core nodes (301) are connected to the second nodes and the outer nodes (303). That is, in this example, some core nodes (301) form connections only with other core nodes (301). Thus, in this example, LN (500) contains a single community (shaded nodes). The LN (500) of this example includes five layers: a core layer, a second layer, and three outer layers. The core layer consists of five core nodes (301) forming a nearly complete graph. In this example of a nearly complete graph, only a single core connection is missing. The second layer consists of a single second node (302) connected to two core nodes (301). The third layer consists of a single external node (303) connected to the second node (302) via an ancestor connection. The external node (303) of the third layer 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 individual core ancestor connections. The fourth layer also consists of a single external node (304). The external node (304) of the fourth layer is connected to the external node (303) of the third layer via an ancestor connection and is connected to the second node (302) via an ancestor connection. The external node (304) of the fourth layer is also connected to two core nodes (301) to which the second node (302) of the third layer and the external node (303) are connected. The external node (304) is connected to the two core nodes (301) via individual core ancestor connections. Finally, the fifth layer consists of two external nodes (305). The two external nodes (305) of the fifth layer are connected to the external node (304) of the fourth layer, the external node (303) of the third layer, and the second node (302), where each connection is an ancestor connection.The two external nodes (305) are also connected to the two core nodes (301) via a core ancestor connection. In this exemplary LN (500), the nodes of the second layer and the nodes of the external layer are not connected to any other nodes of the same layer.

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

[0078] In some embodiments, LN (300, 400, 500, 600) (hereinafter referred to as “300” for brevity) may be a “Blockchain Layered Network (BLN).” The term BLN is defined herein as a blockchain network, or a layered network comprising at least a portion of a blockchain network, e.g., the blockchain network (106) described with reference to FIG. 1.

[0079] BLN is inspired by the Mandala network and shares some similar features, but is designed to allow for a more flexible and desirable connection structure for service and user networks utilizing, for example, the blockchain network (106).

[0080] A BLN (300) may include at least a portion of a blockchain network (106) in its core. Generally, the nodes of a 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). These may include mining nodes (104M), storage nodes (104S), or a combination thereof. In an embodiment, each core node is a mining node (104M) and / or a storage node (104S) (e.g., a full copy node).

[0081] Each external node (303) (or each external node of the outermost layer) may be an end-user node comprising a user's computer equipment. This may be an individual user or an organization such as a company, an academic institution, or a government agency. Accordingly, each external node (303) may include a server comprising one or more server units at one or more sites and / or one or more user terminals. Each external node (303) includes memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take any form of memory media and / or processors, such as those previously discussed in relation to other network elements or user equipment, for example. The memory stores client software arranged to be executed in the processing unit, wherein the client software is configured to operate the node as a client of a protocol following a connection protocol according to any of the following embodiments or similar embodiments when executed. Optionally, one or more of the end-user nodes may include user equipment (103) of a user (102) of the blockchain network (106), and the client software may include a blockchain wallet application (105), etc.

[0082] Each second node (302) may take the form of a server comprising one or more physical server units. Each of these nodes includes memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take any form of memory media and / or processors, such as those previously discussed in relation to other network elements, for example. The memory stores software arranged to be executed in the processing unit of the second node (302). This software is configured to follow a connection protocol according to any of the following embodiments or similar embodiments when executed. In some embodiments, the software is configured to provide a service that operates according to any of the embodiments or similar embodiments described below when executed.

[0083] In some examples, some or all of the second nodes (302) may operate the smart contract service. The smart contract service is configured to perform a predefined action in response to and based on a blockchain transaction sent to the smart contract service by one of the other nodes of the LN (300), for example, an external node (303). For example, the smart contract service may send a blockchain transaction to the core node (301) in response to receiving a specific blockchain transaction from the external node (303).

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

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

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

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

[0088] Some or all of the external nodes (303) may be configured to transmit blockchain transactions to other external nodes (303), such as external nodes of the same layer, or external nodes of the previous layer or the next layer within a sorted set of layers.

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

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

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

[0092] In some embodiments, some or all of the core nodes (301) may be configured to transmit a set of transactions to some or all of the external node(s) and / or some or all of the second node(s) (302) connected to the core node (301). Transactions within the set may share common attributes. For example, the core node (301) may transmit all transactions that include a specific protocol flag. The flag may be included in the output of the transaction, for example, an unspent output. As another example, the transaction may include a specific (and identical) blockchain address, for example, the transaction may be payable to the same blockchain address. The external node (303) may agree with the core node (301) that the core node (301) transmit any payable transaction to an address associated with the external node (303). As yet another example, the transaction may include a second set of consensus rules. That is, the transaction may include more than one control branch in the output, each control branch being specific to each set of consensus rules. The output may include a first control branch specific to the first rule set and a second control branch specific to the second rule set (the two control branches may be included in an if-else condition). If the node (302, 303) is configured to implement the second rule set, the core node (301) may send a transaction to the node (302, 303). If the node (302, 303) is not configured to implement either the first rule set or the second rule set, the core node does not send a transaction to the node (302, 303).

[0093] A core node (301), which is a mining node (104M), may include an identifier specific to that mining node (104M) (e.g., "miner ID") in a generated transaction (also referred to as a "coinbase" transaction) mined into a block (151) by that mining node (104M). Other nodes of the BLN (300) may use the identifier to identify that mining node (104M) on the network.

[0094] Another method of identifying the nodes (301, 302, 303) of the LN (300) is to use digital certificates. Some or all of the nodes (301, 302, 303) may be associated with digital certificates. Digital certificates contain and certify the identifiers of individual nodes, such as the public key associated with the node, the network address of the node (e.g., IP address), etc. Nodes of the LN (300) may be connected to a node using the digital certificate of another node. For example, an external node (303) may obtain a digital certificate from a second node (302) and be connected to the second node (302) using the identification information of the second node included in the digital certificate.

[0095] A node of a given layer can issue a digital certificate to a node of the next layer within the layer of the sorted set, that is, a core node (301) can issue a digital certificate to a second node (302), and the second node (302) can issue a digital certificate to an external node (303) of the first external layer, and so on. In some examples, a node of a given layer can issue a digital certificate to a node of the same layer, for example, a second node (302) can issue individual digital certificates to one or more other second nodes (302).

[0096] Connection ProtocolAs described above, each node connected to the layered network (300) may be connected according to a connection protocol. That is, the connection node must follow the rules of the connection protocol. The connection node may only form connections permitted by the connection protocol. No other connections may be formed. In an example, the connection node may be a core node (301), a second node (302), or an external node (303). In some examples, each node of the LN (300) must follow the connection protocol. In other examples, only the node that is first connected to the LN (300) or rejoins the LN (300) must follow the connection protocol. FIGS. 3 through 6 illustrate exemplary LNs (300, 400, 500, 600) configured according to the connection protocol.

[0097] Physically speaking, it is noted that each of the nodes of LN (300) may be connected to or connected to others at some different level, for example, via the Internet. The connection protocol imposes restrictions on what connections can be formed at the level of the overlay network, that is, at the layered network level, some connections do not exist or are not allowed. Each connection node of LN (300) is configured to operate according to the overlay level protocol of LN (300) (including the connection protocol) which determines what connections a node can and cannot form at the overlay level. In other words, a connection is an allowed communication channel configured to be formed by two nodes according to their protocol. When a node is connected to another node, it can communicate with the other node without hopping through other nodes of the layered network, but if it is not, the node cannot and can only communicate by hopping through one or more other nodes connected between them.

[0098] The connection protocol requires that a connection node be connected to at least one node of a preceding (inner) layer and at least one core node, except that in some examples, the core node may be the innermost layer and therefore cannot be connected to a preceding layer. In an example where the connection node is a second node, these two requirements are equivalent. If the connection node is an outer node of a first outer layer, the connection node is connected to at least the second node (302) and the core node (301).

[0099] The connection protocol may require that a connection node be connected to one or more core nodes. The connection protocol may additionally require that a connection node be connected to one or more core nodes, for example, all core nodes except one, rather than all core nodes. A connection node may be a second node that must be connected to two or more core nodes. That is, some or all of the second nodes must be connected to two or more core nodes (and in some examples, not all core nodes).

[0100] The connection protocol may require that a connection node be connected to one or more second nodes. If the connection node is a second node, this means that the connection (second) node must be connected to one or more other second nodes. If the connection node is an external node, the connection (external) node must be connected to one or more second nodes. The connection external nodes may be external nodes of the first external layer, or external nodes of the second layer, etc.

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

[0102] A connection protocol may require that an external node be connected to one or more (e.g., two) external nodes of the same external layer. A connection protocol may require that each external node be connected to one or more external nodes of the same layer. Alternatively, some external layers may include one or more external nodes forming a same-layer connection, and some external layers may include one or more external nodes that do not form a same-layer connection. A connection protocol may require that each external node of the same external layer be connected to the same number of different external nodes of that layer. For example, each external node of the first external layer may be required to be connected to two external nodes. Each external node of the second external layer may be required to be connected to three external nodes. That is, the number of external nodes of the same layer to which an external node is connected may differ between external layers.

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

[0104] In an embodiment where some or all of the nodes of LN (300) are associated with digital certificates, the connection protocol may require that the connection node be connected only to the node associated with the individual digital certificate. In some embodiments, the connection protocol may require that the connection node (e.g., external node) be connected only to the individual node (e.g., second node) if the digital certificate associated with the individual node was issued by a node of a layer preceding the individual node (e.g., core node), or, in some examples, by a node of the same layer as the individual node (e.g., different second node).

[0105] In some embodiments, the connection protocol may require that a connection node can be connected only to a node that has issued a digital certificate to the connection node. That is, connecting to a node includes receiving a digital certificate from that node.

[0106] Connection protocols enable the construction of BLNs. Like Mandala Networks, BLNs are constructed in layers. Unlike Mandala Networks, the first layer can form an incomplete graph (e.g., a nearly complete graph). Another difference between BLNs and Mandala Networks is that in BLNs, nodes within each successive layer can have different degrees, a node can be connected to more than one node within the central layer, and / or the degree of a node can differ between layers.

[0107] Preferably, for all nodes outside the central core:

[0108] (i) Each node is connected to m nodes out of n1 nodes in the central core.

[0109] (ii) Each node is connected to every node within each layer, where g is the total number of layers.

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

[0111] (iv) Each node is connected to every other node in at most 3 hops. This is referred to as the diameter of the graph.

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

[0113] The characteristic of a mandala network is that every node outside the core layer (i=1) has exactly one core ancestor (i.e., c everywhere). i It means that it is connected to =1). This contributes significantly to the emerging properties of the mandala network.

[0114] ● Network size ( As ) increases, it has an average shortest path length that asymptote to a constant.

[0115] ● Network size ( As ) increases, it becomes very rare.

[0116] ● Robust against random node failure.

[0117] A characteristic of BLN is that all non-core nodes are connected to at least one ancestor. However, the definition of BLN accommodates non-core nodes with a maximum of m connections to a core ancestor (i.e., 1≤c everywhere). i ≤m). Over the entire BLN, c i From =1, 1≤c i The reason for generalizing to ≤m can be understood as an artifact of the blockchain protocol. The protocol defining the blockchain system relies on a probabilistic security model. Essentially, this means that any participant (node) within the BLN who has a vested interest in the event recorded in the blockchain (150) must consider the probabilistic security model by connecting to the minimum fraction (f) of the network hashing power, where 100% of the total hashing power is distributed among the nodes within the core layer of the BLN.

[0118] Assuming that the core layer exhibits a uniform equilibrium distribution of hash power among its n1 core nodes, the minimum ratio of nodes is as follows.

[0119]

[0120] The blockchain protocol indicates that while the lower bound for the minimum rate is f=0.51, network participants in the BLN at scale may require a higher rate (e.g., f=0.67) to increase elasticity (e.g., up to double-spending). The BLN may feature a choice of parameter (m) because this dictates the stochastic security of behavior for participants within the BLN, which depends on the specific use case for the requirements of the BLN.

[0121] The Layer 2 (L2) node closest to the core relies most heavily on the probabilistic security model of the blockchain protocol, and this dependency is L g It can be reduced at the layer accessing it. The connection protocol may require that a node at L2 is connected to exactly c2=m core ancestors, whereas all consecutive nodes at layer i>2 can be anywhere 1≪c i It may be required that a node be connected to a core ancestor in the range ≤m. In some examples, every node within a contiguous hierarchy must be connected to m core ancestors.

[0122] Nodes outside the central core of the BLN can be connected to the core as 'SPV type'. This means that they can do the following:

[0123] a) Send the transaction to the core node.

[0124] b) Ask the core node whether the transaction has been accepted in its own mempool / candidate block.

[0125] c) Request Merkle proof of the transaction mined in the block.

[0126] d) Request the latest block header list.

[0127] These simple and 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 using the BLN. Many use cases will not require the connection types described above. In some examples, the second node (302) and / or the external node (303) are configured to perform only operations a) through d) above. However, other solutions, typically at the enterprise level, may require the core to actively serve more data, such as transactions that meet specific criteria. Thus, while operations a) through d) are the minimum requirements for the BLN, in some examples, additional data transfer between the node and the core is also possible.

[0128] For nodes running a smart contract, some nodes may only require SPV-type operations a) through d), while other nodes may require consensus to receive more data from the core node.

[0129] In some BLNs, users can operate nodes at layer 3 or higher, and smart contracts can be operated by nodes at layer 2 or higher. Because users require continuous monitoring of the blockchain (150) for transactions containing a specific output address, they cannot actually 'listen' to the blockchain continuously for transactions with a specific output address. Given that the number of transactions that can be sent to the blockchain at regular intervals continues to increase, such continuous monitoring is not practical for the end user. In some blockchain wallet architectures, continuous monitoring of the blockchain is common, but given that both the number of transactions submitted to the blockchain at regular intervals and the number of users of the blockchain are expected to increase dramatically in the future, this is not a scalable solution. The following example is considered. Alice wants to pay Bob. She creates a transaction for the desired amount with an output address that she knows belongs to Bob. Then, Alice submits this transaction to a mining network instead of submitting it directly to Bob. To know that a transaction has been accepted, Bob must 'listen' to the blockchain to check when and where a transaction with his output address appears on the network. He must request a mining node to perform this on his behalf. This means that the mining node must record Bob's address and check whether every single transaction it receives matches this address. It should be noted that there is no economic incentive for the miner to perform this. If we assume that a miner must process one million transactions per second and check whether those transactions match one million addresses, it quickly becomes clear that this is unrealistic.

[0130] Instead, in BLN, Alice can connect directly with Bob and send transactions directly to him. Then, Bob can send the transaction to a miner within the core and simultaneously ask them whether they accept the transaction as valid. Since the transaction includes their fees, miners are encouraged to accept the transaction, and they are encouraged to verify whether they have accepted the transaction to reduce the risk of constructing an orphaned block. To make the system much more secure, Alice can send the Merkle proof of the input for her transaction to Bob. Since Bob has a copy of the block header, he can check these Merkle proofs. This guarantees Bob that if Alice's input was part of the blockchain (150) at one point and she had already spent it, he would have proof of double spending because he received a signature from Alice in the transaction Alice provided to him. It is noted that Bob can be a smart contract (second node) and Alice can be a user (external node) who wants to interact with that smart contract. In the case where the smart contract is 'light' in the sense that the smart contract operator has not reached any specific consensus with the mining node to enable the processing of the smart contract, the smart contract operator cannot also rely on listening to the blockchain (150) to receive transactions that trigger a state change. Alice must send such transactions directly to the smart contract.

[0131] Service providers can operate nodes at Layer 2 or higher. The case of service providers differs from that of users or lightweight smart contracts. Service providers can reach commercial consensus with core mining nodes or a collection of core nodes, and then they propagate a specific subset of transactions to service provider nodes. These transactions must be easily identifiable and meet the following specific criteria.

[0132] ● OP_RETURN data with a specific protocol flag. For example, Metanet protocol, Tokenized protocol, or Digital Certificate protocol.

[0133] ● Output addresses that match a specific small set. For example, enterprise-level smart contracts or address whitelists / blacklists.

[0134] ● Secondary consensus rule set indicated by the OP_VER control branch.

[0135] Additionally, transactions sent to a core identified as part of a community that follows these rules or participates in service-level consensus in other ways may have lower (or even zero) transaction fees. The shortfall may be made up by higher transaction volumes or fiat revenue from service-level consensus.

[0136] All nodes of BLN (300) can be associated with a semi-permanent public key associated with their identity. This public key can enable secure communication through the deterministic derivation of the identity key or by using the identity key to sign or encrypt the transaction key, and can provide a link to the public key used in the blockchain transaction.

[0137] The two methods for identifying mining core nodes are as follows.

[0138] 1) Miner ID. Miners may choose to identify themselves by adding their identity key to the input of the coinbase transaction of each block they mine.

[0139] 2) Network analysis. Some miners choose to maintain anonymity. However, it is still possible to identify which node constitutes a block through network analysis, for example, by examining the source of a new block.

[0140] It is important that BLN nodes identify two types of miners so that they can poll as many miners as possible regarding whether their transactions have been accepted.

[0141] A core node with a miner ID can issue digital certificates to Layer 2 nodes. This may be because they have reached a service-level consensus with these nodes, or because these nodes have requested certificates for fees. In this sense, core nodes can act as Certificate Authorities (CAs).

[0142] Layer 2 nodes can find an external CA to issue them digital certificates, regardless of whether they have a certificate from a core node. Therefore, each Layer 2 node can have at least one digital certificate proving its identity. They can issue certificates to other Layer 2 nodes, thereby creating a web of trust between them. Nodes within Layer 2 issue certificates to nodes within Layer 3, and nodes within Layer 3 issue certificates to nodes within Layer 4, and so on, creating a hierarchical structure of certificates referred to as the Public Key Infrastructure (PKI).

[0143] In fact, such a PKI can be used not only to identify nodes of a BLN but also to ensure that the correct BLN structure is adhered to. For example, if a Layer 3 node issues certificates to too many Layer 4 nodes, or fails to ensure that they are properly connected to other nodes in the system, the certificates of the Layer 3 nodes may be revoked.

[0144] These certificates themselves can be stored on a blockchain (150). This makes the PKI transparent and easily auditable.

[0145] Alignment and timestamping

[0146] There may be many applications that can be implemented using a blockchain where the order of application data is important. To address this, according to an embodiment of the present disclosure, one or more nodes of a network may be configured to act as a proof service that mediates between different items of data submitted to the service in order to determine the deterministic order of data items and then record said order immutably on the blockchain.

[0147] The proof service is implemented in one or more proof nodes. In the embodiment, these are nodes of an overlay network overlaid on an underlying infrastructure network such as the Internet. However, alternatively, it is not excluded that they may be infrastructure nodes of a network, e.g., a private network within an organization, with their own authority. In either case, one or more proof nodes are arranged to receive data items from one or more client nodes, form a transaction that records the order of the received data items, and transmit this transaction to one or more core nodes for recording on the blockchain (150). The core nodes are nodes (104) of the blockchain network (106). These may include mining nodes (104M), storage nodes (104S), or a combination thereof. In the embodiment, each core node is a mining node (104M) and / or a storage node (104S) (e.g., a full copy node).

[0148] Each client node may be an end-user node comprising computer equipment of a service user. This may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, each client node may include a server comprising one or more server units at one or more sites and / or one or more user terminals. Each client node includes memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take any form of memory media and / or processors, such as those previously discussed in relation to other network elements or user equipment, for example. The memory stores client software arranged to be executed in the processing unit, wherein the client software is configured to cause the node to operate as a client of a certification service provided by the certification node(s) according to any of the following embodiments or similar embodiments when executed. Optionally, one or more of the transmitting end-user nodes may include user equipment (103) of a user (102) of the blockchain network (106), and the client software may include a blockchain wallet application (105), etc. However, the proof service may be arranged to formulate at least some of the transactions on behalf of the end user, rather than all of such transactions necessarily being formulated in the user's wallet (105).

[0149] A certification node is arranged to provide a certification service that mediates between a client node and a core node. Each certification node may take the form of a server comprising one or more physical server units. Each of these nodes includes memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take any form of memory media and / or processors, such as those previously discussed in relation to other network elements, for example. The memory stores certification service software arranged to run on the processing unit of the certification node. This software is configured to provide a certification service that, when executed, operates according to any of the embodiments described below or similar embodiments. In the embodiments, the identity of each certification node is authenticated by a certification authority, enabling the client node, the core node, and / or other certification service nodes to verify the identity of the certification node. The identity of each client node is authenticated by a certification authority, enabling the certification service node, the core node, and / or other client nodes to verify the identity of the client node. Interaction between these nodes for the purpose of providing or using the certification service may be conditioned on validation. Alternatively, or additionally, node versioning can be used as an alternative mechanism for node identification in overlay networks.

[0150] In the embodiments, the above arrangement may be implemented in the form of a layered network (700) of the type described, for instance, in relation to FIGS. 3 through 6 and also illustrated as an example in FIG. 7. That is, the layered network comprises: a core network including a core node (701); at least one intermediate layer around the core—each intermediate layer including one or more intermediate layer nodes (702)—; and at least one outer layer around the outermost layer of the intermediate layer, each outer layer including one or more outer layer nodes (703). It is noted herein that the term “outer” in “outer layer” is not necessarily limited to the outermost layer of the layered network (700) in itself, but is a possibility. In an embodiment, the layered network (700) of FIG. 7 may be the layered network (300) of FIG. 3, in which case the outer layer node of FIG. 7 is the third layer node of FIG. 3 or 4, the middle layer node (702) of FIG. 7 is the second layer node (302) of FIG. 3 or 4, and the core node (701) of FIG. 7 may be the core node (301) of FIG. 3 or 4.

[0151] As discussed in relation to FIGS. 3 through 6, the layered network (700) may be an overlay network overlaid on an underlying physical or infrastructure network, such as the Internet. In this embodiment, nodes (701, 702, 703) are configured to form connections with one another at the overlay network level. That is, nodes (701, 702, 703) of the layered network are configured to follow an overlay network protocol that specifies what connections they can and cannot form with other nodes (701, 702, 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 these nodes (701, 702, 703) may be more restricted when they participate as nodes (701, 702, 703) of the layered network operating according to the relevant overlay network protocol of the layered network (700). A connection between two nodes (701 / 702 / 703) of a layered network (700) means that these nodes can communicate directly, and in this context, this means that there is no need to perform hops through other nodes (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., the level of the overlay network protocol of the layered network).

[0152] Each intermediate layer node (702) is connected to at least one core node (701) (blockchain network node (104)) of the 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.

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

[0154] Each outer layer node (703) is connected to at least one of the intermediate layer nodes within at least one intermediate layer. In an embodiment, each outer layer node (703) also has at least one connection to at least one core node (701) (i.e., blockchain network (106)). In some of these embodiments, each of the one or more outer layer nodes (703) is connected to more than one core node, though not all of the core nodes (701). In an embodiment, the layered network (700) may be an incomplete network in total, that is, not every individual node (701, 702, 703) is connected to every individual other node at the overlay network level. In an embodiment, each node within a given layer may be connected to at least one other node within the same layer. For example, each node (702) within the intermediate layer may be connected to one or more other nodes within the same intermediate layer, and / or each node (703) within the outer layer may be connected to one or more other nodes within the same outer layer. In the embodiment, a connection may also be formed between different intermediate layer nodes (702) within different intermediate layers and / or different outer layer nodes (703) within different outer layers.

[0155] In an embodiment, the layered network (700) may be configured according to any protocol rule or structural feature described in relation to FIGS. 3 through 6, wherein each intermediate layer of the intermediate node (702) is a layer between the core and the outermost layer, and each outer layer of the outer node (703) is a layer outside the second layer (the intermediate layer(s) are between the core and the outer layer(s)).

[0156] The following embodiments will be illustrated in the context of a layered network, but are not limited thereto, and it will be recognized that, more generally, the proof node(s) may be any node of any type of overlay network mediating between one or more core nodes (104) of the blockchain network (106) and one or more client nodes.

[0157] In an implementation in a layered network (700), at least one of the intermediate nodes (702) within at least one intermediate layer acts as a proof node (702A) providing proof services. At least one of the outer nodes (703) within at least one outer layer 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). Although only two client nodes (703C) and two proof nodes (702A) are shown in FIG. 7 for the sake of simplicity of illustration, it will be recognized that there may be more nodes. In the embodiment, the client nodes (703C) and the proof nodes (702A) may be part of the same community.

[0158] The client nodes (703C) are clients in that they are clients of the proof service. In an embodiment, client software running on one or more of the client nodes (703C) may be further configured to operate its nodes (703C) as clients of one or more additional services provided by one or more second-tier nodes (702), such as database services or smart contract services. And / or, this may be configured to operate its nodes (703C) as clients 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), for example.

[0159] Additionally, the fact that the client node (703C) is described as a client of the certification service (and optionally one or more other services) does not exclude the possibility that the node itself may also be a server of one or more additional services for one or more additional entities (not shown). For example, the client node (703C) may include computer equipment of a company providing online services to customers. In this document, “end user” means the end user of the specific service and is not necessarily limited to an individual consumer at the end of a commercial supply chain (although, of course, that is also a possibility).

[0160] The following describes how a sorting service entity (702A) can use a blockchain (150) to record the sorting and time of data elements received from one or more client nodes (703C). Optionally, the sorting service may also perform timestamping.

[0161] A method for a single trusted order proof node (702A) is first described. This can be modeled as a single intermediate layer (e.g., second layer) node within a layered network (700) having a core of a blockchain network node (104 / 701). Then, the user of this service will be a user of an outer layer (e.g., third layer) node (703C) that is directly connected to the service (702A) and optionally also to the blockchain (150) (by connection to at least one corner node (701) within the core).

[0162] When data elements are received from an external layer client node (703C), the intermediate layer timestamping service (702A) will collect the data elements together in an ordered manner. When a specific time period, e.g., 0.1 seconds, has passed, this list of ordered data elements is encapsulated in a transaction and transmitted to the blockchain (150) via the core (701), and thus recorded immutably. When a timestamp is added to the record, it also records the time as well as the order.

[0163] An exemplary application defines a deterministic order between updates to entries, etc., within a database. In this case, each data item received from the client node (703C) may represent an individual state change (i.e., an update) to an entry within the database. However, these updates are not necessarily commutative; that is, the order matters. For example, if there are two requests to perform non-commutative operations on data elements, such as matrix multiplication from the left, the order matters. In another example, one request might be to delete a file, and the other to read a file. In other words, the order in which these requests are applied makes a difference in the result.

[0164] Another exemplary application is implementing a smart contract in an output-based (e.g., UTXO-based) blockchain model. Since UTXO-based transactions, etc., do not inherently support smart contracts in the same way as transactions in an account-based model, when a smart contract is implemented in an output-based model such as a UTXO-based model, the smart contract function needs to be layered on top of the underlying transaction model. In this case, the data item to be recorded in the blockchain (150) may represent a change in state, such as a change in ownership. In other words, order is important because, for example, the order can affect whether an attempted transfer of ownership is valid.

[0165] Another exemplary application is the alignment and timestamping of digital certificates from Certificate Authorities (CAs). Digital certificates are used to authorize access rights or other electronic permissions, for example, in the SSL / TLS and HTTPS security that underpin the Internet. In 2011, a Dutch CA was compromised by an attacker believed to be operating from Iran. False certificates were issued for high-profile domains, and log files on the CA server were tampered with. If these log files had been stored on a blockchain using the alignment and timestamping services described below, altering the log files would not have been possible due to the security provided by Proof of Work. It is worth noting that the private keys in the company's HSMs were compromised in the attack. This highlights the fact that one cannot always rely solely on classical cryptographic protocols to ensure information security, and that relying on other mechanisms, such as Proof of Work, to make such attacks significantly more cumbersome can also be beneficial.

[0166] In operation, the proof node (702A) is arranged to receive multiple data items from one or more client nodes (703C) via an overlay network connection between the intermediate layer and the outer layer. The data items may be labeled D in the invention using any term. 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 from different client nodes (703C). They may be received directly via the connection between the client node (703C) and the proof node (702A), or transmitted via one or more other nodes of the layered network in between (i.e., received via more than one hop between the transmitting client node (703C) and the proof node (702A).

[0167] The proof node (702A) is configured to determine the order of multiple data items (D) and thus determine the multiple data items of the sequence. In an embodiment, the determined order is the order in which the data items are received at the proof node (702A). However, it is not excluded that some other arbitration rules may be applied. For example, if a data item is stamped with the time of transmission or creation by the client node(s) (703C) that transmitted it, and the proof node (702A) trusts this client node, the order may be the reported transmission or creation time rather than the reception time. As another example, the order may vary according to a priority scheme that assigns different weights to different data items.

[0168] Whatever the determined order may be, the proof node (702A) proves this order by generating a series of blockchain transactions (152) to be recorded on the blockchain (150). The proof node (702A) generates two or more such transactions in a series that may be labeled herein as Tx0, Tx1, Tx2… by any term. The proof node (702A) includes a representation of one or more different sets of data items (D) in the payload of each consecutive transaction (Tx) within the series. The payload may be included in the non-spending output of each individual transaction. Such output may be made non-spending by an operation code, such as OP_RETURN, which terminates the lock script of the corresponding output. However, in other transaction protocols, the payload may be included in a different way. The set of one or more data items represented in each consecutive transaction follows the set represented in the transaction immediately preceding the corresponding transaction within the series, according to the order of data items determined by the proof node (702A). In other words, the order of transactions within the series corresponds to the order of the set of data items in the determined sequence.

[0169] The proof node (702A) generates a public / private key pair for the corresponding series for the transaction in the series, or otherwise determines.

[0170]

[0171] The proof node (702A) uses the private key of each key pair to sign the corresponding transaction within the series of transactions.

[0172] .

[0173] Transaction Tx1 includes P1's signature in its input unlock script, transaction Tx2 includes P2's signature, and so on. Each transaction also includes a payload, for example, in the OP_RETURN field, which contains a representation of a set of one or more data items (D) verified by the individual transaction. This payload is signed over by each signature (in an embodiment using a scripting language, an appropriate SIGHASH flag may be used). The initial funding transaction Tx0 is configured to be unlocked by P1's signature. It may have an outpoint of 0 with a dust value. As an example, Tx1 may be configured as shown in FIG. 8. All subsequent transactions have the same structure. That is, Tx2 includes a signature using P2 in the input pointing to Tx1 to unlock Tx1, and has a lock script in the output that can be unlocked by P3's signature, and so on. The signatures can be verified by the blockchain network (106) based on the corresponding public key of the key pair. Funding transaction Tx0 may or may not include a representation of the first set of data items (the first set of data items in the sequence may be represented in Tx0 or Tx1).

[0174] Note: The form illustrated in Fig. 8 ignores transaction fees for the sake of simplicity. This can be explained by adding other inputs and outputs to the transaction (e.g., managed by a proof service).

[0175] The OP_RETURN statement contains a payload called data1. This contains the data elements (D) submitted by the user or their representations in the order verified by the verification service from the set verified by Tx1. (And the same applies to data2 of Tx2, in this format). Since each transaction signs the hash of the previous transaction, this also implies the order of payloads data1, data2, data3, etc.

[0176] Once a blockchain transaction is accepted by the blockchain network (106), it cannot be effectively double-spended. It also serves as a public form of the order proven for the proof service provided by the proof node (702A). This assures the client node (703) that the position of the user's data elements appearing in the order proven by this proof authority cannot be retroactively changed. Once this transaction is mined in a block (151), the likelihood of the order being changed becomes much lower because replacing the existing block is computationally expensive.

[0177] In some embodiments, the sets indicated in each transaction Tx0, Tx1, Tx2… consist of only a single data item among the data items (D) per transaction (i.e., each data payload represents only a single individual D). Alternatively, the sets indicated in each of these transactions may include multiple data items (D) per transaction (each data payload represents multiple different data items (D) of different individual sets). In the latter case, the payload information also specifies the order of the data items (D) within the individual transaction of the local set. This can be achieved, for example, by an ordered list included in the payload (e.g., OP_RETURN output) and / or an index indicating the order mapped to the indication of each D. An example to be discussed in more detail shortly is illustrated in FIGS. 9 through 11.

[0178] When multiple data items (D) are presented per transaction, some criteria are required to determine which data items are collected together per transaction. In principle, any method may be used to split data items between transactions, but in the embodiment, this may be based on regular time intervals. That is, all data items (D) received by the proof node (702A) within the first instance of a regular time interval are included in the first transaction within the series, and then all data items (D) received within the next instance of a regular time interval are presented in the next transaction within the series, and so on.

[0179] The exact timing of the interval between transactions can be configured by the implementation. For example, transactions can be submitted at intervals of 0.1 seconds.

[0180] Individual sets of data items may simply be indicated in a transaction by explicitly including the data item(s) of the set in the payload of the individual transaction Tx ("in plaintext"). Alternatively or additionally, they may be indicated in a hash, an encrypted form, or a modified form such as an r-puzzle. Examples will be discussed in more detail in relation to FIGS. 9 through 11. In the context of a proof of order service, at least, the "indication" of a data item herein means that some information enables a query node examining the transaction to verify the proven order of the data item. In some cases where the explicit value of a data item (D) is not explicitly included in the transaction, this may require the query node to simply examine the transaction in the mempool (154) of the on-chain or blockchain node (104) with predetermined knowledge of the value of the data item (D) to verify the expected order of the item.

[0181] In an embodiment, the proof node (702A) may also include at least one timestamp in the payload of each transaction Tx0, Tx1, Tx2… of the series. The timestamp indicates the time when the individual data item(s) were received at the proof node (702A). In the case of a single data item (D) per transaction, this may simply be the time of receipt of the corresponding data item. In the case of multiple data items (D) per transaction Tx, each transaction payload may include a single timestamp indicating the arrival time for the set (e.g., the time interval at which the data items were received) or individual timestamps for each data item (D) within the set.

[0182] When the proof service submits a transaction containing user data to the blockchain (150), in some embodiments, the proof service will also transmit this transaction to the client node(s) (703) that submitted the data item (D). This is possible because the user of the outer layer (e.g., Layer 3) is directly connected to the proof node (702A) of the intermediate layer (e.g., Layer 2). In an embodiment, because the client node (703) is also directly connected to the core blockchain mining node (104M) and / or storage node (104S), the client node (703) can independently check that transactions Tx0, Tx1, Tx2… have been 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 storage node (104S) to verify that the expected order has been proven. Other third-party nodes may also verify this in a similar manner through any suitable connection of the blockchain network (106). In some embodiments, a query by the client node (703A) may be performed through the connection between the client node (703C) and the core using only the SPV-type connection previously discussed in relation to FIGS. 3 through 6.

[0183] Optionally, the certification service may also transmit a chain of transactions preceding the transaction containing their data to the client node(s) (703C) that submitted the data item. This is to ensure that the user is confident that there are no two competing chains of transactions of different order submitted to the blockchain by the service. The length of the chain of transactions must be suitable for the level of trust required by the user. This trust can be outsourced, for example, a certification authority can certify the accuracy of the chain of transactions every hour.

[0184] In the embodiment, client nodes (703C) within the layer may also be connected to each other and can transmit (mined) transactions containing their and corresponding Merkle proofs to each other. In the embodiment, because each outer layer (e.g., layer 3) node is independently connected to the blockchain (150), they can verify that the Merkle proof is correct. This allows a user of the outer layer (e.g., layer 3) to agree to the alignment of data with only a minimum amount of temporary trust in the timestamping service before the trust in the blockchain's proof of work is accepted.

[0185] Next, we will explore the OP_RETURN payload data1 in more detail. The goal is for the service to verify the order in which data elements D1, D2, D3,… were received over time intervals. It should be noted that data elements may represent hash commits of data associated with each user. This may be at the user's discretion regarding whether to disclose their data or, instead, record hash commits of their data.

[0186] There are several different ways in which the data items (D) of a set and their relative order can be represented within a transaction Tx. The simplest method is to simply index each element, and since OP_RETURN is signed, this is verified by a timestamping service. However, there is a smarter way to do this that provides additional proof of alignment and allows for generalization to distributed timestamping services.

[0187] Method 1.1: Hash chain. A unique index (i) for each data element D i Assigned to, and entry H of the hash chain i is generated. H iThe value of depends on the data element and the previous element of the hash chain. This means that each element of the hash chain must be created after the previous element to apply the order. An example of a hash chain is shown in the table in Fig. 9. This table will be included in the transaction payload (data), and optionally, an explicit D column may or may not be included in the transaction.

[0188] One advantage of the case where the value of D is not explicitly included is that the hash can be smaller than D, and therefore requires fewer bits to be stored in the chain. Additionally, this means that if the user does not want to disclose the actual value of D, there is no need to disclose the actual value of D. In either case, regardless of whether the value of D is explicitly included, another advantage of the hash chain is that it makes it difficult to change the order. As an example, assume there are 1,000 data items (D) per transaction. Then, reordering these data items would require performing 1,000 hashes, which would be a computational burden. Therefore, even if the proof node (702A) is not fully trusted, this provides the user with additional assurance that the data items have not been reordered.

[0189] In some embodiments, each data element (D i Timestamp of reception of ) (t i A proof of ) may also be included. One way to do this is to include a timestamp in the preimage of each element of the hash chain, for example as follows.

[0190] , There are others.

[0191] In this case, a column containing time will also be added to the table in Fig. 9.

[0192] OP_RETURN payload data1 consists of a table as illustrated in FIG. 9. The 'data' column may be omitted to save space or to keep data elements private. In this case, it should be noted that the only way someone can verify the order of the hash chain is if all data elements are known.

[0193] Additional security can be provided by replacing hash functions with HMACs. HMACs are described in RFC 2104 and introduce a secret symmetric key into the hashing process. This means that only those who know the secret key can verify the order of the data.

[0194] Method 1.2: Hash chain with a Merkle tree. This case is similar to the hash chain of Fig. 9, but instead of exposing the entire hash chain, it is converted into a Merkle tree, and only the root is exposed. In this case, each data item (D) of the set is modeled as a leaf of the Merkle tree. The Merkle root is included in the transaction as an indicator. It is noted that the index of the data is implied by the order in which the data appears in the leaves of the Merkle tree. The Merkle proof can be provided to the user later to allow the user to check the existence and location of the data item in the Merkle tree. This method saves space in the transaction because only 256 bits are required for the OP_RETURN payload for the Merkle root.

[0195] Additionally or alternatively, each data item may be represented in a transaction by a corresponding Merkle proof for its leaf. As will be familiar to those skilled in the art, a Merkle tree allows proving 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).

[0196] Method 2.1: Chain of signatures. In this method, a new public key is generated for each data element (D), and the element is signed with the new public key. This is adjusted according to the requirements of the timestamping protocol outlined in RFC 3161.

[0197] Consider the sequence of signatures and public keys illustrated in Fig. 10. The idea is that each public key is generated based on preceding data. Similar to a hash chain, each public key (and thus the signature) in the sequence is generated only if the previous public key in the sequence is known, and thus the order can be applied.

[0198] In a variation of this method, each entry in the table can be a transaction itself.

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

[0200] An ECDSA (elliptic curve digital signature algorithm) signature consists of a (S,R) combination, where R is the x-coordinate of the public part of the temporary key pair. While the same public key is used for each signature, it is possible to chain the temporary keys together. This will provide the sequence illustrated in Fig. 11. This can be included in the transaction payload (data) as an alternative to any of the above methods or as an additional step.

[0201] Here, R1 is a random temporary key, and <S1, R 1i > (H(D i )) is data H(D i ) is a temporary key(R 1i It means that it is signed as P1 using ).

[0202] Generally, any one of methods 1.1, 1.2, 2.2 and / or 2.2 and / or other methods may be used individually or together to indicate the order among a set of data items (D) in the payload (data) of a transaction.

[0203] Distributed Case: The above description was made in a scenario where the order proof service is provided by an individual node (702A). It is also possible to provide this service through multiple proof nodes (702A).

[0204] For example, consider a situation in which a distributed proof service using a layered network (700) to achieve consensus is used. In this case, more than one of the intermediate layer nodes (702) (e.g., layer 2 nodes) of FIG. 7 will act as proof nodes.

[0205] It is assumed that most proof nodes (702A) operate honestly and that consensus is desired regarding the alignment and timestamping of data propagated around a community (as previously defined) consisting of proof service nodes (702A) and users (703C). It is assumed that there are N independent proof service nodes (703A) connected to m core mining nodes (701) of the same subset and thus defining a community of a layered network (700). The fact that there are multiple intermediate layer (e.g., layer 2) proof nodes (702A) allows many users of the outer layer(s) (e.g., layer 3) to connect to nodes (702) within the intermediate layer (e.g., layer 2) without the load on the intermediate layer nodes becoming too high (without too many connections).

[0206] For example, in a distributed case, the problem to be solved is how the intermediate layer proof node (702A) (e.g., layer 2 node) can reach a consensus on the alignment of the two data items (D1, D2) even if, for example, two data items (D1, D2) submitted by two users arrive at one proof node (702A) in a different order compared to others.

[0207] One method to solve this problem is to use threshold signatures, that is, as previously discussed, at least M distinct signatures (M>1) rather than just one are required to unlock a transaction (Tx). Consider the M-of-N threshold signature system as described, applied to the proof service node (702A). This involves a private keyshare (a1, a2,.., a N This means that there are N participating nodes having ). M participants of any subgroup can create a signature share that is combined to provide a signature of a message to unlock a preceding transaction in the series.

[0208] It is assumed that one of the proof service nodes (702A) generates a candidate transaction Tx1 containing OP_REUTRN payload data1, which is an ordered list of all data elements (D) received by it during a selected time period. This node may broadcast the candidate transaction to all other proof service nodes (702A) (or at least some of them) and request their signature shares to sign the transaction. When they receive at least M signature shares (including their own), the transaction can be submitted to the blockchain network (106) and mined into a block (151). This ensures that the order of the data elements is agreed upon by at least M-of-N timestamping services in the distributed network.

[0209] How is a single proof node (702A) selected to generate a transaction? The above assumes that there is only one proof service node (702A) generating candidate transaction Tx1 and that other proof nodes (702A) have approved it. However, what about the next candidate transaction? There are at least two options as follows: (i) there is always one authorized proof node (702A) generating candidate transactions, or (ii) after each transaction is generated, one of the proof nodes (702A) is randomly selected as the next node to generate the next transaction. This may be a previously determined random sequence or a deterministically random selection based on a seed associated with the transaction Tx1 just submitted. For example, the seed may be taken as Tx1. Other distributed arbitration algorithms for distributed computing may also be possible.

[0210] Distributed database

[0211] FIG. 12 illustrates an example of a distributed database implemented in a layered network (1200) according to an embodiment disclosed herein.

[0212] A layered network (1200) comprises: a core network comprising one or more core nodes (1201); at least one intermediate layer surrounding the core—each intermediate layer comprising one or more intermediate layer nodes (1202)—; and at least one outer layer surrounding the outermost layer, each outer layer comprising one or more outer layer nodes (1203). Again, the term “outer” in “outer layer” herein is not necessarily limited to the outermost layer, but is a possibility. The layered network (1200) may be an overlay network overlaid on an underlying physical or infrastructure network such as the Internet, or alternatively, a standalone network such as a dedicated and / or internal (e.g., private) network within an organization.

[0213] A core node (1201) is a node (104) of a blockchain network (106). These may include a mining node (104M), a storage node (104S), or a combination thereof. In an embodiment, each core node is a mining node (104M) and / or a storage node (104S) (e.g., a full copy node).

[0214] In some cases, some of the intermediate layer nodes (1202) and / or outer layer nodes (1203) may include nodes other than storage nodes (104S), such as peripheral nodes (104) of the blockchain network (106), for example, mining nodes (104M) and / or forwarding nodes (104F). Alternatively, they may include nodes that do not have any role (mining, storage, or forwarding) in the blockchain network (106) and are not clients of the blockchain network (106).

[0215] An intermediate node (1202) includes multiple database nodes (1202DB) across one or more intermediate layers of a layered network (1200). These database nodes (1202DB) are configured to store a distributed database, so that each database node (1202DB) stores at least a portion of the entire database containing one or more database entries. In an embodiment, the entries are replicated across more than one node, so that at least some entries are replicated across more than one database node (1202DB). In some cases, each database node (1202DB) may store a copy of the entire database, but in other embodiments, each database node (1202DB) stores only a portion of the database, and each entry may be replicated across only a portion of the database nodes (1202DB) rather than all of them (the database nodes (1202DB) between them are distributed to store the entire database).

[0216] Each database node (1202DB) may take the form of a server comprising one or more physical server units. Each of these nodes includes memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take any form of memory media and / or processors, such as those previously discussed in relation to other network elements, for example. In addition to the database entries themselves, the memory stores database software configured to be executed in the processing unit of the proof node. This software is configured to provide database services that, when executed, operate according to any of the embodiments described below or similar embodiments.

[0217] In an embodiment, the identity of each database node (1202DB) may be authenticated by a certification authority to enable client node(s) (1203C), a core node (1201) and / or other database nodes (1202DB) or other intermediate layer nodes (e.g., a certification service node (702A) or a smart contract node) to verify the identity of the database node (1202DB). Interaction between these nodes may be conditional on verification. For example, a client node (1203C) may send only update requests to the database node (1202DB) on the condition that its identity is verified based on authentication. Alternatively or additionally, node versioning may be used as an alternative mechanism for node identification in an overlay network.

[0218] Each client node (1203C) may be an end-user node comprising computer equipment of a service user. Again, this may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, each client node may include a server comprising one or more server units at one or more sites and / or one or more user terminals. Each client node includes memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take any form of memory media and / or processors, such as those previously discussed in relation to other network elements or user equipment, for example. The memory stores client software arranged to be executed in the processing unit, wherein the client software is configured to cause the node to operate as a client of a distributed database provided by a database service provided by a database node (1202DB) according to any of the following embodiments or similar embodiments when executed. Optionally, one or more of the transmitting user nodes may include user equipment (103) of a user (102) of the blockchain network (106), and the client software may include a blockchain wallet application (105), etc.

[0219] In an embodiment, the identity of each client node (1203c) may be authenticated by a certification authority to enable a database node (1202DB), other intermediate layer nodes (e.g., a certification service node (702A) or a smart contract node), a core node (1201), and / or other client nodes (1203C) to verify the identity of the client node (1203C). Interactions between these nodes may be conditional on verification. For example, the database node (1202DB) may accept only updates from the client node (1203C) on the condition that it verifies its identity based on authentication. Alternatively, or additionally, node versioning may be used as an alternative mechanism for node identification in an overlay network.

[0220] In an embodiment, the layered network (1200) may be configured according to any of the protocol rules or structural features described in relation to FIGS. 3 through 6 and / or 7. Nodes (1201, 1202, 1203) are configured to form connections with one another at the overlay network level, where the layered network (1200) is an overlay network overlaid on a basic infrastructure network such as the Internet. That is, the nodes (1201, 1202, 1203) of the layered 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 layered network.

[0221] For example, in an embodiment, each intermediate layer node (1202) is connected to at least one core node (1201) (blockchain network node (104)) of the core network. The core network includes at least a portion of the blockchain network (106). In an embodiment, the core network itself may be a complete network (i.e., a complete graph). Each outer layer node (1203) may be connected to at least one of the intermediate layer nodes within at least one intermediate layer. In an embodiment, each outer layer node (1203) also has at least one connection to at least one core node (1201) (i.e., the blockchain network). In some of these embodiments, each of one or more outer layer nodes (1203) is connected to more than one core node, but not all of the core nodes (1201). In an embodiment, the layered network (1200) may be an incomplete network in total, that is, not all of each node (1201, 1202, 1203) are connected to all of each other node at the overlay network level. In an embodiment, each node within a given layer may be connected to at least one other node within the same layer. For example, each node (1202) within an intermediate layer may be connected to one or more other nodes within the same intermediate layer, and / or each node (1203) within an outer layer may be connected to one or more other nodes within the same outer layer. In an embodiment, a connection may also be formed between different intermediate layer nodes (1202) within different intermediate layers and / or different outer layer nodes (1203) within different outer layers.

[0222] A connection between two nodes (1201 / 1202 / 1203) of a layered network (1200) means that these nodes can communicate directly, and in this context, this means that there is no need to perform hops through other nodes (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., the level of the overlay network protocol of the layered network).

[0223] Although only two client nodes (1203C) and two database nodes (1202DB) are shown in FIG. 12 for the simplicity of the example, it will be recognized that there may be more nodes. In the embodiment, the client nodes (1203C) and the database nodes (1202DB) may be part of the same community.

[0224] Client nodes (1203C) are clients in that they are clients of the database service. In an embodiment, client software running on one or more of the client nodes (1203C) may be further configured to operate its nodes (1203C) as clients of one or more additional services provided by one or more second-tier nodes (1202), such as an alignment proof service or a smart contract service. And / or, it may be configured to operate its nodes (1203C) as clients 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), for example. 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 exclude the possibility that these nodes themselves may also be servers of one or more additional services for one or more additional entities (not shown). For example, the client node (1203C) may include computer equipment of a company that provides online services to customers via the web.

[0225] In an embodiment, the layered network (1200) of FIG. 12 may be the layered network (300) of FIG. 3 or 4, in which case the outer layer node (1203) of FIG. 12 is the third layer node (303) of FIG. 3 or 4, the middle layer node (1202) of FIG. 12 is the second layer node (302) of FIG. 3 or 4, and the core node (1201) of FIG. 12 is the core node (401) of FIG. 3 or 4.

[0226] In some embodiments, the layered network (1200) of FIG. 12 may be the layered network (700) of FIG. 7, in which case the outer layer node of FIG. 12 is the outer layer node of FIG. 7, the middle layer node (1202) of FIG. 12 is the middle layer node (702) of FIG. 7, and the core node (1201) of FIG. 12 is the core node (701) of FIG. 7. In such embodiments, the proof service of the proof node (702A) may be integrated into some or all of the same middle layer nodes (702 / 1202) as the database node (1202DB), and / or the proof node (702A) may include separate middle layer nodes (702 / 1202) in the same and / or different middle layers of the same and / or different communities.

[0227] In operation, the database node (1202DB) receives an update request from one or more of the 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 through one of the layered network connections between the requesting client node (1203C) and the receiving database node (1202DB), between the relevant outer layer and the intermediate layer (e.g., Layer 2 and Layer 3). Alternatively, the update request may be received indirectly through one or more hops by being forwarded from another database node (1202DB) that was the direct recipient of the request, for example, from the sending client node (1203C) (see below). In the indirect case, the message may be propagated through connections between intermediate layer nodes (1202) (within the same and / or different intermediate layers) within the layered network (1202).

[0228] Each update request is a request to update a specific individual target entry within the database. For each of these requests, the receiving database node (1202DB) determines whether the request is destined for the receiving database node (1202DB) itself or for another database node (1202DB), that is, the individual target entry to be modified by the request is found in a part of the database stored locally on the receiving database node (1202DB) or another database node (1202DB). It is noted that if data entries are replicated across multiple database nodes (1202DB), the target entry may be found on both the receiving database node (1202DB) and one or more other nodes. It is also possible for the request to be destined for multiple database nodes other than the receiving database node.

[0229] Each update request contains data content, that is, the actual update to be performed. This can be expressed in absolute terms, that is, replacement data to replace part or all of the existing content of the target entry. Alternatively, the content of the update can be expressed as a delta (difference) to the request, that is, a modification to be applied to the individual target entry. The data content may include the full version of the ultimate user data that the user wishes to store, or instead, it may take the form of a compressed version or fingerprint of the user data that is not explicitly the full version itself. In either case, if the update is destined for the receiving database node (1202DB), the receiving database node applies the requested update locally to a copy of the relevant target entry stored locally at the receiving node (1202DB), or if the update is destined for one or more other database nodes among the database nodes (1202DB), the receiving database node (1202DB) forwards the update request to the relevant database node to be applied to a copy of the target entry stored at the relevant database node(s) (1202DB). It is noted again that when an entry is replicated across database nodes (1202DB), both can be performed. If necessary, updates can be propagated between database nodes (1202DB) and / or between different intermediate layers through communication within the intermediate layer.

[0230] It is also noted that the client node (1203C) can send an update request to each of the multiple receiving database nodes (1202DB), and in this case, each receiving database node (1202DB) can behave as described above.

[0231] In addition to being recorded in one or more database nodes (1202DB), according to the present disclosure, a record of each update request is also recorded in the blockchain (150) via one of the connections to the core (1201). This helps to build consensus among the nodes of the network, for example, to improve consistency between database nodes (1202DB).

[0232] The indication of an update is transmitted from the transaction (152) to one of the core nodes (1201), mined into a block (151), and thus recorded on the blockchain. This can be transmitted by a 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 the update. The check may be performed directly through a connection within the layered network (1200) between one or more of the database nodes (1202DB) and the core nodes (1201), or alternatively, vicariously through one or more hops.

[0233] In an alternative scenario, a transaction containing an indication of 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 even a third-party node) may check that the expected update has been recorded on the blockchain (or accepted by the miner's mempool (154)). This check may be performed directly through a connection within the layered network (1200) between one or more of the client nodes (1203C) and the core node (1201), or alternatively, through one or more hops as a proxy.

[0234] In another alternative, a transaction containing indication of an update may be transmitted to the core (1201) by a third-party service within one of the intermediate layers, such as a proof service (702A) or a similar one. This may be transmitted directly or by proxy. One or more of the request client node (1203C) and / or database node (1202DB) may check that the expected update has been written to the chain (or accepted by the mempool (154)). Again, this check may be performed directly (single hop) or by proxy (more than one hop).

[0235] The “mark” of an update to be recorded on the chain may or may not explicitly (absolutely or delta-wise) include the actual content of the update itself. Alternatively, or additionally, it may include a transformation of the update, such as a hash of the preimage, where the preimage contains the update. This may be referred to as a “hash commit.” If only a hash commit, etc., is recorded, this makes it possible to check that a known update has been recorded on the chain (or accepted into a miner’s mempool (154)), but a third party without knowledge of the update will not be able to see it. The hash may also be smaller to store the content itself.

[0236] In one advantageous arrangement, when a database node (1202DB) is temporarily disconnected from the layered network (1200), the database node (1202DB) can check for any relevant updates using records stored in the blockchain (150) and perform them when it returns online. Again, this check can be performed directly through a connection within the layered network (1200) between one or more of the database node (1202DB) and the core node (1201), or indirectly through more than one hop.

[0237] 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 is disconnected, the node may omit updates in the form of deletions. If all other nodes have completely expunged the deleted entry by the time the disconnected node reconnects, that node may re-propagate the deleted data as if the deleted entry were a new entry to be added to the database. However, this can be avoided by maintaining a deletion record stored in the chain. In another advantageous scenario, records on the chain can be used to provide a "hinted handoff." A hinted handoff is a term in the art. As used herein, "handoff" means providing an update to a database node when it reconnects after a period of disconnection, and the hint includes the ID of the database node or nodes to which the update is to be directed (i.e., the relevant entry or part of the database containing the entries). This may also include other fields. It is assumed that a database node (1202DB) receives an update request that needs to be propagated to another database node (1202DB), but that the other database node (1202DB) is currently disconnected from the layered network (1200). Conventionally, the receiving database node (1202DB) may need to store an update containing a hint until the other database node (1202DB) comes back online. However, by writing the hint on-chain instead, the receiving database node (1202DB) does not need to do this.

[0238] Another example of an indication that may be stored in the chain, either alternatively or additionally, is order information. In some scenarios, multiple update requests requesting the same target entry to be updated may be received at the same database node (1202DB) storing the entry. To accommodate this, the 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 time of reception 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 time of reception at the database node that received the request directly from the original sending client (1203C). Alternatively, the specified order may be asserted from one or more update requests from the client, or from messages from other intermediate layer nodes (1202), such as other database nodes (1202DB) or the attestation service node (702A), or from the core (1201). For example, the order can be asserted in the form of a sorted list of multiple updates or an index of the order mapped to each update request.

[0239] In an embodiment, the specified order may be recorded on the blockchain (150) by, for example, the previously discussed proof service (702A). In such an embodiment, a requesting client node (1203C) may obtain the order from the proof service (702A) and submit it to the database node (1202DB). In this case, in addition to recording the order on the blockchain (150), the order proof service (702) also returns a message containing the specified order to the requesting client node (1203C) (which is also the client (703C) of the proof service (702A). When the client (1203C) requests an update for the database node (1202DB), the client also submits the order obtained from the proof service (702A) to the database node (1202DB) in at least one of the update requests. The database node (1202DB) checks the order recorded in the blockchain (or miner's mempool (154)) and then applies updates in a specified order, conditional on whether the order submitted by the client (1203C) matches the order recorded in the chain (150). The check can be performed directly through the connection between the database node (1202DB) and the core (1201), or alternatively through one or more hops.

[0240] Alternatively, the database node (1202DB) performing the update may read the order directly from the blockchain (150) and apply the order read from the blockchain (150) (or the miner's mempool (154)).

[0241] In another variation, the proof 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 timestamps) and recording it on the blockchain (150). The database node (1202DB) responsible for the order may propagate the specified order to other database nodes (1202DB) around the connection between nodes within the intermediate layer(s). The other database nodes (1202DB) may check the order recorded on the blockchain, or alternatively, read the order directly from the blockchain (150) (or from the miner's mempool (154)). This may be done directly through the connection between the database node (1202DB) and the core (1202), or alternatively through one or more hops.

[0242] Sequence information is particularly (but not exclusively) useful in scenarios where different update requests experience different delays when propagated across the intermediate layer(s) of a layered network (1200). For example, consider a scenario where a first update request is issued by an individual client node (1203C) before 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. This may occur, for example, because the first update request must pass through a firewall that the second update request does not pass through, and / or because the first update request is transmitted from a geographically more distant location. The use of sequence information according to an embodiment of the present invention may be used to handle such situations to ensure that updates are applied in the order in which they were issued, or in the order in which they were first received by the intermediate database node (1202DB) of the update originally submitted.

[0243] However, it should be noted that this is not mandatory. More generally, as long as consensus is reached on some deterministic order, that order does not necessarily have to be the order of publication or the order of first receipt. As long as some deterministic order is agreed upon, any given entry in a 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).

[0244] To explain some of the principles other than those disclosed, a specific implementation will now be described as an example. As an example, references will be made to a database node implemented at Layer 2 and a client (user) node within Layer 3, but this can be generalized to any intermediate and outer layers, respectively.

[0245] One reason for using a layered network is that while Layer 2 nodes should ideally store consistent data, not all nodes may be directly connected to one another. Data consistency relates to the order in which data and commands are transmitted and received, and consequently, how data is transformed using the data store. For example, if there are two requests to perform non-commutative operations on data elements—such as matrix multiplication from the left—the order matters. In another example, one request might be to delete a file, and the other to read a file. Again, the order in which these requests are received is important. To prevent disputes, it would be desirable to define the order of data insertion. This can be achieved by the blockchain acting as a central coordinator.

[0246] Incentives for transaction and data propagation may be provided by service level agreements. Database nodes will, for example, propagate transactions to the entire community to ensure the database is consistent, thereby propagating data and transactions throughout Layer 2. This may be a requirement to comply with their service level agreements. Users of the data may propagate it throughout Layer 3 and include Merkle proofs and transactions as proof of reliability and immutability.

[0247] Digital certificates can be issued to Layer 2 nodes. Digital certificates can also be provided to users of Layer 3 nodes. There may be an entire Public Key Infrastructure (PKI) extending down the layers, which can exist on the blockchain using UTXOs for the PKI concept.

[0248] Through comparison, a reference is made to a distributed database implemented in a non-layered network without a blockchain or the core of a blockchain network node. An example of a database for this comparison is the existing Cassandra database.

[0249] In conventional database theory, the CAP theorem (or Brewer's theorem) states that it is possible to achieve only two of the three major desirable properties of a database system.

[0250] ● Consistency ― Data read from the database always corresponds to the most recent record;

[0251] ● Availability ― Data is always available to be read from the database upon request; and

[0252] ● Partition tolerance ― The system continues to operate even with events from network partitions.

[0253] The method disclosed at present can be used to solve this trilemma.

[0254] Cassandra Database Management System is a high-availability, partition-allowing database architecture that satisfies two of the three aspects of the CAP theorem but sacrifices data consistency.

[0255] The basic architecture of a Cassandra database system is a set of distributed 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' nodes and 'master' nodes as in other distributed systems. As a result, the Cassandra nodes within the cluster form a complete graph, where every node can identify and communicate with all other nodes in the network. This architecture is illustrated in FIG. 13(a). This illustrates a Cassandra node cluster (1300) having a Cassandra network connection (1399) between each pair of Cassandra nodes (1301).

[0256] Data stored in the database is partitioned among nodes and will generally be replicated by multiple nodes to allow for resistance and high availability to the network of nodes, as illustrated in FIG. 13(b). This illustrates three exemplary data partitions: data partition 1 (1301), data partition 2 (1352), and data partition 3 (1353).

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

[0258] The consistency of data stored between nodes in a Cassandra cluster is, in substance, the probability that the data returned by a node in response to a read request is actually the most recently written version of the requested data to the Cassandra cluster. The consistency level of a Cassandra cluster can be set for read and write operations and configured to meet the requirements of specific use cases.

[0259] The present disclosure introduces a new method for improving the process used to achieve higher consistency in the Cassandra database—which typically involves sacrificing consistency for performance by design.

[0260] Data Centers and Clusters: The Cassandra architecture uses two definitions related to node multiplicity.

[0261] ● Data Center ― A set of related nodes that can be a physical or virtual set. A single data center can be used to maintain a complete copy of a database and can be housed in a single geographic location.

[0262] ● Cluster ― A cluster is a collection of data centers associated with a Cassandra database. A cluster can span multiple physical locations.

[0263] It will be later found that data centers and clusters can be replicated using a network structure of a layered network having the core of the blockchain network nodes.

[0264] Record and Read Path: In a Cassandra database system, there are two ways for nodes to communicate, generally referred to as inter-node communication. These are as follows:

[0265] ● Direct Communication — In general, it is possible for each node within a Cassandra cluster to communicate with each other node. This is the basis for considering a Cassandra cluster as a complete graph. Messages transmitted directly between any pair of nodes in this way relate to write requests and read requests.

[0266] ● Gossip Protocol ― A peer-to-peer communication protocol used by Cassandra nodes to exchange status messages. Messages are gossipped once per second between a node and up to three other nodes within the cluster. This is used to communicate node status and thus allows for the detection of failures in compromised or unreachable nodes.

[0267] When a client uses a Cassandra cluster to read or write data, it can choose to communicate with any node because any node in the cluster is treated indiscriminately. The node selected by the client becomes the coordinator node for performing the specific read or write request made by the client.

[0268] This involves the coordinator identifying which node within the cluster needs to write / read and, accordingly, fetching data from that node or writing data to it.

[0269] FIG. 14 illustrates different communication paths of a Cassandra cluster graph. Nodes communicate status messages via gossip (dotted line, 1402) and write / read requests via direct communication (bold solid line, 1401). FIG. 14 illustrates a client (1403) sending a read or write request (1404) to a coordinator node (1301c) (solid black) and sending a gossip message from the coordinator (1301c) to multiple replica nodes (1301r) (cross-hatching).

[0270] Data Logging & Recording:At a high level, the hardware components of the Cassandra Node 1301 include the following.

[0271] ● disk:

[0272] ○ Commit Log ― An append-only log of all mutations performed on a Cassandra node.

[0273] ○ SSTable ― An immutable data file used to maintain data on the disk of a Cassandra node.

[0274] ● Memory:

[0275] ○ Memtable ― An in-memory structure where a Cassandra node buffers data from write requests.

[0276] These components of the Cassandra node interact during a write path executed when the node receives a write request from a coordinator node, as illustrated in FIG. 15. The Cassandra node (1301) includes a disk (1501) containing a commit log (1503) and an SSTable (1504), and a memory (1502) containing a Memtable (1505).

[0277] The process of FIG. 15, which details the record request serviced by the node (1301), is as follows.

[0278] (S1) Record the record request (variant) in the commit log (1503).

[0279] (S2) Store the record data blob and index in memory (1502).

[0280] (S3) Flushing data and index from memory to disk (1501).

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

[0282] As an AP system, the Cassandra database relies on a final consistency model. This means that after a mutation occurs and a certain period of time has passed, the database will reflect the most recent mutation. The assumption for achieving final consistency is that the sequence of operations for each mutation performed on the nodes of the cluster is recorded and maintained. This is accomplished using an on-disk commit log to ensure that mutations on data stored in SSTables are performed in the correct order.

[0283] The present disclosure introduces a method for improving a process that can improve the mechanism for reaching eventual consistency using a layered network having a blockchain-node core. Examples will be discussed in more detail later.

[0284] Deletion of data: Deleting data from Cassandra database nodes uses the following techniques.

[0285] ● Upsert ― Cassandra Database treats deletion as an insertion type ('upsertion') where a new version of data is inserted but has a more recent timestamp.

[0286] ● Tombstone — In the case of deletion, the newly recorded record is called a tombstone, which is simply a deletion marker for the corresponding data. Tombstone markers have a built-in expiration time, after which the data is deleted by compaction.

[0287] ● Compression ― The compression process is a mechanism for deleting data marked as tombstones. This involves taking all existing versions of the corresponding rows of data but deleting all versions that were most recently timestamped.

[0288] ● TTL (Time-to-Live) ― A marker that can be added to data as an upcert, which indicates the time when a data row is marked as a tombstone and subsequently deleted.

[0289] There is a known issue unique to Cassandra's distributed replication model known as zombie records. If a node becomes unreachable during the deletion of data rows (i.e., tombstone and compression), when that node rejoins the cluster, it will attempt to treat the records as new records and forward them to other replica nodes. This is known as a zombie record because other replica nodes that were online while the records were being deleted have already deleted the records.

[0290] The embodiments described herein provide a method for mitigating the possibility of zombie records in a distributed database system. Examples will be discussed in more detail later.

[0291] Record Recovery: Recovery during the record path (hint handoff) If one (or more) of the replica nodes on which data recording is to be performed is unreachable, the coordinator node for the recording request may store a local copy of the missing recording data as a hint handoff. A hint handoff includes the following:

[0292] ● Node ID of the unreachable node;

[0293] ● Hint ID serving as a timestamp for the data;

[0294] ● Message ID identifying the Cassandra version; and

[0295] ● Data blob of data to be recorded.

[0296] When an unreachable node (identified by a node ID) comes back online, the coordinator is responsible for replaying hints for that node and forwarding record requests to the node effectively after the fact. This means that, in terms of both disk space and processing, the burden of updating the unreachable node must necessarily fall on the coordinator when the unreachable node rejoins the network.

[0297] The embodiments disclosed herein use a layered network having blockchain node cores to improve this repair process by reducing the burden on the coordinator. Examples will be discussed in more detail later.

[0298] Integration of Distributed Databases into Layered Networks: The present disclosure provides a modification to a Cassandra-type database system, etc., such that a distributed database becomes part of a layered network (1200) having a cluster of blockchain network (1201 / 104) nodes in its core. The structure comprises at least the following layers.

[0299] ● Blockchain core layer (i=1) ― Preferably the innermost layer of a layered network that exclusively includes blockchain network peers (104) forming a complete graph.

[0300] ● Database Node Layer (i=2) ― A layer containing nodes of a distributed database cluster that does not form a complete graph (e.g., this could be a database cluster of an OTT (over-the-top) content provider).

[0301] ● User / Client Layer (i=3) ― A layer comprising users of a system or application backed by a distributed database (e.g., users of an OTT service).

[0302] For convenience, this type of network may be referred to herein as a "blockchain layered network (BLN)".

[0303] FIG. 16 illustrates a method of forming a BLN by integrating other ordinary clusters by removing intra-shell connections (breaking the completeness of the intra-shell graph) and introducing connections from database nodes to blockchain core ancestor nodes.

[0304] The diagram illustrates this transformation for two distinct clusters of different sizes and, for the sake of simplicity, does not depict the external user layer.

[0305] Figure 16 illustrates 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 hierarchy (i>1) coordinated by the blockchain network central core (i=1) due to connections from database nodes to a set of their BLN core ancestors.

[0306] An example of a complete BLN including all three layers of the network is shown in FIG. 17. The term BLNiDD (BLN-implemented distributed database) may be used herein to generally refer to a BLN in which a cluster of distributed database nodes constitutes one of the intermediate layers around the core.

[0307] In a specific embodiment, the following prescription regarding the behavior of a Cassandra node within the i=2 layer of the BLN may be given.

[0308] ● Database nodes can use the same gossip protocol, etc., for status messages.

[0309] ● Database nodes can also propagate transaction messages among themselves using the same gossip protocol, etc.

[0310] ● The database node can use direct communication for write and read requests for pairs of directly connected nodes at i=2.

[0311] BLNiDD's Community: The existing definitions of data centers and clusters in the Cassandra architecture can be applied to BLNiDD. A data center is simply a set of database nodes belonging to a single community in BLNiDD, whereas a cluster itself is an entire layer (i=2) of database nodes from all communities within BLNiDD.

[0312] Public Key Infrastructure: It may be desirable to ensure that communication between a node within a database node cluster (i=2) and a user (also a node within the BLN graph, i=3) is trusted to improve reliability. This can be achieved by implementing a network-wide Public Key Infrastructure (PKI) for the BLN.

[0313] A PKI implementation for a BLN including a database cluster and its users may include the following.

[0314] ● User PKI(i=3):

[0315] ○ User public keys for n3 users of the database that can be assigned by the database administrator (i.e., DBA) assignment of.

[0316] ○ Authentication of the user's public key by the database administrator as a trusted Certificate Authority (CA) for the database.

[0317] ● Cassandra Node PKI(i=2):

[0318] ○ Database node public key for n2 nodes forming a database node cluster that can also be issued by a DBA assignment of.

[0319] ○ Authentication of database node public keys by the database administrator as a trusted CA for the database.

[0320] ● Bitcoin Core PKI(i=1):

[0321] BLN for distributed data storage and retrieval systems can leverage existing (pseudo)PKI of blockchain core networks such as the MinerID system.

[0322] A blockchain core network node to which both database cluster nodes and database users are connected may be a public entity that can be identified and registered as a business / service provider.

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

[0324] FIG. 18 illustrates an example of a distributed database with a BLN implementation having a PKI implemented at least at layer i=2,3.

[0325] Exemplary method: Blockchain can be used to enable a more robust, auditable, and verifiable mechanism for achieving eventual consistency compared to databases such as Cassandra. This can be accomplished by integrating a database cluster into a BLN, as described above. For any of the following methods, the use case may also be composed of the following.

[0326] ● PKI for the BLN layer, and / or

[0327] ● Method for sorting timestamped events.

[0328] In the following methods, a number of methods using blockchain, and more specifically BLN built on its core network, are outlined to improve distributed database systems by solving a number of individual but related problems.

[0329] Method 1 ― Using BLN to improve eventual consistency and / or mitigate zombies Cassandra Database is an AP system, which means that it sacrifices data consistency according to the CAP theorem and instead uses a final consistency mechanism. The order of operations is critical to this, and failures can result in zombie records propagating through the database.

[0330] In a multi-node cluster, different database nodes can store replicas of the same data. When a node receives a delete request for data stored locally, the node tombstones the specified database entry and attempts to forward the tombstone to other nodes containing replicas of the same record. However, if one replica node is unreachable at that time, the replica node will not immediately receive the tombstone, and thus the replica continues to contain a version of the record from before the delete operation. If the "tombstoned" record was already deleted from the rest of the cluster before the node was recovered, the corresponding entry on the now-recovered node can be treated as new data when it comes back online and thus propagated to the rest of the cluster as a new addition. This is referred to as a zombie record.

[0331] To address these issues, BLNiDD is used instead of a simple Cassandra system, allowing the blockchain core network to be leveraged as a central coordinator to determine the order of operations leading to eventual consistency. The order becomes immutable and publicly verifiable. Database nodes within layer i=2 propagate all state transformations via the hash of data blobs using gossip (or other such protocols) rather than direct communication.

[0332] In other words, the order of operations can be important, and it may be desirable to reach an exact final consistency state. To address this, the database cluster (incomplete graph) at layer i = 2 uses the blockchain core network at i = 1 to align events and ensure final consistency. The idea of ​​final consistency aligns well with the concept that a blockchain collapses into an immutable state after a number of blocks (e.g., 6) (i.e., finally).

[0333] This can also be applied to the re-onboarding process for nodes that are temporarily turned off from the network. Other nodes can communicate state changes using gossip, etc., and provide a Merkle proof to prove to the node that the state change actually occurred or was requested. The database node can be of the SPV type here. In the case of re-onboarding, this demonstrates the powerful properties of BLN.

[0334] The method can operate as follows.

[0335] 1. The user / client makes a read / write request to the database node. The user / client simultaneously creates and broadcasts the 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.

[0336] 2. The Coordinator behaves as usual by identifying the relevant node to which the read / write request belongs. Depending on the request type, the Coordinator performs the following:

[0337] a. Read request: There is no requested state change for any node, so the coordinator operator forwards the request to the relevant node via gossip or direct communication (if directly connected).

[0338] b. Record Request: A state transformation is required for the record, so the coordinator must propagate both the request and the data to the relevant replica nodes (via gossip or direct connection).

[0339] c. In any case, the coordinator also propagates the TxID of the record request to the relevant nodes as proof of the order of operations.

[0340] 3. When receiving a request and data from a peer, the replica node verifies from the core that the received request matches the request details of the request transaction and returns an acknowledgment to the coordinator. In the embodiment, the replica node may apply updates only to its own local records based on this check.

[0341] 4. The mediator returns the following.

[0342] a. Success or failure message for user / client.

[0343] b. Optional: Success or failure transaction for the blockchain core layer for mining.

[0344] Details of an exemplary read / write transaction are illustrated in Fig. 19 below. The <request data> packet may include a unique request ID, the ID of the coordinator node for the request, and a key for the row of the requested data.

[0345] A new read / write path for this method is illustrated in Fig. 20. The main differences from the standard Cassandra read / write path are as follows.

[0346] ● Users / clients simultaneously submit their read / write requests to the database cluster and the blockchain core layer, and

[0347] Nodes of a database cluster may propagate requests and data using either gossip (or something similar, i.e., indirectly) or direct communication, depending on the distance between the coordinator and the relevant replica node for the request.

[0348] One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct sequence of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records because the sequence of operations (including deletions) missed by the node while offline is stored on the blockchain and can be recovered from it.

[0349] Method 2 ― Reduces the burden on the coordinator node during the hint handoff. Conventionally, in distributed databases such as Cassandra, if a replica node cannot be reached during the record path, the hint handoff is written to the coordinator node. This places an additional burden on the coordinator to assist the replica node in rejoining the network by storing the hint locally and forwarding it to the rejoin node. The hint handoff can also time out, potentially breaking data eventual consistency.

[0350] To resolve this using BLNiDD, hint handoffs can be recorded on the blockchain by propagating the hint handoffs to the blockchain core layer for an immutable order. When a node rejoins the network, the node can query the blockchain core layer for hints related to itself (e.g., using a node ID and / or PKI). Optionally, at least one replica node has recorded data for the record request, and the rejoining node can use this to obtain the record data blob (instead of also storing the blob on the blockchain).

[0351] This method can operate as follows.

[0352] 1. The user / client requests a record from the node (coordinator) using a replication argument, for example, a replication argument of 3.

[0353] a. Optional: The user / client also sends a record of the request to the Bitcoin Core layer.

[0354] 2. The coordinator identifies three nodes to record data and forwards the record request.

[0355] 3. Two of the nodes record data and respond positively to requests, but the third node is unreachable.

[0356] 4. The coordinator returns a positive response to the user / client, records the hint handoff transaction (see FIG. 21), and broadcasts it to the blockchain core layer for mining. The hint handoff includes the following:

[0357] a. Node ID of the unreachable node, ;

[0358] b. Hint ID for timestamping data;

[0359] c. Message ID;

[0360] d. Node IDs of the two replicas where data was successfully written, ;

[0361] e. Hash of the data blob to be recorded.

[0362] f. Optional: The data itself

[0363] 5. Unreachable nodes rejoin the network and query their connection to the blockchain core network for an incoming hint handoff. When acquiring a hint handoff, the node will perform the following:

[0364] a. Node and / or Obtain a data blob from;

[0365] i. Optional: If the blob is included in the hint handoff, simply acquire the blob.

[0366] b. Verify that the data blob is hashed in the hint handoff;

[0367] c. Assuming no other operations are missed (which is also identified by its own hint handoff), write the data blob to its local disk.

[0368] Figure 21 illustrates an example of a hint handoff transaction.

[0369] Method 3 ― Improving Security for Re-onboarded Database Nodes When a Cassandra node is corrupted or partitioned from the rest of the cluster, the Cassandra node must be re-onboarded later. This involves acquiring and implementing all local database variations requested for that node while it is unreachable.

[0370] Typically, a Cassandra cluster can be considered a trusted environment, whereby all nodes within the cluster trust each other to propagate and communicate these missing mutation requests. However, it may be desirable to improve the rejoining process for database nodes so that a database node does not require trust in other nodes to send the correct missing mutation requests to other nodes.

[0371] This can be advantageous in preventing many nodes of a distributed database from being compromised by sophisticated attackers attempting to propagate malicious mutations from a compromised node.

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

[0373] The trustless rejoin protocol can be as follows.

[0374] 1. Node It is partitioned from the database cluster for a significant period of time. During this time:

[0375] a. Multiple record requests (including upcerts) are made in relation to data replicated by.

[0376] b. Node It is not certain whether it has been partitioned due to a malicious attack, and assuming that other nodes may have been similarly compromised and are under the control of the attacker, this means that the node must rejoin the network.

[0377] 2. When a node rejoins, the rejoining node obtains missing modification requests from signed transactions obtained from the blockchain core network.

[0378] This is similar to Method 1, but uses a blockchain core network to time-order events that allow direct querying to re-onboard recently compromised nodes into the database cluster without trusting other database nodes to provide accurate updates.

[0379] In some embodiments, Merkle proof may be used for re-onboarding.

[0380] The advantage of the above is that by having replication nodes repeat the correct sequence of operations, it reduces the burden on the coordinator to ensure that the same eventual consistency is reached. This is offloaded to the blockchain network.

[0381] Method 4 ― Replicate or replace the commit logs of all nodes with the transaction set Their requirement is that all nodes in the Cassandra cluster must maintain a local copy of the commit log for all database variations requested to be performed. This places a hardware burden on the Cassandra nodes that can limit their performance.

[0382] In the embodiments disclosed herein, the blockchain may be used as an immutable timestamp ledger to offload the burden of storing commit logs from the database node. Since the commit logs can be retrieved from the blockchain when needed, the commit logs only need to be stored ephemerally on the database node itself.

[0383] This can reduce the burden on all nodes within a database cluster that maintain their own local commit logs by recording all nodes on the blockchain instead.

[0384] In an embodiment, the previously discussed data timestamping method can be used to store the entire commit log on the blockchain as a set of linked transactions, and both the data and the sequence of operations of the commit log are immutably recorded on the blockchain by the actions of the blockchain network core layer nodes.

[0385] As previously detailed, the Cassandra commit log is a dedicated log of all modifications made to a single Cassandra node. The blockchain log may be similar in that it is a dedicated event log of transactions committed to the blockchain.

[0386] conclusion

[0387] It will be recognized that the above embodiments are described merely as examples. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided.

[0388] Statement 1: A method for operating a distributed database implemented in a layered network, wherein the layered network comprises a core layer comprising one or more core nodes, one or more intermediate layers each comprising one or more intermediate layer nodes, and one or more outer layers each comprising one or more outer layer nodes, wherein each core node is a node of a blockchain network, at least some of the intermediate layer nodes are database nodes of a distributed database, at least some of the outer layer nodes are client nodes of a distributed database, and each database node stores at least a portion of the distributed database, and the method comprises the step of: receiving one or more update requests from one or more of the client nodes at a first database node among the database nodes — each of the one or more update requests is a request to update an individual target entry in the distributed database — ; For each of the received update requests, the method includes the step of determining whether an individual target entry is found in a portion of the database stored in the first database node, and if so, performing an update of the update request for the individual target entry within the portion of the database stored in the first database node, and if not, forwarding the request to another database node among the database nodes storing the portion of the database containing the individual target entry, and at least one transaction including an indication of one or more update requests is also recorded on the blockchain of the blockchain network.

[0389] It will be recognized that in this context, "first" is merely an arbitrary label for a specific database node and does not, in itself, necessarily imply any particular state associated with another database node.

[0390] Update requests may be received from the same client node or different client nodes, or some may be received from the same client node and some from different client nodes.

[0391] Statement 2: In the method of Statement 1, each client node is connected to at least one of the database nodes within a layered network, and the first database node receives at least one update request directly from the client node through one of the connections between the client node and the database node.

[0392] Statement 3: In the method of Statement 1 or 2, each database node is connected to another database node among at least one of the database nodes within a layered network, at least one of the update requests is received indirectly through at least one of the other database nodes, in addition to the first database node, through at least one of the connections between the database nodes, and / or individual target entries of at least one of the update requests are found in a part of the database stored in one of the other database nodes, and the forwarding step includes the step of forwarding to another database node through at least one of the connections between the database nodes.

[0393] Statement 4: In the method of any previous statement, the at least one transaction is formulated by at least one of the client nodes and transmitted to the core layer by at least one client node to be mined into the blockchain.

[0394] Statement 5: In the method of any previous statement, each client node is connected to at least one of the core nodes within a layered network, enabling the client node to check whether an update request has been recorded on the blockchain.

[0395] Statement 6: In the method of Statement 5, each client is connected to one or more of the core nodes within the layered network.

[0396] Statement 7: In the method of Statement 6, each client is connected to one or more, but not all, core nodes within the layered network.

[0397] Statement 8: In any of the methods of statements 5 to 7, the at least one transaction is transmitted directly to the core layer by at least one of the client nodes through at least one of the connections between the client node and the core node.

[0398] Alternatively, this can be transmitted indirectly through more than one hop.

[0399] Statement 9: In any of the methods of Statements 1 to 3, the at least one transaction is formulated by at least one other database node among the database nodes or an intermediate layer node other than the first database node, and is transmitted to the core layer by at least one other node to be mined into the blockchain.

[0400] For example, at least one transaction may be formulated and transmitted by one of the other database nodes acting as a coordinator, or by another type of intermediate layer node providing an attestation service.

[0401] Statement 10: In the method of any previous statement, the at least one transaction is formulated by at least one of the client nodes or another database node or other intermediate layer node other than the first database node and transmitted to the core layer; and the method further comprises the step of by the first database node: examining the blockchain to check that an indication of one or more update requests has been written to the blockchain, and / or examining one or more miner mempools to check that at least one transaction has been accepted.

[0402] Statement 11: In the method of Statement 10, the step of performing the update is conditional on the check.

[0403] Statement 12: In the method of Statement 10 or 11, the first database node is configured to directly perform the investigation through a connection between the first node and at least one of the core nodes within a layered network.

[0404] Statement 13: In any of the methods of Statements 1 to 3, the at least one transaction is formulated by the first database node and transmitted to the core layer by the first database node to be mined into the blockchain.

[0405] Statement 14: In the method of any previous statement, each database node is connected to at least one of the core nodes within a layered network.

[0406] Statement 15: In the method of Statement 14, each database node is connected to at least one, but not all, of the core nodes within the layered network.

[0407] Statement 16: In the method of Statement 14 or 15, at least one transaction is transmitted directly to the core layer by at least one of the database nodes through at least one of the connections between the database node and the core node.

[0408] Statement 17: In any previous statement method, the indication of one or more update requests included in at least one transaction includes the data content of one or more updates that are updates to be performed on individual data entries or the contents of the entries.

[0409] The content of the data update may take the form of a value or values ​​to replace the previous value or values ​​of individual target entries, and / or a delta to apply to the existing value or values ​​of individual target entries.

[0410] Statement 18: In any previous statement method, the indication of one or more update requests included in at least one transaction includes one or more hashes, each hash is a hash of a preimage containing the data content of at least one update among the updates.

[0411] Statement 19: In any previous statement method, the indication of one or more update requests included in at least one transaction includes the ID of a database node or nodes storing a part of the database where individual target entries are found.

[0412] Statement 20: In the method of any previous statement, the one or more update requests are multiple update requests, and at least some of the individual target entries of the update requests are identical entries in the database found in a part of the database stored in the first database node, and the step of performing the update includes the step of performing the update according to a specified order.

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

[0414] The order may be represented in any one or more of a number of different possible forms, e.g., 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) timestamps associated with each update request.

[0415] Statement 22: In the method of Statement 21, at least one transaction occurs from at least one of the client nodes or from another database node or from an intermediate layer node other than the first database node, and the method comprises: the first database node reading a specified order from a mempool of miners of a blockchain or blockchain network, and the step of performing the update comprises performing the update according to the order determined from the blockchain or mempool.

[0416] For example, the specified order can be determined by a sorting service implemented in one or more other intermediate nodes in addition to the first database node and recorded on the chain.

[0417] Statement 23: In the method of Statement 20 or Statement 21, the order is determined by at least one of the following: the client node submitting to the sorting service, receiving back the order designation from the sorting service, and including the specified order in at least one of the update requests.

[0418] The sorting service can be implemented on one or more intermediate nodes in addition to the first database node.

[0419] Statement 24: In the method of Statement 20 or 21, the specified order is determined by a sorting service implemented in the first database node.

[0420] Statement 25: In the method of any previous statement, one or more entries of the database are replicated across a portion of the database stored on multiple database nodes.

[0421] Statement 26: In the method of Statement 25, a target entry of at least one update request is found in both a part of the database stored in the first database node and another database node among the database nodes, and the method comprises both the step of performing an update in the first database node and the step of forwarding the request to the other database node.

[0422] Statement 27: In the method of any previous statement, a target entry of at least one update request is found in a part of a database stored in a database node other than the first database node, and the forwarding step comprises: determining whether the other database node is currently reachable through a layered network, and forwarding the update request to the other database node on the condition that the other database node is determined to be reachable according to the determination.

[0423] Statement 28: In the method of Statement 27, another database node is temporarily disconnected from the layered network, and the indication of at least one transaction enables the other database node to perform at least one update request update when the other database node is reconnected to the layered network.

[0424] Statement 29: In the method of any previous statement, for a certain period, the first database node is temporarily disconnected from the layered network, and the method further comprises, when the first database node is reconnected to the layered network: the step of the first node examining the blockchain, or the mempool of a miner of the blockchain network, to check for one or more additional transactions related to individual target entries within a portion of the database stored by the first database node while the first database node is disconnected, and the step of performing any such update.

[0425] A mark may include at least the ID of a database node or nodes responsible for storing a portion of the database containing the entry to be updated. The data content of the update may be stored in the mark stored in the transaction and retrieved from therefrom, or instead, the data content may be retrieved from another database node among the database nodes storing a replica of the entry. For example, the node storing the replica may be determined from the ID of at least one transaction.

[0426] Statement 30: In any of the methods of statements 10 to 12 or 27, the first node is configured to directly perform the investigation through a connection between the first node and at least one of the core nodes within a layered network.

[0427] Alternatively, this can be done through one more hop.

[0428] Statement 31: In any previous statement's method, the core layer is complete.

[0429] In other words, every core node within the core layer is connected to every other node within the core layer in the layered network.

[0430] Statement 32: In the method of any previous statement, the layered network is incomplete as a whole.

[0431] That is, every node of every layer is not connected to every different node of every different core layer within the layered network. In some of these embodiments, every node within a given layer is not necessarily connected to every different node of the same layer.

[0432] Statement 33: In any previous statement method, each client node and / or database node is authenticated by a certification authority.

[0433] Statement 34: Computer equipment comprises a memory comprising one or more memory units, a processing unit comprising one or more processing units, and a network interface comprising one or more network interface units, wherein the memory stores code arranged to be executed in the processing unit, and the code, when executed in the processing unit, receives an update request through the network interface, and is configured to operate the computer equipment as the first database node by performing the method of any previous statement.

[0434] Statement 35: A computer program implemented in a computer-readable storage device and configured to perform the method of any one of statements 1 through 33 when executed on one or more processors.

[0435] Statement 36: A method for using a distributed database implemented in a layered network, wherein the layered network comprises a core layer comprising one or more core nodes, one or more intermediate layers each comprising one or more intermediate layer nodes, and one or more outer layers each comprising one or more outer layer nodes, wherein each core node is a node of a blockchain network, at least some of the intermediate layer nodes are database nodes of a distributed database, at least some of the outer layer nodes are client nodes of a distributed database, and each database node stores at least some of the distributed database, and the method comprises the step of: at a first database node among the database nodes, transmitting one or more update requests to one or more of the database nodes ― each of the one or more update requests is a request to update an individual target entry in the distributed database ― ; and directly using a connection between a first client node and at least one of the core nodes in the core layer within a layered network: I) transmit at least one transaction to be recorded on the blockchain of the blockchain network — at least one transaction includes an indication of one or more update requests — and / or II) check that at least one transaction including an indication of one or more update requests has been recorded on the blockchain or at least accepted into the mempool of the miner of the blockchain network.

[0436] Statement 37: In the method of Statement 36, the first client node is configured to communicate with at least one core node, including transmitting the at least one transaction and / or performing the check using a communication protocol, wherein the message in the communication protocol takes the form of: a) a transaction transmitted from the client node to the core node; b) a query from the client node to the core node regarding 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 including 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 including a list of block headers.

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

[0438] In an example, the protocol may be an SPV protocol.

[0439] Statement 38: Computer equipment comprises: memory comprising one or more memory units; a processing unit comprising one or more processing units; and a network interface comprising one or more network interface units, wherein the memory stores code arranged to be executed on the processing unit, and the code comprises performing I and / or II through the network interface when executed on the processing unit, and is configured to operate the computer equipment as the first client node by performing the method of Statement 36 or 37.

[0440] Statement 39: A computer program is implemented on a computer-readable storage device and is configured to perform the method of Statement 36 or 37 when executed on one or more processors.

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

Claims

Claim 1 A method for operating a distributed database implemented in a layered network, wherein the layered network comprises a core layer including one or more core nodes, one or more intermediate layers each including one or more intermediate layer nodes, and one or more outer layers each including one or more outer layer nodes, wherein each of the core nodes is a node of a blockchain network, at least some of the intermediate layer nodes are database nodes of the distributed database, at least some of the outer layer nodes are client nodes of the distributed database, and each database node stores at least a portion of the distributed database, and the method comprises: at a first database node among the database nodes: receiving one or more update requests from one or more of the client nodes — each of the one or more update requests is a request to update an individual target entry within the distributed database —; A method for operating a distributed database, comprising the steps of: determining, for each of the received update requests, whether the individual target entry is found in the part of the database stored in the first database node; and if so, performing an update of the update request for the individual target entry within the part of the database stored in the first database node; and if not, forwarding the request to another database node among the database nodes storing the part of the database containing the individual target entry, wherein at least one transaction including an indication of the one or more update requests is also recorded on the blockchain of the blockchain network. Claim 2 A method for operating a distributed database according to claim 1, wherein each client node is connected to at least one of the database nodes within the layered network, and the first database node receives at least one of the update requests directly from the client node through one of the connections between the client node and the database node. Claim 3 A method for operating a distributed database according to claim 1 or 2, wherein each of the database nodes is connected to at least one other database node among the database nodes within the layered network, and at least one of the update requests is received indirectly through at least one other database node among the database nodes, in addition to the first database node, through at least one connection among the connections between the database nodes, and / or the individual target entry of at least one of the update requests is found in a part of the database stored in one of the other database nodes, and the forwarding step comprises the step of forwarding to the other database node through at least one connection among the connections between the database nodes. Claim 4 A method for operating a distributed database according to claim 1 or 2, wherein at least one transaction is formulated by at least one of the client nodes and transmitted to the core layer by at least one client node to be mined into the blockchain. Claim 5 A method for operating a distributed database according to claim 1, wherein each client node is connected to at least one of the core nodes within the layered network, enabling the client node to check whether an update request has been recorded in the blockchain. Claim 6 A method for operating a distributed database in which, in claim 5, each client is connected to a plurality of core nodes among the core nodes within the layered network. Claim 7 A method for operating a distributed database according to claim 6, wherein each client is connected to multiple core nodes, but not all of the core nodes, within the layered network. Claim 8 A method for operating a distributed database according to claim 5 or 6, wherein the at least one transaction is transmitted directly to the core layer by at least one of the client nodes through at least one of the connections between the client node and the core node. Claim 9 A method for operating a distributed database according to claim 1 or 2, wherein the at least one transaction is formulated by at least one other database node among the database nodes or an intermediate layer node other than the first database node, and is transmitted to the core layer by the at least one other node to be mined into the blockchain. Claim 10 A method for operating a distributed database according to claim 1, wherein the at least one transaction is formulated by at least one of the client nodes or another database node among at least one of the database nodes or an intermediate layer node other than the first database node and transmitted to the core layer; and the method further comprises the step of by the first database node: examining the blockchain to check that the indication of the one or more update requests has been recorded in the blockchain, and / or examining the mempool of one or more miners to check that the at least one transaction has been accepted. Claim 11 In claim 10, the step of performing the update is a method of operating a distributed database based on the condition of the check. Claim 12 A method for operating a distributed database according to claim 10 or 11, wherein the first database node is configured to directly perform the investigation through a connection between the first database node and at least one of the core nodes within the layered network. Claim 13 A method for operating a distributed database according to claim 1 or 2, wherein at least one transaction is formulated by the first database node and transmitted to the core layer by the first database node to be mined into the blockchain. Claim 14 A method for operating a distributed database according to claim 1, wherein each of the database nodes is connected to at least one of the core nodes within the layered network. Claim 15 A method for operating a distributed database in claim 14, wherein each of the database nodes is connected to at least one, but not all, of the core nodes within the layered network. Claim 16 A method for operating a distributed database according to claim 14 or 15, wherein at least one transaction is transmitted directly to the core layer by at least one of the database nodes through at least one connection between the database node and the core node. Claim 17 A method for operating a distributed database according to claim 1 or 2, wherein the indication of the one or more update requests included in the at least one transaction comprises the data content of the one or more updates, which is an update to be performed on the individual data entry or the content of the entries. Claim 18 A method for operating a distributed database according to claim 1 or 2, wherein the representation of one or more update requests included in the at least one transaction includes one or more hashes, and each hash is a hash of a preimage containing the data content of at least one update among the updates. Claim 19 A method for operating a distributed database according to claim 1 or 2, wherein the indication of the one or more update requests included in the at least one transaction includes the ID of the database node or the ID of the nodes storing the part of the database where the individual target entry is found. Claim 20 A method for operating a distributed database according to claim 1, wherein the one or more update requests are multiple update requests, and at least some of the individual target entries of the update requests are identical entries within the database found in a part of the database stored in the first database node, and the step of performing the update includes the step of performing the update according to a specified order. Claim 21 A method for operating a distributed database according to claim 20, wherein the indication of one or more update requests included in at least one transaction includes a specified order of the plurality of update requests. Claim 22 In claim 21, the at least one transaction occurs from at least one of the client nodes or from another database node among at least one of the database nodes or from an intermediate layer node other than the first database node, and the method comprises: the first database node reading the specified order from the blockchain or the mempool of miners of the blockchain network, and the step of performing the update comprises performing the update according to the order determined from the blockchain or the mempool, a method for operating a distributed database. Claim 23 A method for operating a distributed database according to claim 20 or 21, wherein the order is determined by at least one of submitting to a sorting service by the client node, receiving back the designation of the order from the sorting service, and including the designated order in at least one of the update requests. Claim 24 A method for operating a distributed database according to claim 20 or 21, wherein the specified order is determined by a sorting service implemented in the first database node. Claim 25 A method for operating a distributed database according to claim 1, wherein one or more entries of the database are replicated across a portion of the database stored on a plurality of database nodes. Claim 26 A method for operating a distributed database according to claim 25, wherein a target entry of at least one update request is found in both a part of the database stored in the first database node and another database node among the database nodes, and the method comprises both the step of performing the update in the first database node and the step of forwarding the request to the other database node. Claim 27 A method for operating a distributed database according to claim 1, wherein, in addition to the first database node, a target entry of at least one update request is found in a part of the database stored in another database node among the database nodes, and the forwarding step comprises: determining whether the other database node is currently reachable through the layered network, and forwarding the update request to the other database node on the condition that the other database node is determined to be reachable according to the determination. Claim 28 A method for operating a distributed database according to claim 27, wherein the other database node is temporarily disconnected from the layered network, and the indication of at least one transaction enables the other database node to perform an update of at least one update request when the other database node is reconnected to the layered network. Claim 29 A method for operating a distributed database according to claim 1, wherein, for a certain period, the first database node is temporarily disconnected from the layered network, and the method further comprises, when the first database node is reconnected to the layered network: the first database node examining the blockchain or the mempool of a miner of the blockchain network to check for one or more additional transactions that record any update request received by one or more other database nodes, which is related to an individual target entry within the part of the database stored by the first database node while the first database node is disconnected, and performing any such update. Claim 30 A method for operating a distributed database according to claim 10 or 29, wherein the first database node is configured to directly perform the investigation through a connection between the first database node and at least one of the core nodes within the layered network. Claim 31 A method for operating a distributed database according to claim 1 or 2, wherein each core node in the core layer is connected to each other core node. Claim 32 A method for operating a distributed database according to claim 1 or 2, wherein at least one node in the layered network is not connected to at least one other node. Claim 33 A method for operating a distributed database according to claim 1 or 2, wherein each of the client node and / or database node is authenticated by a certification authority. Claim 34 A computer device configured to operate the computer device as a first database node by performing the method of claim 1 or 2, wherein the computer device comprises 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 arranged to be executed by the processing device, and the code includes receiving an update request through the network interface when executed by the processing device. Claim 35 A computer program implemented in a computer-readable storage device and configured to perform the method of claim 1 or 2 when executed on one or more processors. Claim 36 A method for using a distributed database implemented in a layered network, wherein the layered network comprises a core layer including one or more core nodes, one or more intermediate layers each including one or more intermediate layer nodes, and one or more outer layers each including one or more outer layer nodes, wherein each of the core nodes is a node of a blockchain network, at least some of the intermediate layer nodes are database nodes of the distributed database, at least some of the outer layer nodes are client nodes of the distributed database, and each database node stores at least a portion of the distributed database, and the method comprises: a step of transmitting one or more update requests to one or more of the database nodes from a first client node among the client nodes — each of the one or more update requests is a request to update an individual target entry within the distributed database —; A method for using a distributed database, comprising the step of: directly using a connection between the first client node and at least one core node among the core nodes in the core layer within the layered network: I) transmitting at least one transaction to be recorded on the blockchain of the blockchain network — the at least one transaction includes an indication of one or more update requests — and / or II) checking that the at least one transaction including the indication of one or more update requests has been recorded on the blockchain or at least accepted into the mempool of a miner of the blockchain network. Claim 37 A method using a distributed database according to claim 36, wherein the first client node is configured to communicate with at least one core node, including transmitting the at least one transaction and / or performing the check using a communication protocol, and wherein the message in the communication protocol takes the form of: a) a transaction transmitted from the client node to the core node; b) a query from the client node to the core node regarding whether the transaction has been accepted into a 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 including 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 including the list of block headers. Claim 38 Computer equipment configured to operate the computer equipment as a first client node by performing the method of claim 36 or 37, wherein the computer equipment comprises a memory including one or more memory units, a processing unit including one or more processing units, and a network interface including one or more network interface units, wherein the memory stores code arranged to be executed by the processing unit, and the code includes performing I) and II) through the network interface when executed by the processing unit. Claim 39 A computer program implemented on a computer-readable storage and configured to perform the method of claim 36 or 37 when executed on one or more processors.

Images