Hierarchical network

Abstract

A computer-implemented method for connecting to a hierarchical network. The hierarchical network includes a plurality of nodes arranged in an ordered set of layers. The ordered set of layers includes, in order, a core layer including a set of core nodes, a second layer including a set of second nodes, and one or more outer layers, each including a respective set of outer nodes. Each core node is connected to at least one other core node. The method is performed by a connecting node and includes connecting to the network according to a connection protocol. The connection protocol requires that each node must connect to at least one node in the preceding layer and that each outer node must also connect to at least one core node.

Description

Technical Field

[0001] The present disclosure relates to a method of connecting to a hierarchical network according to a connection protocol.

Background Art

[0002] A blockchain refers to a form of a distributed data structure, and a replicated copy of the blockchain is maintained at each of a plurality of nodes in a peer-to-peer (P2P) network. The blockchain includes a chain of data blocks, and each block includes one or more transactions. Each transaction may refer to a preceding transaction in a sequence that may span one or more blocks. A transaction may be submitted to the network to be included in a new block. A new block is created by a process known as "mining", which involves multiple mining nodes competing to each perform a "proof of work", i.e., solve a cryptographic puzzle based on a pool of pending transactions waiting to be included in the block.

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

[0004] A miner who successfully solves the proof-of-work puzzle and creates the latest block is typically rewarded with a new transaction called a "coinbase transaction" that generates a new amount of digital assets. Since mining a block requires a large amount of computational resources and a block containing an attempt at double-spending is likely to be rejected by other nodes, proof-of-work provides an incentive for miners not to exploit the system by including double-spending transactions in those blocks.

[0005] In an "output-based" model (sometimes called the 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 the amount of digital assets, which may also be called a UTXO ("unspent transaction output"). The output may further include a lock script that specifies the conditions for redeeming the output. Each input includes a pointer to such an output in a previous transaction and may further include an unlocking script for unlocking the lock script of the indicated output. Therefore, considering a pair of transactions, they are called the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of digital assets and includes a lock script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and includes an unlocking script for unlocking the output of the first transaction.

[0006] In such a model, when the second target transaction is sent to the P2P network, propagated, and recorded in the blockchain, one of the criteria for validity applied at each node is that the unlocking script satisfies all of the one or more conditions defined by the lock script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another valid transaction elsewhere. A node that discovers that the target transaction is invalid according to any of these conditions will neither propagate it nor include it for mining into the block recorded in the blockchain.

[0007] Conventionally, transactions in blockchain are used to communicate digital assets, i.e., some digital tokens. However, blockchain can also be utilized to overlay additional functions on top of the blockchain. For example, the blockchain protocol may enable the storage of additional user data in the output of a transaction. In the latest blockchains, the maximum data capacity storable within a single transaction has increased, making it possible to incorporate more complex data. For example, this can be used to store electronic documents on the blockchain or even audio or video data.

Summary of the Invention

[0008] The concept of the Mandala network was introduced by C. Sampaio Filho, A. Moreira, R. Andrade et al. in "Mandala Networks: ultra-small-world and highly sparse graphs." Sci Rep 5, 9082 (2015).

[0009] The Mandala network is a network constructed of layers (or shells or generations) where the first layer forms a complete graph and each node within the same layer has the same degree. Here, the first layer forms a complete graph in that each node within the first layer is connected to every other node within the first layer. The "degree" of a layer is a term representing the number of nodes in the same layer to which a given node is connected. For example, if a layer has a degree of 2, each node within that layer is connected to two other nodes in the same layer.

[0010] The type of the Mandala network is specified by the selection of three parameters (n1, b, λ). The parameter n1 represents the number of nodes in the first layer, the parameter b represents the number of nodes connected to each node in the i-th layer to form the (i + 1)-th layer, and λ is a scale factor that determines the degree of nodes in each shell. Nodes in the i-th layer are called the "ancestors" of the node(s) in the (i + 1)-th layer connected to that node. By construction, each node in each layer is directly connected to all of their ancestor nodes up to the first layer.

[0011] If g is the total number of layers in the Mandala network, the degree of nodes in layer i is k ig denoted and given by: k ig = bλ g-i +(i - 1)

[0012] The Mandala network of type A has the parameters (n1, b, λ) = (3, 2, 2), and in this case, the above formula becomes:

Number

[0013] By definition, any type of Mandala network is constructed with just three parameters (n1, b, λ). Therefore, it can only describe a very specific and restricted set of networks. It is recognized that it is desirable to establish a hierarchical network of nodes such that the nodes connecting to the network connect according to a given set of rules.

[0014] According to one aspect disclosed in this specification, a computer-implemented method for connecting to a hierarchical network is provided. The hierarchical network includes a plurality of nodes arranged in a set of ordered layers. The set of ordered layers includes, in order, a core layer including a set of core nodes, a second layer including a set of second nodes, and one or more outer layers each including a respective set of external nodes. Each core node is connected to at least one other core node. The method is executed by a connecting node and includes connecting to the network according to a connection protocol. The connection protocol requires that each node must connect to at least one node in the preceding layer and that each external node must also connect to at least one core node.

[0015] The present invention provides a method for connecting to a hierarchical network (LN) according to a connection protocol. The connection protocol enables a hierarchical network with fewer restrictions than the Mandala network to be formed while still retaining certain beneficial aspects of the Mandala network.

[0016] In embodiments, the core nodes include nodes of a blockchain network. In embodiments, each of the core nodes can be a mining node and / or a storage node (e.g., a full copy node) of the blockchain network.

Brief Description of the Drawings

[0017] To assist in understanding the embodiments of the present disclosure and to show how such embodiments can be implemented, reference is made to the accompanying drawings by way of example only.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

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

[0019] The blockchain 150 includes a chain of data blocks 151, and each copy of the blockchain 150 is maintained at each of a plurality of nodes within the P2P network 160. Each block 151 within the chain includes one or more transactions 152, and a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of digital assets belonging to a user 103 that the output is cryptographically locked (requires the user's signature to be unlocked and thereby redeemed or used). Each input refers to an output of a previous transaction 152, thereby linking the transactions.

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

[0021] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. Generally, the preceding transaction can be any transaction within the pool 154 or any block 151. The preceding transaction 152i needs to exist and be verified for validity for the current transaction to be valid, but the preceding transaction 152i does not necessarily need to exist when the current transaction 152j is created or when it is sent to the network 106. Thus, "preceding" as used herein refers to the preceding one in the logical sequence linked by the pointer and does not necessarily refer to the time of creation or transmission in the time sequence, and thus does not necessarily exclude the possibility that transactions 152i, 152j are created or sent out of order (see the following explanation regarding orphan transactions). The preceding transaction 152i is also referred to as the antecedent transaction or the predecessor transaction.

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

[0023] The above can be referred to as an "output-based" transaction protocol and is also sometimes called an unspent transaction output (UTXO) type protocol (where the output is called a UTXO here). Instead of being defined by any single number stored in the blockchain, the total balance of a user is instead required to have a special "wallet" application 105 to reconcile the values of all of that user's UTXOs scattered throughout many different transactions 152 within the blockchain 151.

[0024] Another type of transaction protocol can be called an "account-based" protocol as part of an account-based transaction model. In the case of account-based, each transaction defines the amount to be transferred by referring to the absolute account balance, rather than by referring to the UTXOs of previous transactions in the sequence of past transactions. The current state of all accounts is stored and constantly updated by a miner separate from the blockchain. In such a system, transactions are ordered using the running transaction tally of 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. Additionally, an optional data field can also be signed in the transaction. This data field can indicate a previous transaction, for example, if the previous transaction ID is included in the data field.

[0025] In any type of mode, if user 103 desires to establish a new transaction 152j, the user sends the new transaction from the user's computer terminal 102 to one of the nodes 104 of the P2P validity confirmation network 106 (which is typically a server or a data center today, but in principle can be other user terminals). This node 104 checks whether the transaction is valid according to the node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 and form the transaction model as a whole. The node protocol typically requires the node 104 to check that the cryptographic signature within the new transaction 152j matches the expected signature that depends on the previous transaction 152i within the ordered sequence of transactions 152. In the case of output-based, this may include checking that the user's cryptographic signature included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i used by the new transaction, and this condition typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i indicated by the input of the new transaction. In some transaction protocols, the conditions may be at least partially defined by custom scripts included in the input and / or output. Alternatively, it may be fixed by simply the node protocol only, or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes among the nodes 104 within the P2P network 106. At least some of these nodes 104 also function as forwarding nodes 104F, apply the same test according to the same node protocol, and forward the new transaction 152j to one or more further nodes 104, and so on.In this way, the new transaction is propagated throughout the network of node 104.

[0026] In an output-based model, the definition of whether a given output (e.g., a UTXO) has been used is whether it has been validly redeemed by an input of another previous transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to use or redeem has not yet been used / redeemed by another valid transaction. Similarly in this case, if it is not valid, transaction 152j is neither propagated nor recorded on the blockchain. This prevents double spending where a user attempts to use the output of the same transaction multiple times.

[0027] In addition to validity verification, at least some of nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is supported by "proof of work". At a mining node 104M, a new transaction is added to a pool of valid transactions that have not yet appeared in the block. Then, the miner competes to assemble a new valid block 151 of transactions 152 from the transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with and hashed with the transaction pool 154, the output of the hash meets a certain condition. For example, the certain condition could be that the output of the hash has a specific number of leading zeros. The property of a hash function is that it has an unpredictable output for its input. Therefore, this search can only be performed by brute force, consuming a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0028] The minor node 104M that first solves the puzzle publishes this to the network 106 and provides as proof its solution that can later be easily checked by other nodes 104 within the network (it is easy to check that the output of the hash meets the conditions given a solution to the hash). The pool 154 of transactions for which the winner has solved the puzzle is then recorded as a new block 151 within the blockchain 150 by at least some of the nodes 104 that function as storage nodes 104S, based on having checked the solution published by the winner at each such node. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 within the chain. Proof of work helps reduce the risk of double-spending as creating a new block 151 requires a great deal of effort, and blocks containing double-spending are likely to be rejected by other nodes 104, so mining nodes 104M are given an incentive to keep double-spending out of those blocks. Once created, the block 151 is recognized and maintained at each of the storage nodes 104S within the P2P network 106 according to the same protocol and cannot be modified. The block pointer 155 also gives a sequential order to the blocks 151. The transactions 152 are recorded in the ordered blocks at each storage node 104S within the P2P network 106, which provides an immutable public ledger of the transactions.

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

[0030] Different miners 104M competing to solve the puzzle at any given time may do so based on different snapshots of the unmined transaction pool 154 at that given time, depending on when they started searching for a solution. Note that regardless of who solves each puzzle first, the transactions 152 that will be included in the next new block 151n are defined and the current pool 154 of unmined transactions is updated. Then the miners 104M continue to compete to create blocks from the newly defined unprocessed pool 154, and so on. There is also a protocol for resolving any "forks" that may occur if two miners 104M solve the puzzle within a very short time of each other and conflicting views of the blockchain are propagated. In short, whichever prong of the fork grows the longest becomes the definitive blockchain 150.

[0031] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a brand-new amount of digital assets (as opposed to a normal transaction that transfers a certain amount of digital assets from one user to another). Thus, the winning node is said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "coinbase" transaction. It automatically forms part of the new block 151n. This reward provides an incentive for the miner 104M to participate in the proof-of-work competition. Often, normal (non-coinbase) transactions 152 also specify an additional transaction fee in one of their outputs to further reward the winning miner 104M that created the block 151n in which that transaction was included.

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

[0033] The memory of each node 104 stores software configured to be executed on the processing device of the node 104 to perform its respective one or more roles and process transactions 152 according to the node protocol. It will be understood that any action attributed to the node 104 herein can be performed by software executed on the processing device of each computer device. The node software can be implemented in one or more applications in the application layer, or in lower layers such as the operating system layer or protocol layer, or any combination thereof. Also, the term "blockchain" as used herein is generally a generic term referring to this type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0034] Each of the computer devices 102 of the plurality of parties 103 that play the role of consumer users is also connected to the network 101. These function as payers and payees in a transaction, but do not necessarily participate in the mining or propagation of the transaction on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102, namely, the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that there are far more such parties 103 and their respective computer devices 102 that can exist and participate in the system, but for the sake of convenience, they are not shown. Each party 103 can be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice, and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob can be replaced with "the first party" and "the second party", respectively.

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

[0036] The client application 105 may first be provided to the computer device 102 of any given party 103 on a suitable one or more computer-readable storage media, for example, downloaded from a server, or provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0037] The client application 105 includes at least a "wallet" function. This has two main functions. One of these is to enable each user party 103 to create, sign, and send a transaction 152 that will be propagated throughout the network of nodes 104 and thereby be included in the blockchain 150. The other is to report to each party the amount of digital assets that the party currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to the party.

[0038] While various client functions can be described as integrated into a given client application 105, it is not necessarily limited thereto. Instead, any client function described herein can alternatively be implemented, for example, in two or more separate applications that interface via an API or where one is a plugin to the other. More generally, client functions can be implemented in the application layer or a lower layer such as an operating system, or any combination thereof. In the following, the client application 105 will be described, but it is understood that it is not limited thereto.

[0039] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the forwarding nodes 104F of the P2P network 106. Thereby, the wallet function of the client 105 can send the transaction 152 to the network 106. The client 105 can also contact one, several, or all of the storage nodes 104 in order to query the blockchain 150 about any transaction for which each party 103 is the recipient (or, in an embodiment, since the blockchain 150 is a public facility that provides trust in transactions through its partial public visibility, actually inspect other parties' transactions in the blockchain 150). The wallet function on each computer device 102 is configured to formulate and send the transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of the transaction 152 according to a node protocol, and in the case of the forwarding node 104F, is configured to forward them to propagate the transaction 152 across the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol progresses with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 within the blockchain 150 (although the transaction protocol may allow for different subtypes of transactions therein). The same node protocol is used by all nodes 104 within the network 106 (although this can handle different subtypes of transactions differently according to the rules defined for those subtypes, and different nodes can assume different roles and thus implement different corresponding aspects of the protocol).

[0040] As described above, the blockchain 150 includes a chain of blocks 151, each block 151 including a set of one or more transactions 152 created by the proof-of-work process as described above. Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order to the block 151. The blockchain 150 also includes a pool 154 of valid transactions waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the genesis transaction) includes a pointer back to the previous transaction to define an order to the sequence of transactions (note: the sequence of transactions 152 can branch). The chain of blocks 151 goes all the way back to the genesis block (Gb) 153 that was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0041] When a given party 103, e.g., Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction according to the relevant transaction protocol (using the wallet function within Alice's client application 105). Alice then sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which Alice is connected. For example, this could be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives a new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for it to be "valid", examples of which will be described in more detail below. In some transaction protocols, the conditions for validity checking may be configurable for each transaction by the script included in the transaction 152. Alternatively, the conditions may simply be an embedded feature of the node protocol, or defined by a combination of the script and the node protocol.

[0042] Conditioned upon passing a test for a newly received transaction 152j to be considered valid (i.e., conditioned upon it being "validated"), any storage node 104S that receives transaction 152j adds a new validated transaction 152 to a pool 154 within a copy of the blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j propagates the validated transaction 152 forward to one or more other nodes 104 within the P2P network 106. Since each forwarding node 104F applies the same protocol, assuming transaction 152j is valid, this means it will be propagated throughout the entire P2P network 106 immediately.

[0043] Once admitted to the pool 154 within a copy of the blockchain 150 maintained at one or more storage nodes 104, miner nodes 104M begin competing to solve a proof-of-work puzzle for the latest version of the pool 154 that includes the new transaction 152 (other miners 104M may be attempting to solve the puzzle based on an older view of the pool 154, but whoever reaches it first will define where the next new block 151 ends and where the new pool 154 starts, and ultimately someone will solve the puzzle for the part of the pool 154 that includes Alice's transaction 152j). When proof-of-work is done for the pool 154 that includes the new transaction 152j, it invariably becomes part of one of the blocks 151 within the blockchain 150. Since each transaction 152 includes a pointer back to the previous transaction, the order of the transactions is also invariably recorded.

[0044] Both mining nodes and storage nodes can perform validation as a function. In the case of mining nodes, the function is assisted by hashing, and in the case of storage nodes, the function may be assisted by storage.

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

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

[0047] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that contains one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies the amount of digital assets. This represents the set number of tokens on the (decentralized) ledger. A UTXO may also include, among other information, the transaction ID of the originating transaction. The transaction data structure may also include a header 201 that may contain an indicator indicating the sizes of the input field(s) 202 and the output field(s) 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 that is submitted to the miner 104M.

[0048] Suppose Alice 103a wishes to create a transaction 152j that transfers the amount of the digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". This takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction within the blockchain 151 nor that Tx1 is the very next transaction within the pool 154. Tx1 can refer to any preceding (i.e., earlier) transaction that still has an unused output 203 locked to Alice.

[0049] The preceding transaction Tx0 may already be validated and included in the blockchain 150 when Alice creates a new transaction Tx1, or at least by the time Alice sends it to the network 106. It may already be included in one of the blocks 151 at that time, or still be waiting in the pool 154, in which case it will be included in a new block 151 shortly. Alternatively, Tx0 and Tx1 can be created and sent together to the network 102, or even Tx0 can be sent after Tx1 if the node protocol allows buffering of "orphan" transactions. The terms "preceding" and "subsequent" as used herein in the context of the transaction sequence refer to the order of transactions in the sequence as defined by the transaction pointers specified within the transaction (such as which transaction refers to which other transaction). They may similarly be replaced with "predecessor" and "successor", or "earlier" and "later", "parent" and "child", etc. This does not necessarily mean the order of their creation, transmission to the network 106, or arrival at any given node 104. Nevertheless, a subsequent transaction (later transaction or "child") that refers to a preceding transaction (earlier transaction or "parent") is not validated until the parent transaction is validated and as long as it is not validated. A child that arrives at node 104 before its parent is considered an orphan. It may be buffered for a specific time or discarded to wait for the parent, depending on the node protocol and / or miner behavior.

[0050] One of one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO labeled as UTXO0 herein. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a lock script, and the lock script defines the conditions that the unlock script within the input 202 of a later transaction must meet for the later transaction to be valid and thus for the UTXO to be properly redeemed. Typically, the lock script locks that amount to a specific party (the beneficiary of the transaction in which it is included). That is, the lock script typically defines an unlock condition that includes the condition that the unlock script within the input of a later transaction includes the cryptographic signature of the party to whom the previous transaction is locked.

[0051] The lock script (commonly known as scriptPubKey) is a portion of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (with a capital S). The lock script specifies what information is required to use the transaction output 203, for example, specifying the requirements for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (commonly known as scriptSig) is a portion of code written in a domain-specific language that provides the information required to meet the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0052] That is, in the illustrated example, the UTXO0 within the output 203 of Tx0 requires Alice's signature Sig P A for the lock script [Checksig P A to be included. [Checksig P A is the public key P from Alice's public key - private key pair AIt includes. The input 202 of Tx1 includes a pointer indicating Tx1 (e.g., in an embodiment, its transaction ID, TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying it within Tx0 to identify UTXO0 from among any other possible outputs of Tx0. The input 202 of Tx1 includes an unlock script <Sig P A > that further includes an Alice's cryptographic signature created by Alice applying her private key from the key pair to a predetermined portion of the data (which may also be called the "message" in cryptography). What data (or "message") needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

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

[0054] When the new transaction Tx1 arrives at 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 meets the conditions defined by the lock script (this condition may include one or more criteria). In an embodiment, this includes concatenating the two scripts: <Sig P A > <P A > || [Checksig P A ​ Here, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function composed of unlock scripts (in this example, a stack-based language). Equally, the scripts can be executed one after another using a common stack rather than concatenating the scripts. In any case, when executed together, the scripts use the public key P A of Alice, which is included in the lock script within the output of Tx0, to authenticate that the lock script within the input of Tx1 contains Alice's signature that signed the expected part of the data. The expected part of the data itself (the "message") also needs to be included in the Tx0 instruction to perform this authentication. In an embodiment, the signed data includes the entirety of Tx0 (i.e., since a separate element specifying the signed part of the plaintext data already essentially exists, it does not need to be included).

[0055] Details of authentication by public-private cryptography are well known to those skilled in the art. Basically, when Alice signs a message by encrypting the message with her private key, given Alice's public key and the plaintext message (the unencrypted message), another entity such as node 104 can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the plaintext version of the message, such that any holder of the public key can authenticate the signature. Thus, it should be noted that any reference herein to signing a particular part of the data or a part of a transaction may, in an embodiment, mean signing the hash of that part of the data or the part of the transaction.

[0056] A hash referred to anywhere in this specification may be implemented by, for example, an 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.

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

[0058] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all of its inputs 202, this represents another basis for invalidity in most transaction models. Thus, such a transaction is neither propagated to nor mined in a block 151.

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

[0060] In practice, today, the reward for generating a transaction alone typically is not sufficient to motivate mining, so Alice usually also needs to include a fee for the winning miner. If Alice does not include a fee for the miner, Tx0 is likely to be rejected by miner node 104M, and thus, even if technically valid, it still will not be propagated and will not be included in blockchain 150 (the miner protocol does not force miner 104M to accept transaction 152 if it does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, the difference between the total amount indicated by the input(s) 202 of a given transaction 152 and the total amount specified by the output(s) 203 is automatically given to the winning miner 104. For example, assume that the pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference is automatically given to the winning miner 104M. However, alternatively or additionally, it is not necessarily excluded that the miner fee can be explicitly specified in one of its own of the UTXOs 203 of transaction 152.

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

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

[0063] Signature P A is a digital signature. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a portion of specific data. In an embodiment, for a given transaction, the signature signs a portion of the transaction inputs and all or a portion of the transaction outputs. The specific portion of the signed output depends 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 (and thus is fixed at the time of signing).

[0064] The lock script may be referred to as "scriptPubKey" to indicate the fact that each transaction contains the public key of the party being locked. The unlock script may be referred to as "scriptSig" to indicate the fact that it supplies the corresponding signature. However, more generally, it is not essential in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0065] Hierarchical network Hierarchical network structure A hierarchical 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., an enterprise-to-enterprise P2P network), or a wide area network such as the Internet. In other examples, the hierarchical network can be a network of nodes connected via a wired connection. In yet other examples, the connection can be a wireless connection, e.g., a Bluetooth® or Wi-Fi connection. In some examples, some or all of the exemplary connections described above can be used to form the hierarchical network.

[0066] Some or all of the nodes are networks and are configured to connect to (i.e., participate or re - participate in) a hierarchical network according to a connection protocol. The connection protocol can vary depending on the particular layer of the network to which the connecting node is connecting (i.e., attempting to participate or re - participate). Before describing the connection protocol in detail, a series of exemplary hierarchical networks that can be created, i.e., enforced, by the connection protocol will be described. However, these are merely exemplary examples, and it will be understood that generally any hierarchical network that follows the connection protocol can be created.

[0067] Figure 3 shows a schematic diagram of an example of a hierarchical network (LN) 300. Generally, an LN includes a core network (or core layer) composed of core nodes 301 and a series of layers (or shells). The core layer is also called the first layer of the LN. The series of layers extends in order from the second layer composed of second nodes 302 towards the outside of the core layer to one or more outer layers. Each outer layer is composed of a set of external nodes 303. Although only one outer layer is shown in Figure 3, it will be understood that an LN can include any number of outer layers. As a specific example, an example of an LN500 including five layers is shown in Figure 5, and an example of an LN600 including four layers is shown in Figure 6.

[0068] The exemplary LN300 of Figure 3 includes five core nodes 301, six second nodes 302, and eight external nodes 303. In some LNs 300, the number of nodes can increase from layer to layer, i.e., the core layer is composed of the smallest number of nodes and the outermost layer is composed of the largest number of nodes. In other examples, one or more of the layers between the core layer and the outermost layer can be composed of the largest number of nodes. In this example, the core layer is the innermost layer of the LN300, the second layer is the middle layer, and the outer layer, which is the only outer layer, is the outermost layer.

[0069] The core layer (network within the LN) in this example forms a complete graph, i.e., each core node 301 is connected to every other core node 301. In the case of a core layer of five core nodes 301, in a given example, the core layer requires 10 distinct core connections (i.e., one connection between two core nodes). In other examples (e.g., FIG. 4), the core layer will not be a complete graph. The core layer may form an “almost complete graph”. In an almost complete graph, at least one core node 301 is not connected to at least one other core node 301. Only one core connection may be missing. In a particular example of an almost complete graph, each core node 301 may be connected to one or more but not all of the other core nodes 301.

[0070] The second layer includes second nodes 302. Note that the term "second node" is used only as a label for nodes 302 that are structurally located within the second layer of the LN300. Each second node 302 is connected to at least one core node 301. In some examples, each second node 302 may be connected to only one core node 301. Alternatively, some or all of the second nodes 302 may be connected to two or more core nodes 301. For example, some or all of the second nodes 302 may be connected to each individual core node 301. In the exemplary LN300 of FIG. 3, each core node 301 is connected to two second nodes 302. However, in this example, some second nodes 302 (shown as striped circles) are connected to one core node 301, and some second nodes 302 (shown as white circles and shaded circles) are connected to two core nodes 301. Second nodes 302 (and outer layer external nodes 303) that are connected to the same core node 301 are called a "community". For example, each white node together forms one community, each striped node together forms one community, and each shaded node together forms yet another community. The connection between the second node 302 and the core node 301 is called an "ancestor connection" and is shown as a thick 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 connections with other second nodes. For example, some second nodes 302 may be connected to other second nodes 302, while some second nodes may not be connected to other second nodes 302. These "intra-layer" connections are shown as solid lines between nodes in FIG. 3.

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

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

[0074] is connected to at least one second node 302, and 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 called a "core ancestor connection" and is shown by a thin dashed line. Each external node 303 can be connected to each of the core nodes 301 to which the second node(s) 302 of their ancestors are connected. As shown in FIG. 3, each external node 303 can be connected to each of the core nodes 301 to which the second node(s) 302 of their ancestors are connected and will not be connected to other core nodes 301. In this case, each external node 303 belongs to a single community.

[0075] FIG. 4 shows a schematic diagram of another example of LN400. Similar to LN300 in FIG. 3, the exemplary LN400 includes a core layer, a second layer, and an outer layer. These exemplary LN300, 400 share the same number of nodes (i.e., 5 core nodes 301, 6 second nodes 302, and 8 external nodes 303), but include different numbers of connections. For example, in this example, since some connections between the core nodes 301 do not exist, the core layer is not a complete graph. Another difference is that two communities (white nodes and shaded nodes) include a single core node 301, while another community (shaded nodes) includes three core nodes 301. Yet another difference is that, unlike the degree of the nodes within the outer shell of LN300 being 2, the degree of the nodes within the outer shell of LN400 is 1 here. That is, in this exemplary LN400, each external node 303 is connected to a single other external node 303. Therefore, the nodes in different layers have different degrees.

[0076] Figure 5 shows a schematic diagram of another example of LN500. In this example, only some of the core nodes 301 are connected to the second node and the external node 303. That is, in this example, some of the core nodes 301 form connections only with other core nodes 301. Therefore, in this example, LN500 includes a single community (shadowed nodes). The LN500 of this example includes five layers: a core layer, a second layer, and three outer layers. The core layer is composed of five core nodes 301 that form an almost complete graph. In this example of an almost complete graph, only a single core connection is missing. The second layer is composed of a single second node 302 connected to two core nodes 301. The second layer is composed of a single second node 302 connected to two core nodes 301. The third layer is composed of a single external node 303 connected to the second node 302 via an ancestor connection. The external node 303 of the third layer is also connected to the 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 their respective core ancestor connections. The fourth layer is also composed 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 to the second node 302 via an ancestor connection. The external node 304 of the fourth layer is also connected to the two core nodes 301 to which the second node 302 and the external node 303 of the third layer are connected. The external node 304 is connected to the two core nodes 301 via their respective core ancestor connections. Finally, the fifth layer is composed 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, to the external node 303 of the third layer, and to the second node 302, and each connection is an ancestor connection. The two external nodes 305 are also connected to the two core nodes 301 via core ancestor connections. In this exemplary LN500, the nodes of the second layer and the nodes of the outer layers are not connected to any other nodes in the same layer.

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

[0078] In some embodiments, LN300, 400, 500, 600 (hereinafter simply referred to as "300") may be a "blockchain layered network (BLN)". As used herein, the term BLN is defined as a layered network that includes a blockchain network, or at least a part of a blockchain network, for example, 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 enable a more flexible and desirable connection structure for, for example, services and user networks that utilize the blockchain network 106.

[0080] BLN300 may include at least a part of the blockchain network 106 at its core. Generally, the nodes of the layered network are overlaid on an underlying infrastructure network such as the Internet 101. Some or all of the core nodes are nodes 104 of the blockchain network 106. They may include mining nodes 104M, storage nodes 104S, or a combination thereof. In an embodiment, each of the core nodes is a mining node 104M and / or a storage node 104S (e.g., a full copy node).

[0081] Each of the external nodes 303 (or each of the outermost external nodes) can be an end-user node including the user's computer device. This can be an individual user, or an organization such as a company, academic institution, or government agency. Thus, each external node 303 can include one or more user terminals and / or a server including one or more server units at one or more sites. Each external node 303 includes a memory including one or more memory units and a processing device including one or more processing units. These can take the form of either a memory medium and / or a processor as described above in relation to other network elements or user equipment. The memory stores client software configured to be executed on the processing device, and the client software, when executed, is configured to operate the node as a client of a protocol according to a connection protocol according to any of the following embodiments or similar. Optionally, one or more of the end-user nodes can include the user equipment 103 of the user 102 of the blockchain network 106, and the client software can include a blockchain wallet application 105 or the like.

[0082] Each second node 302 can take the form of a server including one or more physical server units. Each such node includes a memory including one or more memory units and a processing device including one or more processing units. These can take the form of either a memory medium and / or a processor as described above in relation to other network elements. The memory stores software configured to operate on the processing device of the second node 302. The software, when executed, is configured to comply with a connection protocol according to any of the following embodiments or similar. In some embodiments, the software, when executed, is configured to provide a service that operates according to any of the embodiments described below or similar.

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

[0084] In other examples, some or all of the second nodes 302 may operate a distributed database among themselves. That is, each second node 302 that operates the distributed database is configured to store data received from another node of the LN300, e.g., the external node 303. The second node 302 that receives and stores the data may be configured to propagate the data to other second nodes 302 that are also operating the distributed database.

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

[0086] In an embodiment where LN300 is a BLN, some or all of the second nodes 302 may be configured to send blockchain transactions to the core node 301 to which those second nodes 302 are connected. In some examples, the second node 302 may generate a blockchain transaction and then send the blockchain transaction to the core node(s) 301. In other examples, the second node 302 may forward a blockchain transaction to the core node(s) 301. For example, the second node 302 may receive a blockchain transaction from an external node 303 and then send the received blockchain transaction 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 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 node 303 may send a blockchain transaction to the second node 302 and to the core node 301.

[0088] Some or all of the external nodes 303 may be configured to send blockchain transactions to other external nodes 303, such as external nodes within the same tier or external nodes in the previous or next tier in a set of ordered tiers.

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

[0090] Additionally or alternatively, the second node 302 and / or the third node 303 may be configured to send a request for a Merkle proof of the transactions mined in block 151 of the blockchain 150 to the core node 301. Merkle proofs are well known to those skilled in the art. A Merkle proof is a sequence of hashes leading up to the Merkle root. To verify whether a transaction was mined in block 151, nodes 302, 303 take the hash of the transaction and concatenate it with the first hash in the sequence of hashes of the Merkle proof (i.e., the hash partner of the Merkle tree at the same level as the hash of the transaction), and hash the result. This process of concatenation and hashing is repeated until all the hashes in the Merkle proof are utilized. If the resulting hash is identical to the Merkle root, the transaction must be included in the Merkle tree and thus in block 151. The core node 301 is configured to send the Merkle proof to the requesting 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 includes the Merkle root of the transactions mined in that 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 send a set of transactions to some or all of the second node(s) 302 and / or some or all of the external node(s) 303 connected to the core nodes 301. The transactions within the set may share a common attribute. For example, the core node 301 may send all transactions that include a specific protocol flag. The flag may be included in the output of the transaction, for example, in an unspendable output. As another example, the transactions may include a specific (and the same) blockchain address. For example, the transactions may be payable to the same blockchain address. The external node 303 may agree with the core node 301 that the core node 301 will send any transaction payable to the address associated with the external node 303. As yet another example, the transactions may include a secondary consensus rule set. That is, the transaction may include, in the output, two or more control branches, each control branch being specific to a respective consensus rule set. The output may include a first control branch specific to a first rule set and a second control branch specific to a second rule set (the two control branches may be included in an if-else condition). If the nodes 302, 303 are configured to implement the second rule set, the core node 301 may send the transaction to the nodes 302, 303. If the nodes 302, 303 are not configured to implement either the first rule set or the second rule set, the core node does not send the transaction to the nodes 302, 303.

[0093] The core node 301, which is the mining node 104M, may include an identifier unique to the mining node 104M (e.g., "Miner ID") in the generated transaction (also called "coinbase" transaction) mined into block 151 by the mining node 104M. Other nodes of the BLN300 can identify the mining node 104M on the network using the identifier.

[0094] Another way to identify the nodes 301, 302, 303 of the LN300 is by digital certificates. Some or all of the nodes 301, 302, 303 may be associated with digital certificates. Digital certificates include identifiers of each node, such as the public key associated with the node, the network address of the node (e.g., IP address), etc., and prove them. Nodes of the LN300 can use digital certificates of different nodes to connect to that node. For example, the external node 303 can obtain a digital certificate from the second node 302 and use the identification information of the second node included in the digital certificate to connect to the second node 302.

[0095] Nodes of a given layer can issue digital certificates to nodes of the next layer in the ordered set of layers, i.e., the core node 301 can issue a digital certificate to the second node 302, the second node 302 can issue a digital certificate to the external node 303 of the first outer layer, and so on. In some examples, nodes of a given layer can issue digital certificates to nodes of the same layer, e.g., the second node 302 can issue each digital certificate to one or more other second nodes 302.

[0096] Connection protocol As described above, each node connected to the hierarchical network 300 can be connected according to the connection protocol. That is, the connected nodes must follow the rules of the connection protocol. The connected nodes can only form connections permitted by the connection protocol. Other connections will not be formed. In the example, the connected node can be the core node 301, the second node 302, or the external node 303. In some examples, each node of the LN300 must follow the connection protocol. In other examples, only the nodes that first connect to the LN300 or the nodes that rejoin the LN300 must follow the connection protocol. FIGS. 3 to 6 show exemplary LN300, 400, 500, and 600 established according to the connection protocol.

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

[0098] The connection protocol requires that the connecting node connect to at least one node in the preceding (more inner) layer and at least one core node, except in some cases where the core node can be the innermost layer and the connecting node cannot connect to the preceding layer. In an example where the connecting node is the second node, these two requirements are equivalent. When the connecting node is an external node in the first outer layer, the connecting node connects to at least the second node 302 and the core node 301.

[0099] The connection protocol may require that the connecting node connect to more than one core node. The connection protocol may further require that the connecting node connect to more than one but not all of the core nodes, for example, all core nodes except one. The connecting node can be a second node that must connect to more than one core node. That is, some or all of the second nodes must connect to more than one core node (not all core nodes in some examples).

[0100] The connection protocol may require that the connecting node connect to one or more second nodes. When the connecting node is the second node, this means that the connecting (second) node must connect to one or more different second nodes. When the connecting node is an external node, the connecting (external) node must connect to one or more second nodes. The connecting external node can be an external node in the first outer layer, or an external node in the second layer, etc.

[0101] The connection protocol may require that an external node connected to a node in a preceding layer be connected to some or all of the core node(s) (referred to above as "core ancestors") to which the node in the preceding layer is connected. For example, an external node may be connected to a second node. In that 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 two or more second nodes, the connection protocol may require that the external node be connected to the core node(s) to which each of the second nodes is connected. As another example, an external node in a second outer layer may be connected to an external node in a first outer layer. In that example, the connection protocol requires that the external node in the second outer layer be connected to the core node(s) to which the external node in the first outer layer is connected.

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

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

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

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

[0106] The connection protocol enables the construction of a BLN. Similar to the Mandala network, the BLN is constructed in layers. Unlike the Mandala network, the first layer can form an incomplete graph (e.g., an almost complete graph). Another difference between the BLN and the Mandala network is that in the BLN, nodes in each subsequent layer can have different degrees, a node can be connected to two or more nodes in the central layer, and / or the degree of a node can vary between layers.

[0107] Preferably, for all nodes outside the central core: (i) Each node is connected to m out of n1 nodes in the central core. (ii) Each node is connected to nodes in all layers, where g is the total number of layers. (iii) Each node is a member of exactly one community. There are at most n2 communities, where n2 is the number of nodes in the second layer. (iv) Each node is connected to all other nodes within a maximum of three hops. This is called the diameter of the graph.

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

[0109] A characteristic of the Mandala network is that all nodes outside the core layer (i = 1) are connected to exactly one core ancestor (i.e., c i = 1 everywhere). This greatly contributes to the emergent properties of the Mandala network. · Network size (N = Σ in i has an average shortest path length that asymptotes to a constant as · The network size (N = Σ i n i ) becomes very sparse as it grows. · Is robust to random node failures.

[0110] A feature of the BLN is that all non-core nodes connect to at least one ancestor. However, the definition of the BLN corresponds to non-core nodes having a maximum of m connections to core ancestors (i.e., anywhere 1 ≤ c i ≤ m). The reason for the generalization of c i = 1 to 1 ≤ c i ≤ m across the BLN can be understood as an artifact of the blockchain protocol. The protocol defining the blockchain system depends on a probabilistic security model. In essence, this means that any participant (node) within the BLN that has a vested interest in an event being recorded on the blockchain 150 must take into account the probabilistic security model by connecting to a minimum fraction f of the network hash power, where 100% of the total hash power is distributed among the nodes within the core layer of the BLN.

[0111] Assuming that the core layer exhibits a uniform equilibrium distribution of hash power among its n1 core nodes, the minimum fraction of nodes is as follows: f = m / n1

[0112] The blockchain protocol shows that the lower bound of the minimum fraction is f = 0.51, but network participants in large-scale BLNs may require a higher fraction (e.g., f = 0.67) to increase resilience (e.g., to double-spending). The BLN can be characterized by the choice of the parameter m, which defines the probabilistic security of operation for participants within the BLN and depends on the specific use case of the needs of that BLN.

[0113] The nodes within the second layer L2 closest to the core rely most strongly on the probabilistic security model of the blockchain protocol, and this dependency can decrease as the layer approaches L g . The connection protocol may require the nodes within L2 to connect precisely to c2 = m core ancestors, while the nodes within all subsequent layers i > 2 can connect anywhere within the range 1 < < c i ≤ m of the core ancestors. In some examples, the nodes of all subsequent layers must connect to m core ancestors.

[0114] Nodes outside the central core of the BLN may have a "SPV-like" connection to the core. This means that they can do the following. a) Send transactions to the core nodes. b) Ask the core nodes whether the transactions have been accepted in their mempool / candidate blocks. c) Request the Merkle proofs of the transactions mined in the blocks. d) Request the latest list of block headers.

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

[0116] Regarding nodes that operate smart contracts, some only require actions a) to d) such as SPV, while others require consensus to receive more data from core nodes.

[0117] In some BLNs, the user can operate nodes at layer 3 or above, and smart contracts can be operated by nodes at layer 2 or above. Since it is necessary to continuously monitor the blockchain 150 for transactions containing specific addresses, in reality, the user cannot continuously "listen" to the blockchain for transactions with a specific output address. Considering that the number of transactions that can be sent to the blockchain continues to increase over time, such continuous monitoring is not realistic for end-users. Continuously monitoring the blockchain is common among the wallet architectures of some blockchains, but considering that both the number of transactions submitted to the blockchain over time and the number of blockchain users are expected to increase dramatically in the future, it is not a scalable solution. Consider the following example: Alice wants to pay Bob. Alice creates a transaction for the desired amount with an output address that she knows belongs to Bob. Then, instead of submitting this transaction directly to Bob, Alice submits it to the mining network. For Bob to know that the transaction has been accepted, Bob has to "listen" to the blockchain to check if and when a transaction with his output address appears on the network. Bob has to ask the mining node to do this on his behalf. This means that the mining node has to keep a record of Bob's address and check if all the transactions it receives match this address. Note that there is no economic incentive for the miner to do this. Assuming that the miner has to process one million transactions per second and check if they match one million addresses, it can be seen that this quickly becomes unrealistic.

[0118] Instead, in the BLN, Alice can be directly connected to Bob and can send the transaction directly to Bob. Then, Bob can send the transaction to the miners within the core and at the same time ask them whether they will accept the transaction as valid. Since the transaction includes the miner's fee, the miner is given an incentive to accept the transaction and is given an incentive to check whether to accept the transaction in order to reduce the risk of building a block that will be discarded. To make the system even more secure, Alice can send the Merkle proof of the input to her transaction to Bob. Since Bob has a copy of the block header, he can check these Merkle proofs. This guarantees to Bob that Alice's input was part of the blockchain 150 at a certain point in time, and if Alice has already used them, Bob will have proof of double spending since he has received a signature from Alice in the transaction given to Bob by Alice. Note 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. If the smart contract is "light" in the sense that the smart contract operator has not made any specific agreement with the mining node to facilitate the processing of the smart contract, it cannot rely on listening to the blockchain 150 to receive transactions that trigger a change in state. Alice must send such transactions directly to the smart contract.

[0119] Service providers may operate nodes at layer 2 or above. In the case of service providers, it is different from that of users or lightweight smart contracts. A service provider may have a commercial agreement with a set of core mining nodes or core nodes, and then they propagate a specific subset of transactions to the service provider nodes. Such transactions should be easily identifiable and, for example, meet the following specific criteria: · OP_RETURN data with specific protocol flags. For example, the MetaNet protocol, the tokenization protocol, or the digital certificate protocol. · The output addresses match a small specific set. For example, enterprise-level smart contracts or address whitelists / blacklists. · A secondary consensus rule set indicated by the OP_VER control branch.

[0120] In addition, transactions sent to the core that comply with these rules or are identified as part of the community participating in the service level agreement in other ways may have a low (or even zero) transaction fee. The shortfall can be made up by a higher transaction volume or by the immutable revenue from the service level agreement.

[0121] All nodes of BLN300 can be associated with a semi-permanent public key associated with their identity. This public key enables secure communication and can provide a link to the public key used in blockchain transactions by deterministic derivation of the identity key or by signing or encrypting the transaction key using the identity key.

[0122] Two ways to identify mining core nodes are as follows: 1) Miner ID. A miner may choose to identify itself by adding its ID key to the input of the coinbase transaction within each block it mines. 2) Network analysis. Some miners choose to remain anonymous. However, it is still possible to identify which nodes are constructing blocks by analyzing the network, for example, by seeing where new blocks are coming from.

[0123] It is important that the nodes of the BLN can identify both types of miners, so that as many miners as possible can be polled regarding whether their transactions were accepted.

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

[0125] Regardless of the presence or absence of a certificate from the core node, layer 2 nodes may request that an external CA issue a digital certificate. Thus, each layer 2 node may have at least one digital certificate to prove its identity. They can issue certificates to other nodes within layer 2, thereby creating a web of trust among them. Nodes within layer 2 can issue certificates to nodes within layer 3, nodes within layer 3 can issue certificates to nodes within layer 4, and so on, creating a hierarchy of certificates called a Public Key Infrastructure (PKI).

[0126] In fact, such a PKI can be used not only for identifying nodes within the BLN, but also to ensure that the correct BLN structure is maintained. For example, if a layer 3 node issues certificates to too many layer 4 nodes, or fails to ensure having proper connections to other nodes within the system, the certificate of the layer 3 node can be invalidated.

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

[0128] Adaptive connection Embodiments of the present invention can also provide a method of intentionally dropping (or disabling) the connections of a hierarchical network based on the characteristics (conditions) of the hierarchical network. That is, in these embodiments, the nodes of the LN300 can be configured to adapt their connections to other nodes in response to certain undesirable or unwanted network conditions.

[0129] The adaptive node (i.e., the node that adapts the connection(s)) can be the core node 301, the second node 302, or the external node 303. In some examples, each node of the LN300 can be configured to adapt its connection to other nodes based on network characteristics. The adaptive node can be a node such as an SPV, as described above.

[0130] In the context of the LN300, disabling the connection to a node means preventing any data from being sent through the connection to that node, and does not necessarily mean physically terminating the connection. In other words, as described above, the connection between two nodes 301, 302, 303 in the hierarchical network 300 means that these nodes can communicate directly, which in this context means that there is no need to perform a hop through another node 301, 302, 303 in the hierarchical network 300. In the context of an overlay network such as the hierarchical network, "connection" means a connection (i.e., an edge) at the level of the hierarchical network 300 (i.e., the level of the overlay network protocol of the hierarchical network). Therefore, disabling the connection means that the connection between two nodes 301, 302, 303 in the hierarchical network 300 means that those nodes can no longer communicate directly.

[0131] An adaptive node can be connected to one or more core nodes 301. For example, the adaptive node can be a core node 301 connected to other core nodes 301. In other examples, the adaptive node can be a second node 302 or an external node 303 connected to one or more of the core nodes 301. In these examples, the adaptive node can disable one or more, but not all, of the connections between the adaptive node and the core node(s) 301 to which the adaptive node is connected, in response to network characteristics.

[0132] The adaptive node may be connected to one or more second nodes 302. For example, the adaptive node may be a core node 301 connected to the second node(s) 302. In other examples, the adaptive node may be a second node 302 connected to other second nodes, or the adaptive node may be an external node 303 (such as in either a first outer layer or a second outer layer, etc.) connected to one or more second nodes 302. In these examples, the adaptive node may, in response to network characteristics, disable one, some, or all of the connections between the adaptive node and the second node(s) 302 connected to the adaptive node.

[0133] The adaptive node may be connected to one or more external nodes 303 within, for example, the same outer layer or different outer layers. For example, the adaptive node may be a core node 301 connected to the external node(s) 303 via a core ancestor connection. In other examples, the adaptive node may be a second node 302 connected to the external node(s), or the adaptive node may be an external node 303 connected to one or more external nodes 303 within the same outer layer and / or across different outer layers. In these examples, the adaptive node may, in response to network characteristics, disable one, some, or all of the connections between the adaptive node and the external node(s) 303 connected to the adaptive node.

[0134] In some embodiments, one or more network characteristics on which adaptation is performed may include the load of the hierarchical network. The adaptation node may disable one or more connections in response to detecting a load balancing problem (e.g., too much traffic across one or more connections of the hierarchical network 300). The load balancing problem may be a network scale problem, i.e., the load across the network has exceeded a threshold amount as a whole. In that situation, the adaptation node may select which connection to disable in order to bring the load below an acceptable threshold. In other examples, the adaptation node may receive an instruction from one of the nodes connected to the adaptation node, and the instruction may instruct the adaptation node to drop a specific connection. For example, the core node 301 may instruct the adaptation node (e.g., an external node) to drop the connection between the core node 301 and the adaptation node.

[0135] The load balancing problem may be the load between the adaptation node and a specific node connected to the adaptation node. For example, the adaptation node may be the core node 301 that experiences increased load between the second node 302 or the external node 303. The adaptation node can disable the connection with the increased load, for example, to bring the load within an acceptable threshold amount. Alternatively, the adaptation node may be a node connected to the core node 301, and the adaptation node may disable the connection in response to an instruction from the core node 301 to drop the connection, for example.

[0136] The load balancing problem may be that the load across the core nodes 301 in the core layer exceeds an acceptable threshold. If the adaptation node is the core node 301, the core node 301 may drop one or more of its connections to other core nodes 301 and / or to one or more second nodes 302 and / or to one or more external nodes 303, for example. If the adaptation node is the second node 302 or the external node 303, the second node 302 or the external node 303 may drop one or more of its core connections.

[0137] Detecting a load balancing problem may include detecting that the load on a connection (s) between an adaptive node and one or more other nodes in a hierarchical network exceeds a threshold. Such load may be measured, for example, with respect to bandwidth, error rate, packet loss rate, latency, jitter, or a composite metric combining one or more such measurements. Alternatively or additionally, detecting a load balancing problem may include detecting that the processing load of the adaptive node exceeds a threshold. This may be measured, for example, in terms of the processing resources consumed by the adaptive node or the processing resources available to the adaptive node.

[0138] In an embodiment, detecting a load balancing problem may include detecting that the number of connections between an adaptive node and one or more other nodes of the network (e.g., core node 301) exceeds a threshold number of connections, e.g., the maximum number of total connections to the adaptive node (e.g., core node). For example, the adaptive node may be adapted within a minimum or maximum number of connections permitted by the connection protocol defined above.

[0139] For example, the adaptive node may be core node 301 that is connected to an excessive number of nodes. The threshold may be a threshold for connections between the adaptive node and nodes of a particular layer. For example, the adaptive node may only be permitted to form (and maintain) a certain amount of core connections, or connections to a second node 302, or connections to an external node 303 (e.g., in total across a particular layer or outer layer). The adaptive node may drop one or more of its connections to other nodes and / or may instruct one or more of the nodes to which it is connected to drop their connections to the adaptive node. The number of connections dropped may be the same as or greater than the number of connections that exceed the threshold number of allowable connections.

[0140] In some embodiments, network characteristics may include privacy issues. That is, an adaptive node may receive an indication of a privacy violation of the network (or otherwise obtain information regarding it). The privacy issue may be a hacking or malfunction of a node of the network. Alternatively, the privacy issue may be that the identification information (e.g., of an adaptive node of LN300 or other nodes) has been put at risk (e.g., stolen or leaked). The adaptive node may drop the connection to a node whose identification information has been put at risk. The identification information may include a private key and / or a public key associated with a given node of LN300.

[0141] An adaptive node may receive an indication of network characteristics from one or more nodes of LN300 to which the adaptive node is connected. The indication may also include, for example, an instruction to drop the connection to the node that sends the indication to the adaptive node. In some examples, only the core node 301 is configured to issue indications and / or instructions. In other examples, the second node 302 and / or the external node 303 may be additionally or alternatively configured to issue indications and / or instructions. The adaptive node may drop the connection to the node that sends the indication to the adaptive node.

[0142] In some embodiments, disabling the connection to each node may include invalidating each digital certificate issued to each node by the adapting node. In these examples, a node must have a valid digital certificate to connect to another node. The adapting node may be the core node 301 responsible for issuing digital certificates to the second node 302 and / or the external node 303. The adapting node may, for example, invalidate the digital certificate of the external node 303 to disable the connection to that node. As another example, the second node 302 may be responsible for issuing digital certificates to the external node 303. Here too, the adapting node, which is the core node 301, may instruct the second node 302 to invalidate the digital certificate of the external node 303 to disable the connection between the adapting node and the external node 303.

[0143] The adapting node may be the second node 302 or the external node 303 that requires knowledge of the state of the blockchain 150, such as whether a transaction has been accepted in the pool 154 of the mining node 104M, whether the transaction has been recorded in the block 151 of the blockchain 150, etc. The adapting node may send requests for information to one or more core nodes 104 that are blockchain nodes 301 (e.g., a single core node connected to the adapting node), and one or more second nodes 302 (e.g., a single second node connected to the adapting node). After receiving information from one or more core nodes 301, the adapting node may check the consistency between different sets of the received information. If the received information is consistent, the adapting node can be confident that the core node(s) and the second node(s) have returned correct information. This is particularly beneficial when the adapting node is connected to mining nodes that represent less than 51% of the hash power of the blockchain network 106, such as only a single mining node 104M.

[0144] The adaptive node may request the same information from the core node(s) 301 and the second node(s) 302. Alternatively, the adaptive node may request different but related information from different nodes 301, 302. For example, the adaptive node may request a block header or a Merkle root from the core node(s), and may request a transaction or a Merkle proof from the second node(s).

[0145] In some embodiments, the adaptive node may be configured to reconnect (i.e., reactivate) one or more of the disabled connections. For example, the adaptive node may determine that the network characteristics have returned to a normal state, e.g., there is no longer a load balancing problem (e.g., it may receive information from the nodes of LN300).

[0146] Conclusion It will be understood that the above embodiments are illustrative only. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided.

[0147] Statement 1. A computer-implemented method for connecting to a hierarchical network, the hierarchical network including a plurality of nodes arranged in a set of ordered layers, the set of ordered layers including, in order, a core layer including a set of core nodes, a second layer including a set of second nodes, and one or more outer layers each including a respective set of external nodes, each core node being connected to at least one other core node, the method being performed by a connecting node and including connecting to the network according to a connection protocol, the connection protocol requiring that each node must connect to at least one node in the preceding layer and that each external node must also connect to at least one core node.

[0148] The layers are ordered from the innermost layer (e.g., the core layer) to the outermost outer layer (e.g., one of the outer layers).

[0149] Statement 2. The method according to Statement 1, wherein one, some, or all of the core nodes are connected to two or more other core nodes.

[0150] Statement 3. The method according to Statement 2, wherein one, some, or all of the core nodes are connected to two or more other core nodes, but not all.

[0151] Statement 4. The connection protocol is the method according to any one of Statements 1 to 3, which requires that one, some, or each of the second nodes must be connected to two or more core nodes.

[0152] Statement 5. The connection protocol is the method according to Statement 4, which requires that one, some, or all of the second nodes must be connected to two or more core nodes, but not all.

[0153] Statement 6. The connection protocol is the method according to any of the preceding statements, which requires that one, some, or all of the second nodes must be connected to at least one other second node.

[0154] Statement 7. The connection protocol is the method according to Statement 6, which requires that one, some, or all of the second nodes must be connected to two or more other second nodes.

[0155] Statement 8. The connection protocol is the method according to any of the preceding statements, which requires that each external node of a given outer layer connected to each node of the preceding layer must be connected to at least one of the core nodes to which each node of the preceding layer is connected.

[0156] Statement 9. The connection protocol is the method described in Statement 8, which requires that each external node of a given outer layer connected to each node of the preceding layer must be connected to all of the core nodes to which each of those nodes of the preceding layer is connected.

[0157] Statement 10. The connection protocol is the method described in any of the preceding statements, which requires that one, some, or all of the outer layers must include at least one external node that is connected to at least one other external node of the same outer layer.

[0158] Statement 11. The connection protocol is the method described in Statement 10, which requires that one, some, or all of the outer layers must include at least one external node that is connected to two or more other external nodes of the same outer layer.

[0159] Statement 12. The connection protocol is the method described in Statement 10 or Statement 11, which requires that each external node of a given outer layer be connected to the same number of other external nodes of that outer layer.

[0160] Statement 13. The connection protocol is the method described in Statement 10 or Statement 11, which requires that at least one external node of a given outer layer be connected to a different number of other external nodes of that outer layer.

[0161] Statement 14. The number of nodes in each layer increases from the core layer to the outermost of the outer layers, according to the method described in any of the preceding statements.

[0162] Statement 15. One or more outer layers include a plurality of outer layers, and each external node of a given outer layer is connected to one or more external nodes of each of the first preceding layers that are inside the given outer layer. Each of the one or more external nodes of the first preceding layer is connected to one or more external nodes of each of the second preceding layers that are inside the first preceding layer. The connection protocol requires that one, some, or all of the external nodes of a given outer layer must be connected to at least one of the one or more external nodes of each of the second preceding layers to which the one or more external nodes of the first preceding layer are connected. The method described in any of the preceding statements.

[0163] Statement 16. The connection protocol requires that one, some, or all of the external nodes of a given outer layer must be connected to each of the one or more external nodes of each of the second preceding layers to which the one or more external nodes of the first preceding layer are connected. The method described in Statement 15.

[0164] Statement 17. The connection protocol requires that each external node of a given outer layer must be connected to at least one node of each preceding layer of the network. The method described in Statement 15 or Statement 16.

[0165] Statement 18. The core node includes a node of the blockchain network. The method described in any of the preceding statements.

[0166] The hierarchical network includes, in the core layer, a blockchain network or at least a part thereof. Each of the second nodes and the external nodes provides a service hierarchically around the blockchain network or at least around a part thereof.

[0167] Statement 19. Each core node is the method described in Statement 18, which is each blockchain node of the blockchain network.

[0168] Statement 20. Each core node is the method described in Statement 19, which is at least one of each mining node, each storage node, and each forwarding node of the blockchain network.

[0169] In an embodiment, each core node is a mining node and / or a storage node (e.g., a full copy node).

[0170] Statement 21. One, several, or all of the outermost outer layer's external nodes are the method described in any of the preceding statements, each including a respective end-user device.

[0171] Statement 22. A connection node is the method described in any of the preceding statements, which is any one of one of the core nodes, one of the second nodes, or one of the external nodes.

[0172] Statement 23. Each respective second node and / or external node is configured to send blockchain transactions to one, several, or all of the core nodes to which the respective second node is connected, according to the method described in any of the preceding statements.

[0173] Statement 24. Each respective external node is configured to send blockchain transactions to one, several, or all of the other external nodes in the same layer to which the respective external node is connected, according to the method described in Statement 10 or any statement subordinate thereto.

[0174] Statement 25. Each respective second node and / or external node is configured to request confirmation from one, several, or all of the core nodes to which the respective second node and / or external node is connected that a blockchain transaction has been accepted in a pool of transactions that have been validated according to a set of consensus rules of the blockchain network, in the manner described in Statement 19 or any statement subordinate thereto.

[0175] Statement 26. Each respective second node and / or external node is configured to request a Merkle proof of a transaction mined in a block of the blockchain from one, several, or all of the core nodes to which the respective second node and / or external node is connected, in the manner described in Statement 19 or any statement subordinate thereto.

[0176] Statement 27. Each block of the blockchain includes a block header, and each respective second node and / or external node is configured to request one or more block headers from one, several, or all of the core nodes to which the respective second node and / or external node is connected, in the manner described in Statement 19 or any statement subordinate thereto.

[0177] Statement 28. One, several, or all of the second nodes operate respective smart contract services, and the smart contract services are configured to execute a predetermined operation in response to and based on a blockchain transaction sent to the smart contract service by one of the external nodes, in the manner described in any of the preceding statements.

[0178] Statement 29. One, some, or all of the second nodes operate a distributed database, and each second node that operates the distributed database is configured to store data received from an external node connected to that second node, in accordance with any of the methods described in the preceding statements.

[0179] Statement 30. One, some, or all of the second nodes and / or external nodes are configured to identify each mining node in the core layer based on each mining identifier included in the coinbase transaction of the block mined by that respective mining node, in accordance with the method described in Statement 19 or any statement subordinate thereto.

[0180] Statement 31. One, some, or all of the nodes in the hierarchical network are associated with respective digital certificates, in accordance with any of the methods described in the preceding statements.

[0181] Statement 32. One, some, or all of the nodes in the network are configured to identify other nodes in the network based on the respective digital certificates associated with those nodes, in accordance with the method described in Statement 31.

[0182] Statement 33. The connection protocol requires that a given node connect only to nodes associated with respective digital certificates, in accordance with the method described in Statement 31 or Statement 32.

[0183] Statement 34. One, some, or all of the core nodes are configured to issue respective digital certificates to one or more respective second nodes connected to each core node, in accordance with any of the methods described in the preceding statements.

[0184] Statement 35. The method according to any of the preceding statements, wherein one, several, or all of the second nodes are each configured to issue a respective digital certificate to one or more respective external nodes of the first outer layer connected to each respective second node.

[0185] Statement 36. The method according to statement 35, wherein one, several, or all of the external nodes of the first outer layer are each configured to issue a respective digital certificate to one or more respective external nodes of the second outer layer connected to each respective external node of the first outer layer.

[0186] Statement 37. The method according to any of statements 34 to 36, wherein the connection protocol requires that each node can only connect to the nodes of the preceding layer that issued a digital certificate to that node.

[0187] Statement 38. The method according to statement 19 or any dependent claim thereto, wherein one, several, or all of the core nodes are each configured to send a set of transactions to at least one of the second nodes to which the core node is connected, the set of transactions including at least one of a set of transactions each including a specific protocol flag, a set of transactions each including a specific blockchain address, and / or a set of transactions each including a respective secondary consensus rule set indicated by each respective control branch of the transaction outputs.

[0188] Statement 39. The method according to statement 2, wherein one, several, or all of the core nodes are each connected to each of the other core nodes.

[0189] Statement 40. A computer device comprising a memory including one or more memory units, a processing device including one or more processing units, and a network interface including one or more network interface units, the memory storing code configured to be executed on the processing device, the code being configured to operate the computer device by executing the method described in any of the preceding statements when executed on the processing device.

[0190] Statement 41. A computer program embodied on a computer-readable storage and configured to execute the method described in any of Statements 1 to 39 when executed on one or more processors.

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

Claims

1. A computer-implemented method for connecting to a hierarchical network, wherein the hierarchical network includes a plurality of nodes arranged in an ordered set of layers, and the ordered set of layers includes, in order, a core layer including a set of core nodes, a second layer including a set of second nodes, and one or more outer layers each including a respective set of external nodes, each core node being connected to at least one other core node, and one, some, or all of the core nodes being connected to two or more other core nodes, not all, The method is executed by a connection node and includes connecting to the hierarchical network according to a connection protocol, the connection node being one of the core nodes, one of the second nodes, or one of the external nodes, and The connection protocol is that each node must be connected to at least one node in the preceding layer, and that each external node must also be connected to at least one core node, A method that requires this.

2. The method according to claim 1, wherein the connection protocol requires that one, some, or each of the second nodes must be connected to two or more core nodes.

3. The method according to claim 2, wherein the connection protocol requires that one, some, or all of the second nodes must be connected to two or more core nodes, not all.

4. The method according to any one of claims 1 to 3, wherein the connection protocol requires that one, some, or all of the second nodes must be connected to at least one other second node.

5. The connection protocol according to claim 4, wherein one, several, or all of the second nodes must be connected to two or more other second nodes. **Claim 6** The method according to any one of claims 1 to 5, wherein the connection protocol requires that each external node of a given outer layer connected to each node of the preceding layer be connected to at least one of the core nodes to which each of the nodes of the preceding layer is connected. **Claim 7** The method according to claim 6, wherein the connection protocol requires that each external node of a given outer layer connected to each of the nodes of the preceding layer be connected to all of the core nodes to which each of the nodes of the preceding layer is connected. **Claim 8** The method according to any one of claims 1 to 7, wherein the connection protocol requires that one, several, or all of the outer layers must include at least one external node that is not connected to at least one other external node of the same outer layer. **Claim 9** The method according to claim 8, wherein the connection protocol requires that one, several, or all of the outer layers must include at least one external node that is not connected to two or more other external nodes of the same outer layer. **Claim 10** The method according to any one of claims 1 to 9, wherein the number of nodes in each layer increases from the core layer towards the outermost of the outer layers. **Claim 11** The one or more outer layers include a plurality of outer layers, and each external node of a given outer layer is connected to one or more external nodes of each of the first preceding layers that are inside the given outer layer. Each of the one or more external nodes of the first preceding layer is connected to one or more external nodes of each of the second preceding layers that are inside the first preceding layer. The connection protocol requires that one, some, or all of the external nodes of the given outer layer must be connected to at least one of the one or more external nodes of each of the second preceding layers to which the one or more external nodes of the first preceding layer are connected. The method according to any one of claims 1 to 10.

12. The connection protocol requires that one, some, or all of the external nodes of the given outer layer must be connected to each of the one or more external nodes of each of the second preceding layers to which the one or more external nodes of the first preceding layer are connected. The method according to claim 11.

13. The connection protocol requires that each respective external node of a given outer layer must be connected to at least one node of each preceding layer of the hierarchical network. The method according to claim 11 or 12.

14. The core node includes a node of a blockchain network. The method according to any one of claims 1 to 13.

15. Each core node is a respective blockchain node of the blockchain network. The method according to claim 14.

16. Each core node is at least one of each mining node, each storage node, and each forwarding node of the blockchain network. The method according to claim 15.

17. The method according to any one of claims 1 to 16, wherein one, several, or all of the external nodes of the outermost outer layer each include a respective end-user device. **Claim 18** The method according to any one of claims 1 to 17, wherein each respective second node and / or external node is configured to send a blockchain transaction to one, several, or all of the core nodes to which the respective second node is connected. **Claim 19** The method according to claim 6, wherein each respective external node is configured to send a blockchain transaction to one, several, or all of the other external nodes of the same layer to which the respective external node is connected. **Claim 20** The method according to claim 15, wherein each respective second node and / or external node is configured to request confirmation that a blockchain transaction has been accepted in a pool of transactions that have been validated according to a set of consensus rules of the blockchain network, from one, several, or all of the core nodes to which the respective second node and / or external node is connected. **Claim 21** The method according to claim 15, wherein each respective second node and / or external node is configured to request a Merkle proof of a transaction mined in a block of the blockchain, from one, several, or all of the core nodes to which the respective second node and / or external node is connected. **Claim 22** The method according to claim 15, wherein each block of the blockchain includes a block header, and each respective second node and / or external node is configured to request one or more block headers from one, several, or all of the core nodes to which the respective second node and / or external node is connected.

23. One, several, or all of the second nodes operate respective smart contract services, and the smart contract services are configured to execute a predetermined operation in response to and based on a blockchain transaction transmitted to the smart contract service by one of the external nodes. The method according to any one of claims 1 to 22.

24. One, several, or all of the second nodes operate a distributed database, and each second node operating the distributed database is configured to store data received from an external node connected to that second node. The method according to any one of claims 1 to 23.

25. One, several, or all of the second nodes and / or external nodes are configured to identify each mining node of the core layer based on each mining identifier included in the coinbase transaction of the block mined by that respective mining node. The method according to claim 15.

26. One, several, or all of the nodes of the hierarchical network are associated with respective digital certificates. The method according to any one of claims 1 to 25.

27. One, several, or all of the nodes of the hierarchical network are configured to identify other nodes of the hierarchical network based on the respective digital certificates associated with that node. The method according to claim 26.

28. The connection protocol requires that a given node must only connect to nodes associated with respective digital certificates. The method according to claim 26 or 27.

29. One, several, or all of the core nodes are configured to issue respective digital certificates to each of the one or more respective second nodes connected to each core node, the method according to any one of claims 1 to 28.

30. One, several, or all of the second nodes are configured to issue respective digital certificates to each of the one or more respective external nodes of the first outer layer connected to each of the second nodes, the method according to any one of claims 1 to 29.

31. One, several, or all of the external nodes of the first outer layer are configured to issue respective digital certificates to each of the one or more respective external nodes of the second outer layer connected to each of the external nodes of the first outer layer, the method according to claim 30.

32. The connection protocol requires that each node can only connect to the nodes of the previous layer that issued digital certificates to that node, the method according to any one of claims 29 to 31.

33. One, several, or all of the core nodes are configured to send a set of transactions to at least one of the second nodes to which the core node is connected, the set of transactions comprising - a set of transactions each including a specific protocol flag, - a set of transactions each including a specific blockchain address, and / or - a set of transactions each including a respective secondary consensus rule set indicated by each control branch of the transaction output including at least one of the method according to claim 15.

34. A computer device, 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 comprising: The memory stores code configured to be executed on the processing device, and when the code is executed on the processing device, it is configured to operate the computer device by executing the method according to any one of claims 1 to 33. A computer device.

35. A computer program embodied on a computer-readable storage and configured to execute the method according to any one of claims 1 to 33 when executed on one or more processors.

Images