Ownership proof

Abstract

A computer-implemented method for proving ownership and / or ownership of data (m). A data commitment value is generated based on the secret value (r) and the data (m). A challenge solution ([pi]) associated with a specified verifier is generated, wherein the challenge solution ([pi]) is a zero-knowledge proof that proves that the secret value (r) is known. The data (m), the challenge solution (pi), and the data commitment value are provided to the specified verifier. The secret value (r) is not known by the specified verifier or is not provided to the specified verifier.

Description

Technical Field

[0001] The present disclosure relates to a computer-implemented method for proving ownership and / or possession of data, and a computer-implemented method for verifying ownership and / or possession of data by a designated verifier. 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. Summary of the invention

[0009] A user may wish to share data (e.g., identity data) with a verifier. A user can prove to a verifier that the data they are sharing is correct by providing a certified copy of the data. However, once the verifier has received a certified copy of the data, they can provide the data to any other third party without the user's consent.

[0010] The present disclosure relates to a method for providing data owners with control over which parties can be confident that the data is correct. That is, the data owner can control who can verify the data.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for proving ownership and / or possession of data m, the method comprising: generating a data commitment value based on a secret value r and the data m; generating a challenge solution π, the challenge solution π being associated with a designated verifier, wherein the challenge solution π is a zero-knowledge proof for proving knowledge of the secret value r; and providing the data m, the challenge solution π, and the data commitment value to the designated verifier; wherein the secret value r is not known to the designated verifier or is not made available to the designated verifier.

[0012] For example, aspects disclosed herein can be used in the following scenario. Alice (the data owner) enters a nightclub and Bob, the security guard at the door, asks her to prove that she is over 18 years old. She hands him her passport. After checking the passport, Bob asks Alice if he can make a copy of her passport in case the police come to check whether everyone in the nightclub is of age. Alice refuses because she does not want him to have (certified proof of) her personal data. Instead, she says that the police can come to her and she will easily prove that she is over 18 years old. Therefore, Alice wants to control who can be sure that she is an adult.

[0013] Using the methods described herein, Alice can prove to Bob (the designated verifier) ​​that her data has been obfuscated (committed and hashed) without providing Bob with enough information to prove this to Charlie (the third party). Alice can control the association between the data m and the obfuscation by retaining a secret random value r that she uses to commit to m. If she destroys r, the association between the obfuscation and the data is also permanently destroyed. The methods disclosed herein relate to a non-interactive zero-knowledge (nizk) proof of knowledge for proving knowledge of a private value r of the owner of the data by a designated verifier. Proving π Bob It is made specifically for Bob (the designated validator) and he cannot use π Bob To convince anyone else.

[0014] Furthermore, compared to general-purpose proof systems, the system disclosed herein does not require any trusted setup and is therefore fast and straightforward to implement.

[0015] It should be noted that although the embodiments are mainly described in terms of a party proving ownership of certain data (data owner), the embodiments can also be used to prove the right to hold certain data. In some examples, the data may not necessarily belong to the data owner, and the data owner only holds the data. That is, the right to hold the data does not necessarily mean the ownership of the data, and vice versa. In these examples, the data owner may alternatively be referred to as the data holder (possessor). It should be understood that the term "data owner" is only used as an identification label. In some examples, the data owner may both own and possess the data.

[0016] As an illustrative example, in the context of blockchain, for example, some entity (often referred to as a "wallet provider") controls private keys (i.e., data) on behalf of its users. The user owns the key, but the wallet provider holds or controls the key. As another example, Alice may be a service provider of medical records, and she wants to show the patient records to Bob, the doctor, on behalf of her patient (who authorized her to do so). Alice does not own the data, the data belongs to the patient, but Alice can still use the described embodiments to prove her ownership of the patient's data. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] 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:

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

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

[0020] Figure 3 An exemplary method for timestamping data in a private manner is shown;

[0021] Figure 4 The data transmission between the parties is schematically shown;

[0022] Figure 5a An exemplary method for notarizing data is shown;

[0023] Figure 5b An exemplary method for verifying notarized data is shown;

[0024] Figure 6 schematically illustrates notarization of data by a trusted third party; and

[0025] Figure 7 An exemplary method of registering a commitment key with a notary is shown. DETAILED DESCRIPTION

[0026] 1. Exemplary System Overview

[0027] Figure 1An 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0042] 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).

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

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

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

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

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

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

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

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

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

[0052] 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).

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

[0054] 2. UTXO-based model

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

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

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

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

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

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

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

[0062] 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:

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

[0064] 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 plaintext specify the signed partial data, as it is already present).

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

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

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

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

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

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

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

[0072] 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).

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

[0074] 3. Side Channels

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

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

[0077] 4. Zero-knowledge proof

[0078] set up is a finite group of prime order p, The exponential domain. The elements in the express, The elements in the express. The vector of n elements in is denoted by bold x. Similarly, The vector of m elements is denoted by G.

[0079] The symbol "+" is used in this article to Group operations (addition notation), also used in the field The addition operation in (modulo p addition). Scalar multiplication is represented by x·G. For practical examples, Set to elliptic curve.

[0080] 4.1 Sigma Protocol

[0081] set up is an NP relation. That is, {0, 1} * ×{0, 1} * subset of st such that it can be checked in polynomial time in the length of st And the length of w is also a polynomial in the length of st.

[0082] The first element of the tuple is called the statement, which is public information. The second element is called the witness (the witness of the statement), which is private information. There may be more than one witness for a given statement. The resulting NP language is Is a set of statements.

[0083]

[0084] The Sigma protocol is a three-round protocol between a prover and a verifier. Both parties receive a statement st as input. In addition, the prover receives a witness w as an auxiliary input, and the verifier can receive any arbitrary auxiliary input. The prover proves that he knows the witness w by providing a challenge solution π (also referred to as a public transcript in this article) to the verifier, who verifies the challenge solution π based on the protocol.

[0085] The Sigma protocol can be implemented using the following steps:

[0086] 1. The prover uses randomness a to calculate a commitment A. A is then sent to the verifier while keeping a secret.

[0087] 2. The verifier randomly samples the challenges e and sends them to the prover.

[0088] 3. The prover computes the answer z (using w and a) and sends it to the verifier.

[0089] 4. The verifier accepts whether the statement st is valid based on the public record π:=(A, e, z).

[0090] The Sigma protocol has the following characteristics.

[0091] Completeness. If Then the probability of the verifier accepting is 1.

[0092] Special soundness. For any pair of acceptance records π = (A, e, z), π' = (A, e', z') with the same commitment A (the prover's first message) and different challenges e≠e', it is possible to compute a witness w such that

[0093] Special honest verifier zero-knowledge (SHVZK). There is a polynomial time algorithm Sim that takes input When and a random e, the algorithm outputs an acceptance record π = (A, e, z) that is indistinguishable from the protocol's record.

[0094] Special soundness implies a stronger property: the Sigma protocol is also a proof of knowledge (of the witness).

[0095] Furthermore, SHVZK implies the standard notion of (honest verifier) ​​zero-knowledge, where the simulator’s task is to simulate records given only statements as input. In other words, SHVZK guarantees that no information about the witness is leaked in the exchanged messages, provided that the verifier behaves as specified.

[0096] 4.1.1 Example: Schnorr Protocol

[0097] Given two group elements Schnorr protocol proves that knowing discrete logarithms Here are the steps:

[0098] 1. Provers are randomly selected The prover sends A to the verifier.

[0099] 2. Validators randomly select challenges sample and send it to the prover.

[0100] 3. The prover calculates z:=a+ex mod p and sends it to the verifier.

[0101] 4. The verifier will accept if and only if z·G=A+e·H.

[0102] It is easy to see that the Schnorr protocol is complete and SHVZK. To understand why it has special soundness, we need to note that two acceptance records (A, e, z) and (A, e′, z′) with different challenges e≠e′ can be written as zG=A+e·H and z′.G=A+e′·H. Subtracting the second equation from the first (it should be noted that the same A is used in both equations) yields (zz′)·G=(ee′)·H. Therefore, the following conclusions can be drawn: It should be noted that since e≠e′, ee′ is The inverse has (a multiple) and can be computed efficiently, so the discrete logarithm can be computed using two challenges and two answers.

[0103] 4.1.2 Eliminating Interactions - Fiat-Shamir Heuristic

[0104] The Sigma protocol is an example of a public coin interactive proof system. That is, the message (challenge) sent by the verifier is random and has nothing to do with the prover's message. Using this feature, the interactive Sigma protocol can be turned into a non-interactive protocol (with only one message between the prover and the verifier) ​​by using a cryptographic hash function to simulate the entropy used by the verifier to sample the challenge e. This is called the Fiat-Shamir heuristic.

[0105] The Fiat-Shamir heuristic operates in a stronger security model. In this model, cryptographic hash functions are modeled as functions that output uniformly distributed bit strings over new input bit strings. In this security model, well-known hash functions such as SHA256 can be used to construct a "random oracle" function. This function maps an arbitrary bit string to a challenge Now, just set The prover can then calculate e without the help of the verifier. It should be noted that is the (public) record that appears immediately after the verifier generates a challenge e in the interactive Sigma protocol. Here ctxt represents the (public) context information known in advance by both parties (e.g., session or party identifiers).

[0106] The assumption of the RO function ensures the following two points. First, the challenge e is randomly distributed, so the interactive protocol only needs to satisfy zero knowledge (or SHVZK) of the honest verifier. Second, the prover calculates the commitment (and for that matter statement st) before the challenge could not be computed, so the order of execution of the protocol cannot be reversed.

[0107] If the question space Big enough to try different commitments The last case is correct if no (unique) challenge is encountered that allows impersonation. A moderate / conservative choice is to use a challenge size of 80 or 128 bits, respectively, although it will be appreciated that other challenge bit sizes may also be used.

[0108] 4.2 Pedersen Commitment

[0109] A vector Pedersen commitment or batch Pedersen commitment is a generalization of the Pedersen scheme to use a single group element Pair Vector Batch Pedersen can be instantiated on any group for which the discrete logarithm assumption is difficult to implement.

[0110] This scheme has two algorithms. Assume that the group The description of is an implicit input to both algorithms.

[0111] ● Commitment Com(m, r, CK): In the input message vector Random Elements and commitment key Above, output point:

[0112] C=m1·G1+…+m n ·G n +r·H

[0113] VerifyCom(m, r, C, CK): Reveals the input promise and commitment key Calculate C * =Com(x,CK;r). If C * =C, then output b = T (accept). Otherwise, output b = ⊥ (reject).

[0114] Each G1...G n , H are points on the elliptic curve, so that the commitment key for n=1 is a pair of points on the elliptic curve. Pedersen commitment provides a way to commit to n different messages over a single elliptic curve.

[0115] 4.2.1 Verifiable Generation of Commitment Keys

[0116] The group element H will be generated in a safe way so that the known point G i There is no relationship between and the exponent of H. It can be publicly verified that it was generated correctly.

[0117] 4.2.2 Trapdoor Commitment Key

[0118] By selecting the indices x1, ..., x n And set H: =x1·G1+…+x n ·G n To generate the group element H. It should be noted that, since we know x:=(x1, ..., x n ), so the Pedersen commitment is no longer binding. For example, for n = 1, suppose H = x·G, and C = m·G + rH. By setting r′: = r + x -1 (mm′) mod p can reveal a commitment C for any value m′≠m. The value x may be referred to as a trapdoor or trapdoor value in this article.

[0119] 4.3 Zero-knowledge Argument for Designated Verifiers

[0120] set up is an NP language that accepts the Sigma protocol. There exists a framework in which the prover Alice 130a can only prove the statement to a designated verifier Bob 103b (who holds the secret or trapdoor x) The statement cannot be proved to anyone else. The proof is non-interactive and the assurance is not transferable. The latter case means that Bob 103b cannot convince a third (hidden) verifier Charlie 103c of the truth of the statement, even if Charlie 103c is told the secret x.

[0121] Alice 103a generates proof π V To prove the following statement:

[0122] Or "I know secret x".

[0123] Prove π V is specially made for Bob 103b. If Bob is sure that his secret x has not been leaked, then π V It was indeed a convincing proof to him. However, Bob could not use π V or x to convince Charlie 103c Because Bob 103b can generate exactly the same proof (proving that he knows x).

[0124] A trapdoor commitment scheme can be used (e.g., Pedersen commitment with an unverifiable commitment key - see Section 4.1), where the trapdoor x is known to the designated verifier (Bob 103b). The prover (Alice 103a) commits to a random value w in commitment C, and uses C (along with the statement of the Sigma protocol and the first message A) to generate "half" of the challenge through a hash function. The non-interactive challenge is defined as:

[0125] e:=h+w, where h:=Hash(st||C||A).

[0126] In addition to checking the Sigma protocol, the designated verifier Bob also checks whether C is revealed for w. Now, since Bob can reveal C for any value he likes (using a trapdoor x - see Section 5.1), he can fake a proof π that runs the simulator Sim in a random challenge e V To obtain π: = (A, e, z), then reveal the relationship between w * :=commitment C of e-Hash(st||c||A).

[0127] 5. Proof System

[0128] This section specifies a proof scheme that allows data owners to control who can be convinced of the association between their data and a hashed commitment to the data. This embodiment includes a non-interactive proof system that Alice (the prover) uses to convince Bob (the designated verifier) ​​that he knows a private value r that is used to commit to data m.

[0129] 5.1 Statements

[0130] The data owner uses the Pedersen commitment key CK DO :=(GD O , H DO ) commits to her data m in a hidden way. The public statement (known at least to the data owner and the designated verifier) ​​is the tuple:

[0131]

[0132] Data is encoded as elements The data owner generates a knowledge proof for the designated verifier nizk to prove that he knows the elements in the following set:

[0133]

[0134] 5.2 Generating and Storing Commitment Keys

[0135] Commitment Key CK DO Can be shared between multiple data owners, but must be generated in a verifiable manner to ensure that no one knows (See Section 4.1.) To make this key publicly available, it can be stored in the blockchain as OP RETURN data.

[0136] 5.3 Prover and Designated Verifier Algorithm

[0137] For a given statement st defined above, the data owner generates nizk arguments π DV to prove that they know to reveal r∈ZKP(st) without revealing r to the verifier. In other words, they prove that they know

[0138] Designated verifiers choose random secret trapdoors And set the new commitment key to CK DV :=(G DV , H DV :=xG DV ). In this section, it is assumed that the data owner generates π DV CK DV The algorithm given below uses the cryptographic hash function to generate a non-interactive challenge.

[0139]

[0140] 5.4 Forged Certificate

[0141] Designated verifiers are able to generate "fake proofs" that are valid for false statements that include false data values ​​m'. A third party that receives the false proof will be convinced that the false proof satisfies the verification algorithm, but will not be able to be convinced that the data owner, rather than the designated verifier, is the source of the data.

[0142] Let tuple st:=(m, C, CK DO , obf), such that obf = SHA256(C). A designated verifier who knows the trapdoor x can generate a valid proof for any data m, even if they do not know the reveal r∈ZKP(st). This is possible because the designated verifier can DV reveal a commitment to any value they like, and can therefore choose the Schnorr proof challenge in advance (which supposedly proves that knowing The algorithm for false proofs is described in detail below.

[0143]

[0144] Therefore, a third party that receives proof π from a designated verifier cannot verify the origin of the data, and more specifically, cannot prove that the data owner is the origin of the data.

[0145] 6. Private Timestamp

[0146] The first application of the proof system described in Section 5 is to timestamp data in a private way. The data owner obfuscates the data m and then uploads the obfuscated obfDat to the blockchain. That is, the data owner uploads the obfuscated data commitment obfDat:=SHA256(C) to the blockchain, where C=Com(m, r, CK DO ), while keeping the randomness r private. More generally, the obfuscated obfDat can be any hash of the data commitment value C. That is, obfDat := Hash′(C), where Hash′ is a cryptographic hash function, not necessarily SHA256 or the hash function used to generate the challenge e.

[0147] Afterwards, she proves the association between obfDat and data m (only) to the designated verifier, without revealing the private value r. The proof ensures that m points to the timestamp of the designated verifier; the obfuscation and non-transferability of the proof ensures privacy for everyone except the designated verifier.

[0148] Data is recorded in the blockchain to ensure its immutability and existence at a given time. However, due to the hidden properties of Pedersen commitments, no one can infer which data has been timestamped.

[0149] It should be understood that storing the obfuscation on the blockchain causes the data to be recorded implicitly. That is, the data m does not need to be stored on the blockchain.

[0150] 6.1 Prove that the timestamp is added correctly

[0151] Once obfData is in the blockchain, anyone who wants to verify its association with the data can act as a designated validator. They will be assured that m is indeed consistent with obfDat.

[0152] The steps to prove and verify that the timestamp was added correctly are as follows:

[0153] 1. Designate a verifier to generate a trapdoor commitment key It should be remembered that trapdoors are So that H = x·G. This will change CK DV Sent to the data owner.

[0154] 2. The data owner runs the previous section on input (m, C, CK DO , obf), r and CK DV This will convert (m, C, π DV ) is sent to the specified verifier.

[0155] 3. Specify the verifier to input (m, C, π DV ) Run the verification algorithm. If the output is acceptable, the data m is considered correct.

[0156] Figure 3 An exemplary method of implementing the prover and verifier algorithm described above is shown. In this example, Alice 103a is the prover and data owner, and Bob 103b is the designated verifier.

[0157] In step 1, Alice 103a uses data m to generate a data commitment value C, where C=Com(m, r, CK DO ), r is a secret value known only to Alice 103a, and CK DO is the data owner commitment key, i.e. Alice's commitment key. Alice 103a hashes the data commitment value to generate the obfuscated data value obfData.

[0158] In step 2, Alice 103a stores the obfuscated data value obfData in a proof blockchain transaction on blockchain 150. The OP RETURN script is used to provide these values ​​to Bob 103b and other users. In some embodiments, a commitment value C is also stored on blockchain 150.

[0159] In step 4, Bob 103b retrieves the obfuscated data value obfData from the blockchain. In step 4, he selects a trapdoor value x and uses it to generate a designated validator commitment key CK DV , where CK DV :=(G DV , H DV :=xG DV ). In step 5, Bob 103b submits his designated verifier commitment key CK DV Sent to Alice 103a together with the obfuscated data value obfData. The message serves as or includes a request for a proof π for proving ownership and / or possession of the data m.

[0160] In step 6, once Alice 103a receives the designated verifier commitment key CK DV , she will use the designated verifier commitment key CK DV To generate the verifier commitment value D, so that D = w·G DV +s·H DV In this step, Alice 103a uses CK DV The random value w is later used to form the challenge e=h+w, but w cannot be selected based on h because Alice 103a first commits to m, i.e., uses the commitment D to generate h, to ensure that Alice 103a commits to w first.

[0161] In step 7, Alice 103a generates a proof π for proving knowledge of a secret value r. Alice 103a uses the obfuscated data value obfData received from Bob 103b to identify which data m Bob 103b has requested proof of ownership and / or possession of, and thus which secret value r to use when generating the proof π. Alice 103a may maintain a lookup table with entries (m, r, C, obfData) for implementing this step.

[0162] Then, in step 8, Alice 103a sends proof π including the verifier commitment value D to Bob 103b, thereby uncommitting the random value w. Alice 103a also sends the commitment value C and the data m to Bob 103b.

[0163] Bob 103b uses w.G DV +s·H DV to generate a target verifier commitment value, which he compares with the verifier commitment value D in step 9. If these values ​​match, Bob 103b verifies the data commitment value C based on the proof π by implementing steps 2 to 4 of the verification algorithm described in 5.2 above. In this step, Bob checks whether the uncommitment (w, s) is correct for the commitment D, where w is the committed message and s is the reveal. To do this, he uses his commitment key CK DV .

[0164] In step 11, Bob 103b generates a candidate obfuscated data value by hashing the data commitment value C, which he compares with the retrieved or "target" obfuscated data value obfData. The obfuscated data value obfData retrieved from the blockchain may be referred to as the target obfuscated data value obfData.

[0165] If Bob 103b is satisfied with the comparisons performed in step 9, step 10 and step 11, Bob 103b can be confident that Alice 103a is the owner of data m.

[0166] 6.2 Protecting the privacy of timestamps through non-transferable proofs

[0167] After receiving the (m, C, π) with obfDat = SHA256(C) from the data owner (Alice 103a), DV ), the designated verifier (Bob 103b) can verify the authenticity of any data m of his choice by running the false proof algorithm described in Section 5.4 above. * ≠m produces a convincing proof That is, through the proof of verification algorithm. With this capability, a third party (Charlie 103c) can never determine whether the data forwarded by Bob 103b comes from the data owner or from the designated verifier himself.

[0168] In other words, Charlie 103c cannot tell whether the data was created before (Alice 103a) uploaded obfDat to the blockchain or after (when Bob 103b saw commitment C). This means that any data from Bob 103b is not bound by the timestamp obfDat, thus maintaining the privacy of m from anyone other than Bob 103b.

[0169] Figure 4 A description of information that may be provided to Charlie 103c that may pass the authentication algorithm is provided.

[0170] 7. Data autonomy notarization

[0171] The above-described certification and verification algorithms may be used to provide a method for notarizing data.

[0172] In a self-sovereign notarization implementation of data, the data owner plays an active role in the notarization process (the data is signed by a Notary) and in uploading the signed data to the blockchain.

[0173] The notary receives the data m, but signs the obfuscated obfDat. The data owner is entitled to (a) strong privacy protection: no one can reassociate the signature (stored on-chain) with the actual data, and (b) control over who verifies the signature: only a designated verifier (who is convinced by the proof that such an association exists) can verify the signature to conclude that the notary (implicitly) signed the data.

[0174] A two-phase protocol is provided between the data owner, the designated verifier and the notary. The parameters of the scheme are pre-configured and stored in the blockchain. These parameters include the notary’s verification key PK for signing and the data owner’s commitment key CK DO .

[0175] Phase 1: Data Notarization. In the first phase, the data owner commits to their data m and sends that data along with the commitment C to the notary, who signs the hash of the commitment. The data owner then sends the obfuscated signed data Data * :=(obfDat,σ) is stored in the blockchain, where obfDat=SHA256(C).

[0176] Phase 2: Verify the notarized data. In the second phase, the designated verifier retrieves the data from the blockchain. * and request data m and commitment C from the data owner, along with a non-interactive zero-knowledge proof π revealing the knowledge r used to generate C from m DV The designated verifier uses the proof and signature σ to check the proof and also checks that obfDat is the hash of C.

[0177] Figure 5a and Figure 5b The above two-stage method is shown.

[0178] Figure 5a The "data notarization" phase is shown. The data owner (Alice 103a) sends a request to retrieve data from the blockchain 150. The request includes a "get data" command and a scheme ID (sid). Parameters are returned to Alice 103a, which may include the data owner commitment key CK DO , provided, for example, that the key is shared among multiple data owners. If not, the data owner does not need to retrieve any data from the blockchain.

[0179] Use the retrieved data owner commitment key CK DO , data m and secret value r, Alice 103a generates a data commitment value C.

[0180] Alice 103a requests the notary 502 to notarize the data m. To do this, Alice 103a sends the scheme ID, the data owner ID (id), the "notarize" command, the data commitment value C, and the data m to the notary 502. In response to receiving the request, the notary 502 checks the received data and, if the data is valid, generates an obfuscated data value by hashing the data commitment value and generates a data signature σ, where σ = Sign(sid|id|obfData; SK). The check performed by the notary 502 may depend on the business logic associated with the data, and if the data complies with the requirements specified by the logic, the data is found to be valid. The notary 502 will only sign the data if the commitment value C is a commitment of the data m that they have received and checked and is therefore compliant. Alice 103a proves to know the secret value r in zero knowledge. The notary 502 performs the verification algorithm described in Section 5.3 to check whether Alice 103a knows the secret value r.

[0181] Notary 502 signs the data Data * :=(obfDat,σ) is returned to Alice 103a. Alice 103a generates a blockchain transaction for storing the signed data to the blockchain 150, which also includes the scheme ID and the data owner ID. She uses the "store data" command to send the scheme ID and the data owner ID to be stored in the blockchain 150.

[0182] Figure 5b The "Verify Notarized Data" stage is shown. A designated verifier (Bob 103b) sends a request to retrieve data from the blockchain 150. The request includes a "get_data" command, a scheme ID, and a data owner ID identifying Alice 103a. These parameters and the signed data are returned to Bob 103b along with the scheme ID and data owner ID.

[0183] Bob 103b generates his commitment key CK DV , he sends the commitment key together with the obfuscated data value and the "request_data" command to Alice 103a in a data request.

[0184] Based on the received data request, Alice 103a generates a proof π for proving knowledge of the secret value r, which she sends to Bob 103b along with the data m and the data commitment value C. Bob 103b implements a verification algorithm to verify using the proof of m and checks the data signature σ. If the proof is verified and the signature is valid, Bob 103b can be confident that the data m is correct and owned by Alice 103a.

[0185] Notary 502 receives data m so that they can enforce compliance of the data before signing. Notary 502 does not know the private value r and therefore cannot prove the association between m and C. Data owner 103a can prove such association in zero knowledge, so Notary 502 acts as a designated verifier.

[0186] 8. Data notarisation as a service

[0187] Unlike the previous use case described in Section 7, the data owner trusts the notary with their private value r. In response, the notary generates a nizk proof π DV , and interact with the blockchain on behalf of the data owner. In addition, the notary allows parties to register as designated validators and prove to them that the notarization of the requested data stored in the blockchain is correct. Both services can be provided for a fee.

[0188] In this use case, the notary performs the verification algorithm described in Section 5 on behalf of the data owner. This is possible because the data owner trusts the notary to handle their secret value r.

[0189] Figure 6 The interaction between the parties is shown. The data owner (Alice 103a) sends her data m and secret value r to the notary 502, who checks and notarizes (signs) the data. The notary 502 then stores the signed data to the blockchain 150.

[0190] The designated verifier (Bob 103b) submits his commitment key CK DO Send it to Notary 502 to register with Notary 502. When registering, Bob 103b proves to Notary 502 that he knows the commitment key CK corresponding to him. DO Alternatively, Bob 103b can outsource the commitment key generation to a trusted third party to reveal the trapdoor value x to the designated verifier. Registration will be discussed in more detail below.

[0191] When Bob 103b wants to verify data, he retrieves the notarized data from blockchain 150 and sends it to notary 502 along with a verification request. Notary 502 also retrieves the notarized data from blockchain 150 and uses the corresponding secret value r and Bob's commitment key to generate a proof for Bob 103b, thereby implementing the above-mentioned proof algorithm. This proof is provided to Bob 103b so that he can confirm the source of the data by implementing the verification algorithm.

[0192] In this implementation, the data owner interacts with the notary 502 only once, in order to send only their data. Afterwards, they remain completely unaware of the notarization process. That is, the obfuscated data is uploaded to the blockchain (Phase 1 of the self-sovereign protocol in Section 7) and verified (generating a nizk certificate for a designated verifier - Phase 2 of Section 7).

[0193] 8.1 Signing Data

[0194] Signing data can be done in two ways:

[0195] Explicit Signature: Notary 502 signs the data commitment C and sets the obfuscated data to obfDat = SHA256(C||σ). Thus, the commitment and signature are concatenated. It is assumed that the designated verifier has the correct verification key PK of Notary 502. The designated verifier receives the signed commitment and checks whether the signature is correct and whether it hashes to obfDat (which he retrieved from the blockchain).

[0196] Implicit Signature: Notary 502 embeds the obfuscated data commitment obfDat as the OP RETURN data of the transaction that spends P2PKHUTXO. The designated verifier receives a P2PKH address known to belong to the notary (i.e., commitment C) and checks whether its hash is embedded in the transaction spent from the Kensei P2PKH address. The effect of this is to delegate signature verification to the miners of the blockchain.

[0197] 8.2 Protecting Notaries from Malicious Validators

[0198] A coalition of mutually distrusting designated validators could potentially interact, pay the notary only once, and reuse the same attestation for everyone.

[0199] Attack: A malicious verifier can generate a (trapdoor) commitment key CK in a secret sharing manner DV , where each colluding validator V i Generate the addition share of trapdoor x Then set CK DV : = (G, H: = x1·G+…+x n G) without disclosing x i Since no verifier knows the trapdoor x:=x1+…+x n , the same proof π DV It was convincing for all of them.

[0200] In this attack, a malicious validator can obtain proof π from the notary. DV , and pass the proof to other malicious verifiers, who will also be convinced of the validity of the underlying data. Therefore, if one of the malicious verifiers can convince the notary that they are not a malicious verifier, the notary will provide the proof π to the malicious verifier. DV , then the verified data can be shared among all malicious verifiers.

[0201] Notaries can be protected from this type of validator coalition in two ways.

[0202] 8.2.1 Generation of outsourced trapdoors

[0203] A simple solution to avoid malicious validator alliances is to place the trapdoor commitment key (x, CK DV ) is outsourced to a party (referred to in this article as the trapdoor generator). This party is trusted not to collude with the notary to share the trapdoor x and not to generate simulated proofs. Based on the generation request of the designated verifier, this issues him a signature pair (x, CK DV ). It should be noted that this explicitly includes the trapdoor x.

[0204] Any party can register the commitment key CK with the notary DV , the notary will check whether such a key is signed by the trapdoor generator. If this is the case, the notary is sure that at least one party (the de facto designated verifier) ​​knows CK DV The trapdoor x of , i.e. the party requesting the generation of the trapdoor generator's key. This will make the proof π convincing only to such designated verifier (and trapdoor generator) and not to other members of the federation.

[0205] 8.2.2 Proving knowledge of trapdoors in zero-knowledge

[0206] The solution described in Section 8.2.1 introduces new parties with high confidence, which may be undesirable. Instead, a designated verifier can prove (in zero-knowledge) to the notary that he knows a given commitment key CK DV The trapdoor x.

[0207] The difficulty lies in proving an explicit trapdoor x. For example, the standard Schnorr protocol for proving knowledge of the logarithm of H to base G (see Section 4.1.1) is not sufficient here. Suppose that each validator in the validator coalition as described above only knows the addition share x i , then the validator alliance can collaborate to prove that x is known at the same time.

[0208] 8.2.2.1 Basic idea

[0209] To register the commitment key CK with the notary 502 DV , the designated verifier (Bob 103b) plays the role of the prover, and the notary 502 plays the role of the verifier. As described later, if the proof verification succeeds, the verifier is very likely to be convinced that the prover explicitly used the trapdoor x when generating the proof.

[0210] The protocol is for the public input CK DV =(G, H:=x·G) with the following modifications: the verifier issues a bit challenge e∈{0,1}, and the prover commits in advance to two possible answers z0=a and z1:=a+x. They hash z i Therefore, set c i =Hash(z i ), where Hash is a cryptographic hash function (with collision resistance). Here a is the randomness used to generate the first message of the Schnorr protocol. Then, once the challenge bit e is revealed, the prover sends z e , the verifier will check z e It is c e The original image.

[0211] The modified Schnorr protocol has a reliability error In order to increase the reliability to p = 2 -s , the protocol can be repeated sequentially s times.

[0212] 8.2.2.2 Reduce the number of repetitions

[0213] The size of the challenge can be increased to d bits. Each execution of the protocol with a d-bit challenge will incur a reliability error of 2 -d . To achieve reliability error 2 -s , where s is a fixed security parameter, and the protocol is repeated a total of Second-rate.

[0214] After this, the prover needs to d Different answers i :=r+e i x is committed. This can be done efficiently using a Merkle tree of depth d, where the i-th leaf is set to z i When the verifier raises a challenge * Previously, the prover sent the root c of the Merkle tree, as z * =r+e * x along with its Merkle proof p. A Merkle tree may also be referred to herein as a succinct commitment, since it commits to n values ​​assigned to leaf nodes via one element (the Merkle root).

[0215] 8.2.2.3 Security Analysis - Why is the prover aware of the trapdoor?

[0216] The protocol outlined above has special soundness (see Section 4.1). This means that there exists a polynomial-time extractor algorithm ε that can extract the trapdoor x from two different accepted records (the first message is fixed). More specifically, by computing ε is extracted from two different challenges e≠e′ and two answers z, z′.

[0217] Now, assume that the prover knows all possible answers. Specifically, they can generate two acceptance records and run the extractor ε on them to output the trapdoor x. In other words, if the prover knows all possible answers, then they know the trapdoor x explicitly. The probability of providing a valid Merkle proof p for c without knowing the answer is at most d∈, where ∈ is the probability of finding a collision with the hash function used in a Merkle tree of depth d. Therefore, a convincing prover knows x with probability at least 1-d∈. Finally, it is important to note that ∈ is negligible relative to the size of c, assuming collision resistance of the hash function used in the Merkle tree.

[0218] 8.2.2.4 Implementing the protocol in practice

[0219] A non-interactive version of the protocol outlined above (using the Fiat-Shamir transform) can be implemented as follows:

[0220]

[0221] This zero-knowledge proof system proves knowledge of a trapdoor x. It is parameterized by the bit size d of the challenge and the number of iterations r. The hash function outputs a bit string of length k.

[0222] To preserve zero knowledge (of the trapdoor), the prover (designated verifier, Bob 103b) performs all rounds in sequence. This has an impact on the way the challenge is derived from the record. Specifically, let π i :=(R i ,c i ,e i ,z i ,p i ) is the record generated in round i. The (i+1)th challenge is (π i ,R i+1 ,c i+1 ). In addition, the prover generates a challenge by, for example, refusing to draw a sample to reduce the modulo 2 d No bias is introduced.

[0223] In this way, Bob 103b can prove explicit knowledge of trapdoor x, thereby proving that he knows all possible answers to possible challenges and commits to those answers.

[0224] Figure 7 A method is shown for registering as a designated verifier with notary 502. In this example, Bob 103b requests to register with notary 502.

[0225] Bob 103b generates his designated verifier commitment key CK DV , where CK DV =(G, H=x·G).

[0226] Bob 103b then implements the above proof algorithm. First, he uses the context information to set π0, which includes specifying the verifier commitment key CK DV =(G, H). Then, for each 1≤i≤r, Bob 103b uses π i-1 To iteratively calculate π i . Each π i Both can be called the challenge proof part.

[0227] To calculate each π i , Bob 103b generates the Merkle tree. Bob calculates 2 d answer value, j = 0 to 2 d -1. These values ​​are assigned to leaf nodes 0 to 2 in the Merkle tree. d -1 leaf node, so that there are 2 associated with the answer value in each Merkle tree d leaf nodes.

[0228] Use 2 d Bob 103b generates the Merkle root using the Merkle root and the randomly selected value a. i and the first commitment key component in the commitment key component G to calculate the commitment A i and the previous challenge proof part π i-1 To generate a challenge. The challenge includes the challenge value e i , also called the target challenge value.

[0229] Challenge value e i Used to select one of the answer values. Specifically, select i The corresponding answer value. The chosen answer value is used as the preimage of the Merkle proof.

[0230] Bob 103b generates a Merkle proof for the chosen answer value, i.e., a proof containing As root is c i The certification path p of the leaf of the Merkle tree i , and then generate the challenge proof part π i The challenge proof part consists of the commitment, the Merkle root, the challenge value, and the chosen answer value.

[0231] Bob 103b generates a proof π that includes for every π 1≤i≤r i And the Merkle proof (certification path) p i That is, based on the r Merkle trees he generated. The challenge proof π includes the Merkle root, the Merkle proof, the challenge, and the chosen answer value.

[0232] To improve communication complexity, remove the proof part π i Commitment A i . The verifier then recalculates these values. It should be understood that commitment A i can be included in the proof π and sent from the prover to the verifier.

[0233] Bob 103b provides proof π and his commitment key CK to notary 502 DV In a similar manner as Bob 103b, notary 502 uses the context information to set π0.

[0234] For each 1≤i≤r, notary 502 uses the proof π provided by Bob 103b to calculate the candidate challenge value e i * , and compare the candidate challenge value with the corresponding target challenge value e provided in the challenge proof π i (also called the target challenge value) for comparison.

[0235] Notary 502 also checks the Merkle proofs for each 1≤i≤r provided in the challenge proof π.

[0236] If each candidate challenge value matches its corresponding target challenge value, and each Merkle proof is found to be valid, then the proof is verified and the notary 502 registers Bob's commitment key CK DV .

[0237] Once Bob 103b registers his commitment key CK with notary 502 DV , Bob 103b can then request the notary 502 to verify the data using the proof and verification algorithm described in Section 5.

[0238] 8.2.2.5 Complexity and parameter selection

[0239] Pedersen commitments are initiated over any elliptic curve with order p of 256 bits, and the hash function used to derive the challenge and construct the Merkle tree uses SHA-256. These choices produce proofs of bit size roughly r(512+257d) Where d<<256 is the bit size of the challenge and r is the number of iterations (rounds).

[0240] The prover needs to perform r scalar multiplications, and the verifier needs to perform twice as many. Therefore, the number of iterations r needs to be minimized as much as possible. This is to minimize computational and communication complexity. However, r cannot be set too small (e.g., r = 1), as this will result in a Merkle tree that is too large (e.g., 2 s leaves), so that the prover cannot compute. For example, it can be repeated 5 times, 8 times, or 16 times (i.e., r=5, 8, 16); however, it should be understood that the parameters s, d, r are configurable and can be selected based on the computing power of the device of the designated verifier.

[0241] Considering And the reliability safety parameter has been fixed to s∈{80, 128, 256), and the specific values ​​of r and d should be determined based on experience.

[0242] 9. Alternatives

[0243] In the above example, data m, data commitment value C, and obfuscated data value obfData are retrieved from blockchain 150. It should be understood that some or all of these values ​​can be transferred off-chain between the data owner or the notary and the designated verifier in the implementation described in Section 8. The same is true for signature data. It should be understood that using a blockchain to store and transfer these values ​​introduces an additional level of trust because these values ​​are immutably stored on the blockchain.

[0244] The data commitment value in the above example is C = m·G DO +r·H DO It should be understood that the term "data commitment value" can be used to refer to any other value that requires the user to commit to the data value m. For example, the data commitment value can be a hash (of data m, data commitment value C, or any other suitable value) or a public key.

[0245] 10. DID and C

[0246] The World Wide Web Consortium (W3C) provides guidance and standards for Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs). DIDs support decentralized and verifiable digital identities, while VCs allow claims (i.e., statements about a subject) to be verified by legitimate verifiers. The W3C data model can be accessed at https: / / www.w3.org / TR / Vc-data-model / .

[0247] Although DID is decentralized, VC allows trusted entities to issue cryptographically verifiable credentials. W3C also introduced the concept of verifiable presentation (VP) of VC, which can allow selective disclosure and other attributes to maximize the privacy of VC holders.

[0248] A ZKP with a designated verifier can be a VP that cannot be passed to convince another verifier. As mentioned above, Alice does not want Bob to be able to convince others that she is over 18. Alice can generate a ZKP that designates Bob as the verifier to protect her privacy.

[0249] For example, suppose the statement "Alice is over 18 years old" is attested in the form of a public key certificate (i.e., X509 format). This means that if Alice can generate a digital signature relative to the certification public key, she is proven to be over 18 years old. However, instead of generating a valid digital signature that can be reused to convince others, Alice can generate a ZKP of her private key for a designated verifier, Bob. Therefore, Bob is confident that Alice knows the private key without the digital signature, but Bob cannot convince anyone else of this.

[0250] This approach can be generalized to any verifiable credential that is cryptographically protected by a secret known to the VC owner.

[0251] Another approach is for the VC issuer to certify a commitment to a statement. The owner can present the statement to a designated verifier, who will verify the ZKP proof and the issuer's commitment certificate.

[0252] In the above example, it should be understood that VC (here Alice's age or over 18 status) can be regarded as data, where Alice is the VC owner. The challenge proof π is the VP generated to prove to the designated verifier Bob that Alice knows the secret. For example, the secret as a trapdoor can be her private key, and the corresponding certified public key can be a commitment key. In this case, the data m can be implicitly or explicitly confirmed by the publisher in the public key certificate.

[0253] 11. Further comments

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

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

[0256] 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).

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

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

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

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

[0261] Statement 1. A computer-implemented method for proving ownership and / or possession of data m, the method comprising: generating a data commitment value based on a secret value r and the data m; generating a challenge solution π associated with a designated verifier, wherein the challenge solution π is a zero-knowledge proof that proves knowledge of the secret value r; and providing the data m, the challenge solution π, and the data commitment value to the designated verifier; wherein the secret value r is not known to the designated verifier or is not provided to the designated verifier.

[0262] Statement 2. The method according to statement 1, wherein the step of generating the challenge solution π associated with the specified verifier includes: generating a verifier commitment value associated with the specified verifier, wherein the challenge solution π includes the verifier commitment value.

[0263] Statement 3. A method according to any of the preceding statements, wherein the method further comprises: receiving a verifier commitment key from the designated verifier, wherein the verifier commitment key is associated with the designated verifier, wherein the zero-knowledge proof associated with the designated verifier is generated based on the verifier commitment key.

[0264] Statement 4. The method of any preceding statement, wherein the method further comprises: generating a hash of the data commitment value, and providing the hash of the data commitment value to the designated verifier.

[0265] Statement 5. The method of statement 4, wherein the method further comprises: generating a proof blockchain transaction that, when stored on a blockchain, makes the hash of the data commitment value available; and providing the proof blockchain transaction to one or more nodes of the blockchain.

[0266] Statement 6. A method according to any of the preceding statements, wherein the data commitment value is derived based on a data owner commitment key.

[0267] Statement 7. The method according to any of the preceding statements, wherein the method further comprises: providing the data commitment value and the data m to a notary; and receiving a signed version of the data from the notary.

[0268] Statement 8. The method of statement 7, wherein the signed version of the data is generated by signing the data commitment value.

[0269] Statement 9. The method of statement 7, wherein the signed version of the data is generated by signing a hash of the data commitment value, wherein the hash of the data commitment value is received from the notary.

[0270] Statement 10. The method of statement 7, wherein the method further comprises: generating a notarized blockchain transaction that, when stored on the blockchain, makes available the signed version of the data received from the notary.

[0271] Statement 11. The method of statement 9, wherein the method further comprises: generating a notarized blockchain transaction that, when stored on the blockchain, makes available the hash of the data commitment value received from the notary.

[0272] Statement 12. A method according to any one of statements 1 to 7, wherein the method is implemented by a notary, the method further comprising: receiving the data m from a data owner of the data m; and generating a signature associated with the data m.

[0273] Statement 13. A method according to statement 12 that is subordinate to statement 4, wherein the method further includes: receiving a trapdoor proof from the designated verifier, wherein the trapdoor proof is a non-interactive zero-knowledge proof for proving knowledge of a trapdoor value, wherein the verifier commitment key includes a first elliptic curve point and a second elliptic curve point, wherein the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key; and verifying the trapdoor proof based on the verifier commitment key; wherein, if the trapdoor proof is verified, the notary provides the verifier commitment value and the version of the data commitment value to the designated verifier.

[0274] Statement 14. A method according to statement 12 that is subordinate to statement 3, wherein the method further includes: receiving a signed version of the verifier commitment key; and verifying that the signed version of the verifier commitment key has been signed by a trusted trapdoor generator, wherein the trusted trapdoor generator generates a signed pair, the signed pair comprising the signed version of the verifier commitment key and a signed trapdoor value, each of which is signed by the trusted trapdoor generator, wherein the verifier commitment key comprises a first elliptic curve point and a second elliptic curve point, wherein the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key; wherein, if the signed version is verified, the notary provides the verifier commitment value, and the version of the data commitment value to the designated verifier.

[0275] Statement 15. A computer-implemented method for verifying data m by a designated verifier, the method comprising: obtaining: the data m; a data commitment value, wherein the data commitment value is generated based on the data m and a secret value r, wherein the secret value r is unknown to the designated verifier; and, a challenge solution π associated with the designated verifier, wherein the challenge solution π is a zero-knowledge proof that proves knowledge of the secret value r; and, checking whether the challenge solution π is associated with the designated verifier; and, based on the challenge solution π, verifying the data commitment value based on the data m.

[0276] Statement 16. A method according to statement 15, wherein the challenge solution π associated with the designated verifier includes a target verifier commitment value associated with the designated verifier, wherein the step of checking whether the challenge solution π is associated with the designated verifier includes: generating a candidate verifier commitment value, and comparing the candidate verifier commitment value with the target verifier commitment value, wherein if the candidate verifier commitment value and the target verifier commitment value are equal, then the challenge solution π is associated with the designated verifier.

[0277] Statement 17. A method according to statement 16, wherein the method further includes: generating a verifier commitment key associated with the specified verifier; and transmitting the verifier commitment key to the generator of the verifier commitment value, wherein the target verifier commitment value is generated based on the verifier commitment key.

[0278] Statement 18. The method of statement 17, wherein the verifier commitment key is transmitted along with the request for the data commitment value.

[0279] Statement 19. A method according to any one of statements 15 to 18, wherein the method further comprises: obtaining a target hash of the data commitment value; generating a candidate hash of the data commitment value, and comparing the candidate hash with the target hash of the data commitment value, wherein if the candidate hash matches the target hash, the data m is verified.

[0280] Statement 20. A method according to any one of statements 15 to 18, wherein the target hash of the data commitment value is obtained from a certified blockchain transaction stored on a blockchain.

[0281] Statement 21. A method according to any one of statements 15 to 20, wherein the method further comprises: obtaining a signed version of the data m, and verifying the signed version of the data m.

[0282] Statement 22. The method of statement 21, wherein the signed version of the data m is obtained from a blockchain transaction stored on a blockchain.

[0283] Statement 23. The method of statement 20 as dependent upon statement 17 or 18, wherein the target hash of the data commitment value is transmitted to the generator of the verifier commitment value together with the verifier commitment key.

[0284] Statement 24. A method according to statement 17 or any of its subordinate statements, wherein the method further includes: generating a trapdoor proof, wherein the trapdoor proof is a non-interactive zero-knowledge proof for proving knowledge of a trapdoor value, wherein the verifier commitment key includes a first elliptic curve point and a second elliptic curve point, wherein the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key; transmitting the trapdoor proof to a notary, wherein the notary is the generator of the verifier commitment value; and, receiving the target verifier commitment value from the notary.

[0285] Statement 25. A computer device, comprising: a memory, the memory comprising one or more memory units; and a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device, and the code is configured to cause the processing device to execute a method according to any one of statements 1 to 24 when running on the processing device.

[0286] Statement 26. 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 24.< / pa>

Claims

1. A computer-implemented method for proving ownership and / or possession of data m, the method comprising: generating a data commitment value based on the secret value r and the data m; generating a challenge solution π associated with a specified verifier, wherein the challenge solution π is a zero-knowledge proof proving knowledge of the secret value r; as well as Providing the data m, the challenge solution π, and the data commitment value to the designated verifier; The secret value r is not known to the designated verifier or is not provided to the designated verifier.

2. The method according to claim 1, wherein the step of generating the challenge solution π associated with the designated verifier comprises: A verifier commitment value associated with the designated verifier is generated, wherein the challenge solution π includes the verifier commitment value.

3. The method according to any of the preceding claims, wherein the method further comprises: A verifier commitment key associated with the designated verifier is received from the designated verifier, wherein the zero-knowledge proof associated with the designated verifier is generated based on the verifier commitment key.

4. The method according to any one of the preceding claims, wherein the method further comprises: A hash of the data commitment value is generated, and the hash of the data commitment value is provided to the designated verifier.

5. The method according to claim 4, wherein the method further comprises: generating a proof blockchain transaction that, when stored on a blockchain, makes available the hash of the data commitment value; as well as The attesting blockchain transaction is provided to one or more nodes of the blockchain.

6. A method according to any preceding claim, wherein the data commitment value is derived based on a data owner commitment key.

7. The method according to any of the preceding claims, wherein the method further comprises: Providing the data commitment value and the data m to the notary; as well as A signed version of the data is received from the notary.

8. The method of claim 7, wherein the signed version of the data is generated by signing the data commitment value.

9. The method of claim 7, wherein the signed version of the data is generated by signing a hash of the data commitment value, wherein the hash of the data commitment value is received from the notary.

10. The method according to claim 7, wherein the method further comprises: A notarized blockchain transaction is generated that, when stored on the blockchain, makes available the signed version of the data received from the notary.

11. The method according to claim 9, wherein the method further comprises: A notarized blockchain transaction is generated that, when stored on the blockchain, makes available the hash of the data commitment value received from the notary.

12. The method according to any one of claims 1 to 7, wherein the method is implemented by a notary, and further comprises: receiving the data m from a data owner of the data m; as well as A signature associated with the data m is generated.

13. The method according to claim 12 as appended to claim 4, wherein the method further comprises: receiving, from the designated verifier, a trapdoor proof, wherein the trapdoor proof is a non-interactive zero-knowledge proof proving knowledge of a trapdoor value, wherein the verifier commitment key comprises a first elliptic curve point and a second elliptic curve point, wherein the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key; as well as Verifying the trapdoor proof based on the verifier commitment key; Wherein, if the trapdoor proof is verified, the notary provides the verifier commitment value and the version of the data commitment value to the designated verifier.

14. The method of claim 12 as appended to claim 3, wherein the method further comprises: receiving a signed version of the verifier commitment key; as well as verifying that the signed version of the verifier commitment key has been signed by a trusted trapdoor generator, wherein the trusted trapdoor generator generates a signature pair, the signature pair comprising the signed version of the verifier commitment key and a signed trapdoor value, each of which is signed by the trusted trapdoor generator, wherein the verifier commitment key comprises a first elliptic curve point and a second elliptic curve point, wherein the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key; Wherein, if the signature version is verified, the notary provides the verifier commitment value and the version of the data commitment value to the designated verifier.

15. A computer-implemented method for verifying data m by a designated verifier, the method comprising: Get: The data m; a data commitment value, wherein the data commitment value is generated based on the data m and a secret value r, wherein the secret value r is unknown to the designated verifier; and a challenge solution π associated with the designated verifier, wherein the challenge solution π is a zero-knowledge proof proving knowledge of the secret value r; Checking whether the challenge solution π is associated with the specified verifier; as well as Based on the challenge solution π, the data commitment value is verified based on the data m.

16. The method of claim 15, wherein the challenge solution associated with the designated verifier comprises a target verifier commitment value associated with the designated verifier, wherein the step of checking whether the challenge solution is associated with the designated verifier comprises: A candidate verifier commitment value is generated and the candidate verifier commitment value is compared with the target verifier commitment value, wherein if the candidate verifier commitment value and the target verifier commitment value are equal, then the challenge solution π is associated with the designated verifier.

17. The method according to claim 16, wherein the method further comprises: generating a verifier commitment key associated with the designated verifier; as well as The verifier commitment key is transmitted to a generator of the verifier commitment value, wherein the target verifier commitment value is generated based on the verifier commitment key.

18. The method of claim 17, wherein the verifier commitment key is transmitted along with the request for the data commitment value.

19. The method according to any one of claims 15 to 18, wherein the method further comprises: Obtain a target hash of the data commitment value; A candidate hash of the data commitment value is generated and compared to the target hash of the data commitment value, wherein if the candidate hash matches the target hash, the data m is verified.

20. The method of any one of claims 15 to 18, wherein the target hash of the data commitment value is obtained from a certified blockchain transaction stored on a blockchain.

21. The method according to any one of claims 15 to 20, wherein the method further comprises: Obtain a signed version of the data m, and verify the signed version of the data m.

22. The method of claim 21, wherein the signed version of the data m is obtained from a blockchain transaction stored on a blockchain.

23. A method according to claim 20 as appended to claim 17 or 18, wherein the target hash of the data commitment value is transmitted to the generator of the verifier commitment value together with the verifier commitment key.

24. The method according to claim 17 or any claim dependent therefrom, wherein the method further comprises: generating a trapdoor proof, wherein the trapdoor proof is a non-interactive zero-knowledge proof that proves knowledge of a trapdoor value, wherein the verifier commitment key comprises a first elliptic curve point and a second elliptic curve point, wherein the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key; transmitting the trapdoor proof to a notary, wherein the notary is the generator of the verifier commitment value; as well as The target verifier commitment value is received from the notary.

25. 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 code arranged to be executed on the processing device, and the code is configured to cause the processing device to execute the method according to any one of claims 1 to 24 when executed on the processing device.

26. 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 24.

Images