Multi-layer communication network

Abstract

1. A system including a hierarchical network, the hierarchical network including a plurality of LN nodes arranged in an ordered layer set, the ordered layer set including, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers including respective sets of intermediate nodes, and a device layer including a set of end devices, wherein each master node is configured to control a respective subset of the intermediate nodes, a first master node is configured to control the first subset of the intermediate nodes, a second master node is configured to control the second subset of the intermediate nodes, and each intermediate node is configured to control a respective subset of the end devices.

Description

Technical Field

[0001] The present disclosure relates to controlling devices in a hierarchical network using blockchain transactions.

Background Art

[0002] A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and widely published at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter also referred to as a "blockchain network"). A blockchain includes a chain of data blocks, and each block includes one or more transactions. Each transaction other than a so-called "coinbase transaction" points to a preceding transaction in the sequence. The sequence may span one or more blocks up to one or more coinbase transactions. Coinbase transactions are discussed below. Transactions submitted to a blockchain network are included in new blocks. New blocks are generated by a process known as "mining". "Mining" involves solving a cryptographic puzzle based on the presentation of a defined set of ordered and verified pending transactions waiting to be included in a new block of the blockchain, in which each of a plurality of nodes competes to perform "proof-of-work". It should be noted that the blockchain may be pruned at the nodes, and the publication of a block can be achieved through the publication of only the block header.

[0003] Transactions within a blockchain are used to perform one or more of the following: carry digital assets (i.e., a number of digital tokens), order a set of journal entries in a virtual ledger or registry, receive and process timestamp entries, and / or sequence index pointers. The blockchain can also be utilized to layer additional functionality on top of it. The blockchain protocol can be made to allow storing additional user data or indexes to the data within a transaction. There is no predefined limit on the maximum data capacity that can be stored within a single transaction. Thus, more complex data can be incorporated. For example, this can be used to store an electronic document, or audio or video data, within the blockchain.

[0004] Nodes in a blockchain network (sometimes referred to as "miners") perform the decentralized transaction registration and verification processes described below. That is, during this process, the nodes attempt to confirm the validity of the transactions, insert them into a block template, and identify a valid proof-of-work solution for them. When a valid solution is found, the new block is propagated to other nodes in the network, enabling each node to record the new block in the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The node that receives the transaction competes to find a proof-of-work solution and incorporates the validated transaction into a new block. Each node is configured to implement the same node protocol that includes one or more conditions for the transaction to be valid. Invalid transactions are not propagated and are not incorporated into blocks. Assuming that a transaction is verified and thereby accepted into the blockchain, the transaction (including any user data) remains registered and indexed at each node in the blockchain network as an immutable public record.

[0005] Nodes that succeed in solving the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction called a "coinbase transaction" that creates a new quantity of digital assets, i.e., the number of tokens. The detection and rejection of invalid transactions are carried out by the actions of competing nodes that are incentivized to act as agents of the network and report and prevent wrongdoing. Through the extensive public disclosure of information, users can continuously audit the performance of the nodes. By simply publishing the block headers, participants can ensure the current integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies an amount of digital assets derivable from a preceding transaction sequence. Spendable outputs are sometimes called UTXOs (unspent transaction outputs). An output may further include a lock script that specifies conditions for future redemption of the output. A lock script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output within a preceding transaction, and may further include an unlock script for unlocking the lock script of the pointed-to output. Thus, when considering a pair of transactions, they are referred to as the first transaction and the second transaction (or “target” transaction). The first transaction includes at least one output that specifies an 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 an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to a blockchain network where it is propagated and recorded on the blockchain, one of the criteria for validity applied at each node is that the unlock script satisfies all of 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 repaid by another previous valid transaction. Any node that determines that the target transaction is invalid according to any of these conditions will not propagate the transaction (as a valid transaction) (but may record the invalid transaction) and will not include it in a new block for recording on the blockchain.

Summary of the Invention

[0008] The Internet of Things (IoT) technology enables a network of physical devices to exchange data and monitor events without human intervention. Motivating the development of IoT technology is the need for real-time data collection and automatic control mechanisms to replace traditional monitoring and control methods across a wide range of industries. IoT systems generate vast amounts of data and rely on systems with network scalability, strong cybersecurity, reliable connectivity, and minimal network latency.

[0009] Traditional IoT devices typically have a single master node or device that issues commands to other nodes or devices on the network. For example, an IoT network may have a network topology designed such that a master node can monitor activities including communication between all nodes within a hierarchical structure across the network. However, a single master node introduces a single-point-of-failure. For example, the failure of the master node prevents the master node from issuing and receiving transactions and prevents the rest of the network from being monitored and / or controlled. Therefore, it is desirable to avoid this single-point-of-failure.

[0010] According to one aspect disclosed herein, a computer-implemented method for controlling devices in a hierarchical network using blockchain transactions, wherein the hierarchical network (LN) includes a plurality of LN nodes configured in an ordered layer set, the ordered layer set including, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers each including an intermediate node set, and a device layer including an end device set, each master node being configured to control each intermediate node subset, a first master node being configured to control a first intermediate node subset, a second master node being configured to control a second intermediate node subset, each intermediate node being configured to control each end device subset, the method being executed by a first master node, identifying, by the second master node, one or more problems affecting control of at least one of the second intermediate node subset; in response, issuing, to the at least one node of the second intermediate node set, each command transaction for controlling the node; A method is provided that includes the above.

[0011] A node of the network (hereinafter referred to as an IoT node) operates as a bridge between a hierarchical network (e.g., an IoT network) and a blockchain network. That is, the IoT node of the hierarchical network is part of the IoT network and can form a connection to a blockchain node of the blockchain network. Thereby, the IoT node can connect to the IoT network (e.g., to communicate with other IoT nodes and devices) and to the blockchain network (e.g., to send transactions to the blockchain node and to obtain transactions published on the blockchain). In some examples, one or more of the devices of the hierarchical network can also connect to a blockchain node of the blockchain network.

[0012] The IoT nodes of the hierarchical network cooperate to operate a decentralized IoT communication protocol using blockchain transactions. The blockchain network enables a high-capacity and low-fee microtransaction throughput. Thereby, IoT nodes and devices can be connected globally in a reliable way while communicating at a minimal cost. By combining multiple levels of control hierarchy and a blockchain-based communication protocol, the requirements and communication protocol provide large-scale communication using low-fee microtransactions, integration of value transfer and control into one platform, low barriers for IoT network devices to enter, secure storage of IoT communication data with timestamps, and IoT data accessible for auditing and performance monitoring.

[0013] The hierarchical network includes at least two independent master IoT nodes. This configuration removes single points of failure within the IoT network by distributing the amount of control that a single master IoT node has. Each master IoT node is responsible for each subset of the IoT network under normal operating conditions. That is, each master IoT node is configured to primarily control each set of intermediate IoT nodes and thus each subset of end devices. According to the present invention, when a defect in a master IoT node is detected, another master IoT node operates as a backup and takes over the control of the intermediate IoT node subset of the defective master IoT node.

[0014] According to one aspect disclosed in the present specification, a system including a hierarchical network, wherein the hierarchical network includes a plurality of LN nodes configured in an ordered layer set, and the ordered layer set includes, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers each including a set of intermediate nodes, and a device layer including a set of end devices, each master node is configured to control each subset of intermediate nodes, a first master node is configured to control a first subset of intermediate nodes, a second master node is configured to control a second subset of intermediate nodes, and each intermediate node is configured to control each subset of end devices.

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Mode for Carrying Out the Invention

[0016] Overview of an exemplary system FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet switching network 101, which is typically a wide area Internet network such as the Internet. The packet switching network 101 includes a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet switching network 101. Although not shown, the blockchain nodes 104 may be arranged as an almost complete graph. Each blockchain node 104 is thus highly coupled to other blockchain nodes 104.

[0017] Each blockchain node 104 includes a peer's computer device having different nodes 104 among the nodes 104 belonging to different peers. Each blockchain 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 other devices such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). Each node also includes a memory, i.e., a computer-readable storage device in the form of a non-transitory computer-readable medium. The memory may include one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or one or more memory units using optical media such as optical disk drives.

[0018] 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 104 within a distributed or blockchain network 160. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block headers (described below) of each block 151. Each block 151 within the chain includes one or more transactions 152, and in this context, a transaction represents 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 uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents an amount of digital assets as an asset. In this example, the output is cryptographically locked to user 103 (requiring that user's signature or other solution to unlock and thereby redeem or use). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0019] Each block 151 also includes a block pointer 155 that points back to previously generated blocks 151 in the chain so as to define a sequential order to the blocks 151. Each transaction 152 (other than the coinbase transaction) includes a pointer to the previous transaction in order to define an order to the sequence of transactions (note that the sequence of transactions 152 is permitted to branch). The chain of blocks 151 goes back to the genesis block (Gb) 153 that was the first block in the chain. One or more original transactions 152 at the beginning of the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0020] Each of the blockchain nodes 104 is configured to transfer a transaction 152 to other blockchain nodes 104, thereby propagating the transaction 152 across the network 106. Each blockchain node 104 is configured to generate a block 151 and store a copy of each of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 that are waiting to be incorporated into a block 151. The ordered set 154 is sometimes referred to as a "mempool". This term is not limited to any particular blockchain, protocol, or model in this specification. It represents an ordered set of transactions that the node 104 has accepted as valid and is obligated not to accept other transactions that attempt to use the same outputs.

[0021] In a given current transaction 152j, the input (or each of them) includes a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the current transaction 152j. Generally, the previous transaction can be any transaction within the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist when the current transaction 152j is generated or transmitted to the network 106, but the previous transaction 152i needs to exist and be verified for the current transaction to be valid. Thus, as used herein, "previous" refers to what is previous in the logical sequence linked by the pointer and does not necessarily represent the time of generation or transmission in chronological order. Thus, it does not necessarily exclude that transactions 152i, 152j are generated or transmitted out of order (see the discussion below regarding orphan transactions without parents). The previous transaction 152i can equally be referred to as an antecedent or predecessor transaction.

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

[0023] According to the output-based transaction protocol such as Bitcoin, when an entity 103 such as a user or a machine wants to act on a new transaction 152j, the entity sends the new transaction from its computer terminal 102 to the receiving side. Eventually, the entity or the receiving side sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which are, today, typically servers or data centers, but in principle other user terminals are also possible). In some examples, it is not excluded that the entity 103 acting on the new transaction 152j can send the transaction to one or more of the blockchain nodes 104 instead of the receiving side. The blockchain node 104 that receives the transaction checks whether the transaction is valid according to the blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such an output-based transaction protocol, this may include checking that the cryptographic signature or other authentication of the entity 103 included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152j assigned by the new transaction, which typically includes at least checking that the cryptographic signature or other authentication in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The conditions may be at least partially defined by a script included in the output of the previous transaction 152i. Alternatively, it can be fixed only by the blockchain node protocol, or by a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 transfers the new transaction to one or more other blockchain nodes 104 within the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same node protocol, transfer 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 blockchain nodes 104.

[0024] In an output-based model, the definition of whether a given allocated output (e.g., UTXO) can be allocated is whether it has already been validly redeemed by the input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of a preceding transaction 152i that it attempts to allocate or redeem has not yet been allocated / redeemed by another transaction. Again, if not valid, the transaction 152j is not propagated or recorded on the blockchain 150 (unless flagged as invalid and propagated for modification). This prevents double-spending where a trader attempts to allocate the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, since the order of transactions is defined, the account balance has a single defined state at any one time.

[0025] In addition to the verification transaction, blockchain node 104 also competes to initially create a block of transactions in a process called mining, which is supported by "proof-of-work". In blockchain node 104, a new transaction is added to the ordered set 154 of valid transactions that have not yet appeared in block 151 recorded in blockchain 150. The blockchain node then competes to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. This typically involves searching for a "nonce" value such that when the nonce is concatenated with the representation of the ordered set 154 of transactions and hashed, the output of the hash meets a predetermined condition. For example, the predetermined condition may be that the output of the hash has a predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle and other types are not excluded. The characteristic of a hash function is to have an output that is unpredictable with respect to the input. Therefore, this search can only be performed by brute force and thus consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0026] The first blockchain node 104 that solves the puzzle notifies this to the network 106 and provides the solution as proof. This solution can be easily checked by other blockchain nodes 104 within the network (if a solution to a hash is given, it is easy to confirm that the output of the hash meets the conditions). The first blockchain node 104 propagates the block to the agreement of other nodes at the threshold for accepting the block, and thus enforces the protocol rules. The ordered set of transactions 154 will then be recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. Also, a block pointer 155 is assigned to the new block 151n to point to the previously created block 151n-1 in the chain. A significant amount of effort, for example in the form of hashes, required to generate the proof-of-work solution signals the intention of the first IoT node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, or what is known as double spending. Once generated, the block 151 is recognized and maintained at each of the blockchain nodes 104 within the blockchain network 106 and thus cannot be modified. Also, the block pointer 155 imposes an order on the blocks 151. The transactions 152 are recorded in the ordered blocks at each blockchain node 104 within the network 106, which provides an immutable public ledger of the transactions.

[0027] The different blockchain nodes 104 that are constantly competing to solve the puzzle may start looking for a solution at any time, or may be solving the puzzle based on different snapshots of the ordered set 154 of transactions that are still not yet published, depending on the order in which the transactions were received. Note that whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, and in that order, the current set 154 of unpublished transactions is updated. Then, the blockchain nodes 104 continue to compete to create a block from the newly defined current ordered set 154 of unpublished transactions. There is also a protocol for resolving possible "forks". This is the case when two blockchain nodes 104 solve the puzzle within a very short time of each other, and conflicting views of the blockchain propagate between the nodes 104. In short, whenever a fork occurs, the longest one always becomes the final blockchain 150. Note that this does not affect the users or agents of the network because the same transactions appear in both branches.

[0028] According to the Bitcoin blockchain (and most other blockchains), a node that has successfully constructed a new block 104 is given the ability to allocate the approved amount of digital assets within a new special type of transaction that distributes a certain quantity of digital assets (different from an agent - to - agent or user - to - user transaction that transfers an amount of digital assets from one agent or user to another agent or user). This special type of transaction is usually called a "coinbase transaction", but may also be called an "initiation transaction". It forms the first transaction of the new block 151n in the standard. Proof - of - work signals that the node that constructed the new block intends to follow the protocol rules so that this special transaction can be redeemed later. The blockchain protocol rules may require an expiration, for example 100 blocks, before this special transaction can be redeemed. A normal (non - generation) transaction 152 often specifies an additional transaction fee in one of its outputs, which further rewards the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is usually called the "transaction fee" and will be described later.

[0029] For the resources related to transaction validity verification and publication, typically, each of at least the blockchain nodes 104 takes the form of a server that includes one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals network - connected to each other.

[0030] The memory of each blockchain node 104 stores software configured to operate on the processing device of the blockchain node 104 to perform each of one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be appreciated that any operations belonging to the blockchain node 104 can be performed by software executed on the processing device of each computer device. The node software may 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.

[0031] Also connected to the network 101 are the computer devices 102 of each of a plurality of parties 103 that act as consumer users. These users can interact with the blockchain network but do not participate in validating, constructing, or propagating transactions and blocks. Some of these users or agents may act as senders and receivers in a transaction. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities (e.g., having obtained a copy of the blockchain from a blockchain node 104) that store a copy of the blockchain 150.

[0032] Some or all of Party 103 may be coupled as a portion of a network overlaid on a different network, such as blockchain network 106. Users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network. However, since these users do not perform the required role of a blockchain node, they are not blockchain nodes 104. Instead, each Party 103 may interact with blockchain network 106 and thereby utilize blockchain 150 by coupling to (i.e., communicating with) blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes and are the first party 103a and its respective computer devices 102a, and the second party 103b and its respective computer devices 102b. It will be understood that more such parties 103 and their respective computer devices 102 can exist in and participate in system 100, but for simplicity they are not shown. Each Party 103 may be an individual or an organization. By way of pure 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 references to Alice or Bob herein can each be replaced with "first party" and "second party", respectively.

[0033] The computer device 102 of each party 103 includes each processing device having one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 further includes a memory, that is, a non-transitory computer-readable medium or a computer-readable storage device in the form of a medium. This memory can include one or more memory units using one or more memory media, such as magnetic media like hard disks, SSDs, electronic media like flash memory or EEPROM, and / or optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software including each instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any action attributed to party 103 given herein can be executed using software executed on the processing device of each 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 like a smartwatch. The computer device 102 of a given party 103 may include one or more other networked resources, such as cloud computing resources accessed via the user terminal.

[0034] The client application 105 can first be provided to the computer device 102 of any given party 103 on one or more suitable computer-readable storage media, such as those downloaded from a server, or removable storage devices such as removable SSDs, flash memory keys, removable EEPROMs, removable magnetic disk drives, magnetic floppy disks or tapes, optical disks such as CDs or DVD ROMs, or removable optical drives.

[0035] The client application 105 includes at least a "wallet" function. This mainly has two functions. One of these is to enable each party 103 to create, authorize (e.g., sign), and send transactions 152 to be included in the blockchain 150 by being propagated across the network of blockchain nodes 104. The other is to report to each party the amount of digital assets currently owned. In an output-based system, this second function involves collating the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0036] Note: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead, any client function described herein may be implemented in a suite of two or more different applications, for example, interfacing via an API or one being a plugin to the other. More generally, client functions may be implemented at the application layer, or a lower layer such as an operating system, or any combination thereof. The following is described from the perspective of the client application 105, but it is understood that this is not limiting.

[0037] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. Thereby, the wallet function of the client 105 can send a transaction 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 about any transaction for which each party 103 is the receiving party (or, in an embodiment, since the blockchain 150 is a public facility that provides trust for transactions through its public visibility, actually inspect the transactions of other parties within the blockchain 150). The wallet function on each computer device 102 is configured to form and send a transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to transfer a transaction 152 to validate the transaction 152 according to a blockchain node protocol and propagate the transaction 152 across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model with a given node protocol. The same transaction protocol is used for all transactions 152 within the blockchain 150. The same node protocol is used for all nodes 104 within the network 106.

[0038] If a given party 103, e.g., Alice, wishes to send a new transaction 152j included in the blockchain 150, she formulates a new transaction according to the relevant transaction protocol (using the wallet function of her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective roles. This includes first checking whether the newly received transaction 152j meets certain conditions for it to be "valid", examples of which will be briefly elaborated below. In some transaction protocols, the conditions for validity verification 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 may be defined by a combination of the script and the node protocol.

[0039] On the condition that the newly received transaction 152j passes the test of being considered valid (i.e., under the condition of being "valid"), any blockchain node 104 that receives the transaction 152j adds the new verified transaction 152 to the ordered set 154 of the blockchain maintained by that blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j propagates the verified transaction 152 to one or more other blockchain nodes 104 within the network 106. Since each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means it will soon be propagated throughout the network 106.

[0040] When placed into the ordered set 154 of transactions maintained at a given blockchain node 104, that blockchain node 104 initiates a competition to solve a proof-of-work puzzle for the latest version of their respective ordered set of transactions that includes the new transaction 152. (Other blockchain nodes 104 are trying to solve the puzzle based on different ordered sets 154 of transactions, but note that whoever is first defines the ordered set of transactions included in the latest block 151. Eventually, blockchain node 104 will solve the puzzle for the part of the ordered set 154 that includes Alice's transaction 152j.). Once proof-of-work is done for the ordered set 154 that includes the new transaction 152j, it becomes part of one of the blocks 151 within the blockchain 150 in an immutable way. Since each transaction 152 includes a pointer to a previous transaction, the order of the transactions is also immutably recorded.

[0041] Different blockchain nodes 104 may first receive different instances of a given transaction and thus may have conflicting views as to which instance is "valid" before one instance is published (Publishing) into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance is recorded in the blockchain 150, that blockchain node 104 must accept this and discard (i.e., treat as invalid) the first instance it accepted (i.e., the one not yet published in a block 151).

[0042] As part of an account-based transaction model, another type of transaction protocol used by some blockchain networks may be referred to as an "account-based" protocol. In the case of an account-based system, each transaction is transferred by referring to the absolute account balance, rather than defining the amount transferred by referring back to the UTXOs of previous transactions in a series of past transactions. The current state of all accounts is stored and continuously updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using a sequential transaction record of the account (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also be signed with the transaction. This data field can point back to previous transactions, for example, if the previous transaction ID is included in the data field.

[0043] UTXO-based model Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO" - based protocol. However, this is not limited to all possible embodiments. The exemplary UTXO-based protocol is described with reference to Bitcoin, but note that it can be equally implemented on other exemplary blockchain networks.

[0044] 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 inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value that specifies the amount of the digital asset. This represents the set number of tokens on the distributed ledger. Also, among other information, the UTXO may also include the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include an indicator of the sizes of the input field 202 and the output field 203. The header 201 may also include 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 unprocessed transaction 152 submitted to the node 104.

[0045] For example, suppose Alice 103a wants to create a transaction 152j that transfers an amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". This incorporates the amount of the digital asset locked to Alice into the output 203 of a preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. These do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the transaction immediately following the pool 154. Tx1 can refer to any of the preceding (i.e., ancestor) transactions that still have an unspent output 203 locked to Alice.

[0046] The preceding transaction Tx0 may already be verified and included in block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least when she sends it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting within the ordered set 154, in which case it will be included in the new block 151 shortly. Alternatively, Tx0 and Tx1 can be generated and sent to the network 106, or Tx0 can be sent after Tx1 if the node protocol allows buffering of "orphan" transactions. The terms "preceding" and "subsequent" as used in the context of the transaction sequence refer to the order of the transactions within the sequence as defined by the transaction pointers specified within the transaction (such as which transaction refers to which other transaction). They can be equivalently replaced by "preceding" and "successive" or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily mean the order in which they are created, sent to the network 106, or reach any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that refers to a preceding transaction (ancestor transaction or "parent") is not verified unless the parent transaction is verified. A child that arrives at the blockchain node 104 before the parent is considered an orphan. It may be discarded, buffered for a certain time, or buffered depending on the node protocol and / or the behavior of the node while waiting for the parent.

[0047] One of the one or more outputs 203 of the preceding transaction Tx0 includes a specific UTXO labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a lock script defining conditions that must be satisfied by an unlock script in the inputs 202 of a subsequent transaction in order for the subsequent transaction to be verified and thus for the UTXO to be properly redeemed. Typically, the lock script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the lock script standardly defines unlocking conditions such as: the unlock script within the input of a subsequent transaction includes the cryptographic signature of the party to which the preceding transaction was locked.

[0048] The lock script (also known as scriptPubKey) is part of the code written in a domain-specific language recognized by the node protocol. A particular example of such a language is what is called "Script" (with a capital S) used by the blockchain network. The lock script specifies the information necessary to consume the transaction output 203, e.g., the requirements for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (also known as: scriptSig) is part of the code written in a domain-specific language that provides the information necessary to meet the criteria of the lock script. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0049] In the illustrated example, the UTXO0 of the output 203 of Tx0 includes the lock script [ChecksigP A , which requires Alice's signature SigP A for the UTXO0 to be redeemed (strictly speaking, for the subsequent transaction attempting to redeem UTXO0 to be valid). [Checksig P Ais the public key P from Alice's public-private key pair A includes a representation (i.e., a hash) of A . The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0 which in an embodiment is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 in order to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlock script that includes Alice's cryptographic signature created by applying Alice's private key from the key pair to a predetermined portion of the data (sometimes called the "message" in cryptography). <sigpa>It includes. The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0050] When the new transaction Tx1 arrives at the blockchain 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 in the lock script (this condition can include one or more criteria). In an embodiment, this includes concatenating the two scripts.

Number

[0051] The details of authentication by public - private cryptography will be well - known to those skilled in the art. Basically, when Alice signs a message using her private key, if Alice's public key and the message are in plaintext, another entity such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the message with this as the signature, which enables the owner of the public key to authenticate the signature. Thus, in embodiments, a reference to signing a particular piece of data or part of a transaction, etc., may mean signing the hash of the piece of data or part of the transaction.

[0052] If the unlock script within Tx1 meets one or more conditions specified by the lock script of Tx0 (in the example shown, if Alice's signature is provided and authenticated within Tx1), the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 adds Tx1 to the ordered set of transactions 154. The blockchain node 104 forwards the transaction Tx1 to one or more other blockchain nodes 104 within the network 106, whereby it will be broadcast throughout the network 106. Once Tx1 is verified and included in the blockchain 150, this is defined as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been used (whether it has already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose the order defined in the transactions 152. In practice, a given blockchain node 104 can maintain a separate database that marks the UTXO203 consumed by the transaction 152, but ultimately, it is whether a valid input to another valid transaction within the blockchain 150 has already been formed that defines whether the UTXO has been consumed.

[0053] If the total amount specified among all the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, this is another basis for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in the block 151.

[0054] Note that in a UTXO-based transaction model, it is necessary to use a given UTXO as a whole. Of the amount defined by the UTXO, while another portion is being consumed, it is not possible to "leave a portion behind". However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined by UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Therefore, if Alice does not wish to give all of the amount defined by UTXO0 to Bob, she can use the remaining amount to give herself change within the second output of Tx1 or pay another party.

[0055] In particular, Alice usually needs to include a transaction fee for the Bitcoin node 104 that publishes her transaction. If Alice does not include a fee for the miner, Tx0 is likely to be rejected by the miner's blockchain node 104, and thus, although technically valid, it will still not be propagated and will not be included in the blockchain 150 (the node protocol does not force the blockchain node 104 to accept transaction 152 if they do not want to). In some protocols, the transaction fee does not require a separate, distinct output 203 (i.e., does not require a separate UTXO). Instead, the difference between the total amount indicated by the input 202 and the total amount specified by the outputs 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. 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 the digital asset specified by UTXO0 is more than the amount specified by UTXO1, that difference may be allocated by the node 104 that publishes the block containing UTXO1. However, alternatively or additionally, it is not excluded that the transaction fee can be explicitly specified, necessarily in a separate one of the UTXOs 203 of transaction 152.

[0056] The digital assets of Alice and Bob consist of UTXOs locked to them within any transaction 152 in blockchain 150. Thus, typically, the assets of a given party 103 are dispersed across all the UTXOs of various transactions 152 through blockchain 150. Nowhere within blockchain 150 is there stored a single numerical value that defines the total balance of a given party 103. It is the role of the wallet function in client application 105 to sum up the values of all the various UTXOs locked to each party and not yet used in some other onward transaction. This can be done by querying a copy of blockchain 150 stored in any of the Bitcoin nodes 104.

[0057] Note that the script code is often expressed in a schematic way (i.e., not using exact language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_...." represents a specific opcode of the script language. As an example, OP_RETURN is an opcode of the script language for generating an unusable output of a transaction that can store data within the transaction when preceded by OP_FALSE at the start of the lock script, thereby immutably recording the data on blockchain 150. For example, the data can include a document that is desired to be stored on the blockchain.

[0058] Standardly, the input of a transaction is the public key P A It includes a digital signature corresponding thereto. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs part of the transaction input and all or part of the transaction output. The specific part of the output to be signed depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of the signature and selects which output is signed (and thus is fixed at the time of signing).

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

[0060] As shown in FIG. 1, the client applications in each of the computer devices 102a and 120b of Alice and Bob may have additional communication functions. This additional function enables Alice 103a to establish a separate side channel 301 with Bob 103b (either by the invitation of any party or a third party). The side channel 301 enables the exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without being registered on the blockchain network 106 or proceeding on the chain 150 until one of the parties chooses to broadcast the transaction 152 to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 301 may be used to exchange data related to any other transaction, such as keys, negotiated amounts or terms, data content, etc.

[0061] Side channel 301 may be established via the same packet-switched network 101 as blockchain network 106. Alternatively or additionally, side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or a direct wired or wireless link between the devices 102a, 102b of Alice and Bob. Generally, the side channel 301 referred to anywhere in this specification is "off-chain", that is, it may include any one or more links via one or more networking technologies or communication media for exchanging data separately from blockchain network 106. When more than one link is used, a bundle or set of off-chain links as a whole may be referred to as side channel 301. Thus, note that when it is said that Alice and Bob exchange certain information or data pieces etc. via side channel 301, this does not necessarily mean that all of these data pieces need to be transmitted via exactly the same link or the same type of network.

[0062] The Internet of Things IoT is an extension of the Internet to everyday physical devices and objects. When equipped with computing processing capabilities and Internet connectivity, devices can communicate and interact with each other and can be remotely monitored and controlled. Over time, the definition of IoT evolves with the convergence of machine learning, real-time analytics and multiple technologies, but it is generally accepted that a system of devices capable of supporting wireless sensor networks and / or control systems may enable IoT.

[0063] IoT systems are facing several problems. For example, the scalability and cost of such systems can prevent IoT systems from reaching their full potential. When coupled and controlled in a centralized manner, IoT devices require a backend infrastructure to send data and receive control commands. These backend infrastructures are hosted on third-party cloud services or on-premises owned server farms. The scalability of IoT solutions is determined by the scalability of the backend servers and data centers, which leads to prohibitively high operating costs for IoT service providers. As a result, many proposed IoT solutions are cost-ineffective and not suitable for use in daily scenarios. Performance measurements such as network latency are also important factors in determining the rate of IoT adoption.

[0064] Another problem that IoT systems face is the trade-off between automation and control. IoT solutions are designed to enable remote access and control of everyday electronic devices. Most IoT solutions strike a balance between full user control and automated communication between devices and other IoT solution components. In the event of a failure of either the device or the IoT system, safety measures such as override mechanisms need to be taken.

[0065] Another problem is the threat of cyberattacks. By enabling the automatic control of devices via the Internet, users are exposing themselves to security risks. This comes in two forms. One is the privacy risk caused by transmitting IoT device metadata over the Internet. For example, if a eavesdropper gains access to data from a device such as a household appliance, the pattern of device usage could be used by a criminal, e.g., a trespasser with illegal intent, to predict when someone is at home. The second risk is the possibility that an attacker or third party could gain control of an IoT device. In the case of critical control software used to operate heavy machinery or dangerous goods, an attack could have tragic consequences.

[0066] IoT systems can be designed to be centralized or decentralized and / or hybrid. Centralized solutions suffer from bottlenecks, but allow for faster and more reliable control by privileged components within the IoT system. Decentralized state reporting makes IoT solutions more scalable. Edge computing helps reduce network latency for critical applications, reduce dependence on the cloud for IoT systems, and provide good management of large amounts of IoT data. The emergence of decentralized processing highlights the opportunity in system architecture to leverage the advantages of both centralized and distributed architectures. A hybrid system that combines centralized and distributed systems within a hierarchical control structure can improve the user's safety and usability objectives.

[0067] Figure 3 shows an exemplary system 300 for implementing an embodiment of the present disclosure. The exemplary system 300 includes a first network of one or more devices (i.e., computing devices) 302 and one or more IoT nodes 303 (i.e., computing devices that execute the blockchain client application 105 and thus can form a first network over the blockchain network 106). For clarity, the first network is also referred to as an IoT network, i.e., a network of computing devices interconnected by the Internet. Usually, the end devices 302 and the IoT nodes 303 are implemented in everyday devices. The end devices 302 can take various forms, such as, for example, user devices (e.g., smart TVs, smart speakers, toys, wearables, etc.), smart home appliances (e.g., refrigerators, washing machines, ovens, etc.), meters or sensors (e.g., smart thermostats, smart lighting fixtures, security sensors, etc.). Similarly, the IoT nodes 303 can take various forms including, but not limited to, the same forms that the end devices can take. The IoT nodes 303 can take the form of dedicated server equipment, base stations, access points, routers, etc. In some examples, each device may have a fixed network (e.g., IP) address. For example, one, some, or all of the end devices may be fixed devices (e.g., smart lighting fixtures, or smart central heating control, etc.) as opposed to mobile devices.

[0068] The IoT network is a packet - switched network 101, typically a wide - area Internet network such as the Internet. The IoT nodes 303 and devices 302 of the packet - switched network 101 are configured to form an overlay network within the packet - switched network 101. Each node 303 includes each computer device that includes one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application - specific processors, and / or field - programmable gate arrays (FPGAs). Each IoT node 303 also includes a memory, that is, a non - transitory computer - readable medium or a computer - readable storage device in the form of a medium. The memory may include one or more memory units that use one or more memory media, such as magnetic media like hard disks, solid - state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disk drives.

[0069] Each IoT node 303 of the IoT network operates a blockchain client application 105. Each IoT node 303 of the IoT network is configured to control the end device 302 either directly or indirectly. An IoT node 303 directly coupled to the end device 302 can directly control the device. An IoT node 303 not directly coupled to the end device 302 can only indirectly control the device, for example, by transferring a control message to the end device via one or more intermediate IoT nodes. Each IoT node 303 is coupled to one or more blockchain nodes 104.

[0070] Figure 3 also shows a network 304 of blockchain nodes 104, which is a subset of the blockchain network 106.

[0071] As shown in FIG. 3, the IoT node 303 forms a part of both the IoT network and the blockchain network 106. On the other hand, the blockchain node 104 forms only a part of the blockchain network 106. Although the end device 302 is shown in FIG. 3 as forming only a part of the IoT network, it is not excluded that the end device 302 can be coupled to the blockchain node 104.

[0072] FIG. 4 shows an exemplary IoT network topology. The IoT network may control a set 401 of one or more of the master IoT nodes 303a, intermediate IoT nodes 303b, 303c, and a set of end devices 302. The master IoT node 303a is configured to control one or more intermediate IoT nodes 303b, 303c. If the IoT network includes multiple sets (e.g., layers) 401a, 401b of intermediate IoT nodes, the master IoT node 303a is configured to directly control a first set (layer) 601a of intermediate IoT nodes (e.g., the layer of “server nodes” 303b) and indirectly control one or more further sets (layers) 401 of intermediate IoT nodes (e.g., the layer of “slave nodes” 303c). The master IoT node 303a has the ability (i.e., permission) to override and control the server and slave nodes. Each server node 303b has the ability to control the slave nodes 303c. Each slave node 303c is a node under the control of the slave node 303b and the master IoT node 303a. As an example, to instruct the end device 302a, the master IoT node 303a issues a command to the slave node 303c via the vassal node 303b.

[0073] The exemplary IoT network of FIG. 4 shows only two layers of intermediate IoT nodes 303 (server nodes and slave nodes), but other examples may include one or more additional sets of intermediate IoT nodes, for example, between master IoT node 303a and server node 303b and / or between server node 303b and slave node 303c. As shown, each IoT node is coupled to one or more other nodes via respective couplings 402, and each end device 302 is coupled to one or more slave nodes via respective couplings 402. One or more nodes (e.g., the master IoT node) are hereinafter referred to as control nodes.

[0074] IoT network nodes 303 may correspond to a hierarchy in terms of function scope, command / privilege superiority, and / or access scope. In some implementations, the hierarchical set of SPV nodes implements an "IoT control unit" and has three hierarchical levels corresponding to the master 303a, server 303b, and slave 303c of FIGS. 3 and 4. The master IoT node 303a instructs one or more server nodes 303b, and each server node instructs one or more slave nodes 303c. Each slave node 303c receives instructions from one or more server nodes 303b. Each slave node 303c communicates with one or more IoT devices 302, which are direct communication channels between the IoT control unit 303 and the IoT end device 302. The execution state of the IoT control unit 303 is recorded in the blockchain transaction Tx. Each IoT node, i.e., master, server, or slave, has the ability to generate a corresponding transaction Tx and broadcast it to the blockchain network 106. Each slave node monitors trigger and / or confirmation signals from the end device 302, and all IoT nodes 303 have the ability to interact with any other IoT node to execute all the logic of the IoT control unit.

[0075] The master IoT node, the server node, and the slave node can each be independently connected to the nodes on the blockchain network 106 and operate the blockchain client application 105. The master IoT node 303a is configured to monitor the activities of other IoT nodes directly and indirectly under its control, issue commands to these other IoT nodes in the form of blockchain transactions Tx, and respond to warnings. The server node 303b is configured to monitor a plurality of addresses including addresses not directly controlled by the server node 303b. The server node 303b can be instructed by the master IoT node 303a to execute an action. The slave node 303c is configured to monitor the activities of the end device 302 under its control. The slave node 303c is under the direct command of the server node 303b and can also be instructed by the master IoT node 303a to execute an action. The slave node 303c operates as a gateway node with respect to the end device 302 (i.e., a gateway between the end device and the blockchain network 106). The end device 302 is configured to connect to a nearby slave node. They report on the end device state using an off-chain message protocol.

[0076] The IoT node 303 and the end device 302 are distinguished in that the end device 302 is controlled by the IoT node 303 but does not control the IoT node 303 itself, but note that the end device 302 can also be connected to the blockchain node 104 of the blockchain network 106. That is, in some examples, the end device 302 may operate the blockchain client application 105.

[0077] The IoT network balances between centralization and decentralization by using the blockchain network infrastructure to combine the command and control hierarchical structure. Users of the network can generate their own multi-level control hierarchical structure, including client-server and peer-to-peer relationships between devices. The network architecture includes two layers: the IoT network and the blockchain network 104. The blockchain network 106 operates as a backend infrastructure and there is an overlap between the IoT network and the blockchain network 106.

[0078] Request and response protocol The IoT nodes 303 of the IoT network 303 may operate according to a communication protocol. Here, the IoT nodes 303 use blockchain transactions Tx to issue command requests, command the devices based on those command requests, and issue command confirmation responses. Although embodiments are described with respect to the IoT network, generally, the teachings of the present disclosure can be applied to any network including network entities 303 that operate a blockchain client application 105 and end devices controllable by at least a subset of the network entities.

[0079] The first IoT node 303 (e.g., master IoT node 303a or server node 303b) of the IoT network generates a first transaction Tx1. The first transaction Tx1 includes an input signed by the first IoT node and an output including command data. The command data includes an identifier of the end device 302 to be controlled and a command message for controlling the end device 302. The first IoT node may be the originator of the command. That is, the first IoT node may generate the command data.

[0080] The first IoT node may send a first transaction Tx1 to a second IoT node 303 (e.g., slave node 303c) of a first network that controls the end device 302. The first transaction Tx1 may be sent off-chain, that is, not sent to the blockchain. For example, the first transaction Tx1 may be sent directly from the first IoT node to the second IoT node, e.g., via the Internet. For example, the first IoT node may be the server node 303b, and the second IoT node may be the slave node 303c. Alternatively, the first transaction Tx1 may be sent indirectly, e.g., via one or more intermediate IoT nodes. As an example, the first transaction Tx1 may be sent from the master IoT node 303a to the slave node 303c via the server node 303b. The second IoT node may be coupled to the end device 302 via a wired or wireless connection, e.g., via an Ethernet or Wi-Fi connection.

[0081] Additionally or alternatively, the first IoT node may send the first transaction Tx1 to the blockchain network 106 to be published on the blockchain 150. This depends on the first transaction Tx1 being a valid transaction. As will be described later, in some cases, it may be desirable not to send the first transaction Tx1 to the blockchain 150.

[0082] The second IoT node may obtain the first transaction Tx1 directly or indirectly from the first IoT node. For example, the first transaction Tx1 may be transferred to the second IoT node via one or more intermediate IoT nodes. The second IoT node uses the command data to send a control command to the end device 302 identified by the device identifier ("Device ID") in the command data. The control message in the command data may define the desired action of the end device 302. The control message causes the second IoT node to send a specific one of a plurality of possible commands to the end device 302. Alternatively, the second IoT node may be configured to send a single command to the end device 302. That is, the second IoT node sends only the same command to the end device. This applies, for example, when the end device 302 is a simple device such as a sensor and the command is a request for sensor reading.

[0083] The command (i.e., the command for the end device) may be sent to the device via a wired or wireless connection off-chain, for example using Wi-Fi. Alternatively, if the device is also a node of the network, the command may be sent via a blockchain transaction Tx.

[0084] In some embodiments, the device and control unit communication request and response cycle may be implemented by the first and second IoT nodes. The request (command) is issued as a partially completed transaction containing an output that includes command data (e.g., an OP_FALSE OP_RETURN payload). The response (acknowledgment response to the command) is a broadcast of the final transaction that includes the signatures of both the requesting and responding nodes. Although the receiving side of the message can add inputs and outputs, it cannot change the command data (e.g., the OP_FALSE OP_RETURN payload), so the malleability of the transaction enables this communication method.

[0085] The first transaction Tx1 sent from the first IoT node to the second IoT node may be sent without having a second output. That is, the transaction includes a single output (the output including command data). To complete the partial transaction, the second IoT node may update the transaction by adding inputs and outputs to the first transaction. The input includes a signature of the second IoT node, that is, a signature generated using the private key of the second node. The output is an output locked to the public key of the second IoT node, for example, a P2PKH output. To unlock the P2PKH output, the input of the payment transaction must include the public key. As a result, the hash of the public key (for example, OP_HASH160) matches the public key hash in the P2PKH output. The P2PKH output imposes a challenge on the party attempting to unlock the output to provide two items: a public key such that the hash of the public key matches the address (hash) in the P2PKH output, and a signature valid for the public key and the transaction message, not necessarily in that order. The public key may correspond to the private key used to generate the signature. Alternatively, the signature may be linked to the first public key and the output may be locked to a different public key. The second IoT node may then send the completed transaction to the blockchain network 106. The completed transactions (referred to as command transactions in these embodiments) are published on the blockchain 150 for other IoT nodes to obtain and function as a record of commands executed by the device. That is, when the transaction is broadcast, an independent observer can know which public key issued the command / message and which public key responded to it.

[0086] Figures 5A and 5B show an exemplary partial first transaction Tx1(partial) and an exemplary updated first transaction Tx1(complete). The partial first transaction includes a single input and a single output. The updated first transaction includes inputs and outputs added by the second IoT node. The SIGHASH_SINGLE signature type can be used to achieve the desired level of transaction compliance. For example, an IoT node having public key PK0 sends an instruction to an IoT node having public key PK1. The instruction is encoded in an unusable output (e.g., OP_FALSE OP_RETURN output) of a transaction signed using the SIGHASH_SINGLE signature type. The partially completed transaction is valid. When the instruction is completed, the second IoT node having PK1 adds an output locked to their public key. The second IoT node having PK1 completes the transaction by signing the entire transaction using the SIGHASH_ALL signature type.

[0087] In an alternative embodiment, the first transaction Tx1 sent from the first IoT node to the second IoT node may be sent with a second output. The second output is locked to the public key of the second IoT node. For example, the second output may be a P2PKH for the public key of the second IoT node.

[0088] To complete the first transaction Tx1, the second IoT node updates the first transaction by adding an input to the first transaction. The first transaction Tx1 now includes two inputs and two outputs. The second input includes the public key of the second IoT node. The public key within the second input may or may not be the same as the public key by which the second output is locked. Upon completion, the updated first transaction (referred to as a command transaction in these embodiments) is sent to the blockchain network 106 to be published on the blockchain 150. When the command transaction is broadcast, any independent observer can know which public key issued the command / message and which public key responded to it.

[0089] The second output locked to the public key of the second IoT node may allocate an amount of digital asset that is greater than the amount of digital asset referenced by the first input of the first transaction. In that case, the first transaction Tx1 is a partially completed transaction that is not considered valid by the blockchain node 104. That is, the first transaction Tx1 is not published in the block 151 of the blockchain 150 because it does not meet the consensus rules followed by the blockchain node 104. When updating the first transaction Tx1, the second IoT node needs to ensure that the combined amount of digital asset referenced by the first and second inputs is greater than the amount of digital asset locked to the second output.

[0090] Figures 6A and 6B show an exemplary partial first transaction Tx1(partial) and an exemplary updated first transaction Tx1(complete). The first transaction includes command data in a first output and a second output locked with the public key of a second IoT node. The updated first transaction includes additional inputs added by the second IoT node. If a first IoT node having PK0 sends a command to a second IoT node having PK1 that is desired to be executed only by the second IoT node having PK1, they can send a partially completed transaction that locks both outputs but does not pay a transaction fee (thus, it is less likely to be included in block 151 by blockchain node 104). To redeem a digital asset locked with PK1, the second IoT node having PK1 needs to provide an input to cover the transaction fee. To issue a command using the partially completed transaction, the SIGHASH flag of <Sig PK0 > is set to SIGHASH_ANYONECANPAY and includes an OP_FALSE OP_RETURN output having the command data. This means that the command data included in the first output is finalized, but anyone can add additional inputs. The public key that received the command can add additional inputs to redeem the digital token in input 801a. To guarantee new inputs and prevent further transaction malleability, the receiving side of the token adds a minimum value (dust) input and signs the transaction outputs using SIGHASH_ALL.

[0091] Note that the SIGHASH flag is a flag added to the signature in the transaction input to indicate which part of the transaction the signature is for. The default is SIGHASH_ALL (all parts of the transaction except ScriptSig are signed). The unsigned parts of the transaction can be changed.

[0092] Referring to FIG. 7, an exemplary request and response algorithm is provided below. The control device 303b is configured to communicate with other IoT nodes on the IoT network and can calculate the shortest communication path to any other IoT node on the IoT network. For example, PK serv is PK slave identifies that it is the control unit closest to the device with device_ID.

[0093] Step 1: The control device 303b with the public key PK serv sends the partial command Tx1 to the second control device 303c with PK slave . The IoT message included in the transaction specifies the target device with device_ID and the command.

[0094] Step 2: The second control device (PK slave ) checks that the signature of the transaction is valid and that the message included in the IoT message payload is valid according to the rules of the network.

[0095] Step 3: The second control device (PK slave ) sends the command message ("Msg") to the device (device_ID) via off-chain communication (e.g., wired connection, Bluetooth, IP-to-IP).

[0096] Step 4: When the action requested by the command is completed, the device (device_ID) returns a command completion or confirmation response message ("ack") to the second control device (PK slave ).

[0097] Step 5: The second control unit (PK slave ) adds a second input, signs it, and completes the transaction. This signals that the second control unit has confirmed the completion of the command.

[0098] Step 6: The second control unit (PK slave ) broadcasts the completed transactions to the blockchain network 106.

[0099] Figure 8 shows an exemplary command data output of a command transaction. The first command transaction includes an input (not shown) including the signature of the IoT node 303 and an output including the command data. In this example, following the protocol identifier (4 bytes), there is a 93-byte payload including IoT communication information. The communication information includes the 32-byte device ID of the intended recipient of the command instruction, the location of the device certificate, the command, and the device status. In some examples, all transactions that issue a new command or a state update must follow this format. Otherwise, it is considered an invalid command. If a field is not required for any on-chain message, the bytes may be set to 0x00000000. Desirably, as will be described later, the payload data itself is encrypted. The payload data can then be accessed only by the party holding the decryption key. The following table shows the fields of an exemplary IoT message payload. Note that the specific sizes (number of bytes) of the data fields used here are examples and not limitations.

Table 1

[0100] The replication of the device state is a logical representation of the reported or desired state of the device. In the IoT message, the device state information is encoded in the Device ID, Status, and Prev. Status. The most recent transaction related to the device ID represents the current device state. Messages including data related to commands, responses, and the state of the device are included in the timestamped blocks 150 on the blockchain 150.

[0101] In short, node 303 on the IoT network communicates directly by using a transaction containing IoT command data and by coupling to the blockchain network 106 to broadcast the transaction. The blockchain 150 is used as a permanent data store that records commands and status updates from IoT network components and issues reports and warnings related to IoT device 302.

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

[0103] Some or all of the LN nodes of the network may be configured to couple (i.e., participate or re-participate) to the hierarchical network according to a coupling protocol. The coupling protocol may vary depending on the particular layer of the network to which the coupling node is coupling (i.e., attempting to participate or re-participate). Before describing the coupling protocol in detail, a series of exemplary hierarchical networks generated or implemented by the coupling protocol are described. However, these are merely examples for illustration purposes, and it is understood that generally any hierarchical network according to the coupling protocol may be generated.

[0104] FIG. 9 shows a schematic representation of an exemplary hierarchical network (LN) 900. Typically, an LN includes a core network (or core layer) composed of core LN nodes 901, and a series of layers (or shells). The core layer is also referred to as the first LN layer. The series of layers extends outward from the core layer, in order, from the second layer composed of second LN nodes 902 to one or more outer layers. Each outer layer is composed of a set of outer LN nodes 903. Although only one outer layer is shown in FIG. 9, it can be seen that an LN may include any number of outer layers. As a specific example, FIG. 11 shows an example of an LN 1100 that includes five layers, and FIG. 12 shows an example of an LN 1200 that includes four layers.

[0105] The exemplary LN 900 of FIG. 9 includes five LN nodes 901, six LN nodes 902, and eight outer LN nodes 903. In some LNs 900, the number of LN nodes may increase with each layer. That is, the core layer is composed of the fewest LN nodes, and the outermost layer is composed of the most LN nodes. In other examples, one or more layers between the core layer and the outermost layer may be composed of the maximum number of LN nodes. In this example, the core layer is the innermost layer of the LN 900, the second layer is the middle layer, and the outermost layer, which is the only outer layer, is the outermost layer.

[0106] The core layer (network within the LN) of this example forms a complete graph. That is, each core LN node 901 is coupled to each other core LN node 901. In a core layer of five LN nodes 901, in a given example, the core layer requires ten distinct core couplings (i.e., couplings between two core LN nodes). In other examples (e.g., FIG. 10), the core layer may not be a complete graph. The core layer may form an "almost complete graph". In an almost complete graph, at least one LN node 901 is not coupled to at least one other core LN node 901. Only one core coupling may be missing. In a particular example of an almost complete graph, a given core LN node 901 may be coupled to more than one but not all of the other core LN nodes 901.

[0107] The second layer includes second LN nodes 902. Note that the term "second LN node" is used only as a label for the LN nodes 902 arranged within the second layer of the LN 900 by configuration. Each second LN node 902 is coupled to at least one core LN node 901. In some examples, each second LN node 902 may be coupled to only one core LN node 901. Alternatively, some or all of the second LN nodes 902 may be coupled to more than one core LN node 901. For example, some or all of the second LN nodes 902 may be coupled to each and every one of the core LN nodes 901. In the exemplary LN 900 of FIG. 9, each core LN node 901 is coupled to two second LN nodes 902. However, in this example, some of the second LN nodes 902 (the nodes shown as striped circles) are coupled to one core LN node 901, and some of the second LN nodes 902 (the nodes shown as white circles and the shaded circles) are coupled to two core LN nodes 901. The second LN nodes 902 (and the outer LN nodes 903 of the outer layer) that are coupled to the same core LN node 901 are called a "community". For example, each white node forms one community together, each striped node forms a community together, and each shaded node forms another community together. The connection between the second LN node 902 and the core LN node 901 is called an "ancestor connection" and is shown by a thick dashed line.

[0108] In the example of FIG. 9, each second LN node 902 is coupled to two other second LN nodes 902. In some examples, some or all of the second LN nodes 902 may not form a connection with other second LN nodes. For example, some of the second LN nodes 902 may be coupled to other second LN nodes 902, and some of the second LN nodes may not be coupled to other second LN nodes 902. These "intra-layer" connections are shown by solid lines between the nodes in FIG. 9.

[0109] The outer layer of FIG. 9 includes outer LN nodes 903. Note that the term "outer" in the "outer layer" need not be limited to the outermost layer of the LN network as a whole, although it is possible. Each outer LN node 903 is coupled to at least one second LN node 902. In some examples, each outer LN node 903 may be coupled to only one core LN node 902. Alternatively, some or all of the outer LN nodes 903 may be coupled to more than one second LN node 902. For example, some or all of the outer LN nodes 903 may be coupled to each of the second LN nodes 901. In the exemplary LN 900 of FIG. 9, each outer LN node 903 is coupled to two second LN nodes 902. Some of the second LN nodes 902 (i.e., the striped nodes) are coupled to two outer LN nodes 903, and some of the second LN nodes 902 (i.e., the white and shaded nodes) are coupled to three outer LN nodes 903.

[0110] In the example of FIG. 9, each outer LN node 903 is coupled to two other outer LN nodes 903 in the same layer. In some examples, some or all of the outer LN nodes 903 need not form a connection with other outer LN nodes 903 in the same layer. Some or all of the outer LN nodes 903 may form at least one connection with another outer LN node 903 in the same layer.

[0111] Similarly, since each outer LN node 903 is coupled to at least one second LN node 902, each outer LN node 903 is also coupled to at least one core LN node 901. The connection between the outer LN node 903 and the core LN node 901 is called a "core ancestor connection" and is shown by a thin dotted line. Each outer LN node 903 may be coupled to each of the core LN nodes 901 to which its ancestor second LN nodes 902 are coupled. As shown in FIG. 9, each outer LN node 903 may be coupled to each of the core LN nodes 901 to which its ancestor second LN nodes 902 are coupled, and not to other core LN nodes 901. In this case, each outer LN node 903 belongs to a single community.

[0112] FIG. 10 shows a schematic representation of another example of LN1000. Similar to LN900 of FIG. 9, the exemplary LN1000 includes a core layer, a second layer, and an outer layer. These exemplary LN900, 1000 share the same number of LN nodes (i.e., 5 LN nodes 901, 6 second LN nodes 902, and 8 outer LN nodes 903), but include different numbers of connections. For example, in this example, since some connections between the core LN nodes 901 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 LN node 901, and another community (shaded nodes) includes three LN nodes 901. Yet another difference is that the degree of the LN nodes in the outer shell of LN400 is 1, which is different from the degree of the nodes in the outer shell of LN900 being 2. That is, in LN1000 of this example, each outer LN node 903 is connected to a single other outer LN node 903. Thus, the LN nodes of different layers have different degrees.

[0113] FIG. 11 shows a schematic representation of another example of LN1100. In this example, only some of the core LN nodes 901 are coupled to the second LN node and the outer LN nodes 903. That is, in this example, only some of the core LN nodes 901 form connections with other core LN nodes 901. Thus, in this example, LN900 includes a single community (the shaded nodes). The LN900 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 901 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 LN node 902 that is coupled to two core LN nodes 901. The second layer is composed of a single second LN node 902 that is coupled to two core LN nodes 901. The third layer is composed of a single outer LN node 903 that is coupled to the second LN node 902 via an ancestor connection. The outer LN node 903 of the third layer is also coupled to the two core LN nodes 901 to which the second LN node 902 is coupled. The outer LN node 903 is coupled to the two core LN nodes 901 via each core-ancestor connection. The fourth layer is also composed of a single outer LN node 904. The outer node of the fourth layer is coupled to the outer LN node 903 of the third layer via an ancestor connection and to the second LN node 902 via an ancestor connection. The outer LN node 904 of the fourth layer is also coupled to the two core LN nodes 901 to which the second LN node 902 and the outer LN node 903 of the third layer are coupled. The outer LN node 904 is coupled to the two core LN nodes 901 via each core-ancestor connection. Finally, the fifth layer is composed of two outer LN nodes 905. The two outer nodes 905 of the fifth layer are coupled to the outer LN node 904 of the fourth layer, to the outer LN node 903 of the third layer, and to the second LN node 902. Each connection is an ancestor connection. The two outer LN nodes 905 are also coupled to the two core LN nodes 901 via core-ancestor connections. In the LN1100 of this example, the LN nodes of the second layer and the LN nodes of the outer layers are not coupled to any other LN nodes of the same layer.

[0114] Figure 12 shows a schematic representation of another example of LN1200. This LN includes two communities of LN nodes, indicated by white nodes and black nodes. In this example, the core layer forms a complete graph (i.e., a complete network of LN nodes). Each community includes an individual set of three core LN nodes 901. The LN1200 of this example includes four layers (a core layer, a second layer, and two outer layers). Each LN node in the outer layer is connected to one LN node in the preceding layer. Similar to the exemplary LN1100 of FIG. 11, the nodes in the second layer and the LN nodes in the outer layer are not connected to any other LN nodes in the same layer.

[0115] The LN of some embodiments of the present invention is (or includes) a mandala network, or may share some but not all of the characteristics of a mandala network. For example, the LN may share some similar features, but instead may be designed to enable a more flexible and desirable connection structure for services and user networks that utilize the blockchain network 106.

[0116] Generally, the infrastructure network underlying the LN is a blockchain 150, and the LN is an overlay network overlaid on the blockchain 150. The LN nodes of the LN are nodes having a connection to the blockchain network 106 (e.g., lightweight clients configured to execute a simplified payment verification (SPV) method). The outer nodes of the layer network are connected to off-chain devices. However, it is not excluded that some or all of the devices may have a connection to the blockchain network 106.

[0117] The LN nodes 901, 902, and 903 are configured to form connections among themselves at the overlay network level. That is, the LN nodes 901, 902, and 903 of the hierarchical network are configured to follow an overlay network protocol that specifies the connections that they can and cannot form with other LN nodes 901, 902, and 903 of the hierarchical network. Thus, all the LN nodes may (but are not required to) be physically connected to each other via the underlying infrastructure (e.g., the Internet), but when they are participating as LN nodes 901, 902, and 903 of the hierarchical network, they operate according to the relevant overlay network protocol of the hierarchical network 900, and thus, the connections among such LN nodes 901, 902, and 903 may be more restricted. The connections among the LN nodes 901, 902, and 903 of the hierarchical network 900 mean that those nodes can communicate directly with each other. In this context, this means that there is no need to perform hops via another LN node 901, 902, and 903 of the hierarchical network 900. In the context of an overlay network such as a hierarchical network, "connection" means a connection (i.e., an edge) at the level of the hierarchical network 900 (i.e., at the level of the overlay network of the hierarchical network).

[0118] The LN nodes 901, 902, 903 of LN900 may identify and communicate with each other using digital certificates. That is, some or all of the LN nodes 901, 902, 903 may be associated with respective digital certificates. The digital certificates may include identifiers of each of the LN nodes 901, 902, 903, such as the public keys associated with the nodes, the network addresses of the nodes (e.g., IP addresses), etc., and may indicate the same. The LN nodes 901, 902, 903 of LN900 may use digital certificates of different nodes to connect to the LN nodes. For example, the outer LN node 903 may obtain a digital certificate from the second LN node 902 and use the identification information of the second LN node included in the digital certificate to connect to the second LN node 902. The LN nodes of a given layer may issue digital certificates to the LN nodes of the next layer in the ordered set of layers. That is, the core LN node 901 may issue a digital certificate to the second LN node 902, the second LN node 902 may issue a digital certificate to the outer LN node 903 of the first outer layer, and so on. In some examples, the LN nodes of a given layer may issue digital certificates to the LN nodes of the same layer. For example, the second LN node 902 may issue respective digital certificates to one or more other second LN nodes 902.

[0119] Multiple master nodes Figure 13 shows the importance of the exemplary network 303 of FIG. 4. That is, if the master IoT node 303a breaks down, malfunctions, or becomes unable to control or monitor other IoT nodes 303 on the network 300, the network 303 may not be able to operate as intended. For example, a malicious party may hijack the master IoT node 303a and prevent the master IoT node 303a from controlling other IoT nodes on the IoT network.

[0120] FIG. 14 shows an exemplary network 1400 for implementing an embodiment of the present invention. The network is similar to the network of FIG. 3 in that it includes a plurality of IoT nodes arranged in layers (i.e., in a hierarchical structure defined by each layer of the IoT network). The network 1400 differs from the network of FIG. 3 in that it includes a plurality of master IoT nodes 303a. In this example, only two master IoT nodes 303a, 303a' are shown, but typically, the network 1400 may include any number of master IoT nodes 303a. Each master IoT node is coupled to and configured to control each set of intermediate IoT nodes. For example, the first master IoT node 303a' (shown as a white circle) is coupled to and configured to control one intermediate IoT node 303b' (shown as a white circle). On the other hand, the second master IoT node 303a (shown as a striped circle) is coupled to two intermediate IoT nodes 303b (shown as striped circles). As can be seen from FIG. 14, the first master IoT node 303a' is also coupled to the two intermediate IoT nodes 303b controlled by the second master IoT node 303a. In some examples, the second master IoT node 303a may be coupled to the intermediate IoT node 303b' controlled by the first master IoT node 303a'. Each intermediate IoT node 303b, 303b' in each intermediate layer is coupled to one or more intermediate IoT nodes 303c in the next intermediate layer or, in the case of the device layer, to one or more end devices 302.

[0121] In another approach, network 1400 is configured as a hierarchical network, with a core layer including a plurality of master IoT nodes 303a and then a series of outer layers. Each of the master IoT nodes may be coupled to each of the other master IoT nodes (e.g., the core layer may be a complete graph). Alternatively, the core layer may be an almost complete graph as described above. The outer layers include one or more intermediate layers. Each intermediate layer includes one or more intermediate IoT nodes. Each master IoT node in the core layer controls, under normal operation, each set of intermediate IoT nodes in the first intermediate layer. That is, the intermediate layer is directly coupled to the core layer. Each set of intermediate IoT nodes controlled by the first master IoT node 303a’ and each set of intermediate IoT nodes controlled by the second master IoT node 303a may or may not be exclusive sets (i.e., they may or may not overlap). Also, it is not excluded that one or more of the master IoT nodes are coupled to one or more intermediate IoT nodes in a different intermediate layer, e.g., the second intermediate layer. The hierarchical network also includes a device layer including one or more end devices. Referring to FIGS. 3 - 8, any of the features belonging to master IoT node 303a, intermediate IoT nodes 303b, 303c, and end device 302 are equally applicable to the following description of those nodes and devices.

[0122] In some embodiments, network 1400 may share one, some, or all of the characteristics of any one of the hierarchical networks 900, 1000, 1100, 1200 described with reference to FIGS. 9 - 12, respectively. For example, network 1400 may take the form of a mandala network or share characteristics such as a mandala.

[0123] As shown in FIG. 13, problems occur when the network is composed of a single master IoT node 303a. This problem is solved by the present invention by operating a master IoT node as a backup when a problem occurs in a different master IoT node. For example, the first master IoT node 303a' may take over the control of the intermediate IoT node 303b controlled by the second master IoT node 303a when there is a problem (e.g., a failure) in the second master IoT node 303a.

[0124] The following will be described from the perspective of the first master IoT node 303a' that operates as a backup for the second master IoT node 303a. However, in general, it is understood that any of the multiple master IoT nodes may execute an action belonging to the first master IoT node 303a.

[0125] The first master IoT node 303a' identifies a problem (or multiple problems) that affects its ability to control each set of intermediate IoT nodes of the second master IoT node, that is, the second set of intermediate IoT nodes.

[0126] For example, the problem may be that the second master IoT node 303a cannot control the second set of intermediate IoT nodes by issuing a command transaction to one or more nodes of the second set of intermediate IoT nodes, for example, in accordance with the above-mentioned request and response protocol. The second master IoT node 303a may be unable to control the second set of intermediate IoT nodes due to, for example, a failure or other technical problems of the second master node 303a, or because the second master IoT node 303a has been compromised by a malicious party.

[0127] As another example, the problem may be that the second master IoT node 303a is experiencing a load balancing problem (e.g., there is too much traffic across one or more connections of the network 1400). The load balancing problem may be a network-wide problem. That is, the load across the network as a whole exceeds a threshold amount. In that situation, the second master IoT node may need to disable one or more of its connections in order to bring the load below an acceptable threshold. In other examples, the second master IoT node may receive an instruction from one of the other master IoT nodes (e.g., the second master IoT node). The instruction instructs the second master IoT node to drop a particular connection. In some examples, instead of dropping a connection, the second master IoT node 303a may handle the load balancing problem by redirecting traffic to the first master IoT node 303a'.

[0128] The load balancing problem may be the load between the second master IoT node and a particular intermediate IoT node or set of intermediate IoT nodes coupled to the second master IoT node 303a. The second master IoT node may disable one or more connections, for example, to bring an increased load within an acceptable threshold amount. Alternatively, the second master IoT node may drop a connection with another master IoT node, for example, in response to an instruction to drop a connection from another master IoT node.

[0129] (Detected by the second master IoT node 303 itself or another node, such as the first master IoT node) load balancing problems may include detecting that the load on the connection between the second master IoT node and one or more other nodes within the hierarchical network exceeds a threshold. Such load may be measured, for example, in terms of bandwidth, error rate, packet loss rate, delay, jitter, or a connection metric that combines one or more such measurements. Alternatively or in addition, detecting load balancing problems may include detecting that the processing load at the second master IoT node exceeds a threshold. This may be an indicator, for example, in terms of the processing resources consumed by the second master IoT node, or the processing resources available to the second master IoT node.

[0130] In an embodiment, detecting load balancing problems may include detecting that the number of connections between the second master IoT node of the IoT network and one or more other nodes (e.g., one or more nodes among the second set of nodes) exceeds a threshold number of connections, such as the maximum total number of connections to the second master IoT node. For example, the second master IoT node may be required to maintain a minimum or maximum number of connections permitted by the connection protocol of network 1400.

[0131] The threshold may be a threshold for connections between the second master IoT node and nodes of a particular layer. For example, the second master IoT node may be permitted to form (and maintain) only a certain number of core connections, or connections to intermediate IoT nodes 303b (e.g., across a particular intermediate layer or the entire intermediate layer). The second master IoT node may drop one or more of its own connections to intermediate IoT nodes and / or instruct one or more of its connected intermediate IoT nodes to drop their connections to the second master IoT node. The number of connections dropped may be equal to or greater than the number of connections exceeding the threshold number of allowable connections.

[0132] In some embodiments, disabling the connection with each IoT node may include revoking each digital certificate issued to each IoT node by the second master IoT node. In these examples, the IoT node must have a valid digital certificate to connect with another IoT node. The second master IoT node may be responsible for issuing digital certificates to intermediate nodes. The second master IoT node may revoke the digital certificate of the node to disable the connection with the intermediate IoT node 303b.

[0133] As another example, the problem may be a privacy problem. That is, the second master IoT node may receive an indication (or obtain information regarding) of a privacy violation of the network. The privacy problem may be that the second master IoT node is hacked or fails. Alternatively, the privacy problem may be that the identification information (e.g., of the second master IoT node or other nodes in the network) is compromised (e.g., stolen or leaked). The second master IoT node 303a may drop its connection with one or more of the nodes in the second set of intermediate IoT nodes to prevent further damage to the IoT network. The identification information may include the secrets and / or public keys associated with the second master IoT node 303a.

[0134] The first master IoT node 303a' may be configured to identify problems based on instructions from one or more other nodes in the network. For example, the first master IoT node 303a' may receive instructions from the second master IoT node 303a and / or from one or more nodes in the second set of intermediate IoT nodes, such as an instruction that the second master IoT node 303a can no longer control, or an instruction that the control by the second master IoT node 303a is being affected. As a specific example, if the second master IoT node 303a has to disable a connection with one or more intermediate IoT nodes, the second master IoT node 303a may notify the first master IoT node 303a' of the connection to be disabled. The intermediate IoT node whose connection with the second master IoT node 303a has been disabled may, or instead of the second master IoT node 303a, notify the first master IoT node 303a of the connection that has been disabled. For example, one or more nodes in the second set of intermediate IoT nodes may request that the first master IoT node 303a' take over the control of them or other nodes in the second set of intermediate IoT nodes.

[0135] Additionally or alternatively, the first master IoT node 303a' may be configured to identify problems based on a failed attempt to communicate with the second master IoT node 303a. That is, the first master IoT node 303a' may determine that there is a problem with the second master IoT node 303a if the first master IoT node 303a' cannot connect to the second master IoT node 303a.

[0136] As another additional or alternative option for identifying problems with the second master IoT node 303a, the first master IoT node 303a' may determine that the second master IoT node 303a does not issue a command transaction to one or more nodes of the second set of intermediate IoT nodes during a threshold amount of time (e.g., as part of the request and response protocol described above). For example, the first master IoT node 303a' may monitor the blockchain 150 (e.g., periodically or on an ad-hoc basis) for transactions issued by the second master IoT node 303a and / or sent to intermediate IoT nodes under its control. That is, transactions that are signed by the signature of the second master IoT node or locked to the respective public key (or public key hash or any other blockchain address associated with a given intermediate IoT node) of each intermediate IoT node. If such a transaction is not issued within an expected time period (e.g., 1 minute, 1 hour, etc.), the first master IoT node 303a' takes this as an indication that there is a problem with the second master IoT node 303a.

[0137] As another option, the first master IoT node 303a' may identify that there is a problem with the second master IoT node 303a if the state of the intermediate IoT nodes does not change over a predetermined time period. Additionally or alternatively, the first master IoT node 303a' may identify that there is a problem with the second master IoT node 303a if the state of one or more of the end devices controlled by the second set of intermediate IoT nodes does not change over a predetermined time period. For example, as shown in FIG. 8, as part of the request and response protocol, nodes and / or end devices may report their state in request and response transactions. If the state of the device does not change within a set time period, this may indicate that the intermediate IoT node did not instruct the device to perform an action within that time period. This may also indicate that the second master IoT node 303a did not instruct the intermediate IoT node to control the end device 302 within that time period.

[0138] In response to identifying one or more of the above-described problems of the second master IoT node 303a, the first master IoT node 303a' is configured to control one or more nodes of the second intermediate IoT node set. As described above, control of nodes on the network 1400 is performed by issuing command transactions. Accordingly, in response to the identification of the problem, the first master IoT node 303a' is configured to issue each command transaction to one or more nodes of the second intermediate IoT node set. In some examples, the command transaction is used for each of the second intermediate IoT node sets. In other examples, the command transaction may be issued only to some of the nodes of the second intermediate IoT node set, for example, to nodes that the second intermediate IoT node 303a cannot control.

[0139] Since a complete description of the exemplary request and response protocol implemented by the IoT nodes (including master IoT nodes and intermediate IoT nodes) of the IoT network has been provided above, details will not be described again except for those related to the specific actions that may be performed by the first master IoT node 303a'.

[0140] Each command transaction issued to one of the nodes of the second intermediate IoT node set may include an output locked to the public key of that intermediate IoT node, for example, by a P2PKH output. The command transaction may also include one or more inputs, for example, an input including the signature of the first master IoT node 303a'.

[0141] A command transaction issued to one of the nodes in the second intermediate IoT node set may include command data for controlling one or more end devices controlled by the intermediate IoT node. For example, the command data may include the device identifier of each device to be controlled. As described above, the command data may be included in the unusable output of the command transaction. However, it is not excluded that the command data may be included in a usable output, for example, an output locked with the public key of the intermediate IoT node.

[0142] The first master IoT node 303a' may submit a command transaction to the blockchain network 106 so as to be included in the blockchain 150. Additionally or alternatively, each command transaction may be sent directly to each intermediate IoT node, for example, via a secure communication channel.

[0143] In some examples, the first master IoT node 303a' may receive a request for controlling one of the nodes in the second intermediate IoT node set, for example, in the form of a request transaction. The first master IoT node 303a' may receive this as an indication that there is a problem with the second master IoT node 303a, and then may issue a command transaction to one or more of the nodes in the second intermediate IoT node set. As an example, the request transaction may be a partial transaction that the first master IoT node 303a' completes and submits to the blockchain network. Completing the request transaction may include adding an input (including the signature of the first master IoT node 303a') to the request transaction. In other examples, the request transaction may be a completed transaction having an output locked with the public key of the first master IoT node 303a', and the first master IoT node 303a' may use this output using a command transaction to control the intermediate IoT node.

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

[0145] For example, some of the above-described embodiments have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it is understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may be generally applicable to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain at all. More generally, the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may each be replaced by a blockchain network 106, a blockchain 150, and a blockchain node 104. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104.

[0146] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the above-described functions of generating, publishing, propagating, and storing the block 151 of the blockchain 150. The existence of other network entities (or network elements) that perform only one or some, but not all, of these functions is not excluded. That is, a network entity may perform the function of propagating and / or storing blocks, but does not have to generate and publish blocks (remember that these entities are not considered nodes of a suitable Bitcoin network 106).

[0147] In an unsuitable embodiment of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or a part of, rather than all of, the functions of generating, publishing, propagating, and storing a block 151 of the blockchain 150. For example, in these other blockchain networks, the term "node" may be used to represent a network entity that is configured to generate and publish a block 151 but does not store and / or propagate the block 151 to other nodes.

[0148] More generally, the above reference to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element". Such an entity / element is configured to perform some or all of the roles of generating, publishing, propagating, and storing a block. The functions of such a network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

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

[0150] (Statement 1) A method implemented by a computer for controlling a hierarchical network device using blockchain transactions, wherein the hierarchical network (LN) includes a plurality of LN nodes configured in an ordered layer set, and the ordered layer set includes, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers each including an intermediate node set, and a device layer including an end device set, each master node being configured to control each intermediate node subset, the first master node being configured to control a first intermediate node subset, the second master node being configured to control a second intermediate node subset, each intermediate node being configured to control each end device subset, the method being executed by the first master node, identifying, by the second master node, one or more problems affecting control of at least one of the second intermediate node subset; in response, issuing, to the at least one node of the second intermediate node set, each command transaction for controlling the node; A method comprising.

[0151] (Statement 2) The method according to statement 1, wherein the step of identifying the one or more problems includes identifying that the second master node is unavailable for controlling at least one of the second intermediate node set.

[0152] (Statement 3) The method according to statement 1 or 2, wherein the step of identifying the one or more problems includes identifying a load balancing problem associated with the second master node.

[0153] (Statement 4) The method according to statement 3, wherein the load balancing problem includes that the load across the connection between one or more of the second intermediate node sets and the second master node is higher than a predetermined threshold value.

[0154] (Statement 5) The method according to statement 3 or 4, wherein the load balancing problem includes that the load across the connection between one or more of the second intermediate node sets and the second master node is higher than a predetermined threshold value as a whole.

[0155] (Statement 6) The method according to any one of statements 3 to 5, wherein the load balancing problem includes that the number of connections between the second master node and the second intermediate node set is higher than a predetermined threshold value.

[0156] (Statement 7) The method according to any one of statements 1 to 6, wherein each of the command transactions includes a first output locked by each public key associated with at least one of the nodes in the second intermediate node set.

[0157] (Statement 8) The method according to any one of statements 1 to 7, wherein each of the command transactions causes at least one of the nodes in the second intermediate node set to control one or more of the end devices in the subset of end devices controlled by the node.

[0158] (Statement 9) The method according to statement 8, wherein each of the command transactions includes each command data, and each of the command data includes identifiers of each of the one or more end devices in the subset of end devices controlled by at least one of the nodes in the second intermediate node set.

[0159] For example, the command data may be included in the unusable output of the command transaction.

[0160] (Statement 10) Each of the command transactions is configured to cause at least one of the nodes in the second intermediate node set to send each control command to one or more of the end devices in the end device subset, and each of the control commands is based on each of the command data, and is the method described in any one of Statements 1 to 9.

[0161] The command data may be encrypted or encoded.

[0162] (Statement 11) Each of the command transactions includes a first input including a signature linked to each public key of the first master node, and is the method described in any one of Statements 1 to 10.

[0163] (Statement 12) The step of issuing each of the command transactions to at least one of the nodes in the second intermediate node set includes the step of sending each of the command transactions to the node, and is the method described in any one of Statements 1 to 11.

[0164] For example, an off-chain communication channel is used.

[0165] (Statement 13) The step of issuing each of the command transactions to at least one of the nodes in the second intermediate node set includes the step of sending each of the command transactions to one or more blockchain nodes so as to be published on the blockchain, and is the method described in any one of Statements 1 to 12.

[0166] (Statement 14) The step of identifying the one or more problems comprises: identifying, by the second master node, one or more problems affecting control of some or all of the nodes of the second intermediate node subset; subsequently, in response, issuing a respective command transaction to some or all of the nodes of the second intermediate node subset to control some or all of the nodes of the second intermediate node subset; The method according to any one of Statements 1 to 13.

[0167] (Statement 15) The step of identifying the one or more problems comprises the following: receiving an indication from one or more nodes of the hierarchical network, the indication indicating that the second master node is experiencing one or more problems affecting control of some or all of the nodes of the second intermediate node subset; attempting and failing to establish a connection with the second master node; determining that the state of each of at least one of the nodes of the second intermediate node set and / or one or more end devices controlled by at least one of the nodes of the second intermediate node set has not changed over a predetermined time period; and / or identifying that the second master node has not issued a respective command transaction to at least one of the nodes of the second intermediate node set within a predetermined time period; The method according to any one of Statements 1 to 14, comprising one or more of the above.

[0168] The indication may be sent, for example, by one of the intermediate nodes following a predetermined threshold number of connection failures.

[0169] (Statement 16) The step in which the second master node identifies that it has not issued each command transaction to at least one of the second intermediate node set within a predetermined time period includes the step of identifying that each blockchain address associated with the node has not received each command transaction within the predetermined time period, the method described in statement 15.

[0170] (Statement 17) The step of receiving an instruction from one or more LN nodes of the hierarchical network includes the step of receiving a request for controlling at least one of the second intermediate node set, the method described in statement 15 or 16.

[0171] For example, another one of the intermediate nodes may send a request to the second master node to control at least one of the second intermediate node set, and since the request cannot be used by the second master node to control the other master node, no reply is required. Therefore, other intermediate nodes may rely on the first master node as a backup.

[0172] (Statement 18) The step of receiving a request for controlling at least one of the second intermediate node set includes the step of receiving a request transaction, the method described in statement 17.

[0173] (Statement 19) The request transaction includes an output locked to each public key associated with the first master node, the method described in statement 18.

[0174] (Statement 20) The first master node is coupled to a plurality of blockchain nodes of the blockchain network, the method described in any of statements 1 to 19.

[0175] (Statement 21) Each master node is coupled to a plurality of blockchain nodes of the blockchain network by the method described in Statement 20.

[0176] (Statement 22) Each master node is coupled to each of the other master nodes by the method described in any of Statements 1 to 21.

[0177] (Statement 23) Each intermediate node of the first layer of the intermediate layers is coupled to at least two master nodes by the method described in any of Statements 1 to 22.

[0178] (Statement 24) Each intermediate node of a given layer is coupled to at least one node of the previous layer by the method described in any of Statements 1 to 23.

[0179] (Statement 25) The first intermediate node subset and the second intermediate node subset are non-overlapping subsets by the method described in any of Statements 1 to 24.

[0180] (Statement 26) The end device is an IoT device by the method described in any of Statements 1 to 25.

[0181] (Statement 27) A computer device, a memory including one or more memory units, a processing device including one or more processing units, a network interface including one or more network interfaces, A computer device that includes [description not provided in the original], wherein the memory stores code configured to be executed by the processing device, and the code, when executed by the processing device, is configured to operate the computer device by executing the method described in any of Statements 1 to 26.

[0182] (Statement 28) A computer program embodied on a computer-readable storage device and configured to execute the method described in any of Statements 1 to 26 when executed on one or more processors.

[0183] (Statement 29) A system including a hierarchical network, wherein the hierarchical network includes a plurality of LN nodes configured in an ordered layer set, and the ordered layer set includes, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers each including an intermediate node set, and a device layer including an end device set. Each master node is configured to control each intermediate node subset, the first master node is configured to control the first intermediate node subset, the second master node is configured to control the second intermediate node subset, and each intermediate node is configured to control each end device subset.

[0184] According to another aspect disclosed in the present specification, a method including the operations of some or all of the first master node and the intermediate nodes may be provided.

[0185] According to another aspect disclosed herein, a system including the computer device of the first master node and some or all of the computer devices of the intermediate nodes can be provided.< / sigpa>

Claims

1. A method implemented by a computer for controlling a hierarchical network device using blockchain transactions, wherein the hierarchical network (LN) includes a plurality of LN nodes configured in an ordered layer set, and the ordered layer set includes, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers each including an intermediate node set, and a device layer including an end device set, each master node being configured to control each intermediate node subset, a first master node being configured to control a first intermediate node subset, a second master node being configured to control a second intermediate node subset, each intermediate node being configured to control each end device subset, the method being executed by the first master node, identifying, by the second master node, one or more problems affecting the control of at least one of the second intermediate node subset; in response, issuing, to the at least one node of the second intermediate node subset, each command transaction for controlling the node; A method comprising.

2. The method according to claim 1, wherein the step of identifying the one or more problems includes identifying that the second master node is unavailable for controlling at least one of the second intermediate node subset.

3. The method according to claim 1 or 2, wherein the step of identifying the one or more problems includes identifying a load balancing problem associated with the second master node.

4. The method according to claim 3, wherein the load balancing problem includes that the load across the connection between one or more of the second intermediate node subset and the second master node is higher than a predetermined threshold.

5. The method according to claim 3 or 4, wherein the load balancing problem includes that the load across the connection between one or more of the second intermediate node subsets and the second master node is higher than a predetermined threshold as a whole.

6. The method according to any one of claims 3 to 5, wherein the load balancing problem includes that the number of connections between the second master node and the second intermediate node subset is higher than a predetermined threshold.

7. The method according to any one of claims 1 to 6, wherein each command transaction includes a first output locked by each public key associated with at least one of the second intermediate node subsets.

8. The method according to any one of claims 1 to 7, wherein each command transaction causes at least one of the second intermediate node subsets to control one or more of the end devices in the subset of end devices controlled by the node.

9. The method according to claim 8, wherein each command transaction includes respective command data, and each command data includes identifiers of each of the one or more end devices in the subset of end devices controlled by at least one of the second intermediate node subsets.

10. The method according to any one of claims 1 to 9, wherein each command transaction is configured to cause at least one of the second intermediate node subsets to send respective control commands to the one or more end devices in the subset of end devices, and each control command is based on the respective command data.

11. The method according to any one of claims 1 to 10, wherein each command transaction includes a first input including a signature linked to each public key of the first master node.

12. The step of issuing each of the command transactions to at least one of the nodes of the second intermediate node subset includes the step of sending each of the command transactions to the node, according to any one of claims 1 to 11.

13. The step of issuing each of the command transactions to at least one of the nodes of the second intermediate node subset includes the step of sending each of the command transactions to one or more blockchain nodes so as to be published on the blockchain, according to any one of claims 1 to 12.

14. The step of identifying the one or more problems includes identifying one or more problems that affect the control of some or all of the nodes of the second intermediate node subset by the second master node, and in response, issuing each command transaction to some or all of the nodes of the second intermediate node subset to control some or all of the nodes of the second intermediate node subset, according to any one of claims 1 to 13. The method according to any one of claims 1 to 13, comprising

15. The step of identifying the one or more problems is as follows: receiving an instruction from one or more nodes of the hierarchical network, the instruction indicating that the second master node is experiencing one or more problems that affect the control of some or all of the nodes of the second intermediate node subset, and attempting and failing to establish a connection with the second master node, and determining that the state of at least one of the nodes of the second intermediate node subset and / or one or more end devices controlled by at least one of the nodes of the second intermediate node subset has not changed over a predetermined time period, and / or The step of the second master node identifying that it has not issued each command transaction to at least one of the second intermediate node subset within a predetermined time period The method according to any one of claims 1 to 14, including one or more of . **Claim 16** The step of the second master node identifying that it has not issued each command transaction to at least one of the second intermediate node subset within a predetermined time period includes the step of identifying that each blockchain address associated with the node has not received each command transaction within the predetermined time period. The method according to claim 15 **Claim 17** The step of receiving an instruction from one or more LN nodes of the hierarchical network includes the step of receiving a request for controlling at least one of the second intermediate node subset. The method according to claim 15 or 16 **Claim 18** The step of receiving a request for controlling at least one of the second intermediate node subset includes the step of receiving a request transaction. The method according to claim 17 **Claim 19** The request transaction includes an output locked to each public key associated with the first master node. The method according to claim 18 **Claim 20** The first master node is coupled to a plurality of blockchain nodes of the blockchain network. The method according to any one of claims 1 to 19 **Claim 21** Each master node is coupled to a plurality of blockchain nodes of the blockchain network. The method according to claim 20 **Claim 22** Each master node is coupled to each of the other master nodes. The method according to any one of claims 1 to 21

23. The method according to any one of claims 1 to 22, wherein each intermediate node of the first layer among the intermediate layers is coupled to at least two master nodes.

24. The method according to any one of claims 1 to 23, wherein each intermediate node of a given layer is coupled to at least one node of the previous layer.

25. The method according to any one of claims 1 to 24, wherein the first intermediate node subset and the second intermediate node subset are non - overlapping subsets.

26. The method according to any one of claims 1 to 25, wherein the end device is an IoT device.

27. A computer device, a memory including one or more memory units, a processing device including one or more processing units, a network interface including one or more network interfaces, and wherein the memory stores code configured to be executed by the processing device, and the code, when executed by the processing device, is configured to operate the computer device by executing the method according to any one of claims 1 to 26.

28. A computer program for causing a computer device to execute the method according to any one of claims 1 to 26.

29. A system including a hierarchical network, wherein the hierarchical network includes a plurality of LN nodes configured in an ordered layer set, and the ordered layer set includes, in order, a core layer including a plurality of master nodes each coupled to one or more blockchain nodes of a blockchain network, one or more intermediate layers each including an intermediate node set, and a device layer including an end device set, each master node is configured to control each intermediate node subset, a first master node is configured to control a first intermediate node subset, a second master node is configured to control a second intermediate node subset, each intermediate node is configured to control each end device subset, and the first master node identifies one or more problems that affect the control of at least one node of the second intermediate node subset by the second master node, and in response, issues each command transaction for controlling the at least one node to the at least one node of the second intermediate node subset, configured system.

Images