Wrapping Encryption

Abstract

1. A computer-implemented method for encrypting data by performing the following steps: a) encrypting a first data item with a first respective encryption key to generate a first encrypted value; b) combining a second data item with the first encrypted value to generate a first combined value; c) encrypting the first combined value with a second respective encryption key to generate a second encrypted value; and d) repeating the process of i) combining each next data item with each most recently encrypted value to generate a respective next combined value, and ii) encrypting each next combined value with each next encryption key to generate a respective next encrypted value, until the combination of the final data item and each most recently encrypted value has been encrypted with a respective next encryption key to generate a final encrypted value, wherein the encrypted payload comprises the final encrypted value.

Description

[Technical Field]

[0001] The present disclosure relates to a method for encrypting data. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform a solution to a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through publication of simple block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains may 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 or indexes to data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

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

[0005] The node that successfully solves the proof-of-work puzzle and creates the latest block is typically awarded a new transaction, called a "coinbase transaction," that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, which act as agents of the network and are encouraged to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node behavior. The mere publication of block headers allows participants to guarantee the continued validity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying an amount of a digital asset derivable from the evolving series of transactions. A consumable output is sometimes called a UTXO (“unspent transaction output”). The output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that specifies the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, a pair of transactions is considered, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that specifies one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlock script meets all of one or more conditions specified in the lock script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

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

[0009] Blockchain networks are already a type of overlay network that overlays an underlying network, such as the Internet. However, it is also possible to overlay additional layers of overlay networks on a blockchain. One example of this is called 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 OP_RETURN transaction at its output. The data content is the actual user content, such as text, images, video, or audio content, that the Metanet is using to store, while the metadata defines the links between Metanet nodes. Links or edges between Metanet nodes do not necessarily correspond to consuming edges in the blockchain layer. That is, if the input of a given Metanet transaction points to the output of another funding transaction in the blockchain layer, the parent of that same transaction or Metanet node in the Metanet layer is not necessarily the same transaction as the funding transaction. Instead, links or edges in the Metanet layer define the links between Metanet data content. Summary of the Invention [Problem to be solved by the invention]

[0010] Various techniques exist for encrypting (i.e., obfuscating) data to ensure its privacy and confidentiality. The process of encrypting and decrypting data involves keys: an encryption key to encrypt the data, and a decryption key to decrypt the data. Depending on the type of encryption scheme (symmetric or asymmetric), the encryption key may be the same or different compared to the decryption key.

[0011] Typically, a set of data items is encrypted as a whole; that is, the entire set of data items is encrypted as one using a single encryption key. A problem with such encryption protocols is that when the data is decrypted, the entire set of data items is revealed. This is problematic, for example, when a data set contains information of different importance, sensitivity, classification, etc. Some of the data may be suitable for access by the decrypting party, while some of the data may not be suitable. This creates a problem for the decrypting party to either gain access to all of the data (by being provided with a decryption key) or to none of the data (by being left without a decryption key).

[0012] Some protocols involve using multiple encryption keys to encrypt a set of data items. That is, a first encryption key is used to encrypt the entire data set to create an encrypted data set, and a second encryption key is used to encrypt the encrypted data set to provide an additional layer of encryption. This process can be repeated several times, which adds an additional layer of security to the data (assuming the encryption keys are different). Using different encryption schemes to encrypt data items may also add an additional layer of security to the data. However, while it may be possible to add an additional layer of security to the data using these techniques, the same access problem exists. That is, it is not possible to prevent an accessing party, provided with a set of decryption keys, from accessing the entire data set, even if some data items are not suitable for viewing by that party.

[0013] It would therefore be desirable to provide an encryption protocol that solves the above-mentioned problems by allowing different data items to be selectively revealed, i.e., it would be advantageous to control the amount of data accessible to a decrypting party. [Means for solving the problem]

[0014] According to one aspect disclosed herein, a computer-implemented method for encrypting data is provided, the method being executed by an encryption service and comprising generating an encrypted payload representing a data set comprising an ordered set of data items starting with a first data item and ending with a final data item, wherein the encrypted payload is generated by performing the following steps: a) encrypting the first data item with a first respective encryption key to generate a first encrypted value; b) combining a second data item with the first encrypted value to generate a first combined value; c) encrypting the first combined value with a second respective encryption key to generate a second encrypted value; and d) repeating the process of: i) combining each next data item with a respective most recently encrypted value to generate a respective next combined value, and ii) encrypting each next combined value with a respective next encryption key to generate a respective next encrypted value, until the combination of the last data item and each most recently encrypted value has been encrypted with a respective next encryption key to generate a final encrypted value, wherein the encrypted payload comprises the final encrypted value.

[0015] The disclosed encryption protocol is referred to herein as "wrapping encryption," which refers to a scheme in which an additional layer of encryption is wrapped around a first data item as each successive data item is encrypted. That is, when encrypting a first data item, a first layer of encryption is applied to (or wrapped around) the first data item, and then when encrypting a second data item and the encrypted first data item, a second layer of encryption is applied to (or wrapped around) the first data item. At this point, the second data item has only a single layer of encryption, while the first data item has two layers of encryption. After the next stage of encryption (if there are three data items in the set), the first data item will have three layers of encryption, the second data item will have two layers of encryption, and the third data item will have a single layer of encryption. This process continues, with another layer of encryption applied to each data item, until all data items have at least one layer of encryption. The first layer of encryption is sometimes referred to as the innermost layer of encryption, and the final layer of encryption is sometimes referred to as the outermost layer of encryption.

[0016] This protocol allows different data items to be revealed during decryption depending on the number of layers of encryption that can be removed by the provided decryption key. For example, an encryption service may provide only a decryption key that allows the outermost layer of encryption to be removed, revealing only the final data item. In another example, an encryption service may provide a decryption key that allows the outermost and penultimate layers of encryption to be removed, revealing both the final and penultimate data items in a data set. In another example, an encryption service may provide all decryption keys, allowing all encryption layers to be removed to reveal the entire set of data items.

[0017] For illustrative purposes, some embodiments are described in the context of encrypting data stored as part of a metanet. However, it will be appreciated that this is not limiting and that the same principles may be applied more generally to encrypt data stored as part of any overlay network overlaid on a blockchain. Going further, the same principles may be applied to encrypt any type of data, whether the encrypted data is stored on a blockchain or not.

[0018] For example, in some instances, the final data item in the dataset includes data related to a metanet transaction in the metanet tree, such as an identifier for the transaction and / or a parent transaction. The data may be structural and / or positional, in that the data relates to the structure of the metanet tree and / or the position of the transaction within the metanet tree. As an example, the data may identify a link between a transaction and its parent transaction.

[0019] To assist 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: [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded in a blockchain. [Figure 3] A schematic diagram of a network overlaid on a blockchain. [Figure 4] FIG. 1 is a schematic transaction diagram illustrating an exemplary protocol for overlaying a network, such as a metanet, on a blockchain. [Figure 5]FIG. 1 illustrates a schematic diagram of a hierarchical set of keys having the same tree structure as at least a portion of a network of metanet nodes. [Figure 6] FIG. 1 illustrates a schematic diagram of a scheme for deriving multiple key domains, each comprising a hierarchical set of keys. [Figure 7] FIG. 2 illustrates a schematic diagram of an exemplary process for encrypting data. [Figure 8] FIG. 8 is a diagram illustrating a specific example of the process shown in FIG. 7. [Figure 9] FIG. 1 illustrates an example of the division of the encryption process between different entities. [Figure 10] FIG. 1 is a diagram illustrating an exemplary blockchain transaction that stores encrypted data. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0023] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing a quantity of a digital asset, one example of a property being the user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backward to the output of a preceding transaction 152, thereby linking the transactions.

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

[0025] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions attempting to consume the same output.

[0026] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction onward. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and even sent to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or submission in a temporal sequence, and therefore does not necessarily preclude a transaction 152i, 152j from being created or submitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0027] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input of the preceding transaction 152i to the new user or entity 103b as specified in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a for providing change). In some cases, a transaction may also have multiple inputs to aggregate the amount from multiple outputs of one or more preceding transactions and redistribute it among one or more outputs of the current transaction.

[0028] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or organization, wishes to establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party sends the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately sends this transaction to one or more blockchain nodes 104 of the network 106 (which today is typically a server or data center, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may, in some instances, send the transaction directly to one or more of the blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to 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 such output-based transaction protocols, this may comprise checking that a cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition specified in the output of a prior transaction 152i that the new transaction consumes (or "allocates"); this condition typically comprises at least checking that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the prior transaction 152i to which the input of the new transaction is linked. The condition may be specified at least in part by a script included in the output of the prior transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or may result from a combination of these.Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and so forward the new transaction 152j onto one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0029] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has yet been validly redeemed by the input of another transaction 152j forward according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless flagged as invalid and propagated to warn) or recorded in the blockchain 150. This protects against double spend, whereby a transactor attempts to allocate the same transaction output more than once. On the other hand, the account-based model protects against double spend by maintaining an account balance. Again, because there is a defined order of transactions, the account balance always has a defined single state.

[0030] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, in a process supported by "proof of work," commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that, when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition might be that the output of the hash has some predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that the hash has an output that is unpredictable given its input. Therefore, this search can only be performed by brute force, and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0031] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the solution satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it up to threshold agreement of other nodes enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155, which points back in the chain to the previously created block 151n-1, is also assigned to the new block 151n. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction; otherwise, known as double spending. Once created, blocks 151 cannot be modified since they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0032] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool 154 of unissued transactions at any given time, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unissued transactions is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unissued transactions, and so on. The protocol also exists to resolve any "forks" that may occur, which are cases where two blockchain nodes 104 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 104. In essence, whichever prong of the fork grows the longest becomes the final blockchain 150. Note that when the same transaction appears in both forks, this should not affect users or agents of the network.

[0033] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional accepted amounts of digital assets in a new special type of transaction that distributes a specified additional quantity of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is typically called a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node’s intent to construct the new block to comply with protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

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

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

[0036] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as accumulating entities that accumulate copies of the blockchain 150 (e.g., obtain copies of the blockchain from blockchain nodes 104).

[0037] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It is understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, 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 will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

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

[0039] The client application 105 may be initially 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 may be 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.

[0040] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second functionality comprises reconciling the amounts specified in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0041] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented within a set of two or more separate applications that interface via, for example, an API, or one plugged into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0042] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, to truly inspect the transactions of other parties 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 organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to jointly implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0043] When a given party 103, for example, Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction according to the relevant transaction protocol (using a wallet function in her client application 105). Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets some conditions for being “valid,” examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be specified by a combination of the script and the node protocol.

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

[0045] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle on the latest version of their respective pool of 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions that will be included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 that includes the new transaction 152j, the new transaction 152j immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer back to earlier transactions, so that the order of transactions is also immutably recorded.

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

[0047] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance, rather than by referencing backward the UTXO of a transaction that precedes it in the sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called its "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed with a transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0048] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0049] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0050] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0051] The preceding transaction Tx0 may already be valid and included in a block 151 of the blockchain 150 at the time Alice creates her new transaction Tx1, or at least by the time she 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 ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or Tx0 may even be sent after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence, as defined by transaction pointers specified in the transactions (e.g., which transactions point backward to which other transactions). They may be equivalently substituted for “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or the like. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (a descendant transaction or “child”) that points to a preceding transaction (an ancestor transaction or “parent”) is not valid until and unless the parent transaction is valid. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, an orphan may be discarded or may be buffered for some time to wait for its parent.

[0052] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that specifies the condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script typically specifies an unlocking condition that includes the condition that the unlocking script in the input of the subsequent transaction comprise the cryptographic signature of the party to which the preceding transaction is locked.

[0053] A lock script (also 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) used by blockchain networks. A lock script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (also 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.

[0054] So, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID, TxID0. Tx1's input 202 comprises a pointer that points backward into Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlock script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a lock script, or by a node protocol, or a combination of these.

[0055] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the lock script and the unlock script together to check whether the unlock script satisfies a condition specified in the lock script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" denotes a location within the data on the stack, and "[...]" is a function provided by the lock script (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. A, which authenticates that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (so there is no need to include a separate element in the clear specifying the signed portion of the data, as it is already inherently present).

[0056] The details of authentication via public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as a signature on the message, thus allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or part of a transaction or the like can, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0057] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (so, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 propagates throughout the network 106. 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 consumes unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 is already spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a prescribed order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

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

[0059] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" a fraction of the amount specified in the UTXO as spent while another fraction is consumed. However, the amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount specified in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount specified in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to make a payment to another party.

[0060] In practice, Alice also typically needs to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and, therefore, while technically valid, may not be propagated or included in the blockchain 150 (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of transaction 152's UTXOs 203 itself.

[0061] Alice and Bob's digital assets consist of the 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. There is no single number stored somewhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values of all the various UTXOs locked to each party and that have not yet been spent in another transaction onward. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

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

[0063] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portion of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

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

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

[0066] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 107 may be established over a variety of networks, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, a side channel 107 as referenced elsewhere herein may comprise any one or more links, via one or more networking technologies or communications media, for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange several pieces of information or data, or the like, over the side channel 107, this does not necessarily imply that all these pieces of data must be sent over exactly the same links, or even the same type of network.

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

[0068] This second tier of the overlay network 300 comprises a network of nodes 301 and edges 302. Note that nodes 301 refer here to nodes in the layer of the metanet (or other such network overlaid on a blockchain) rather than nodes 104 in the layer of the blockchain network 106 as previously described with respect to FIGS. 1 and 2. Each node 301 in the metanet network (or the like) is a different respective transaction 152 on the blockchain 150, each of which accumulates data in the payload of the respective transaction. Thus, nodes 301 in the metanet network 300 (or the like) are sometimes referred to herein as data accumulation nodes or data accumulation transactions. The data accumulated therein may comprise data content and / or metadata, typically both. In an output-based model, it may be accumulated in the output 203 of the respective transaction. The output may be consumable or non-consumable. The output may be made non-consumable by one or more opcodes in a locking script that, when executed, terminates the script. For example, in a system employing the Script language, this may be a combination of the OP_0 and OP_RETURN opcodes. However, this is not limiting, and those skilled in the art will recognize other techniques for storing arbitrary payload data in transactions in other blockchain systems, for example, in systems employing an account-based model. The following may be illustrated with respect to an output-based model, but this is not limiting.

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

[0070] The data content is the actual data that the metanet (or the like) is using to store, e.g., text, audio, still or video images, or other files or documents. The data content is sometimes referred to as user content or user data. The metadata implements the protocol for layering the network on top of the blockchain 150. Within at least some of the transactions 152, the metadata defines links between the data content. These may also be described as edges 302 between nodes 301. The links or pointers may comprise, for example, the transaction ID of the parent node, i.e., TxIDparent. Note that the "link" referred to herein does not necessarily imply a hypertext link, although that is one possible example. 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).

[0071] For convenience, the following will be described as an example with respect to a metanet, but it will be appreciated that this is not limiting and, more generally, wherever herein a metanet is referenced, this may be replaced with any overlay network overlaid on a blockchain. Similarly, any reference to a metanet node may be replaced with a reference to any overlay network node or data storage node of the overlay network, and any reference to a metanet link or edge may be replaced with a reference to any overlay network edge or link at the layer of that overlay network.

[0072] The Metanet Protocol defines methods and standards for structuring data on-chain that can be recorded on a public blockchain and used in a variety of applications for many use cases. The protocol specifies that graph structures with nodes and edges can be constructed from sets of blockchain transactions, and that these structures can be used to store, carry, 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 on-chain graph structures such as those shown in Figure 3.

[0073] 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 its own, and so on. Note that the tree structure in question for present purposes may be only a subset of a broader tree or graph.

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

[0075] The structure of Figure 3 may comprise nested domains, e.g., the 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., the write key, funding key, or encryption key domains, to be described later) can span many of these structural domains. The structural "domains" shown in Figure 3 should not be confused with the functional key domains, to be described later.

[0076] 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.

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

[0078] The child transaction 152N carries a payload (payload from the perspective of the blockchain layer), e.g., a non-consumable output 203 that has been made non-consumable by OP_RETURN. This payload may comprise the data content of the metanet, which may or may not be encrypted. In FIG. 4, by way of example, the data content ("Data") is shown in plaintext. However, as explained further below, this may be replaced by an encrypted version of the data (in which case <data>is in Figure 4.<e(Data)> where the "e" indicates that the data is encrypted).

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

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

[0081] Figure 4 outlines only some relevant components of a metanet transaction as an abstraction of the transaction in its entirety. These components, in addition to the protocol discriminator flag, include: public key P_node, The signature SigP_Parent of the parent public key P_Parent, The node's own transaction ID, TxID_node, and The transaction ID of the node's parent, TxID_Parent.

[0082] Placeholder <data>generally refers to any content data that may be included in a metanet node transaction. In many applications, one may wish to encrypt that data. Encryption of data is further described below.

[0083] Each metanet node 301 can be uniquely identified by the pair (P_node, TxID_node), which is an index that allows strong versioning and authorization controls to be inherited by the metanet graph. It should also be appreciated that each metanet node contains sufficient information to identify itself (P_node, TxID_node) and its parent (P_parent, TxID_parent).

[0084] To ensure that metanet node 301N transactions include the appropriate input signature SigP_Parent from parent node 301P, it may often be desirable to create a funding transaction to facilitate this, as shown in the bottom left of Figure 4.

[0085] The parent key Pparent and / or the child node key Pnode may be viewed as write keys that authorize writing data for the child node 301N to the blockchain 150. These are sometimes referred to herein as "structure keys."

[0086] 5. Hierarchical Key Sets Keys associated with blockchain transactions 152 that pertain to 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 called hierarchical deterministic (HD) key management has emerged. The standard is designed to facilitate handling of many such key pairs by ensuring that all keys in a user's wallet can be derived from a single source of entropy and that the keys are derived deterministically from that seed using a publicly known derivation function. HD wallets themselves are well known and are simply wallets that use well-defined standards for deriving keys to be used in transactions, as outlined in several improvement proposals called "BIPs," namely, BIP32, BIP39, and BIP44. Essentially, these standards define how to deterministically generate many private and public keys from a "seed" key, define "paths" for generating specific descendent keys from the seed key, and define hierarchical wallet structures that use deterministic key derivation functions. These standards are widely used in the blockchain industry for handling keys related to a given user's funds or transactions for a particular application.

[0087] A deterministic algorithm for deterministically deriving one key from another is sometimes called a child key derivation (CKD) function. Thus, a set of keys can be determined starting from a seed, and the keys are all 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 derivation that follows 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 may 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, any party who knows the algorithm can 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 arbitrary graph structure (e.g., a tree structure).

[0088] Note: 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 for which the children (of multiple siblings) are being created for a given parent. Equivalently, the chaincode and / or index can be considered to be parameters that parameterize that form of CKD.

[0089] It should also be noted that the term "seed" as used herein does not necessarily imply that the seed is the absolute highest-level key in the overall hierarchy or tree. More generally, CKD can 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 will be described in more detail later).

[0090] As explained above, each Metanet node 301 has a key P associated with it at the Metanet network layer (see Pnode and Pparent in the example of FIG. 4). In some instances, it will be convenient 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 uniquely maps onto a corresponding key in key tree 500, and each Metanet edge 302 uniquely maps onto a corresponding key derivation edge in key tree 500. This means that, given the position of a node 301 in the Metanet tree and knowledge of the seed and the type of CKD function used, it is always possible to derive the associated key needed for that node 301.

[0091] 6. Functional Key Domains When examining a typical metanet transaction 152N as shown in FIG. 4, which may include encrypted data and its corresponding funding transaction 152F, it can be seen that there are several different keys (e.g., Pnode, Pparent, TxIDnode, ek) associated with a single metanet node 301.

[0092] There are potentially many different types of keys associated with metanet nodes and their corresponding funding transactions. For example, these may be categorized according to their function as follows: Structure (write) key - P_node, P_parent Encryption key - ek Funding key - P_Funding

[0093] Note that in more complex examples of metanet transactions, there may also be other key types relating to other functions used to create metanet node transactions 152N and / or perform other functions with respect to the metanet node 301. For example, another type of key may be an application layer key that facilitates application layer functions, such as an idempotency key (to ensure that node 301's data is not used more than once or counted twice for some application layer purpose). As another example, instead of or in addition to encryption, data content may be subjected to another form of obfuscation, such as padding or reordering, which may require a corresponding obfuscation key to obfuscate and / or deobfuscate.

[0094] As previously explained, it is advantageous to take advantage of the prevalence and robustness of HD Wallet standards (and the like) for managing keys, and in the embodiments disclosed herein, this desire extends to any or all such key types, e.g., structure 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 directly contradictory. It is not immediately clear how to ensure key separation while maintaining that they all originate from the same seed key. To further complicate matters, as explained above, an additional desirable property of such an HD key hierarchy is that the derivation path for 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.

[0095] The following discloses a solution to this problem by defining a Functional Key Domain as a branch of an HD wallet whose keys relate to a single function involved in making a particular transaction.

[0096] In the case of a metanet transaction, where there may be two, three, or more distinct functions to take into account (e.g., construction, encryption, and funding), a separate branch of the HD key structure is assigned to each key type.

[0097] The write keys (i.e., construction keys), Pnode and Pparent, are used to sign metanet transactions, the encryption keys are used to encrypt any content data included in the transaction, and the funding keys are used to sign funding transactions whose UTXOs are consumed by metanet transactions.

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

[0099] FIG. 6 shows an example of allocating various functional key domains. FIG. 6 shows an exemplary derivation tree that may be created using the CKD function. Preferably, a master seed 601M (mk) is at the top (source or root) of the tree. Multiple child seeds are derived from the master seed 601M, one for each of multiple types of functions. Each child seed serves as the source / root of a respective set of keys for a respective type of function (e.g., write, encrypt, and fund). In the illustrated example, there are three child seeds for three such functions, respectively: a write seed 601W for deriving a set of write keys P to enable writing the metanet node 301; an encryption seed 601E for deriving a set of encryption keys ek for encrypting and / or decrypting the node's 301 data content; and a fund seed 601F for deriving a set of keys for funding the recording of the node's 301's corresponding transaction 152 on the blockchain 150. The seed itself may be considered a type of key (a sub-master key or seed within its respective key set, if they are all derived from the same master key 601M).

[0100] Each set of keys has its own tree structure according to which keys in each key set are derived from each other. Each such tree structure is a subtree of the overall tree stemming 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 different key sets are identical to each other. So, for example, there is one write key per node 301 in the metanet (or fragment of the metanet), and the derivation edges for those keys strictly follow the corresponding edges 302 in the metanet tree structure 300. At the same time, there is one funding key per node 301 in the metanet (or fragment of the metanet), and the derivation edges for the funding keys strictly follow the edges between the corresponding edges 302 in the metanet tree structure 300 and the corresponding write keys in the write key set. And so on for encryption and / or any other functions for which key sets are derived according to this scheme.

[0101] Note: 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 the corresponding public key is derived from the private key.

[0102] It should also be noted that there may be multiple key sets generated for one or more of the types of functionality, e.g., encryption, e.g., multiple layers of encryption, in which case each of the encryption key sets has the same tree structure, as shown, for example, in the bottom center of Figure 6.

[0103] Furthermore, it should be noted again that the term "seed" as used herein does not necessarily imply an absolute and 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 can be used to derive other keys. In embodiments, the seeds of different functions (e.g., 601W, 601E, 601F) are actually just keys that are all 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 in the hierarchy for a given set of keys, but may also be a child in a broader hierarchy.

[0104] It will be appreciated that the examples of writing, encrypting, and funding are just a few examples of different types of functions that may be implemented in a metanet (and so on), for which respective key sets may be required, with keys per 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 functions, and in some embodiments, third or more functions. 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., idempotence).

[0105] 7. Encrypting Data for Selective Disclosure Embodiments of the present disclosure provide encryption methods (referred to herein as "wrapping encryption") that can be used to selectively reveal (i.e., disclose) different data belonging to a dataset. For example, data may be revealed depending on the sensitivity of the data, the type of data, the access rights of the data accessor, etc.

[0106] FIG. 7 illustrates an exemplary system 700 for encrypting data using the methods (i.e., protocols) disclosed herein. As shown, system 700 includes a cryptographic service 701 and a data provider 702. While FIG. 7 illustrates cryptographic service 701 and data provider 702 as separate entities, it is not excluded that cryptographic service 701 and data provider 702 may be provided by a common entity, e.g., cryptographic service 701 and data provider 702 may be different components of the same system. Although not shown in FIG. 7, the system may also include a data accessor and one or more nodes 104 of blockchain network 106. The data accessor may be the same entity as data provider 702.

[0107] Generally, the cryptographic service 701 and the data provider 702 each comprise and operate a respective computing device comprising a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, cryptographic processors, and / or FPGAs. Each computing device further comprises a respective memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on each computing device may store software comprising a respective instance of at least one client application configured to execute on the processing unit. It will be understood that any actions attributed herein to the cryptographic service 701 or data provider 702 may be performed using software executing on the processing unit of the respective computing device of the cryptographic service 701 or data provider 702. Each computing device comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. Each computing device may also comprise one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

[0108] In some examples, the cryptographic service 701 may be configured to perform any of the actions attributed to Alice 103a and / or Bob 103b above as described with reference to Figures 1 and 2. Similarly, the data provider 702 may be configured to perform any of the actions attributed to Alice 103a and / or Bob 103b.

[0109] Generally, the data provider 702 has access to a dataset to be encrypted. The dataset comprises multiple data items. The data items may relate to a person, a business, an organization, an object, etc. For example, the data items may relate to personal details of a particular person, such as the person's name, address, date of birth, email address, occupation, hobbies, medical history, etc. The data items may relate to business details, such as financial records, employee records, purchase history, sales history, etc. In some examples, some data items may be more sensitive (or important) than other data items. As an example, a person's email address may be more sensitive than their hobbies, in the sense that an email address can be used to identify a person, but most of the time their hobbies cannot be used. The sensitivity of data items is described further below. In some examples, the data items may not relate to any particular entity.

[0110] In some examples, the data provider 702 sends the data set to the cryptography service in the clear, i.e., the entire data set is in the clear and is not encrypted. As explained further below, in some examples, the data provider 702 may encrypt one or more data items before sending the data set to the cryptography service 701. In other words, in these examples, the data set obtained by the cryptography service 701 includes one or more data items that are encrypted, i.e., encrypted data items.

[0111] The data items in a set have an order starting with the first data item and ending with the last data item. Depending on the number of data items in the dataset, one or more data items may be located between the first and last data items. It will be appreciated that "first" and "last" are used merely to refer to the endpoints of a dataset, and the first data item does not necessarily have to be located at the beginning of the dataset. In other words, the last data item may appear first in the dataset, and the first data item may actually appear last in the dataset. In this case, the second data item would be the data item located in the penultimate position in the ordered set of data items. The data items may be ordered by the cryptography service 701 or the data provider 702. For example, the cryptography service 701 may receive a set of data items and may rearrange (i.e., reorder) the data items such that the order of the data items is scrambled (different) compared to the initial ordering of the received set. In some examples, the cryptography service 701 may generate one or more data items of the dataset.

[0112] Continuing with this example, when a data set is received in its raw format, the cryptography service 701 encrypts the data set using a wrapping encryption technique. First, the cryptography service 701 encrypts a first data item with a first encryption key. This generates a first encrypted value. As used herein, the term "value" may be substituted for "item" unless the context requires otherwise. That is, a value need not necessarily be a number. A second data item is then combined (e.g., concatenated) with the first encrypted value to generate a first combined value. The cryptography service 701 encrypts the first combined value with a second encryption key to generate a second encrypted value. If the data set contains only two data items, the process is complete. If the data set contains one or more additional data items, the process continues. In this case, a third data item is combined (e.g., concatenated) with the second encrypted value to generate a second combined value, and the second combined value is encrypted using a third encryption key to generate a third encrypted value. The process of encrypting data items continues until the final data item has been encrypted to generate a final encrypted value, also called the encrypted payload. Each respective stage (or step) of encryption involves encrypting a single data item in its raw form. Each encryption step, other than the first, also involves encrypting an encrypted value (combined with a plaintext data item).

[0113] As described above, the data provider 702 may encrypt one or more of the data items. In these examples, the data provider 702, rather than the cryptography service 701, performs some of the encryption steps. For example, the data provider 702 may encrypt a first data item, in which case the data set provided to the cryptography service 701 includes the first encrypted value rather than the first data item. The data provider 702 may encrypt more than one data item. For example, the data provider 702 may generate a second encrypted value, in which case the data set provided to the cryptography service 701 includes the second encrypted value rather than the first and second data items. In other words, the data provider 702 may encrypt one or more data items using a wrapping encryption scheme and send the resulting encrypted value (which encodes the one or more data items) to the cryptography service 701 rather than the data items. Effectively, in these examples, one of the "data items" in the data set received by the cryptography service 701 is an encrypted value that encodes one or more of the original plaintext data items.

[0114] In some examples, instead of or in addition to the data provider 702 performing some of the steps of the encryption protocol and the cryptography service 701 then performing the remaining steps, the encryption protocol may be used to add an additional layer of encryption to already encrypted data items. That is, the data provider 702 may encrypt one or more data items (using any encryption method), and the cryptography service 701 may then provide the encrypted versions of the data items to the cryptography service 702 for encryption using the wrapped encryption protocol (which may use any encryption method, e.g., AES). In other words, the data provider 702 provides a set of already encrypted data items to the cryptography service 701, which then performs each step of the wrapped encryption protocol. In an example, each data item received by the cryptography service may already be encrypted by the data provider 702. In other examples, some, but not all, of the data items received by the cryptography service 701 may already be encrypted by the data provider 702.

[0115] Each respective encryption step involves a respective encryption key. In some examples, each encryption key is different. However, it is not excluded that one or more encryption keys may be the same. In some examples, one or more consecutive data items are encrypted using the same encryption key. This would allow those data items to be revealed using the same encryption key. For example, the data items may be of similar sensitivity, importance, etc., and it may be appropriate / acceptable to reveal a subset of the data items to the same data accessor.

[0116] The wrapped encryption process is shown in Figure 7. In this example, a data provider 702 provides an array of data to a cryptography service 701. The data is encrypted element by element by the cryptography service 701. In this example, data item D1 is encrypted with encryption key k1, the result is encrypted together with data item D2 with encryption key k2, and the result is encrypted together with data item D3 with encryption key k3. A new encryption key may be used for each of k1, k2, and k3.

[0117] In some examples, the encryption keys may be used as part of a symmetric encryption scheme (e.g., AES) in which each encryption key used to encrypt each data item is the same key required to decrypt the corresponding encrypted value. As a particular example, the encryption algorithm may be 256-bit AES (CBC mode). In these examples, each encryption key may be a hash of a respective secret key. This is described further below. Alternatively, an asymmetric encryption scheme (e.g., ECIES) may be used in which a different key is required to decrypt the data. For example, the encryption key may be a secret key and the decryption key may be a corresponding decryption key.

[0118] The encryption keys may belong to or be generated from (e.g., by hashing) keys belonging to a hierarchical key structure, for example similar to those described with reference to Figures 5 and 6. Each encryption key may be derived from a common key of the key structure. For example, each encryption may be (a hash of) a child private key of the same parent private key. This is illustrated schematically in Figure 6, where multiple child encryption keys are derived from a parent key, which is ultimately derived from an encryption seed 601E.

[0119] In some embodiments, the cryptographic service 701 generates a blockchain transaction that includes the encrypted payload, i.e., the final encrypted value. The cryptographic service 701 sends the blockchain transaction to the blockchain network 106 for storage on the blockchain 150. Additionally or alternatively, the cryptographic service 701 sends the blockchain transaction to a different entity (e.g., the data provider 702) for transmission to the blockchain network 106. This transaction may be labeled as a target data storage transaction for ease of reference.

[0120] In these embodiments, the target data deposition transaction may be a data deposition transaction of an overlay network 300, such as the overlay networks described with reference to FIGS. 3-6. That is, the target data deposition transaction may be a node of the overlay network 300. For example, the target data deposition transaction may be a metanet transaction that forms a node of the metanet. Thus, the target data deposition transaction includes a signature corresponding to a parent public key assigned to a parent node of the metanet.

[0121] In some examples, the dataset may comprise one or more data items related to the overlay network. For example, the one or more data items may relate to the graph structure of the overlay network. For example, the one or more data items may include a public key assigned to a node represented by the target data deposition transaction. The node's public key uniquely identifies the target data deposition transaction as part of the graph structure. The one or more data items may include a transaction identifier of a parent transaction of the target data deposition transaction. The transaction identifier of the parent transaction indicates a link between the (child) target node corresponding to the (child) target data deposition transaction and the parent node corresponding to the parent data deposition transaction. Figure 8 illustrates a data array in which the final data item (first occurring in the data array) represents the node's public key P node and the transaction identifier TxID of the parent transaction parent In this example, P node and TxID parent form a single data item.

[0122] Previously, as described above with reference to FIG. 4, only the user data stored in a metanet transaction was encrypted (without using the wrapping encryption scheme described herein). However, this meant that the structural information contained in the metanet transaction was immutably available on-chain, allowing the structure of the metanet tree to be identified. Even if the user data itself is not accessible due to the encryption, identifying and determining the structure of the metanet tree can, in some instances, allow a third party to determine or at least infer characteristics of the user data. For example, if a third party knows that a metanet node is related to a user's medical prescriptions, the third party can associate the frequency of metanet transactions / nodes with the number of prescriptions and therefore infer the corresponding medication or treatment. Now, by encrypting the structural information, even the structure of the metanet tree to which the target data storage node belongs cannot be determined. This improves the privacy of the underlying user data. In some instances, the target transaction includes a metanet flag. However, this only allows a third party to determine that the transaction is a metanet transaction; it does not allow a third party to determine the tree structure. Figure 10 shows an example of a metanet transaction with an encrypted payload. In this example, all we can see is the metanet flag, which identifies the transaction as a metanet transaction.

[0123] Encrypting the structural information using a wrapping encryption scheme allows only the structural information to be revealed to a specific (i.e., given) data accessor, so that the metanet tree structure can be determined (e.g., for audit purposes) without revealing additional data, e.g., personal information related to users, companies, etc.

[0124] Providing different sets of encryption keys to different entities effectively establishes different versions of the Metanet tree, depending on which keys the entities have access to. For example, providing only an encryption key that reveals structural information only allows the entity to view the tree structure. That is, the entity can see the number of nodes in the tree and the links between those nodes, but not the data to which the tree pertains. As another example, the cryptography service 701 may provide an entity with an encryption key that reveals structural information and an encryption key that reveals one or more additional data items. This allows the entity to view those data items. In some examples, some, but not all, of the encryption keys are revealed. For example, a first data item may comprise identifying information, such as a name, email address, etc. By not revealing the encryption key that encrypts the first data item, the entity can view all of the other information without determining to whom that information pertains. This may allow a third party, for example, to perform statistical analysis on the data without knowing the user's identity.

[0125] The sensitivity of data items was discussed above. In some examples, different data items may have different levels of sensitivity, importance, secrecy, etc. In other words, the impact of some data being revealed may vary between data items. For example, a third party may gain less information by obtaining a user's zip code compared to obtaining their first line of the user's address. Similarly, a third party may gain less information by obtaining a user's favorite sports team compared to obtaining the user's passport information. Therefore, it may be important to apply encryption, and therefore more layers of protection, to more sensitive, more important, etc. data items. This improves the privacy of those data items. In examples, data items are ordered by level of sensitivity, with the most sensitive data items encrypted with the most layers of encryption and the least sensitive data items encrypted with the fewest layers of encryption. FIG. 9 shows an example data set in which a user's email address (most sensitive) is the first data item to be encrypted and structural information (least sensitive) is the last data item to be encrypted. In the example of Figure 9, the first two data items are encrypted by the data supplier 702 with associated encryption values provided to the cryptography service 701. The cryptography service 701 then applies a final layer of encryption by encrypting the third data item together with the received encryption value.

[0126] 7. Further Special Notes Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited not by the described embodiments, but only by the appended claims.

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

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

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

[0130] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 104.

[0131] Some embodiments are described with respect to a blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The node that is chosen is often called a validator. Blockchain nodes can look up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

[0132] For example, the above example describes overlay layer links being defined within the payload of a metanet transaction (e.g., by TxIDparent in the output of TxIDnode in the example of FIG. 4). However, this is not required. In alternative embodiments, the graph structure need not actually be declared on-chain, or at least not entirely. For example, a variant of a metanet may be provided in which some data structures are stored on the blockchain but overlay layer links may be stored off-chain. The hierarchy of keys signing the inputs of data-storage transactions would still be sufficient to recover (most of) the data structures, but only to someone who knows the seed, i.e., not the general public browsing the blockchain, thus improving privacy. In a further variant, the graph structure of a metanet (or other such overlay network) could be defined entirely off-chain, with only data content stored on-chain.

[0133] 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.

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

[0135] Statement 1. A computer-implemented method for encrypting data, the method being performed by a cryptographic service; generating an encrypted payload representing a data set comprising an ordered set of data items beginning with a first data item and ending with a final data item, said encrypted payload comprising the following steps: a) encrypting a first data item using a first respective encryption key to generate a first encrypted value; b) combining the second data item with the first encrypted value to generate a first combined value; c) encrypting the first combined value with a second respective encryption key to generate a second encrypted value; d) an encrypted payload is generated by repeating the steps of: i) combining each next data item with each latest encrypted value to generate a respective next combined value; and ii) encrypting each next combined value with each next encryption key to generate a respective next encrypted value, until the combination of the final data item and each latest encrypted value is encrypted using the respective next encryption key to generate a final encrypted value, wherein the encrypted payload comprises the final encrypted value.

[0136] Statement 2. The method of statement 1, wherein each respective encryption key is a different encryption key.

[0137] Statement 3. The method of statement 1, wherein one or more of the respective encryption keys are the same encryption key.

[0138] Statement 4. The method of any of statements 1-3, wherein said generating an encrypted payload by an encryption service comprises performing each encryption step.

[0139] Statement 5. The method of any of statements 1-3, wherein said generating an encrypted payload by the encryption service comprises performing at least one encryption step but not all encryption steps, and at least one encryption step is performed by a data provider, and the method further comprises: receiving from the data provider each encrypted value generated as a result of at least one encryption step performed by the data provider;

[0140] Statement 6. The method of statement 5, wherein the first data item is encrypted by the data provider, and said receiving comprises receiving a first encrypted value.

[0141] Statement 7. The method of Statement 5 or Statement 6, wherein all but one of the encryption steps are performed by a data provider, and the method comprises: receiving from the data provider each encrypted value produced as a result of all but one of the encryption steps performed by the data provider;

[0142] Statement 8. The method of any of statements 1-5, wherein one, some, or all of the respective data items in the set of data items are respective encrypted data items.

[0143] Statement 9. The method of any preceding statement, wherein each encryption step utilizes a symmetric encryption scheme.

[0144] Statement 10. The method of any preceding statement, wherein each data item is associated with a respective sensitivity, and the first data item is associated with the highest sensitivity.

[0145] Statement 11. The method of any preceding statement, wherein each respective encryption key is generated by hashing a respective private key.

[0146] Statement 12. The method of statement 11, Maintaining a hierarchical key structure comprising respective layers of private keys, each derivable from a common seed value, and each respective encryption key being a respective child private key of the same parent private key.

[0147] Statement 13. Any of the preceding statements, storing the encrypted payload in a target data storage transaction; and submitting the target transaction to a blockchain network for storage on the blockchain.

[0148] Statement 14. The method of any preceding statement, wherein an overlay network is overlaid on the data deposition transactions of the blockchain, whereby data content of the overlay network is deposited in the data deposition transactions, overlay network links are defined between the data deposition transactions, a graph structure of the overlay network comprises a plurality of nodes and edges between the nodes, each of the nodes corresponds to a different respective one of the data deposition transactions, each of the edges corresponds to a different respective one of the links, each node is associated with a respective signing key for signing inputs of the child data deposition transactions to authorize writing the child data deposition transactions of the overlay network to the blockchain, and the target data deposition transactions are each child data deposition transaction of the graph structure.

[0149] Statement 15. The method of statement 14, wherein each data item of the dataset comprises structural information that identifies a respective node in the graph structure that corresponds to the target data store transaction.

[0150] Statement 16. The method of statement 15, wherein the structural information comprises a transaction identifier of a parent data store transaction of the target data store transaction and / or a public key assigned to each node corresponding to the target data store transaction.

[0151] Statement 17. Any of the foregoing statements, Sending one or more of the respective encryption keys to the data accessor to selectively reveal one or more of the respective data items to the data accessor.

[0152] Statement 18. The method of statements 16 and 17, wherein said one or more of the respective encryption keys comprises a respective encryption key used to encrypt structural information.

[0153] Statement 19. The method of statement 17 or statement 18, wherein the data accessor is a data provider.

[0154] Statement 20. The method of any preceding statement, wherein each step of combining a respective data item with a respective encrypted value comprises concatenating the respective data item with the respective encrypted value.

[0155] Statement 21. A computer device, a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured, when on the processing device, to perform the method of any of statements 1 to 20.

[0156] Statement 22. A computer program embodied on computer-readable storage and configured, when executed on one or more processors, to perform the method of any of statements 1-20.

[0157] According to another aspect disclosed herein, a method may be provided that comprises encryption services and actions of a data provider.

[0158] According to another aspect disclosed herein, a system may be provided that includes a cryptographic service and a data provider's computer equipment. [Explanation of symbols]

[0159] 101 Packet-switched networks, Internet, base networks, network infrastructure 103a Alice 103b Bob 104 Blockchain nodes, Bitcoin nodes 106 Peer-to-peer (P2P) networks, decentralized networks, blockchain networks 150 Blockchain 152 transactions 202 Input, input field 203 Output, Output Field 300 Overlay Network, Metanet Network, Metanet Tree Structure 301 Node 302 Edge 402 Blockchain Layer Consumption Edge 500 Tree Structure, Key Tree 601E Encryption Seed 601F Seed Funding 601M Master seed, master key 601W Write Seed 700 System 701 Cryptography Services 702 Data Providers< / data> < / data>

Claims

1. 1. A computer-implemented method for encrypting data, the method being performed by a cryptographic service, comprising: generating an encrypted payload representing a data set comprising an ordered set of data items beginning with a first data item and ending with a final data item, said encrypted payload comprising the following steps: a) encrypting the first data item using a first respective encryption key to generate a first encrypted value; b) combining a second data item with the first encrypted value to generate a first combined value; c) encrypting the first combined value with a second respective encryption key to generate a second encrypted value; d) repeating the process of i) combining each next data item with each latest encrypted value to generate a respective next combined value, and ii) encrypting each next combined value with each next encryption key to generate a respective next encrypted value, until the combination of the final data item and each latest encrypted value is encrypted using a respective next encryption key to generate a final encrypted value; wherein the encrypted payload is generated by performing the following:

2. The method of claim 1 , wherein each respective encryption key is a different encryption key.

3. The method of claim 1 , wherein one or more of each of the encryption keys is the same encryption key.

4. The method of claim 1 , wherein the generating of the encrypted payload by the encryption service comprises performing each encryption step.

5. and wherein the generating of the encrypted payload by the encryption service comprises performing at least one encryption step but not all encryption steps, and at least one encryption step is performed by a data provider, the method comprising: receiving from the data provider each of the encrypted values generated as a result of the at least one encryption step performed by the data provider; 4. The method of claim 1, comprising:

6. 6. The method of claim 5, wherein the first data item is encrypted by the data provider, and the receiving step comprises receiving the first encrypted value.

7. All but one of the encryption steps are performed by the data provider, and the method comprises: receiving from the data provider each of the encrypted values generated as a result of all but one of the encryption steps performed by the data provider; The method of claim 5 or 6, comprising:

8. 6. The method of claim 1, wherein one, some, or all of the respective data items in the set of data items are respective encrypted data items.

9. 9. The method of claim 1, wherein each encryption step utilizes a symmetric encryption method.

10. 10. The method of claim 1, wherein each data item is associated with a respective sensitivity, the first data item being associated with the highest sensitivity.

11. 11. The method of any one of claims 1 to 10, wherein each respective encryption key is generated by hashing a respective private key.

12. maintaining a hierarchical key structure comprising respective layers of private keys, each private key derivable from a common seed value, and each respective encryption key being a respective child private key of the same parent private key; The method of claim 11.

13. storing the encrypted payload in a target data store transaction; submitting the target data storage transaction to a blockchain network for storage on the blockchain; 13. The method of claim 1, comprising:

14. 14. The method of claim 1, wherein an overlay network is overlaid on the data storage transactions of a blockchain, whereby data content of the overlay network is stored in the data storage transactions, overlay network links are defined between the data storage transactions, the graph structure of the overlay network comprises a plurality of nodes and edges between the nodes, each of the nodes corresponds to a different one of the data storage transactions, each of the edges corresponds to a different one of the overlay network links, each node is associated with a respective signing key for signing inputs of the child data storage transactions of the overlay network to authorize writing the child data storage transactions of the overlay network to the blockchain, and a target data storage transaction is a respective child data storage transaction of the graph structure.

15. The method of claim 14 , wherein each data item of the data set comprises structural information that identifies each of the nodes in the graph structure that correspond to the target data storage transaction.

16. 16. The method of claim 15, wherein the structural information comprises a transaction identifier of a parent data storage transaction of the target data storage transaction and / or a public key assigned to each of the nodes corresponding to the target data storage transaction.

17. sending one or more of the respective encryption keys to the data accessor so as to selectively reveal one or more of the respective data items to the data accessor; 17. The method of any one of claims 1 to 16, comprising:

18. 18. The method of claim 16 or 17, wherein one or more of the respective encryption keys comprises the respective encryption key used to encrypt the structural information.

19. 19. The method of claim 17 or 18, wherein the data accessor is the data provider.

20. 20. The method of claim 1, wherein each step of combining a respective data item with a respective encrypted value comprises the step of concatenating said respective data item with said respective encrypted value.

21. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; wherein the memory stores code configured to run on the processing device, the code being configured, when on the processing device, to perform the method of any one of claims 1 to 20. Computer equipment.

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

Images