How it is performed by computing devices

Abstract

A method performed by a node in a blockchain network, comprising the steps of: sending a data distribution control message to a node in the blockchain network, wherein the data distribution control message indicates that data in a transaction among multiple transactions should not be distributed by the node, and the data is stored by the node and associated with the blockchain; receiving a zero-knowledge proof from the node that proves the deletion of data from a transaction in accordance with the data distribution control message; generating a record transaction, wherein the record transaction includes proof of the deletion of data from a transaction in accordance with the data distribution control message; and sending the record transaction to the node for commit to the blockchain.

Description

[Technical Field]

[0001] This disclosure relates to a method performed by a computing device. [Background technology]

[0002] Blockchains are designed to be immutable, meaning that data embedded in them cannot be altered. This characteristic makes the removal of unwanted data extremely difficult. When data is removed from a blockchain transaction, the remaining transaction data becomes unverifiable. This is because, due to the missing data, even obtaining a double hash of the serialized transaction data does not allow for the reconstruction of the transaction ID. Furthermore, it is impossible to prove the existence of a transaction within a block using Merkle proofs, nor to prove the existence of a block header within the blockchain using Proof of Work (PoW). This poses a challenge for node operators and other blockchain service providers who need to distribute unwanted data as part of blockchain maintenance, given that such unwanted data may be illegal. [Overview of the project]

[0003] According to one aspect disclosed herein, a method is provided that is performed by a computing device, the method comprising: sending a data distribution control message to a node of a blockchain network, the data distribution control message indicating that data in a transaction of a plurality of transactions should not be distributed by the node, the data is stored by the node and associated with the blockchain; receiving from the node a zero-knowledge proof that the data has been removed from the transaction in accordance with the data distribution control message; generating a record transaction, the record transaction including proof of the removal of data from the transaction in accordance with the data distribution control message; and sending the record transaction to the node for commit to the blockchain.

[0004] In another aspect disclosed herein, a computer-readable medium is provided for storing processor-executable instructions, the processor-executable instructions including instructions that, when executed by one or more processors, cause one or more processors to perform any of the methods described herein. The computer-readable medium may be a non-temporary medium.

[0005] According to another aspect disclosed herein, a computer program is provided which, when executed by a computing device, includes instructions causing the computing device to perform one of the methods described herein.

[0006] Instructions may be provided on one or more carriers. These may include one or more non-temporary memories, such as programmed memory including EEPROM (e.g., flash memory), disk, CD-ROM, or DVD-ROM, read-only memory (e.g., for firmware), one or more temporary memories (e.g., RAM), and / or data carriers (may be multiple) such as optical signal carriers or electrical signal carriers. These memories may be integrated into the corresponding processing chip or may be separate from the chip. Code (and / or data) for carrying out embodiments of the disclosure may include source code, object code, or executable code written in a conventional programming language such as C (interpreted or compiled), or assembly code, code for setting up or controlling an ASIC (Application-Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array), or code for a hardware description language.

[0007] A computing device is provided according to another aspect disclosed herein. This computing device comprises one or more processors, memory, and computer executable instructions stored in the memory, which, when executed by one or more processors, cause the processors to perform any of the methods described herein.

[0008] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments are carried out, the accompanying drawings are provided for illustrative purposes. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates some examples of transactions that can be recorded on a blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] FIG. 3A is a schematic mock-up diagram of an exemplary user interface that can be presented by a client application. [Figure 4] FIG. 4 is a schematic block diagram of node software for processing transactions. [Figure 5] FIG. 5 is an example of a transaction that includes unnecessary data in a consumable output of the transaction. [Figure 6] FIG. 6 is an example of a transaction that includes unnecessary data in a non-consumable output of the transaction. [Figure 7a] FIG. 7 is a schematic block diagram of a blockchain node. [Figure 7b] FIG. 8 is a schematic block diagram of a data distribution control device. [Figure 8] FIG. 9 is a sequence diagram showing steps executed in accordance with an embodiment of the present disclosure. [Figure 9] FIG. 10 is a diagram showing an example of a transaction that includes unnecessary data in a consumable output of the transaction and two recorded transactions. DETAILED DESCRIPTION OF THE INVENTION

[0010] 1. Example of System Overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

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

[0012] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

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

[0014] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0015] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0016] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0017] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0018] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0019] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0020] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0021] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0022] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0023] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

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

[0025] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

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

[0027] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0028] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0029] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

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

[0031] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0032] 2. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

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

[0034] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0035] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0036] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

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

[0038] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0039] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0040] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0041] Typically, the input to a transaction is the public key P. A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0042] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0043] 3. Client Software Figure 3A shows an example implementation of a client application 105 for implementing an embodiment of the method of the present disclosure. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement transaction-related functions of the client 105, such as creating transaction 152, receiving and / or sending transactions and other data via side channels 301, and / or sending transactions to one or more nodes 104 propagated via the blockchain network 106, in accordance with the method described above and a scheme to be described in more detail later.

[0044] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of each user's computer equipment 102, and includes outputting information to each user 103 via user output means of equipment 102, and receiving input from each user 103 via user input means of equipment 102. For example, user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output. User input means may include, for example, an input array of one or more touchscreens (same or different as those used for output means); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and voice or speech recognition algorithms for receiving audio or voice input; one or more gesture-based input devices for receiving input in the form of manual or body gestures; or one or more mechanical buttons, switches, joysticks, etc.

[0045] Note: While this specification describes various functions as being integrated into a single client application 105, this is not necessarily limiting, and they could be implemented as a suite of two or more different applications, for example, one as a plug-in to the other, or interfaced via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a particular module, such as the transaction engine 401, may be divided among multiple applications. Furthermore, it is not excluded that some or all of the functions described herein may be implemented, for example, in the operating system layer. Where a single or specific application 105, etc., is referred to herein, this is merely illustrative, and more generally, it should be understood that the functions described herein can be implemented in any form of software.

[0046] Figure 3B shows a mockup of UI 500 that can be rendered by the UI (User Interface) layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI can be rendered by client 105b on Bob's device 102b, or by any other client.

[0047] Figure 3B shows UI500 as an example from Alice's perspective. UI500 may consist of one or more UI elements 501, 502, 502 which are rendered as individual UI elements by a user output means.

[0048] For example, a UI element may include one or more user-selectable elements 501, such as different buttons on the screen or different options in a menu. User input means are configured to allow user 103 (in this case, Alice 103a) to select or act on one of the options by clicking or touching a UI element on the screen or by speaking the name of the desired option (the term "manual" as used herein is in contrast to "automatic" and is not necessarily limited to the use of hands). These options allow the user (Alice) to create a transaction 152 and send it to one or more nodes 104 for propagation through the blockchain network 106.

[0049] Alternatively or additionally, a UI element may include one or more data input fields 502 for user use. These data input fields may be rendered via user output means (e.g., on a screen), and data may be entered into the fields via user input means (e.g., a keyboard or touchscreen). Alternatively, data may be received verbally, for example, based on speech recognition.

[0050] Alternatively or additionally, a UI element may include one or more information element outputs to provide information to the user. For example, this information may be displayed on screen or audibly.

[0051] Please understand that the specific methods for rendering various UI elements, selecting options, and inputting data are not important. The functions of these UI elements will be explained in detail later. Also, UI500 shown in Figure 3 is a schematic mockup and may actually contain one or more UI elements, but these are not shown for the sake of simplicity.

[0052] 4. Node Software Figure 4 shows an example of node software 450 that runs on each blockchain node 104 of network 106 in an example of a UTXO-based or output-based model. Note that another entity may run node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required as a node 104. Node software 450 can include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision-making engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 can run node software that includes one or more of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The consensus module 455C can include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module may be configured separately from the consensus module 455C. One or more modules may operate in parallel. Node 104 can include additional modules. The protocol engine 401 is typically configured to recognize different fields of transaction 152 and process them according to the node protocol. When receiving a transaction 152j (Tx m-1 ) having an input that refers to an output (e.g., UTXO) of another previous transaction 152i (Tx j ), the protocol engine 451 identifies the unlock script within Tx j and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Tx j based on the pointer within the input of Tx i . Tx i [[ID= 12]] may be published on the blockchain 150, in which case the protocol engine retrieves Tx i from a copy of block 151 of blockchain 150 stored at node 104.You can obtain it. Alternatively, Tx i It is possible that the transaction has not yet been published to blockchain 150. In that case, the protocol engine 451 will take the transaction from the ordered set of unpublished transactions 154 managed by node 104. i It is possible to obtain the Tx. In either case, the protocol engine 451 will obtain the referenced Tx i Identify the lock script from the output and pass it to script engine 452.

[0053] In this way, script engine 452, Tx i The lock script and the corresponding Tx j The unlock script is obtained from the input. For example, Figure 2 shows transactions labeled Tx0 and Tx1, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together as described above, which involves placing data on the stack 453 and retrieving data from the stack 453, according to the stack-based scripting language being used (e.g., Script).

[0054] The script engine 452 executes these scripts simultaneously to determine whether the unlock script meets one or more criteria defined in the lock script; that is, whether to "unlock" the output containing the lock script. The script engine 452 returns this determination result to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns a result of "true". Otherwise, it returns a result of "false".

[0055] In an output-based model, the output "true" from script engine 452 is one of the conditions for transaction validity. Typically, one or more protocol-level conditions, evaluated by protocol engine 451, must also be met. For example, Tx j The total value of the digital assets specified in the output does not exceed the total value indicated by its input, and Tx i This includes ensuring that the output has not already been consumed by another valid transaction. The protocol engine 451 evaluates the output from the script engine 452 and one or more protocol-level conditions, and only if they are all true does transaction Tx proceed. j The protocol engine 451 outputs an instruction to the application-level decision engine 454 indicating whether the transaction is valid. j Only if it is actually verified, the decision engine 454 controls both the consensus module 455C and the propagation module 455P, and Tx j Each blockchain-related function can be executed in relation to this. This means that the consensus module 455C can perform Tx j Adding the ordered transaction set 154 of each node and incorporating it into block 151, and the propagation module 455P Tx j This includes transferring the transaction to another blockchain node 104 within the network 106. Optionally, in the embodiment, an application-level decision engine 454 may apply one or more additional conditions before triggering any or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees remain.

[0056] Furthermore, the terms "true" and "false" here are not necessarily limited to returning a result represented by a single binary number (bit), but are merely one implementation example. More generally, "true" refers to any state indicating success or a positive outcome, and "false" refers to any state indicating failure or a negative outcome. For example, in an account-based model, a "true" result could be indicated by a combination of implicit protocol-level verification of the signature and a positive output from the smart contract (the overall result is considered true if both individual results are true).

[0057] 5. Delete unnecessary data As explained above, each copy of blockchain 150 is maintained at each of the multiple blockchain nodes 104 within the blockchain network 106, and each block 151 in the chain consists of one or more transactions 152.

[0058] According to embodiments described herein, blockchain node 104 receives a data distribution control message indicating that unnecessary data of transactions stored by blockchain node 104 should not be distributed by blockchain node 104. In this specification, “unnecessary data” refers to any transaction data identified in a data distribution control message sent from a data distribution control device to blockchain node 104. Unnecessary data may include, for example, text data or image data. Unnecessary data may include illegal data such as child pornography or bomb-making instructions, or data that infringes copyright.

[0059] Transactions can contain unwanted data in two different locations within the transaction. For example, unwanted data may reside in the transaction's consumable output, i.e., the unconsumed transaction output (UTXO). In particular, unwanted data may only exist in the transaction's lock script and not in metadata fields such as the Bitcoin value.

[0060] Figure 5 shows the unnecessary data present in the consuming output of transaction 500. <data>The following is an example of transaction 500, which includes ).

[0061] As shown in Figure 5, unnecessary data may be placed after the opcodes OP_CHECKSIG and OP_RETURN. In another example, unnecessary data may be placed after the opcodes OPJZHECKSIG and OP_PUSH and before the opcode OP_DROP (i.e., <pb>OPJZHECKSIGOP_PUSH <data>(OP_DROP). It will be understood that a malicious entity may use other methods to place unwanted data in the lock script for the transaction's consumable output.

[0062] In this example, we need to consider the validity of the UTXO when it is consumed in the future. Every new transaction must reference the UTXO. When a new transaction is validated, it needs to know information about the UTXO, such as its Bitcoin value and lock script. This becomes a problem if the UTXO contains unnecessary data that will be consumed by a new transaction. Validating a new transaction requires validating the UTXO, which in turn requires knowledge of the unnecessary data. If other nodes or service providers need to validate this transaction, they also need access to the unnecessary data. Because we don't know when the UTXO will be consumed, the unnecessary data could exist indefinitely within the UTXO set. The UTXO set may be made publicly available through a block explorer.

[0063] As another example, unnecessary data may reside in other parts of a transaction (i.e., unnecessary data is not included in the savable output and plays no further role in the consensus process). For example, unnecessary data may reside in the non-savable transaction output (typically characterized by the OP_FALSEOP_RETURN script pattern). This is illustrated in Figure 6, which shows an example of transaction 600 containing unnecessary data in the non-savable transaction output. In this case, the unnecessary data is not included in the savable output and plays no further role in the consensus process.

[0064] As mentioned above, if OP_FALSE is placed before the OP_RETURN opcode at the beginning of the lock script, an unconsumable output of the transaction is created, which a malicious entity can use to store unnecessary data within the transaction, and as a result, it can be immutably recorded on blockchain 150.

[0065] In this alternative example, blockchain node 104 simply refuses to share parts of a transaction that contain unnecessary data. This is called pruning and is mentioned in the Bitcoin white paper as a way for nodes to reclaim disk space. Unnecessary data will not be needed in the future because it does not affect the validation of new transactions. A drawback of the pruning technique is that it cannot independently verify the integrity of other fields within a transaction.

[0066] In Figure 6, even if unnecessary data is removed from the second output, the first output may remain untapped. This is acceptable because removing data from the second output does not affect the validation of the transaction consuming the first output.

[0067] It will be understood that unnecessary data may exist in both the savable and non-savable outputs of the same transaction.

[0068] Embodiments of this disclosure relate to a mechanism that, while removing unnecessary data from a transaction by a blockchain node 104, verifies the remaining fields against a specific transaction ID and / or provides on-chain evidence of data removal in accordance with a data distribution control message.

[0069] Figure 7a shows a schematic block diagram of a blockchain node 104. The blockchain node 104 comprises a processing unit 702 which includes one or more processors (e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs)). The blockchain node 104 also comprises memory 704, i.e., computer-readable storage devices in the form of one or more non-temporary computer-readable media. Memory 704 may comprise one or more memory units using one or more storage media (e.g., magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives). Memory 704 may store node software 450. Memory 704 may store each copy of blockchain 150. The functions of the processor 702 described herein may be implemented as code (software) stored in memory (e.g., memory 704). This code is fetched from memory and executed on processor 702 to perform operations in accordance with the embodiments described herein. Blockchain node 104 also includes a communication interface for sending and receiving data to and from blockchain node 104.

[0070] Figure 7b shows a schematic block diagram of the data distribution control device 750. The data distribution control device 750 comprises a processing unit 752 which includes one or more processors (e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs)). The data distribution control device 750 also comprises a memory 754, i.e., a computer-readable storage device in the form of one or more non-temporary computer-readable media. The memory 754 may comprise one or more memory units using one or more memory media (e.g., magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives). The functions of the processor 752 described herein may be implemented by code (software) stored in memory (e.g., memory 754). The code is fetched from memory and, when executed on the processor 752, is configured to perform operations in accordance with the embodiments described herein. The data distribution control device 750 also includes a communication interface for sending and receiving data to and from the blockchain node 104.

[0071] The data distribution control device 750 is connected to the packet-switched network 101. The data distribution control device 750 can communicate with the blockchain node 104 even when it is outside the blockchain network 106.

[0072] Embodiments of this disclosure will be described with reference to the sequence diagram shown in Figure 8.

[0073] In step S802, blockchain node 104 receives a data distribution control message indicating that the transaction (Tx) data stored in the memory of blockchain node 104 should not be distributed by blockchain node 104 to anyone (including other blockchain nodes). Specifically, the data distribution control message identifies a particular transaction by one or more unique identifiers associated with the transaction (e.g., transaction ID). Furthermore, the data distribution control message specifies which data within the transaction is unwanted by one or more identifiers of the unwanted data stored in the transaction. It will be understood that this can be achieved in various ways. For example, the data distribution control message may include an identifier of a particular output of the transaction (e.g., index number), indicating, for example, that all data contained in the second output of the transaction is unwanted data. Additionally or alternatively, the data distribution control message may include one or more bit identifiers to identify the bit positions corresponding to the unwanted data within the transaction. For example, it may indicate that data at bit positions 2000-3000 is unwanted data. The data distribution control message is sent from the data distribution control device 750 to blockchain node 104.

[0074] In response to receiving a data distribution control message, in step S804, the blockchain node 104 is configured to obtain a zero-knowledge proof (ZKP) to prove that unnecessary data has been removed from the transaction.

[0075] In some implementations, blockchain node 104 may obtain a ZKP by generating it itself. A ZKP may be generated using (i) a transaction referenced in a data distribution control message, (ii) one or more identifiers of unwanted data stored in the transaction (one or more identifiers included in the data distribution control message), and (iii) public parameters.

[0076] In other implementations, blockchain node 104 may not generate ZKPs itself, but instead receive them from a remote computing device.

[0077] Blockchain node 104 can receive a ZKP from a remote computing device in response to sending the remote computing device (i) a transaction referenced in a data distribution control message, and (ii) an identifier for one or more unwanted data stored in the transaction. In these examples, the remote computing device may be located outside the blockchain network 106; that is, the remote computing device may not be blockchain node 104. Alternatively, the remote computing device may be another blockchain node 104.

[0078] Although Figure 8 shows a single blockchain node 104 for simplification, the data distribution control device 750 can send data distribution control messages to multiple blockchain nodes 104 within the blockchain network 106. Thus, the blockchain node 104 shown in Figure 8 can receive a data distribution control message and, accordingly, receive a ZKP from another blockchain node that has generated a ZKP. In these examples, it will be understood that the blockchain node 104 shown in Figure 8 does not need to send (i) the transaction referenced in the data distribution control message, and (ii) one or more identifiers of unnecessary data stored in the transaction to the ZKP generating blockchain node.

[0079] It is clear that a ZKP can be built by blockchain nodes, blockchain service providers, or other entities that have access to data that is not necessary. A blockchain service provider as defined herein refers to an entity that provides blockchain data but does not generate blocks. For example, a blockchain service provider may be an entity that provides a block explorer, such as WhatsOnChain, and provides blockchain data on demand. Alternatively, a blockchain service provider may be an entity that provides a platform that receives data from users, incorporates it into transactions, pays fees, transmits transactions to the blockchain network, and provides users with proof of data registration on the blockchain.

[0080] A zero-knowledge proof (ZKP) is a method by which one party, called the prover, proves to another party, called the verifyer, that a statement is true, without revealing any information other than the fact that the statement is true. In embodiments of this disclosure, a ZKP is generated to prove that unwanted data, specified in a data distribution control message, has been removed from a particular transaction (also specified in a data distribution control message). That is, the term “zero-knowledge proof” as used herein means a proof of knowledge between the prover and the verifyer in which no information about the unwanted data is revealed.

[0081] Embodiments of this disclosure are not limited to any particular type of ZKP. The ZKP obtained in step S804 may be a type of interactive zero-knowledge proof (requiring interaction between the prover and the verifier). Alternatively, the ZKP obtained in step S804 may be a type of non-interactive zero-knowledge proof (NIZK). In this case, the prover generates only one message called a “proof” to convince the verifier that the statement is true (i.e., unnecessary data has been removed from the transaction).

[0082] zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is an example of a NIZK proof that is concise, has a very short proof, and is easy to verify. The statement is represented by an arithmetic circuit used to generate the proof of the statement.

[0083] In the example where ZKP is a zkSNARK proof, the public parameters correspond to the proof key (part of the prover-verification key pair computed during the setup phase).

[0084] As is well known to those skilled in the art, proof keys and verification keys work within the context of zkSNARK, but not with other types of zero-knowledge proofs such as MPC-based proofs (e.g., zkBOO), STARK, and BUIletproofs. However, all types of zero-knowledge proofs use some public parameters to generate the proof, and the form of these public parameters depends on the type of zero-knowledge proof employed.

[0085] In response to receiving a data distribution control message, in step S806, blockchain node 104 is configured to remove unnecessary data from transaction (Tx) according to the data distribution control message and generate a modified transaction (Tx'). The modified transaction (Tx') corresponds to the original transaction (Tx) from which the unnecessary data has been removed. It will be understood that knowledge of the unnecessary data is necessary to generate the ZKP. The transaction ID of transaction (Tx) is not changed; that is, the transaction ID of transaction (Tx) is the same as that of the modified transaction (Tx'). The ZKP is used to associate the incomplete transaction data in the modified transaction (Tx') with the transaction ID. In particular, since the ZKP includes the transaction ID as a fixed public parameter, the transaction ID can be considered data that is explicitly included as part of the ZKP. When a verifier verifies the ZKP, the verification process takes the ZKP and the modified transaction (Tx') (and the verification key in the context of zkSNARK) as input and outputs a "true" or "false" determination (e.g., bit 1 or 0). The output will be "true" if the correct edited transaction corresponding to a specific TxID is provided as input to the ZKP.

[0086] ZKP proves that only unnecessary data has been removed from a transaction and that no blockchain node has deleted or tampered with the transaction in any other way. Specifically, ZKP proves that unnecessary data has been "completely removed" from a particular transaction. That is, if a transaction consists of data {X||Y} and Y is completely removed, what remains is {X||.}. This means that X has not been tampered with. If Y is not completely removed, what remains is {Z||.}, which does not match the starting data.

[0087] It is crucial that the data associated with the value of Bitcoin and its public key is not removed from transactions, as this allows us to identify who uploaded unwanted data and which Bitcoins were used for that purpose. This also makes it possible to recover Bitcoin in a transparent manner.

[0088] This is especially true when unnecessary data exists within a UTXO, and many different entities may be interested in that data. For example, the sender or receiver of a transaction using the UTXO containing the data, and the nodes or blockchain service providers involved in processing that transaction. One of these entities may want to prove to other entities that it complied with the data distribution control message. A blockchain node or blockchain service provider may want to prove that it removed a particular part of a transaction, even if that part no longer exists within the UTXO.

[0089] In some implementations, blockchain node 104 retains unnecessary data in memory 704 even after deleting unnecessary data from a transaction. In other implementations, blockchain node 104 does not retain unnecessary data in memory 704 after deleting unnecessary data from a transaction.

[0090] In step S808, the blockchain node 104 is configured to send a ZKP to the data distribution control device 750. The ZKP provides the data distribution control device 750 with proof that the blockchain node 104 has followed the data distribution control message. The data distribution control device 750 receives the ZKP sent from the blockchain node 104.

[0091] By verifying the ZKP, the data distribution control device 750 can explicitly confirm that the proof relates to the correct portion of the transaction identified in the data distribution control message. The techniques for verifying the ZKP (those that produce valid or invalid outputs) are known to those skilled in the art and will not be described in detail here. As an example, if the ZKP is a zkSNARK, the data distribution control device 750 (or other verification device) requires the verification key (corresponding to the aforementioned proof key), all the data of the transaction (that held the unnecessary data) excluding the unnecessary data itself, and the ZKP.

[0092] In step S810, blockchain node 104 may receive a request for a transaction (Tx) identified in a data distribution control message. This request is sent from a requesting computing device 800. The requesting computing device 800 is, for example, a user's computer equipment 102. Alternatively, the requesting computing device 800 may be blockchain node 104, for example, when a new miner joins the blockchain network, the miner needs to download the entire blockchain, verify all transactions, and build a UTXO set. The request received in step S810 may be sent from the requesting computing device 800 as part of the process of downloading the entire blockchain, verifying all transactions, and building a UTXO set.

[0093] In response to receiving the request in step S810, in step S812, the blockchain node 104 sends the modified transaction (Tx') and a ZKP to the requesting computing device 800. Since the modified transaction (Tx') does not contain any unnecessary data, the transmission in step S812 conforms to the data distribution control message. The ZKP used in the embodiments of this disclosure certifies that the edited transaction data is correct for a specific transaction ID. In particular, the ZKP sent in step S812 certifies to the requesting computing device 800 that the edited transaction data within the modified transaction (Tx') is correct for the transaction ID of the modified transaction (Tx'). The ZKP enables verification of data that is not unnecessary (the remaining data in the modified transaction following step S806), providing transparency and auditability. This is especially useful when unnecessary data is present in the UTXO, as there may be many stakeholders affected by the data distribution control message.

[0094] In step S812, the blockchain node 104 can further send a data distribution control message to the requesting computing device 800.

[0095] When blockchain node 104 obtains a ZKP in step S804, it can send the ZKP to one or more other blockchain nodes 104 within the blockchain network 106. Since a ZKP does not require trust in its creator, once created, it can be reused by other devices, such as other blockchain nodes 104 within the blockchain network 106. This has the advantage of minimizing the processing overhead of the blockchain network, as each blockchain node 104 within the blockchain network 106 does not need to generate a ZKP, which can be computationally expensive.

[0096] The above example provided a simple illustration of a data distribution control message identifying a single transaction containing unwanted data. However, it will be understood that a data distribution control message may also identify unwanted data from multiple transactions stored in the memory of blockchain node 104 that should not be distributed by blockchain node 104. In these examples, blockchain node 104 performs steps S804, S806, and S808 for each transaction identified by the data distribution control message. That is, a ZKP is obtained for each transaction stored by blockchain node 104 that contains unwanted data identified by the data distribution control message. Each ZKP is constructed for a specific transaction ID (TxID), which is data explicitly recorded as part of the respective ZKP.

[0097] In response to receiving a ZKP in step S808, if unnecessary data is present in the transaction's savable output, the data distribution control device 750 may be configured to generate a recorded transaction in step S814 to provide evidence that data has been removed from the transaction in accordance with the data distribution control message.

[0098] Evidence may include a ZKP or a commitment to a ZKP. A commitment to a ZKP may be, for example, a hash of a ZKP or a Pedersen commitment. In addition, or alternatively, evidence may include a data distribution control message or a commitment to a data distribution control message. A commitment to a data distribution control message may be, for example, a hash of a data distribution control message or a Pedersen commitment. Evidence may also include metadata associated with the deletion of data from a transaction. This specification refers to examples of commitments that may be used in embodiments of this disclosure, such as hashes and Pedersen commitments. These are examples, and it will be understood that evidence of data deletion may include other types of commitments.

[0099] At least some of the evidence may be stored in the input of a recording transaction. Specifically, one or more of the following may be stored in the input of a recording transaction: (i) a ZKP or ZKP commitment, (ii) a data distribution control message or a data distribution control message commitment, and (iii) metadata.

[0100] Figure 9 shows TXID m This example shows a recording transaction 900 that provides both a ZKP and a data distribution control message as input to recording transaction 950, which has a transaction ID.

[0101] The input to the example recording transaction 900, identified by index 0, includes a pointer to transaction 500 (for example, by transaction ID, TxlDn, and in an embodiment, the hash of the entire transaction 500). The input to the example recording transaction 900 also includes an index that identifies the UTXOO (a record of data to be deleted before removal) within transaction 500, identifying the UTXOO from other possible outputs of transaction 500. As shown in Figure 9, the input to the example recording transaction 900, identified by index 0, also includes both the ZKP and data distribution control messages in the unlock script (this implicitly links the evidence that data to be deleted from transaction 500 to the UTXOO (a record of data to be deleted before removal) of transaction 500). These are items that are pushed onto the stack and then dropped (i.e., OP_PUSH). <zkp>Since it can be included in the unlock script as OP_DROP, it does not affect the execution of the script.

[0102] In the example recording transaction 900, both the ZKP and the data distribution control message are shown within the unlock script, but if both are present, they do not need to be in the same place within recording transaction 900, and as explained above, recording transaction 900 may not contain both the ZKP and the data distribution control message.

[0103] At least a portion of the evidence may be stored in the output of the recording transaction. Specifically, one or more of the following may be stored in the output of the recording transaction: (i) a ZKP or ZKP commitment, (ii) a data distribution control message or a data distribution control message commitment, and (iii) metadata. The output storing the portion of the evidence may be a consumable or non-consumable output.

[0104] Figure 9 further shows an example of recorded transaction 950, where both the ZKP and the data distribution control message have a transaction ID of TXID. m This is provided to the unavailable output of recorded transaction 950.

[0105] The input to the example recording transaction 950, identified by index 0, includes a pointer to transaction 500 (for example, transaction IDTxlDn), which in an embodiment is a hash of the entire transaction 500. The input to the example recording transaction 950 also includes an index that identifies UTX00 (which contained unnecessary data before deletion) within transaction 500, so that it can be identified among other possible outputs of transaction 500.

[0106] As shown in Figure 9, recording transaction 950 includes both the ZKP and the data distribution control message in the lock script of the unavailable output. However, as mentioned above, at least some of the evidence may be stored in the consumable output of the recording transaction (for example, <P C > OP_CHECKSIG OP_RETURN <zkp> <ddcm>If the output of recording transaction 950 provides evidence (e.g., ZKP and / or data distribution control messages) that unnecessary data has been removed from transaction 500, recording transaction 950 will link that evidence to the specific UTXO (e.g., UTXOO of transaction 500) that contained the unnecessary data before it was removed.

[0107] One way to provide this link is to include the transaction ID (TxIDn) and output index number of transaction 500 in the output of recording transaction 950 (for example, the OP_RETURN data). The combination of TxIDn and output index number identifies the UTXO that was storing unnecessary data before deletion. In the example in Figure 9, the output index number (index 0) is used within transaction 500 to identify the UTXO that was storing unnecessary data before deletion.

[0108] If a ZKP is provided to the output of recording transaction 950, it explicitly indicates the transaction ID (TxIDn) of transaction 500 because the ZKP was generated from transaction 500. In particular, the ZKP includes TxIDn as a fixed public parameter (and therefore can be considered included as part of the ZKP). In these examples, in addition to the ZKP, it is not necessary to explicitly specify TxIDn in the output of recording transaction 950 (e.g., OP_RETURN data). In these examples, an output index number may also be provided to the output of recording transaction 950 (e.g., OP_RETURN data), and the combination of TxIDn and output index number specifies the UTXOO. In the example in Figure 9, the output index number is used to identify the UTXOO (which contained data that was no longer needed before deletion) within transaction 500.

[0109] If a data distribution control message is provided in the output of recorded transaction 950, the data distribution control message may provide a link specifying a particular UTXO that stores the unwanted data to be edited.

[0110] In the example recording transaction 950, both the ZKP and the data distribution control message are shown in the lock script, but if both are present, they do not need to coexist in recording transaction 950, and as mentioned above, recording transaction 900 may not contain both the ZKP and the data distribution control message. The metadata above may include one or any combination of the following: (i) a version number associated with code (software) that, when stored in memory 754 and fetched and executed by processor 752, performs operations in accordance with the embodiments described herein; (ii) the type / scheme of the zero-knowledge proof associated with the ZKP received in step S808; (iii) data indicating that the recording transaction contains a ZKP or a commitment to a ZKP; (iv) an identifier of the location of the ZKP in the recording transaction or a commitment to the ZKP; (v) data indicating that the recording transaction contains a data distribution control message or a commitment to a data distribution control message; (vi) an identifier of the location of the data distribution control message in the recording transaction or a commitment to a data distribution control message, and the date and time the recording transaction was generated.

[0111] In the illustrated example, the UTXOO in the output of transaction 500 consists of a lock script that requires Bob's signed PB to redeem the UTXOO (more precisely, for subsequent transactions attempting to redeem the UTXOO to become valid).

[0112] The input to recorded transactions 900,950 typically consists of an unlock script containing Bob's cryptographic signature. This signature is created when Bob applies his private key to a predefined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that Bob needs to sign to provide a valid signature is defined by the unlock script, the node protocol, or a combination of these. This message consists of the UTXOO included in the output of transaction 500, i.e., it contains unnecessary data. In one example, this message consists of the UTXOO of transaction 500 (e.g., the values ​​assigned to the first output and the first unlock script for the first output) and all the contents of recorded transactions 900,950 (excluding all the unlock scripts for the recorded transactions).

[0113] In some embodiments of this disclosure, the recorded transactions 900, 950 do not include a signature that would be expected by the UTXO lock script of transaction 500. In particular, the recorded transactions 900, 950 do not include a signature of a message containing the savable output of transaction 500 that contains unwanted data. Therefore, the parties do not need to know the unwanted data in transaction 500 in order to verify the recorded transactions 900, 950.

[0114] If the consumable output of transaction 500, which contains unnecessary data, assigns a digital asset value to one entity, then the recorded transaction may include consumable output that reassigns the value of that digital asset to another entity. This is illustrated in Figure 9, in which the public key P is in the lock script corresponding to the value of x Bitcoin. C The value of x Bitcoin is being reassigned by including (which may be associated with some authorization entity).

[0115] Once a recording transaction is generated in step S814, in step S816, the data distribution control device 750 sends the recording transaction to the blockchain node 104 and commits it to the blockchain.

[0116] The sequence diagram in Figure 8 shows that the steps are performed in a specific order, but embodiments of this disclosure are not limited to the steps in Figure 8 being performed in this specific order. For example, step S814 may be performed before step S810, or steps S814 and S816 may be performed before steps S810 and S812.

[0117] The above describes a simple example in which a data distribution control message identifies a single transaction containing unnecessary data, the data distribution control device 750 receives a single ZKP, and the data distribution control device 750 generates a single record transaction. However, this is merely one example. In embodiments in which a data distribution control message identifies multiple transactions containing unnecessary data, and the data distribution control device 750 receives multiple ZKPs, one or more record transactions are generated in step S814 to provide evidence that data has been removed from transactions in accordance with the data distribution control message. For example, a single record transaction (for example, referring to multiple ZKPs) may be generated to provide evidence that data has been removed from multiple transactions in accordance with the data distribution control message. In another example, multiple record transactions may be generated in step S814, and each record transaction may provide evidence that data has been removed from each of the multiple transactions in accordance with the data distribution control message.

[0118] Steps S814 and S816, which are performed by the data distribution control device 750, have been described, but S814 and S816 may also be performed by the blockchain node 104. In particular, when the blockchain node 104 generates a record transaction in S814, it can add the record transaction to its own mempool and send the record transaction to one or more other blockchain nodes 104 in the blockchain network 106.

[0119] Record transactions (including, for example, ZKPs) are included in the blockchain to provide on-chain evidence that data was removed from the transaction in accordance with data distribution control messages. Thus, in embodiments of this disclosure, unwanted data can be removed from a transaction, but a trace of evidence always remains (this is the immutability of the blockchain). ZKPs allow for a more detailed understanding of which data bits were removed.

[0120] The advantage of using ZKP is that it provides an independent mathematical proof of the statement. In embodiments of this disclosure, ZKP makes it possible to prove that data has been deleted without trusting blockchain nodes or service providers.

[0121] In one example, a data distribution control message might indicate that the first output of transaction Tx contains invalid data. Assume this first output is consumable and has not yet been consumed (UTXO). According to an embodiment of this disclosure, the data distribution control message notifies a blockchain node of the invalid data. One of the blockchain nodes deletes the data and creates a ZKP to prove that it has deleted this data. These nodes share the ZKP with the data distribution control device and other blockchain nodes. Because the ZKP can verify other fields in the transaction, the blockchain node can prove that a signature associated with a public key P was used to upload the invalid data. At a later date, the public key P may be used to identify an individual. The ZKP is used to prove that its public key was associated with the invalid data, and that individual may be prosecuted.

[0122] As another example, a data distribution control device issues a data distribution control message indicating that the unconsumable output of a transaction that appears deep within many blocks of the blockchain contains malicious data. A blockchain node then prunes the output containing the malicious data, creating a ZKP that certifies that the malicious data or the entire unconsumable output has been removed from the pruned transaction, in accordance with this data distribution control message. The blockchain node stores the ZKP in its own internal log file in memory and / or on the blockchain as proof of pruning. The blockchain node no longer distributes the output containing the malicious data, but if another device requests a transaction without the output, the blockchain node can share that output with the other device along with the ZKP.

[0123] Appendix Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0124] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0125] 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 described functions of creating, publishing, distributing, and storing block 151 of 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, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0126] 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 a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

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

[0128] Several embodiments describe blockchain networks that implement 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 appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0129] It will be understood that the embodiments described above are for illustrative purposes only. More generally, methods, apparatus, or programs are provided according to one or more of the following descriptions.

[0130] One aspect disclosed herein provides a method performed by a computing device, the method comprising: sending a data distribution control message to a node of a blockchain network, the data distribution control message indicating that data in a transaction of a plurality of transactions should not be distributed by the node, the data is stored by the node and associated with the blockchain; receiving a zero-knowledge proof from the node that proves the deletion of data from a transaction in accordance with the data distribution control message; generating a record transaction, the record transaction including proof of the deletion of data from a transaction in accordance with the data distribution control message; and sending the record transaction to the node for commit to the blockchain.

[0131] A data distribution control message may indicate that the data of a transaction's consumable output should not be distributed.

[0132] The evidence may include zero-knowledge proofs or commitments to zero-knowledge proofs.

[0133] The evidence may include a data distribution control message or a commitment to a data distribution control message.

[0134] At least some of the evidence may be stored in the output of the recorded transaction.

[0135] The output may be the consumable output of the recording transaction, or it may be the non-consumable output of the recording transaction.

[0136] At least a portion of the evidence may be stored in the input of the recorded transaction.

[0137] Recorded transactions may include metadata related to the deletion of data from the transaction.

[0138] The recorded transaction does not include a signature on the data containing the transaction's consumable output.

[0139] A transaction's consumable output may involve assigning the value of a digital asset to an entity, and a recording transaction may include consumable output that reallocates the value of a digital asset to a different entity.

[0140] A data distribution control message may indicate that data from multiple transactions should not be distributed by the node.

[0141] The method may further comprise the steps of: receiving a plurality of zero-knowledge proofs from a node, each zero-knowledge proof of the deletion of data from each of a plurality of transactions in accordance with a data distribution control message; generating one or more record transactions to provide evidence of the deletion of data from the plurality of transactions in accordance with the data distribution control message; and sending one or more record transactions to a node for commit to the blockchain.

[0142] Computing devices may be located outside the blockchain network.

[0143] A zero-knowledge proof can be a zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proof.

[0144] Another aspect disclosed herein provides a computer-readable medium for storing processor-executable instructions. Processor-executable instructions include instructions that, when executed by one or more processors, cause one or more processors to perform any of the methods described herein. The computer-readable medium may be a non-temporary medium.

[0145] A computing device is provided according to another aspect disclosed herein. The computing device includes one or more processors, memory, and computer executable instructions stored in the memory, which, when executed by one or more processors, cause the processors to perform any of the methods described herein. [Explanation of symbols]

[0146] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output< / ddcm> < / zkp> < / zkp> < / data> < / pb> < / data>

Claims

1. A method performed by a computing device, A step of sending a data distribution control message to a node in a blockchain network, wherein the data distribution control message indicates that data in one of a group of transactions should not be distributed by the node, and the data is stored by the node and associated with the blockchain. The steps include receiving a zero-knowledge proof from the node that proves the deletion of the data from the transaction in accordance with the data distribution control message, A step of generating a recording transaction, wherein the recording transaction includes evidence of the deletion of the data from the transaction in accordance with the data distribution control message, The steps of sending the aforementioned record transaction to the node for commit to the blockchain and A method that includes [a certain feature].

2. The method according to claim 1, wherein the evidence includes the zero-knowledge proof.

3. The method according to claim 1, wherein the evidence includes a commitment to the zero-knowledge proof.

4. The method according to any one of claims 1 to 3, wherein the evidence includes the data distribution control message.

5. The method according to any one of claims 1 to 3, wherein the evidence includes a commitment of the data distribution control message.

6. The method according to any one of claims 1 to 5, wherein at least a portion of the evidence is stored in the output of the recorded transaction.

7. The method according to claim 6, wherein the output is the consuming output of the recorded transaction.

8. The method according to claim 6, wherein the output is an unconsumable output of the recorded transaction.

9. The method according to any one of claims 1 to 8, wherein at least a portion of the evidence is stored in the input of the recorded transaction.

10. The method according to any one of claims 1 to 9, wherein the recorded transaction includes metadata relating to the deletion of the data from the transaction.

11. The method according to any one of claims 1 to 10, wherein the recorded transaction does not include signing data that includes the consumable output of the transaction.

12. The method according to any one of claims 1 to 11, wherein the consumable output of the transaction includes assigning the value of a digital asset to an entity, and the recording transaction includes consumable output of reallocating the value of the digital asset to a different entity.

13. The method according to any one of claims 1 to 12, wherein the data distribution control message indicates that data in multiple transactions among the multiple transactions should not be distributed by the node.

14. A step of receiving a plurality of zero-knowledge proofs from the node, wherein each of the plurality of zero-knowledge proofs proves the deletion of the data from each of the plurality of transactions in accordance with the data distribution control message, The steps include generating one or more record transactions to provide evidence of the deletion of the data from the plurality of transactions in accordance with the data distribution control message, The steps of sending one or more of the record transactions to the node for commit to the blockchain and The method according to claim 13, further comprising:

15. The method according to any one of claims 1 to 14, wherein the computing device is located outside the blockchain network.

16. The method according to any one of claims 1 to 15, wherein the zero-knowledge proof is a zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proof.

17. The method according to any one of claims 1 to 16, wherein the zero-knowledge proof provides proof that only the indicated data has been removed from the transaction and that the node has not removed or modified any other data in the transaction.

18. A computer-readable medium storing processor-executable instructions, wherein the processor-executable instructions include instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 17.

19. One or more processors, Memory and A computing device comprising computer executable instructions stored in the memory, A computing device that, when the computer executable instruction is executed by the one or more processors, causes the one or more processors to perform the method according to any one of claims 1 to 17.

Images