Blockchain-based system and method for publishing an operating system

Abstract

1. A method comprising: identifying, by a client device, one or more target transactions recorded on a blockchain, the one or more target transactions including operating system software stored in a payload of the one or more target transactions, the operating system software including at least a portion of an operating system including at least some executable code of the operating system; accessing the operating system software from the payload of the one or more target transactions stored on the blockchain; and executing, on the client device, the operating system software accessed from the one or more target transactions, the executing step including executing the executable code of the operating system.

Description

[Technical Field]

[0001] The present disclosure relates to the use of blockchains where data content, including software, can be stored in the payload of transactions on the blockchain. [Background technology]

[0002] A blockchain refers to a form of distributed data structure, in which a copy of the blockchain is maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to the preceding transaction in a sequence that may span one or more blocks up to one or more coinbase transactions. Coinbase transactions are further described 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 competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a pool of ordered, validated, outstanding transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and publication of blocks may be achieved by publishing only the block headers.

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

[0004] Nodes (often called "miners") in a blockchain network perform a decentralized transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a block template, and the nodes attempt to identify a valid proof-of-work solution for that block template. Once a valid solution is found, a new block is disseminated to other nodes in the network, allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network for dissemination. Nodes receiving the transaction can compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated or incorporated into a block. 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 to create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., a certain number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit node performance. Publishing only block headers allows participants to ensure 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 specifying an amount of a digital asset derivable from the preceding sequence of transactions. A consumable output is sometimes called a UTXO (or “unspent transaction output”). An output may further comprise a locking script that specifies conditions for further redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or “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 comprises at least one input comprising a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one validity criterion applied at each node is that the unlocking script meets 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, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not disseminate the transaction (or, in some cases, not disseminate the invalid transaction as a valid transaction in order to register it) and will not include the transaction in a new block to be recorded on the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and periodically updated by nodes separate from the blockchain.

[0009] A blockchain network is already a type of overlay network overlaid on an underlying network such as the Internet. However, it is also possible to overlay further layers of overlay networks on a blockchain. One example of this is known as the Metanet. Each node in the Metanet is a different transaction on the blockchain (note that "node" is now used differently and refers to a node in the Metanet rather than a node in a blockchain network). Data content and Metanet metadata are stored in the payload of each such transaction, in the unspendable output of the transaction using OP_RETURN. Data content is the actual user content that the Metanet is used to store, for example, text, images, video, or audio content, while metadata defines the links between Metanet nodes. Links or edges between Metanet nodes do not necessarily correspond to spending edges in the blockchain layer. That is, if the input of a given Metanet transaction points to the output of another, funding transaction in the blockchain layer, the parent of that same transaction, or Metanet node in the Metanet layer, is not necessarily the same transaction as the funding transaction. Instead, links or edges in the Metanet layer define links between data contents in the Metanet. Summary of the Invention [Means for solving the problem]

[0010] The present disclosure provides new techniques that enable publishing operating system software on the blockchain as a live distribution or for installation on client devices.

[0011] According to one aspect of the present disclosure, there is provided a method that includes identifying, by a client device, one or more target transactions recorded on a blockchain, the one or more target transactions including operating system software stored in payloads of the one or more target transactions, the operating system software including at least a portion of an operating system, including at least some executable code of the operating system. The method further includes accessing the operating system software from the payloads of the one or more target transactions stored on the blockchain and executing, on the client device, the operating system software accessed from the one or more target transactions, wherein the executing includes executing the executable code of the operating system.

[0012] Some devices can benefit from a standard, always-available operating system that is stored on the blockchain and may be run live from the chain or downloaded on demand to be installed on the device. Updates may also be published on the chain. For example, this is particularly applicable to Internet of Things (IoT) devices, which use small operating systems and have limited resources. IoT devices may be generated in thousands of copies and scattered over wide areas. Therefore, IoT devices can benefit from a decentralized blockchain solution because they can connect to any available blockchain node that has access to authentic data immutably stored on the chain (they can also use SPV, i.e., Simplified Payment Verification, or similar methods to double-check with other nodes). For example, IoT devices may download and run a live distribution of an operating system available on the chain, and in embodiments, IoT devices may be remotely controlled by their administrators (e.g., using the Bitcoin network to send device-specific commands or code to be executed).

[0013] In embodiments, an overlay network tree structure, such as Metanet, may be used to construct operating system files. In such embodiments, a client device can download, run, or directly boot any compatible operating system from the blockchain; the only information needed is the root of the Metanet tree used to store the unique OS. The same tree may be used to publish commands and code (e.g., smart contracts) to be executed by one or more devices.

[0014] For example, an IoT device may be created with an embedded tree root (e.g., stored in ROM), and the IoT device will always be linked to the same tree, the IoT device will always download the correct version of the operating system and published updates, and the IoT device will execute any code (e.g., smart contracts) published in the tree. As long as the private keys used to create and manage the tree are not compromised, the IoT device is secure and can execute arbitrary code in an evidence-able and even provable manner and using specified libraries and modules.

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

[0016] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] A schematic diagram of a network overlaid on a blockchain. [Figure 4] FIG. 1 is a schematic transaction diagram illustrating an exemplary protocol for overlaying a network such as Metanet onto a blockchain. [Figure 5] 1 is a schematic diagram illustrating an operating system stored in an overlay tree structure (in the illustrated example, a live Linux distribution of Puppy Linux BionicPup32 stored in a Metanet tree). [Figure 6] FIG. 1 is a diagram illustrating an example of an overlay network tree structure, such as a Metanet tree, used to build an OS. [Figure 7]This diagram illustrates the process of updating a file in an overlay network tree structure, such as a Metanet tree, where the current version is replaced by a new version (the new version is a child of the old version) by creating a link from the old version to the new version. [Figure 8] FIG. 1 shows a schematic diagram of an example of executing a command or executing some code, where the command and the code are exposed on the same tree of the operating system. [Figure 9] 1 is a schematic flowchart of an exemplary method performed by a client device, according to embodiments disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

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

[0018] Each blockchain node 104 comprises a peer's computing equipment, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and 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 high-value disk drives.

[0019] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple 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 can be pruned 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, where a transaction in this context refers 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 general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as wealth, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and redeem or spend). Each input points to the output of a preceding transaction 152, thereby linking those transactions.

[0020] 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 the genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0021] Each blockchain node 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 pool 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "memory pool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0022] For a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed, or "consumed," in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152i is created or even transmitted to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to something that precedes in the logical sequence linked by the pointer, and not necessarily to the time of creation or transmission in the chronological order, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may also be referred to as an ancestor transaction or predecessor transaction.

[0023] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j may then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an 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, a transaction 152j may have multiple outputs to divide the amount of the input among multiple users or entities (one of which may be the original user or entity 103a to provide the remaining amount). In some cases, a transaction may also have multiple inputs to pool together amounts from multiple outputs of one or more preceding transactions and redistribute one or more outputs of the current transaction.

[0024] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an institution, wishes to execute a new transaction 152j (either manually or through an automated process used by the party), the executing party transmits the new transaction from the party's computer terminal 102 to a recipient. The executing party or recipient ultimately transmits this transaction directly to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but in principle could also be other user terminals). It is not excluded that the party 103 executing the new transaction 152j can transmit the transaction to one or more of the blockchain nodes 104, but in some instances not to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an 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 the cryptographic signature or other authorization of a party 103 included in the input of a new transaction 152j matches a condition defined in the output of a previous transaction 152i to which the new transaction assigns, 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 chained. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or it may be a combination of these.In any event, 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 manner, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0025] In an output-based model, the definition of whether a given output (e.g., UXTO) is allocated (e.g., spent) is whether it has already been validly redeemed by the input of another prior 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 the transaction attempts to redeem has not already been redeemed by another transaction. Again, if not valid, the transaction 152j is not disseminated (unless flagged as invalid and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, such as when a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining account balances. Again, because there is a defined order of transactions, an account balance has a single defined state at any given time.

[0026] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, aided by "proof of work," in a process commonly referred to as mining. At blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves 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 hash output satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain number of leading zeros. Note that this is just one specific type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. This search can therefore only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0027] A first blockchain node 104 attempting to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that it results in a satisfying hash output). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 is then 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 significant effort required to create the proof-of-work solution, e.g., in the form of a hash, indicates the first node's 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known 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. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0028] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which 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. Protocols also exist for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. That is, whichever tip of the fork has grown longer will become the final blockchain 150. Note that this should not affect users or agents of the network, as the same transactions appear in both forks.

[0029] According to the Bitcoin blockchain (and most other blockchains), a node 104 that successfully constructs a new block is granted the ability to allocate an additional, permitted amount of digital assets in a new, special type of transaction that distributes an additional, defined quantity of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is commonly called a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work indicates the node constructing the new block’s intent to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generational) 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 was published. This fee is commonly called a “mining fee” and is discussed below.

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

[0031] 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 in accordance with the blockchain node protocol. It will be understood that any activity attributable to this specification for a blockchain node 104 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.

[0032] Also connected to the network 101 are computer devices 102 of multiple participants 103, each of which may be an individual user or an organization, in the role of a consuming user. 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 or 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 copies of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0033] 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 called “clients”) are sometimes said to be part of a system that includes the blockchain network 106. However, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each participant 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that more such participants 103 and their respective computing 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. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party" respectively.

[0034] The computing device 102 of each participant 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each participant 103 further comprises 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 memory, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing unit. It will be understood that any activity attributable to this specification for a given participant 103 may be performed using software executing on the processing unit of the respective computing device 102. The computing device 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 smartwatch. The computing equipment 102 of a given participant 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0036] 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, approve (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 so that the transactions 152 are disseminated throughout the network of blockchain nodes 104 and included in the blockchain 150. The other is to report to each party the amount of digital assets that they currently own. In an output-based system, this second function comprises reconciling the amounts defined in the outputs of various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0037] Note: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, interfacing, for example, via an API, or one plugging into another. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0038] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually investigate other party transactions in the blockchain 150, since the blockchain 150 is a public entity that lends credibility to some transactions by virtue of its public presence). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward them to disseminate the transactions 152 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol accompanies a given node protocol and together implements 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.

[0039] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the associated transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the new transaction 152j according to the blockchain node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets any conditions for being "valid," examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validation may be configurable per transaction via a script included in the transaction 152. Alternatively, this condition 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.

[0040] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained by that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j disseminates 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, assuming the transaction 152j is valid, this means that it will soon be disseminated throughout the network 106.

[0041] Once granted access to the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 of transactions, including the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to earlier transactions, the order of the transactions is also immutably recorded.

[0042] 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 accepts it and discards (i.e., treats as invalid) the instance it originally accepted (i.e., the instance not published in block 151).

[0043] An alternative type of transaction protocol operated by some blockchain networks is sometimes 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 an absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of every account is stored and periodically updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called its "position"). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0044] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the 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 to all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0045] In a 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 can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on a distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0046] Suppose Alice 103a wants to create a transaction 152j that transfers a certain amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." Tx1 takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor do they mean that Tx1 is the immediate next transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0047] The predecessor transaction Tx0 may already be validated and included in block 151 of blockchain 150 when Alice creates new transaction Tx1, or at least when she submits it to network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “predecessor” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (e.g., which transaction points to which other transaction). They may be equally replaced by “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This 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 (a descendant transaction or "child") that points to a preceding transaction (an 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 some time to wait for its parent, depending on the node protocol and / or node behavior.

[0048] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying 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 the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

[0049] 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 the transaction output 203, for example, the requirements of Alice's signature. An unlocking script appears in the transaction's output. 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 transaction's input 202.

[0050] Thus, in the example shown, UTXO0 in Tx0's output 203 must contain Alice's signature SIG P in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig PA ]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 comprises a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. Tx1's input 202 also comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0051] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to see if the unlocking script meets the conditions defined in the locking script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' are functions contained in the locking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. Either way, when executed together, the scripts will create a locking script containing Alice's public key P, as contained in the locking script in the output of Tx0. A is used to authenticate that the unlocking script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

[0052] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as a signature onto the message, 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., in embodiments means signing a hash of that data or transaction piece.

[0053] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, in the illustrated example, if Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of outstanding transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that it is disseminated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines the UTXO0 from Tx0 as being consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to ascertain whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it has already formed valid inputs into another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent in it, but ultimately, what defines whether a UTXO is spent is whether the UTXO has already formed valid inputs into another valid transaction in blockchain 150.

[0054] 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 also grounds for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0055] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" part of the amount defined in the UTXO as spent while another part is spent. However, the amount from a UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give the remaining amount in the second output of Tx1 to herself or to pay another party.

[0056] In practice, Alice is also typically required to include a fee for any Bitcoin node 104 that succeeds in including her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and therefore not disseminated or included in the blockchain 150, even though 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, the transaction fee does not require a unique, separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104 that wins the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in its own one of transaction 152's UTXOs 203.

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

[0058] Note that script code is often expressed generally (i.e., without using a precise 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 a locking script, produces a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0059] Typically, the input for a transaction is a public key P AIn embodiments, 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 portions of the outputs to sign depend on the SIGHASH flag, which is typically a 4-byte code included at the end of the signature (and therefore fixed at the time of signing) that selects which outputs are signed.

[0060] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that the locking script typically includes the public key of the party to which each transaction is locked. An unlocking script is sometimes 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 include authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" are sometimes preferred.

[0061] Layer 2 Overlay Network The blockchain network 106 is already in the form of an overlay network overlaid on a network such as the Internet 101. However, it is also possible to layer another layer of an overlay network on top of the blockchain. This is shown by way of example in FIG. 3. One example is the Metanet. Such a network is sometimes referred to as a "Layer 2" network, in the sense that it is a second layer of an overlay network, with the base network 101 (e.g., the Internet) as the underlying network infrastructure and the blockchain network 106 as the first layer of an overlay network overlaid on the base network.

[0062] This second layer of the overlay network 300 includes a network of nodes 301 and edges 302. Note that nodes 301 now refer to nodes in the layer of the Metanet (or other such network overlaid on a blockchain), not nodes 104 in the layer of the blockchain network 106 previously described with respect to FIGS. 1 and 2. Each node 301 in the Metanet network (or the like) is a different respective transaction 152 on the blockchain 150, each of which stores data in the payload of the respective transaction. Thus, nodes 301 in the Metanet network 300 (or the like) are sometimes referred to herein as data storage nodes or data storage transactions. The data stored therein may include data content and / or metadata, and generally may include both. In an output-based model, data may be stored in the non-spendable output 203 of the respective transaction. The output may be made non-spendable by one or more opcodes in a locking script that terminates the script upon execution. For example, in a system using a scripting language, this may be an OP_RETURN opcode, or OP_FALSE followed by OP_RETURN, depending on the protocol used. However, this is not a limitation, and those skilled in the art will know other techniques for storing arbitrary payload data in transactions in other blockchain systems, for example, in systems using an account-based model. The following may be illustrated with respect to an output-based model, but this is not a limitation.

[0063] Note that the Layer 2 overlay network 300 may be purely composed of data and entirely virtual, i.e., as an overlay network overlaid on the transactions 152 of the blockchain 150, such as the Metanet, the nodes 301 and edges 32 do not necessarily correspond to any particular physical actor or entity in the underlying blockchain network 106 or the underlying network infrastructure 101.

[0064] Data content is the actual data that Metanet (or the like) is used to store, for example, text, audio, still or video images, or other documents. Data content is sometimes called user content or user data. Metadata implements the protocol for layering a network on the blockchain 150. For at least some of the transactions 152, the metadata defines links between data content. These may be described as edges 302 between nodes 301. Links or pointers may point to, for example, the transaction ID, TxID, of a parent node. parent Note that a "link" as referred to herein does not necessarily mean a hypertext link, although that is one possibility. More generally, a link can refer to any form of pointer that points to another node 301 with which the current node 301 is related at the Metatnet layer (or other such overlay layer layered on top of the blockchain 150).

[0065] For convenience, the following will be described by way of example with respect to the Metanet, but it will be appreciated that this is not a limitation, and more generally, anywhere herein referring to the Metanet, this may be replaced with any overlay network overlaid on a blockchain. Similarly, any reference to a Metanet node may be replaced with a reference to any overlay network node or data storage node of the overlay network, and any reference to a Metanet link or edge may be replaced with a reference to any overlay network edge or link at the layer of that overlay network.

[0066] The Metanet protocol defines methods and standards for structuring on-chain data that can be stored on a public blockchain and used in a variety of applications for many use cases. The protocol specifies that graph structures, including nodes and edges, can be constructed from sets of blockchain transactions, and that these structures can be used to store, transport, represent, and distribute data of any nature ("content"). By treating transactions as nodes and signatures as edges created between transactions, the Metanet protocol enables the creation of the on-chain graph structure shown in Figure 3.

[0067] As can be seen, the nodes 301 and edges 302 of Metanet 300 form a tree structure: a parent node 301 is linked to one or more child nodes 301, any given child 301 may itself be a parent linked to one or more of its own children, etc. Note that the tree structure in question for present purposes may only be a subset of a broader tree or graph.

[0068] Figure 3 also shows how a node 301 and its associated edges 302 can be updated. Because transactions are immutably recorded in the blockchain 152, updates to a Metanet node 301 require the creation of a new instance 301' and corresponding edges 302' via a new transaction 152.

[0069] The structure of Figure 3 may include nested regions, e.g., the structure of a website and its pages, where a "top-level region" encapsulates sub-regions below it, etc. One functional key region (e.g., a write key, funding key, or encryption key region, described below) can span many of these structural regions.

[0070] The circles in Figure 3 represent nodes, which are simply transactions created according to the Metanet protocol's rule set. An example of a transaction 152N created and formatted according to that rule set is shown in Figure 4.

[0071] Transaction 152C on the right side of Figure 4 represents transaction 152 of blockchain 150 implementing a given node 301C (child) of the Metanet. Transaction 152P in the top left of Figure 4 represents a transaction of blockchain 150 implementing the parent of child node 152C at the Metanet layer. Child node transaction 152C includes an unlocking script and has an input 202 pointing to an output 203 of funding transaction 152F of blockchain 150. In other words, the output of funding transaction 152F is consumed by the input of Metanet node 152C. Note that funding transaction 152F and Metanet parent transaction 152P are not necessarily (but are not excluded) from being the same transaction.

[0072] Child transaction 152C includes a non-spendable output 203 that maintains a payload (payload from the perspective of the blockchain layer) that has been made non-spendable by, for example, OP_RETURN. This payload may include hashed and / or encrypted Metanet data content (“Data”), or may simply be raw (“plain”) data.

[0073] The payload of the child transaction 152C also contains Metanet network layer metadata, which includes at least the transaction identifier of the parent transaction 152P, which creates a link (edge) 302 at the Metanet layer. The key P associated with the child node 301C node In some cases, the inclusion of

[0074] The locking script of the output 203 of the funding transaction 152F also requires a signature included in the unlocking script of the input 202 of the child node 152C. In particular, this signature is included in the key P associated with the Metanet parent. parent 152F). This creates an edge 402 (sometimes called a spend edge) in the blockchain layer. If the unlocking script in the input 202 of the child transaction 152C does not contain the required signature, the child transaction 152C will not be validated by the nodes 104 of the blockchain network 106 and therefore will not be propagated through the blockchain network 106 or recorded in the blockchain 150. Note, however, that again, the funding transaction 152F is not necessarily the same blockchain transaction 152 as the Metanet parent transaction 152P, and therefore the blockchain layer spend edge 402 is not necessarily the same as the Metanet layer edge 302.

[0075] Figure 4 outlines just some of the relevant components of a Metanet transaction as an abstraction of the transaction as a whole. These components, in addition to the protocol identifier flag, include: · Public key P node and, · Parent public key P Parent SigP signature Parent and, The node's own transaction ID TxID node and, The transaction ID TxID of the node's parent Parent and Includes.

[0076] Placeholders <data>generally refers to any content data that may be included in a Metanet node transaction. In some applications, you may want to encrypt the data with an encryption key ek, in which case the data included in the transaction is<e(Data,ek)> where e() is a suitable encryption function.

[0077] Each Metanet node 301 is a pair (P node ,TxID node ), which is an index that allows strong versioning and permissioning control to be inherited by the Metanet graph. Each Metanet node can identify itself (P node ,TxID node ) and its parent (P parent ,TxID parent It should also be appreciated that the .ID includes sufficient information to identify the .ID.

[0078] Metanet child node 301C transactions receive the correct input signature SigP from parent node 301P parent , it may often be desirable to create one or more funding transactions 152F to facilitate this, which is shown in the bottom left of Figure 4.

[0079] Parent key P parent and / or the child node key P node can be seen as a write key that authorizes the child node 301C to write data to the blockchain 150.

[0080] The Metanet therefore provides a protocol that allows on-chain data to be constructed in a way that encodes permissioning and write access control for such data using only the technology underlying the blockchain itself. The Metanet protocol is therefore a solution that allows users to provably own their on-chain content.

[0081] The Metanet protocol defines a set of rules that allow the creation of a Metanet Direct Acyclic Graph (Metanet DAG). A single instance of a Metanet DAG is called a Metanet tree. Each Metanet tree has a root node (the top-level node), and each Metanet node, including the root node, can have one or more child nodes (see, for example, Figure 3 again).

[0082] The Metanet DAG thus becomes a global collection of trees, where each tree starts from its own root node and can have its own localized permission structure.

[0083] A Metanet node 301 is simply a transaction that follows the rule set of the Metanet protocol. There are two types of nodes: root nodes, which have no parent, and child nodes, where a given child node has exactly one parent. According to one implementation, the most basic outline structure of a Metanet node requires transactions that meet the following criteria: The transaction has at least one OP_RETURN output. The OP_RETURN payload contains: ○ Metanet flag. ○ Node address P node . Parent transaction ID TxID parent . Each transaction, except for the root node, contains an input signed by its parent node. As mentioned above, a Metanet node is a transaction 152 that contains four elements: P node - The address of the node. TxID node -Node version. P parent - The address of the node's parent. TxID parent - The version of the node's parent.

[0084] Metanet edges 302 are created by signatures. To create an edge from a parent node to a child node, the child node must be signed using the key pair associated with its parent, Sig P parent must be seen at the input of the child node.

[0085] Blockchain-based operating system An operating system (OS) is defined as software that schedules software (e.g., programs, tasks, or threads) running on a computer and coordinates their access to the computer's hardware resources. For example, an operating system provides processor time, memory allocation, and access to the computer's input and output (e.g., ports or peripheral devices). Typically, an OS is installed by a user or system administrator and updated by a producer using a proprietary, centralized server. In addition, a system administrator manages the OS and other computer programs, installing updates and bug fixes and verifying their integrity.

[0086] While this solution is an optimal choice for large servers and ad-hoc multifunction devices, it can be inefficient for smaller devices and systems that use standardized software, for example. These devices can benefit from a standard, small-sized, constantly available, and updated operating system that can be stored on the blockchain and downloaded on demand. This is particularly applicable to IoT devices that use small operating systems and have limited resources. IoT devices may be generated in thousands of copies and scattered over a wide area. Therefore, IoT devices can benefit from a decentralized blockchain solution because they can connect to any available blockchain node that has access to authentic data immutably stored on-chain (they can also use SPV or similar methods to double-check with other nodes). IoT devices may download and run a live distribution of the operating system available on-chain, and they may be remotely controlled by their administrators (e.g., using the Bitcoin network to send device-specific commands or code to be executed).

[0087] The present disclosure provides a new technique that allows parts or all of an operating system to be published on-chain and therefore accessible to run on any (compatible) device. Embodiments may use an overlay tree structure, such as Metanet, to structure the operating system's files. In further embodiments, any device can download and run any (compatible) operating system, and the only information needed is the root of the Metanet tree used to store the unique OS. The same tree can be used to publish commands and code (e.g., smart contracts) to be executed by one or more devices.

[0088] The operating system (OS), drivers, and any required files and programs may be stored on-chain or stored on a third-party server and hashed with the committed on-chain. A Metanet-based OS may be used in applications where a verifiable version of the OS is required and / or where a suite of programs must be installed in a provable manner. Additionally, a Metanet-based OS may be used to improve the software update and bug fix process.

[0089] More generally, operating system (OS) software, whether arranged in an overlay tree structure or not, may be stored in the payload of any one or more blockchain transactions on the blockchain 150. The operating system software may be accessed from the blockchain 150 by any one or more client devices 102 that are clients of the blockchain to be executed on the client device 102. The on-chain operating system software may include the entire operating system required by the client device 102, or may be only a portion used to supplement existing operating software already installed on the client device 102.

[0090] Each such client device 102 may be any computing device, such as a desktop computer, laptop, tablet, smartphone, etc., or a wearable device, such as a smartwatch or smart glasses. In embodiments, one or more client devices 102 accessing the on-chain OS software may include one or more Internet of Things (IoT) devices, such as dedicated sensor devices. Such IoT devices may not include a screen and / or keyboard or keypad in their own housing. In embodiments, an IoT device 102 may not incorporate any user input and / or output means in their own housing.

[0091] Preferably, the operating system software is stored in a tree structure of an overlay network overlaid on the blockchain 150. In an embodiment, this may be a Metanet tree configured according to the Metanet protocol.

[0092] An example is shown in Figure 5. As shown, a tree structure is created that includes a root node 301R and multiple leaf nodes 301L. The tree structure may be created, for example, by the computer equipment of an operating system producer as a central resource for use by each computer equipment (client device) 102 of one or more users 103.

[0093] The root node 301R is a parent node 301P of at least one child node 301C. Each node other than the root 301R is at least a child node 301C and may also be a parent node 301P of another child 301C. A node that is both a child node 301C and a parent node 301P of another child is sometimes referred to herein as an intermediate node 301I of the tree.

[0094] Each node 301I, 301L (i.e., each child node 301C) other than the root 301R is connected by one edge 302 to its respective parent node 301P, which may be the root node 301R or an intermediate parent node 301I that is itself a child of another parent. That is, the tree may have more than one level. Each leaf node 301L is simply a child node 302C. In some cases, the root node 301R may be one or more parent nodes 301P of the leaf nodes 301L. And / or, if the tree has more than one level, an intermediate-level node 301I may be the parent 301P of one or more leaf nodes 301L, and the parent of each intermediate-level node 301I may itself be another, higher-level intermediate node 301I or the root node 301R, depending on the number of levels in the tree.

[0095] Each node 301 is a different transaction 152 of the blockchain 150, e.g., as described herein with respect to FIGS. 3 and 4. Each edge 302 is a link between a pair of nodes 301. Edges 302 are created by cryptographically signing a child node with a private key associated with the respective parent node, which can be authenticated using the parent's corresponding public key. In an embodiment, these edges 302 are created as described with respect to FIGS. 3 and 4. That is, each node 152 is a transaction of an output-based model (e.g., a UTXO-based model) that includes at least one input 202 and at least one output 203, and the edge 302 is created by signing the input 202 of the child node 301C with the private key of the parent node 301P. To record a child 301C on the chain, the child 301C's input points to the output 203 of the funding transaction 152F, whose locking script requires the parent's signature for unlocking and therefore for the child node transaction 301C / 152C to be validated by the blockchain network 106 for recording on the blockchain. The parent node's key may be associated with each parent node 301P by being included in the payload of the parent node's 301P output 203. The parent's 301P transaction ID may also be included in the payload of the child's 301C output. See again FIG. 4 for an example. The payload may be included in the unspendable output of each transaction made unspendable by, for example, OP_RETURN or OP_FALSE and OP_RETURN, depending on the protocol used. In an embodiment, the overlay protocol may be a Metanet protocol, and thus the tree structure may take the form of a Metanet graph or a portion thereof.

[0096] However, it is not excluded that other overlay protocols may use other methods to create overlay edges between transactions 152, thus forming a tree structure in which those transactions form the nodes of the tree. Also, tree structures may be formed using other types of transaction models, such as using smart contracts in an account-based model. The techniques disclosed below and elsewhere herein are not limited to output-based transaction models unless explicitly stated.

[0097] According to embodiments disclosed herein, operating system software, including at least a portion of an operating system, may be stored in one or more child nodes 301C of an overlay tree structure, such as the overlay tree structure shown in FIG. 5. In an embodiment, the operating system software is stored in one or more leaf nodes 301L. The portion includes at least some executable code for the operating system. The operating system software may also include other elements, for example, one or more data files, such as configuration files. In an embodiment, the entire OS is stored on the chain.

[0098] Transactions of one or more child nodes 301C (e.g., leaf nodes 301L) that store an OS (or command, in embodiments—see later) are sometimes referred to herein as target transactions and are targets for accessing the operating system software (or command) stored therein. The OS software may be stored in the payload of the target transaction, in some cases across the payloads of multiple target transactions. In an output-based (e.g., UTXO-based) transaction model, the respective payload of each target transaction may be included in one or more respective outputs 203 (e.g., UTXOs) of the respective target transaction. These may be, for example, one or more unspendable outputs made unspendable by the OP_RETURN opcode or OP_FALSE and OP_RETUTN, depending on the protocol used. The operating system software may be stored in the same output 203 as the output used to record the identity of the parent node (see FIG. 4 ), or in a different output 203. In other variations, the payload may be included in a smart contract, for example, in an account-based model.

[0099] 9 illustrates a method by which a client device 102, such as an IoT device, can access and execute operating system software from a blockchain 150. This method may be implemented by client software or firmware running on the client device 102, or even by the device's dedicated hardware. In an embodiment, the method may be implemented by a boot stub (initial piece of boot code) that runs from the ROM of the client device 102 at boot time.

[0100] In step 901, the client device 102 identifies one or more target transactions recorded on the blockchain 150 that include operating system software stored in their payload. In an embodiment, this step may be based on the transaction ID of the root node 301R (or "root ID" for short). In this case, the client device 102 starts from the root node based on knowing the root ID of the tree, and then follows paths formed from the edges 302 down the tree from the root node 301R to find leaf nodes 301L where the OS software is stored. For example, the root ID may be pre-stored in the client device 102, e.g., at the time of manufacturing or deployment. Thus, all the client device 102 needs is the root ID and a connection to the chain 150, and the client device 102 can find all of the current OS software at the leaves 301L of the tree.

[0101] At step 920, the client device 102 accesses operating system software from the payload of one or more identified target transactions as stored in the blockchain 150. This involves downloading the software, either permanently or temporarily (i.e., streamed), to the client device 102. The software is downloaded from one or more nodes 104 of the blockchain network 106 that store a copy of at least a portion of the blockchain 150 that includes the target transactions of interest.

[0102] In step 930, the client device 102 executes the operating system software it accessed from the target transaction on the blockchain 150. This may involve executing the entire OS from the blockchain or executing portions of the OS from the blockchain 150 in conjunction with complementary portions already stored locally on the client device 102. In either case, the OS software accessed from the blockchain 150 may be executed live or installed on the client device 102. In the former case, downloading involves streaming the OS software from the blockchain 150 to the client device's 102's RAM (random access memory), i.e., volatile memory, where the OS software is temporarily retained on the client device 102. The software is executed from RAM in a streamed manner. In contrast, in the case of installation, the OS software is downloaded to the client device's 102's non-volatile storage. Installation also includes configuring one or more files of the operating system to suit one or more unique characteristics of the hardware of the particular client device 102 on which the OS is installed (the installed software is configured to suit the particular device on which it is installed and therefore cannot necessarily be simply copied to another device). The client device 102 then executes the installed version of the OS. After step 960 or step 970, the method may loop back to step 940 to continue monitoring for further updates.

[0103] In embodiments, the operating system software stored on-chain may be arranged in a file and folder structure, i.e., the software is represented as including multiple files, each of which is stored in a folder. Different files may be stored in different folders. Folders may include a hierarchical arrangement of parent folders and subfolders (children of the parent folder). Files may be stored in parent or subfolders.

[0104] In such embodiments, the tree structure of the overlay network, or at least portions thereof, may be arranged to mirror some or all of the hierarchical file and folder structure of the operating system. This is advantageous because an operating system naturally has a hierarchical structure for the organization of its files, and the tree structure of the overlay network (e.g., Metanet) can be used to reflect this.

[0105] One example is shown in FIG. 5 , and another example is shown in FIG. 6 . In such an embodiment, each node 301 may be tagged (e.g., in its payload) to indicate whether it is a folder node or a file node. A different tag may be used to indicate the root 301R, but this is not required as the root may be known to be the root by its ID. One of the leaf nodes 301L may be a child of the root node 301R (here, child means immediate descendant). This may be used to represent a file as being in the root directory of the file and folder structure. Another child of the root 301R may be tagged as a folder node. This is an intermediate node 301I, as it will have one or more children of its own, which may represent files or subfolders, or a combination thereof. In the example shown in FIG. 6 , the folder node is a leaf 301L and has one child used to hold a file. Naturally, more complex file and folder structures are possible.

[0106] In a further alternative or additional feature embodied by the present disclosure, the client device 102 may be configured to check the validity of each node 301 it encounters along each path as it walks the tree to find leaf nodes in step 910. Here, validity means validity according to at least the tree-structured overlay network protocol, e.g., the Metanet protocol. This protocol may include one or more protocol rules.

[0107] For example, in an embodiment, the rules include a requirement that each child node 301C be signed with the key of its respective parent node 301P, as described with respect to Figures 3 and 4. If any node 301 is found by the client 102 to not meet this requirement, then the node 301 and any of its children will be ignored as invalid, meaning that any OS software stored in that node or any of its children will not be included in the OS software executed by the client device 102.

[0108] In some embodiments, another rule is that only the leaf node 301L is considered to validly contain the OS software (or commands) for the client device 102. In this case, the client device 102 will simply run the OS software found in the leaf node 301L at the end of the path. One advantage of this is that it provides a mechanism for removing or updating the OS software, as will be explained in more detail shortly.

[0109] As an optional addition to the blockchain-based OS distribution scheme disclosed herein, a similar mechanism may be used to enable remote control of a client device 102 running a blockchain-based OS. In such an embodiment, the client device 102 also searches for a node 301 containing commands and OS software. For example, this may involve starting from the same root node 301R and following the path of edges down to the leaf 301L. If the client device 102 finds OS software validly stored in a leaf node 301, it includes it in the OS software to be executed on the client device. On the other hand, if the client device 102 finds a command, it executes the command. The command may be, for example, a command in a general-purpose scripting language recognized by the OS, such as a shell script or a Python script. In some embodiments, a script of multiple such commands may be included in a transaction. As another example, the command may be a device- or application-specific command (assuming the OS has the ability to interpret it), such as read a temperature and publish it on chain, or open a gate, or change the update frequency to X. Similar to files and folders, a scheme of tags (e.g., also stored in the payload) may be used to record whether a node 301 holds software or commands (or, in some implementations, it is not excluded that both may be allowed within the same node).

[0110] Commands may be included in the leaf nodes 301L by a remote administrator system that is remote from the client device 102, e.g., in a different geographic location. Both the administrator system and the client device 102 are connected to the blockchain network 106, e.g., via the Internet. The administrator system itself may also be a client of the blockchain network 106 or one of the blockchain nodes 104. The administrator system, e.g., Alice or Bob in FIG. 1, may record new transactions in the blockchain 150, making the new transactions the leaves 301L of the tree. In various use cases, this may occur at a later stage (e.g., at a later date) after the client device initially executes an OS from the chain. The commands are higher-level instructions than the operating system's executable code (machine code instructions), and the commands are interpreted by the operating system or higher-level application software running on the client rather than executed at the machine code level. The described techniques may also be extended to scripts of multiple commands.

[0111] In some embodiments, the OS software (or commands) held in a particular node 301 may be updated or deleted by adding another node to that node. This applies in embodiments where only leaf nodes 301L are considered to contain valid content. To do this, the administrator system adds a new node 301 to the current leaf node 301L to be deleted or updated. The adding means connects with an overlay network edge 302, for example, in the sense described with respect to FIG. 3 or FIG. 4. That is, the new node is made a child 301C of the node to which it is added, and this node is now the parent 301P of the new node. Thus, the old leaf is now an intermediate node 301I, and the new node is a new leaf 301L.

[0112] Figures 7 and 8 show some examples. Label 301I' represents a node that was previously a leaf but is now an intermediate node to which a new leaf has been added. Label 301L' represents the newly added leaf.

[0113] FIG. 9 shows optional steps that may be performed by the client device 102 to perform updates and / or deletions and / or to convey our commands from a remote administrator. In step 940, after starting execution of the OS software initially accessed in steps 910 through 930, the client device 102 continues to monitor the blockchain 150 for new target transactions involving the OS software (and / or commands, in some cases). In embodiments, this includes monitoring the current leaf node 301L to check whether any new nodes are added to the (previous) leaf. Alternatively or additionally, monitoring may include re-walking the tree path from its root 301R to the leaf 301L to check for new paths leading to the new leaf. In step 950, the client device determines whether monitoring has discovered any new target nodes 301. If not, the client device loops back to step 940, where the client device continues monitoring. If, however, it does, the method proceeds to step 960, where the client device determines whether the new target node includes OS software or commands. If the new target node contains OS software, it is considered an update, and the method branches to stop 960, where the client device 102 performs the update. On the other hand, if the new target node is a command, the method branches to step 970, where the client device 102 executes the command. Another possibility is that the node contains neither an update to OS software nor a command. In this case (assuming it is not tagged as a folder node), the newly added node is considered to represent a deletion of its parent, and the client 102 ceases executing the OS software or ceases executing the command that was contained in the deleted parent.

[0114] Whatever the nature of the new node, the client device 102 then loops back to step 940 where it continues to monitor for additional new nodes.

[0115] As another optional feature, the client device 102 may be configured to record an acknowledgment on the blockchain 150 when it accesses or executes OS software from one of the nodes 301 and / or executes a command from such a node. This means that the client device 301 sends a transaction to the blockchain network 106 to be published on the blockchain 150 (or sends the transaction to an administrator or third party for forwarding to the blockchain network to be published on the blockchain 150). The transaction includes the acknowledgment in the transaction payload, for example, in a non-spendable output (e.g., made non-spendable with OP_RETURN, or OP_FALSE, OP_RETURN, depending on the protocol used). The acknowledgment then remains immutable on-chain as evidence that the client accessed or executed the OS software or executed the command.

[0116] The acknowledgment may be used to verify that the client device simply received the command or script. Alternatively or additionally, the acknowledgment may be recorded by the client device 102 once it actually executes the OS software or command. In this case, the acknowledgment may simply record that the client device 102 reportedly executed the software or command, which provides some evidence, although not irrefutable proof (a device may cheat and say it executed the command, but it did not). For example, a device may acknowledge that it received a command to open a gate, but it is difficult to prove that the device actually opened the gate. Alternatively, the acknowledgment may use provable computing techniques to provide stronger evidence that the software or command was executed. Existing techniques for proving code execution are themselves known in the art.

[0117] As yet another optional feature, the client device 102 may be connected to one or more other client devices in a network, e.g., a wireless local area network such as a Wi-Fi network, a Bluetooth network, a ZigBee network, or the like. In embodiments, this network may take the form of a mesh network. This may be a network other than the wide area network 101 used by the client device 102 (and, in embodiments, the administrator system) to connect to the blockchain network. When connected with other client devices in such a network, the client device may share some or all of the operating system software and / or commands that the client device obtained from the blockchain 150. This may be advantageous if one or more of the other devices are not connected to the blockchain network 106, or if they must query the blockchain separately to conserve bandwidth for all devices in the network. In a mesh network arrangement, some of the other devices may subsequently share OS software and / or commands with their peers in the network, etc. Note that not all devices must be connected to the blockchain; one is sufficient, but two or more increases security. More than one increases security because different devices can connect to different blockchain nodes 104, thus they will detect if a blockchain node is cheating and sending a false version of the blockchain. A single device may also be connected to multiple nodes 104 to increase security, but it would be a single point of failure (e.g., an attacker could compromise that device and take control of all other devices).

[0118] Some further illustrative details of some possible implementations will now be described, but by way of example only.

[0119] On-chain live OS A live operating system (live OS) is an OS that does not need to be installed on a system before it can be run. A live OS is a complete, bootable system that runs directly from a storage device (e.g., a USB key) in a computer's memory. When published on-chain, these OSes can run automatically once downloaded from the blockchain, without needing to be installed. Alternatively, the blockchain can be used as the main persistent storage, and only the parts that are needed are downloaded to the device's memory (e.g., RAM). This is possible, for example, on a Linux system, since it loads all of its drivers at boot time.

[0120] Considering that a live distribution of a lightweight Linux Operating System requires 50-500MB of disk space and transaction fees of 0.5 sat / byte (the standard minimum BSV transaction fee at the time of writing), the cost of publishing an operating system on-chain can be estimated at 0.25-2.5 BSV (50-500 USD at the time of writing). A live OS can be published once and reused. Because of this, the cost of uploading an operating system on-chain can be considered affordable, especially for businesses.

[0121] When running an entire live OS is not feasible or desirable, all or part of the OS and software can be installed on the system hard drive and maintained and updated using the blockchain. In situations where publishing the entire OS on-chain is not feasible, for example, for economic or copyright reasons, part or all of the OS can be stored on one or more third-party servers, and only its hash may be published. Once downloaded from one of these servers, the authenticity of the OS can be verified using the hash published on-chain.

[0122] In embodiments, the live OS is published on-chain using the Metanet protocol to replicate the OS structure, which has several advantages: On-chain OS and program certification and integrity management. Facilitates automatic on-chain updates (when a device updates the Metanet tree, the device automatically receives the updates). Facilitates code execution (code can be linked into the device Metanet tree). Provable code execution (data and code to be executed are stored on-chain). Secure access to devices (using PKI). Remote control of all devices (expose commands on-chain). Facilitate data collection and publication from devices.

[0123] Using Metanet trees to store the OS The Metanet can be used to structure data on-chain using a tree-like structure. Because all leaves of a tree are associated with their root, it is always possible to search and download the entire tree starting from the root. The association between a leaf and the root can be direct (i.e., there is a direct parent-child link between the root and the leaf) or indirect (i.e., there are intermediate nodes between the root and the leaf). Given the ID of a Bitcoin transaction that represents the Metanet root according to Metanet rules, it is easy to track and download the entire tree, as well as add new nodes to the tree if the private key is known. Structuring data using Metanet protocols is advantageous because it provides an efficient way to link and search data for enabling and disabling nodes and updating files.

[0124] A typical system (e.g., a laptop or IoT device) can download and run an operating system stored on-chain in a Metanet tree, given its tree root. This means that if the tree root is given and stored in a secure way, the system will always be able to download and run the same OS in a verifiable manner. Furthermore, the system will automatically update and run newly published code when new information is included in new Metanet nodes and linked to the same tree. For example, an IoT device can be created with an embedded tree root (e.g., stored in ROM). This IoT device will always be linked to the same tree, will always download the correct version of the operating system and published updates, and will run any code (e.g., smart contracts) published in the tree (a possible implementation is described later). As long as the private keys used to create and manage the tree are not compromised, the IoT device is secure and can run any code provably and using specified libraries and modules.

[0125] As an example, Figure 5 shows the tree structure used to store a live Linux distribution, namely Puppy Linux BionicPup32. Given a root ID, all files and folders can be downloaded. In this example, there are two folders: "uui" (Universal USB Installer) and "help." The "uui" folder contains the "syslinux.cfg" file, which is a Linux boot loader that operates on a FAT file system. The "help" folder contains several files that display text messages during the bootloading process. Other files are directly linked to the tree root, such as the "ubuntu_10.03.sfs" file, which is a "combo pack" of multiple applications in one file specific to the Puppy distribution. The "*.c32" files store 32-bit modules used by syslinux to perform low-level functions such as hardware detection and setup during the boot process. Other files (not shown), including modules, libraries, drivers, programs, etc., are linked directly or indirectly to the same tree root.

[0126] Publishing the OS on-chain An OS can be published on-chain by a software distributor or by any system administrator (if the OS license allows doing so). In the first case, a plain OS will be published, and in the second case, additional software, configuration files, and scripts may be published along with the OS. The OS is contained in the "OS root directory", which is the first or top directory in the hierarchy. The OS can be likened to the trunk of a tree, as the origin from which all branches containing different files emanate. Given any live OS distribution contained in the OS root directory, it can be published on-chain by following the steps below: 1. Create a Metanet node that represents your OS root directory, where you can add additional information (e.g., distribution name and version). 2. For each file and folder in the actual OS root directory (i.e. the root of the device or the folder containing the OS), create a new Metanet node representing that file or folder (more details later). Link these nodes (as children) to the OS root node. 3. Select a folder that has not yet been processed and create a new Metanet node for each file and folder it contains. Link these nodes (as children) to the selected folder. 4. Repeat point 3 for each folder and subfolder.

[0127] In this exemplary embodiment, each tree representing an OS (or better, an OS root directory) must adhere to the following rules: 1. All files and folders must be valid Metanet nodes, and nodes can contain special tags to identify whether the node contains a file or represents a folder. An example of a transaction representing a file or folder is shown in Figure 6. If the Metanet node contains a file, the file must be stored (possibly encrypted) after OP_RETURN. If the Metanet node represents a folder, the name of the folder must be stored (possibly encrypted) after OP_RETURN. 2. All files and folders stored in the OS root directory must be children of the tree root. 3. All files and folders that are not stored at the root of the operating system (i.e., they are contained in a folder) must be children of the node representing that folder in the Metanet tree. Table 1 below shows an example structure of a Metanet node containing a file or folder. After the file or folder name, more tags or metadata can be added to the list.

[0128] [Table 1]

[0129] A simple example of a Metanet tree is shown in Figure 6, where four nodes (each similar to the node shown in Figure 5) represent one tree root (Tx1), one folder (Tx2), and two files (Tx3, Tx4). At the first level (the OS root), there is one file and one folder. The second file is stored within a folder at level 1.

[0130] The four nodes will be published on-chain as follows: · Root - Tx1: OP_RETURN META P1None root Folder - Tx2: SigP1P1| OP_RETURN META P2Tx1 folder encrypted_folder_name File 1 - Tx3: SigP1P1| OP_RETURN META P3Tx1 file encrypted_file1 File 2 - Tx4: SigP2P2| OP_RETURN META P4Tx2 file encrypted_file2 Here, Px is the public key of each node (all different).

[0131] It is possible to expose two types of OS on-chain: general-purpose systems and ad-hoc systems. On the one hand, general-purpose OSes have a basic installation and configuration and can be linked to any compatible device. On the other hand, ad-hoc systems are specifically exposed to a device or set of devices, and they usually have specific configurations and programs installed and used to control the devices. Multiple copies of the same ad-hoc system may be exposed and linked to different devices, which allows controlling the behavior of different devices (when they are linked to different trees) by exposing different commands in each tree.

[0132] Download On-Chain OS New devices that wish to download and install an OS published on-chain may be required to have the requirements outlined here and to follow the instructions described below. The new device remembers (knows) the transaction ID of the tree root. New devices can access the blockchain directly (e.g., Ethernet, wi-fi) or indirectly (e.g., ZigBee). The new device knows the encryption key (if the data is encrypted). The new device has the private key (if the device needs to write data on-chain).

[0133] When the device is turned on for the first time, minimal pre-installed software connects to one or more Bitcoin nodes (just like a light client would) and performs the following steps: 1. Starting from the provided transaction ID (i.e., the tree root), download the latest version of the tree. To ensure the most recent version of the data is used, if any two transactions using the same Metanet node public key are available, the transaction with the highest block height is used. 2. Verify the roots. 3. Verify the child's signature: Having a parent's signature on the unlocking script is not sufficient to prove the validity of the child, so an explicit signature verification process is recommended, e.g., for each node, the entire transaction that creates it (used in the unlocking script) and the transaction that initiates it (the one that includes the locking script) must be provided along with their Merkle proofs). 4. For each node, decrypt the data as needed. If the node contains a file, the file is decrypted and stored in the system hard drive root or in a specified folder. If the node contains a folder, a folder with the same name is created in the specified path. Finally, the system monitors the blockchain for changes to its tree, and if a new update is found, the new update is automatically downloaded (as described in steps 1, 2, and 3) and installed (step 4).

[0134] Update your OS Devices using an on-chain OS will preferably perform periodic checks of the state of their Metanet tree, looking for updates. This process is sometimes called tree discovery and can involve three steps: 1. The blockchain is parsed looking for transactions that include the OS tree root and its children. 2. The latest copy of the tree on-chain is compared with the one currently in use locally. A new node is identified. The new node receives a previously non-existent public key P node is a node having Old nodes are identified. Old nodes are nodes that have duplicate nodes on-chain (with the same public key P node In this case, only the latest version is retrieved, the heights of the blocks of the conflicting versions are compared, and the node with the highest height is selected (the most recently published one). 3. New nodes and nodes with newer versions available are downloaded and fixes or updates are applied to the system (e.g., an old file is replaced with its latest version). The device may need to be rebooted or turned off to complete this step.

[0135] OS updates can be published on-chain by software distributors (e.g., Microsoft can publish and maintain a live version of Windows) or by system administrators. System administrators can also publish updates for configurations and specific software (e.g., updating a Python module). When a distributor or system administrator wants to provide a new version of an operating system, program, driver, or the like, they can publish new files on a new Metanet node and link them to the OS tree. New versions of files can be added to the tree as children of the previous version of the same file.

[0136] During the tree discovery process, the system will automatically detect nodes that have new children added, and the relative file will be replaced with the latest available (deepest in the tree) version. This technique allows for automatic updates of any software without using any third-party servers (thus reducing maintenance costs and eliminating many security and availability concerns), but only publishing the latest version on-chain associated with each OS tree. Devices associated with this tree will be automatically updated during the tree discovery process.

[0137] As an example, in Figure 7, a file in the Metanet tree is updated, and the latest version of the file is always a child of the previous version of the same file, with the same public key P node The version considered valid is always a leaf node, the deepest node of that particular branch. Similarly, a node can be node A node can be deleted (i.e., removed from the Metanet tree) by creating a new sibling or child node with an empty content. Alternatively or additionally, a node can be deleted by spending any UTXOs that are present in transactions that include the node.

[0138] Publish commands and code on-chain Metanet trees can be used not only to store operating systems, but also to publish commands or some code / scripts (e.g., smart contracts) to be executed by devices associated with the tree. Similar to OS files and software, these commands, codes, and scripts are published as Metanet nodes, linked (directly or indirectly) to the tree root and classified using special tags.

[0139] Using this technique, an operating system tree owner (e.g., a system administrator) can publish new code, scripts, or commands to be executed on one or more specific devices, thereby controlling the devices. Publishing the code on-chain makes it possible to prove the exact code sent to the device and the specific time it was published on-chain; the code can be encrypted and the decryption key can be made available only to interested parties to increase privacy. Additionally, the device can publish an acknowledgment on-chain to prove that the code was received and executed.

[0140] An example of a Metanet tree with several command nodes is shown in Figure 8. Commands and codes may be published in the same tree in an operating system. In an embodiment, the exact sequence of commands is stored as a proof in the blockchain.

[0141] Commands and code can be updated by publishing new versions on-chain, similar to OS and software updates. During the tree discovery process, these nodes are processed and their content is executed, replacing older versions. The update process is the same as described previously, where, when a newer version is available, the new command or code is downloaded, replacing the existing one already (nodes with the same public key but higher block height). In this scenario, the tree acts not only as a repository but also as a logger, making it virtually always possible to establish which command or code was sent to a device, in what order, and at what specific time (as well as the execution status and time, if acknowledgement messages are used).

[0142] Once the OS is up and running, command and code execution occurs as follows: 1. The node containing the command or code / script is downloaded, processed and the required action is performed, such as executing some file or reading some sensor. 2. Output data (e.g., measurements, alerts, computation results) can be written to the blockchain by publishing a transaction signed with the device private key.

[0143] A script can be executed once (e.g., open a gate) or can be a task that is repeated until a new command / script is received (e.g., read the temperature and publish it on-chain).

[0144] Finally, the system uses a tree discovery process to monitor the blockchain for changes in the tree, and if new commands or codes are found, they automatically replace their respective older versions.

[0145] Exemplary Applications Below we describe two possible applications of a Metanet-based OS: one for deterministic execution of smart contracts, and the other for remote control of IoT devices.

[0146] Deterministic execution of smart contracts Smart contracts should have deterministic results so that their execution can be replicated and verified by other blockchain nodes. Transactions containing smart contracts therefore also involve the Metanet root node linking the Metanet-based OS used, and upon request, can be added to ensure that the smart contract is executed only in an environment that runs the OS and the provided software. A node that wants to publish the transaction should download the corresponding OS and execute the provided code. Other nodes or entities that want to validate a given smart contract must download the same OS and execute the smart contract within their machine. Alternatively, a smart contract can be part of a tree (i.e., a node that contains the same tree code). However, for computational reasons, validating a smart contract should not be a requirement for all nodes (as opposed to validating published transactions) but is merely an optional check.

[0147] It is worth mentioning that by the expression "smart contract" we are referring here to the execution of code that can be proven and recorded using blockchain techniques, rather than the entire process of decentralized execution and validation on-chain (as in Ethereum smart contracts).

[0148] An example of a Metanet transaction containing a smart contract linked to an OS is shown below in Table 2, where references to the smart contract and OS are stored after OP_RETURN and other parameters.

[0149] [Table 2]

[0150] All nodes may provide a list of operating systems and software that the operating system already supports, and they may charge users for running the code. That way, users can adapt their code to run on an operating system that is already widely available at low cost in the Bitcoin ecosystem, or users may pay the node an additional fee to run the code on a specific operating system or use specific software by providing a new operating system root.

[0151] The advantages of this approach include: · A standard, certified, and verifiable environment. · Deterministic and provable code execution. · Creating a marketplace where nodes can sell their computing power.

[0152] On-chain controlled IoT devices Companies that want to run or sell Internet of Things (IoT) devices with provable code execution capabilities can replace the pre-installed IoT OS with an on-chain OS. IoT devices using a Metanet-based OS only need the ability to connect to one or more blockchain nodes and a reference to a specific OS (root node) on-chain. If the IoT device should publish data on-chain (e.g., measurements or computation results), a private key is also required. The latest version of the OS is then downloaded from the blockchain (as described in the previous chapter). Devices that are not directly connected to the Internet can communicate with other IoT devices and receive updates from Bitcoin nodes using wireless mesh networking protocols (e.g., ZigBee).

[0153] Devices can be upgraded and controlled remotely by simply adding a node to the OS tree. Controlling IoT devices on-chain ensures system integrity, decentralized management, and logging of all actions (e.g., commands) sent to devices. There is no need to configure and manage third-party servers.

[0154] conclusion It will be appreciated that the above-described embodiments have been described by way of example only.

[0155] For example, some embodiments above are described with reference 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 apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with 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 properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0156] In an embodiment, 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 in 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, network entities may perform the function of disseminating and / or storing blocks without creating and publishing them (it is not to be recalled that these entities are not considered to be preferred Bitcoin network 106 nodes).

[0157] In other embodiments, 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, in these other blockchain networks, "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.

[0158] Also 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 entity / element may be implemented in hardware in the same manner as described above with respect to blockchain node 104.

[0159] Even more generally, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0160] Statement 1: A method comprising: identifying, by a client device, one or more target transactions recorded on a blockchain, the one or more target transactions including operating system software stored in payloads of the one or more target transactions, the operating system software including at least a portion of an operating system including at least some executable code of the operating system; accessing the operating system software from the payloads of the one or more target transactions stored on the blockchain; and executing, on the client device, the operating system software accessed from the one or more target transactions, the executing step including executing the executable code of the operating system.

[0161] Statement 2: The method of statement 1, wherein the operating system software is the entire operating system.

[0162] Statement 3: The method of statements 1 or 2, wherein the performing step includes performing the operating system software live from the blockchain by streaming the operating system software through RAM of the client device without installation on the client device.

[0163] Statement 4: The method of statements 1 or 2, wherein the performing step includes installing a copy of operating system software on the client device and performing the installed copy.

[0164] Statement 5: The method of any one of statements 1 to 4, wherein the accessing and executing steps relating to the operating system software occur at boot time of the client device.

[0165] Statement 6: The method of any one of statements 1 to 5, further comprising sending, by the client device, an acknowledgment that the client device has accessed the operating system software, as published on the blockchain.

[0166] Statement 7: The method of any one of statements 1 to 6, further comprising sending, by the client device, an acknowledgment that the client device has executed the operating system software, as published on the blockchain.

[0167] Statement 8: The method of any one of statements 1 to 7, wherein the one or more target transactions are multiple target transactions.

[0168] Statement 9: The method of any one of statements 1 to 8, wherein a tree structure is overlaid on the blockchain, the tree structure including a plurality of nodes and edges between the nodes, each node being a different transaction recorded on the blockchain, each edge connecting a respective child node to a respective parent node, the edges being formed by each child node specifying the transaction ID of its respective parent node in the payload of each child node, one of the parent nodes being a root node of the tree structure, and one or more target transactions storing the operating system software being child nodes of the tree structure.

[0169] Statement 10: The method of statement 9, wherein the tree structure comprises a Metanet tree.

[0170] Statement 11: The method of statement 9 or 10, wherein the operating system software includes a plurality of files in different folders arranged in a hierarchical file and folder structure, each of the target transactions stores at least one of the files, and one or more parent nodes of the target transactions are tagged to represent folders, such that at least a portion of the tree structure of the nodes follows at least a portion of the file and folder structure of the operating system software.

[0171] Statement 12: A method according to any one of statements 9 to 11, wherein the identifying step includes a step of following a path of edges from a root node down the tree structure to find a leaf node based on the transaction ID of the root node, a leaf node being a child node that is not a parent node of other child nodes, and each of the one or more target transactions being a leaf node.

[0172] Statement 13: The method of statement 12, wherein the client device checks that the target transaction and each of any intermediate parent nodes on the path between the target transaction and the root node satisfy one or more rules of a tree protocol associated with a tree structure, and wherein execution of the method is conditioned on satisfying the one or more rules.

[0173] Statement 14: The method of statement 13, wherein the set of rules includes at least that for each child along a path from the root node to the target transaction, the child is signed with the key of its respective parent node.

[0174] Statement 15: The method of statements 13 or 14, wherein the one or more rules include that only leaf nodes can form valid parts of the operating system.

[0175] Statement 16: The method of any of statements 15, further comprising checking, by the client device, at a subsequent time following said execution, for a new leaf node subsequently added to each one of the target transactions, whereby each target transaction is no longer a leaf and the new leaf node represents an update or deletion of the respective target transaction.

[0176] Statement 17: The method of statement 16, wherein one of the respective target transactions includes an update, and the method further includes the step of the client device performing the update.

[0177] Statement 18: The method of any one of statements 1 to 17, further comprising: identifying, by the client device, a further transaction on the blockchain that includes a remote command or script recorded in the payload of the further transaction by a remote administrator system that is remote from the client device; and executing the command or script accessed from the further transaction.

[0178] Statement 19: The method of statement 18, further comprising sending, by the client device, an acknowledgment that the client device has accessed the command or script as published on the blockchain.

[0179] Statement 20: The method of statement 18 or 19, further comprising sending, by the client device, an acknowledgment that the client device executed the command or script, as published on the blockchain.

[0180] Statement 21: The method of any one of statements 1 to 20, wherein the device is an Internet of Things, or IoT, device.

[0181] Statement 22: The method of any one of statements 1 to 21, wherein the client device is connected to one or more other devices of a network and shares operating system software with at least one of the other devices via said network.

[0182] Statement 23: The method of statement 22, wherein the network is a mesh network.

[0183] Statement 24: The method of statements 22 or 23, wherein the network is a wireless local area network.

[0184] Statement 25: The method of statements 22, 23, or 24, wherein not all of the other devices have access to the blockchain.

[0185] Statement 26: The method of any one of statements 1 to 25, wherein the blockchain uses an output-based model, each transaction includes at least one respective input and one or more respective outputs, and the payload of each transaction is included in one or more of the respective outputs.

[0186] Statement 27: A client device comprising a processing device having one or more processing units and a memory having one or more memory units, wherein the memory stores code arranged to operate on the processing device, and the code, when operating on the processing device, is configured to perform an operation according to any one of statements 1 to 26.

[0187] Statement 28: A computer program embodied on a computer-readable storage medium, the computer program comprising code configured to perform the operations of any of statements 1 to 26 when running on a client device.

[0188] Statement 29: A method comprising: transmitting, by a computing device of an operating system producer, operating system software to be published in a payload of a transaction on a blockchain, wherein the operating system software comprises at least a portion of an operating system, including at least some executable code of the operating system.

[0189] Statement 30: A method for updating a tree structure overlaid on a blockchain, the tree structure including a plurality of nodes and edges between the nodes, each node being a different transaction recorded on the blockchain, each edge connecting a respective child node to a respective parent node, the edges being formed by each child node specifying a transaction ID of each parent node of each child node in the payload of the respective child node, the tree structure including one of the parent nodes as a root node of the tree structure, a plurality of leaf nodes being child nodes that are not parent nodes of other child nodes, one or more of the leaf nodes storing operating system software in the payload of the one or more leaf nodes, the operating system software including at least a portion of an operating system including at least some executable code of the operating system, the tree structure being governed by a protocol whereby only the leaf nodes are considered to form valid parts of the operating system, the method including the step of adding, by an administrator system, a new leaf node to each one of the one or more leaf nodes, whereby each target transaction is no longer a leaf, and the new leaf node represents an update or deletion of the each target transaction.

[0190] Statement 31: An administrator system comprising a processing device having one or more processing units and a memory having one or more memory units, the memory storing code arranged to operate on the processing device, the code configured to perform the method described in statement 30 when operating on the processing device.

[0191] Statement 32: A computer program embodied on a computer-readable storage medium, the computer program comprising code configured to perform the method of statement 30 when run on an administrator system.

[0192] Other variations or applications of the disclosed technology may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the embodiments described above, but is limited only by the appended claims. [Explanation of symbols]

[0193] 101 Network 102 Computer Terminals / Computer Equipment / Client Devices 103 Users / Related Parties 104 nodes 105 Client Applications 106 Blockchain Network 150 Blockchain 151 blocks 152 transactions 154 Pool 201 Header 202 Input 203 Unexpendable Output / Output 300 System 300 Overlay Network / Metanet Network / Metanet 301 Node / Parent Node / Child / Target Node / Metanet Node / Leaf Node / Child Node / Client Device / Side Channel 302 Edge< / data>

Claims

1. By client device, Identifying one or more target transactions recorded on a blockchain, the one or more target transactions including operating system software stored in a payload of the one or more target transactions, the operating system software including at least a portion of the operating system, including at least some executable code of the operating system; accessing the operating system software from the payload of the one or more target transactions stored on the blockchain; executing, on the client device, the operating system software accessed by the one or more target transactions, the executing step including executing the executable code of the operating system; A method comprising:

2. The method of claim 1 , wherein the operating system software is the entire operating system.

3. 3. The method of claim 1 or 2, wherein the executing step comprises executing the operating system software live from the blockchain by streaming the operating system software through RAM of the client device without installation on the client device.

4. 3. The method of claim 1, wherein the executing step comprises installing a copy of the operating system software on the client device and executing the installed copy.

5. The method of claim 1 , wherein the accessing and executing steps for the operating system software occur at boot time of the client device.

6. 6. The method of claim 1, further comprising sending, by the client device, an acknowledgment that the client device has accessed the operating system software, to be published on the blockchain.

7. 7. The method of claim 1, further comprising sending, by the client device, an acknowledgment that the client device has executed the operating system software, as published on the blockchain.

8. 8. The method of claim 1, wherein the one or more target transactions is a plurality of target transactions.

9. a tree structure is overlaid on the blockchain, the tree structure including a plurality of nodes and edges between the nodes, each node being a different transaction recorded on the blockchain, each edge connecting a respective child node to a respective parent node, each child node specifying a transaction ID of its respective parent node in its payload, one of the parent nodes being a root node of the tree structure; The method of claim 1 , wherein the one or more target transactions that store the operating system software are child nodes of the tree structure.

10. The method of claim 9 , wherein the tree structure comprises a Metanet tree.

11. 11. The method of claim 9 or 10, wherein the operating system software includes a plurality of files in different folders arranged in a hierarchical file and folder structure, each of the target transactions stores at least one of the files, and one or more parent nodes of the target transactions are tagged to represent folders, such that at least a portion of the tree structure of the nodes follows at least a portion of the file and folder structure of the operating system software.

12. 12. The method of claim 9, wherein the identifying step comprises: finding a leaf node by following the path of edges from the root node down the tree structure based on the transaction ID of the root node, the leaf node being a child node that is not a parent node of another child node, and each of the one or more target transactions being a leaf node.

13. 13. The method of claim 12, wherein the client device checks that the target transaction and each of any intermediate parent nodes on the path between the target transaction and the root node satisfy one or more rules of a tree protocol associated with the tree structure, and the execution is conditioned on the satisfaction of the one or more rules.

14. 14. The method of claim 13, wherein the set of rules includes at least that for each child along a path from a root node to a target transaction, the child is signed with the key of the respective parent node.

15. 15. A method according to claim 13 or 14, wherein the one or more rules include that only leaf nodes can form a valid part of the operating system.

16. 16. The method of claim 15, further comprising checking, by the client device, at a subsequent time following the execution, for a new leaf node subsequently added to each one of the target transactions, whereby the respective target transaction is no longer a leaf and the new leaf node represents an update or deletion of the respective target transaction.

17. The method of claim 16 , wherein one of the respective target transactions includes an update, the method further comprising the client device executing the update.

18. by the client device identifying, by a remote administrator system remote from the client device, the further transaction on the blockchain, the further transaction including a remote command or script recorded in the payload of the further transaction; executing the command or script accessed from the further transaction; 18. The method of any one of claims 1 to 17, further comprising:

19. 20. The method of claim 18, further comprising sending, by the client device, an acknowledgment that the client device has accessed the command or script to be published on the blockchain.

20. 20. The method of claim 18 or 19, further comprising sending, by the client device, an acknowledgment that the client device has executed the command or script, as published on the blockchain.

21. 21. The method of any one of claims 1 to 20, wherein the device is an Internet of Things, or IoT, device.

22. 22. The method of claim 1, wherein the client device is connected to one or more other devices in a network and shares the operating system software with at least one of the other devices over the network.

23. The method of claim 22 , wherein the network is a mesh network.

24. 24. The method of claim 22 or 23, wherein the network is a wireless local area network.

25. 25. The method of claim 22, 23, or 24, wherein not all of the other devices have access to the blockchain.

26. 26. The method of any one of claims 1 to 25, wherein the blockchain uses an output-based model, each transaction including at least one respective input and one or more respective outputs, and the payload of each transaction is included in one or more of the respective outputs.

27. a processing device comprising one or more processing units; a memory comprising one or more memory units; 1. A client device comprising:

27. A client device, wherein the memory stores code arranged to run on the processing unit, the code being configured to perform the operations of any one of claims 1 to 26 when running on the processing unit.

28. 27. A computer program embodied on a computer-readable storage medium, the computer program comprising code configured to perform the operations of any one of claims 1 to 26 when run on a client device.

29. A method for updating a tree structure overlaid on a blockchain, the tree structure including a plurality of nodes and edges between the nodes, each node being a different transaction recorded on the blockchain, each edge connecting a respective child node to a respective parent node, the edges being formed by each child node specifying the transaction ID of its respective parent node in the payload of the respective child node, the tree structure including one of the parent nodes as a root node of the tree structure, and a plurality of leaf nodes being child nodes that are not parent nodes of other child nodes, one or more of the leaf nodes store operating system software in a payload of the one or more leaf nodes, the operating system software including at least a portion of the operating system including at least some executable code of the operating system; the tree structure is governed by a protocol whereby only leaf nodes are considered to form active parts of the operating system; The method includes, by an administrator system: adding a new leaf node from among the one or more leaf nodes to a target node, whereby the target node is no longer a leaf and the new leaf node represents an update or deletion of the target node.

30. a processing device comprising one or more processing units; a memory comprising one or more memory units; An administrator system comprising: the memory storing code arranged to run on the processing unit, the code configured, when running on the processing unit, to perform the method of claim 29; Administrator system.

31. 30. A computer program embodied on a computer readable storage medium, the computer program comprising code configured to perform the method of claim 29 when run on an administrator system.

Images