Package encryption

Abstract

A computer-implemented method encrypts data by performing the following steps: a) encrypting a first data item using a first corresponding 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 using a second corresponding encryption key to generate a second encrypted value; and d) repeating the following processes: i) combining the respective next data item with the respective latest encryption value to generate a respective next combined value, and ii) encrypting the respective next combined value using a next respective encryption key to generate a respective next encrypted value, a combination of the final data item and the corresponding latest encryption value has been encrypted using the next corresponding encryption key to generate a final encryption value, the encryption load including the final encryption value.

Description

Technical Field

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

[0002] Blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely disclosed. The blockchain includes a series of data blocks, each of which includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in a sequence, which can span one or more blocks back to one or more coinbase transactions. The coinbase transaction will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block is generally referred to as "mining", which involves each of a plurality of nodes competing to perform "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of blocks can be achieved by publishing only the block header.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing time-stamped entries; and / or sorting index pointers by time. Blockchains can also be used to implement hierarchical additional functions on blockchains. For example, a blockchain protocol may allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in a blockchain.

[0004] The nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, nodes verify transactions and insert them into block templates, which attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes of the network, so that each node can record the new block on the blockchain. In order to record a transaction in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The nodes receiving the transaction can compete to find a proof-of-work solution that incorporates the verified valid transaction into the new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that the transaction is valid. Invalid transactions will not be propagated or incorporated into the block. Assuming that the transaction has been verified to be valid and thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an immutable public record on each node in the blockchain network.

[0005] The node that successfully solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e. the number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, which act as agents of the network and are incentivized to report and prevent improper behavior. The widespread publication of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the continued integrity of the blockchain.

[0006] In the "output-based" model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies future redemption conditions for the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (except for a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and may also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset, and includes a locking script that defines one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

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

[0008] Another transaction model is the account-based model. In this case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored individually by the node in the blockchain and is constantly updated.

[0009] The blockchain network itself is an overlay network that is overlaid on the underlying network (e.g., the Internet). However, it is also possible to overlay another layer of overlay network on the blockchain. Metanet is an example of this. Each node of Metanet is a different transaction on the blockchain. The data content and Metanet metadata are stored in the payload of each such transaction, which is stored in the output of the transaction via OP_RETURN. The data content is the actual user content stored by Metanet, such as text, images, video or audio content, etc.; while the metadata defines the links between Metanet nodes. The links or edges between Metanet nodes do not necessarily correspond to the spending edges of the blockchain layer. That is, if the input of a given Metanet transaction points to the output of another funding transaction at the blockchain layer, the parent node of the same transaction or Metanet node at the Metanet layer is not necessarily the same as the funding transaction. Instead, the links or edges at the Metanet layer define the links between the data content of the Metanet. Summary of the invention

[0010] There are various techniques to encrypt (i.e., obfuscate) data in order to ensure the privacy and confidentiality of the data. The process of encrypting and decrypting data involves the following keys: an encryption key, which is used to encrypt the data; and a decryption key, which is used to decrypt the data. Depending on the type of encryption scheme (symmetric or asymmetric), the encryption key can be the same as or different from the decryption key.

[0011] Typically, the set of data items is encrypted as a whole. That is, the entire set of data items is encrypted as a whole using a single encryption key. One problem with this type of encryption protocol is that when the data is decrypted, the entire set of data items is revealed. This can be problematic, for example, if the data set contains information of varying importance, sensitivity, classification, etc. While some data may be suitable for access by the decrypting party, some data may not be. This creates a problem where the decrypting party either has access to all the data (by providing the decryption key) or has no access to any of the data (in the case where the decryption key is withheld).

[0012] Some protocols involve encrypting sets of data items using multiple encryption keys. That is, a first encryption key is used to encrypt the entire data set, creating an encrypted data set; a second encryption key is used to encrypt the encrypted data set, providing another layer of encryption. This process can be repeated multiple times. This adds an additional layer of security to the data (assuming the encryption keys are different). Encrypting the data items using different encryption schemes may also add an additional layer of security to the data. However, while these techniques can be used to add additional layers of security to the data, the same access issues exist. That is, even if certain data items are not suitable for viewing by an accessing party provided with a set of decryption keys, it is not possible to prevent that party from accessing the entire data set.

[0013] It would therefore be desirable to provide an encryption protocol that addresses the above-mentioned problems by enabling selective disclosure of different data items. That is, it would be advantageous to control the amount of data accessible to the decrypting party.

[0014] According to one aspect disclosed herein, a computer-implemented method for encrypting data is provided, wherein the method is performed by an encryption service and includes: generating an encrypted payload, the encrypted payload representing a data set, the data set including an ordered set of data items, the 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 using a first corresponding 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 using a second corresponding encryption key to generate a second encrypted value; and d) repeating the following process: i) combining a corresponding next data item with a corresponding latest encrypted value to generate a corresponding next combined value, and ii) encrypting the corresponding next combined value using a corresponding next encryption key to generate a corresponding next encrypted value, until the combination of the final data item and the corresponding latest encrypted value has been encrypted using the corresponding next encryption key to generate a final encrypted value, the encrypted payload including the final encrypted value.

[0015] The disclosed encryption protocol is referred to herein as "wrapped encryption," which refers to the manner in which another layer of encryption is wrapped around the first data item as each successive data item is encrypted. That is, as the first data item is encrypted, a first layer of encryption is applied to (or wrapped around) the first data item; then, as the second data item and the encrypted first data item are encrypted, 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 (in the case of 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, applying another layer of encryption to each data item, until all data items have at least one layer of encryption. The first layer of encryption may be referred to as the innermost layer of encryption, while the last layer of encryption may be referred to as the outermost layer of encryption.

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

[0017] For illustrative purposes, some embodiments will be described in the context of encrypting data stored as part of a Metanet. However, it should be understood that this is not so limited, and more generally, the same principles can be applied to encrypting nodes that are part of any overlay network overlaid on a blockchain. Furthermore, the same principles can be applied to encrypting any type of data, whether the encrypted data is stored on a blockchain or otherwise.

[0018] For example, in some examples, the final data item in the data set includes data related to a Metanet transaction of the Metanet tree, such as an identifier of the transaction and / or a parent transaction. The data can be structural data and / or positional data, in that the data is related to the structure of the Metanet tree and / or the position of the transaction in the Metanet tree. For example, the data can identify a link between a transaction and its parent transaction. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0021] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown;

[0022] Figure 3 It is a schematic diagram of the network overlaid on the blockchain;

[0023] Figure 4 is a schematic transaction diagram illustrating an exemplary protocol for overlaying a network (such as Metanet, etc.) on a blockchain;

[0024] Figure 5 Schematically illustrating a hierarchical key set having a tree structure identical to at least a portion of a Metanet node network;

[0025] Figure 6 A scheme for deriving multiple key domains, each of which includes a hierarchical set of keys, is schematically shown;

[0026] Figure 7 schematically illustrates an exemplary process for encrypting data;

[0027] Figure 8 yes Figure 7 Specific examples of the processes shown;

[0028] Fig. 9 An example of splitting the encryption process between different entities is shown;

[0029] Fig.10 An exemplary blockchain transaction storing encrypted data is schematically illustrated. DETAILED DESCRIPTION

[0030] 1. Exemplary System Overview

[0031] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 101, typically a wide area internet such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0032] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0033] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output that is cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0034] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0035] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to spend the same output.

[0036] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming an output, or allocating it to one or more outputs in another subsequent transaction. In general, a previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, it is not necessary for a previous transaction 152i to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily the creation time or sending time in a time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of isolated transactions below). A previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0037] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0038] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends (or "allocates"), where the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0039] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it is validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents double spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at all times.

[0040] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0041] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it spends or allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0042] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0043] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify 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 often called a "transaction fee" and is discussed below.

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

[0045] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0046] Computer devices 102 of each of the parties 103 acting as consuming users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0047] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0048] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as 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 computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0050] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0051] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0052] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This can enable 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 to which the corresponding party 103 is a recipient (or indeed to check other parties' transactions in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

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

[0054] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0055] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0056] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is “valid” before one 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, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0057] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of a previous transaction in the past sequence of transactions, but by reference to an absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using an account's running transaction record (also called a "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, optional data fields can also be signed in the transaction. For example, a data field can point to a previous transaction if it contains the ID of the previous transaction.

[0058] 2. UTXO-based model

[0059] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx" for short) is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

[0060] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not been redeemed). The UTXO includes a value that specifies the amount of a digital asset. This represents a set of tokens on a distributed ledger. The UTXO may also include a transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input field 202 and the output field 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0061] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In , Alice's new transaction 152j is labeled "Tx1". This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. Figure 2, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels that do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0062] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already be valid and included in block 151 of the blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 may even be sent after Tx1. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may equally be replaced by "predecessors" and "successors", "predecessors" and "descendants", or "parents" and "children", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") pointing to a previous transaction (predecessor transaction or "parent transaction") will not be valid unless the parent transaction is valid. A child transaction that arrives at the blockchain node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0063] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking condition, which typically includes the following conditions: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

[0064] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0065] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A >, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0066] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

[0067] <Sig PA> <pa>||[Checksig PA]

[0068] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (included in the locking script of the output of Tx0) to verify that the unlocking script in the input of Tx1 contains Alice's signature when signing the expected portion of the data. The expected partial data itself (the "message") also needs to be included in order to perform this verification. In an embodiment, the signed data includes the entire Tx1 (so there is no need to include a separate element to clearly specify the signed partial data, as it is already present).

[0069] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message using her private key cryptographically, then given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a particular data fragment or transaction portion, etc., may mean signing the hash value of that data fragment or transaction portion.

[0070] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will propagate throughout the network 106. Once Tx1 is valid and included in the blockchain 150, this will define UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid if it spends unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (that is, whether it has formed a valid input for another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a transaction 152 as having been spent, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0071] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0072] Note that in the UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave behind" a portion of the amount defined in a UTXO as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split between multiple UTXOs in Tx1. Therefore, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remaining portion to make change for herself in the second output of Tx1, or to pay another party.

[0073] In practice, Alice will also typically need to include a fee for the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and therefore, although technically valid, may not be propagated and included in the blockchain 150 (if the blockchain node 104 does not want to accept transaction 152, the node protocol does not force the blockchain node 104 to accept it). In some protocols, the transaction fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that 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 spent) by the node 104 that wins the proof-of-work race to create the block containing UTXO1. Alternatively or additionally, this does not necessarily preclude the possibility of explicitly specifying a transaction fee in one of the UTXOs 203 in its own transaction 152.

[0074] Alice and Bob's digital assets consist of the UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, in general, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To achieve this, it can query a copy of the blockchain 150 stored at any one Bitcoin node 104.

[0075] It should be noted that script code is often represented schematically (i.e., using an imprecise language). For example, an opcode (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode of the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a file to be stored in the blockchain.

[0076] Typically, the inputs to a transaction contain a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0077] The locking script is sometimes referred to as "scriptPubKey", which means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it usually provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include verification of the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0078] 3. Side Channels

[0079] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). The side channel 107 enables data to be exchanged away from the blockchain network. Such communications are sometimes referred to as "off-chain" communications. For example, this can be used to exchange transactions 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0080] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0081] 4. Layer 2 Overlay Network

[0082] The blockchain network 106 itself takes the form of an overlay network overlaid on a network (e.g., the Internet 101). However, another overlay network can also be overlaid on top of the blockchain. Figure 3 This is explained by way of example in . Metanet is an example of this. Such a network can also be called a "layer-2" network because it is a second-layer overlay network relative to the base network 101 (e.g., the Internet) as the underlying network infrastructure and the blockchain network 106 as the first-layer overlay network overlaid on the base network.

[0083] The second layer overlay network 300 includes a network consisting of nodes 301 and edges 302. It should be noted that node 301 now refers to the node of the Metanet (or other such network overlaid on the blockchain) layer, rather than the node previously combined with Figure 1 and Figure 2 The node 104 of the blockchain network 106 layer. Each node 301 of the Metanet network (or similar network) is a different corresponding transaction 152 on the blockchain 150, each of which stores data in the payload (also translated as effective load) of the corresponding transaction. Therefore, the node 301 of the Metanet network 300 (or similar network) may also be referred to as a data storage node or a data storage transaction in this article. The data stored therein may include data content and / or metadata, usually both of which are included. In an output-based model, the data may be stored in the output 203 of the corresponding transaction. The output may be unspendable or spendable. The output may become unspendable by locking one or more opcodes in the script, which terminates the script at runtime. For example, in a system using a scripting language, this may be a combination of OP_0 and OP_RETURN opcodes. However, this is not limited to this, and those skilled in the art will understand other techniques for storing arbitrary payload data in transactions of other blockchain systems, such as in systems using an account-based model. The following is an example of an output-based model, but this is not limited to this.

[0084] It should be noted that the layer 2 overlay network 300 may consist of data only, i.e., a completely virtual network. That is, the nodes 301 and edges 302 of the Metanet or the like as an overlay network overlaying the transactions 152 of the blockchain 150 do not necessarily correspond to any specific physical participants or entities of the underlying blockchain network 106 or the underlying network infrastructure 101.

[0085] Data content is the actual data that the Metanet (or similar network) stores, such as text, audio, static or dynamic images, or other files or documents. This may also be referred to as user content or user data. Metadata implements the protocol that layers the network on top of the blockchain 150. In at least some transactions 152, it defines links between data content. These may also be referred to as edges 302 between nodes 301. For example, a link or pointer may include the transaction ID of the parent node, i.e., TxID parent It should be noted that a "link" in this document does not necessarily refer to a hypertext link, although there is a certain possibility. More generally, a link can refer to any form of pointer that points to another node 301 related to the current node 301 at the Metanet layer (or other such overlay layer on top of the blockchain 150).

[0086] For convenience, the following description uses Metanet as an example, but it should be understood that this is not limited to this. More generally, any reference to Metanet in this article can be replaced with any overlay network overlaid on the blockchain. Similarly, any reference to a Metanet node can 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 can be replaced with a reference to any overlay network edge or link of the relevant overlay network layer.

[0087] The Metanet Protocol defines a scheme and standard for structuring on-chain data that can be recorded on a public blockchain and used for different applications in many use cases. The protocol specifies that graph structures (including nodes and edges) can be constructed from multiple sets of blockchain transactions, and that these structures can be used to store, communicate, represent, and distribute data ("content") of any nature. By treating transactions as nodes and signatures as edges created between transactions, the Metanet Protocol allows the creation of Figure 3 The on-chain graph structure shown.

[0088] It can be seen that the nodes 301 and edges 302 of Metanet 300 form a tree structure. That is, a parent node 301 is linked to one or more child nodes 301, and any given child node 301 itself can be a parent that is linked to one or more of its own children, and so on. It should be noted that for the purposes of the present invention, the relevant tree structure can only be a subset of a wider tree or graph.

[0089] Figure 3 It also shows how to update a node 301 and its associated edge 302. Since transactions are immutably recorded on the blockchain 152, updating a Metanet node 301 requires creating a new instance 301' and corresponding edge 302' through a new transaction 152.

[0090] Figure 3 The structure shown can include nested domains, such as the structure of a website and its pages, where a "top-level domain" encapsulates subdomains below it, and so on. A functional key domain (discussed later, such as the domains for writing keys, funding keys, encryption keys) can span many such structural domains. It should not be confused with Figure 3 The structural "fields" shown are related to the functional key fields discussed later.

[0091] Figure 3 The circles in the figure represent nodes, which are simply transactions created according to the ruleset of the Metanet protocol. Figure 4 An example of a transaction 152N created and formatted according to this rule set is shown in FIG.

[0092] Figure 4 Transaction 152N on the middle right side represents transaction 152 of blockchain 150 of a given node 301N (child node) implementing the Metanet. Figure 4 Transaction 152P in the upper left corner represents a transaction of blockchain 150 that implements the parent node of child node 152N at the Metanet layer. Child node transaction 152N has input 202, which includes an unlocking script and points to output 203 of funding transaction 152F of blockchain 150. In other words, the input of Metanet node 152N consumes the output of funding transaction 152F. It should be noted that funding transaction 152F and Metanet parent transaction 152P are not necessarily the same transaction (although this possibility is not excluded).

[0093] Subtransaction 152N includes an unspendable output 203 (e.g., made unspendable by OP_RETURN) with a payload (from the blockchain layer's perspective). The payload may include Metanet data content that may or may not be encrypted. Figure 4 In the example, the data content ("data") is shown in clear text. However, as discussed further below, this may be replaced by an encrypted version of the data (in which case, <data>will be replaced by Figure 4 In<e(Data)> , where "e" means the data is encrypted).

[0094] The payload of subtransaction 152N also includes metadata at the Metanet network layer. The metadata includes at least the transaction identifier of the parent transaction 152P. This creates a link (edge) 302 at the Metanet layer. The Metanet protocol may also require the inclusion of a key P associated with the child node 301N. node .

[0095] The locking script of output 203 of funding transaction 152F also requires that a signature be included in the unlocking script of input 202 of child node 152N. Specifically, this signature must be signed using the key P associated with the Metanet parent key. parent 152F is a subtransaction 152N that is signed by a signature (i.e., a message signed by that key). This creates an edge 402 (sometimes referred to as a spend edge) at the blockchain layer. If the unlocking script of input 202 of subtransaction 152N does not contain the required signature, then subtransaction 152N will not be verified by nodes 104 of blockchain network 106 and therefore will not be propagated through blockchain network 106 and will not be recorded on blockchain 150. However, it should also be noted that funding transaction 152F is not necessarily the same blockchain transaction 152 as Metanet parent transaction 152P, and therefore blockchain layer spend edge 402 is not necessarily the same as Metanet layer edge 302.

[0096] Figure 4 Only specific relevant components of Metanet transactions that serve as a complete transaction abstraction layer are outlined. In addition to the protocol identifier flag, these components include:

[0097] Public key P_node;

[0098] Signature SigP_Parent of the parent public key P_Parent;

[0099] The transaction ID of the node itself, TxID_node; and

[0100] The transaction ID of the node's parent, TxID_Parent.

[0101] Placeholder <data>Generally refers to any content data that can be included in a Metanet node transaction. In many applications, it may also be necessary to encrypt data. The encryption of data is discussed further below.

[0102] Each Metanet node 301 can be uniquely identified by a node pair (P_node, TxID_node), which is an index that can inherit strong version control and permission control from the Metanet graph. It should also be understood that each Metanet node contains enough information to identify itself (P_node, TxID_node) and its parent node (P_parent, TxID_parent).

[0103] In order to ensure that the Metanet node 301N transaction contains the correct input signature SigP_Parent from the parent node 301P, it is necessary to create a funding transaction in many cases. For details, see Figure 4 .

[0104] The parent key Pparent and / or the child node key Pnode may be considered as a write key that authorizes writing the data of the child node 301N to the blockchain 150. These may also be referred to herein as "structure keys".

[0105] 5. Hierarchical Key Sets

[0106] The keys associated with blockchain transactions 152 (for a particular user or application) are typically managed using a hierarchical key structure. For example, a general standard called hierarchical deterministic (HD) key management has emerged to handle the many private and public keys that may be associated with a given user's wallet. The standard is intended to facilitate the handling of many such key pairs by: ensuring that all keys in a user's wallet can be derived from a single entropy source; and ensuring that the keys are derived from that seed in a deterministic manner using a publicly known derivation function. HD wallets are known per se, and are simply wallets that use an explicit standard for deriving keys intended for use in transactions outlined in a number of improved protocols called "BIPs" (i.e., BIP32, BIP39, and BIP44). In essence, these standards define ways to: deterministically generate many private and public keys from a "seed" key; define a "path" for generating a specific derived key from a seed key; and define a hierarchical wallet structure using a deterministic key derivation function. These standards for handling keys associated with a given user’s funds or transactions with a specific application are widely used in the blockchain industry.

[0107] A deterministic algorithm for deriving a key from another key in a deterministic manner is sometimes called a child key derivation (CKD) function. Thus, a set of keys can be determined starting from a seed, all of which are related to each other in a hierarchical manner. Such a hierarchical key set also has a tree structure. That is, the keys in the key set are derived from each other in a derivation hierarchy 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 can be derived from the key, and so on. In this tree structure, each node is a key, and each edge represents the derivation of the key from its parent key. Given a parent key or seed, any party who knows the algorithm can deterministically determine one or more of its child keys or seeds; but given a child key, it is impossible (or at least computationally impossible) to determine the parent key. Various forms of CKD are known in the art that allow the generation of hierarchical key sets with any desired arbitrary graph structure (e.g., a tree structure).

[0108] It is important to note that when a given key or key graph structure is derived by applying CKD to a seed or parent key, it does not exclude that the key or graph structure can be derived by applying CKD to the seed / parent key and some other data. For example, in an embodiment, the CKD function takes as input: a parent key or seed, some other data called a chain code, and an index to create child keys (multiple sibling keys) for a given parent key. Likewise, the chain code and / or index can be considered as parameters that parameterize the CKD form.

[0109] It is also important to note that the term "seed" as used herein does not necessarily mean that the seed is the absolute top-level key in the entire hierarchy or tree. More generally, CKD can be applied to any key in the hierarchy to generate one or more child keys from it. A "seed" in this context is simply any parent key or value from which other child keys in a given key set are derived. In embodiments, a seed itself can be a child key of another key or a seed in a wider hierarchy (e.g., see Figure 6 , which will be discussed in more detail later).

[0110] As described above, each Metanet node 301 has a key P associated with it in the Metanet network layer (see Figure 4 In some examples, it is advantageous to generate these keys according to a tree structure 500 that maps directly to the corresponding tree structure 300 of the Metanet network nodes 301 and edges 302. That is, each Metanet node 301 in the Metanet tree structure maps to only one corresponding key in the key tree 500, and each Metanet edge 302 maps to only one corresponding key derivation edge in the key tree 500. This would mean that given the position of a node 301 in the Metanet tree, knowledge of the seed, and the form of the CKD function used, it would always be possible to derive the relevant key required for that node 301.

[0111] 6. Functional key domain

[0112] If we examine the standard Metanet transaction 152N (such as Figure 4 As shown, which may include encrypted data) and its corresponding funding transaction 152F, it can be seen that there are many different keys associated with a single Metanet node 301 (Pnode, Pparent, TxIDnode, ek).

[0113] Many different types of keys may be associated with a Metanet node and their corresponding funding transactions. For example, these keys can be categorized based on the following functions:

[0114] Structure (write) keys - P_node, P_parent

[0115] Encryption Key -ek

[0116] Funding Key - P_Funding

[0117] It should be noted that in more complex examples of Metanet transactions, there may also be other key types involved in other functions used to create Metanet node transactions 152N and / or perform other functions related to Metanet nodes 301. For example, other types of keys may be application layer keys that facilitate the implementation of application layer functions, such as idempotence keys (to ensure that the data of node 301 is not used more than once or calculated twice for some application layer purpose). For another example, as an alternative or in addition to encryption, the data content may be obfuscated in another form, such as padding or reordering, which may require a corresponding obfuscation key for obfuscation and / or deobfuscation.

[0118] As previously discussed, it is advantageous to manage keys using the ubiquity and robustness of the HD wallet standard (or similar standards), and in the embodiments disclosed herein, this requirement extends to any or all such key types, such as structural keys, encryption keys, and funding keys. However, it may be necessary to handle and manage different key types separately. In addition, preferably, all keys should be derived from the same seed to reduce the risk of leakage. However, these two requirements are quite contradictory. It is not clear how to ensure key separation and at the same time keep all keys derived from the same seed key. As mentioned above, to further complicate things, another desirable property of such HD key hierarchies is that the derivation path for a given key should be mapped (at least in part) to the Metanet graph structure. In other words, in addition to reconciling the first two conflicting requirements, reflecting the Metanet graph structure (e.g., as Figure 5 is the third requirement that must be met.

[0119] One solution to this problem is disclosed below, which is to define the functional key domain as a branch of an HD wallet whose keys are associated with a single function involved in creating a specific transaction.

[0120] For a Metanet transaction, there may be two, three, or more different functions to consider (e.g., construction function, encryption function, and funding function), and each key type will be assigned a separate branch of the HD key structure.

[0121] The write keys (i.e., structure keys) Pnode and Pparent are used to sign Metanet transactions, the encryption keys are used to encrypt any content data contained in the transactions, and the funding keys are used to sign funding transactions whose UTXOs are consumed by Metanet transactions.

[0122] All keys in the overall HD structure are unique and cannot be related to each other without knowing the wallet's master key (mk) pair (master seed). However, they are related because they all belong to the same Metanet structure location. This common location is encoded using a multi-path type system embedded in the overall path of a given key.

[0123] Figure 6 An example of assigning different functional key fields is shown. Figure 6 An exemplary derivation tree is shown, which can be created using the CKD function. Preferably, the top level (source or root) of the tree is the master seed 601M (mk). Multiple sub-seeds are derived from this, one for each type of function in multiple types of functions. Each sub-seed acts as the source / root of a corresponding key set for a corresponding type of function (e.g., a write function, an encryption function, and a funding function). In the example shown, three such functions have three sub-seeds respectively: a write seed 601W, which is used to derive a key set for a write key P to be able to write to a Metanet node 301; an encryption seed 601E, which is used to derive a key set for an encryption key ek to encrypt and / or decrypt the data content of a node 301; and a funding seed 601F, which is used to derive a key set to provide funds for recording the corresponding transaction 152 of the node 301 on the blockchain 150. The seed itself can be considered a type of key (referring to the seed of a sub-master key or its corresponding key set when all are derived from the same master key 601M).

[0124] Each key set includes a corresponding tree structure, according to which the keys in the corresponding key set are derived from each other. Each such tree structure is a subtree of the overall tree from the master seed 601M. In each key set, the tree structure is directly mapped to the tree structure of the Metanet 300. Therefore, the tree structures of different key sets are identical to each other. Therefore, for example, each node 301 (or its related fragment) of the Metanet has a write key, and the derived edges of these keys are exactly the same as the corresponding edges 302 in the Metanet tree structure 300. At the same time, each node 301 (or its related fragment) of the Metanet has a fund key, and the derived edges of the fund key are exactly the same as the endpoints between the corresponding edges 302 in the Metanet tree structure 300 and the corresponding write keys in the write key set. Similarly, for encryption and / or any other function, a key set will be derived for it according to this scheme.

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

[0126] It is also important to note that for one or more function types (e.g., encryption functions), multiple key sets may be generated, for example for multiple layers of encryption. Figure 6 As shown in the bottom-center example, each encryption key set has the same tree structure.

[0127] Additionally, it is important to note again that "seed" as used herein does not necessarily refer to the absolute final master seed of a wider tree structure. For example, write seed 601W is itself a subkey of master seed 601M. A seed is simply any type of key or value that can be used to derive other keys. In an embodiment, the seeds for different functions (e.g., 601W, 601E, 601F) are actually derived from some master seed or key 601M. A seed in this article can refer to a special type of key that is (at least locally) a "top-level" key in a hierarchy for a given key set, but may also be a subkey in a wider hierarchy.

[0128] It should be understood that the examples of writing, encryption, and funding are merely some examples of different types of functions that may be implemented in a Metanet (or similar network), for which corresponding sets of keys may be required, one for each node in a given set of a given function type. More generally, the above scheme may be used for any set of keys for a first function and a second function, and in some embodiments, for a third function or more. For example, encryption may be generalized to any obfuscation (e.g., padding or reordering). Alternatively, the scheme may be used for completely different types of keys, such as application layer sequence numbers that are intended to be assigned to each Metanet node 301 for some application layer purpose (e.g., idempotence).

[0129] 7. Encrypt data for selective disclosure

[0130] Embodiments of the present disclosure provide an encryption method (referred to herein as "wrapped encryption") that can be used to selectively reveal (i.e., disclose) different data belonging to a data set. For example, data can be revealed based on the sensitivity of the data, the type of data, the access rights of the data accessor, etc.

[0131] Figure 7 An exemplary system 700 for encrypting data using the method (ie, protocol) disclosed herein is shown. As shown, the system 700 includes an encryption service 701 and a data provider 702. Although the encryption service 701 and the data provider 702 are Figure 7 Although shown as separate entities, it is not excluded that the encryption service 701 and the data provider 702 may be composed of a common entity, for example, the encryption service 701 and the data provider 702 may be different components of the same system. Figure 7 As shown, the system may also include a data accessor and one or more nodes 104 of a blockchain network 106. The data accessor may be the same entity as the data provider 702.

[0132] Typically, the encryption service 701 and the data provider 702 each include and operate a corresponding computer device, which includes a corresponding processing device, and the corresponding processing device includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, dedicated processors, encryption processors and / or FPGAs. The corresponding computer device also includes a corresponding memory, that is, a computer-readable memory in the form of a non-transient computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as 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 corresponding computer device can store software, which includes a corresponding instance of at least one client application that is set to run on the processing device. It should be understood that any action attributed to the encryption service 701 or the data provider 702 in this article can be executed using software running on the processing device of the corresponding computer device of the encryption service 701 or the data provider 702. The corresponding computer device includes at least one user terminal, such as a desktop computer or a laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The corresponding computer device may also include one or more other network resources, such as cloud computing resources accessed by a user terminal.

[0133] In some examples, the encryption service 701 can be configured to perform the above-referenced Figure 1 and Figure 2 Any actions attributed to Alice 103a and / or Bob 103b. Similarly, data provider 702 may be configured to perform any actions attributed to Alice 103a and / or Bob 103b.

[0134] Typically, a data provider 702 has access to a data set to be encrypted. The data set includes multiple data items. These data items may relate to individuals, companies, organizations, objects, and the like. For example, these 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, and the like. These data items may relate to details of a company, such as financial records, employee records, purchase history, sales history, and the like. In some examples, certain data items may be more sensitive (or important) than other data items. For example, a person's email address may be more sensitive than their hobbies because, in most cases, the email address can be used to identify the person, while their hobbies may not be able to achieve this. The sensitivity of data items will be discussed further below. In some examples, these data items may not relate to any particular entity.

[0135] In some examples, data provider 702 sends the data set to encryption service in plaintext. That is, the entire data set is in plaintext and is not encrypted. As will be discussed further below, in some examples, data provider 702 may encrypt one or more data items before sending the data set to encryption service 701. In other words, in these examples, the data set obtained by encryption service 701 contains one or more data items that have been encrypted (i.e., encrypted data items).

[0136] The order of the data items in the data set starts from the first data item and ends with the final data item. Depending on the number of data items in the data set, one or more data items may be located between the first data item and the final data item. It should be understood that "first" and "final" are only used to refer to the endpoints of the data set, and the first data item does not have to be located at the beginning of the data set. In other words, the first data item may actually appear in the last position in the data set, and the final data item appears in the first position in the data set. In this case, the second data item will be the data item located in the second to last position in the ordered data item set. The data items can be sorted by the encryption service 701 or the data provider 702. For example, the encryption service 701 can receive a data item set and rearrange (i.e., reorder) the data items so that the order of the data items is scrambled (different) compared to the initial sorting of the received set. In some examples, the encryption service 701 can generate one or more data items of the data set.

[0137] Continuing with the example of receiving a data set in its original form, encryption service 701 encrypts the data set using encapsulation encryption technology. First, encryption service 701 encrypts a first data item using a first encryption key. This generates a first encrypted value. Unless the context requires otherwise, the term "value" used herein may be replaced with "item". That is, a value is not necessarily a number. Then, a second data item is combined (e.g., concatenated) with the first encrypted value to generate a first combined value. Encryption service 701 encrypts the first combined value using 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 the data items continues until the final data item has been encrypted to generate a final encrypted value, also referred to as an encrypted payload. Each corresponding stage (or step) of encryption involves encrypting a single data item in its original form. With the exception of the first encryption step, each encryption step involves encrypting an encrypted value (which is combined with the plaintext data item).

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

[0139] In some examples, instead of or in addition to data provider 702 performing some of the steps of the encryption protocol and encryption service 701 subsequently performing the remaining steps, the encryption protocol can be used to add an additional encryption layer to the already encrypted data items. That is, data provider 702 can encrypt one or more data items (using any encryption scheme) and provide the encrypted version of the data items to encryption service 702 so that encryption service 701 can then encrypt using the encapsulation encryption protocol (which can use any encryption scheme, such as AES). In other words, data provider 702 provides the encrypted set of data items to encryption service 701, and then encryption service 701 performs each step of the encapsulation encryption protocol. In the example, each data item received by the encryption service may have been encrypted by data provider 702. In other examples, some but not all of the data items received by encryption service 701 may have been encrypted by data provider 702.

[0140] 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 will allow the same encryption key to be used to reveal these data items. For example, these data items may have similar sensitivity, importance, etc., and it may be appropriate / acceptable to reveal a subset of the data items to the same data accessor.

[0141] The encapsulation encryption process is as follows Figure 7 As shown. In this example, data provider 702 provides an array of data to encryption service 701. The data is encrypted element by element by encryption service 701. In this example, data item D1 is encrypted using encryption key k1, the result is encrypted with data item D2 using encryption key k2, and the result is encrypted with data item D3 using encryption key k3. A new encryption key can be used for each of k1, k2, and k3.

[0142] In some examples, the encryption key can be used as part of a symmetric encryption scheme (e.g., AES), where the corresponding encryption key used to encrypt the corresponding data item is the same as the key required to decrypt the corresponding encrypted value. As a specific example, the encryption algorithm can be 256-bit AES (CBC mode). In these examples, the corresponding encryption key can be a hash of the corresponding private key. This will be discussed further below. Alternatively, an asymmetric encryption scheme (e.g., ECIES) can be used, where different keys are required to decrypt the data. For example, the encryption key can be a private key and the decryption key can be a corresponding decryption key.

[0143] The encryption key may belong to a hierarchical key structure, or be generated from a key belonging to a hierarchical key structure (e.g., by hashing), such as similar to reference Figure 5 and Figure 6 Describes the keys. Each encryption key can be derived from the public key of the key structure. For example, each encryption can be a child private key of the same parent private key. Figure 6 This is shown schematically, where multiple child encryption keys are derived from a parent key, which is ultimately derived from an encryption seed 601E.

[0144] In some embodiments, the cryptographic service 701 generates a blockchain transaction including an encrypted payload (i.e., a final encrypted value). The cryptographic service 701 sends the blockchain transaction to the blockchain network 106 to store it 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. For ease of reference, the transaction may be labeled as a target data storage transaction.

[0145] In these embodiments, the target data storage transaction may be an overlay network 300 (eg, reference Figures 3 to 6 The target data storage transaction may be a data storage transaction of the overlay network described in the embodiment of the present invention. That is, the target data storage transaction may be a node of the overlay network 300. For example, the target data storage transaction may be a Metanet transaction of a node forming the Metanet. Therefore, the target data storage transaction includes a signature corresponding to a parent public key assigned to a parent node of the Metanet.

[0146] In some examples, the data set may include 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 storage transaction. The public key of the node uniquely identifies the target data storage 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 storage transaction. The transaction identifier of the parent transaction represents a link between a (child) target node corresponding to the (child) target data storage transaction and a parent node corresponding to the parent data storage transaction. Figure 8 An example is shown where the final data item (appearing in the first position in the data array) includes 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.

[0147] Previously, as mentioned above Figure 4 As discussed, only user data stored in Metanet transactions is encrypted (without using the encapsulation encryption scheme described herein). However, this means that the structural information included in the Metanet transaction is immutably available on-chain and allows the structure of the Metanet tree to be identified. Even if the user data itself is inaccessible due to the encryption, in some examples, identifying and determining the structure of the Metanet tree can enable a third party to determine or at least infer the properties of the user data. For example, if a third party knows that a Metanet node is associated with a user's medical prescription, the third party can associate the frequency of Metanet transactions / nodes with the number of prescriptions, thereby inferring the corresponding medication or treatment. Now, by encrypting the structural information, it is not even possible to determine the structure of the Metanet tree to which the target data storage node belongs. This improves the privacy of the underlying user data. In some examples, the target transaction includes a Metanet flag. However, this only allows a third party to determine that the transaction is a Metanet transaction. This does not allow a third party to determine the tree structure. Fig.10 An example of a Metanet transaction including an encrypted payload is shown. In this example, only the Metanet flag that identifies the transaction as a Metanet transaction can be seen.

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

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

[0150] Reference was made above to the sensitivity of data items. In some examples, different data items may have different levels of sensitivity, importance, confidentiality, etc. In other words, the impact of certain data being revealed may differ between data items. For example, a third party may gain less information by obtaining a user's zip code than by obtaining the first line of the user's address. Similarly, a third party may gain less information by obtaining a user's favorite sports team than by obtaining the user's passport information. Therefore, it may be critical to apply more encryption layers and protect more sensitive, important, etc. data items. This increases the privacy of these data items. In the examples, the data items are sorted by sensitivity level, with the most sensitive data items being encrypted with the most encryption layers and the least sensitive data items being encrypted with the fewest encryption layers. Fig. 9 An exemplary data set is shown where the user's email address (most sensitive) is the first data item to be encrypted and the structural information (least sensitive) is the last data item to be encrypted. Fig. 9 In the example of , the first two data items are encrypted by data provider 702 using the associated encryption values ​​provided to encryption service 701. Encryption service 701 then applies a final layer of encryption by encrypting the third data item together with the received encryption value.

[0151] 7. Further comments

[0152] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

[0153] For example, some of the embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above can be replaced with reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes can share some or all of the characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 described above.

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

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

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

[0157] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments any type of suitable consensus mechanism may be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has a chance to produce the next block 151. The selected node is often referred to as a verifier. A blockchain node may lock its token for a period of time in order to have a chance to become a verifier. Typically, the node that has locked the largest stake for the longest time is most likely to become the next verifier.

[0158] For example, the example above states that the overlay link is defined in the payload of the Metanet transaction (e.g., via Figure 4 In the example of TxIDnode in the output of TxIDparent). 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, one might provide a variant of the Metanet where certain data structures are stored on the blockchain, but the overlay links might be stored off-chain. The key hierarchy that signs the inputs to the data storage transaction would still be sufficient to recover (most of) the data structure, but would be limited to people who know the seed (i.e., not the general public viewing the blockchain), so privacy would be improved. In a further variant, the graph structure of the Metanet (or other such overlay network) could be defined entirely off-chain, with only the data content stored on-chain.

[0159] Furthermore, although a tree structure has been described above, more generally, the same principles apply to any graph structure. For example, a given node 301 may have two parent nodes. In this case, a corresponding key will be derived from the two parent keys.

[0160] It should be understood that the above embodiments are described by way of example only. In more general terms, a method, apparatus or program may be provided according to any one or more of the following statements.

[0161] Statement 1. A computer-implemented method of encrypting data, wherein the method is performed by an encryption service and comprises:

[0162] Generate an encrypted payload representing a data set, the 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:

[0163] a) encrypting the first data item using a first corresponding encryption key to generate a first encrypted value;

[0164] b) combining a second data item with the first encrypted value to generate a first combined value;

[0165] c) encrypting the first combined value using a second corresponding encryption key to generate a second encrypted value; and,

[0166] d) repeating the following process: i) combining the corresponding next data item with the corresponding latest encrypted value to generate a corresponding next combined value, and ii) encrypting the corresponding next combined value using the next corresponding encryption key to generate the corresponding next encrypted value, until the combination of the final data item and the corresponding latest encrypted value has been encrypted using the next corresponding encryption key to generate a final encrypted value, and the encrypted payload includes the final encrypted value.

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

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

[0169] Statement 4. A method according to any one of statements 1 to 3, wherein generating the encrypted payload by the encryption service includes: executing each encryption step.

[0170] Statement 5. The method of any one of statements 1 to 3, wherein said generating, by said encryption service, said encrypted payload comprises: performing at least one but not all encryption steps, wherein at least one encryption step is performed by a data provider, and wherein said method comprises:

[0171] From the data provider, a corresponding encrypted value generated as a result of the at least one encryption step performed via the data provider is received.

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

[0173] Statement 7. The method of statement 5 or 6, wherein all but one of the encryption steps are performed by the data provider, and wherein the method comprises:

[0174] From the data provider, corresponding encrypted values ​​generated as a result of all but one encryption step performed via the data provider are received.

[0175] Statement 8. A method according to any one of statements 1 to 5, wherein one, some or all of the corresponding data items in the set of data items are corresponding encrypted data items.

[0176] Statement 9. A method as described in any of the preceding statements, wherein each encryption step utilizes a symmetric encryption scheme.

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

[0178] Statement 11. A method as described in any of the preceding statements, wherein each respective encryption key is generated by hashing a respective private key.

[0179] Statement 12. The method of statement 11, comprising:

[0180] A hierarchical key structure is maintained, the hierarchical key structure comprising layers of corresponding private keys, each of which is derivable from a common seed value, and wherein each corresponding encryption key is a corresponding child private key of the same parent private key.

[0181] Statement 13. A method according to any of the preceding statements, comprising:

[0182] storing the encrypted payload in a target data storage transaction; and,

[0183] The target transaction is submitted to the blockchain network to be stored on the blockchain.

[0184] Statement 14. A method according to any of the preceding statements, wherein an overlay network is overlaid on the data storage transaction of the blockchain, thereby storing the data content of the overlay network in the data storage transaction, and defining overlay network links between the data storage transactions; wherein a graph structure (graph structure, also translated as a graph structure) of the overlay network includes a plurality of nodes and edges between nodes, wherein each of the nodes corresponds to a different corresponding data storage transaction in the data storage transaction, and each of the edges corresponds to a different corresponding link in the links, wherein each node is associated with a corresponding signature key, and the corresponding signature key is used to sign the input of the sub-data storage transaction of the overlay network so as to authorize the sub-data storage transaction to be written to the blockchain, and wherein the target data storage transaction is the corresponding sub-data storage transaction of the graph structure.

[0185] Statement 15. The method of statement 14, wherein the corresponding data item of the data set includes structural information, the structural information identifying the corresponding node corresponding to the target data storage transaction in the graph structure.

[0186] Statement 16. A method according to statement 15, wherein the structural information includes a transaction identifier of a parent data storage transaction of the target data storage transaction and / or a public key assigned to the corresponding node corresponding to the target data storage transaction.

[0187] Statement 17. A method according to any preceding statement, comprising:

[0188] One or more of the corresponding encryption keys are sent to a data accessor to selectively reveal one or more of the corresponding data items to the data accessor.

[0189] Statement 18. The method of statements 16 and 17, wherein the one or more of the corresponding encryption keys include a corresponding encryption key for encrypting the structure information.

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

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

[0192] Statement 21. A computer device, the computer device comprising:

[0193] a memory, the memory comprising one or more memory cells; and,

[0194] A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to execute a method according to any one of statements 1 to 20 when executed on the processing device.

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

[0196] According to another aspect disclosed herein, a method may be provided, the method comprising actions of the encryption service and the data provider.

[0197] According to another aspect disclosed herein, a system may be provided, the system comprising the encryption service and a computer device of the data provider.< / data> < / data> < / pa>

Claims

1. A computer-implemented method of encrypting data, wherein the method is performed by an encryption service and comprises: Generate an encrypted payload representing a data set, the 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 using a first corresponding 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 using a second corresponding encryption key to generate a second encrypted value; and d) repeating the following process: i) combining the corresponding next data item with the corresponding latest encrypted value to generate a corresponding next combined value, and ii) encrypting the corresponding next combined value using the next corresponding encryption key to generate the corresponding next encrypted value, until the combination of the final data item and the corresponding latest encrypted value has been encrypted using the next corresponding encryption key to generate a final encrypted value, and the encrypted payload includes the final encrypted value.

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 the corresponding encryption keys are the same encryption key.

4. The method according to any one of claims 1 to 3, wherein generating the encrypted payload by the encryption service comprises: Execute each encryption step.

5. The method according to any one of claims 1 to 3, wherein generating the encrypted payload by the encryption service comprises: performing at least one but not all encryption steps, wherein at least one encryption step is performed by a data provider, and wherein the method comprises: From the data provider, a corresponding encrypted value generated as a result of the at least one encryption step performed via the data provider is received.

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

7. A method according to claim 5 or 6, wherein all but one of the encryption steps are performed by the data provider, and wherein the method comprises: From the data provider, corresponding encrypted values ​​generated as a result of all but one encryption step performed via the data provider are received.

8. A method according to any one of claims 1 to 5, wherein one, some or all of the corresponding data items in the set of data items are corresponding encrypted data items.

9. A method according to any preceding claim, wherein each encryption step utilizes a symmetric encryption scheme.

10. A method according to any preceding claim, wherein each data item is associated with a respective sensitivity, and wherein the first data item is associated with the highest sensitivity.

11. A method according to any preceding claim, wherein each respective encryption key is generated by hashing a respective private key.

12. The method according to claim 11, comprising: A hierarchical key structure is maintained, the hierarchical key structure comprising layers of corresponding private keys, each of which is derivable from a common seed value, and wherein each corresponding encryption key is a corresponding child private key of the same parent private key.

13. A method according to any preceding claim, comprising: storing the encrypted payload in a target data storage transaction; as well as The target transaction is submitted to the blockchain network to be stored on the blockchain.

14. A method according to any of the preceding claims, wherein an overlay network is overlaid on the data storage transaction of the blockchain, thereby storing the data content of the overlay network in the data storage transaction, and defining overlay network links between the data storage transactions; wherein the graph structure of the overlay network includes a plurality of nodes and edges between the nodes, wherein each of the nodes corresponds to a different corresponding data storage transaction in the data storage transaction, and each of the edges corresponds to a different corresponding link in the links, wherein each node is associated with a corresponding signature key, and the corresponding signature key is used to sign the input of the sub-data storage transaction of the overlay network so as to authorize the sub-data storage transaction to be written to the blockchain, and wherein the target data storage transaction is the corresponding sub-data storage transaction of the graph structure.

15. The method of claim 14, wherein the corresponding data item of the data set includes structural information identifying a corresponding node corresponding to the target data storage transaction in the graph structure. 16 . The method according to 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 the corresponding node corresponding to the target data storage transaction.

17. A method according to any preceding claim, comprising: One or more of the corresponding encryption keys are sent to a data accessor to selectively reveal one or more of the corresponding data items to the data accessor.

18. The method according to claims 16 and 17, wherein the one or more of the corresponding encryption keys include a corresponding encryption key used to encrypt the structure information.

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

20. A method according to any preceding claim, wherein each step of combining a respective data item with a respective encrypted value comprises: The corresponding data item is concatenated with the corresponding encrypted value.

21. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device, comprising one or more processing units, wherein the memory stores a code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 20 when executed on the processing device.

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

Images