Mapping keys to blockchain overlay networks

Abstract

A method for managing an overlay network overlaid on data storage transactions of a blockchain, wherein data content of the overlay network is stored in the payload of the data storage transaction and overlay layer links are defined between the data storage transactions. The method includes identifying a graph structure of the overlay network, where nodes correspond to different ones of the data storage transactions and edges correspond to links. Each node is associated with a respective first key for signing inputs of child data storage transactions to authorize writing the child to the blockchain. The method further includes using a child key derivation (CKD) function to determine a hierarchical set of second keys having the same graph structure as the overlay network, where the second keys enable additional functions other than signing inputs of data storage transactions.

Description

[Technical field]

[0001] The present disclosure relates to an overlay network, such as a metanet, that is overlaid on a blockchain, and to determining a set of keys to map to different nodes of the overlay network. [Background technology]

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

[0003] Traditionally, transactions in a blockchain are used to communicate digital assets, i.e. data that acts as a store of value. However, blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing for more complex data to be incorporated. For example, this can be used to store electronic documents or even audio or video data on the blockchain.

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

[0005] Miners who successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction, called a "generation transaction," that generates a new amount of digital assets. Because mining a block requires significant computational resources, and blocks containing double-spend attempts are unlikely to be accepted by other nodes, proof-of-work incentivizes miners not to cheat the system by including double-spend transactions in their blocks.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any usable output includes an element that specifies the amount of a digital asset, sometimes called a UTXO ("unspent transaction output"). The output may further include a locking script that specifies the conditions for redeeming the output. Each input includes a pointer to such output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to an output of the first transaction and an unlocking script to unlock the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the validity criteria 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, and another is that the output of the first transaction has not yet been redeemed by another prior valid transaction. A node that finds the target transaction invalid according to any of these conditions will neither propagate it nor include it for mining into the block to be recorded in the blockchain.

[0008] Another 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 the sequence of past transactions. The current state of every account is stored and constantly updated by miners separately from the blockchain.

[0009] A blockchain network is already a kind of overlay network overlaid on an underlying network such as the Internet. However, it is also possible to overlay a further layer of overlay networks on the blockchain. An example of this is known as a metanet. Each node of a metanet is a different transaction on the blockchain. Data content and metanet metadata are stored in the payload of each such transaction in the unspendable output of the transaction with OP_RETURN. The data content is the actual user content that the metanet is used to store, for example, text, images, video or audio content, and the metadata defines the links between the metanet nodes. The 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, the links or edges in the metanet layer define the links between the data content of the metanet. Summary of the Invention

[0010] For purposes of illustration, this overview is described in the context of a metanet and metanet nodes and edges, however, it will be understood that this is not limiting and the same principles can be applied more generally to the nodes and edges of any overlay network overlaid on a blockchain.

[0011] Each node in a metanet network may have a key associated with it for some given function, e.g., a key is required to authorize writing data content to a respective metanet node. Furthermore, for a given function (e.g., writing), a different individual key may be required for each of multiple different metanet nodes. Thus, multiple sets of keys are required, one for each of multiple different metanet nodes.

[0012] Furthermore, any given node in a metanet network may actually have one or more of several different possible functions associated with it, where each such function may require a different key. For example, a first key from a first key set may be required to write data content to a metanet node, and a second key from a second key set may be required to encrypt and / or decrypt data content for a given metanet node. Thus, across multiple metanet nodes, a first set of keys may be required for a first function (a different individual first key for each metanet node), and a second set of keys may be required for a second function (a different individual second key for each metanet node).

[0013] A given set of keys may be hierarchical in nature. This means that within the set, keys further down in the hierarchy are each derived from a parent key further up in the hierarchy, potentially across multiple generations (parent, grandparent, etc.), all the way back to a common seed from which all the keys in the set are ultimately derived. Thus, a key set may be described as having a graph structure, such as a tree structure, where nodes in the tree correspond to different keys in the set, and edges between nodes represent the derivation of one key from another. The seed may be thought of as the "trunk" or "root" of the tree. The keys may be derived from one another using a known type of deterministic key derivation algorithm called a Child Key Derivation (CKD) function. Various forms of CKD functions are known that allow a system designer to derive a set of keys according to any graph structure they desire.

[0014] It would be desirable to provide a means to more efficiently allocate, manage, and / or communicate various keys in a metanet network (or the like).

[0015] In particular, it would be desirable if the hierarchical structure of a given key set, from which keys for a given function are derived from one another, could be directly mapped to a graph (e.g., tree) structure of metanet nodes and edges of the corresponding portion of the metanet (or other such overlay network overlaid on the blockchain). In other words, for a metanet node (or the like) at a given point in the tree structure, the key needed to perform a given function on that metanet node would be found at the same location in a corresponding hierarchical key set with the same graph structure. Then, to determine which key to use for a given metanet node, only the associated seed and the node's location in the graph structure need to be known.

[0016] Therefore, according to one aspect disclosed herein, a method for managing an overlay network overlaid on a data storage transaction of a blockchain is provided, where data content of the overlay network is stored in the payload of the data storage transaction and overlay layer links are defined between the data storage transactions. The method includes identifying a graph structure of the overlay network by a first software module executed on a first computing device, the graph structure including a plurality of nodes and edges between the nodes, each of the nodes corresponding to a different respective one of the data storage transactions and each of the edges corresponding to a different respective one of the links. Each node is associated with a respective first key for signing an input of the child data storage transaction in the graph structure of the overlay network to authorize writing the child to the blockchain. The first key is generated from a first seed. The method further includes determining, by the first software module, a hierarchical set of second keys having the same graph structure as the overlay network using a child key derivation (CKD) function applied to a second seed. Each second key corresponds to a different one of the nodes in the graph structure at the same position as the respective data storage transaction, and the second keys are not used to sign the inputs of the data storage transaction, but instead are provided to enable additional functionality (e.g., funding or decryption).

[0017] The enumerated graph structures of an overlay network (eg, a metanet network) may be the structure of part or all of the overlay network.

[0018] Each key may comprise the private key of a public-private key pair, or the public key of a public-private key pair, or both.

[0019] Previously, in a metanet, the idea of ​​generating a hierarchy of keys with the same structure as the metanet has only been used for set keys (sometimes called structure keys or write keys) for signing inputs of metanet data storage transactions. It has never been used to generate a hierarchy of any other type of key, such as sets of keys used for funding or encryption. This disclosure recognizes that this idea may be extended to other such sets of keys.

[0020] For example, this allows keys for a given metanet node to be communicated between different modules of software (e.g., wallets of different parties, or different isolated modules within a given wallet) by simply indicating the metanet node's location in the graph. Given the seed of the relevant set of keys, a receiving module can derive the key needed for the metanet node at the indicated location in the graph structure by simply knowing the node's location and the graph seed. This provides a more efficient way of signaling keys with less data overhead. If the seed is kept secret between a selected group of software modules (e.g., only the sending and receiving parties, or a selected group of parties), this is also more secure since the keys themselves do not need to be signaled between modules.

[0021] Thus, in an embodiment, the method may further include communicating from the first software module an indication of one of the locations in the graph structure to the second software module, thus enabling the second software module to determine a first key for each of the nodes at that location based on the communicated location, the first seed, and the CKD function used for the first keys.

[0022] When a hierarchical set of keys is said to have a tree structure or other such graph structure, this means a hierarchically derived set of keys, as is well known to those skilled in the art. That is, the keys in the set are hierarchically derived from one another, starting from a seed at the top of the structure. In other words, each node in the graph structure corresponds to a respective key, and each edge corresponds to the derivation of one of the keys in the set from another key. When a hierarchical set of keys is said to have the same graph structure as an overlay network (e.g., a metanet), this means that the graph structure of the hierarchical derivation between the keys is the same as the structure of the links between data storage transactions in the overlay network. In other words, each node in the graph structure corresponds to both a respective key in the set and a respective data storage transaction in the overlay network, and each edge in the graph structure corresponds to a respective dependency in the key set and a respective link between data storage transactions in the overlay network.

[0023] In an embodiment, the same graph structure may be used for two or more different key sets, each key set for a different function (e.g., one for encrypting and / or decrypting data content and another for authorizing the writing of data content).

[0024] For example, the method further includes determining, by the first software module, using a CKD function applied to the first seed, first keys as keys of a hierarchical key set having the same graph structure as the overlay network and the second key set, where each first key corresponds to a different one of the nodes co-located with the respective node in the graph structure.

[0025] In this case, the key set is derived using a different seed but has the same hierarchical graph structure. The CKD function used to determine the second set of keys may be the same form of function as used for the first set of keys (but applied to a different seed), or may be a different form of the CKD function.

[0026] Preferably, the second seed is not communicated by the first software module to the second software module, nor is the second software module given access to the second seed in any other manner.

[0027] Thus, the first software module can signal an indication of the node's location in the metanet graph structure (or the like) to the second software module, but without divulging the second seed. For example, these modules may be software running on different parties' computing equipment, or may be different, separate modules running within a given party's computing equipment. In either case, the second software module has access to the first seed, but not to the second seed. For example, the first seed may be sent by the first module to the second module along with the node location, or the first node may be known a priori to the second module (e.g., pre-shared by the first module or the third module). This allows the second software module to derive a key for the first function based on the location and the seed, but cannot derive a key for the second function of a node at the same location, since it does not have access to the second seed.

[0028] As an example application of this, a first software module may include a wallet for a customer Alice, and a second software module may include software for a service provider Bob who has more technical expertise than Alice. Alice pays Bob to record Alice's data in a transaction on the blockchain as a node in the metanet. Alice needs to communicate to Bob the key to write to the node. However, Alice will also be encrypting the content and does not want to leak the encryption key to Bob. There is no reason why Bob should be able to decrypt the data or see it in plaintext in order to upload it.

[0029] Another alternative or additional example of an advantageous application of the disclosed mapping of the second set of keys to the overlay network graph structure is to ensure that, for at least the first software module, the structure in its key derivation is preserved, such that some other entity (i.e., a third software module) will be able to recover all relevant keys for a data storage transaction (e.g., a metanet transaction) using only knowledge of the keys and the transaction's position in the structure (and CKD). [Brief description of the drawings]

[0030] To aid in understanding 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: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 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 a metanet, on a blockchain. [Diagram 5] 1 illustrates generally a hierarchical set of keys having a tree structure that coincides with at least a portion of a network of metanet nodes. [Figure 6] 1 illustrates generally a scheme for deriving multiple key domains, each containing a hierarchical set of keys. [Figure 7] 7 illustrates diagrammatically different path types of the scheme shown in FIG. 6; [Figure 8] FIG. 2 is a schematic block diagram illustrating communication of keys between a first software module and a second software module. [Figure 9] 4 is a schematic flow chart of a method performed by a first computing device. [Figure 10] 5 is a schematic flow chart of a method performed by a second computing device. [Figure 11] 1 illustrates a schematic of a mechanism for generating child private and public keys from a parent in the HD Wallet framework. [Figure 12] 1 illustrates a schematic of a mechanism for generating a child public key from an extended parent public key. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101.

[0032] For purposes of this subsection, a "node" refers to a node 104 of a blockchain network 106. Later, a node may also refer to a node of a metanet, or other such network overlaid on a blockchain.

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

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

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

[0036] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. In general, the preceding transaction can be any transaction in the pool 154 or any block 151. Although the preceding transaction 152i must exist and be validated for the current transaction to be valid, the preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106. Thus, "preceding" in this specification 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 time sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). The preceding transaction 152i is also called the antecedent transaction or a predecessor transaction.

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

[0038] This may be referred to as an "output-based" transaction protocol, and sometimes as an unspent transaction output (UTXO) type protocol (where the outputs are referred to as UTXOs). A user's total balance is not defined by any one number stored in the blockchain, instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are scattered across many different transactions 152 in the blockchain 151.

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

[0040] With any type of transaction protocol, when a user 103 wants to make a new transaction 152j, he sends the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is typically a server or a data center, but in principle could be other user terminals). This node 104 checks whether the transaction is valid according to the node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 in question, and together form a transaction model. The node protocol typically asks the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking that the cryptographic signature of the user included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction uses, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, the condition may be defined at least in part by custom script included in the input and / or output. Alternatively, it may be fixed solely by the node protocol, or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes of the nodes 104 in the P2P network 106.At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of nodes 104.

[0041] In an output-based model, the definition of whether a given output (e.g., UTXO) has been spent is whether it has been validly redeemed by an input of another forward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it is trying to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double-spending, where a spender tries to spend the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining an account balance. Again, since the transaction order is defined, the account balance is always in a single defined state.

[0042] In addition to validation, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is backed by "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a certain predefined number of leading zeros. A property of a hash function is that it has an unpredictable output for its input. This search therefore consumes a significant amount of processing resources at each node 104M trying to solve the puzzle, since it can only be performed in a brute force manner.

[0043] The first miner node 104M to solve the puzzle publishes it to the network 106, providing a proof of its solution that can be easily checked later by other nodes 104 in the network (given the solution to the hash, it is easy to check that the output of the hash satisfies the condition). The pool 154 of transactions for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's published solution at each such node. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. Proof of work helps reduce the risk of double spends, since it takes a lot of effort to create a new block 151, and since blocks containing double spends are likely to be rejected by other nodes 104, mining nodes 104M are incentivized to not include double spends in their blocks. Once created, blocks 151 cannot be modified because they are known and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on the blocks 151. As transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this provides an immutable public ledger of transactions.

[0044] Note that different miners 104M competing to solve the puzzle at any given time may be doing so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started searching for a solution. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, and the current pool of unmined transactions 154 is updated. Miners 104M then continue competing to create blocks from the newly defined unprocessed pool 154, and so on. There are also protocols to resolve any "forks" that may occur if two miners 104M solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate. In essence, whichever prong of the fork grows the longest will be the final blockchain 150.

[0045] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that suddenly creates a new amount of digital assets (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). The winning node is therefore said to have "mined" an amount of digital assets. This special type of transaction is sometimes referred to as a "generating" transaction. It automatically forms part of the new block 151n. This reward incentivizes the miner 104M to participate in the proof-of-work competition. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M who created the block 151n in which the transaction was included.

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

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

[0048] Also connected to the network 101 are computer equipment 102 of each of a number of parties 103 acting as consuming users. They act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and its respective computer equipment 102a, and a second party 103b and its respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 may be an individual or an organization. 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 that any reference herein to Alice or Bob may be replaced with "first party" and "second party", respectively.

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

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

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

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

[0053] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. Each node 104 runs software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, to forward the transactions 152 for propagation throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol proceeds with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow different subtypes of transactions therein). The same node protocol is used by all nodes 104 in the network 106 (although it may process different subtypes of transactions differently according to rules defined for the subtype, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

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

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

[0056] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j adds the new validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will be propagated throughout the P2P network 106 immediately.

[0057] Once admitted to the pool 154 in the copy of the blockchain 150 maintained in one or more storage nodes 104, the miner nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of the pool 154 that contains the new transaction 152. (Other miners 104M may be trying to solve the puzzle based on an old view of the pool 154, but whoever gets there first will define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j.) Once the proof-of-work is done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

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

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

[0060] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). It may also include, among other information, a transaction ID for the underlying transaction. The transaction data structure may also include a header 201, which may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 that is submitted to the miner 104M.

[0061] Suppose Alice 103a wants to create a transaction 152j that transfers an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset 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 just arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 can point to any previous (i.e., earlier) transaction that still has an unspent output 203 locked to Alice.

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

[0063] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script, which defines a condition that an unlocking script in the input 202 of the following transaction must satisfy in order for the following transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines an unlocking condition, which includes a condition that an unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0064] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "script" (capital S). A lock script specifies what information is needed to use the transaction output 203, e.g., the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0065] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A ] is the public key P from Alice’s public-private key pair. ATx1's input 202 includes 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 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a given piece of data (sometimes called a "message" in cryptography). <Sig P A What data (or "message") needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0066] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that are composed in the unlock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. In any case, when executed together, the scripts will generate Alice's public key P as included in the lock script in the output of Tx0. A, to authenticate that the lock script in Tx1's input contains Alice's signature, who signed the expected portion of data. The expected portion of data itself (the "message") must also be included in the Tx0 instruction to perform this authentication. In an embodiment, the signed data includes the entirety of Tx0 (i.e., a separate element specifying the signed portion of the plaintext data need not be included, since that is already inherently present).

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

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

[0069] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models, and therefore such a transaction will not be propagated to block 151 or mined.

[0070] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" a portion of the amount defined in the UTXO as spent, and another portion is spent. However, it is possible to split the amount from the UTXO 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 remainder to herself in the second output of Tx1, or to pay another party.

[0071] In practice, today, the reward for the generating transaction alone is typically not enough to incentivize mining, so Alice usually also needs to include a fee for the winning miner. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner nodes 104M, and therefore, even if technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force the miner 104M to accept the transaction 152 if it does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the winning miner 104. 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 is automatically awarded to the winning miner 104M. However, it is not necessarily excluded that a miner fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

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

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

[0074] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific portion of data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs, and all or some of the transaction outputs. The specific portion of the outputs that are signed depends on the SIGHASH flag, which is a 4-byte code included at the end of the signature to select which outputs are signed (and thus fixed at the time of signing).

[0075] A lock script is sometimes referred to as a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, any condition or conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0076] 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 overlay another layer of an overlay network on top of the blockchain. This is shown by way of example in FIG. 3. An example is the Metanet. Such a network may also be referred to as a "Layer 2" network, in the sense that it is a second layer of an overlay network, relative to 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.

[0077] This second layer of the overlay network 300 includes a network of nodes 301 and edges 302. Note that here, node 301 refers to a node in the layer of the metanet (or other such network overlaid on the blockchain) and not to node 104 in the layer of the blockchain network 106 as described above in connection with FIG. 1 and FIG. 2. Each node 301 of the metanet network (or the like) is a different respective transaction 152 on the blockchain 150, each storing data in the payload of the respective transaction. Thus, the node 301 of the metanet network 300 (or the like) may be referred to herein as a data storage node or data storage transaction. The data stored therein may include data content and / or metadata, typically both. In an output-based model, it may be stored in the unusable output 203 of the respective transaction. This output may be made unusable by an opcode in the lock script that terminates the script when executed. For example, in a system using a scripting language, this may be an OP_RETURN opcode. However, this is not limiting and one skilled in the art will recognize other techniques for storing arbitrary payload data in transactions in other blockchain systems, for example systems employing an account-based model, which may be exemplified below with respect to an output-based model, but without being limited thereto.

[0078] Note that the layer-2 overlay network 300 may be composed purely of data and entirely virtual, i.e., as an overlay network overlaid on the transactions 152 of the blockchain 150, the nodes 301 and edges 302 of the metanet, etc., do not necessarily correspond to any particular physical actors or entities of the underlying blockchain network 106 or the underlying network infrastructure 101.

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

[0080] For convenience, the following will be described with reference to a metanet as an example, but it will be understood that, more generally, any reference herein to a metanet may be replaced with any overlay network overlaid on a blockchain, and 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.

[0081] The Metanet Protocol defines methods and standards for structuring on-chain data that can be mined onto a public blockchain and used in a variety of applications for many use cases. The protocol specifies that graph structures containing nodes and edges can be constructed from a set of blockchain transactions, and that these structures can be used to store, communicate, 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 an on-chain graph structure such as that shown in Figure 3.

[0082] As can be seen, the nodes 301 and edges 302 of the 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 children of itself, and so on. Note that for purposes of the present invention, the tree structure may be only a subset of a broader tree or graph.

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

[0084] The structure of Figure 3 may include nested domains, e.g., a structure of a website and its pages, where a "top level domain" encapsulates the subdomains below it, and so on. One functional key domain (e.g., a writing key, funding key, or encryption key domain, described below) can span many of these structural domains. The structural "domains" shown in Figure 3 should not be confused with functional key domains, described below.

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

[0086] Transaction 152N on the right side of FIG. 4 represents transaction 152 of blockchain 150 that implements a given node 301N (child) of the metanet. Transaction 152P on the top left of FIG. 4 represents a transaction of blockchain 150 that implements a parent of child node 152N in the metanet layer. The child node transaction 152N includes an unlock script and has an input 202 that points to an output 203 of funding transaction 152F of blockchain 150. In other words, the output of funding transaction 152F is consumed by an input of metanet node 152N. Note that funding transaction 152F and metanet parent transaction 152P are not necessarily the same transaction (although this is not excluded).

[0087] The child transaction 152N includes an unusable output 203, e.g., made unusable by OP_RETURN, which holds a payload (payload from the blockchain layer perspective). This payload may contain the metanet's data content, which may or may not be encrypted. In FIG. 4, by way of example, the data content ("Data") is shown encrypted by the encryption function e and encryption key ek. However, this may be replaced by the plaintext data content (in this case<e(Data,ek)> is simply the same as in Figure 4. <data>If the data content is encrypted, then the encryption key ek, or the corresponding decryption key, is required to decrypt the data and view it in plaintext.

[0088] The payload of the child transaction 152N also contains metanet network layer metadata. This metadata includes at least the transaction identifier of the parent transaction 152P, which creates a link (edge) 302 at the metanet layer. It also contains the key P associated with the child node 301N. node It may be required by the Metanet protocol to include

[0089] The lock script of the output 203 of the funding transaction 152F also requires that a signature be included in the unlock script in the input 202 of the child node 152N. Specifically, this signature is included in the key P associated with the metanet parent. parent The signature (i.e., a message signed by that key) must be signed using the unlock script in the input 202 of the child transaction 152N. This creates an edge 402 (sometimes called a usage edge) in the blockchain layer. If the required signature is not included in the unlock script in the input 202 of the child transaction 152N, the child transaction 152N will not be validated by the nodes 104 of the blockchain network 106 and will not be propagated through the blockchain network 106 or recorded in the blockchain 150. Note again, however, that the blockchain layer usage edge 402 is not necessarily the same as the metanet layer edge 302 because the funding transaction 152F is not necessarily the same blockchain transaction 152 as the metanet parent transaction 152P.

[0090] Figure 4 outlines only the specific relevant components of a metanet transaction as an abstraction of the entire transaction. These components, in addition to the protocol discriminator flag, include: · Public key P node · Parent public key P Parent Signature of SigP Parent The node's own transaction ID TxID node The transaction ID TxID of the node's parent Parent

[0091] Placeholders <data>refers generally to any content data that may be included in a metanet node transaction. It is also anticipated that many applications will want to encrypt data with an encryption key ek, in which case the data included in the transaction will be<e(Data,ek)> where e( ) is the appropriate encryption function.

[0092] Each metanet node 301 has a pair (P node ,TxID node ) Each metanet node can be uniquely identified by itself (P node ,TxID node ) and its parent (P Parent ,TxID parent It should also be understood that the term "identifier" includes sufficient information to identify the identifier.

[0093] The transaction of metanet node 301N receives the correct input signature SigP from parent node 301P. Parent To ensure that all funds are included, it may often be desirable to create a funding transaction that facilitates this, which is shown in the bottom left of Figure 4.

[0094] Parent key P parent and / or the child node key P node may be considered as write keys that authorize the writing of data of the child node 301N to the blockchain 150. These may also be referred to herein as "structure keys."

[0095] Hierarchical Key Sets Keys associated with blockchain transactions 152 for a particular user or application are typically managed using a hierarchical key structure. For example, to handle the many private and public keys that may be associated with a given user's wallet, a common standard known as hierarchical deterministic (HD) key management has emerged. This standard is designed to facilitate the handling of many such key pairs by ensuring that all keys in the user's wallet can be derived from a single source of entropy and by ensuring that the keys are derived from their seeds in a deterministic manner using publicly known derivation functions. HD wallets themselves are well known and are simply wallets that use well-defined standards for deriving keys to be used in transactions outlined in several improvement proposals known as "BIPs", namely BIP32, BIP39, and BIP44. In essence, these standards define how to deterministically generate many private and public keys from a "seed" key, define "paths" for generating specific descendant keys from the seed key, and define a hierarchical wallet structure using deterministic key derivation functions. These standards for handling keys associated with a given user's funds or transactions for a particular application are widely used in the blockchain industry.

[0096] A deterministic algorithm that derives one key from another in a deterministic way is sometimes called a child key derivation (CKD) function. Thus, a set of keys can be determined starting from a seed, all of which are hierarchically related to one another. Such a hierarchical set of keys also has a tree structure. That is, the keys in the set are derived from one another in a hierarchy of derivations that follow a tree structure. That is, one or more keys are derived from a seed, and then for each such child of the seed, one or more keys can be derived from that key, and so on. In this tree structure, each node is a key and each edge represents the derivation of that key from its parent. Given a parent key or seed, it is possible for any party who knows the algorithm to deterministically determine its one or more children, but given a child key, it is not possible (or at least computationally feasible) to determine the parent key. Various forms of CKD are known in the art that allow for the generation of hierarchical key sets with any desired graph structure (e.g., a tree structure). For illustrative purposes only, one specific example is described below. Note that when a given key or key graph structure is said to be derived by applying a CKD to a seed or parent key, this does not exclude that the key or graph structure may be derived by applying the CKD to the seed / parent and some other data. For example, in an embodiment, the CKD function takes as input the parent key or seed, some other data called a chaincode, and an index at which children (of multiple siblings) have been created for a given parent. Similarly, the chaincode and / or index can be considered as parameters that parameterize the form of the CKD.

[0097] It should also be noted that the term "seed" as used herein does not necessarily mean that the seed is the absolute highest level key in the overall hierarchy or tree. More generally, a CKD may be applied to any key in a hierarchy to generate one or more child keys therefrom. A "seed" herein is simply any parent key or value from which other child keys of a given key set are derived. In embodiments, a seed may itself be a child key of another key or seed in a broader hierarchy (e.g., see FIG. 6, which is described in more detail below).

[0098] It may be desirable to adopt the above framework for a metanet structure. In particular, the CKD function may be used to map the keys P that define the metanet structure to HD wallets, etc. This is shown as an example in Figure 5.

[0099] As mentioned above, each metanet node 301 has a key P associated with it at the metanet network layer (P in the example of FIG. 4). node and P parent 5. It is advantageous to generate these keys according to a tree structure 500 that maps directly onto the corresponding tree structure 300 of metanet network nodes 301 and edges 302. That is, each metanet node 301 in the metanet tree structure is uniquely mapped to one corresponding key in the key tree 500, and each metanet edge 302 is uniquely mapped to one corresponding key derivation edge in the key tree 500. This means that, given the position of a node 301 in the metanet tree, knowledge of the seed, and the form of the CKD function used, it is always possible to derive the relevant key required for that node 301.

[0100] An advantageous application of this is to enable more secure and / or compressed (lower overhead) communication of keys between different modules of software. This is illustrated in FIG. 8. FIG. 8 shows a first software module 810 and a second software module 820. For example, these may be modules of software on separate pieces of computer equipment that communicate remotely (e.g., over the Internet 101). And / or they may be modules of software executed by different parties. Alternatively, they may be different modules of software executed on the same computer equipment of the same party, in which case at least some degree of isolation between the two modules is desired (e.g., so that if one is corrupted or compromised, the other is not). They may be implemented in the wallet software of a client 103 of the blockchain network 106, or in the node software (e.g., miner software) of a node 104 of the blockchain network 106. They may be physically stored on one or more memory units and executed on one or more processing units of any of the types previously described in connection with FIG. 1 and / or any other type familiar to those skilled in the art.

[0101] The first software module 810 sends a communication 815 to a second software module 820 to communicate a key associated with a given node 301 of the metanet 300 to the second module 820 to enable the second software module 820 to perform a function related to that node 301 that requires execution of the key. The communication 815 may include one or more individual signals or messages.

[0102] To communicate the key, the first module 810 need only include in the communication 815 I) the position of the node 301 in the metanet tree structure. The communication 815 may also include II) an indication of the form of the CKD function to be used, if there are different possible options. Alternatively, the form of the CKD may be of a fixed, pre-defined type known a priori to the second module 820, in which case it need not be signaled in the communication 815. In any case, if the seed is pre-determined and a priori known to the second module 820, neither the key itself nor the seed need to be included in the communication 815. For example, the seed may be a secret shared between the first module 810 and the second module 820, and may be shared only once with the second module 820, for example, by the first module 810 or a third administrator module at some initial point in time. This means that at a later point in time, when the first module 810 communicates keys for a different metanet node 301 to the second module 820, it does not need to explicitly signal the keys, thus reducing the risk of eavesdropping and / or avoiding the signaling overhead of sending a key or seed each time for each metanet node 301.

[0103] Note again that the tree structure 300 may only be a subset of the overall metanet graph. Thus, a seed may simply be a parent key at one level of a hierarchical domain, and the seed itself may have a parent further up the tree or graph.

[0104] In some other applications, the communication 815 may also include III) a seed, which is described in more detail below.

[0105] Functional Key Domain Examining a typical metanet transaction 152N, as shown in FIG. 4, and its corresponding funding transaction 152F, which may include encrypted data, shows that several different keys (e.g., P node , P parent , TxID node , ek) exist.

[0106] There are potentially many different types of keys associated with a metanet node and its corresponding funding transactions. For example, these can be categorized according to their function as follows: Structure (write) key-P node, P Parent Encryption key -ek Funding key-P Funding

[0107] It should be noted that in more complex examples of metanet transactions, there may also be other key types associated with other functions used to create the metanet node transaction 152N and / or other key types that perform other functions in relation to the metanet node 301. For example, another type of key may be an application layer key that facilitates an application layer function, such as an idempotent key (to ensure that node 301's data is not used or counted more than once for some application layer purpose). As another example, as an alternative or in addition to encryption, the data content may be subject to another form of obfuscation, such as padding or reordering, which may require a corresponding obfuscation key to obfuscate and / or deobfuscate.

[0108] As mentioned above, it is advantageous to take advantage of the prevalence and robustness of the HD Wallet standard (or similar) to manage keys, and in the embodiments disclosed herein, this desire extends to any or all such key types, e.g., construction keys, encryption keys, and funding keys. However, different key types may need to be handled and managed separately. Also, preferably, all keys should originate from the same seed to reduce the risk of compromise. However, these two requirements are quite contradictory. It is not immediately obvious how to ensure separation of keys while maintaining that they all originate from the same seed key. To complicate matters further, as mentioned above, a further desirable property of such HD key hierarchies is that the derivation path of a given key should map (at least partially) to a metanet graph structure. In other words, the desire to reflect the metanet graph structure in the key hierarchy (e.g., as in FIG. 5) serves as a third requirement that must be met in addition to reconciling the first two conflicting requirements.

[0109] Below we disclose a solution that solves this problem by defining a Functional Key Domain as a branch of an HD wallet that has keys associated with a single function involved in making a particular transaction.

[0110] In a metanet transaction, where there may be two, three or more different functions to account for (e.g., structuring, encryption, and funding), each key type is assigned an independent branch of the HD key structure.

[0111] Write key (i.e., structure key) P node , P parent is used to sign metanet transactions, the encryption key is used to encrypt any content data included in the transaction, and the funding key is used to sign funding transactions whose UTXOs are used by the metanet transactions.

[0112] All keys in the entire HD structure are unique and cannot be related to each other without knowledge of the wallet's master key (mk) pair (master seed). However, they are related in that they all belong to the same metanet structure location. This common location is encoded using a system of multiple path types embedded within the overall path for a given key.

[0113] FIG. 6 shows an example of allocating different function key domains. FIG. 6 shows an example derivation tree that can be created using the CKD function. Preferably, there is a master seed 601M(mk) at the top (source or root) of the tree. Multiple child seeds are derived from this, one for each of multiple types of functions. Each child seed serves as the source / root of a respective set of keys for each type of function (e.g., writing, encryption, and funding). In the example shown, there are three child seeds for three such functions, respectively, which are as follows: a write seed 601W for deriving a set of write keys P for enabling writing of the metanet node 301, an encryption seed 601E for deriving a set of encryption keys ek for encrypting and / or decrypting the data content of the node 301, and a funding seed 601F for deriving a set of keys for funding the record of the corresponding transaction 152 of the node 301 on the blockchain 150. The seed itself can be thought of as a type of key (the seed or sub-master key for its respective key set if they are all derived from the same master key 601M).

[0114] Each set of keys includes a respective tree structure according to which the keys in each key set are derived from each other. Each such tree structure is a subtree of the overall tree resulting from the master seed 601M. Within each key set, the tree structure maps directly onto the tree structure of the metanet 300. Thus, the tree structures of the different key sets are identical to each other. So, for example, there is one write key per node 301 of the metanet (or fragment thereof), and the edges of the derivation of those keys exactly follow the corresponding edges 302 in the metanet tree structure 300. At the same time, there is one funding key per node 301 of the metanet (or fragment thereof), and the edges of the derivation of the funding keys exactly follow the corresponding edges 302 in the metanet tree structure 300 and the ends between the corresponding write keys in the write key set. The same is true for encryption and / or any other functions for which key sets are derived according to this scheme.

[0115] Note that a given key here may refer to a private key, or a public key, or a public-private key pair. In an embodiment, a private key is first derived according to a tree structure, and then a corresponding public key is derived from the private key.

[0116] Note also that multiple key sets may be generated for one or more of these types of functions, e.g., encryption, e.g., for multiple layers of encryption, where each of the encryption key sets has the same tree structure, as shown by way of example in the bottom center of FIG.

[0117] Additionally, note again that the term "seed" as used herein does not necessarily mean the absolute final master seed of a broader tree structure. For example, write seed 601W is itself a child key of master seed 601M. A seed is simply any type of key or value that may be used to derive other keys. In an embodiment, the seeds of different functions (e.g., 601W, 601E, 601F) are in fact all keys derived from some master seed or key 601M. A seed as referred to herein may refer to a special type of key that is (at least locally) the "top" key of a hierarchy for a given set of keys, but may be a child in a broader hierarchy.

[0118] The examples of writing, encrypting, and funding are just a few examples of different types of functions that may be implemented in a metanet (or the like) for which respective key sets may be required, where it will be understood that there is a key for each node in a given set for a given type of function. More generally, the scheme outlined above may be applied to key sets for any first and second function, and in some embodiments, to a third function or more. For example, encryption may be generalized to any obfuscation (e.g., padding or reordering). Or, the scheme may be used for an entirely different type of key, such as an application layer serial number to be assigned to each metanet node 301 for some application layer purpose (e.g., powers, etc.).

[0119] Returning to FIG. 8, an advantageous application of the described scheme can be seen. Consider the case where a first software module 810 desires to signal a key of a first key set to a second software module 820 without compromising the key of the second key set or explicitly communicating the key itself. Similarly, the first and second modules 810 may be executed on different remote computing devices and / or by different parties, or may be separate modules within a given party's software and / or may be executed on the same device. In any case, consider the case where a first set of keys enables a first type of functionality (e.g., writing the node 301 to the metanet) and a second set of keys enables a second type of functionality (e.g., decrypting the node's data content). Within a given set, each key enables functionality for a different corresponding one of the metanet nodes 301. To enable the second module 820 to perform a first function in relation to a particular one of the nodes 301, the first software module 810 may send a communication 815 to the second module 820 indicating at least I) the corresponding first key in relation to the location of the corresponding node 301 in the metanet key structure 300. Optionally, it may also signal II) the form of the CKD function to be used, and III) a first seed (the seed from which the first key set for the first function is derived, e.g., 601W). Alternatively, one or both of these II, III) may be pre-determined and known in advance to the second module 820. In any case, the second key or seed (e.g., 601E) is not sent. Thus, since the second software module 820 knows the relevant first seed and the location in the tree structure of both the node 301 and the corresponding first key, it can derive the relevant first key for the first function (e.g., write). However, without having the second key, it is not possible to derive the key for the second function (eg, decryption).

[0120] For example, the first software module 810 may be Alice's 103a wallet, and the second software module 820 may be the software of the service provider Bob 103b or the miner 104. Take Bob as an example. Alice does not have the technical expertise to upload data content to the metanet 300. Bob provides a service that does this on Alice's behalf. In order for Bob to do this on Alice's behalf, Bob needs Alice's write keys for each of the P nodes 301 that are to be written to the blockchain 150. However, the data content of one or more of the nodes 301 should also be encrypted with the corresponding encryption key for each such node. Alice does not want Bob to be able to decrypt the data content, and there is no reason to require decryption by Bob to upload it in encrypted form. Thus, Alice can use the disclosed method to communicate a key from the first key set (in this case, for writing) to Bob without compromising the second key set (encryption keys).

[0121] Since it is the intent of this application to not allow Bob to derive the second set of keys, Alice may optionally signal the first seed III) in communication 815 to Bob, but note that Bob is not sent the second seed or otherwise provided with access to the second seed.

[0122] In an embodiment, the encryption key may be for a symmetric encryption scheme (e.g., AES) in which the encryption key ek used to encrypt the data is the same as the key needed to decrypt the data. Alternatively, an asymmetric encryption scheme (e.g., ECIES) may be used in which a different key is needed to decrypt the data. In this case, the "encryption" key of the second key set may be a decryption key, and the "encryption" key communicated to the second software module 820 may be a decryption key (commonly referred to as an "encryption key" in the sense that it is a key used in the application space or encryption context).

[0123] Funding Key P funding is another example of a key that Alice would not want Bob to know. Funding keys are the keys Alice uses to sign transactions that make payments for uploading metanet transactions, so Alice would not want Bob (or anyone else) to get hold of them and be able to accept payments without providing the service.

[0124] Note that the funding transaction does not necessarily pay Bob. Rather, it simply (or at least) pays for the data storage transaction to get on the blockchain, and at a minimum may only pay mining fees. Alice may or may not pay Bob for services, either on-chain or off-chain. A more compelling reason to outsource the second set of keys may be for processing and volume. That is, if a company (Alice) wants to put a lot of data on the blockchain, but does not want to deal with the optimization problems of (a) buying a native crypto token (digital asset) to do so, or (b) using an enterprise-grade wallet to do UTXO management and transaction creation, it may simply want to outsource the entire process to another party (Bob).

[0125] If Alice is the one wanting to put data on-chain and she would be “paying” Bob to do it, it doesn’t necessarily matter if both parties know the funding key, since they are just doing work, and Alice could be covering Bob’s costs by creating the funding transaction via fiat or other off-chain payment or business transaction.

[0126] In another exemplary use case, the first software module 810 and the second software module 820 may be different, separate functions within a given wallet application. For example, the first module 810 may be a write function (corresponding to the left branch of FIG. 6) and the second function may be an encryption function (corresponding to the center branch of FIG. 6). In this case, if one module is corrupted or compromised, the key set of the other, separate module is not necessarily compromised or affected accordingly.

[0127] Note again that key derivation is one-way, from the top down the tree; that is, one cannot go back upstream to determine a parent key from a child, but one can determine a child key from a parent. So if a first seed is shared, this does not compromise the master seed, and therefore does not compromise either the second seed or the keys derived from it. One can "go down, but not up" the tree. In embodiments, other restrictions can be placed on keys that prevent them from going down certain branches, which can be applied on a per-key basis using a process called hardening.

[0128] As another alternative or additional advantageous reason for employing the disclosed scheme, one or both of the software modules 810, 820 may wish to ensure that structure in their key derivation is preserved so that some other entity (i.e., a third software module) can recover all relevant keys of a metanet transaction using only knowledge of the metanet transaction's structure / location in the structure (and CKD) and those keys. This rationale may apply whether or not the first module 810 and the second module 820 communicate keys to each other in the manner described above.

[0129] Figure 7 illustrates the concept of path types. To ensure that keys related to different functions can be processed separately by different entities, embodiments use a function-based path structure for key derivation that can be decomposed into multiple different path types depending on the vertical level in the key hierarchy. For example: · m-path: A top-level path, which can describe anything in the hierarchy. · p-pass: Functional level passes (encryption pass, writing pass, funding pass). · b-path: Metanet graph structure path.

[0130] These paths can be more easily expressed as parts of a larger overall path for each key, written as follows:

number

[0131] The path elements following the m / p / b component are identical for all keys associated with a given metanet transaction. This is because a metanet transaction uses key P Parent and encrypted with key P Funding where all keys share a common path substructure ( / ... / ...) that follows their respective metanet structure root.

[0132] FIG. 9 is a flow chart of a method that may be performed by the first software module 810. In step S10, the first software module identifies the metanet tree structure 300. In step S20, the first software module 810 determines a first set of keys having the same tree structure as the metanet based on a first seed (e.g., 601W). In step S30, the first software module 810 determines a second set of keys having the same tree structure as the metanet and the first set of keys based on a second seed (e.g., 601E). Preferably, the first and second seeds are derived from the same master seed (e.g., 601M). In step S40, the first software module 810 sends a communication 815 to the second software module 820 indicating the location in the tree structure of the metanet node 301, enabling the second module 820 to perform the function associated with the first set of keys in relation to the metanet node 301 at the indicated location. This communication 815 may optionally include a form of a CKD function used to derive the first key set and / or the first seed. Alternatively, these may be known a priori to the second software module 820. In any event, the communication 815 from the first software module 810 to the second software module 820 does not include the second seed (or master seed).

[0133] FIG. 10 is a flow chart illustrating a method that may be performed by the second software module 820. In step T10, the second software module 820 receives an indication of a node location in a tree structure from the first software module 810. In step T20, based on the indicated location knowledge of the tree structure (and the CKD function and the first seed), the second software module 820 determines a metanet node and a corresponding key from a first key set. In step T30, a relevant function can then be performed in relation to the indicated node 301 based on the derived first key. However, the second function cannot be performed because the corresponding second key cannot be derived.

[0134] The concept of functional key domains presented herein may be used to provide any one or more of the following advantages or the like: · Transaction creation can be modularized and split into functions that can be distributed across different actors, services, or machines. This makes transaction construction more efficient and improves the scalability of the system, since each component can be created as a microservice and optimized independently of other components and in a way that does not require components to have information about other components in order to operate. In a multi-component transaction creation system, this method ensures that if one component is compromised, it cannot compromise the keys of other components, since each component can only access keys within its own functional domain branch. Multiple encryption keys ek1, ek2,...,ek n If present, this scheme makes it possible to implement fine-grained permission and access control over data manipulated by multiple layers or functions of encryption. This can be used to create complex Access Control Frameworks (ACFs) for on-chain metanet data. · All functional domain branches emerge from the same single entropy drain, allowing security for all components in a transaction building system to be handled by a single highly secure component that only has access to the master key (mk). This allows security to be bespoke and centralized in a single component of a multi-component system, which can help optimize how the system is built as a whole.

[0135] Child Key Derivation (CKD) Function Below are examples of known CKD functions, it will be understood that this is not limiting and other CKDs are known to those skilled in the art.

[0136] In the terminology adopted above, the top key in a given key set is called the "seed," and multiple such seeds may be derived from a "master seed" in an overall hierarchy. In alternative terminology, the local "seeds" of a given set may be called "extended" keys (whether public or private), and the master seed may be called "entropy."

[0137] The process of creating a master key can be written as follows: Generate a (e.g., 256-bit) random sequence of bits D that serves as a "wallet seed" from a secure pseudorandom number generator; Perform a function F (e.g., HMAC-SHA512) on the random bit sequence, Assign wallet parameters as follows: - Master Secret Key:=The left 256 bits of F(D), and - Master chain code:= right 256 bits of F(D).

[0138] The master secret key is the master private key for the wallet and typically contains a private-public key pair in the hierarchy.

[0139] To ensure that knowledge of a given parent key is insufficient to generate its child keys, additional entropy known as a "chaincode" may be used throughout an HD wallet. Chaincodes are generated deterministically throughout the HD wallet's key hierarchy using a "master chaincode" generated here as the initial chaincode in a deterministic sequence of all chaincodes for the HD wallet.

[0140] A system for abstracting the entropy required for a master key into a mnemonic phrase that is easy for humans to remember and manipulate was outlined in BIP39 and has since become standard technique used in cryptocurrency wallets.

[0141] Extended Keys: As mentioned earlier, HD wallets require an additional unit of entropy, known as a chaincode, in addition to knowledge of the key, to derive child keys. Thus, the concept of an "extended" key may be used to represent a given key concatenated with its corresponding chaincode. These can be written as follows for extended private and extended public keys, respectively: EPriv:=(privkey, chain code) EPub:=(pubkey, chain code) These extended private and public keys can be used to generate derived child keys using well-known public child key derivation functions.

[0142] Child Key Derivation (CKD) Function: An exemplary Child Key Derivation (CKD) function is defined in BIP32 that allows for the derivation of a child private key or child public key, respectively, using a given parent private key or parent public key, which can be written as follows:

number

[0143] Note also that the key tree of an HD wallet can only be traversed downwards, never upwards, deterministically, and in the case of extended public keys, it is also possible to limit the ability to go downwards by a process known as hardening.

[0144] Hardened Keys: In BIP32, the option to generate HD wallets using hardened keys. These keys eliminate the ability to generate hardened extended public keys from an extended parent public key, which is 2 32 This is achieved by extending the definition of the CKD function for indices greater than -1.

[0145] Multi-Account Hierarchy: Formally introduced in BIP44 is the concept of using different branches and levels of the key hierarchy within a HD wallet for different accounts related to the use of the cryptocurrency. In all cases, however, the different "accounts" define keys for substantially the same purpose, i.e., for the purpose of using the cryptocurrency by signing transactions.

[0146] Hierarchical Deterministic Wallets Below is some further discussion of hierarchical deterministic wallets in the context of a particular embodiment using elliptic curve cryptography, see FIG.

[0147] The homomorphic property of EC point multiplication affects HD wallets. This allows the corresponding child public key S child Without knowing or storing the parent public key P Parent From child public key P child can be constructed successively.

[0148] FIG. 11 shows how child key pairs are constructed from operations on a parent key pair in a hierarchical deterministic (HD) wallet.

[0149] FIG. 11 illustrates an exemplary mechanism for generating child private and public keys from a parent in the HD Wallet framework.

[0150] This can be done using either an extended private key or an extended public key, which are defined as follows:

number

[0151] Case 1: Use an extended private key. Extended private key ES parent Given a child key pair, the private key S child and the public key P child According to the drawing, these are defined and calculated as follows:

number

[0152] Here, given the extended parent private key, it was possible to compute both parts of the child key pair using the process outlined in the diagram.

[0153] Case 2: Using an extended public key. Extended public key EP parent Given a public key P, child Only can be built:

number

[0154] The derivation of this result relies on the homomorphism of elliptic curve private-public key pairs. The derivation is as follows:

number

[0155] The corresponding private key S for this public key child Deriving a public key from its parent is called parent :=(P Parent ||C parent ) is given, S parent This turns out to be impossible, since we need H = 1. The reason for this is that we must add the parent private key to the deterministic part given by the leftmost digit of the output of H, which can be seen from the diagram.

[0156] S child The only other way to find x is to "invert" the elliptic curve point multiplication algorithm, which is currently a very difficult problem.

[0157] Generating child public keys without needing to see, know, or store the corresponding private key is advantageous as it reduces storage requirements and can be used for much more secure wallet implementations that do not need to store private keys to generate blockchain addresses for receiving payments.

[0158] This effect is a direct consequence of the homomorphic nature of EC point multiplication and fundamental properties of ECC key pairs.

[0159] For completeness, FIG. 12 shows an example of how a child public key can be generated from an extended public key.

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

[0161] For example, in the above example, the overlay layer link is in the payload of the metanet transaction (e.g., TxID in the example of Figure 4). node TxID at the output of parent It has been described that the graph structure is defined by (by) the seed. However, this is not required. In alternative embodiments, the graph structure does not actually need to be declared on-chain, or at least not entirely. For example, a variant of the Metanet may be provided where some data structures are stored on the blockchain, but the overlay layer links may be stored off-chain. A hierarchy of keys signing inputs of data storage transactions would still be sufficient to recover (most of) the data structures, but only to those who know the seed, i.e., not to the general public looking at the blockchain, thus improving privacy. In a further variant, the graph structure of the Metanet (or other such overlay network) may be defined entirely off-chain, with only the data content being stored on-chain.

[0162] Furthermore, although the above has been described with respect to a tree structure, the same principles can be applied more generally to any graph structure: for example, a given node 301 may have two parents, in which case the corresponding key will be derived from the two parent keys.

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

[0164] Statement 1: A method for managing an overlay network overlaid on a data storage transaction of a blockchain, wherein data content of the overlay network is stored in a payload of the data storage transaction and an overlay layer link is defined between the data storage transactions, the method including, by a first software module executing on a first computing device, performing the following: identifying a graph structure of the overlay network, where the graph structure includes a plurality of nodes and edges between the nodes, where each of the nodes corresponds to a different respective one of the data storage transactions, and where each of the edges corresponds to a different respective one of the links, where each node is associated with a respective first key for signing an input of a child data storage transaction in the graph structure of the overlay network to authorize writing of the child to the blockchain, where the first key is generated from a first seed; and Using a child key derivation (CKD) function applied to the second seed to determine a hierarchical set of second keys having the same graph structure as the overlay network, where each second key corresponds to a different one of the nodes that is in the same position in the graph structure as a respective data storage transaction, and where the second keys are not used to sign inputs of the data storage transactions, but instead are provided to enable additional functions.

[0165] The above graph structure of the overlay network may be the structure of part or all of the overlay network.

[0166] Each key may comprise the private key of a public-private key pair, or the public key of a public-private key pair, or both.

[0167] Note also that when a hierarchical key set is said to be derived by applying a CKD to a parent or seed, this does not necessarily mean that the only input to the CKD must be the parent key or seed (whether public or private parent key). For example, in embodiments, the CKD may also take a chaincode and / or index value as input parameters.

[0168] Statement 2: The method according to statement 1, further comprising: Using a CKD function applied to the first seed, determining first keys as keys of a hierarchical key set having the same graph structure as the overlay network and the second key set, where each first key corresponds to a different one of the nodes that is co-located with the respective node in the graph structure.

[0169] Statement 3: The method according to statement 1 or 2, further comprising: Communicating from the first software module to a second software module an indication of one of the locations in the graph structure, thus enabling the second software module to determine a first key for each of the nodes at that location based on the communicated location, the first seed, and the CKD function used for the first keys.

[0170] Statement 4: The method of statement 3, wherein the first seed is also communicated to a second software module, and wherein the determination by the second module is based on the first seed communicated to the second module.

[0171] This may be communicated from the first software module or, for example, a third software module running on a separate third party computing device or running on the same device as the first or second software module but separate from the first and second modules.

[0172] Statement 5: The method of statement 3, wherein the first seed is known a priori to a second software module, and the decision by the second module is based on prior knowledge of the first seed.

[0173] Statement 6: The method of any one of statements 3, 4 or 5, wherein an indication of the CKD function to be used for the first key is also communicated to the second software module, and the determination by the second module is based on the CKD function indicated by the first software module.

[0174] Similarly, this may be communicated from the first software module or from a third software module, for example, running on a separate third party computing device or running on the same device as the first or second software module but separate from the first and second modules.

[0175] Statement 7: The method of statements 3, 4 or 5, wherein the CKD function is known a priori to the second software module, and the decision by the second module is based on prior knowledge of the CKD function.

[0176] Statement 8: The method of any of the preceding statements, wherein each of the first keys authorizes writing of a respective child data storage transaction to the blockchain.

[0177] Statement 9: The method of any of the preceding statements, wherein one or more of the data storage transactions each include a respective input that points to a respective funding output of another transaction, the respective inputs including a respective unlocking script, and the respective locking scripts require that a cryptographic signature based on a first key of a respective parent data storage transaction in the overlay graph structure be included in the respective unlocking script to validate the respective data storage transaction for recording on the blockchain.

[0178] STATEMENT 10: The method of STATEMENT 9, wherein each respective funding output is an output of a respective funding transaction other than the respective parent data storage transaction.

[0179] Statement 11: The method of statement 10, wherein the input of each funding transaction includes a cryptographic signature based on a respective funding key to validate the funding transaction for recording on the blockchain, and the output of each funding transaction specifies an amount of digital assets to fund recording of the respective data storage transaction on the blockchain.

[0180] Statement 12: A method according to any of the preceding statements, wherein each of the links is a link between a parent and a child of the data storage transactions, and the links are formed at the overlay layer by including the parent's respective transaction ID in the child's payload.

[0181] For example, the parent's transaction ID may be included in the unavailable output of each child data storage transaction. In some embodiments, such outputs may be made unavailable by including in the lock script an opcode that terminates the script. For example, this may be an OP_RETURN opcode in a scripting language.

[0182] Statement 13: The method of any preceding claim, wherein the second software module is not given access to the second seed.

[0183] Statement 14: A method as described in any of the preceding statements, wherein the second key is an obfuscation key, and the additional function includes obfuscating and / or deobfuscating data content of each data storage transaction of each node.

[0184] Statement 15: The method described in statement 14, wherein the obfuscation key is an encryption key, and the additional function includes encrypting and / or decrypting data content of each data storage transaction of each node.

[0185] Statement 16: The method of any of statements 1 to 13, wherein the second key is a funding key and the additional function includes funding each data storage transaction of each node to be recorded on the blockchain.

[0186] Statement 17: The method of any of statements 1 to 13, wherein the second key is an application layer key and the additional function includes an application layer function to be performed in connection with each data storage transaction of each node.

[0187] For example, each of the second keys may be a different respective application layer serial number of a respective data store transaction of a respective node, eg, used for idempotent purposes.

[0188] Statement 18: A method according to any of the preceding statements, further comprising: Using a CKD algorithm applied to a third seed, determining an overlay network and a hierarchical set of third keys having the same graph structure as the set of second keys, where each third key corresponds to a different one of the nodes in the same position as a respective node in the graph structure, and the third keys are for enabling a third function.

[0189] Statement 19: The method of any of the preceding statements, wherein at least the first seed and the second seed are derived from the same master seed.

[0190] Statement 20: The method of any of the preceding statements, wherein the second software module executes on a second computing device separate from the first computing device.

[0191] Statement 21: The method of statement 20, wherein the first computer device is a computer device of a first party and the second computer device is a computer device of a second party separate from the first party.

[0192] Statement 22: The method of statement 21, wherein the method is used by a first party to entrust a second party with recording one or more of the data storage transactions on the blockchain without revealing a second key to the second party.

[0193] Statement 23: A method according to statement 22 subordinate to statement 14 or 15, wherein the method is used by a first party to entrust a second party with having one or more of the data storage transactions recorded on the blockchain without enabling the second party to deobfuscate the data content stored therein.

[0194] Statement 24: The method of any of statements 1 to 19, wherein the second software module executes on the same first computing device as the first software module.

[0195] For example, this can be used to prevent the second key from being compromised if the first software module is corrupted or hacked, thereby keeping the functionality of the first module separate from the second module.

[0196] Statement 25: A method according to any preceding claim, wherein the data content is stored in one or more unusable outputs of the data storage transactions.

[0197] For example, such output can be disabled by including in the lock script an opcode that terminates the script - for example, this might be the OP_RETURN opcode in the scripting language.

[0198] Statement 26: A method according to any preceding claim, wherein the overlay layer link is stored within a payload of a data storage transaction.

[0199] Statement 27: A method according to any preceding claim, wherein the graph structure is a tree structure.

[0200] Statement 28: A computer program product comprising code embodied on a computer readable storage and configured to, when executed, perform operations in accordance with the method described in any of the preceding statements.

[0201] Statement 29: A computer apparatus comprising: a memory comprising one or more memory units; and a processing device including one or more processing units; Here, the memory stores a first software module configured to execute on one or more processing units and, when executed, to perform the method described in any of statements 1 to 27.

[0202] Statement 30: The method, comprising performing, by a second software module: receiving from a first software module an indication of a location of a node in a graph structure representing an overlay network, where data content of the overlay network is stored in payloads of data storage transactions on the blockchain, overlay layer links are defined between the data storage transactions, the graph structure including a plurality of nodes and edges between the nodes, each of the nodes corresponding to a different respective one of the data storage transactions, and each of the edges corresponding to a different respective one of the links; determining a key from among a hierarchical set of first keys using the indicated location, where the hierarchical set of keys has the same graph structure as the overlay network, and each first key corresponds to a different respective one of the nodes that is in the same position in the graph structure as the respective data storage transaction, said determining including determining a key for each of the nodes in the indicated location based on its location and a CKD function and a seed used for the set key; Using the determined key, perform functions in connection with each data storage transaction other than signing inputs to the data storage transaction.

[0203] Statement 31: A computer program product comprising code embodied on a computer readable storage and configured to perform operations according to the method described in statement 30 when executed.

[0204] Statement 32: A computer apparatus comprising: a memory comprising one or more memory units; and a processing device including one or more processing units; Here, the memory stores a second software module configured to execute on one or more processing units and, when executed, to perform the method described in statement 30.

[0205] According to another aspect disclosed herein, a method may be provided that includes operation of both a first and a second software module.

[0206] According to another aspect disclosed herein, a computer program product embodied on a computer readable storage device may be provided that includes both first and second software modules.

[0207] According to another aspect disclosed herein, there may be provided a system comprising first and second computing devices.

[0208] Other variations or uses of the disclosed techniques may become apparent to those of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.< / data> < / data>

Claims

1. 1. A method for managing an overlay network overlaid on a blockchain data storage transaction, wherein data content of the overlay network is stored in a payload of the data storage transaction and overlay layer links are defined between the data storage transactions, the method comprising: identifying a graph structure of the overlay network, where the graph structure includes a plurality of nodes and edges between the nodes, each of the nodes corresponding to a different respective one of the data storage transactions, each of the edges corresponding to a different respective one of the overlay layer links, each node being associated with a respective first key for signing an entry of a child data storage transaction in the graph structure of the overlay network to authorize writing of the child data storage transaction to the blockchain, the first key being generated from a first seed; determining a hierarchical set of second keys having the same graph structure as the overlay network using a child key derivation (CKD) function applied to a second seed, where each second key corresponds to a different respective one of the nodes that is co-located in the graph structure with a respective one of the data storage transactions, and where the second keys are not used to sign inputs of the data storage transactions, but instead are provided to enable additional functionality; A method comprising:

2. using a CKD function applied to the first seed to determine the first keys as keys of a hierarchical key set having the same graph structure as the overlay network and the set of second keys, where each first key corresponds to a different respective one of the nodes that is co-located in the graph structure with a respective one of the nodes. The method of claim 1.

3. communicating from the first software module to a second software module an indication of one of the locations in the graph structure, thereby enabling the second software module to determine the first key for each of the nodes at that location based on the communicated location, the first seed, and the CKD function used for the first key. Further comprising: the second software module executes on the first computing device or a second computing device; The method according to claim 1 or 2.

4. 4. The method of claim 3, wherein the first seed is also communicated to the second software module, and the determination by the second software module is based on the first seed communicated to the second software module.

5. The method of claim 3 , wherein the first seed is known a priori to the second software module, and the decision by the second software module is based on a priori knowledge of the first seed.

6. 6. The method of claim 3, 4 or 5, wherein an indication of the CKD function to be used for the first key is also communicated to a second software module, and the decision by the second software module is based on the CKD function indicated by the first software module.

7. The method of claim 3, 4 or 5, wherein the CKD function is known a priori to the second software module, and the decision by the second software module is based on prior knowledge of the CKD function.

8. 8. The method of claim 1, wherein one or more of the child data storage transactions each include a respective input that points to a respective funding output of another transaction, each of the inputs including a respective unlocking script, each of the funding outputs including a respective locking script, and each of the locking scripts requiring that a cryptographic signature based on the first key of a respective parent data storage transaction in an overlay graph structure be included in the respective unlocking script to validate the respective data storage transaction for recording on the blockchain.

9. The method of claim 8 , wherein each respective funding output is an output of a respective funding transaction other than the respective parent data storage transaction.

10. 10. The method of claim 9, wherein the input of each funding transaction includes a cryptographic signature based on a respective funding key to validate the funding transaction for recording on the blockchain, and the output of each of the funding transactions specifies an amount of digital assets to fund recording of each of the data storage transactions on the blockchain.

11. 11. The method of claim 1, wherein each of the overlay layer links is a link between a parent and a child of the data storage transactions, the overlay layer links being formed at the overlay layer by including a transaction ID of each of the parents in the payload of the child.

12. 12. The method of any one of claims 3 to 7 or any one of claims 8 to 11 when dependent on claims 3 to 7, wherein the second software module is not given access to the second seed.

13. 13. The method of claim 1, wherein the second key is an obfuscation key and the additional functionality includes obfuscating and / or deobfuscating data content of each of the data storage transactions at each of the nodes.

14. The method of claim 13 , wherein the obfuscation key is an encryption key, and the additional functionality includes encrypting and / or decrypting data content of each of the data storage transactions at each of the nodes.

15. 13. The method of claim 1, wherein the second key is a funding key and the additional functionality includes funding each of the data storage transactions of each of the nodes to be recorded in the blockchain.

16. 13. The method of claim 1, wherein the second key is an application layer key and the additional functions include application layer functions to be performed in association with the data storage transaction at each of the nodes.

17. and determining, using a CKD algorithm applied to third seeds, a hierarchical set of third keys having the same graph structure as the overlay network and the set of second keys, where each third key corresponds to a different respective one of the nodes in the same position as a respective one of the nodes in the graph structure, and the third keys are for enabling a third function.

17. The method according to any one of claims 1 to 16.

18. 18. The method of claim 1, wherein at least the first seed and the second seed are derived from the same master seed.

19. 19. The method of any one of claims 3 to 7 or any one of claims 8 to 18 when dependent on claims 3 to 7, wherein the second software module runs on a second computing device separate from the first computing device.

20. 20. The method of claim 19, wherein the first computing device is a computing device of a first party and the second computing device is a computing device of a second party separate from the first party.

21. 21. The method of claim 20, wherein the method is used by the first party to entrust the second party to have one or more of the data storage transactions recorded on the blockchain without revealing the second key to the second party.

22. 22. The method of claim 21 dependent on claim 13 or 14, wherein the method is used by the first party to entrust a second party to have one or more of the data storage transactions recorded on the blockchain without enabling the second party to de-obfuscate the data content stored therein.

23. 19. The method of claim 3, wherein the second software module runs on the same first computing device as the first software module.

24. 24. The method of claim 1, wherein the data content is stored in an unusable output of one or more of the data storage transactions.

25. 25. The method of claim 1, wherein the overlay layer link is stored in the payload of the data storage transaction.

26. The method of claim 1 , wherein the graph structure is a tree structure.

27. A computer program causing a computer to carry out the method according to any one of claims 1 to 26.

28. 1. A computer device comprising: a memory having one or more memory units; a processing device including one or more processing units; Equipped with 27. wherein the memory stores a first software module configured to execute on the one or more processing units and, when executed, to perform the method of any one of claims 1 to 26. Computer equipment.

29. A method comprising: receiving from a first software module an indication of a node's location in a graph structure representing an overlay network; data content of the overlay network being stored in payloads of data storage transactions on a blockchain, overlay layer links being defined between the data storage transactions, the graph structure including a plurality of nodes and edges between the nodes, each of the nodes corresponding to a different respective one of the data storage transactions, and each of the edges corresponding to a different respective one of the overlay layer links; using the indicated locations to determine a key from among a hierarchical set of first keys, where the hierarchical set of keys has the same graph structure as the overlay network, and where each first key corresponds to a different respective one of the nodes that is in the same position in the graph structure as a respective one of the data storage transactions, said determining including determining the key for each of the nodes in the indicated locations based on their locations and a CKD function and a seed used for the set keys; using the determined key to perform functions in connection with each of the data storage transactions other than signing an input to the data storage transaction; Including, A method, wherein the second software module executes on a separate computing device or on the same computing device as the first software module.

30. 30. A computer program causing a computer to carry out the method of claim 29.

31. 1. A computer device comprising: a memory comprising one or more memory units; a processing device including one or more processing units; Equipped with The memory stores a second software module configured to execute on the one or more processing units and, when executed, to perform the method of claim 29. Computer equipment.

Images