Blockchain transactions

Abstract

A computer-implemented method for generating a blockchain transaction is provided. And generating a first locking script for querying the block chain transaction, wherein the first locking script comprises a target statement and a verification script for verifying a query solution pi provided in a first unlocking script for proving the block chain transaction. The challenge solution [pi] is a non-interactive zero knowledge proof that proves that the secret witness w is known. The first lock script, when executed together with the first unlock script, is configured to: calculate a candidate commitment value A * based on the challenge solution pi and one of candidate statements provided in the target statement and the first unlock script; calculating a candidate hash value using the candidate commitment value A * and one of the target statement and the candidate statement; verifying the challenge solution [pi] based on the candidate hash value; and verifying that the challenge solution pi is provided in the attestation block chain transaction.

Description

Technical Field

[0001] The present disclosure relates to a computer-implemented method for generating a blockchain transaction, the output of which is locked based on a challenge, and a computer-implemented method for generating a blockchain transaction including an unlocking script, wherein the unlocking script is used to provide a challenge solution to unlock the locking script. 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] Most locking scripts are one of a limited number of types, including pay-to-public-key (P2PK), pay-to-public-key-hash (P2PKH), and multi-signature. While these locking scripts are suitable for many applications, it is desirable to extend the functionality of blockchains by providing additional mechanisms for locking unspent transaction outputs (UTXOs). Furthermore, most locking scripts typically work by forcing the spender of the UTXO to provide certain data in the unlocking script of the spending transaction. In some cases, this may create security and / or privacy issues. Therefore, it would be beneficial to be able to lock a UTXO based on (secret) data without having to reveal this data in the unlocking script.

[0010] According to one aspect disclosed herein, a computer-implemented method for generating a blockchain transaction is provided, the method comprising: generating a first locking script for challenging a blockchain transaction, the first locking script comprising a target statement, and a verification script for verifying a challenge solution π provided in a first unlocking script for proving the blockchain transaction, wherein the challenge solution π is a non-interactive zero-knowledge proof for proving knowledge of a secret witness w; wherein, when executed together with the first unlocking script, the first locking script is configured to: calculate a candidate commitment value A based on the challenge solution π provided in the first locking script and one of the target statement and the candidate statement provided in the first unlocking script * ; Use the candidate commitment value A * and one of the target statement and the candidate statement to calculate a candidate hash value; based on the candidate hash value, verifying the challenge solution π; and, verifying that the challenge solution π is provided in the proof blockchain transaction; and providing the blockchain transaction to one or more nodes of the blockchain.

[0011] Unlike standard puzzles, the solution to a zero-knowledge puzzle is never published on-chain in the unlocking script (also referred to herein as the "scriptSig field") of a spending transaction. Instead, the scriptSig field contains mathematical proof that the solution is known for sure. The proof itself does not reveal any information about the solution. Verification of the mathematical proof is implemented in the Script and embedded in the locking script (also referred to herein as the "scriptPubKey field") of the transaction being spent.

[0012] More specifically, let the mathematical finite group There are p elements. The unlocking script of the spending transaction contains a non-interactive zero-knowledge (nizk) proof π, which is used to prove knowledge of the secret witness — Undisclosed puzzle solution. The locking script of the transaction being spent implements a verification algorithm that checks that π is valid relative to a public statement also embedded in the locking script. correctness.

[0013] As described in the detailed description, embodiments of the present disclosure provide a locking script that provides one or more of higher security, privacy, compatibility, and flexibility than at least some existing locking scripts. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0017] Figure 3 A schematic block diagram of some node software for processing transactions is shown;

[0018] Figure 4a It is shown that Sigma agreement of the pre-image in ;

[0019] Figure 4b An interactive Sigma protocol for an OR relationship is shown;

[0020] Figure 5 Schematically illustrating payment to a generic ECDSA public key using a zero-knowledge puzzle;

[0021] Figure 6Schematically illustrating private payments to a group using a zero-knowledge puzzle;

[0022] Figure 7 Schematic illustration of private payment to a threshold group using a zero-knowledge puzzle;

[0023] Figure 8 Schematically illustrates the method by which two collaborators generate challenge proofs for a zero-knowledge puzzle;

[0024] Fig. 9 Schematic diagram of a method for three collaborators to generate a challenge proof for a zero-knowledge puzzle. DETAILED DESCRIPTION

[0025] 1. Exemplary System Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0053] 2. UTXO-based model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0073] 3. Side Channels

[0074] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functions. This additional function enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). Side channel 107 enables data to be exchanged away from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. 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, side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0075] 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 link bundle or collection as a whole may be referred to as a side channel 107 in the case of multiple links. 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.

[0076] 4. Node software

[0077] Figure 3 An example of node software 450 running on each blockchain node 104 of the network 106 in an example of a UTXO-based or output-based model is shown. It should be noted that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., not performing the actions required of the node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes, but is not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to identify different fields of a transaction 152 and process such fields according to the node protocol. When a transaction 152i (Tx m-1 )’s output (e.g., UTXO) is an input transaction 152j (Tx j ), the protocol engine 451 identifies Tx j The unlocking script in and passes it to the script engine 452. The protocol engine 451 also j The pointer in the input to identify and retrieve Tx i .Tx i may be published on blockchain 150, in which case the protocol engine may retrieve Tx from the copy of block 151 of blockchain 150 stored at node 104 i . Or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve Tx from unpublished ordered transaction set 154 maintained by node 104. i Regardless of the method used, the script engine 451 will identify Tx i The locked script in the reference output is passed to the script engine 452.

[0078] Therefore, the script engine 452 has Tx i The locking script and the j The unlocking script for the corresponding input. For example, Figure 2 Transaction labels Tx0 and Tx1 are shown in FIG, but the same transaction can also be applied to any transaction pair. As previously described, the script engine 452 runs two scripts together, which will include placing data on and retrieving data from the stack 453 according to the stack-based scripting language used (e.g., script).

[0079] By running the scripts simultaneously, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script unlocks the output including the locking script? The script engine 452 returns the result of the determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet one or more criteria specified in the corresponding locking script, the result "TRUE" is returned. Otherwise, the result "FALSE" is returned.

[0080] In the output-based model, the result "TRUE" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, one or more further protocol-level conditions evaluated by the protocol engine 451 must also be satisfied; for example, Tx j The total amount of digital assets specified in the inputs of tx does not exceed the total amount pointed to in its outputs, and tx i The pointed output of has not been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 and one or more protocol-level conditions, and only if they are all TRUE, the protocol engine verifies the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Only when the conditions are really valid, the decision engine 454 can choose to control the consensus module 455C and the propagation module 455P at the same time to execute its Tx j . This includes the consensus module 455C, adding Tx to the corresponding ordered transaction set 154 of the node j , for incorporation into block 151; and propagation module 455P, Tx j Forwarded to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees are reserved.

[0081] In addition, it should be noted that in this article, the terms "TRUE" and "FALSE" are not necessarily limited to returning results that are expressed only in the form of a single binary number (bit), although this is indeed a possible implementation. More generally, "TRUE" can refer to any state indicating a successful or positive result, while "FALSE" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, the combination of implicit protocol-level verification of signatures and additional positive outputs of smart contracts can be used to indicate that the result is "TRUE" (if both individual results are TRUE, the overall result is considered to be TRUE).

[0082] 5. Zero-knowledge proof

[0083] set up is a finite group of order p, An index ring. The elements in the express, The elements in the express. The vector of n elements in is represented as same, The vector of m elements in is represented as The symbol + is used for Group operations (addition notation), also used in rings Addition operation in (modulo p addition).

[0084] There is no requirement that p is prime. However, for practical instantiations, p is prime. In general, is assumed to be a prime-order elliptic curve.

[0085] 5.1 SIGMA Protocol

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

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

[0088]

[0089] This paper uses Camenisch-Stadler notation to represent the witness set (knowledge set) as:

[0090]

[0091] This paper uses this notation to make it easier to distinguish concisely between the sentence st, the witness w, and the predicate acting on them.

[0092] The Sigma protocol is a three-round protocol between a prover and a verifier, and its structure is as follows. Both parties receive a statement st as input. In addition, the prover receives a witness w as an additional input.

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

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

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

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

[0097] Features of the Sigma protocol include:

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

[0099] 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

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

[0101] Special soundness implies stronger properties: the Sigma protocol is also used to prove knowledge (of the witness).

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

[0103] 5.2 Relations based on group homomorphism

[0104] This paper considers NP statements about elements of prime-order groups, including elliptic curves. Let p be a prime number, and group p be One-way homomorphism Define a binary relation as Get the knowledge set:

[0105]

[0106] Proven Figure 4a The protocol in is reliable and has SHVZK. For a given vector of group elements This protocol is used to prove that The original image in

[0107] 5.3 Analog Recording

[0108] Input Point Simulator Algorithm for Zero Knowledge (Derived from Statements) and Challenge e Do the following:

[0109] 1. Random selection sample

[0110] 2. Calculation

[0111] 3. Output simulation proof

[0112] The simulated proof will pass the check equation and therefore appear completely valid to the verifier. In fact, if e is random, the simulated proof will have the same distribution as the honest proof. It should be noted that this particular simulation method is only valid when the first message is generated. This is only possible when the challenge e is known, so participation Figure 4a A cheating prover using the interactive protocol described in will not be able to do this.

[0113] Proving simulation not only helps to argue that no witness information has been leaked (since the records in the protocol can be generated without using witnesses), the algorithm is also used to prove OR statements, as described in Section 5.5.

[0114] 5.4 Conjunctive proofs

[0115] AND proofs are used to prove knowledge of (possibly different) relations n independent witnesses. When limited to the relationship described in Section 5.1 above When , the knowledge set of AND relationship is:

[0116]

[0117] can be seen as another original image knowledge relation, where is a composite group homomorphism:

[0118]

[0119] Σ AND The agreement only needs to be run Figure 4a It should be noted that the same challenge is used to prove all knowledge of the original image.

[0120] 5.5 Disjunctive proofs

[0121] In this scenario, the goal is to verify that the witness knows at least one statement in r. The knowledge set of the OR relationship is:

[0122]

[0123] The idea of ​​an OR proof is to let the prover simulate all proofs except one, that is, the prover can simulate proofs for statements for which they do not know the witness, but not give them much freedom in choosing the challenges (they can choose exactly r-1 challenges). This way, the prover is forced to prove that the witness knows at least one relation.

[0124] In more detail, assuming that j is a true statement, that is, the prover knows w such that Proof of i≠jπ i Through the Sigma protocol (See Section 5.3)

[0125] Simulator Generated, pre-selected query e i However, the challenge of the jth proof is completely determined by the other challenges and the offset value (also called offset challenge in this paper), which is determined by the verifier after seeing all the commitments. This ensures that the prover can generate π when knowing the witness w j .

[0126] Figure 4b It shows that Σ OR Interactive version of the protocol.

[0127] 5.6 Eliminating Interactions — FIAT-SHAMIR Heuristic

[0128] It is best to limit the communication between the prover and the verifier to just a single message.

[0129] 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 unrelated to the verifier's message. Using this property, the interactive Sigma protocol can be turned into a non-interactive protocol by simulating the entropy used by the verifier to sample the challenge e using a cryptographic hash function. This is called the Fiat-Shamir heuristic.

[0130] 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 any bit string to Now, by setting The prover can compute e without the help of the verifier. It should be noted that is the (public) record that appears immediately after a verifier generates a challenge e in the interactive Sigma protocol.

[0131] The assumption of the RO function ensures two things. First, the challenge e is randomly distributed, so zero knowledge of the honest verifier is sufficient. Second, the prover is (and for that matter statement st) before the challenge could not be computed, so the order of execution of the protocol cannot be reversed.

[0132] If the query space is large enough to try different commitments The last case is correct if no (unique) challenge is encountered that allows impersonation. That is, try until (See Section 5.3) * The probability of

[0133] 5.6.1 Binding Information to Non-Interactive Proofs

[0134] Any public context information ctxt can be bound to the proof by prepending the context information to the input of the random oracle RO. This means that the challenge e also depends on ctxt, so it is guaranteed that this information is provided by the prover (because only he can prove to know the witness). Specifically, the challenge e of the non-interactive Sigma proof is generated as follows:

[0135]

[0136] 5.6.2 Shorter Proofs

[0137] To reduce the size of the solution to the puzzle, specifically, the size of Σ to prove π, an equivalent verification procedure can be used, which commits Removed from the proof of transfer. With this verification, the proof is defined as

[0138]

[0139] 6. Zero-knowledge puzzle specifications

[0140] Zero-knowledge puzzles are other NP languages ​​that support script verification The NP language generated by AND / OR combination (See Section 5.1.) This language (again, supporting script validation) is called part of a puzzle. The solution to the puzzle is the statement And a non-interactive zero-knowledge argument π(nizk) that proves its truth. Non-interactive zero-knowledge argument π may also be referred to as a proof or challenge solution in this article.

[0141] Roadmap for specifying zero-knowledge puzzles: This zero-knowledge puzzle specification includes defining scripting algorithms for different verifiers in Section 5. These algorithms are centralized via a general non-interactive verifier described in Section 5.6.2.

[0142] Specifying a script for this universal verifier means being able to homomorphically Apply to answer And instantiate the random oracle.

[0143] Section 6.1 below describes the abstract structure (template) of the zero-knowledge puzzle script. Section 6.2 provides a concrete instantiation of the random oracle function RO in the script (see Section 5.6). The remaining sections deal with the implementation of the (non-interactive version of) on-chain verifiers: Section 6.3 implements the preimage knowledge verifier in 4a, Section 6.4 implements the conjunction (AND) verifier, and Section 6.5 implements the disjunction (OR) verifier.

[0144] 6.1 The structure of the zero-knowledge puzzle as a spending condition

[0145] The necessary steps to construct a zero-knowledge puzzle into a locking script and deconstruct it into the corresponding unlocking script are described below.

[0146] 6.1.1 Binding Spend Transactions to NIZK Proofs

[0147] The integrity of spending transactions (transactions that provide puzzle solutions in unlocking scripts) against corrupt miners or man-in-the-middle attackers is enforced at the scripting engine 452 level.

[0148] The integrity of the transaction is verified by a dummy signature technique. A digital signature tx_dummy_sign:=(r,s) generated using a signing key and (optionally) a fixed temporary key is included in the unlocking script. The dummy signature can be an ECDSA signature. This signature on secp256k1 can use the opcode OP_CHECKSIG to ensure integrity.

[0149] It should be understood that other forms of ensuring transaction integrity may be adopted, such as injection techniques such as the so-called OP_PUSHTX technique. The virtual signature technique is used herein because it is more efficient than other known techniques.

[0150] After verification, tx_dummy_sign will generate a non-interactive challenge on-chain as context information. (See also Section 6.2)

[0151] 6.1.2 Generate locking script

[0152] The locking script can be generated by following the steps below:

[0153] 1. Write the NP language of the use case. The more general form of the language can be expressed in disjunctive normal form:

[0154]

[0155] in is any group homomorphism The original image knowledge language.

[0156] 2. Use the modular framework in the next section to generate the validator script to encode.

[0157] 3. Set public statements Hardcode it in the locking script. (Or, for "puzzle as address", hardcode the hash of the statement).

[0158] The locking script generated by following the above steps might be as follows:

[0159]

[0160] Where G represents the base point of the curve secp256k1, st is the target statement, is a verification script used to verify the solution to the challenge π. The verification script provided in the locking script depends on the application, i.e. the type of puzzle used, as described in more detail below. When the locking script is executed, it checks whether the candidate statement provided in the unlocking script matches the target statement of the unlocking script and verifies the challenge solution provided in the unlocking script.

[0161] 6.1.3 Generate unlock script

[0162] By performing the following steps, the candidate statement can be used And the secret witness w to generate the unlocking script:

[0163] 1. Let tx_dummy_sign be the dummy signature of the transaction SIGHASH serialization.

[0164] 2. Create nizk proof π

[0165] To ensure transaction integrity of the transaction fields, tx_dummy_sign is used as context information ctxt. This ensures that the proof provided in the unlocking script is associated with the fields of the transaction. It should be understood that other methods can be used to prove transaction integrity.

[0166] Collaborate to create nizk proofs if necessary. This is required when witnesses are spread across multiple parties - see Section 7.3 for an example.

[0167] 3. Includes context information, candidate statements, and nizk proofs, also referred to as challenge solutions in the unlocking script in this article.

[0168] The unlock script generated by following the above steps may be as follows:

[0169] [us]:=<π> <st><tx_dummy_sign>

[0170] Where π is the challenge solution, st is the candidate statement, and tx_dummy_sign is the context information (here is a dummy signature).

[0171] The query solution π is an element vector whose length depends on the application described below.

[0172] 6.2 Start the random oracle

[0173] In the examples given in this article, each group has p>2 128 order group, so the question space is set to This choice ensures a conservative security level of 128 bits to ensure the reliability of the Sigma protocol. Other orders can be selected. The random oracle function H is started as follows:

[0174]

[0175] By definition, RO maps a bit string x of arbitrary length into The values ​​are uniformly distributed (according to the ROM heuristic) in the hash function. It can be seen that the modular reduction step does not introduce any bias to the output of the hash function SHA256. This is because the size of the output byte array d:=SHA256(x) is exactly 256 bits and the modulo 2 reduction is applied. 128 (So ​​every point in the image of RO has two exactly identical pre-images).

[0176] An example random oracle script that generates a 128-bit challenge is as follows:

[0177] <x>[Random Oracle(128)]:=OP_SHA256<2 128 >OP_MOD

[0178] Another possibility is to generate a 160-bit challenge using the following (slightly more efficient) script:

[0179] <x>[Random Oracle(160)]:=OP_HASH160

[0180] The caveat of using a 160-bit challenge is that the challenge is 4 bytes longer than before. This may not be desirable for larger OR proofs. The challenge space is The random oracle is defined as:

[0181]

[0182] By adding the dummy signature of the spending transaction, tx_dummy_sign, to the front of the input of the RO, the dummy signature is bound to the proof provided in the unlocking script of the spending transaction, that is:

[0183]

[0184] in, It's a promise.

[0185] The digest d := SHA256(x) is interpreted as a little-endian integer and can be used to enable RO in the script. The prover must interpret the digest in the same way to ensure consistency (i.e., either party computes the same challenge). It should also be noted that if the prover uses little-endian byte order, then there is no need to implement reverse byte order in the script.

[0186] 6.3 Verify the known preimage

[0187] Next, we implement the algorithm described in Section 5.6.2 for a given group homomorphism Verify script The script can be thought of as being implemented in two steps: first recalculating the commitment, then checking the challenge.

[0188] Step 1 — Recalculate Commitment

[0189] The first step uses the target sentence st and the challenge solution provided in the unlocking script to recompute the commitment, where e is the target challenge, is the target challenge answer. Script The steps are as follows:

[0190] a. If it is unclear, derive the image point from the target sentence st

[0191] b. Extract the challenge e from π and calculate

[0192] c. Extract the answer from π And calculate

[0193] d. Calculate candidate commitments

[0194] Homomorphisms are instantiated on elliptic curves. Therefore, the group It is a p-order elliptic curve. It uses the Script interface of the elliptic curve algorithm. This article uses the following symbols:

[0195] [Add points]: Add two points (of the elliptic curve).

[0196] [Subtract points]: Subtract two points.

[0197] [Multiply by scalar]: Multiply a point by a scalar.

[0198] [MultiplyPbyscalar]: Multiply the hardcoded point P by a scalar.

[0199] [Are equal points]: Returns true if and only if the two points are equal.

[0200] [Negate point]: Returns the reciprocal of a point.

[0201] For any given elliptic curve homomorphism The Script interface is sufficient to compute the above steps (a)–(d). Homomorphic Function Depends on the application.

[0202] Step 2 - Check the query

[0203] The second step is to check whether the target challenge e embedded in the proof π is calculated correctly. is the commitment recomputed in step 1 (also referred to as the candidate commitment value in this article), let tx_dummy_sign be the dummy signature of the spend transaction, and let st be the candidate statement. Perform the following steps:

[0204] a. Cascade (Use opcode OP_CAT)

[0205] b. Execute the script [Random Oracle] in Section 6.2. This step recalculates the challenge e based on the public record x. * (also referred to herein as a candidate challenge).

[0206] c. Extract the target challenge e from the challenge solution π and check whether it is the same as the candidate challenge e * (Using OP_EQUAL) matches.

[0207] If the recomputed challenge matches the challenge extracted from the proof, the script pushes a 1 to the top of the stack. Otherwise it pushes a 0.

[0208] Candidate Question * It may also be referred to as a candidate hash value in this article.

[0209] 6.4 Verifying the "AND" Proof

[0210] s-original image knowledge relation The conjunction proof of is verified in exactly the same way as in the previous section. The only difference is that the script The hard-coded group homomorphism in is the composite See Section 5.4 for details.

[0211] 6.5 Verification of "OR" Proof

[0212] Non-interactive verifier [Σ OR -verifier] is very similar to the verifier in Section 6.3. The main difference is that the offset query o is based on all commitments Calculated:

[0213]

[0214] Then for all queries e i Enforcement (such as Figure 4b shown).

[0215] Step 1 — Recalculate Commitment

[0216] This is the script [Σ OR -verifier recompute commitment]. Input r pairs of statements / proofs (st1,π1),…,(st r ,π r ), where i = 1, ..., r, and perform the following steps:

[0217] 1. By inputting the i-th candidate sentence st i and the i-th challenge proof Run the script To reconstruct the i-th candidate commitment

[0218] As mentioned above, elliptic curve algorithms are used in implementing this step.

[0219] Step 2 - Check the query

[0220] set up Let r be the recomputed value in step 1 (i.e., the candidate commitment), let tx_dummy_sign be the dummy signature of the spending transaction, and let st i is a candidate sentence. OR -verifier check challenge] includes the following steps:

[0221] a. Cascade (Use opcode OP_CAT)

[0222] b. Execute the script [Random Oracle] in Section 6.1 on input x. This step recalculates the offset query o based on the public record x. * .

[0223] c. Inspection where e i Is a candidate challenge (using OP_ADD, OP_MOD, and OP_EQUAL).

[0224] If the candidate offset query o * and solve π from the query i The target query extracted from i If the two match, the script pushes 1 to the top of the stack. Otherwise, it pushes 0.

[0225] 7. Zero-knowledge puzzle examples

[0226] The previous sections introduced a modular framework that allows simple puzzles to be combined into arbitrarily complex puzzles. This is achieved via the Σ protocol, a set of public coin zero-knowledge proof systems that are three-round protocols and do not require a trusted setup. Specifically, the preimage Sigma protocol is described to prove (in zero-knowledge) group homomorphism: For the original image knowledge under In the case of elliptic curves, we show how to implement the non-interactive verifier of the preimage Sigma protocol as a locking script using the Script interface for elliptic curve algorithms. In addition, modularity can be achieved using verification AND / OR statements in Script.

[0227] The versatility of zero-knowledge puzzles can be demonstrated by the following three new payment methods. In these examples, transaction integrity techniques or injection techniques can be used to explicitly bind the spending transaction to the nizk proof π. It should be understood that more puzzles can be built using this Script framework.

[0228] The first application listed below is the ability to pay to a generic ECDSA public key P, which is a generalization of the standard P2PK puzzle. is an elliptic curve with base point G. The requirement to sign on the curve secp2561k1 (the opcode OP_CHECKSIG is hard-coded to this curve) can be omitted, and instead the verification is used to prove knowledge of the signing key w (with base G). The discrete logarithm of π DL It should be understood by those skilled in the art that the ECDSA signature algorithm can be used on many curves. Custom curves are instantiated on all FPGAs, not just on secp256k1. There are several reasons for custom curves:

[0229] a) Long-term transactions: Current P2PK UTXOs must be spent in no more than ten years. This is because public keys with 128 bits of security (such as those on curve secp256k1) can be brute-forced in less than ten years. A party may want their receiving address to have security greater than 128 bits. For example, curve secp384r1 and curve secp521r1 have security of 192 bits and 256 bits, respectively. P2GPK UTXOs may remain unspent for an arbitrary period of time, depending on the underlying curve.

[0230] b) Default public key: A party may hold a public key P that has been certified by a certification authority (CA) (or P is their favorite public key for authenticating themselves, not just in the blockchain environment). Such a public key may not be compatible with secp2561k1.

[0231] Verifying P2PK solutions is fast and cheap (in terms of fees and computational resources) thanks to the built-in opcode OP_CHECKSIG. The downside is that this technique produces larger scripts in exchange for higher security or compatibility.

[0232] The next two payment methods focus on increasing privacy for the spender.

[0233] The second application is the ability to pay to a group of public key holders. Any one of these holders can spend the funds, but no one, not even the rest of the group, will know who in the group redeemed the funds. This is accomplished with the OR proof used to prove knowledge of discrete logarithms.

[0234] The third application is the generalization to the threshold setting of the above payment method and the standard multi-signature puzzle (P2MS): the identity of the threshold subset that spends the funds is unknown to anyone except the members of the threshold subset. The technology of P2GP script is guided to this scenario using a combination of OR / AND proofs, and an off-chain agreement between members is designed to generate nizk proofs in a private manner.

[0235] 7.1 Paying to a Generic ECDSA Public Key

[0236] For a fixed generator G of the curve, all elliptic curve (ECDSA) public keys are of the form PK=xG. Instead of standard P2PK, a zero-knowledge puzzle for proving knowledge of a discrete logarithm x with base G can be used. Here, x can be considered to be a signature key. Specifically, the puzzle corresponds to a proof system with the following set of knowledge:

[0237]

[0238] For the instantiation of ECDSA, the p-order subgroup For a given generator G, the group homomorphism is The steps of the prover and verifier are detailed below.

[0239]

[0240] The prover is implemented off-chain and the context information is a virtual signature of the spending transaction. The instantiation of the function RO is described in Section 6.2.

[0241] The verifier follows the steps of the general algorithm template outlined in Section 5.6.2. The verifier is implemented on-chain using the Script interface for elliptic curve algorithms, among others. (See also step 1 of Section 6.3.) The resulting script is represented as

[0242] Figure 5 The on-chain steps implemented by the verification script of the first locking script 203A of the first transaction Tx1 (referred to herein as the challenge transaction) are shown. The first locking script 203A also includes a target statement.

[0243] The first unlocking script 202A of the second transaction Tx2 (referred to herein as the proof transaction) includes the challenge proof π, the candidate statement, and the context information part tx_dummy_sign. These components are generated off-chain by the challenger.

[0244] In step A, the candidate sentence is compared with the target sentence.

[0245] In step B, the candidate commitment A is computed using the proof π=(e,z) and the candidate statement provided in the first unlocking script * As step C, candidate commitment A * Together with the candidate statement and context information part tx_dummy_sign is used to calculate the candidate hash value (here is the candidate challenge e * ).

[0246] Finally, in step D, the candidate challenge is compared with the target challenge of the challenge.

[0247] If the candidate statement and the target statement as well as the candidate challenge and the target challenge are equal, the challenger knows the proof and is therefore eligible to unlock the UTXO of the first transaction Tx1.

[0248] 7.1.1 Generalized P2PK Script

[0249] If Alice 103a wants to ask Bob 103b for his public key To send 1 BSV, she would create a transaction with the following locking script:

[0250]

[0251] G secp256k1 Indicates the base point of the curve secp256k1. The corresponding unlocking script is:

[0252] [us_P2GPK]:=

[0253] <π DL ><G||PK><tx_dummy_sign>

[0254] in is a proof of knowledge of the signing key s, is a candidate sentence.

[0255] 7.1.2 Generalized P2PK Address

[0256] Similarly, a P2PKH address can be thought of as analogous to a locking script:

[0257] [ls_P2GPKH]:=

[0258] OP_DUP <G secp256k1 >OP_CHECKSIGVERIFY

[0259]

[0260] The address is defined as GPKHash:=RIPEMD160(SHA256(G||PK)). The unlocking script is [us_P2GPK].

[0261] 7.2 Private payment to the group

[0262] Payment to a set of public key holders can be achieved through the OR proof of DL relations. For a given set of public keys PK1, ..., PK r :

[0263]

[0264] All public keys are in the same group The steps of OR prover and OR verifier are as follows.

[0265] The prover implements the simulation described in Section 5.3 to derive each public key PK of the statement st i Target commitment value A i , where the witness x is not the key of the statement. In this way, the prover only needs to know a private key (the witness) to generate a valid unlocking script.

[0266] The validator then computes a set of corresponding commitment values ​​and computes the candidate offset value o based on these values. * The candidate offset values ​​may also be referred to as candidate hash values ​​in this article.

[0267]

[0268] As mentioned above, tx_dummy_sign represents a dummy signature for a spending transaction. The verifier writes It is implemented on the chain.

[0269] By requiring the challenge e implemented by the verifier in step 3 i The sum is equal to the offset value, and at least one of these challenges must be calculated correctly, that is, knowing the secret key x. Therefore, the verifier can prove that he has enough knowledge of the solution to be eligible to unlock the UTXO.

[0270] Figure 6 The on-chain steps implemented by the verification script of the first locking script 203B of the first transaction Tx1 (referred to herein as the challenge transaction) are shown. The first locking script 203B also includes a target statement. In this implementation, the statement includes the public key of each user.

[0271] The first unlocking script 202B of the second transaction Tx2 (referred to as the proof transaction in this article) includes a challenge proof π, a candidate statement, and a context information part tx_dummy_sign. These components are generated off-chain by the challenger. The challenge proof includes the challenge proof part, π i Corresponding to each of the keys locked by UTXO, each of the challenge proof parts includes a corresponding challenge part e i and the answer value z i .

[0272] In step A, the candidate sentence is compared with the target sentence.

[0273] In step B, use the proof π=(e1,z1,…,e r ,z r ) and the candidate statements provided in the first unlocking script calculate the candidate commitment A for each i=1, ..., r i * As step C, candidate commitment A i * Together with the candidate statement and context information part tx_dummy_sign is used to calculate the candidate hash value (here is the candidate offset o * ).

[0274] Finally, in step D, the candidate offset value is compared modulo 2 128 The sum of the target queries on the .

[0275] If the checks performed in step A and step D are found to be true, the challenger knows the proof and is therefore eligible to unlock the UTXO of the first transaction Tx1.

[0276] 7.2.1 Payment to group script

[0277] For example, to send 1 BSV to the swarm address, Alice 103a creates the locking script:

[0278]

[0279] The unlock script is:

[0280] [us_P2GP]:=<π rOR-DL > <G||PK1||…||PK r ><tx_dummy_sign>

[0281] The proof is The statement is

[0282] You can also pay to the group address hash:

[0283] GPKHash:=RIPEMD160(SHA256(G||PK1||…||PK r )).

[0284] 7.3 Private Payment to Threshold Group

[0285] In some cases, it is necessary to require that any subset below a threshold t of a set of public key holders can collectively redeem the UTXO without revealing which subset it is. This is both a generalization of the above-mentioned private payment to group script (P2GP) and a generalization of the standard multi-signature P2MS script.

[0286] For example, with a 2 / 3 threshold, for public key holders PK1, PK2, and PK3, the knowledge set is:

[0287]

[0288] The underlying AND homomorphism is Generated Very similar to the script outlined in Section 7.2, the only difference is that now and Operates on 2D vectors.

[0289] Figure 7 The on-chain steps implemented by the verification script of the first locking script 203C of the first transaction Tx1 (referred to herein as the challenge transaction) are shown in the case of a 2 / 3 threshold. The first locking script 203C also includes a target statement. In this implementation, the statement includes the public key of each user.

[0290] The first unlocking script 202C of the second transaction Tx2 (referred to herein as the proof transaction) includes the challenge proof π, the candidate statement, and the context information part tx_dummy_sign. These components are generated off-chain by the challenger. Figure 6 As shown in the example of , the challenge proof v includes a challenge proof part π corresponding to each of the keys locked by UTXO i .

[0291] In step A, the candidate sentence is compared with the target sentence.

[0292] In step B, use the proof π = (e 1,2 ,z 1,2 ,e 1,3 ,z 1,3 ,e 2,3 ,z 2,3 ) and the candidate statements provided in the first unlocking script calculate the candidate commitment A for each i=1,2,3 i * As step C, candidate commitment A i * Together with the candidate statement and context information part tx_dummy_sign, it is used to calculate the candidate hash value (here is the candidate offset value o * ).

[0293] Finally, in step D, the candidate offset value is compared modulo 2 128 The sum of the target queries on the .

[0294] If the checks performed in step A and step D are found to be true, the challenger knows the proof and is therefore eligible to unlock the UTXO of the first transaction Tx1.

[0295] 7.3.1 Private Payment to Threshold Group Script

[0296] The locking script (for the 2 / 3 threshold) is:

[0297]

[0298] The unlock script is:

[0299] [us]:=<π 3OR-2AND_DL ><2||3||G||PK1||PK2||PK3><tx_dummy_sign>

[0300] The proof is:

[0301]

[0302] 7.3.2 Create unlock script

[0303] If the user (key holder) and To redeem UTXO, they need to collaborate off-chain to generate proof π 3OR-2AND_DL The reason is that the witnesses of the real AND statement are and The discrete logarithm of x,x′. The threshold subset of values ​​the user wishes to save privately.

[0304] For example, for a 2 / 3 threshold, the statement includes three public keys belonging to three different users. Two of the three users need to collaborate to generate the proof. Each user knows their own signing key but does not want to share it with any other user. The protocol to create the unlocking script has three rounds.

[0305] One of the two users participating in the proof acts as a coordinator and receives the challenge e i and the answer z i , and generates the challenge solution that will be provided in the unlocking script 3OR-2AND_DL In the following example, the user Acting as a coordinator, user To users Provide their queries and answers.

[0306] Here are the steps:

[0307] 1. User start:

[0308] a. Randomly draw commitments sample

[0309] b. Send to user

[0310] 2. User For input x′ and received input Do the following:

[0311] a. Randomly draw commitments Sample.

[0312] b. Randomly select questions sample

[0313] c. Simulation proof (see section Error! Reference source not found.):

[0314]

[0315] d. Create an offset query:

[0316]

[0317] e. Calculation

[0318] f. Create answers

[0319] g. Send to user

[0320] 3. User For input and receive input Do the following:

[0321] a. Perform the following checks:

[0322] i. Check the simulation certificate Whether to verify.

[0323] ii. Check if the offsets are derived from serialized transactions, statements and commitments.

[0324] iii. Inspection and questioning Whether the sum is equal to the offset o (modulo 128).

[0325] iv. Inspection certificate Whether to verify.

[0326] b. Calculate the answer

[0327] c. Create unlocking script and proof:

[0328]

[0329] The above method is Figure 8 In this case, users Alice 103a, Bob 103b, and Charlie use public keys P A , P B and P C Funds are locked. Each user is able to spend using zk proofs for OR-AND relationships. Therefore, a zk proof proving knowledge of public key 1 and public key 2, or knowledge of public key 1 and public key 3, or knowledge of public key 2 and public key 3 can be used to unlock the UTXO of the challenge transaction.

[0330] exist Figure 8 In the example, Alice 103a and Bob 103b want to unlock UTXO. They need to generate a signature key sk to prove that they both know the signature key sk. A and sk B Alice 103a and Bob 103b act as provers of the OR-AND proof, collaborating in a way that does not reveal their private keys to the other party. In this article, Alice 103a is called the prover and Bob 103b is called the collaborator.

[0331] Used to prove that knowing sk A and sk B The AND relationship with Figure 4a The protocol in is similar, but in parallel: Alice 103a and Bob 103b send commitment A to the verifier A =aG、A B = bG, the verifier answers with challenge e, Alice 103a and Bob 103b answer with z A =a+e*sk A and z B =a+e*sk B Use the same challenge e to generate the answer z A and z B , only Alice 103a can generate z A (knowing her signing key), only Bob 103b can generate z B .

[0332] Alice 103a and Bob 103b collaborate to generate a challenge proof π in the following steps: Figure 8 shown.

[0333] In step 1a, Alice 103a creates her own target commitment A A , and sends the target commitment to Bob 103b in step 1b.

[0334] Then, in step 2a, Bob 103b creates his own target commitment A B (Also referred to as collaborator goal commitment A in this article c ). To generate his own target commitment, Bob 103b uses his own secret random value (also called the collaborator's secret random selection value r c ).

[0335] Since neither Alice 103a nor Bob 103b knows Charlie’s signature key sk C , so in step 2c, Bob 103b simulates the two methods used to prove that he knows the signature key sk A and sk C The proof of knowing the signature key sk B and sk C , π A,C and π B,C Proof.

[0336] According to the promise A A and A B 、Simulation proves π A,C and π B,C , Bob 103b derives the offset value o that the verifier should publish in the interactive version of the protocol (see Figure 4b )(step 2d), Bob 103b can derive the true challenge value e from it A,B (Step 2e) and derive your own answer z B (Step 2e).

[0337] In step 2g, Bob 103b will simulate and prove π A,C and π B,C 、My own promise B , offset challenge o and challenge value e A,B Sent to Alice.

[0338] Alice 103a checks the value received from Bob 103b (step 3a). That is, Alice 103a checks, among other things, whether the offset challenge o received from Bob 103b is derived from the transaction fields that Alice 103a is satisfied with. Alice 103a then uses the challenge value e A,B Export your own answers A (Step 3b).

[0339] Alice 103a now has all the data needed to create the OR-AND proof π, which will be included in the unlocking script (step 3c).

[0340] The protocol is generalized to the following m / n threshold. Let the subset of t users be A user in the subset of users (i.e., ) acts as a coordinator. After receiving all the commitments from other users in the subset, this user simulates the proof and creates an offset challenge. Then, Broadcast this information to other users who can check if the record is correct and, if so, calculate their own answer and send it back to the user who can create the unlocking script It should be noted that the size of the unlocking script is exponentially related to the number of users (specifically ), so if the threshold is very large, the size of the unlocking script will be prohibitively large.

[0341] Fig. 9 A generalized protocol for a 3 / n threshold is shown, where users Alice 103a, Bob 103b, and Charlie 103c contribute to the challenge proof. Alice 103a again acts as the coordinator, and Bob 103b and Charlie 103c act as collaborators.

[0342] In step 1a and step 1b, Bob 103b and Charlie 103c generate and calculate their own commitments respectively. Then, the collaborator sends his commitment to Alice 103a (step 2a and step 2b).

[0343] Alice 103a uses the received commitments of Bob 103b and Charlie 103c and her own commitment to simulate the proof part and generate an offset challenge (step 3). Alice 103a also generates a challenge value e.

[0344] Alice 103a then broadcasts the analog proof portion and the offset challenge (steps 4a and 4b), which Bob 103b and Charlie 103c check (steps 5a and 5b). Alice 103a may also broadcast the challenge value e, however, it should be understood that this value is determined based on the analog proof challenge and the offset challenge and is therefore not required.

[0345] If the collaborators are satisfied with the simulation proof and the offset value, they generate their own answer (steps 6a and 6b) and then send the answer to Alice 103a in steps 7a and 7b. The answer is sent only after the received value has been checked. B and z C , which ensures that a coordinator only provides his answer if he is satisfied with the transaction content. This way, a corrupt coordinator cannot change the output of a spend transaction (where funds are sent) to something of his own choosing.

[0346] Once Alice 103a receives Bob and Charlie’s answers, she generates the proof π that is included in the spending transaction.

[0347] 8. Alternative Embodiments

[0348] In each of the above implementations, the candidate statement (i.e., the statement provided in the unlocking script) is used to verify the proof. However, it should be understood that the target statement (i.e., the statement provided in the locking script) can also be used when verifying the proof. This is because the target statement and the candidate statement should be the same, which is verified in the script.

[0349] In some embodiments, the unlocking script does not include the candidate statement. In such embodiments, the target statement of the locking script is used to verify the proof, and the step of checking the candidate statement against the target statement is not implemented ( Figure 5 , Figure 6 and Figure 7 Step A) in each of the figures.

[0350] It should be understood that there is another way to verify the proof: convert the interactive Sigma protocol directly into a non-interactive protocol. The above method uses a "short challenge proof" where π = (e, z). Each of the above methods performs the following steps:

[0351] 1. Recompute the commitment A based on the statement st, the challenge e, and the answer z (implicitly using the verifier’s verification function).

[0352] 2. Check if the hash(statement,commitment) matches the challenge.

[0353] As an alternative, a "long challenge proof" can be used, where the long challenge proof is defined as π = (A, e, z). Verification methods include:

[0354] 1. Execute the test equation and accept if it passes. The test of the original image Sigma protocol is to check z*G=A(st e ).

[0355] The embodiments are mainly described from the perspective of the prover and the verifier. Generally, the prover and the verifier can take any form, such as a user, a user group, an organization, an autonomous device, a smart contract, etc. In some examples, the prover can take the form of Alice 103a, operating a computer device 102a, and being configured to execute a reference Figure 1 and Figure 2 is described as any action performed by Alice 103a. Similarly, the verifier may take the form of Bob 103b, operating a computer device 102b, and configured to perform the reference Figure 1 and Figure 2 Described as any action performed by Bob 103b. Alternative scenarios may also apply, i.e. the prover could be Bob 103b and the verifier could be Alice 103a.

[0356] 9. Further comments

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

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

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

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

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

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

[0363] Statement 1. A computer-implemented method for generating a challenge blockchain transaction, the method comprising:

[0364] Generate a first locking script for the challenge blockchain transaction, the first locking script comprising a target statement, and a verification script for verifying a challenge solution π provided in a first unlocking script proving the blockchain transaction, wherein the challenge solution π is a non-interactive zero-knowledge proof proving knowledge of a secret witness w; wherein the first locking script, when executed together with the first unlocking script, is configured to:

[0365] Calculate the candidate commitment value A based on the challenge solution π provided in the first locking script and the target statement and one of the candidate statements provided in the first unlocking script * ,

[0366] Using the candidate commitment value A * and one of the target sentence and the candidate sentence to calculate a candidate hash value,

[0367] Based on the candidate hash value, verify the challenge solution π, and,

[0368] verifying that the challenge solution π is provided in the attestation blockchain transaction; and,

[0369] The challenge blockchain transaction is provided to one or more nodes of the blockchain.

[0370] Statement 2. The method of statement 1, wherein the first locking script is further configured to compare the candidate statement with the target statement.

[0371] Statement 3. The method of statement 1 or 2, wherein the challenge solution π comprises a target challenge value e and a target answer value z.

[0372] Statement 4. A method according to any of the preceding statements, wherein the non-interactive zero-knowledge proof is provided by a one-way homomorphism function definition.

[0373] Statement 5. The method of statements 3 and 4, wherein the candidate commitment A * is defined as:

[0374]

[0375] Where z is the target answer value, e is the target challenge value, and w is the secret witness.

[0376] Statement 6. A method according to any of the preceding statements, wherein the candidate statement and the target statement include an elliptic curve point generator G and a public key PK associated with the witness.

[0377] Statement 7. The method of statements 5 and 6, wherein the function is defined as:

[0378]

[0379] The public key is defined as:

[0380]

[0381] The calculation formula for the candidate commitment is:

[0382] A * =zG-ePK.

[0383] Statement 8. A method according to any of the preceding statements, wherein the first locking script is further configured to verify a context information portion of the first locking script, wherein the context information portion is used to prove the integrity of the proof blockchain transaction.

[0384] Statement 9. The method of statement 3 or any dependent statement thereof, wherein the candidate hash value is a candidate challenge value e * , wherein the step of verifying the challenge solution π comprises verifying the candidate challenge value e * Compare with the target challenge value e.

[0385] Statement 10. The method of statements 8 and 9, wherein the candidate challenge value e * is to use the context information part, the target sentence and one of the candidate sentences, and the candidate commitment A * Calculated.

[0386] Statement 11. The method of statements 3, 6, and 7, wherein the candidate statement and the target statement further include at least one additional public key, each public key PK i And the corresponding secret witness w i associated with each witness w i The corresponding target challenge value e i and the target answer value z i , where each witness w is calculated using the following formula i The corresponding candidate commitment A * i :

[0387] A * i =z i Ge i PK i .

[0388] Statement 12. The method of statements 8 and 11, wherein the candidate hash value is a candidate offset. * , where the candidate offset o * is to use the corresponding candidate commitment A * i The target sentence and one of the candidate sentences and the context information portion are calculated for each corresponding candidate commitment in the target sentence and one of the candidate sentences.

[0389] Statement 13. The method of statement 12, wherein the step of verifying the challenge solution π comprises:

[0390] Based on the target challenge value e i Calculate the target offset o; and,

[0391] For the target offset o and the candidate offset o * Make a comparison.

[0392] Statement 14. A computer-implemented method for generating a proof blockchain transaction, the method comprising:

[0393] Randomly select a secret value r;

[0394] Calculate a target commitment A using the secret value r;

[0395] Compute a challenge solution v based on the target commitment A, the candidate statement, and the secret witness w, wherein the challenge solution π is a non-interactive zero-knowledge proof proving knowledge of the secret witness w;

[0396] generating a first unlocking script of the attesting blockchain transaction including the challenge solution π; and,

[0397] The attesting blockchain transaction is provided to one or more nodes of the blockchain.

[0398] Statement 15. The method of statement 14, wherein the first unlocking script further includes the candidate statement.

[0399] Statement 16. A method according to statement 14 or 15, wherein the challenge solution π includes a target challenge value e and a target answer value z, wherein the target challenge value e is a hash value derived from the target commitment A and the candidate statement, and wherein the target answer value z is calculated using the target challenge value e, the secret witness w and the secret value r.

[0400] Statement 17. The method of statement 16, wherein the first unlocking script further includes a context information portion, wherein the target challenge value e is also derived from the context information portion.

[0401] Statement 18. The method of statement 14, wherein the candidate statement comprises an elliptic curve point generator G and a plurality of public keys PK i , where the public key PK i Each public key in i Correspondingly, at least one secret witness w j It is known that at least one secret witness w i is unknown, wherein the method further comprises, for each unknown secret witness w i :

[0402] Randomly select the target challenge value e i ;as well as,

[0403] Based on the target challenge value e i , the elliptic curve point generator G and the public key PK i Simulate the query solution to part π i .

[0404] Statement 19. The method of statement 18, wherein the simulated query solution portion π i The steps include: for each unknown secret witness w i :

[0405] Randomly select simulated answer z i ;as well as,

[0406] Based on the target challenge value e i , the elliptic curve point generator G, the simulated answer z i and the public key PK i Calculate the target commitment A i ;

[0407] Wherein the challenge solution part π i Including the simulated answer z i , the simulated target commitment A i and the target challenge value e i .

[0408] Statement 20. The method of statement 19, wherein the first unlocking script further includes a context information portion, wherein the method further includes:

[0409] Based on the at least one unknown secret witness w i The corresponding query solution part π i , and the at least one known secret witness w j The corresponding target commitment A j And the simulated target commitment A i calculating a target offset o, wherein the target offset o is a hash value; and,

[0410] Based on the target offset o, the secret value r and the known witness w j Compute the at least one known secret witness w j The corresponding query solution part π j ;

[0411] The challenge solution π is obtained from the i The corresponding query solution part π i Exported.

[0412] Statement 21. The method of statement 14, wherein the candidate statement includes an elliptic curve point generator G and a plurality of public keys PK i , where the public key PK i Each public key in i Correspondingly, at least one secret witness w j It is known that at least one secret witness w i is unknown, where the target commitment A is with the known secret witness w j Related target commitment A j , wherein the method further comprises:

[0413] Commit the target to A j Send to collaborators;

[0414] Receive from said collaborator:

[0415] At least one simulation proves part π i , each simulation proves part π i is committed from the simulated target A i Exported,

[0416] Based on the collaborator's secret random selection of the value r c The target collaborator of the export commits A c ,

[0417] Based on the target commitment A j , the simulated target commitment A i , the collaborator's target commitment A c and the multiple public keys PK i The derived target offset value o,

[0418] a target challenge value e derived based on the target offset value o, and

[0419] Based on the target challenge value e and the collaborator's secret witness w c Exported collaborator answer value z c ;as well as,

[0420] Based on the target challenge value e and the known secret witness w j To calculate the target answer value z j ;

[0421] The challenge solution π includes the target answer value z j , the collaborator's answer value z c , the target challenge value e and the at least one simulation proof part π i .

[0422] Statement 22. The method of statement 14, wherein the candidate statement comprises an elliptic curve point generator G and a plurality of public keys PK i , where the public key PK i Each public key in i Correspondingly, at least one secret witness w j It is known that at least one secret witness w i is unknown, where the target commitment A is with the known secret witness w j Related target commitment A j wherein the method further comprises:

[0423] Receive a randomly selected value r based on the collaborator's secret c At least one target collaborator of the export commits A c , each target collaborator commits to A c Generated by the corresponding collaborators;

[0424] Generate at least one simulated proof part π i , each simulation proves part π i is committed from the simulated target A i And the target commitment A j and the target collaborator commits A c At least one of the commitments is derived;

[0425] Calculation based on the target commitment A j , the simulated target commitment A i , the at least one collaborator goal commitment A c and the multiple public keys PK i The derived target offset value o and target challenge value e;

[0426] Transmit the at least one simulation proof part π to each collaborator i and the target offset value o; and,

[0427] Receive from each collaborator a value based on the target offset value o and the collaborator secret witness w c The corresponding collaborator answer value z is exported c ;

[0428] The challenge solution π includes the target answer value z j , the collaborator's answer value z c , the target challenge value e and the at least one simulation proof part π i .

[0429] Statement 23. A computer device, the computer device comprising:

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

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

[0432] Statement 24. 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 22.< / x> < / x> < / st> < / pa>

Claims

1. A computer-implemented method for generating a challenge blockchain transaction, the method comprising: Generate a first locking script for the challenge blockchain transaction, the first locking script comprising a target statement and a verification script for verifying a challenge solution π provided in a first unlocking script proving the blockchain transaction, wherein the challenge solution π is a non-interactive zero-knowledge proof proving knowledge of a secret witness w, wherein the first locking script, when executed together with the first unlocking script, is configured to: Calculate the candidate commitment value A based on the challenge solution π provided in the first locking script and the target statement and one of the candidate statements provided in the first unlocking script * ; Using the candidate commitment value A * and one of the target sentence and the candidate sentence to calculate a candidate hash value; Verifying the challenge solution π based on the candidate hash value; and Verifying that the challenge solution is provided in the proof blockchain transaction; as well as The challenge blockchain transaction is provided to one or more nodes of the blockchain. 2 . The method of claim 1 , wherein the first locking script is further configured to compare the candidate statement with the target statement. The method according to claim 1 or 2, wherein the challenge solution π comprises a target challenge value e and a target answer value z.

4. A method according to any preceding claim, wherein the non-interactive zero-knowledge proof is provided by a one-way homomorphic function definition.

5. The method according to claim 3 and 4, wherein the candidate commitment A * is defined as: Where z is the target answer value, e is the target challenge value, and w is the secret witness.

6. A method according to any preceding claim, wherein the candidate statement and the target statement include an elliptic curve point generator G and a public key PK associated with the witness.

7. The method according to claim 5 and 6, wherein the function is defined as: The public key is defined as: The calculation formula for the candidate commitment is: A * =zG-ePK.

8. A method according to any of the preceding claims, wherein the first locking script is further configured to verify a context information portion of the first locking script, wherein the context information portion is used to prove the integrity of the proof blockchain transaction.

9. The method according to claim 3 or any claim dependent thereon, wherein the candidate hash value is a candidate challenge value e * , wherein the step of verifying the challenge solution π comprises verifying the candidate challenge value e *Compare with the target challenge value e.

10. The method according to claim 8 and 9, wherein the candidate challenge value e * is to use the context information part, the target sentence and one of the candidate sentences, and the candidate commitment A * Calculated.

11. The method according to claim 3, 6 and 7, wherein the candidate sentence and the target sentence further include at least one additional public key, each public key PK i And the corresponding secret witness w i associated with each witness w i The corresponding target challenge value e i and the target answer value z i , where each witness w is calculated using the following formula i The corresponding candidate commitment A * i : A * i =z i Ge i PK i .

12. The method according to claim 8 and 11, wherein the candidate hash value is a candidate offset o * , where the candidate offset o * is to use the corresponding candidate commitment A * i The target sentence and one of the candidate sentences and the context information portion are calculated for each corresponding candidate commitment in the target sentence and one of the candidate sentences.

13. The method according to claim 12, wherein the step of verifying the challenge solution π comprises: Based on the target challenge value e i Calculate the target offset o; as well as For the target offset o and the candidate offset o * Make a comparison.

14. A computer-implemented method for generating a proof blockchain transaction, the method comprising: Randomly select a secret value r; Calculate a target commitment A using the secret value r; Compute a challenge solution π based on the target commitment A, the candidate statement, and the secret witness w, wherein the challenge solution π is a non-interactive zero-knowledge proof proving knowledge of the secret witness w; generating a first unlocking script of the attesting blockchain transaction including the challenge solution π; as well as The attesting blockchain transaction is provided to one or more nodes of the blockchain. The method according to claim 14 , wherein the first unlocking script further comprises the candidate sentence.

16. A method according to claim 14 or 15, wherein the challenge solution π includes a target challenge value e and a target answer value z, wherein the target challenge value e is a hash value derived from the target commitment A and the candidate statement, and wherein the target answer value z is calculated using the target challenge value e, the secret witness w and the secret value r.

17. The method of claim 16, wherein the first unlocking script further comprises a context information portion, wherein the target challenge value e is also derived from the context information portion.

18. The method according to claim 14, wherein the candidate statement comprises an elliptic curve point generator G and a plurality of public keys PK i , where the public key PK i Each public key in i Correspondingly, at least one secret witness w j It is known that at least one secret witness w i is unknown, wherein the method further comprises, for each unknown secret witness w i : Randomly select a target challenge value e i ;as well as Based on the target challenge value e i , the elliptic curve point generator G and the public key PK i Simulate the query solution to part π i .

19. The method of claim 18, wherein the simulated challenge solution part π i The steps include: for each unknown secret witness w i : Randomly select simulated answer z i ;as well as Based on the target challenge value e i , the elliptic curve point generator G, the simulated answer z i and the public key PK i Calculate the target commitment A i ; The challenge solution part π i Including the simulated answer z i , the simulated target commitment A i and the target challenge value e i .

20. The method of claim 19, wherein the first unlocking script further comprises a context information portion, wherein the method further comprises: Based on the at least one unknown secret witness w i The corresponding query solution part π i , and the at least one known secret witness w j The corresponding target commitment A j And the simulated target commitment A i Calculate a target offset o, wherein the target offset o is a hash value; as well as Based on the target offset o, the secret value r and the known witness w j Compute the at least one known secret witness w j The corresponding query solution part π j ; The challenge solution π is obtained from the i The corresponding query solution part π i Exported.

21. The method according to claim 14, wherein the candidate statement comprises an elliptic curve point generator G and a plurality of public keys PK i , where the public key PK i Each public key in i Correspondingly, at least one secret witness w j It is known that at least one secret witness w i is unknown, where the target commitment A is with the known secret witness w j Related target commitment A j wherein the method further comprises: Commit the target to A j Send to collaborators; Receive from said collaborator: At least one simulation proves part π i , each simulation proves part π i is committed from the simulated target A i exported; Based on the collaborator's secret random selection of the value r c The target collaborator of the export commits A c ; Based on the target commitment A j , the simulated target commitment A i , the collaborator's target commitment A c and the multiple public keys PK i The derived target offset value o; A target challenge value e derived based on the target offset value o; as well as Based on the target challenge value e and the collaborator's secret witness w c Exported collaborator answer value z c ; as well as Based on the target challenge value e and the known secret witness w j Calculate the target answer value z j ; The challenge solution π includes the target answer value z j , the collaborator's answer value z c , the target challenge value e and the at least one simulation proof part π i .

22. The method according to claim 14, wherein the candidate statement includes an elliptic curve point generator G and a plurality of public keys PK i , where the public key PK i Each public key in i Correspondingly, at least one secret witness w j It is known that at least one secret witness w i is unknown, where the target commitment A is with the known secret witness w j Related target commitment A j wherein the method further comprises: Receive a randomly selected value r based on the collaborator's secret c At least one target collaborator of the export commits A c , each target collaborator commits to A c Generated by the corresponding collaborators; Generate at least one simulated proof part π i , each simulation proves part π i is committed from the simulated target A i And the target commitment A j and the target collaborator commits A c At least one of the commitments is derived; Calculation based on the target commitment A j , the simulated target commitment A i , the at least one collaborator goal commitment A c and the multiple public keys PK i The derived target offset value o and target challenge value e; Transmit the at least one simulation proof part π to each collaborator i and the target offset value o; as well as Receive from each collaborator a value based on the target offset value o and the collaborator secret witness w c The corresponding collaborator answer value z is exported c ; The challenge solution π includes the target answer value z j , the collaborator's answer value z c , the target challenge value e and the at least one simulation proof part π i .

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

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

Images