Communication protocol utilizing blockchain transactions

Abstract

A computer-implemented method for granting a requester with permission to join a first network. The first network includes a set of bridge nodes and a set of devices controllable by one or more of the set of bridge nodes. Each bridge node is also a corresponding node in the blockchain network. The method is performed by a registration institution and includes generating a first blockchain transaction. The first blockchain transaction includes an input that includes a signature of a first public key linked to the registration authority. The first blockchain transaction also includes a first output, the first output including a first certificate, the first certificate including an identifier assigned to the requester. The method further includes transmitting the first block chain transaction to the block chain network to include it in the block chain.

Description

[0001] This application is a divisional application of Chinese application number 202080076769.5 (PCT international application number PCT / IB2020 / 059319), filed on October 5, 2020, entitled "Communication Protocol Utilizing Blockchain Transactions". Technical Field

[0002] This disclosure relates to a method for granting a requesting entity permission to join a network, for example, so that the requesting entity can access the network. Background Technology

[0003] A blockchain is a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a series of data blocks, where each block comprises one or more transactions. Each transaction can refer back to previous transactions in the sequence, and can extend one or more blocks. Transactions can be included in new blocks by being committed to the network (e.g., through a process called "mining").

[0004] Transactions in blockchains are typically used to transfer digital assets, i.e., data used as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in the transaction output. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, thus enabling the incorporation of more complex data. For example, this can be used to store electronic documents, or even audio or video data, in the blockchain.

[0005] Each node in the network can have any or all of the following roles: forwarder, storer. Forwarding nodes propagate transactions throughout the network. Storer nodes each store their own copy of the blocks in the blockchain. To record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. Each node is configured to adhere to the same node protocol, which includes one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated to blocks. Assuming the transaction has been verified as valid and thus accepted on the blockchain, the attached user data will therefore continue to be stored as an immutable public record at various nodes in the P2P network. Summary of the Invention

[0006] The Internet of Things (IoT) technology enables networks of physical devices to monitor events and exchange data without human intervention. The driving force behind the development of IoT technology is the need for real-time data acquisition and automated control mechanisms to replace conventional monitoring and control methods across industries. IoT systems generate massive amounts of data and rely on systems with network scalability, robust network security, reliable connectivity, and minimal network latency.

[0007] Currently, centralized architecture models are widely used for authenticating, authorizing, and connecting nodes in the Internet of Things (IoT). Such models are vulnerable to attack and act as a single point of failure. If a centralized system is compromised, malicious devices may be granted and / or have access to the IoT removed from existing devices. For example, if a malicious device is granted access to the IoT, it could acquire sensitive data or compromise the network.

[0008] Compared to centralized architectures, peer-to-peer (P2P) architectures offer a more secure and efficient solution, allowing adjacent nodes to interact directly without the need for any centralized node or agent. Blockchain technology, the foundation for secure P2P communication, holds the promise of revolutionizing the development of IoT systems. However, realizing next-generation blockchain-based IoT device systems requires overcoming the inherent challenges of open systems. These include data privacy and device protection / control mechanisms that may not be inherent to blockchain itself.

[0009] According to one aspect disclosed herein, a computer-implemented method is provided for granting a requester permission to join a first network, wherein the first network includes a set of bridging nodes and a set of devices controllable by one or more of the set of bridging nodes, wherein each bridging node is also a corresponding node in a blockchain network; the method is performed by a registry and includes: generating a first blockchain transaction, wherein the first blockchain transaction includes inputs and a first output, the inputs including a signature of a first public key linked to the registry, the first output including a first certificate, wherein the first certificate includes an identifier assigned to the requester; and transmitting the first blockchain transaction to the blockchain network to include it in the blockchain.

[0010] The first network (e.g., the Internet of Things, or IoT) includes one or more bridging nodes and one or more devices that can be controlled by the bridging nodes. The bridging nodes are also nodes in the blockchain network. That is, the bridging nodes are part of both the IoT and the blockchain network; that is, the bridging nodes can be connected to both the IoT (e.g., to communicate with other network nodes and devices) and the blockchain network (e.g., to transmit transactions to the blockchain and to identify and read transactions recorded on the blockchain). These nodes act as gateways or bridges between the first network and the blockchain network. Furthermore, these nodes do not necessarily need to function as forwarding or storage nodes in the blockchain network, but this is not excluded. In some examples, one or more of the devices in the first network may also be nodes in the blockchain network.

[0011] The registration authority (which may or may not be a bridging node in the IoT) is a node in the blockchain network. That is, the registration authority connects to the blockchain to transmit transactions. The registration authority is responsible for granting certificates to requesters (requesting entities), which then grant the requester permission to join the network. In this document, after joining the network, the requester can perform tasks, such as communicating with other nodes and / or devices connected to the first network. The registration authority is a trusted party that can verify the credentials of new devices and issue digital certificates. The registration authority acts as an entry threshold, allowing or prohibiting new devices from joining the IoT.

[0012] In the output of the transaction, the first blockchain transaction includes a certificate issued to the requester. The certificate includes a unique identifier (“Device ID”) for the requester. The Device ID may be a pseudo-random byte string. The registry broadcasts the transaction (and the certificate) to the blockchain network. The first blockchain transaction is linked to the registry via the signature in the first input. The signature is linked to the registry's public key. In other words, the signature is generated based on the private key corresponding to the registry's public key. Only the registry knows the private key, therefore only the registry can sign the transaction with its signature. In other words, the certificate cannot be forged. Therefore, the certificate can only be granted to a genuine entity. When the requester communicates with other nodes or devices in the first network after obtaining the certificate, these nodes and devices can check whether a certificate has been issued to the requester, thereby verifying whether the requester is a genuine entity.

[0013] In some embodiments, the requester is also a node in the blockchain network. In this case, the certificate may include a public key assigned to the requesting node. In other words, the public key is an authentication public key. If the requesting node uses its authentication public key or a key derived therefrom to communicate with other nodes (e.g., sending transactions signed using one of the public keys to a node or the blockchain), the other nodes can be confident that the node sending these transactions is the genuine node.

[0014] According to another aspect disclosed herein, a computer-implemented method is provided for requesting permission to join a first network, wherein the first network includes a set of bridging nodes and a set of devices controllable by one or more of the set of bridging nodes, wherein each bridging node is also a corresponding node in a blockchain network; the method is performed by a requester and includes: sending a request to a registry to join the first network; obtaining a first certificate issued by the registry and including an identifier assigned to the requester. Attached Figure Description

[0015] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0016] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0017] Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain;

[0018] Figure 3 This is a schematic block diagram of another system used to implement blockchain;

[0019] Figure 4 A schematic block diagram of node software for processing transactions according to a node protocol based on an output-based model is shown.

[0020] Figure 5 This schematically illustrates the overlap between the Internet of Things (IoT) and blockchain networks;

[0021] Figure 6 The hierarchical network topology is illustrated schematically.

[0022] Figure 7a and Figure 7b The diagram illustrates partial and complete command transactions.

[0023] Figure 8a and Figure 8b The illustrations show alternative partial and complete transactions;

[0024] Figure 9 The command request and response cycle is illustrated schematically;

[0025] Figure 10a and Figure 10b The diagram illustrates partial and complete command transactions transmitted from the server node to the slave node.

[0026] Figure 11a and Figure 11b The diagram illustrates command requests and approval transactions.

[0027] Figure 12a and Figure 12b The diagram illustrates a partial and a complete encrypted command transaction.

[0028] Figure 13 An exemplary command data format is shown;

[0029] Figure 14 An exemplary point-to-point printing system is schematically illustrated;

[0030] Figures 15a to 15c An exemplary transaction used in a point-to-point printing system is illustrated schematically;

[0031] Figure 16a and Figure 16b The certificate transaction and exemplary certificate format are illustrated schematically. Detailed Implementation

[0032] Exemplary System Overview

[0033] Figure 1 An exemplary system 100 for implementing blockchain 150 is generally illustrated. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0034] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0035] At least some of the nodes in node 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some of the nodes in node 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storage node storing a corresponding copy of the same blockchain 150 in its respective storage. A given node 104 can be forwarding node 104, storage node 104S, or any combination of these nodes.

[0036] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the current transaction can be any transaction in pool 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when creating the current transaction 152j or even sending the current transaction 152j to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0037] The input to the current transaction 152j also includes the signature of user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for modification). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0038] The above can be referred to as an "output-based" transaction protocol, sometimes also called a protocol for unspent transaction outputs (UTXOs) (where the output is called a UTXO). A user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special application 105 (e.g., a "wallet" application) to organize all of the user's UTXO values, which are scattered across many different transactions 152 in the blockchain 151.

[0039] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by specific nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to a previous transaction.

[0040] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could be another user terminal). This node 104 checks the validity of the transaction according to the node protocol applied at each node in the node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of output-based transactions, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, conditions may be defined at least in part by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or by a combination thereof. Regardless of the approach, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0041] In the output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it has been validly redeemed by the input of another subsequent transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempted to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the same output of a transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining account balances. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0042] In addition to verification, at least some nodes in node 104M compete to create transaction blocks. At node 104M, new transactions are added to a pool of valid transactions that have not yet appeared in the block. Nodes then compete to assemble a new valid block 151 of transaction 152 from transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value such that when the random number is concatenated with transaction pool 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs. Therefore, this search can only be performed by brute force, consuming significant processing resources at each node 104M attempting to solve the puzzle.

[0043] Node 104M, having solved the problem, announces the solution on network 106, providing proof of the solution. Other nodes 104 in the network can then easily check the solution (once a solution with a hash value is provided, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). The transaction pool 154 then records this as a new block 151 in blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S. A block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, block 151 is immutable because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes order on block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0044] Each forwarding node 104M and / or storage node 104S can take the form of a server or a data center. However, in principle, any given node 104 can take the form of a single user terminal or a group of user terminals networked together.

[0045] Each node 104's memory stores software configured to run on the node 104's processing device to perform its appropriate role and process transactions 152 according to the node protocol. It should be understood that any action attributed to node 104 herein can be performed via software running on the processing device of the corresponding computer device. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0046] Each of the multiple parties 103 acting as consumer users has its computer device 102 connected to network 101. They act as payers and receivers in the transaction, but do not necessarily participate in the dissemination of the transaction on behalf of the other parties. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for convenience, they are not shown. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0047] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0048] The client application or software 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0049] Client application 105 may include two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the network of nodes 104 and thus included in blockchain 150. The other function is to report to the corresponding party the amount of digital assets they currently possess. In an output-based system, this second function includes organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0050] An instance of client application 105 on each computer device 102 is operatively coupled to at least one forwarding node among forwarding nodes 104F of the P2P network 106. This enables the client 105 to send transaction 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query in the blockchain 150 any transaction for which the corresponding party 103 is the recipient (or actually check transactions of other parties in the blockchain 150, since in this embodiment, the blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of transaction 152 according to a node protocol and, in the case of forwarding node 104F, forward transaction 152 to propagate such transactions throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes within it). All nodes 104 in network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to rules defined for that subtype, and different nodes may also play different roles, thus implementing different corresponding aspects of the protocol).

[0051] As described above, blockchain 150 includes a series of blocks 151, each block 151 comprising a set of one or more transactions 152. Each block 151 also includes a block pointer 155 pointing to previously created blocks 151 in the blockchain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154, which await inclusion in new blocks. Each transaction 152 (except for a generating transaction) includes pointers to previous transactions to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more earlier original transactions 152 in blockchain 150 point to the genesis block 153, not to previous transactions.

[0052] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using functionality in her client application 105). She then sends transaction 152j from client application 105 to one of one or more forwarding nodes 104F that it is connected to. For example, this could be a forwarding node 104F that is most recently or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it will process it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets specific conditions to become "valid," specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0053] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any storage node 104S that receives transaction 152j will add the new valid transaction 152 to pool 154 in the replica of blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0054] Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0055] UTXO-based model

[0056] Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to protocols based on outputs or UTXOs. However, this is not limited to all possible embodiments.

[0057] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO may contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this 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 original transaction 152.

[0058] It should be noted that, although Figure 2 Each output in the transaction is represented as a UTXO, but a transaction may additionally or alternatively include one or more non-cost transaction outputs.

[0059] exist Figure 2 In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to the next transaction in pool 154. Tx1 can refer to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0060] When Alice creates her new transaction Tx1, or at least when she sends it to network 106, the previous transaction Tx0 may already be valid and included in blockchain 150. This transaction may at this point be included in a block of block 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 can be created and sent together to network 102; or, if the node protocol allows buffering of “orphaned” transactions, Tx0 may even be sent after Tx1. The terms “previous” and “subsequent” as used in the context of transaction sequences in this paper refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can also be replaced with “predecessor” and “successor,” “preceding” and “descending,” or “parent” and “child,” etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (preceding transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. According to the node protocol, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0061] One of the outputs 203 of a previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must satisfy for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script defines unlocking conditions that usually include the following: the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to which the previous transaction was locked.

[0062] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (S capitalized). The locking script specifies the information required for the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0063] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0064] When a new transaction Tx1 arrives at node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves concatenating two scripts:

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

[0066] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when run together, the scripts use Alice's public key P. A (Included in the locking script at the output of Tx0) to authenticate whether the locking script at the input of Tx1 contains the signature when Alice signs the expected portion of the data. The expected portion of the data itself (“message”) also needs to be included in Tx0 in order to perform this authentication. In this embodiment, the signed data includes the entire Tx0 (therefore, it is not necessary to include a separate element to plaintext specify the portion of the signed data, as it already exists on its own).

[0067] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), any entity, such as Node 104, capable of authenticating an encrypted version of the message must have already signed it by Alice. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thus enabling any holder of the public key to authenticate the signature.

[0068] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (therefore, in the example shown, if Alice's signature is provided and authenticated in Tx1), then node 104 considers Tx1 valid. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in network 106, thus propagating it throughout the network. Once Tx1 is valid and included in blockchain 150, this defines UTXO0 in Tx0 as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If an attempt is made to spend an output that has already been spent by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (has formed a valid input for another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transaction 152 is important. In practice, a given node 104 can maintain a separate database that marks the UTXO 203 of a spent transaction 152, but the final definition of whether a UTXO has been spent depends on whether a valid input to another valid transaction is formed in blockchain 150.

[0069] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined as spent in a UTXO while simultaneously spending another portion. However, the amount of a UTXO can be split across multiple outputs in the next transaction. For example, the amount defined in UTXO0 of Tx0 can be split across multiple UTXOs in Tx1.

[0070] Also note that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another failure criterion in most transaction models. Therefore, such a transaction will not propagate to block 151.

[0071] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 at any point in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The function of client application 105 is to consolidate the various UTXO values ​​locked to the corresponding party and not yet spent in other subsequent transactions. This is achieved by querying a copy of blockchain 150 stored at any storage node 104S (e.g., the storage node 104S most recently or best connected to the corresponding party's computer device 102).

[0072] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, it might be written as [ChecksigP A ] indicates [Checksig P A ] = OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY and OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by the 'sig' input. Similarly, OP_RETURN is a scripting language opcode used to create a non-spent output for a transaction, which can store metadata within the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0073] Signature P AThis is a digital signature. In this embodiment, it is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and all or part of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the output to be signed (and therefore fixed at the time of signing).

[0074] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature authentication. Furthermore, a scripting language can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0075] Optional side channel

[0076] Figure 3 Another system 100 for implementing blockchain 150 is shown. In addition to additional communication functions, system 100 is connected to… Figure 1 The content shown is essentially the same. The client applications on each of Alice and Bob's computer devices 102a and 120b include additional communication capabilities. That is, this allows Alice 103a to establish a side channel 301 separate from Bob 103b (at the instigation of either party or a third party). Side channel 301 enables data exchange independently of the P2P network. Such communication is sometimes referred to as "off-chain" communication. For example, this communication can be used when Alice and Bob exchange transaction 152 without wanting to publish the transaction (yet) to the P2P network 106, until one party chooses to broadcast the transaction to network 106. Alternatively or additionally, the side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0077] Side channel 301 can be established via the same packet-switching network 101 as the P2P overlay network 106. Alternatively, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between Alice and Bob's devices 1021, 102b. Generally, side channel 301 as referred to herein may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e., independently of the P2P overlay network 106). When multiple links are used, the entire bundle or set of off-chain links can be referred to as side channel 301. Therefore, it should be noted that although Alice and Bob exchange specific information or data fragments or similar items via side channel 301, this does not necessarily mean that all these data fragments must be sent via the same link or even the same type of network.

[0078] Node software

[0079] Figure 4 An example of node software 400 running on each node 104 of a P2P network 106 is shown, in examples of UTXO-based or output-based models. Node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set 405 of one or more blockchain-related functional modules. At any given node 104, these modules may include any or all of the following modules: a forwarding module 405F, a storage module 405S (depending on one or more roles of that node). Protocol engine 401 is configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a transaction with a pointer to another previous transaction 152m-1(Tx) is received... m-1 The output (e.g., UTXO) of the transaction's input is 152m (Tx). m When ), the protocol engine 401 identifier Tx m The unlock script is then passed to script engine 402. Protocol engine 401 is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 in blockchain 150 stored on the corresponding node or another node 104. Regardless of the method used, script engine 401 will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 402.

[0080] Therefore, script engine 402 has Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example, Figure 4 The examples Tx1 and Tx2 shown are applicable, but the same applies to any transaction pair, such as Tx0 and Tx1. As previously mentioned, script engine 402 runs two scripts simultaneously, which will involve placing data onto stack 403 and retrieving data from that stack according to the stack-based scripting language being used (e.g., script).

[0081] By running the scripts simultaneously, the script engine 402 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 402 returns this determination to the protocol engine 401. If the script engine 402 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0082] In the output-based model, the result "TRUE" from script engine 402 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 401 must also be met; for example, Tx m The total amount of digital assets pointed to in the output does not exceed the total amount specified in the input(s), and Tx m-1 The output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 401 evaluates the results from script engine 402 along with one or more protocol-level conditions, and only when all of them are TRUE does protocol engine 401 verify transaction Tx. m Valid. Protocol engine 401 outputs an indication of whether the transaction is valid to application-level decision engine 404. Only in Tx m Only when the verification is valid can the decision engine 404 select the control forwarding module 405F to execute its Tx-related tasks. m The corresponding blockchain-related functions. This may include: a forwarding module 405F, which forwards Tx m The transaction is forwarded to another node 104 in the P2P network 106. However, it should be noted that in this embodiment, while the decision engine 404 will not choose to forward invalid transactions, this does not necessarily mean that the decision engine must trigger the forwarding of a transaction simply because it is valid. Optionally, in this embodiment, the decision engine 404 may apply one or more additional conditions before triggering one or two of these functions.

[0083] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model ( Figure 4 In (not shown), the result can be indicated as "TRUE" by a combination of the implicit protocol-level verification of the signature by node 104 and the additional positive output of the smart contract (if both individual results are TRUE, the overall result is considered TRUE).

[0084] Internet of Things

[0085] The Internet of Things (IoT) is an extension of the internet to everyday physical devices and objects. Devices with embedded computing power and internet connectivity can communicate and interact with each other, and can be remotely monitored and controlled. Over time, the definition of IoT has evolved due to machine learning, real-time analytics, and the convergence of multiple technologies, although it is generally believed that systems capable of supporting wireless sensor networks and / or control systems have the potential to realize IoT.

[0086] The Internet of Things (IoT) faces several challenges. For example, the scalability and cost of such systems can hinder them from reaching their full potential. When connected and controlled in a centralized manner, IoT devices require backend infrastructure to transmit data and receive control commands. This backend infrastructure is hosted in third-party cloud services or on-premises server farms. The scalability of IoT solutions is determined by the scalability of the backend servers and data centers, which can make the operating costs prohibitively high for IoT service providers. Consequently, many proposed IoT solutions are not cost-effective and are unsuitable for everyday use. Performance metrics such as network latency will also be important factors in determining IoT adoption rates.

[0087] Another challenge facing IoT systems is the trade-off between automation and control. IoT solutions aim to enable remote access and control of everyday electronic devices. Most IoT solutions strike a balance between complete user control and automated communication between devices and other IoT solution components. In the event of a device or IoT system failure, safety measures such as overlay mechanisms are required.

[0088] Another challenge is the threat from cyberattacks. By automating device control over the internet, users may face two potential security risks. One is the privacy risk arising from the transmission of IoT device metadata over the internet. For example, if an eavesdropper gains data access to devices such as home appliances, thieves and other criminals could use device usage patterns to predict when someone is home. The second risk is that attackers or other third parties could gain control of IoT devices. For performance-critical control software, such as software used to operate heavy machinery or hazardous materials, an attack could have catastrophic consequences.

[0089] IoT systems can be designed as centralized, distributed, and / or hybrid. Centralized solutions have bottlenecks, but faster and more reliable control can be achieved through licensed components within the IoT system. Decentralized status update reporting makes IoT solutions more scalable. Edge computing helps reduce network latency for mission-critical applications, decreases the IoT system's dependence on the cloud, and enables better management of large amounts of IoT data. The rise of distributed processing highlights the opportunity to better leverage the advantages of both centralized and distributed architectures in system architecture. Hybrid systems that combine centralized and distributed systems in a hierarchical control structure aim to improve user security and availability.

[0090] Blockchain technology has the potential to play a dominant role in the future Internet of Things (IoT) for the following reasons: Blockchain enables the integration of payments and control into a single network; existing infrastructure can be used to piggyback messages about changes in device status; and decentralized control of data within the network can improve the speed of interaction between users and devices. Combined with blockchain technology, traditional IoT devices functioning in the real world can simultaneously transmit messages and exchange value. Public blockchains act as global payment networks and universal ledgers for goods, with their protocols incorporating strong cryptographic security to automatically address various risks associated with the IoT.

[0091] Figure 5An exemplary system 500 for implementing embodiments of this disclosure is illustrated. The exemplary system 500 includes a first network 501 consisting of one or more terminal devices (i.e., computing devices) 502 and one or more bridging nodes 503 (i.e., computing devices running blockchain client applications and thus acting as bridges between blockchain network 106 and the first network 501). For clarity, the first network 501 is referred to as the Internet of Things (IoT), i.e., a network of computing devices interconnected via the Internet. Typically, the terminal devices 502 and bridging nodes 503 are embedded in everyday devices. The terminal devices 502 can take many forms, such as user devices (e.g., smart TVs, smart speakers, toys, wearable devices, etc.), smart appliances (e.g., refrigerators, washing machines, ovens, etc.), meters, or sensors (e.g., smart thermostats, smart lighting, security sensors, etc.). Similarly, the bridging nodes 503 can also take many forms, including but not limited to the same forms that the terminal devices can take. Nodes 503 can also 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 terminal devices may be fixed devices (e.g., smart lights or smart central heating controllers) rather than mobile devices.

[0092] The Internet of Things (IoT) is a packet-switched network 101, typically a wide-area internet such as the Internet. Nodes 503 and devices 502 in the packet-switched network 101 are arranged to form a peer-to-peer (P2P) overlay network 501. Each node 503 includes a corresponding computer device, and each computer device includes a corresponding processing unit, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs). Each node 503 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks; electronic media like solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media like optical disc drives.

[0093] Each node 503 in the Internet of Things (IoT) is also a blockchain node 104. These nodes 503 are arranged as bridging nodes (gateway nodes), acting as a bridge (gateway) between the first network 501 and the blockchain network 106. Blockchain nodes 104 can be "listening nodes." Listening nodes run client applications that maintain a complete copy of the blockchain, verify and propagate new transactions and blocks, but do not actively generate new blocks. Alternatively, nodes can be "simple payment verification nodes" (SPV nodes). SPV nodes run lightweight clients that can generate and broadcast transactions and indirectly monitor addresses, but do not maintain a complete copy of the blockchain.

[0094] Each node 503 in the Internet of Things (IoT) is used to directly or indirectly control the terminal device 502. A node 503 directly connected to the terminal device 502 can directly control the device. A node 503 not directly connected to the terminal device 502 can only control the device indirectly, for example, by forwarding control messages to the terminal node through one or more intermediate nodes.

[0095] like Figure 5 As shown, node 503 constitutes part of P2P network 501 and blockchain P2P network 106. Although Figure 5 The diagram shows that terminal device 502 is only part of P2P Internet of Things 501, but it does not exclude that terminal device 502 may also be a blockchain node 104.

[0096] Figure 6 An exemplary topology of an Internet of Things (IoT) 501 is shown. IoT 501 can control a master node 503a, one or more groups (601) of one or more intermediate nodes (503b, 503c), and a group of terminal devices 502. The master node 502a is used to control one or more intermediate nodes (503b, 503c). If IoT 501 includes multiple groups (e.g., multiple layers) (601a, 601b) of intermediate nodes, the master node 503a is used to directly control the first group (layer) (601a) of intermediate nodes (“server node” 503b) and indirectly control one or more groups (layers) (601b) of other intermediate nodes (e.g., one layer of “slave node” 503c). The master node 503a is a control node capable of overriding and controlling both the server node and the slave nodes. Each server node 503b is a node capable of controlling the slave node 503c. Each slave node 503c is a node controlled by both the server node 503b and the master node 503a. For example, in order to instruct terminal device 502a, master node 503a sends a command to slave node 503c through server node 503b.

[0097] Although Figure 6The exemplary IoT shown depicts only two layers of intermediate nodes (server node and slave node), but other examples may include one or more other groups of intermediate nodes, such as the intermediate node between master node 503a and server node 503b and / or the intermediate node between server node 503b and slave node 503c. As shown, each node is connected to one or more other nodes via a corresponding connection 602, and each terminal device 502 is connected to one or more slave nodes via a corresponding connection 602. One or more nodes (e.g., master node) are referred to hereinafter as control nodes. Each control node is a node 503 that can instruct other nodes to perform operations by issuing commands.

[0098] The IoT node 503 can correspond to a hierarchy in terms of functional scope, command / privilege priority, and / or access scope. In some implementations, a set of hierarchical SPV nodes implements an "IoT controller" with three levels, corresponding to... Figure 5 and Figure 6 The diagram shows a master node 503a, a server node 503b, and a slave node 503c. The master node 503a instructs one or more server nodes 503b, and each server node instructs one or more slave nodes 503c. Each slave node 503c receives instructions from one or more server nodes 503b. Each slave node 503c communicates with one or more IoT terminal devices 502, which is the direct communication channel between the IoT controller 503 and the IoT terminal devices 502. The execution status of the IoT controller 503 is recorded in a blockchain transaction Tx. Each IoT node (i.e., master node, server node, or slave node) has the ability to create a corresponding transaction Tx and broadcast it to the blockchain network 106. Each slave node monitors trigger and / or confirmation signals from the terminal devices 502, and each IoT node 503 has the ability to interact with any other IoT node to execute the overall logic of the IoT controller.

[0099] The master node, server node, and slave node can each connect individually to node 104 in the blockchain network 106 to operate blockchain wallets (e.g., monitor blockchain addresses) and may run full nodes (although this is not required). The master node 503a monitors the activity of other IoT nodes directly and indirectly under its control, issues commands to these nodes in the form of blockchain transactions (Tx), and responds to alerts. The server node 503b monitors multiple addresses, including those not directly under its control. The master node 503a can command the server node 503b to perform operations. The slave node 503c monitors the activity of the terminal device 502 directly under its control. The slave node 503c is subject to direct commands from the server node 503b and can also perform operations according to commands from the master node 503a. The slave node 503c acts as a gateway node for the terminal device 502 (i.e., a gateway between the terminal device and the blockchain network 106). The terminal device 502 connects to nearby slave devices. The slave devices report their status using an off-chain messaging protocol.

[0100] It is important to note that although a distinction is made between IoT node 503 and terminal device 502 (i.e., terminal device 502 is controlled by IoT node 503, but does not control IoT node 503 itself), terminal device 502 can also be node 104 in blockchain network 106. In other words, in some examples, terminal device 502 can operate a blockchain protocol client.

[0101] The Internet of Things (IoT) 501 strikes a balance between centralization and decentralization by combining a command and control hierarchy with the use of blockchain network infrastructure. Users of Network 501 can create their own multi-level control hierarchy, including client-server and peer-to-peer relationships between devices. The network architecture comprises three layers: IoT 501; Blockchain P2P Network 104 (i.e., full blockchain clients and lightweight blockchain clients, such as the master node, server node, and slave node being lightweight clients); and Blockchain Network 504 (a subset of the Blockchain P2P network that verifies, propagates, and stores transactions propagated by IoT nodes). Blockchain Network 106 acts as backend infrastructure, with overlap between IoT 501 and Blockchain P2P Network 106.

[0102] License Agreement

[0103] This disclosure provides a protocol for granting permission to a node 503 or device 502 requesting access to network 501 to join network 501. In an Internet of Things (IoT) environment, this allows a new node 503 to join IoT 501 using an on-chain, tamper-proof digital certificate provided by a registration authority (e.g., a trusted entity in the network). By ensuring that only genuine nodes can access the network and / or control other nodes or devices in the network, this protocol addresses issues related to network attacks.

[0104] Access to IoT 501 is granted by a registration authority (also referred to as an "authorization authority" or "certification authority"). The registration authority is responsible for issuing digital certificates to requesting entities (e.g., requesting nodes or requesting devices). Entities with valid certificates can access IoT 501. The registration authority includes corresponding computer equipment, each computer equipment including a corresponding processing unit, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs). The computing equipment of the registration authority also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory cells in the form of one or more storage media, such as magnetic media like hard disks; electronic media like solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media like optical disc drives.

[0105] To grant the requesting entity permission to join network 501, the registry generates a blockchain transaction Tx, hereinafter referred to as a "certificate transaction". An example certificate transaction is as follows: Figure 16a As shown. A certificate transaction Tx includes one or more inputs and one or more outputs. At least one input 1501a includes the digital signature of the registrar. That is, the registrar has a first private key (e.g., a first private key-public key pair) from which a digital signature can be generated, and the registrar uses this digital signature to sign the transaction. An exemplary certificate format is as follows. Figure 16bAs shown. By signing the certificate transaction, the registration authority verifies the data contained in the transaction output. The digital signature can only be generated by the registration authority knowing the first private key. The transaction also has a first output 1502a (e.g., an unspendable output), which includes a digital certificate issued by the registration authority to the requester. The digital certificate contains an identifier assigned to the requester. In IoT 501, the identifier is unique to the requester. An identifier is assigned to the requester, which must remain unchanged once issued and will appear in any certificate issued to the device. Preferably, the device identifier is assigned when the certificate is generated. However, it is not excluded that the requester already possesses a device identifier, which is then authenticated by being included in the certificate.

[0106] After the certificate transaction is generated, the registration authority transmits it to one or more nodes 104 in the blockchain network 106 to record it in the blockchain 150. Once the certificate transaction is recorded in the blockchain 150, the requester can use the certificate to prove to other nodes or devices in the network 501 that the requester has been granted permission to join the network 501. For example, when communicating with other nodes 503 in the network 501, the requester can include information identifying the certificate transaction, and therefore the certificate.

[0107] refer to Figures 1 to 3 In these examples, the first node can be Alice 103a's computer device 102a, and the second node can be Bob 103b's computer device 102b.

[0108] If the requester is node 503 in network 501 (or is requesting permission to join network 501 as a node), the certificate may include a unique public key assigned to that node. After requesting node 503 joins network 501, the public key allows requesting node 503 to transmit and receive blockchain transactions.

[0109] A private key is a secret value known only to its owner. For example, the private key could be a 256-bit string. A public key is a related public value derived from the private key and can be shared. For example, the public key can be calculated using elliptic curve multiplication of the private key and the points generated by the secp256k1 elliptic curve. The signature can be a cryptographic signature, such as one generated using the Elliptic Curve Digital Signature Algorithm (ECDSA). Alternative signature schemes, such as Rabin signatures, can also be used.

[0110] The certificate transaction may include a second output 1502b locked to a second public key of the registrar. The second public key may be the same as or a different public key used to generate the signature for signing the certificate transaction. The second output 1502b is locked to the second public key; that is, the second public key is required to unlock the output. For example, the second output may include a hash of the second public key, which must include the second public key for it to be unlocked by the input of a subsequent transaction. When the second output 1502b is executed along with the input of the second transaction, the second public key provided in the input is hashed and compared with the hash contained in the second output 1502b. If the two hashes match, the second output 1502b can be unlocked (provided any additional constraints are met).

[0111] Outputs can be locked to a public key via Payment to Public Key Hash (P2PKH). P2PKH is a scripted pattern for locking outputs to a public key hash. A P2PKH output can be spent if the recipient provides a valid signature relative to a public key that matches the hash of that public key. In other words, a P2PKH output requires the spender to provide two items: a public key whose hash matches the address in the P2PKH output; and a signature valid for both the public key and the transaction message, but not necessarily in that order.

[0112] Because the second output 1502b is locked to the public key of the registration authority, only the registration authority can revoke the certificate. This prevents the certificate from being revoked by a malicious party.

[0113] The second output 1502b can be time-locked to the second public key. The output locked by the time lock can only be unlocked after a predetermined time period has elapsed. For example, the registration authority can include the lock time in the certificate transaction. The lock time prevents the second output 1502b of the certificate transaction from being successfully spent by subsequent transactions before the end of a certain time period (which can be specified by Unix time or block height, etc.). The lock time can be implemented through the transaction's "nLocktime" field. nLocktime is a transaction parameter that specifies the minimum time before which the output can be spent. Combined with nLockTime, an opcode (e.g., OP_CHECKLOCKTIMEVERIFY(CLTV)) will prevent subsequent transactions from spending the second output (by causing script execution to fail) unless the first transaction's nLocktime is equal to or greater than the time parameter provided to the opcode. Since subsequent transactions can only be included in a valid block if their nLockTime has occurred in the past, this ensures that the CLTV-based time lock has expired before subsequent transactions can be included in a valid block.

[0114] Additionally or alternatively, the second output 1502b may be a "multi-signature" output. The multi-signature output is locked to multiple public keys, namely the second public key of the registration authority and at least one other public key. The other public key may be the public key of another node in network 501, or the public key of a third-party node outside the Internet of Things but within the blockchain network 106. Inputs to subsequent transactions attempting to spend the second output 1502b must contain multiple signatures, one signature for each public key to which the second output is locked.

[0115] Time-locking prevents the registration authority from revoking a certificate before an agreed-upon time or without the permission of a different node (e.g., the master node). Multi-signature outputs prevent certificates from being revoked without the permission of a different node (e.g., the master node). Both techniques enforce the minimum certificate duration.

[0116] When recorded in blockchain 150, each transaction can be identified by a unique transaction identifier (TxID). The transaction identifier can be generated by calculating a (double) SHA256 hash of the serialized transaction bytes. Other hash functions can be used instead of SHA256. The registry can transmit the transaction identifier of the certificate transaction to the requester. This allows the requester to identify the certificate transaction and obtain the certificate within it. Alternatively, the requester can listen for transactions transmitted from the registry's address to blockchain 150.

[0117] If the requester joins network 501 as a node (e.g., a server node), the requesting node can use a transaction identifier to obtain the first public key of the registrar and identify one or more other transactions (i.e., other certificate transactions) sent from that first public key. Each of these other transactions may include a corresponding certificate from one or more other nodes or devices in network 501. The requester can then obtain (e.g., download and save) these certificates. Information in the certificates (e.g., device identifiers and / or public keys) can be used to communicate with other nodes 503 and / or devices 502 in network 501. For example, the requester can use the authentication public key of another node 503 to transmit a blockchain transaction to that node, for example, by including an output (e.g., a P2PKH output) in the transaction locked to that authentication public key. Upon receiving a command, the requester can use the certificate to check whether the command was issued from authorized node 503 or device 502.

[0118] If the requester joins network 501 as a terminal device 502 that cannot access the blockchain, the registration authority can transmit the certificate to the terminal device via a wired or wireless connection (e.g., Bluetooth, Wi-Fi, etc.). The registration authority can also transmit a set of second certificates, consisting of one or more second certificates, to the requesting terminal device 502. Each second certificate issued to the corresponding node or terminal device in network 501 can be used to ensure communication between the requesting terminal device and the authorized node 503 and device 502.

[0119] Each certificate (first certificate and second certificate) may include the network address (e.g., IP address) of the node 503 or terminal device 502 that issued the certificate. The requester may communicate with the authorized (i.e., authenticated) node using the network address of the authorized node, for example, by sending sensor readings or command confirmations.

[0120] The registration authority may transmit the certificate issued to the requester to one or more nodes and / or terminal devices in network 501. These terminal devices may use the certificate to communicate with the requester and verify whether the requester has been granted permission to join network 501.

[0121] To prevent third parties from viewing the contents of the certificate (which may contain sensitive information), the registration authority may encrypt the certificate. For example, the certificate may be encrypted using an encryption key based on the registration authority's public key (which may be the same as or different from the registration authority's first and / or second public key). Alternatively, the encryption key may be a random number generated by the registration authority.

[0122] In some examples, the registry may issue a certificate only to the requester, i.e., without receiving an explicit request. In other examples, the requester may first send a request to the registry. The request may contain one or more credentials of the requester. For example, the credentials may include one or more of the following: device type (e.g., laptop, telephone, oven, refrigerator, etc.), node type (e.g., master node, server node, slave node, terminal device), network address (e.g., IP address, which may be an IPv6 address), etc. The registry or a different node (e.g., the master node) may verify the request. If the request is verified, the registry may generate a first transaction and transmit it to blockchain network 106. If the request is not approved, the registry may not generate a transaction.

[0123] In some cases, it may be necessary to revoke a certificate issued to a requester. For example, the requester may have been compromised or may have experienced a malfunction. To revoke a certificate, the registry generates a second blockchain transaction (“revocation transaction”). The revocation transaction has inputs that reference the second output of the certificate transaction (i.e., the output locked to the registry’s second public key). The inputs include a signature linked to the second public key. If the second output of the certificate transaction is a P2PKH output, the inputs of the revocation transaction must include a public key such that the hash of the public key (e.g., OP_HASH160) matches the hash of the public key in the P2PKH output. The P2PKH output requires the spender to provide two items: a public key such that the hash of the public key matches an address in the P2PKH output; and a signature valid for the public key and the transaction message, but not necessarily in that order.

[0124] The revocation transaction may include one or more outputs, such as outputs locked to a third public key of the registrar (which may be the same as or different from the registrar's first and / or second public key). The registrar then transmits the revocation transaction to blockchain network 106 to record it in blockchain 150. After the revocation transaction is recorded in blockchain 150, the certificate transaction is removed from the output set (e.g., the set of unspent transaction outputs (UTXOs)). A UTXO is an output of a blockchain transaction that has not been spent by another blockchain transaction. When different nodes in network 501 attempt to identify a certificate issued to a requesting node, that node will find that the certificate transaction including that certificate has been spent and interpret this as a certificate revocation. Each node in network 501 can dynamically update its peer list (i.e., the list of authorized / authenticated nodes) by observing transactions generated from the issuing address (i.e., the second public key) and transactions transmitted to the issuing address.

[0125] The validity of a node / device certificate may depend on three criteria: the issuing key is a recognized issuing key (contained in a certificate signed by a master key); the certificate is correctly formatted according to a predefined protocol; and the spendable outputs in the certificate transaction are not spent. A certificate can be renewed after revocation. The registry spends the UTXO from the old certificate and then creates a new certificate Tx using the updated information. The registry can then broadcast the new certificate's output point location index to devices in the IoT 501. This also applies to the registry's own (self-signed) certificates.

[0126] As mentioned above, the certificate includes a unique identifier for the requester. The certificate may also include the requester's unique public key. Generally, a certificate may include one or more of the following fields:

[0127]

[0128] This type of certificate requires 104 to 184 bytes of data, for example, encoded in the non-spendable (OP_RETURN) output of a blockchain transaction.

[0129] As described above, network 501 may include master node 503. In some examples, the registrar may include master node 503a. The requester may be node 503 or terminal device 502. Therefore, master node 503a may issue certificates to node 503 or device 502 itself. In additional or alternative examples, the requester may be master node 503a. If master node 503a is both the registrar and the requester, then master node 503a self-signs its own certificate.

[0130] IoT 501 access permissions have been granted, and a permissioned (or bootstrapping) algorithm is used to authorize new entities (nodes or devices). Two exemplary algorithms are provided below. Master node 503a can be controlled by a registry that can (directly or indirectly) verify the credentials of any new device requesting permission to join network 501. Master nodes 503s can then issue an on-chain certificate, which is broadcast to all other nodes 503 in network 501. The bootstrapping algorithm differs for some devices (e.g., devices that do not operate blockchain wallets) because it relies on communication between IP addresses rather than through blockchain transactions.

[0131] Exemplary licensing algorithms (master / server / slave)

[0132] Step 1: The computing device running the node registers its credentials with a registration authority, including all relevant manufacturing information. The registration authority may be the same entity operating the master node 503a. However, preferably, the public key used to sign regular commands or messages is different from the public key used to sign the certificate transactions.

[0133] Step 2: PKI key ssue The registration authority with control verifies the authenticity of the certificate and determines whether the device should be authorized to join the Internet of Things 501.

[0134] Step 3: If the device is authorized, the registration authority creates a unique certificate transaction for that node. This transaction originates from the PKI. ssue Broadcast to PKI ssue Address. The registration authority sends the TxID to the new node.

[0135] Step 4: The new node finds the transaction and identifies the PK to the registry. Issue The new node downloads and verifies data via PK. IssueAll certificates issued and currently in effect.

[0136] Step 5: The existing server and slave nodes on network 501 are used to listen for broadcasts to PK. Issue The affairs and from PK Issue Broadcast transactions. After seeing a new transaction, downloading and evaluating the new device certificate, the aforementioned node can configure its wallet and communicate with the new node.

[0137] Example licensing algorithm (end device)

[0138] Step 1: Terminal device 502 registers its credentials with the registration authority, including all relevant manufacturing information and IP address. Similarly, the registration authority can be the same entity operating master node 503a. However, preferably, the public key used to sign regular commands or messages is different from the public key used to sign the certificate transaction.

[0139] Step 2: Analyze the key PK Issue The registration authority with control verifies the authenticity of the certificate and determines whether device 502 should be authorized to join the Internet of Things 501.

[0140] Step 3: If device 502 is authorized, the registration authority creates a unique device certificate transaction for that device. This transaction originates from the PK. Issue Controlled address broadcast, or broadcast to PK Issue The controlled address. The certificate data is encrypted, so only IoT nodes can see the details.

[0141] Step 4: The registration authority sends a list of certificates that enables terminal device 502 to create a list of peer nodes. This list enables terminal device 502 to connect to other nodes 503c in network 501 and interpret the public key hierarchy.

[0142] Step 5: Node 503 in network 501 can see the device certificate and can communicate with the terminal device via IP to IP (TLS).

[0143] Request and Response Protocol

[0144] This disclosure also provides a protocol for nodes in a network (e.g., the Internet of Things) 501 to issue command requests using blockchain transactions Tx, instruct devices according to these command requests, and issue command confirmations. Although embodiments will be described with reference to the Internet of Things 501, in general, the teachings of this disclosure can be applied to any network including nodes operating a blockchain protocol client application 105 and terminal devices that can be controlled by at least a subset of these nodes.

[0145] A first bridging node 503 in network 501 (e.g., master node 503a or server node 503b) generates a first transaction Tx1, which includes inputs and outputs. The inputs are signed by the first node, and the outputs include command data. The command data includes an identifier of a terminal device 502 to be controlled and a command message for controlling the terminal device 502. The first node can be the initiator of the command; that is, the first node can generate the command data.

[0146] The first node can transmit the first transaction Tx1 to the second bridging node 503 (e.g., slave node 503c) in the first network 501 of the control terminal device 502. The first transaction Tx1 can be transmitted off-chain, i.e., without needing to be transmitted to the blockchain. For example, the first transaction Tx1 can be sent directly from the first node to the second node via the internet or other means. For example, the first node can be a server node 503b, and the second node can be a slave node 503c. Alternatively, the first transaction Tx1 can be sent indirectly through one or more intermediate nodes. For example, the first transaction Tx1 can be sent from the master node 503a to the slave node 503c via the server node 503b. The second node can be connected to the terminal device 502 via a wired or wireless connection (e.g., via Ethernet or Wi-Fi).

[0147] Alternatively or additionally, the first node may transmit the first transaction Tx1 to blockchain network 106 for recording in blockchain 150. This depends on the first transaction Tx1 being a valid transaction. As described below, in some cases, it is best not to transmit the first transaction Tx1 to the blockchain.

[0148] refer to Figures 1 to 3 In these examples, the first node may consist of Alice 103a's computer device 102a, and the second node may consist of Bob 103b's computer device 102b. As described above, Alice and Bob may exchange transactions using a side channel (e.g., side channel 301) without (yet) publishing the transaction to blockchain network 106 or into chain 150, until one of them chooses to broadcast it to network 106.

[0149] The second node can obtain the first transaction Tx1 directly or indirectly from the first node. For example, the first transaction Tx1 can be forwarded to the second node through one or more intermediate nodes. The second node uses the command data to transmit control instructions to the terminal device 502 identified by the device identifier (“Device ID”) in the command data. The control message in the command data can define the desired operation of the terminal device 502. The control message can be used to cause the second node to transmit a specific instruction from a plurality of possible instructions to the terminal device 502. Alternatively, the second node can be used to send a single instruction to the terminal device 502, that is, the second node sends only the same instruction to the terminal device. This may occur, for example, if the terminal device 502 is a simple device like a sensor, and the instruction is a request for sensor readings.

[0150] Commands (i.e., instructions to the terminal device) can be transmitted to the device off-chain via a wired or wireless connection (e.g., using Wi-Fi). Alternatively, if the device is also a node in the network, the command can be transmitted via a blockchain transaction Tx.

[0151] In some embodiments, the request and response cycle for communication between the device and the controller can be implemented by the first node and the second node. The request (command) is issued as a partially completed transaction including output, which comprises the command data (e.g., the OP_RETURN payload). The response (command acknowledgment) is a broadcast of the completed transaction, containing signatures from both the requester and responder nodes. Transaction extensibility enables this communication method because the message receiver can add inputs and outputs but cannot modify the command data (e.g., the OP_RETURN payload).

[0152] Opcodes are instruction bytes or packets used in the script engine 402 to perform stack-based and cryptographic operations on data. In this paper, the script engine 402 is the execution environment used to verify scripts within a blockchain transaction Tx; the stack 403 is a data structure (a set of elements) involved in two main operations: "push," adding an element to the set; and "pop," removing the most recently added element. Opcodes are designed to perform operations on stack elements. When verifying transaction Tx, the script engine 402 does not execute any data in the output script (ScriptPubkey) after the OP_RETURN opcode. In practice, this means that the remaining script data can be arbitrary, and the output itself is unspendable (in a blockchain protocol, an OP_FALSE opcode is required before OP_RETURN to ensure the unspendability of the output).

[0153] The first transaction Tx1, transmitted from the first node to the second node, can be transmitted without a second output. That is, the transaction consists of a single output (which includes the command data). To complete a partially completed transaction, the second party can update the transaction by adding inputs and outputs to the first transaction. The inputs include the signature of the second node, i.e., a signature generated using the second node's private key. The output is an output locked to the second node's public key, such as a P2PKH output. To spend the P2PKH output, the input to the spending transaction must include a public key such that the hash of the public key (e.g., OP_HASH160) matches the hash of the public key in the P2PKH output. The P2PKH output requires the spender to provide two items: a public key such that the hash of the public key matches an address in the P2PKH output; and a signature valid for the public key and the transaction message, but 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 a first public key, and the output may be locked to a different public key. The second node can then transmit the completed transaction to blockchain network 106. The completed transaction (referred to as a command transaction in these embodiments) is visible to other nodes (e.g., the first node) in blockchain 150 and serves as a record of the commands executed by the device. That is, after the transaction is broadcast, an independent observer can see which public key issued the command / message and which public key responded to it.

[0154] Figure 7a and Figure 7b An exemplary partial first transaction Tx1 (partial) and an exemplary updated first transaction Tx1 (complete) are shown. The partial first transaction includes a single input 701a and a single output 702a. The updated first transaction includes an input 701b and an output 702b added by the second node. The SIGHASH_SINGLE signature type can be used to achieve the desired level of transaction scalability. For example, a node with public key PK0 sends an instruction to a node with public key PK1. This instruction is encoded in the non-spent output (e.g., OP_RETURN output) of the transaction signed using the SIGHASH_SINGLE signature type. Figure 10a The partially completed transaction is valid. After the instruction is completed, the second node with PK1 adds an output locked to its address. Then, the second node with PK1 completes the transaction by signing the entire transaction using the SIGHASH_ALL signature type (see...). Figure 10b ).

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

[0156] To complete the first transaction Tx1, the second node updates the first transaction by adding inputs to it. The first transaction Tx1 now includes two inputs and two outputs. The second input includes the public key of the second node. The public key in the second input may be the same as or different from the public key to which the second output is locked. Upon completion, the updated first transaction (referred to as the command transaction in these embodiments) is sent to blockchain network 106 to be included in blockchain 150. After the command transaction is broadcast, an independent observer can see which public key issued the command / message and which public key responded to it.

[0157] Compared to the amount of digital assets referenced by the first input of the first transaction, the second output of the public key locked to the second node can transfer a larger amount of digital assets. In this case, the first transaction Tx1 is a partially completed transaction and will not be considered valid by other nodes in the blockchain network 106. That is, the first transaction Tx1 does not satisfy the consensus rules followed by the blockchain nodes and therefore will not be included in block 152 of blockchain 150. When updating the first transaction Tx1, the second node must ensure that the total amount of digital assets referenced by the first and second inputs is greater than the amount of digital assets locked to the second output.

[0158] Figure 8a and Figure 8b An exemplary partial first transaction Tx1 and an exemplary updated first transaction Tx1 (complete) are shown. The first transaction includes command data in the first output 802a and the second output 802b of the public key locked to the second node. The updated first transaction includes an additional input 801b added by the second node. If the first node with PK0 sends an instruction to the second node with PK1 that it wishes to be executed only by the second node with PK1, a partially completed transaction locking both outputs (802a, 802b) can be sent without paying any fees (therefore, the transaction will not be propagated). To redeem digital assets locked to PK1, the second node with PK1 needs to provide input 801b to pay the fees. To issue a command using the partially completed transaction, The SIGHASH flag is set to SIGHASH_ANYONECANPAY, and the output contains OP_RETURN with the command data. This means that while the command data contained in the first output 802a is fixed, anyone can add additional inputs. The public key receiving the command can add additional input 801b to redeem the funds in input 801a. To ensure the security of the new input 801b and prevent further transaction extrapolation, the fund recipient adds a minimum input and signs the transaction output with SIGHASH_ALL.

[0159] It's important to note that the SIGHASH flag is added to the signature of the transaction input to indicate which part of the transaction the signature is for. The default is SIGHASH_ALL (signs all parts of the transaction except ScriptSig). The unsigned parts of the transaction can be modified.

[0160] The following will refer to Figure 9 , Figure 10a and Figure 10b An exemplary request and response algorithm is provided. Control device 503b is used to communicate with other nodes in network 501 and can calculate the shortest communication route to any other node on the network. For example, PK serv Identify PK slave It is the controller closest to the device with the device_ID.

[0161] Step 1: Possess public key PK serv The 503b control device sends a public key PK to the device. slave The second control device 503c sends part of the command Tx1 (see...) Figure 10a The IoT message contained in the transaction specifies the command and the target device with device_ID.

[0162] Step 2: Second control device (PK) slave Check the validity of the transaction signature according to the rules of Network 501, and check the validity of the message contained in the IoT message payload.

[0163] Step 3: Second control device (PK) slave Command messages (“Msg”) are sent to the device (device_ID) via off-chain communication (e.g., wired connection, Bluetooth, IP to IP).

[0164] Step 4: After the operation requested by the command is completed, the device (device_ID) sends a command completion or acknowledgment message ("ack") back to the second control device (PK). slave ).

[0165] Step 5: Second controller (PK) slave Add a second input and signature, and complete the transaction (see...). Figure 10b This indicates that the second controller has confirmed the command has been completed.

[0166] Step 6: Second controller (PK) slave The completed transaction will be broadcast to the blockchain network 504.

[0167] In some embodiments, the first transaction Tx1 may be a command request transaction Tx1 (request) rather than a transaction. That is, the first node may send a request to two or more nodes in the network, requesting approval from the controlling terminal device 502. For example, the first node may be a server node 503b requesting approval from the master node 503a and different bridge nodes 503 (e.g., another server node 503b). The first transaction Tx1 includes the command data, which includes command messages for controlling the controlling terminal device 502. However, the first node transmits the first transaction Tx1 to two or more nodes that can approve the command request, rather than transmitting the first transaction Tx1 to the node controlling the controlling terminal device 502. That is, the first node includes outputs locked to two or more nodes in network 501. To unlock the outputs, the signature of each node must be provided in the input of the subsequent transaction Tx2. The first transaction Tx1 is broadcast to the blockchain network 160 to be included in the blockchain 150. When two or more nodes see transaction Tx2 (by listening to transactions paid to their public key or public key address), if the two or more nodes want to approve the command request, each of the two or more nodes must sign the input of the command approval transaction Tx2 (approval) and broadcast transaction Tx2 to the blockchain network 106. The command approval transaction Tx2 includes the same command data as the command request transaction Tx1, plus an additional output of the public key of the second node locked to the control terminal device 502.

[0168] Figure 11a and Figure 11bExemplary first and second transactions are illustrated. First transaction Tx1 is a command request transaction, and second transaction Tx2 is a command approval transaction. First transaction Tx1 includes an input 1101a signed by the first node, a first output 1102a containing command data, and a second output 1102b locked to two different public keys: one is the public key of a third node, and the other is the public key of a fourth node (which is also the bridging node 503 of IoT 501). Second transaction Tx2 includes an input 1101b signed by both the third and fourth nodes, the first output 1102a, and a second output 1102c locked to the public key of the second node. Multi-signature scripts can implement multi-factor approval of commands. In some cases, the interpretation of a command or the verification of a certificate may require signatures from two or more nodes (e.g., nodes in an IoT). Furthermore, it may be necessary to check whether the expendable output is in the UTXO set. For example, a first node with public key PK0 may want to instruct a second node with public key PK3 to perform an operation. As a security requirement, the command requires simultaneous approval from a third node with public key PK1 and a fourth node with public key PK2. The first node with public key PK0 creates a first transaction that sends funds to the multi-signature address. The first transaction also contains command data that requires approval (the command is encoded in PK3). In response, node 503 with public keys PK1 and PK2 can choose to spend funds from the multi-signature address, provided that both parties provide signatures. Approval can be understood as the command requesting the spending of the output in the transaction. While these figures illustrate a 2-2 payment to multi-signature (P2MS) output, in general, a P2MS output can be an n-way output, where n is any integer. P2MS is a scripting pattern that allows a payer to lock an output to multiple addresses. To be spent, the output may require one or more signatures from a set of specified public keys.

[0169] In some embodiments, as described above, the first node may generate a command request transaction Tx1. Additionally or alternatively, the first node may generate a command approval transaction Tx2 in response to command request transactions generated by different nodes of the Internet of Things 501. For example, the first node may be a master node 503a capable of approving requests. In this case, the blockchain 150 includes the command request transaction, which includes the output of a public key locked to the first node and one or more corresponding public keys of one or more other nodes 503 of the Internet of Things 501. For example, the first node may be a node that approves a command issued to a terminal device 502 controlled by the second node. If the first node approves the command, the first node signs the command approval transaction referencing the output of the command request transaction. If the first node is the last node to sign the command approval transaction, the first node transmits the transaction to the blockchain network 106. Broadcasting transaction Tx2 can be understood as an approval of the command request.

[0170] When the second node (e.g., a slave node) receives a command transaction or command-approval transaction, it sends a command (Msg) to the device identified by the device identifier (Device_ID) in the command data. In some examples, device 502 may send an acknowledgment message (Ack) to the second node to indicate that it has received the command and / or executed it. In these examples, the second node can only update the first transaction (and then broadcast the updated transaction) upon receiving acknowledgment from the device. This provides further supporting evidence that the terminal device has executed the command.

[0171] Due to the resource constraints of most everyday small electronic devices, it may not be easy to monitor blockchain 150 and / or even be able to communicate with IoT components outside their immediate location. Therefore, control of the terminal device 502 is performed locally (second node to device) and off-chain. Messages sent and received by the terminal device can be in the form of raw command data (e.g., OP_RETURN payload) without the need for additional transaction metadata. This ensures that the data packets containing the messages remain small and do not require computationally intensive operations (e.g., elliptic curve mathematics).

[0172] In some embodiments, command data contained in the transaction is encrypted. The command data can be encrypted using a random number-based encryption key, although preferably, the encryption key is generated based on the public key of the first node and the public key of the second node. The public key of the first node and / or the second node can be an authentication public key (discussed below). The authentication public key is contained in the corresponding certificate issued to the first node and / or the second node. These public keys may be different from the public keys used by the first node and the second node to generate and update the first transaction. That is, the public key used to generate the signature or lock the transaction output (“transaction public key”) may be different from the public key used to generate the encryption key. In other examples, the transaction public key may be used to generate the encryption key.

[0173] The encryption key used to encrypt the command data can be generated independently by the first node and the second node. For example, the first node can generate the encryption key based on its known private key and the second node's public key. The second node can generate the encryption key based on the public key corresponding to the first node's private key and the private key corresponding to the second node's public key. This ensures that both the first node and the second node can decrypt the command data; for example, this allows the second node to access the command message to instruct the device.

[0174] Optionally, the output of the first transaction, including the command data, may include the encryption key used to encrypt the command data. The encryption key may be encrypted using a different second encryption key. A party knowing the second encryption key can decrypt the encrypted encryption key and then decrypt the encrypted command data. For example, it may be beneficial for entities such as master nodes to be able to view all command messages sent and received by network nodes. The second encryption key can be generated based on the public key of the first node and the public keys of different nodes (e.g., the master node). The public key of the first node may be the authentication key or transaction public key of the first node. Similarly, the public key of the master node may be the authentication key or transaction public key of the master node.

[0175] Encryption can be symmetric. Symmetric encryption provides the same level of privacy for on-chain data as HTTPS provides for internet communication. To this end, the master node creates encryption keys to encrypt all regular messages between local IoT nodes. Each IoT transaction's OP_RETURN payload (i.e., the output including the command data) can have two data blocks. One is the BIE1ECIES encrypted IoT message, where the encryption key is derived using the (authentication) public keys of the requesting and responding devices (end-to-end). The other is a BIE1 ECIES encrypted encryption / decryption key for the IoT message. Elliptic Curve Integration Encryption (ECIES) is an encryption scheme based on the Diffie-Hellman exchange. The second encryption key (used to encrypt this data push) is derived using the master key and the requester's public key. An additional byte push is added to the end of the encrypted payload containing the IoT message decryption key; this byte push itself is encrypted using BIE1 between the requesting node and the master node. This ensures that the master node can view the decrypted data sent between devices on the network. Other encryption techniques, such as the United States Encryption Standard (AES), can also be used.

[0176] Figure 12a and Figure 12b The command and response transactions containing encrypted payload data are shown.

[0177] As described above, the first and second nodes can use the transaction public key when generating and updating transactions. While public keys are used to identify nodes in the Internet of Things (IoT), preferably, these public keys should not be used to sign transactions. For example, each node may have a public key contained in a certificate issued by a registry authority. The owner of the authentication key (e.g., the public key of the corresponding certificate signed by the master node) can derive a shared key that masks its identity to third parties and can be used to sign transactions.

[0178] As described above, the Internet of Things 501 may include a master node 503a. The master node 503a may acquire (e.g., generate) a seed key, and then generate a set (e.g., multiple) of private keys, each based on the seed key. The master node 503a may then transmit the set of private keys (hereinafter referred to as the combined private key) to nodes in the network (e.g., server nodes and slave nodes). Each node receives the same set of combined private keys but does not receive the seed private key.

[0179] Each node has a corresponding master private key, such as the private key corresponding to the node's authentication public key. Each node, including the master node 503a, uses the aforementioned set of federated private keys to generate a corresponding set of secondary (or transactional) private keys. Transactional private keys are generated by adding the corresponding node's master private key to each federated key. For each node, a corresponding set of transactional public keys can be generated based on the aforementioned set of transactional private keys.

[0180] The first node can be the master node 503a, i.e., the node that generates the set of combined private keys. Alternatively, the first node can be an intermediate node (e.g., a server node or a slave node) that receives the set of combined private keys from the master node. In some examples, each node may use the transaction public key only once.

[0181] The following provides an exemplary key masking algorithm for generating transaction keys based on authentication keys. Certificates with registered public keys have been issued to all nodes 503 in the local IoT 501. Specifically, the server node has an authentication key PK. Serv The master node has the authentication key PK. Master The authentication key has a private key sk Master .

[0182] Step 1: Master node 503a generates the master extended private key m based on the seed key. joint `m` is used to generate key packets, which will be shared within the IoT 501 and used to mask the address of each node. The combined key packet has an index key:

[0183]

[0184] Step 2: The master node 503a uses an off-chain end-to-end encryption scheme (e.g., BIE1 ECIES) to share m with other nodes in the IoT in off-chain messages.

[0185] Step 3: After obtaining m, server node 503b can derive a set of hierarchical deterministic key pairs from the key packet.

[0186] Step 4: Each node 503 in network 501 generates its key packet private key by adding the private key from its authentication key pair to the private key generated by the federated key packet. For example, the master node generates the transaction signing key. in

[0187]

[0188] Step 5: Each node 503 can identify all payment endpoints (addresses) of other nodes 503 in the IoT 501 by adding the public keys of other nodes to the public key in the federated key packet. For example, server node 503b can derive the payment address public key of the master node. in

[0189]

[0190] Each node 503 in IoT 501 can derive its own key packet and monitor the addresses of other devices, provided that it knows the location of m and the relevant IoT certificate.

[0191] Encryption and key shielding can protect device activity data from being leaked to third parties, while still ensuring device visibility of all nodes 503 in the local IoT 501.

[0192] Each transaction transmitted by node 503 in IoT 501 includes an output, which includes command data. The output and / or the command data may include protocol flags to indicate that the output includes the command data. This allows IoT devices and independent third parties to identify when on-chain commands, operations, or state updates occur.

[0193] Figure 13 An exemplary command data output for a first transaction is shown. The first transaction includes an input (not shown) and an output 1301, where the input includes the signature of the first node and the output 1301 includes the command data. The first transaction may also include a second output (not shown), which will be discussed below. In this example, a protocol identifier (4 bytes) is followed by a 93-byte payload containing IoT communication information. This communication information includes a 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, every transaction issuing a new command or status update must follow this format; otherwise, it will be considered an invalid command. If a field is not required for any on-chain message, its bytes can be set to 0x00000000. As described below, the payload data itself is preferably encrypted. Then, only the parties holding the decryption key can access the payload data. The following table describes the fields of an exemplary IoT message payload.

[0194]

[0195] A device status copy is a logical representation of the device's reported or desired state. In IoT messages, device status information is encoded in the device ID, state, and previous state. The latest transaction associated with the device ID represents the current device state. Messages containing commands, responses, and data related to the device state are included in timestamped blocks on the blockchain and protected using public-key cryptography and consensus rules.

[0196] In summary, node 503 in IoT 501 broadcasts transactions by directly using transactions containing IoT command data and communicating through connection to blockchain network 106. Blockchain 150 serves as a permanent data store for recording commands and status updates from IoT components, as well as issuing reports and alerts related to IoT device 502. This protocol may utilize one or more of the following features.

[0197] The request and response messaging system uses a request and response system for receiving and confirming commands. A request is an offline (peer-to-peer) transaction encoded with IoT logic that can be interpreted by the end device. Responses or confirmations are interpreted based on transaction visibility in the blockchain network 106.

[0198] Offline transaction propagation – direct (peer-to-peer) sending of instructions encoded into the transaction. The master node, server node, and slave node can independently verify the origin of a transaction by verifying the transaction signature. This is also a payment method for the controller.

[0199] Direct communication between nodes and end devices – If the instructions encoded into the transaction command payload are for the end device, the server or slave node can extract the instructions from the transaction and transmit them directly to the end device.

[0200] Broadcast transactions serve as operation confirmations – broadcasting a transaction to the blockchain network indicates that the operation encoded in the command has been executed by a device with a device ID.

[0201] Transactions that encode device status and history - Blockchain acts as a (logically) centralized and physically distributed database that stores complete device status and history.

[0202] The embodiments provide one or more of the following advantageous features.

[0203] The security of the underlying blockchain infrastructure uses public-key cryptography and consensus rules to protect all transactions that encode value transfer and record IoT interactions. Elliptic curve cryptography (ECC) based on the secp256k1 parameter provides protection for the public / private keys used to identify IoT nodes, and consensus rules provide protection for the blockchain that records IoT state and history.

[0204] Secure key management and key obfuscation techniques are used to ensure that sensitive public keys are not vulnerable to attack due to overuse of their corresponding private keys. Key obfuscation also enables IoT solution components to improve privacy by masking their public addresses.

[0205] Encryption—The specific device data contained within is encrypted end-to-end (e.g., BIE1 or AES), so that only IoT nodes with the decryption key can gain access.

[0206] Exemplary use cases

[0207] Exemplary use cases include printer services in public libraries. In most public or university libraries, in the current (centralized) model, users open accounts managed by the library administration. Accounts need to be pre-entered, and transactions must be managed by software operated by the library, which places a significant administrative burden on the library. This disclosure addresses this problem by combining a licensing agreement and a peer-to-peer control protocol. Figure 14 An exemplary IoT 501 for P2P printing is shown.

[0208] 1) The library administrator establishes a master node 503a (controlled by the library administrator) and configures a slave node 503c to directly control the printer (terminal device) 502.

[0209] 2) The administrator configures the rule engine, which will be used by node 503c and terminal device 502 to interpret messages. The rule engine is a system that executes one or more rules.

[0210] 3) The library administrator configures slave node 503c. Slave node 503c is the payment recipient that can directly instruct the printer to perform physical operations.

[0211] 4) Verify new library users authorized by the master node 503a using standard registration / login methods (e.g., username and password, or one or more credentials). The IoT permission algorithm is executed in the backend. Figure 15a This illustrates an exemplary transaction used by a library administrator to issue certificates to new library users. In this case, the library administrator is the master node 503a and also the registrar with the right to revoke certificates.

[0212] 5) When a user wants to print a document, the printed document can be sent within the library intranet system. The command transaction is sent along with the document. This transaction includes the payment to the slave node coordinating the printer, the printer device ID, and a SIGHASH_SINGLE transaction signature. Figure 15b An exemplary command transaction is shown, sent from a laptop (server node) to a controller (slave node).

[0213] 6) The controller (slave node) will authenticate whether the transaction is a valid blockchain transaction and authorize the transaction source (public key) to enter the system.

[0214] 7) If all checks pass, the slave node will instruct the printer to perform the user-requested operation.

[0215] 8) Add an output from the node that locks the payment to its address and adds a signature with SIGHASH_ALL, then broadcast the transaction to the blockchain network 106. Figure 15c An exemplary command—confirming a transaction—is shown broadcast from the controller to the blockchain network 106.

[0216] in conclusion

[0217] It should be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided based on any one or more of the following statements.

[0218] Statement 1. A computer-implemented method for granting a requester permission to join a first network, wherein the first network comprises a set of bridging nodes and a set of devices, the set of devices being controllable by one or more of the set of bridging nodes, and wherein each bridging node is also a corresponding node in a blockchain network; the method is performed by a registration authority and includes:

[0219] Generate a first blockchain transaction, wherein the first blockchain transaction includes input and a first output, the input including a signature of a first public key linked to the registry, and the first output including a first certificate, wherein the first certificate includes an identifier assigned to the requester; and

[0220] The first blockchain transaction is transmitted to the blockchain network to be included in the blockchain.

[0221] Statement 2, as described in Statement 1, wherein the first transaction includes a second output, the second output being locked to a second public key of the registration authority.

[0222] Statement 3, as described in statement 2, wherein the first output is locked to the second public key of the registration authority by a time lock, wherein the time lock prevents the first output from being unlocked before the end of a predetermined time period.

[0223] Statement 4, as described in statement 2 or 3, wherein the first output is locked to at least the second public key of the registration authority and a different public key.

[0224] Different public keys can be the public keys of nodes within the network, or the public keys of third parties outside the network. This means that certificate revocation requires multi-signature.

[0225] Statement 5, the method as described in any one of statements 1 to 4, the method comprising: transmitting the transaction identifier of the first blockchain transaction to the permission requester.

[0226] Statement 6, the method as described in any one of statements 1 to 5, wherein the certificate is encrypted using an encryption key generated by the registration authority.

[0227] For example, the encryption key could be a random number generated by the registration authority.

[0228] Statement 7. The method as described in any one of statements 1 to 6, the method comprising:

[0229] Receive a request from the requester to join the network, wherein the request includes one or more credentials;

[0230] The request is verified based on one or more credentials, wherein the generation of the first blockchain transaction is conditional upon the validity of the request.

[0231] For example, the one or more credentials may include the requester's IP address and / or manufacturing information.

[0232] Statement 8, the method of any one of statements 1 to 7, wherein the set of bridging nodes includes a master node and a set of intermediate nodes controllable by the master node, wherein the registration authority is the master node.

[0233] Statement 9, the method of any one of statements 1 to 8, wherein the set of bridging nodes includes the master node and the set of intermediate nodes controllable by the master node, wherein the requester is the master node.

[0234] Statement 10, the method as described in any one of statements 1 to 9, wherein the requester is a corresponding node in the blockchain network, and wherein the certificate includes a public key assigned to the permission requester.

[0235] Statement 11, the method of any one of statements 1 to 8, wherein the requester is a device controllable by one or more bridging nodes in the first network, and wherein the method comprises:

[0236] A set of certificates is transmitted to the requester, each of which has been transmitted to the corresponding node in the set of nodes.

[0237] Statement 12, the method as described in any one of statements 1 to 11, the method comprising: transmitting the first certificate to one or more of the set of bridging nodes.

[0238] Statement 13, the method described as in statement 2 or any of its dependent statements, the method comprising:

[0239] Generate a second blockchain transaction, wherein the second blockchain transaction includes an input that references the second output of the first transaction, and also includes a signature of the second public key linked to the registry;

[0240] The second blockchain transaction is transmitted to the blockchain network to be included in the blockchain.

[0241] Statement 14. A computer-implemented method for requesting permission to join a first network, wherein the first network comprises a set of bridging nodes and a set of devices, the set of devices being controllable by one or more of the set of bridging nodes, and wherein each bridging node is also a corresponding node in a blockchain network; the method is performed by a requester and includes:

[0242] Send a request to the registration authority to join the first network;

[0243] Obtain a first certificate, which is issued by the registration authority and includes an identifier assigned to the requester.

[0244] Statement 15, the method as described in statement 14, wherein the acquisition includes:

[0245] Receive the transaction identifier of the first blockchain transaction, which includes the first certificate;

[0246] The first blockchain transaction is obtained from the blockchain using the transaction identifier.

[0247] Statement 16. The method as described in Statement 15, wherein the first blockchain transaction includes a first input and a second output, the first input including the certificate, and the second output linked to the public key of the registry, wherein the method includes:

[0248] The public key that identifies the registration authority;

[0249] The public key of the registration authority identifies one or more second certificates contained in one or more corresponding transactions transmitted to the blockchain, each second certificate being issued to a corresponding bridging node or device or the network.

[0250] Statement 17, the method as described in Statement 16, wherein the first certificate includes the public key of the requester, wherein each second certificate issued to a corresponding bridge node in the set of bridge nodes in the first network includes the corresponding public key of the node, wherein the method includes:

[0251] A third blockchain transaction is transmitted to at least one of the group of bridge nodes, wherein the third blockchain transaction includes the output of the corresponding public key locked to the at least one bridge node.

[0252] Statement 18, the method as described in any one of statements 14 to 17, wherein obtaining the first certificate comprises: receiving the first certificate from the registration authority.

[0253] Statement 19. The method as described in any one of statements 14 to 18, the method comprising:

[0254] Receive one or more second certificates from the registration authority, each second certificate being issued to a corresponding bridging node or device in the set of bridging nodes or devices in the first network.

[0255] Statement 20, the method as described in statement 19, wherein the first certificate includes the network address of the requester, wherein each second certificate issued to the corresponding bridging node in the first network includes the corresponding network address of the node, wherein the method includes:

[0256] Send a message to one or more of the group of bridging nodes, the message being sent from the network address of the requester to the corresponding network address of the one or more bridging nodes to which the message is sent.

[0257] This network address can be an IP address.

[0258] Statement 21, the method of any one of statements 14 or 18 to 20, wherein the requester is one of the group of devices in the first network.

[0259] Statement 22, the method of any one of statements 14 to 21, wherein the requester is one of the set of nodes in the first network.

[0260] Statement 23, as described in statement 22, wherein the set of bridging nodes includes a master node and one or more intermediate nodes that can be controlled by the master node, wherein the requester is the master node.

[0261] Statement 24, the method of any one of statements 14 to 23, wherein the request includes one or more credentials of the requester.

[0262] Statement 25, as described in statement 24, wherein one or more credentials include the IP address of the requester.

[0263] Statement 26. A computer device, the computer device comprising:

[0264] The memory includes one or more memory units;

[0265] A processing apparatus comprising one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute, when run on the processing apparatus, a method as described in any one of statements 1 to 13.

[0266] Statement 27. A computer program (or computer program product) implemented on a computer-readable storage medium, the computer program being configured to perform the method as described in any one of statements 1 to 13 when run on a computer device as described in statement 26.

[0267] Statement 28. A computer device, the computer device comprising:

[0268] The memory includes one or more memory units;

[0269] A processing apparatus comprising one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute, when run on the processing apparatus, a method as described in any one of statements 14 to 25.

[0270] Statement 29. A computer program (or computer program product) implemented on a computer-readable storage medium, the computer program being configured to perform the method as described in any one of statements 14 to 25 when run on a computer device as described in statement 28.

[0271] According to another aspect of the teachings disclosed herein, a method may be provided that includes the operations of the registrar and the permission requester.

[0272] According to another aspect of the teachings disclosed herein, a system may be provided that includes the computer devices of the registrar and the permission requester.

[0273] According to another aspect of the teachings disclosed herein, a set of transactions may be provided, which includes a first blockchain transaction and / or a second blockchain transaction.

[0274] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended statements.

Claims

1. A computer-implemented method for granting a requester permission to join a first network, wherein the first network comprises a set of bridging nodes and a set of devices, the set of devices being controllable by one or more of the set of bridging nodes, and wherein each bridging node is also a corresponding node in a blockchain network; The method is performed by the registration authority and includes: Generate a first blockchain transaction, wherein the first blockchain transaction includes an input, a first output, and a second output, wherein the input includes a signature linked to a first public key of the registry, the first output includes a first certificate, and the second output is locked to a second public key of the registry, wherein the first certificate includes an identifier assigned to the requester; The first blockchain transaction is transmitted to the blockchain network to be included in the blockchain; Generate a second blockchain transaction, wherein the second blockchain transaction includes inputs referencing the second output of the first transaction, and further includes a signature of the second public key linked to the registry; and The second blockchain transaction is transmitted to the blockchain network to be included in the blockchain.

2. The method according to claim 1, wherein the first output is locked to the second public key of the registration authority via a time lock, wherein, A time lock prevents the first output from being unlocked before the end of a predetermined time period.

3. The method of claim 2, wherein the first output is at least locked to the second public key of the registration authority and a different public key.

4. The method according to any one of claims 1 to 3, wherein the method comprises: The transaction identifier of the first blockchain transaction is transmitted to the requester of the permission.

5. The method according to any one of claims 1 to 4, wherein the certificate is encrypted using an encryption key generated by the registration authority.

6. The method according to any one of claims 1 to 5, wherein the method comprises: Receive a request from the requester to join the network, wherein the request includes one or more credentials; The request is verified based on one or more credentials, wherein the generation of the first blockchain transaction is conditional upon the validity of the request.

7. The method according to any one of claims 1 to 6, wherein the set of bridging nodes includes a master node and a set of intermediate nodes controllable by the master node, wherein the registration authority is the master node.

8. The method according to any one of claims 1 to 7, wherein the set of bridging nodes includes a master node and a set of intermediate nodes controllable by the master node, wherein the requester is the master node.

9. The method according to any one of claims 1 to 8, wherein the requester is a corresponding node in the blockchain network, and wherein the certificate includes a public key assigned to the requester for the permission.

10. The method of any one of claims 1 to 7, wherein the requester is a device controllable by one or more bridging nodes in the first network, and wherein the method comprises: A set of certificates is transmitted to the requester, each of which has been transmitted to the corresponding node in the set of nodes.

11. The method according to any one of claims 1 to 10, the method comprising: The first certificate is transmitted to one or more of the group of bridging nodes.

12. A computer device, the computer device comprising: The memory includes one or more memory units; A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 11 when run on the processing apparatus.

13. A computer program implemented on a computer-readable storage medium, the computer program being configured to perform the method according to any one of claims 1 to 11 when run on a computer device.

Images