COMMUNICATION SYSTEM, METHOD AND COMPUTER PROGRAM

Abstract

A computer-implemented method, the method being executed by a controller configured to communicate with a blockchain and a network comprising one or more devices, the method including the steps of maintaining identification information comprising an index number assigned to each of the one or more devices; receiving one or more input-output pairs of a blockchain transaction, each input-output pair being associated with an assigned index number, each input-output pair comprising data from a device of the one or more devices; generating a blockchain transaction based on the one or more input-output pairs; and sending the blockchain transaction to the blockchain.

Description

[Technical field]

[0001] The present disclosure relates to a system, method, and computer program for communication. Some embodiments relate to a communication protocol for storing information in a blockchain. [Background technology]

[0002] Blockchain refers to a form of distributed data structure, where duplicate copies of the blockchain are maintained and publicly published at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network"). The blockchain comprises a chain of blocks of data, where each block comprises one or more transactions. Each transaction, other than a so-called "coinbase transaction," points to a preceding transaction in a sequence, which may span one or more blocks and go back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining," which involves multiple nodes each competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, outstanding transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through publication of only the block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: moving digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. A blockchain may also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow for the storage of additional user data or indexes for data in a transaction. Since there is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes of a blockchain network (often called "miners") perform a distributed transaction registration and validation process, which is described in more detail below. In summary, during this process, nodes validate transactions and insert them into a block template for which they attempt to identify a valid proof-of-work solution. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated and are not included in blocks. Assuming the transaction is validated and therefore accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction", distributing an amount of digital assets, i.e. a number of tokens. Detection and rejection of fraudulent transactions is performed by the actions of competing nodes, who are incentivized to act on behalf of the network and report and prevent fraudulent activity. Widespread publication of information allows users to continuously audit node behavior. The mere publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element that specifies an amount of a digital asset derivable from a preceding sequence of transactions. A consumable output may be called a UTXO (an “unspent transaction output”). An output may further comprise a locking script that specifies a condition for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit a digital token or asset. Each input of a transaction (other than a coinbase transaction) may comprise a pointer (i.e., a reference) to such output in a preceding transaction and further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, consider a pair of transactions, which we call a first transaction and a second transaction (or a “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which comprises a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one criterion of correctness applied at each node is that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not disseminate it as a legitimate transaction, but possibly disseminate it to register the fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of the preceding transaction in the sequence of past transactions, but by referencing the absolute account balance. The current state of every account is stored in the blockchain separately by multiple nodes and is constantly updated. Summary of the Invention [Means for solving the problem]

[0009] Examples described herein provide a low-power protocol for enabling communication between devices (e.g., Internet of Things (IoT) devices) and a blockchain using an ad-hoc local network. In some examples, a controller may manage a network of devices. The devices can communicate locally and also communicate externally to the network. External communications can be stored in the blockchain.

[0010] According to one aspect disclosed herein, a computer-implemented method is provided, the method being executed by a controller configured to communicate with a blockchain and a network comprising one or more devices. The method may include maintaining identification information comprising an index number assigned to each of the one or more devices, and receiving one or more input-output pairs of a blockchain transaction, each input-output pair being associated with an assigned index number, each input-output pair comprising data from a device of the one or more devices, the data being signed with a signature corresponding to a public key of the device. The method may further include generating a blockchain transaction based on the one or more input-output pairs, and sending the blockchain transaction to the blockchain.

[0011] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be put into practice, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] FIG. 3B is a schematic mock-up of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of some node software for processing transactions. [Diagram 5] FIG. 2 is a schematic diagram showing the various layers of a communication protocol. [Figure 6]FIG. 1 is a schematic block diagram of a network. [Figure 7] FIG. 2 is a schematic block diagram illustrating an example of a controller operating in a first mode. [Figure 8] FIG. 11 is a schematic block diagram illustrating an example of a controller operating in a second mode. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be adapted to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to the other blockchain nodes 104.

[0014] Each blockchain node 104 comprises a peer computer device, with different nodes of the nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (FPGAs), as well as other devices such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer readable storage in the form of a non-transitory computer readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0015] The blockchain 150 comprises a chain of blocks 151 of data, a respective copy of which is maintained at each of a number of blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, a transaction in this context referring to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount that represents an amount of digital assets, such as a user 103 to which the output is cryptographically locked (requiring that user's signature or other solution in order to be unlocked and thereby redeemed or spent). Each input points to the output of a preceding transaction 152, thereby chaining transactions together.

[0016] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0017] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not limited to a particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0018] In a given current transaction 152j, the (or each) input comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, which specifies that this output should be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily imply a transfer of financial assets, although that is of course a common application. More generally, consumption can be described as spending an output or allocating it to one or more outputs in another forward transaction. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, as used herein, "preceding" refers to something that precedes in a logical sequence linked by pointers, and not necessarily to a time of creation or transmission in a chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

[0019] The input of the current transaction 152j also comprises the authorization of the input, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to provide the change). In some cases, the transaction can also have multiple inputs to gather together amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0020] According to an output-based transaction protocol such as Bitcoin, when a participant 103, such as an individual user or an organization, wants to enact a new transaction 152j (either manually or by an automated process used by the participant), the enacting participant transmits the new transaction from its computer terminal 102 to a recipient. The enacting participant or recipient eventually transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are usually servers or data centers, but in principle could be other user terminals). It is not excluded that the participant 103 who enacts the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances not to a recipient. The blockchain nodes 104 that receive the transaction verify whether the transaction is legitimate according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that a cryptographic signature or other authorization of a participant 103 included in the input of the new transaction 152j matches a condition defined in the output of a preceding transaction 152i that the new transaction consumes (or "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by a combination of these. In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0021] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has not yet been validly redeemed by the input of another forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it is trying to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless it is flagged as fraudulent and disseminated for a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor tries to allocate the same transaction output more than once. On the other hand, the account-based model protects against double spending by maintaining an account balance. Again, there is no defined order to transactions, so the account balance has a single defined state at any one time.

[0022] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is aided by "proof of work." At the blockchain nodes 104, new transactions that have not yet appeared in a block 151 recorded in the blockchain 150 are added to an ordered pool 154 of legitimate transactions. The blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this comprises looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool of outstanding transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a certain defined number of leading zeros. Note that this is just one particular type of proof of work puzzle, other types are not excluded. The nature of a hash function is that it has an unpredictable output with respect to its input. Therefore, this search can only be performed by brute force, which consumes a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0023] The first blockchain node 104 that will solve the puzzle will announce this to the network 106 and provide the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution makes the output of the hash satisfy the condition). The first blockchain node 104 will then disseminate the block to a threshold consensus of other nodes that will accept the block and enforce the protocol rules. The ordered set of transactions 154 will then be recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The large amount of effort, e.g. in the form of hashing, required to produce the proof-of-work solution indicates the willingness of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (also known as double-spend). Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0024] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that are not yet published at any given time, depending on when they started searching for a solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may occur, which is a situation in which two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to be propagated between the nodes 104. That is, the fork with the longest branch will be the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0025] According to the Bitcoin blockchain (and most other blockchains), a node that succeeds in constructing a new block 104 is given the ability to newly allocate an additional acceptable amount of digital assets in a new special type of transaction (rather than an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional defined amount of digital assets. This special type of transaction is usually called a "coinbase transaction", but can also be named an "initial transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work indicates the willingness of the node constructing the new block to follow the protocol rules that allow this special transaction to be redeemed later. The blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, an ordinary (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction is published. This fee is usually called a "transaction fee" and is discussed below.

[0026] Depending on the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal, or a group of user terminals networked together.

[0027] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 according to the blockchain node protocol. It will be understood that any action attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

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

[0029] Some or all of the participants 103 may be connected as part of a different network, for example a network superimposed on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but are not shown for convenience. Each participant 103 may be an individual or an organization. By way of example only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not intended to be limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0030] The computing equipment 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment 102 of each participant 103 further comprises a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium. This memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing equipment 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to be executed on the processing device. It will be understood that any action attributed herein to a given participant 103 may be performed using software executed on the processing device of the respective computing equipment 102. The computing equipment 102 of each participant 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given participant 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0031] The client application 105 is initially provided to the computing equipment 102 of any given participant 103 on a suitable computer-readable storage medium, which may, for example, be downloaded from a server and provided on a removable storage device, such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0032] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorise (e.g. sign) and send transactions 152 to one or more Bitcoin nodes 104 so that they are disseminated throughout the network of blockchain nodes 104 and thus included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, the second function comprises reconciling amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0033] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and any client function described herein may instead be implemented in a suite of two or more separate applications that interface, for example, via an API or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer, at a lower layer such as an operating system, or any combination of these. The following is described with respect to a client application 105, but it will be understood that this is not limiting.

[0034] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to ask the blockchain 150 about any transactions of which the respective party 103 is the recipient (or, in an embodiment, to actually look into the transactions of other parties in the blockchain 150, since the blockchain 150 is a public entity that lends credibility to transactions in part by being publicly visible). The wallet function of each computing device 102 is configured to organize and send the transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate the transactions 152 according to the blockchain node protocol and forward the transactions 152 to disseminate the transactions 152 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is attached to a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0035] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction (using the wallet functionality of Alice's client application 105) according to the relevant transaction protocol. Alice then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it handles the transaction 152j according to the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j satisfies certain conditions to be "valid", an example of which will be discussed in detail shortly. In some transaction protocols, the conditions for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0036] Provided that the newly received transaction 152j passes the tests for it to be considered valid (i.e., for what it is "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0037] Once admitted into the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions 154, but whoever solves first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. The order of transactions is also immutably recorded, since each transaction 152 has a pointer to an earlier transaction.

[0038] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

[0039] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored separately in the blockchain by the nodes of the network and is constantly updated. In such a system, transactions are ordered using the transaction execution record (also called "position") of the account. This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be a signed transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in this data field.

[0040] UTXO-based model FIG. 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it can equally be implemented on other exemplary blockchain networks.

[0041] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO comprises a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also comprise, among other information, a transaction ID of the transaction from which it originates. The transaction data structure may also comprise a header 201, which may comprise an indication of the sizes of the input fields 202 and the output fields 203. The header 201 may also comprise an ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (minus the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0042] Suppose Alice 103a wishes to create a transaction 152j that transfers an amount of a target digital asset to Bob 103b. In Figure 2, Alice’s new transaction 152j is written as “Tx 1" in the output 203 of the previous transaction 152i in the sequence, which has the amount of digital assets locked in Alice and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx 0 " Tx 0 and Tx 1 are just arbitrary labels. 0 is also the first transaction on blockchain 151. 1 It does not necessarily mean that Tx is the immediately following transaction in the pool 154. 1 may point to any preceding (i.e., ancestor) transaction that still has unconsumed outputs 203 locked to Alice.

[0043] Alice creates a new transaction, Tx 1 When Alice creates a transaction Tx, or at least by the time she sends it to the network 106, the transaction Tx 0 Tx may already have been validated and included in a block 151 of the blockchain 150. It may already have been included in one of the blocks 151 at that point, or it may still be waiting in the ordered set 154, in which case it will be included in a new block 151 shortly. Alternatively, Tx 0 and Tx 1 may be created and sent together to the network 106, or, if the node protocol allows for buffering of "orphan" transactions, Tx 0 Tx 1The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence as defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may be equally replaced with "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", etc. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to wait for the parent, depending on the node protocol and / or node behavior.

[0044] Preceding transaction Tx 0 One or more outputs of 203 are UTXOs 0 Each UTXO comprises a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines a condition that must be met by an unlocking script in the input 202 of a subsequent transaction for the subsequent transaction to be validated and thus the redemption of the UTXO to be successful. Typically, the locking script locks the amount to a specific party (the recipient of the transaction in which the locking script is included). That is, the locking script defines the unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises a cryptographic signature of the party to which the preceding transaction is locked.

[0045] A locking script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume a transaction output 203, e.g., requirements for Alice's signature. An unlocking script appears in the output of a transaction. An unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0046] Thus, in the example shown, Tx 0 UTXO in output 203 0 is the locking script [Checksig P A ], which is UTXO 0 In order for the UTXO to be redeemed (strictly speaking, 0 (For any subsequent transaction attempting to redeem the token to be valid), Alice's signature Sig P A [Checksig P A ] is the public key P from Alice's public-private key pair. A Contains a representation (i.e., a hash) of Tx 1 The input 202 of the Tx 1 (for example, transaction ID TxID 0 Here, in the embodiment, the TxID is indicated by 0 is a transaction Tx 0 A pointer to the entire Tx 1 The input 202 of the Tx 0 UTXO from all other possible outputs of 0 To identify the Tx 0 UTXOs in 0It has an index that identifies the Tx 1 Input 202 is also an unlocking script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from a key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a locking script, or by a node protocol, or by a combination of these.

[0047] New transaction Tx 1 When the locking script arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script meets the conditions defined in the locking script (where the conditions may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' represents concatenation, '<...>' means to put data on the stack, and '[...]' are the functions the locking script contains (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, these scripts will be executed in the same order as Tx 0 Alice's public key P as included in the locking script in the output of A Using Tx 1 The input of Tx authenticates that the unlocking script contains Alice's signature signing the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data is 1(Thus, a separate element specifying the signed portion of the data in plaintext need not be included, since that is essentially already present).

[0048] The details of public-private cryptographic authentication are familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key, the plaintext, and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or transaction, etc., may, in embodiments, mean signing a hash of that piece of data or transaction.

[0049] Tx 1 The unlocking script in Tx 0 If one or more conditions specified in the locking script of 1 ) and the blockchain node 104 is Tx 1 This means that the blockchain node 104 considers Tx 1 This means adding the transaction Tx to the ordered pool of pending transactions 154. The blockchain node 104 also 1 to one or more other blockchain nodes 104 in the network 106, so that the transaction Tx 1 is disseminated throughout the network 106. 1 Once validated and included in the blockchain, this is called Tx 0 UTXO from 0 Define Tx as consumed. 1Note that Tx can be legal only if it consumes an unconsumed transaction output 203. 1 If a transaction 152 tries to consume an output that has already been consumed by another transaction, Tx 1 is fraudulent even if all other conditions are met. Therefore, the blockchain node 104 also 0 It is also necessary to check whether the referenced UTXO in has already been spent (i.e., whether it already formed a legitimate input to another legitimate transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for the blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has been spent with, but what ultimately defines whether a UTXO is spent is whether it already formed a legitimate input to another legitimate transaction in the blockchain 150.

[0050] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction is neither propagated nor included in block 151.

[0051] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Some of the amount defined in the UTXO is "left behind" as unspent, while other parts are not spent. However, the amount from the UTXO may be split among multiple outputs of subsequent transactions. For example, Tx 0 UTXO in 0 The amount defined in is Tx 1 Therefore, if Alice receives a UTXO 0If Alice does not want to give Bob the full amount defined in Tx 1 At the second output of the transaction the user can give the change to himself or herself or pay another party.

[0052] In practice, Alice would normally also need to include a fee for any Bitcoin nodes 104 that successfully include her transaction 104 in a block 151. If Alice does not include such a fee, Tx 0 Since a transaction 152 may be rejected by a blockchain node 104, it may not be disseminated or included in the blockchain 150 even if it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, a transaction fee does not require a unique separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount indicated by the input 202 of a given transaction 152 and the total amount specified in the output 203 is automatically given to the blockchain node 104 that issues the transaction. For example, a UTXO 0 A pointer to Tx 1 is the only input to the Tx 1 Only one output UTXO 1 Let us assume that we have UTXO. 0 The amount of digital assets specified in 1 If the UTXO is greater than the amount specified in 1 The difference may be allocated (or consumed) by the node 104 that wins the proof-of-work race to create a block containing . However, it is not necessarily excluded that the transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of the transaction 152.

[0053] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number that defines the entire balance of a given party 103 stored anywhere in the blockchain 150. It is the role of the wallet function of the client application 105 to collate together the values ​​of all the various UTXOs locked to each party and that have not yet been spent in another onward transaction. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0054] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the locking script, creates a non-consumable output of the transaction that can store data within the transaction, thereby recording the data immutably in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0055] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs that the digital signature signs depend on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0056] A locking script may be referred to as a "scriptPubKey", referring to the fact that the locking script typically comprises the public key of the party to whom the respective transaction is locked. An unlocking script may be referred to as a "scriptSig", referring to the fact that the unlocking script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0057] Side Channels As shown in FIG. 1, the client applications of each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of an interested party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 without the transactions 152 being registered in the blockchain network 106 or entering the chain 150 (yet) until one of Alice and Bob chooses to broadcast the transaction 152 between Alice and Bob to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction related data, such as keys, negotiated amounts or terms, data content, etc.

[0058] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b, or the like. In general, the side channel 107 referred to anywhere in this specification may comprise any one or more links over one or more networking technologies or communication media for exchanging data "off-chain", i.e., separately from the blockchain network 106. If more than one link is used, the bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data, etc., over the side channel 107, this does not necessarily imply that all such data must be transmitted over exactly the same links, or even the same type of network.

[0059] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the presently disclosed schemes. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the transaction-related functions of the client 105 infrastructure, such as orchestrating transactions 152, receiving and / or sending transactions and / or other data via a side channel 301, and / or sending transactions to one or more nodes 104 for dissemination through the blockchain network 106, in accordance with the schemes discussed above and as will be discussed in more detail shortly. According to embodiments disclosed herein, the transaction engine 401 of each client 105 may comprise a function 403.

[0060] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of each user's computing device 102, including outputting information to each user 103 via user output means of the device 102 and receiving input from each user 103 via user input means of the device 102. For example, the user output means may comprise one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means may comprise, for example, one or more touch screen input arrays (same or different as those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or audio input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0061] Note: although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting, and instead they may be implemented as a suite of two or more separate applications, e.g. one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

[0062] 3B provides a mock-up of an example of a UI 500 that may be rendered by a user interface (UI) layer 402 of a client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by a client 105b on Bob's device 102b or on any other participant's device.

[0063] 3B illustrates a UI 500 from Alice's perspective. The UI 500 may comprise one or more UI elements 501, 502, 503 that are rendered as separate UI elements via user output means.

[0064] For example, the UI elements may comprise one or more user selectable elements 501, which may be different on-screen buttons, or different options in a menu, etc. User input means are adapted to allow the user 103 (in this case Alice 103a) to select or otherwise act on one of the options, such as by clicking or touching the UI element on the screen, or by speaking the name of the desired option (note that the term "manual" as used herein is intended only to contrast with automatic and is not necessarily limited to use of the hand).

[0065] Alternatively or additionally, the UI elements may include one or more data entry fields 502, through which a user can... These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or a touch screen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0066] Alternatively or additionally, the UI element may comprise one or more output information elements 503 to output information to the user. For example, this / these may be rendered on a screen or audio.

[0067] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not essential. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is only a schematic mockup, and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0068] Node Software FIG. 4 illustrates an example of node software 450 executed on each blockchain node 104 of the network 106 in the example of the UTXO-based model or the output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required for a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but is not limited to, all three of the following: an agreement module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlocking script in Tx j Based on the pointer at the input of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx i Alternatively, Tx i , may not yet have been published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. iIn any case, the script engine 451 may extract Tx i locates the locking script in the referenced output of and passes it to the script engine 452.

[0069] Therefore, the script engine 452 executes the Tx i Locking script and Tx j For example, Tx 0 and Tx 1 2, the same can be applied to any pair of any transactions. The script engine 452 executes the two scripts together as previously discussed, which includes putting data on and taking data off the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0070] By executing the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the locking script "unlocks" the output it is included in. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, the script engine 452 returns the result "true". Otherwise, it returns the result "false".

[0071] In the output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, such as Tx j the aggregate value of the Digital Assets specified in the output of Tx will not exceed the aggregate value indicated by its input; jThe protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol level conditions, and accepts the transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j is actually validated, the decision engine 454 will j , which may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to the nodes of the transaction 154 for inclusion in the block 151. j and a consensus module 455C that adds Tx j and a propagation module 455P that forwards the transaction to the application level decision engine 454. Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only under the condition that the transaction is legitimate and has sufficient transaction fees remaining.

[0072] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed only in the form of a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or negative outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of the signature and an additional positive output of the smart contract (if both individual outcomes are true, the overall outcome is considered to indicate true).

[0073] COMMUNICATION SYSTEM, METHOD, AND COMPUTER PROGRAM A network may be used to communicate and manage one or more devices. Each network may have a corresponding controller. In some examples, devices in the network (non-controller devices) may comprise devices that operate using small amounts of energy. Such devices may be referred to as low power electronics (LPEs). In the following, devices in a local network controlled by a controller may be referred to as "LPEs", but it will be understood that one or more of the LPE devices may be replaced with other devices that are not LPE devices. LPE devices may comprise, for example, Internet of Things (IoT) devices, such as IoT sensors. It should be noted that although some examples are applicable to systems comprising LPE devices, the methods and systems disclosed herein are also applicable to other types of devices.

[0074] In an example, a local network comprising a controller and one or more devices is created and managed by the controller. The network is enabled to participate in internal and external communications through blockchain transactions. Transactions in the network can be verified using the blockchain.

[0075] As LPE devices, such as IoT devices, become more commonly used, communication protocols that match the efficiency requirements of LPE devices are needed. These communication protocols can also be used with other types of devices to improve the efficiency of operation. Some examples disclosed herein also maintain data integrity of any form of communication within the system. Some examples disclosed herein also provide a system that allows for verifiability of communication within the system.

[0076] Some examples describe blockchain-based communication protocols, which may comprise a Bitcoin-based communication protocol, which may enable low-bandwidth and / or low-energy communications while natively embedding blockchain-based inherent capabilities as infrastructure services for notarization, data integrity, and attestation.

[0077] Some examples may provide a communication protocol within a system that communicates internally at some network layer, and any external communication (incoming or outgoing) to the system can be verified as a transaction on the blockchain.

[0078] An example of a network layer is shown in Figure 5. In the example of Figure 5, the Internet protocol suite (Transport Control Protocol / Internet Protocol (TCP / IP)) is shown, but it will be understood that the methods disclosed herein may be applied to other network configurations.

[0079] The Internet Protocol Suite (TCP / IP) defines a set of protocols used for communication in computer networks. The Internet Protocol Suite (TCP / IP) is conceptually structured in a system 558 that comprises four layers that describe, at different levels of granularity, how data is transmitted. The first layer 550 comprises the link layer. The link layer 550 may be used for Ethernet, Wi-Fi, or digital subscriber line (DSL) communications.

[0080] Above the link layer 550 is an internet layer 552 that can be used, for example, for internet protocol communications. Above the internet layer 552 is a transport layer 554. The transport layer 554 can be used for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) communications. The application layer 556 can be used for at least one of HyperText Transfer Protocol (HTTP) communications, Transport Layer Security (TLS) / Secure Sockets Layer (SSL) communications, Domain Name System (DNS) communications, and Point of Presence (POP) communications.

[0081] The Internet layer 552 defines how devices identify and find themselves on a network. It contains the methods, protocols, and specifications used to address and transport packets across and between different networks. At the core of the Internet layer 552 is the IP protocol, which is widely used for packet destination addressing and routing.

[0082] Some of the examples disclosed herein define peer-to-peer (P2P) protocols that can be utilized at the same level as the Internet layer 552, allowing low-power devices (e.g., IoT devices) to communicate with the blockchain in a network. The protocols disclosed herein can be applied to any type of system of devices, but are useful for LPE devices, such as IoT devices, which are generally very low-power tools that are not connected to a power source. Due to the limited amount of energy available, LPE devices require efficient hardware and slow, low-energy communication protocols. The protocols disclosed herein allow communication between devices and the blockchain using a local network. The local network may comprise an ad-hoc local network.

[0083] In one specific example, the protocol may be referred to as the "P2P Bitcoin Internet Layer Protocol" or BILP. Note, however, that the protocol is not limited to use with Bitcoin (other blockchains may be used) nor is it limited to the Internet layer (it may operate at various layers of a communications network).

[0084] The system 600 comprises a controller device 660. One or more devices 662a, 662b, and 662c can communicate with an external network via the controller 660. At least one of the one or more devices 662a, 662b, and 662c may comprise an LPE. The local network 690 may comprise the controller 660 and one or more devices 662a, 662b, and 662c. The controller 660 may be used to manage the network 690 and coordinate the one or more devices 662a, 662b, and 662c. Although three devices 662a, 662b, and 662c are shown in the system 600, the network 690 may comprise more or fewer devices.

[0085] The controller 660 and one or more devices 662a, 662b, and 662c may communicate within a local network 690 within a network layer. For example, communication within the local network 690 may occur at the Internet layer.

[0086] 6, controller 660 may communicate with device 662a via connection 666a. Controller 660 may also communicate with device 662b via connection 666b. Device 662b may communicate with device 662c via connection 666d. Device 662c may communicate with device 662a via connection 666c.

[0087] The controller 660 may communicate with devices outside the network 690. The controller may communicate with the blockchain 150 (which may be a blockchain node or a blockchain network) via a connection 664. In some examples, the connection 664 comprises a TCP / IP connection. In some examples, the connections 666a, 666b, and 666c comprise low power connections. By way of example, the low power connection may comprise, for example, a Bluetooth Low Energy connection.

[0088] The controller 660 may sequence messages from devices 662a, 662b, and 662c into blockchain transactions (e.g., Bitcoin transactions) and send the blockchain transactions to the blockchain 150. By exchanging information structured within blockchain transactions, devices 662a, 662b, and 662c can communicate among themselves (exchanging updates and passing messages), communicate with external resources, and upload / retrieve data to / from the blockchain 150. Thus, the communication protocol can provide native data integrity and attestation for low-bandwidth, low-energy communications.

[0089] In some examples, the only device in the system 690 that is connected to the Internet is the controller 660, and devices 662a, 662b, and 662c communicate with the controller or with each other via low-power connections.

[0090] In some examples, the network 690 comprises a local network. In some examples, the network 690 comprises an ad-hoc network. The network 690 that follows the BILP rules may be considered to comprise a "BILP network."

[0091] The controller 660 may be the most capable device in the network 690. The controller 660 may act as a coordinator for the other devices 662a, 662b, and 662c. The controller 660 may be the only device in the network 660 that interacts with the blockchain 150. In some examples, the controller 660 may comprise a wired device with sufficient power and bandwidth to maintain a stable connection with the blockchain and to receive and broadcast blockchain transactions. In some examples, the controller 660 may manage the other devices in the network 690. In some examples, the controller 660 may collect transactions from and route transactions to the devices 662a, 662b, and 662c.

[0092] The devices 662a, 662b, and 662c may comprise LPE devices, such as IoT sensors. Such devices may be designed to sacrifice some performance in exchange for low energy consumption and long battery life. Such devices are typically wireless IoT devices that communicate low power, infrequently with a central coordinator, which may be the controller 660. To increase the robustness and resilience of the network, in some implementations, the devices 662a, 662b, and / or 662c may also broadcast messages coming from other devices (e.g., other LPEs) to the controller 660 and vice versa, creating a mesh network 690.

[0093] In BILP, the power requirements for one or more of the devices 662a, 662b, and 662c are low: the devices 662a, 662b, and 662c only need enough computational power to create and sign a raw transaction and send it to the controller 660, other than the energy / computation needed to accomplish the task they are designed for (e.g., measuring temperature, recording some activity).

[0094] Devices 662a, 662b, and 662c may uniquely identify themselves using an identifier, e.g., a public key. For simplicity and compatibility, in some examples, the public key may be derived from a private key according to the same rules used to generate public keys for blockchain (e.g., Bitcoin) transactions. Data from devices 662a, 662b, and 662c transmitted from inside and outside the network 690 may be signed using the corresponding private keys of devices 662a, 662b, and 662c to create an unalterable association between the data from the device and the device that published it. For example, it is always possible to track which device published any given information, or to retrieve all information published by a single device. Since the private key is embedded in the device, the signature may also be used as a form of authentication.

[0095] The networks described herein (including the BILP network) can be divided into two classes depending on who funds transactions containing messages and data to be published on the blockchain 150. In the first class, "controller pays all," the controller 660 acts as a master peer, broadcasting messages to the blockchain and funding transactions for the entire BILP network. This approach can be chosen when the LPE devices 662a, 662b, and 662c are trusted and managed by the controller 660 (e.g., a set of IoT sensors in a building). In the second class, "LPE pays itself," the controller 660 acts as a coordinator and a gateway to the blockchain 150, but each LPE 662a, 662b, and 662c is responsible for funding the information they want to share and publish. This approach should be chosen when the LPE devices 662a, 662b, and 662c are independent entities and may connect temporarily to the BILP network 690 (eg, an electric vehicle connecting to a vehicle charging station).

[0096] BILP networks such as network 690 may be used in system-to-system exchanges and IoT groups, where transactions are signed by multiple parties and arranged by a gateway to be sent to blockchain 150. Controller 660 may be connected to blockchain 150. In some examples, controller 660 may be connected to blockchain 150 through an mAPI gateway as discussed in the "Merchant API documentation" https: / / github.com / bitcoin-sv-specs / brfc-merchantapi using a standard Internet connection (i.e., IP protocol). In this manner, controller 660 may act as a gateway and transaction broadcaster to / from blockchain and LPEs 662a, 662b, and 662c.

[0097] Communications 666a, 666b, and 666c between LPEs 662a, 662b, and 662c in the same BILP network 690 may comprise P2P or peer-to-controller connections according to BILP. In specific cases, some of the BILP transactions may be structured using the Metanet protocol [BSV wiki, "Metanet Protocol", https: / / wiki.bitcoinsv.io / index.php / Metanet_Protocol], for example, when the transactions have an implicit hierarchy or require access control.

[0098] Devices such as LPEs 662a, 662b, and 662c that belong to the same network 690 may be identified using a unique ID. Each LPE 662a, 662b, and 662c communicates its ID to interested parties (including the controller 660). The device's ID may be a public key selected by the respective device (generated from a private key that it controls), or alternatively, a hash derived from unique LPE hardware and software. In the following, without loss of generality, LPEs 662a, 662b, and 662c are identified in the local network using public keys, but it will be understood that hashes or any other form of identification may be used. The controller 660 maintains the identification information of the LPEs 662a, 662b, and 662c. The identification information may comprise a list of IDs, called an ID table, that comprises the identifiers (e.g., public keys) of all of the connected LPEs 662a, 662b, and 662c.

[0099] The identification information stored in the controller 660 may comprise a list (ID table) of identifiers of connected LPEs 662a, 662b, and 662c. An LPE may be removed from the ID table if the LPE actively signals its intention to leave the network 690 or if the LPE stops responding to messages to the controller 660 for too long a period of time (exceeding a predetermined time threshold).

[0100] For the communication protocol disclosed herein, three modules may be used. An outbound communication module and an inbound communication module may be used for external devices, and a local communication module may be used within the local network 690. The three modules are: Outbound communication: Devices 662a, 662b, and 662c (e.g., LPEs) want to send messages to other devices or applications outside the network 690 (e.g., upload data to the blockchain). Inbound communication: Devices 662a, 662b, and 662c (e.g., LPEs) want to receive messages from other devices or applications outside the network 690 (e.g., download data from the blockchain). · Local communication: Devices 662a, 662b, and 662c (eg, LPEs) wish to communicate with other devices 662a, 662b, and 662c within the same network 690.

[0101] A message may comprise any type of information sent from / to devices 662a, 662b, and 662c (e.g., to an LPE device). This includes communication messages, plain or encrypted data, and any other type of information. This information may be just data (such as other protocols in the Internet layer) as received from a higher layer in the Internet Protocol suite (e.g., from TCP or UDP). Alternatively, it may be application level information (e.g., communication messages). In the latter case, BILP is considered to be a protocol that spans from the Internet layer to the application layer of the Internet Protocol suite.

[0102] Communication between multiple BILP networks is generally done through the blockchain for auditability reasons (outbound and inbound communication protocols). In concrete situations, for example when higher privacy is required, two or more BILP networks can be connected through their respective controllers (e.g., via a VPN). In this case, communication is not stored on-chain, but instead follows a local communication protocol where the controller collects message transactions in the network and broadcasts them between the networks.

[0103] Depending on the network configuration, a controller such as controller 660 can operate in two modes: as a router or as a peer.

[0104] The first mode, "router mode," is shown in FIG. 7. When the controller 660 is in router mode, in addition to the ID table, the controller 660 tracks all connected LPEs 762a, 762b, 762c, and 762d in the local network 790 and also stores information on how to connect to each LPE device. This additional information is stored in a separate table called the LPE address table 764. The controller 660 uses the LPE address table 764 to locate the indicated LPE and sends messages only to the indicated LPE. The router acts as a central communication point. In some examples, the router mode may be preferred for networks with a star topology. In router mode, all devices are connected to the controller 660, which maintains a table of addresses 764 to send direct messages to the intended recipients. The LPE address table may be considered to comprise address information comprising the addresses of each of one or more devices 762a, 762b, 762c, and 762d in the network 790. In the router mode, sending the message by the controller 660 to at least one of the one or more devices may include sending at least one message directly to at least one of the one or more devices 762a, 762b, 762c, and 762d in the network 790 based on the address information. The controller 660 shown in Figures 6, 7, and 8 may be the same controller that operates in different modes or network configurations. However, in some examples, a different controller may be used in each mode or network configuration. Furthermore, although the LPEs shown in each of Figures 6, 7, and 8 are labeled with different reference numbers, there may be some overlap between the LPE devices shown in the figures. For example, the LPE device 662a may comprise the LPE device 762a. In a further example, the LPE device 762a may comprise the LPE device 862a.

[0105] A second mode, "peer mode," is shown in FIG. 8. When the controller 660 is in peer mode, the controller 660 is not required to keep track of the LPEs 862a, 862b, 862c, and 862d in the local network 890 (i.e., it is not necessary to store an LPE address table, only an ID table is maintained). Messages are broadcast to the controller 660's neighborhood, and the controller 660 broadcasts messages to its neighborhood until the message reaches all peers. A device may be considered to be adjacent to another device in the network to which it has a direct connection. An interested peer recognizes (and optionally decodes) messages addressed to it. This configuration allows for the creation of redundant interconnections between peers. In networks with a mesh topology, peer mode may be preferred. In peer mode, a device may be connected to the controller or another device, and messages are broadcast to all peers until the message reaches the recipient. In peer mode, sending a message to at least one of the one or more devices 862a, 862b, 862c, and 862d in the network 890 may include broadcasting, by the controller 660, the at least one message to one or more neighboring devices in the network, which broadcast the at least one message to one or more further neighboring devices until the at least one message is delivered to the at least one of the one or more devices.

[0106] When in peer mode, communication relies on LPEs broadcasting messages to their neighbors. However, LPEs may want to be as efficient as possible and in some instances may not spread messages. In some implementations, message spreading may be forced, for example, by blacklisting LPEs that do not broadcast messages. This may be accomplished by the controller 660 actively monitoring the network and removing identifiers (e.g., public keys) of rogue LPEs from the ID table (i.e., outbound communication is disabled for these LPEs).

[0107] In some examples, for additional security, messages may be encrypted using the public key of the receiver (or intended recipient). In this way, only the intended receiver can decrypt the message using the corresponding private key. In some examples, encryption methods may be used to provide authenticity of the data so that the LPE knows that the data has not been altered after it is put onto the blockchain or similarly when it is received at the LPE from an external sender.

[0108] The outbound communication module may be used for communication to external devices (e.g., devices outside the network 690 of FIG. 6). Data may be stored / certified on-chain using the outbound communication module. Uploads from the BILP local network to the blockchain may use coordination between the LPE and the network's controller 660. Funds management may be used to pay the correct amount of fees when publishing blockchain transactions on-chain.

[0109] The outbound communication module may be managed through a communication round (BILP communication round). The controller 660 may maintain identification information for each device 662a, 662b, and 662c in the network 690. The identification information may comprise an index number assigned to each device. Each communication round may be initiated by the controller 660. The controller 660 assigns an index number to each device in the network. This may be performed using an ID table. The index number of a particular device may be communicated from the controller 660 to each particular device. The index number indicates an egress point index reserved for the particular device. Each device (e.g., LPE device) identifier (e.g., public key) may be mapped to an egress point. Each device may then create a blockchain partial transaction (e.g., input-output pair) into which the device inserts the data it wishes to broadcast using its assigned index number. The data may be signed using the device's private key. The data may include measurements (e.g., sensor measurements) made by the device. For example, data may be inserted using the OP_RETURN function or using the OP_PUSH and OP_DROP functions. The partial transactions (input-output pairs) generated by each LPE are then broadcast to connected LPEs, which then rebroadcast to their neighbors. If an LPE has multiple connections, it may receive the same partial transaction multiple times, in which case all duplicate messages can be safely discarded.

[0110] When a new round of communication begins, a device (e.g., an LPE) can create a blockchain (e.g., Bitcoin) transaction with the flags SIGHASH_SINGLE|ANYONECANPAY and fill in the inputs and outputs corresponding to the indexes assigned by the controller 660. This partial transaction is sent to the controller 660.

[0111] [Table 1]

[0112] At the end of each communication round, the partial transactions may be arranged by the Controller 660 in a new transaction (a “BILP transaction”) to be published on-chain.

[0113] BILP transactions are data structures that use the blockchain (e.g., Bitcoin) transaction protocol to broadcast information within the network and publish them to the blockchain 150 through the controller 660. Each transaction includes an input / output pair for each LPE connected to the network (according to its assigned output point index) and a signature from the controller 660.

[0114] When a communication round begins, a device (e.g., an LPE) can create its own partial transaction or append its own inputs and outputs to an existing partial transaction (if it has received it at least once). In both cases, the device just fills in the input / output pairs with indices assigned by the controller 660 so that a single transaction can be confirmed and consolidated by the controller 660 in the completed BILP transaction. Depending on the network type, the output point TxID LPEi It may be a simple dust transaction used to sign and attest data ("controller pays all"), or it may contain enough value (e.g., satoshis) to fund the transaction ("LPE pays itself"). Note that devices do not have change addresses, and in the latter approach, any additional funds are collected by the controller 660. In both cases, each device may use a preloaded list of UTXOs that will be spent over time.

[0115] In some implementations, a communication round may be preceded by an acknowledgement round, in which only devices willing to communicate indicate their intent to communicate. In this case, only devices that have indicated interest are assigned an output point index by the controller 660 in the next BILP transaction. A device may skip some rounds to gain more energy efficiency at the expense of output frequency. Before receiving one or more input-output pairs from one or more devices in the network 690 for generating a blockchain transaction by the controller 660, the controller 660 may send a request to each of the one or more devices to confirm their intent to participate in the round of communication. In response to the request, the controller 660 may receive an indication of intent to participate in the round of communication from at least one of the one or more devices.

[0116] Once all intended devices have broadcasted their partial transactions, the controller 660 may generate a blockchain transaction based on one or more input-output pairs received from the devices. This may be performed by the controller 660 arranging the input-output pairs into the same transaction. Before sending the blockchain transaction to the blockchain, the controller 660 may add an additional output point to the blockchain transaction, which indicates that the controller has signed all of the inputs and all of the outputs of the blockchain transaction. For example, the controller 660 may add an additional output point with a SIGHASH_ALL flag to attest the transaction and make the transaction immutable. If the network is "controller pays all", the controller 660 output point may also include the amount (e.g., satoshis) required to fund all other output points in the transaction and may also add the associated controller 660 change output (see table 1). Finally, the controller 660 broadcasts the completed BILP transaction to the blockchain (i.e., blockchain 150) to attest the data and message.

[0117] [Table 2]

[0118] The inbound communication module can be used to download data from the blockchain to the local (BILP) network. The inbound communication module can also be used to retrieve external messages.

[0119] In some examples, to maintain compatibility with other modules, the inbound module may follow the same rules and structure as the outbound module. The controller 660 takes messages from the blockchain and sends them to interested devices according to the configured controller type (router mode or peer mode as discussed above). Router mode: The controller 660 sends a message to the indicated LPE (according to a public key or other identifier). Interested devices decrypt the message. Peer mode: The controller 660 broadcasts a message to its neighbors, who then broadcast it to their neighbors until the message reaches all peers. Interested peers recognize and decode the message.

[0120] An example of a transaction being taken from the blockchain and sent to the three LPEs is shown in Table 3.

[0121] [Table 3]

[0122] The controller 660 can identify transactions destined for the internal (BILP) network by monitoring the blockchain for transactions that identify (comprise) an identifier (e.g., a public key) of at least one of the one or more devices 662a, 662b, and 662c in the network 690, or by using other available techniques (e.g., an external sender can announce them to the controller 660, the announcement comprising a public key or other identifier of at least one of the one or more devices 662a, 662b, and 662c). The controller 660 can identify transactions on the blockchain that comprise at least one message that is destined for at least one of the one or more devices in the network, then retrieve the at least one message from the blockchain and send the at least one message to at least one of the one or more devices 662a, 662b, and 662c in the network 690. The techniques used to identify inbound transactions and retrieve them are similar to other applications (e.g., wallets).

[0123] A local communication module can be used to exchange messages within the same network, and these locally communicated messages are not recorded on the chain. For inbound modules, depending on the network configuration, the controller 660 can act as a router or a peer. Router mode: The device always sends messages to the controller 660, which in turn sends the messages to the indicated LPEs (according to a public key or other identifier). Interested peers decrypt the messages. Peer mode: A device broadcasts a message to its neighbors, who then broadcast it to their neighbors until the message reaches all peers. Interested peers recognize and decode the message.

[0124] To maintain compatibility and consistency with other modules, the local communication module may follow the same rules and structure as the previously described modules. In this module, there is no need to pre-allocate an index (i.e., sequence number) using the BILP communication round protocol (defined in the outbound module) since it is not necessary for the transaction to be completed by the controller 660 or broadcast externally. After being shared internally, the transaction can be discarded. Any LPE willing to communicate can create a Bitcoin transaction with the flags SIGHASH_SINGLE|ANYONECANPAY (Table 4). Depending on the network configuration, the transaction is sent to the controller 660 (router mode) or to the LPE's neighbors (peer mode).

[0125] From the perspective of the controller 660, when operating in a router mode using a local communication module, the method may include receiving a message from a first device in the network, the message being addressed to a second device in the network, and transmitting the message to the second device in the network. The controller 660 may then discard the message after transmitting to the second device in the network.

[0126] From the perspective of the controller 660, when operating in peer mode using the local communication module, the method may include receiving a message broadcast from a neighboring device in the network, the message being addressed to a third device in the network, and broadcasting the message to one or more neighboring devices in the network. The controller 660 may then discard the message after transmitting it to the one or more neighboring devices in the network.

[0127] Note that these transactions are for internal communication only (they are not published on the chain) and for this reason they do not need to be funded (spent transaction outputs can be reused). They keep the blockchain transaction structure only for compatibility with other communication modules. For other communications, messages can be encrypted using the receiver's public key for additional security.

[0128] [Table 4]

[0129] In some use cases, it can be useful to maintain and prove the order in which messages were sent (for example, internal communication where two devices exchange data). In this case, messages can be grouped into threads. Threads do not require any additional logic; they are just agreed upon between two or more devices. If a message is part of a thread of messages, other LPEs can append their messages to the same transaction (SIGHASH_SINGLE|ANYONECANPAY is used). Using sequence numbers, the order in which messages are created is recorded in the transaction. This allows the creation of an ordered sequence of messages for internal communication. Since internal communication is completely off-chain, ordering cannot be enforced, rather it is a choice by the LPE to respond to an existing thread by appending a message to an existing transaction.

[0130] Each time a transaction is updated with new data (i.e., an output pair), the message transmission protocol (router mode or peer mode) can be restarted (i.e., local rebroadcast) since the updated message is equivalent to a new message.

[0131] [Table 5]

[0132] When using the inbound or outbound communication module, a record of data sent from the local network may be stored in the blockchain. When using the local communication module, no record may be sent.

[0133] In some examples, communications within the local network are performed at the Internet Layer of the Internet Protocol Suite.

[0134] The data transmitted by one or more devices (LPEs) of the network may comprise at least one of temperature, humidity, air quality, and image information of an area of ​​the environment.

[0135] The protocol described above can be used in building management. IoT devices can communicate and share information through the BILP network. All data and messages are automatically attested on-chain. Public information can be made available by broadcasting directly to potential users, while confidential information can be attested by only revealing a hash digest. As an example, IoT sensors can monitor temperature and humidity in a workplace to attest to air quality, while other sensors can record entry into restricted areas.

[0136] The protocol described above may be used in an automobile charging station. An electric vehicle may connect to the BILP network of the charging station and use it to record information such as charging time and cost. This information may be used later for analysis or billing purposes. Moreover, the car may securely receive updates or notifications from the vehicle manufacturer or other services. In such an example, one or more parameters of an electric vehicle charging session may be recorded. For example, the parameters may comprise at least one of charging time, cost, and energy used.

[0137] Further findings Other variations or uses of the disclosed techniques may become apparent to those of ordinary skill in the art given the disclosure herein, and the scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

[0138] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any reference above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with a reference to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0139] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of disseminating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0140] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, on those other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but not store and / or disseminate those blocks 151 to other nodes.

[0141] Even more generally, any reference above to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element,” where such entity / element is configured to perform some or all of the roles of creating, publishing, disseminating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0142] It will be appreciated that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0143] Statement 1: A computer-implemented method, the method being executed by a controller configured to communicate with a blockchain and a network comprising one or more devices, the method comprising: maintaining identification information comprising an index number assigned to each of the one or more devices; receiving one or more input-output pairs of a blockchain transaction, each input-output pair being associated with an assigned index number, each input-output pair comprising data from a device of the one or more devices; generating a blockchain transaction based on the one or more input-output pairs; and sending the blockchain transaction to the blockchain.

[0144] Statement 2: The method according to Statement 1, comprising: assigning an index number to each of the one or more devices by mapping an identifier of each of the one or more devices to an index number; and communicating to each of the one or more devices the index number assigned to the device.

[0145] Statement 3: A method according to Statement 1 or Statement 2, comprising: prior to receiving one or more input-output pairs of a blockchain transaction, sending a request to each of the one or more devices to confirm intent to participate in the round of communication; and receiving, in response to the request, an indication of intent to participate in the round of communication from at least one of the one or more devices.

[0146] Assertion 4: A method according to any preceding assertion, in which data from the device of the one or more devices is signed with a signature corresponding to the device's public key.

[0147] Assertion 5: A method according to any preceding assertion, comprising adding an additional output point to the blockchain transaction prior to sending the blockchain transaction to the blockchain, the additional output point indicating that the controller has signed all of the inputs and all of the outputs of the blockchain transaction.

[0148] Statement 6: The method according to Statement 5, wherein the additional output point comprises an amount to fund all other output points in the blockchain transaction.

[0149] Statement 7: A method according to any preceding statement, comprising the steps of identifying a transaction on the blockchain comprising at least one message destined for at least one of the one or more devices in the network, retrieving the at least one message from the blockchain, and sending the at least one message to the at least one of the one or more devices.

[0150] STATEMENT 8: The method according to STATEMENT 7, wherein identifying transactions in the blockchain includes monitoring the blockchain for transactions that identify at least one identifier of the one or more devices.

[0151] STATEMENT 9: The method according to STATEMENT 7 or STATEMENT 8, wherein the step of identifying a transaction in the blockchain comprises the step of receiving a notification from a device external to the network, the notification including an identifier of at least one of the one or more devices.

[0152] STATEMENT 10: The method according to any of STATEMENTS 7 to 9, comprising maintaining address information comprising an address of each of the one or more devices, and wherein sending at least one message to at least one of the one or more devices comprises sending at least one message directly to at least one of the one or more devices based on the address information.

[0153] Statement 11: The method according to any of statements 7 to 9, wherein the step of sending the at least one message to at least one of the one or more devices includes a step of broadcasting, by the controller, the at least one message to one or more neighboring devices in the network, the one or more neighboring devices broadcasting the at least one message to one or more further neighboring devices until the at least one message is delivered to the at least one of the one or more devices.

[0154] Statement 12: A method according to any preceding statement, comprising receiving a message from a first device in the network, the message being addressed to a second device in the network, and transmitting the message to the second device in the network.

[0155] Statement 13: The method according to statement 12, including discarding the message after transmitting to a second device in the network.

[0156] Statement 14: A method according to any of statements 1 to 11, comprising the steps of receiving a message broadcast from a neighboring device in the network, the message being addressed to a third device in the network, and broadcasting the message to one or more neighboring devices in the network.

[0157] Statement 15: The method according to statement 14, comprising discarding the message after transmitting to one or more neighboring devices in the network.

[0158] Statement 16: The method according to any of statements 7 to 15, wherein at least one message is encrypted using a public key of an intended receiving device in the network.

[0159] Assertion 17: A method according to any preceding assertion, wherein if at least one of the following occurs: a device of one or more devices signals that it is leaving the network, the device does not respond to messages from the controller for a predetermined period of time, and the device is identified by the controller as not broadcasting messages to neighboring devices, then the index number for the device is removed or assigned to a different device.

[0160] Statement 18: The method according to any preceding statement, wherein the one or more devices comprise one or more Internet of Things (IoT) devices.

[0161] Assertion 19: A method according to any preceding assertion, whereby for every communication from an external entity to the network, a record is stored on the blockchain, and for every communication from the network to an external entity, a record is stored on the blockchain.

[0162] Assertion 20: A method according to any preceding assertion, where communication within the network is performed at the Internet Layer of the Internet Protocol Suite.

[0163] Statement 21: The method according to any preceding statement, wherein the controller is connected to one or more blockchain nodes by a Transport Control Protocol / Internet Protocol (TCP / IP) connection.

[0164] CLAIM 22: The method according to any preceding claim, wherein the data from a device of two or more devices comprises measurements made by that device.

[0165] STATEMENT 23: The method according to any preceding statement, wherein one or more devices of the network are used to monitor parameters of the environment, the parameters comprising at least one of temperature, humidity, air quality, and image information of an area of ​​the environment.

[0166] STATEMENT 24: The method according to any preceding statement, wherein one or more devices of the network are used to record parameters of an electric vehicle charging session, the parameters comprising at least one of charging time, cost, and energy used.

[0167] Statement 25: The method according to any preceding statement, wherein the one or more devices comprise two or more devices, and wherein generating the blockchain transaction based on the one or more input-output pairs includes sequencing the input-output pairs to generate the blockchain transaction.

[0168] Statement 26: A method performed by a system comprising one or more devices and a controller configured to communicate with a blockchain, the method comprising: maintaining, by the controller, identification information comprising an index number assigned to each of the one or more devices; generating, by each of the one or more devices, an input-output pair of a blockchain transaction associated with the assigned index number, the input-output pair comprising data from the device; sending, by each of the one or more devices, the input-output pair to the controller; ordering, by the controller, the input-output pair to generate a blockchain transaction; and sending, by the controller, the blockchain transaction to the blockchain.

[0169] Statement 27: A method performed by a system comprising one or more devices and a controller configured to communicate with a blockchain, the method comprising: maintaining, by the controller, identification information comprising an index number assigned to each of the one or more devices; generating, by each of the one or more devices, an input-output pair of a blockchain transaction associated with the assigned index number, the input-output pair comprising data from the device; sending, by each of the one or more devices, the input-output pair to the controller such that the controller receives the one or more input-output pairs; generating, by the controller, a blockchain transaction based on the one or more input-output pairs; and sending, by the controller, the blockchain transaction to the blockchain.

[0170] Statement 28: The method according to Statement 27, wherein the one or more devices comprise two or more devices, and the step of generating a blockchain transaction based on the one or more input-output pairs includes the step of ordering the input-output pairs to generate the blockchain transaction.

[0171] Statement 29: A computing device comprising a memory having one or more memory units and a processing device having one or more processing units, the memory storing code adapted to be executed on the processing device, the code being configured, when executed on the processing device, to perform a method according to any of statements 1 to 28.

[0172] Statement 30: A computer program embodied on a computer readable storage and configured to, when executed on one or more processors, perform the method of any of statements 1 to 28.

[0173] According to another aspect disclosed herein, a method may be provided for comprising controller activity.

[0174] According to another aspect disclosed herein, a method comprising activity of an LPE device may be provided.

[0175] According to another aspect disclosed herein, a method may be provided that comprises activity of a system that comprises a controller and one or more LPE devices.

[0176] According to another aspect disclosed herein, there may be provided a system comprising a computing device of a controller.

[0177] According to another aspect disclosed herein, a system may be provided that includes a computing device of an LPE device.

[0178] According to another aspect disclosed herein, there may be provided a system comprising a computer apparatus of a system comprising a controller and one or more LPE devices. [Explanation of symbols]

[0179] 101 Internet, packet-switched networks 102 Computer terminals, equipment 103 users 104 Blockchain nodes 105 Client Applications 106 P2P Networks 107 Side Channel 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output 401 Transaction Engine 402 UI Layer 451 Protocol Engine 452 Script Engine 454 Application Level Decision Engine 455 Blockchain-related functional modules 500 UI 501 UI elements, user selectable elements 502 UI elements 503 UI elements, information elements 550 Link Layer 552 Internet Layer 554 Transport Layer 556 Application Layer 558 System 600 System 660 Controller 662 LPE 664 connections 666 Connections 690 Network 762 LPE 764 LPE Address Table 790 Local Network 862 LPE 890 Local Network

Claims

1. 1. A computer-implemented method, the method being performed by a controller configured to communicate with a blockchain and with a network comprising one or more devices, the method comprising: maintaining identification information comprising an index number assigned to each of the one or more devices; receiving one or more input-output pairs of a blockchain transaction, each input-output pair being associated with an assigned index number, each input-output pair including data from a device of the one or more devices; generating a blockchain transaction based on the one or more input-output pairs; sending the blockchain transaction to the blockchain; A method comprising:

2. assigning an index number to each device of the one or more devices by mapping an identifier of each of the one or more devices to the index number; communicating to each device of the one or more devices an index number assigned to the device; 2. The method of claim 1, comprising:

3. sending a request to each of the one or more devices to confirm intent to participate in a round of communication prior to receiving the one or more input-output pairs of the blockchain transaction; receiving, in response to the request, from at least one of the one or more devices an indication of the intent to participate in the round of communications; 2. The method of claim 1, comprising:

4. The method of claim 1 , wherein the data from the device of the one or more devices is signed with a signature corresponding to a public key of the device.

5. 2. The method of claim 1, further comprising adding an additional output point to the blockchain transaction prior to sending the blockchain transaction to the blockchain, the additional output point indicating that the controller has signed all of the inputs and all of the outputs of the blockchain transaction.

6. 6. The method of claim 5, wherein the additional output point comprises an amount for funding all other output points in the blockchain transaction.

7. identifying a transaction on the blockchain comprising at least one message addressed to at least one of the one or more devices in the network; Retrieving the at least one message from the blockchain; sending the at least one message to the at least one of the one or more devices; 2. The method of claim 1, comprising:

8. 8. The method of claim 7, wherein identifying the transactions in the blockchain comprises monitoring the blockchain for transactions that identify an identifier of at least one of the one or more devices.

9. 8. The method of claim 7, wherein identifying the transaction in the blockchain comprises receiving a notification from a device external to the network, the notification comprising an identifier of at least one of the one or more devices.

10. maintaining address information comprising an address of each of the one or more devices; 8. The method of claim 7, wherein sending the at least one message to the at least one of the one or more devices comprises sending the at least one message directly to the at least one of the one or more devices based on the address information.

11. 8. The method of claim 7, wherein sending the at least one message to the at least one of the one or more devices comprises broadcasting, by the controller, the at least one message to one or more neighboring devices in the network, the one or more neighboring devices broadcasting the at least one message to one or more further neighboring devices until the at least one message is delivered to the at least one of the one or more devices.

12. receiving a message from a first device in the network, the message being addressed to a second device in the network; sending the message to the second device in the network; 2. The method of claim 1, comprising:

13. The method of claim 12 , further comprising discarding the message after transmission to the second device in the network.

14. receiving, from a neighboring device in the network, a message broadcast from the neighboring device, the message being addressed to a third device in the network; broadcasting said message to one or more neighboring devices in said network; 2. The method of claim 1, comprising:

15. The method of claim 14, comprising discarding the message after transmission to the one or more neighboring devices in the network.

16. The method of claim 7 , wherein at least one message is encrypted using a public key of an intended receiving device of the network.

17. a device of the one or more devices indicating that the device is leaving the network; the device not responding to messages from the controller for a predetermined period of time; The device is identified by the controller as not broadcasting messages to neighboring devices.

2. The method of claim 1, wherein if at least one of the following occurs, the index number for the device is removed or assigned to a different device.

18. The method of claim 1 , wherein the one or more devices comprise one or more Internet of Things (IoT) devices.

19. For every communication from an external entity to the network, a record is stored in the blockchain; The method of claim 1 , wherein for every communication from the network to an external entity, a record is stored in the blockchain.

20. The method of claim 1 , wherein communication within the network is performed at the Internet Layer of the Internet Protocol Suite.

21. The method of claim 1 , wherein the controller is connected to one or more blockchain nodes by a Transport Control Protocol / Internet Protocol (TCP / IP) connection.

22. The method of claim 1 , wherein the data from a device of two or more of the devices comprises measurements made by the device.

23. 2. The method of claim 1, wherein the one or more devices of the network are used to monitor parameters of an environment, the parameters comprising at least one of temperature, humidity, air quality, and image information of an area of ​​the environment.

24. 2. The method of claim 1, wherein the one or more devices of the network are used to record parameters of an electric vehicle charging session, the parameters comprising at least one of charging time, cost, and energy used.

25. 2. The method of claim 1 , wherein the one or more devices comprise two or more devices, and generating the blockchain transaction based on the one or more input-output pairs comprises sequencing the input-output pairs to generate the blockchain transaction.

26. 1. A method performed by a system comprising one or more devices and a controller configured to communicate with a blockchain, the method comprising: maintaining, by the controller, identification information comprising an index number assigned to each of the one or more devices; generating, by each device of the one or more devices, an input-output pair of a blockchain transaction associated with the assigned index number, the input-output pair comprising data from the device; transmitting, by each device of the one or more devices, input-output pairs to the controller such that the controller receives the one or more input-output pairs; generating, by the controller, a blockchain transaction based on the one or more input-output pairs; transmitting, by the controller, the blockchain transaction to the blockchain; A method comprising:

27. 27. The method of claim 26, wherein the one or more devices comprise two or more devices, and generating the blockchain transaction based on the one or more input-output pairs comprises sequencing the input-output pairs to generate the blockchain transaction.

28. 1. A computer device comprising: a memory comprising one or more memory units; 28. A computing apparatus comprising: a processing device having one or more processing units; and the memory storing code adapted to execute on the processing device, the code being configured, when executed on the processing device, to perform the method of any one of claims 1 to 27.

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

Images