Blockchain-based commitment method

Abstract

A computer-implemented method for making a commitment to a message for which an outcome is to be determined. The method is executed by a first participant in a group of participants. The coordinator is associated with a coordinator public key. The method includes generating a first encrypted message by encrypting the first message with the coordinator public key, generating a first commitment value based on the first encrypted message, making the first commitment value available to the group of participants and the coordinator, and, upon determining that each other participant has made their respective commitment value available to the group of participants and the coordinator, making the first encrypted message and first disclosure data available to the group of participants and the coordinator, the first disclosure data enabling the first encrypted message to be obtained from the first commitment value.

Description

[Technical Field]

[0001] The present disclosure relates to methods of committing messages and methods of verifying outcomes to determine outcomes based on multiple committed messages, which may be used to implement voting or auctions and may utilize blockchain. [Background technology]

[0002] The online auction market is steadily expanding, generating billions of US dollars in revenue each year. The main challenge for online auctions is ensuring fairness and auditability while protecting the privacy of each bidder. At the same time, utility-driven blockchain technology is rapidly developing, bringing transparency and data integrity to many applications.

[0003] There are various types of auctions. One type is known as a first-price sealed-bid auction (FPSBA), in which bidders submit their bids in digitally sealed envelopes and send them to the auctioneer. Once the bidding phase is over, the auctioneer opens the envelopes and determines the highest bid. In an FPSBA, bids are kept private, encouraging bidders to bid according to the asset's valuation. It is assumed that the auctioneer will not disclose bidders' bids to any other bidders. Conducting the auction on a public blockchain increases transparency and immutability. Key properties of an FPSBA are: · Bid Privacy: Bidders cannot infer any information about other bids before submitting their own. Forward Privacy: Bidders cannot infer any information about unsuccessful bids. This assumes a quasi-honest auctioneer. · Public verifiability: After the results are published by the auctioneer, anyone can audit the validity of the results.

[0004] Other desirable properties include binding bids (bidders cannot change their minds after the bidding phase has ended) and financial fairness (honest bidders are financially rewarded if bidders or the auctioneer misbehave). Summary of the Invention [Means for solving the problem]

[0005] According to one aspect disclosed herein, there is provided a computer-implemented method for making a commitment to a message for which an outcome is to be determined, the method being executed by a first participant of a group of participants, a coordinator being associated with a coordinator public key, the method being executed by the first participant and including the steps of: generating a first encrypted message by encrypting the first message with the coordinator public key; generating a first commitment value based on the first encrypted message; making the first commitment value available to the group of participants and the coordinator; and upon determining that each other participant has made their respective commitment value available to the group of participants and the coordinator, making the first encrypted message and first disclosure data available to the group of participants and the coordinator, the first disclosure data enabling the first encrypted message to be obtained from the first commitment value.

[0006] According to one aspect disclosed herein, a computer-implemented method is provided for determining an outcome based on a respective message from each of a group of participants, the method being performed by the coordinator, wherein a coordinator is associated with a coordinator public key, the method including the steps of: obtaining a respective commitment value generated by each participant; obtaining a respective encrypted message generated by each participant, wherein each encrypted message is generated by encrypting the respective message with the coordinator public key; obtaining a respective disclosure data generated by each participant; using the respective disclosure data to verify, for each participant, that the respective commitment value corresponds to the respective encrypted message; determining, for each participant, a respective message by decrypting the respective encrypted message; and determining an outcome based on the respective message.

[0007] According to one aspect disclosed herein, there is provided a computer-implemented method for verifying a result determined based on respective messages from each of a group of participants, the method being performed by a verifier and comprising the steps of: obtaining a respective commitment value generated by each of the participants; obtaining a respective encrypted message generated by each of the participants, wherein each encrypted message is generated by encrypting the respective message with a coordinator public key; obtaining a respective disclosure data generated by each of the participants; and obtaining a result generated by the coordinator. For each participant, using the respective disclosure data to verify that the respective commitment value corresponds to the respective encrypted message, verifying the results, and making the results of the verification available to the group of participants and / or the coordinator.

[0008] Described herein is a blockchain-based first-price sealed-bid auction scheme that enhances privacy and public verifiability. The scheme can be implemented on any public blockchain that is leveraged to provide transparency, data integrity, and therefore auditability. The impossibility of double-spending in blockchain is exploited to prevent bid replay attacks. Furthermore, the scheme efficiently achieves non-repudiation for both bidders and auctioneers.

[0009] In some embodiments, an efficient instantiation of the scheme is constructed using ElGamal cryptography and bulletproofs. In some embodiments, recursive ZKSNARKs are used to reduce the number of proofs from 2n-2 to 1, where n is the number of bidders. Bulletproofs are short, non-interactive, zero-knowledge proofs that can convince a verifier that an encrypted value is within a specified range without revealing any information about the value.

[0010] It should be noted that embodiments can be used to implement an auction scheme, but more generally can be applied to any other use case where it is desirable for multiple parties to commit to a message or value (not necessarily monetary) without other parties knowing that value, at least until a certain point, e.g., until the outcome based on the committed message is disclosed.

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

[0012] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2]FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 illustrates a schematic diagram of an exemplary system for implementing a blockchain-based auction. [Figure 4] FIG. 1 illustrates a schematic diagram of another exemplary system for implementing a blockchain-based auction. [Figure 5] FIG. 1 is a diagram illustrating the algorithm of the ElGamal encryption method. [Figure 6] FIG. 1 illustrates the algorithm of the randomized SHA3 commitment scheme. [Figure 7] FIG. 1 illustrates the algorithm of the sealing encryption protocol. [Figure 8] FIG. 1 illustrates a SNARK algorithm for comparing two bids xw, xi encrypted in ElGamal ciphertexts ctw, cti. [Figure 9] FIG. 1 illustrates an auction-based algorithm using ElGamal cryptography and bulletproof. DETAILED DESCRIPTION OF THE INVENTION

[0013] 1.Seal encryption The embodiments described herein can be used to implement auctions, voting, or any other scheme that requires parties to commit to a message (e.g., a value), where the message cannot be subsequently changed or contested, and where outcomes can be determined based on the committed message. Furthermore, to protect privacy, messages can be disclosed only to selected parties.

[0014] FIG. 3 illustrates an exemplary system 300 for implementing some embodiments described herein. The system 300 includes one or more participants (referred to herein as bidders) 301, a coordinator (referred to herein as an auctioneer) 302, and a verifier (referred to herein as an auditor) 303. While only one bidder 301 is shown in FIG. 3, in general, the system 300 may include any number of bidders 301. The system 300 may also include one or more blockchain nodes 104 of a blockchain network 106. Note that the use of a blockchain 150, while advantageous for reasons detailed below, is optional.

[0015] Each bidder 301 may be an individual user, a group of users, an organization (e.g., a business), etc. Each bidder 301 operates a respective computing device and may be configured to perform any of the actions described below performed by Alice 103a and / or Bob 103b. Similarly, the auctioneer 302 may be an individual user, a group of users, an organization (e.g., a government agency or a bank), etc. The auctioneer 302 operates a computing device and may be configured to perform any of the actions described below performed by Alice 103a and / or Bob 103b. Similarly, the auditor 303 may be an individual user, a group of users, an organization (e.g., a regulatory agency), etc. The auditor 303 may be a trusted third party. The auditor 303 operates a computing device and may be configured to perform any of the actions described below performed by Alice 103a and / or Bob 103b.

[0016] Figure 4 also illustrates an exemplary system 400 for implementing some embodiments described herein. The system 400 illustrated in Figure 4 is similar to the system 300 illustrated in Figure 3, except that in this example, the auditor 303 is not a separate entity. Instead, the actions of the auditor 303 are implemented by a self-executing smart contract stored on the blockchain 150.

[0017] Although the embodiment is described primarily with respect to actions performed by the first bidder 301, it will be understood that this is purely for illustrative purposes and that each bidder 301 is configured to perform equivalent actions.

[0018] The first bidder 301 decides on a first message to commit. The first message may be any type of data and does not necessarily have to be a communication, although it is not excluded from being a communication. In some examples, the first message includes an offer (e.g., a bid) or a vote.

[0019] A first bidder 301 encrypts a first message to generate a first encrypted message. The encryption of the first message is based at least in part on a public key controlled by the auctioneer 302. In other words, the auctioneer knows the corresponding private key and can therefore decrypt the message encrypted with the public key. Any suitable encryption method may be used, such as RSA encryption or ElGamal encryption.

[0020] The first bidder 301 generates a first commitment value based on the first encrypted message. Any suitable type of commitment can be used, such as a hash function (e.g., a salted hash, a randomized hash, e.g., randomized SHA3), a Pedersen commitment, etc. In some examples, each bidder 301 has a respective commitment key, and the commitment is based on the commitment key. More generally, the commitment value is a value that can be used to verify that the first bidder 301 committed to the first encrypted message, but does not itself reveal the first encrypted message. For example, the message can be input into a hash function to produce the same hash value, so the hash value is a commitment to the message, but the hash value itself does not reveal any information about the message.

[0021] The first bidder 301 publishes the first commitment value so that it is accessible to other bidders 301 and the auctioneer 302. Publishing the first commitment value may include submitting the first commitment value to the blockchain 150 or to another publicly accessible resource, such as a web page stored on the internet. In some examples, publishing the first commitment value may include broadcasting the first commitment value to the other bidders 301 and the auctioneer 302.

[0022] The first bidder 301 determines that each of the other bidders 301 has published their respective commitment values. This may be done by monitoring a public resource (e.g., a blockchain) for commitment values ​​from the other bidders 301 or by receiving an indication from the auctioneer 302 that the other bidders 301 have submitted commitment values. In some examples, the first bidder 301 may receive the other commitment values ​​directly from the other bidders 301.

[0023] After each of the other bidders 301 publishes their respective commitment values, the first bidder publishes a first encrypted message and a first opening (also referred to as first disclosure data). The opening data / disclosure data can be used to determine the first encrypted message from the first commitment. Those skilled in the art will be familiar with concepts such as opening. The first encrypted message and the first opening can be published together or separately. The first encrypted message and the first opening can be published in any of the ways described above in connection with the first commitment value.

[0024] If blockchain 150 is used to publish the first commitment value, the first encrypted message, and the first opening, the transaction that includes the first encrypted message (and optionally the first opening) can reference the transaction that includes the first commitment value. For example, the transaction that includes the first encrypted message (and optionally the first opening) can include an input that consumes an output of the transaction that includes the first commitment value and / or can include a transaction identifier of the transaction that includes the first commitment value.

[0025] In some examples, the commitment transaction (i.e., the transaction that includes the first commitment value) may reference a UTXO controlled by the first bidder 301. In these examples, the first commitment value may be further based on the transaction identifier of the transaction that includes the referenced UTXO.

[0026] We now turn to the actions taken by the auctioneer 302. The auctioneer 302 collects the commitment values ​​provided by each bidder 301. This may involve receiving the commitment values ​​directly from the bidders 301 or obtaining the commitment values ​​from a publicly accessible resource such as the blockchain 150. The auctioneer 302 similarly collects a pair of encrypted messages and openings from each bidder 301.

[0027] The auctioneer 302 uses the opening provided by a given bidder 301 to verify that the commitment value provided by that bidder 301 is a commitment to an encrypted message provided by the same bidder 301.

[0028] The auctioneer 302 uses its public key to decrypt the encrypted message and determine the corresponding plaintext message. An outcome (i.e., result) is then determined based on the decrypted message. In some examples, if the commitment value does not correspond to the encrypted message, the corresponding decrypted message is not used to determine the outcome.

[0029] The form of the result varies depending on the use case. In some examples, the result can be one of the respective messages. For example, if the messages are bids (or values ​​in general), the result can be the highest or lowest bid (or value). The result can be associated with one of the messages; that is, the result can be linked to one of the messages rather than explicitly containing it. In some examples, the result contains or is linked to multiple messages. In the case of a vote, the result can be the outcome of the vote, for example, a decision or a winning candidate.

[0030] The auctioneer 302 may publish the results, for example, to the blockchain 150. In some examples, the auctioneer 302 may broadcast the results to the bidders 301.

[0031] The auctioneer 302 can generate a proof (an "outcome proof" or "result proof") that proves that an outcome corresponds to a particular message. The proof may be a zero-knowledge proof. Exemplary proofs are described below in Section 2, any of which may be used to generate the result proof. The auctioneer 302 can publish the result proof, for example, to the blockchain 150.

[0032] Similarly, the auctioneer 302 can generate one or more comparison proofs that prove that each but one of the messages is not a result, i.e., that one of the messages is the "best" or "winning" message, i.e., the highest or lowest bid. That is, each comparison proof compares a given non-winning message with the winning message. Each comparison proof may be a zero-knowledge proof. As described in Section 2 below, each proof may utilize a bulletproof. The auctioneer 302 can publish the comparison proofs, for example, to the blockchain 150.

[0033] In some examples, rather than publishing multiple comparison proofs, the auctioneer 302 may generate a single comparison proof for all messages and publish the single comparison proof, for example, to the blockchain 150. The single proof may be a recursive SNARK and may be generated as described in Section 2 below.

[0034] In some use cases, the auctioneer 302 may offer something in return to the bidder 301 who submits a "win" message, for example a good or service such as an artwork. In some examples, this is contingent on the auditor 303 verifying the data submitted by the bidder 301 and / or the auctioneer 302.

[0035] The auditor 303 performs some of the same actions performed by the auctioneer 302, such as obtaining bidder commitment values, encrypted messages, and openings. The auditor 303 obtains data in any suitable manner, for example, from a public resource (e.g., blockchain 150), bidders 301, auctioneer 302, etc. The auditor 303 also obtains the results published by the auctioneer 302. The results can be obtained directly from the auctioneer, from bidders 301, or from a public resource such as blockchain 150.

[0036] The auditor 303 is responsible for verifying the commitments published by the bidders and the results published by the auctioneer 302. The auditor 303 uses the opening to verify that each bidder's commitment value corresponds to that bidder's encrypted message. The auditor 303 also verifies that the results are correct. The auditor 303 then publishes the verification results (e.g., confirms that the results are correct). The verification results may be sent directly to the bidders 301 and / or the auctioneer 302, or may be published on the blockchain 150 or an alternative public resource.

[0037] In some examples, auditor 303 obtains one or more proofs to verify the results generated by auctioneer 302. The proofs generated by auctioneer 302 are described above. Details of example proofs are described in Section 2 below.

[0038] It should again be noted that the embodiments are described in terms of an auction, purely by way of example, and the terms bidder, auctioneer, and auditor may be interchanged throughout with participant, coordinator, and verifier.

[0039] 2. Revisiting verifiable sealed-bid auctions on the blockchain 2.1 Assumptions In this section, we first describe the security model of FPSBA, and then describe the building blocks used to construct the scheme.

[0040] 2.1.1 Auction Model This protocol is a sealed-bid auction under the quasi-honest auctioneer model and satisfies the following properties: · Bid Privacy: Bidders must not be able to infer any information about other bids. Forward Bid Privacy: In a semi-honest model, bid privacy should be maintained even when results are made public, and bidders should not give up privacy to prove their honest behavior. · Binding bids: Once a bid is committed to the blockchain, a bidder cannot change their mind and bid a different amount. Publicly verifiable accuracy: Anyone looking at the blockchain should be able to be confident that the winning bidder is who the auctioneer claims they are. · Financial fairness: A dishonest bidder or auctioneer should be financially penalized. Non-interactive: The only communication between the auctioneer and the bidders is when they publish their bids and the results of the auction. No other interaction is required, and in particular the bidders are not involved in the calculation of the results or in the public verification of the method.

[0041] An auction is said to be quasi-honest if the auctioneer can collude with the bidders without affecting the outcome. In our model, bid privacy is maintained even if bidders are required to prove their honesty. This property is trivial in our case, since the honesty of bidders is verifiable by public factors. We emphasize that this privacy consideration is novel in practical auction schemes.

[0042] Building Blocks: To build our auction protocol, we use cryptographic primitives such as commitments, encryption, and succinct non-interaction arguments of knowledge (SNARKs). We formally describe these schemes in the following sections.

[0043] 2.1.2 Public Key Cryptography Encryption method E is described by four PPT algorithms (Setup, KeyGen, Encrypt, Decrypt). Setup(1 λ ) where λ is a security parameter and generates the global parameters param of the scheme. ·KeyGen(param) outputs a pair of (public) encryption key pk and (private) decryption key sk. ·Encrypt(pk,M;ρ) outputs ciphertext C for plaintext M under encryption key pk using randomness ρ. ·Decrypt(sk,C) outputs M, or ⊥, encrypted in ciphertext C.

[0044] While our method for achieving verifiable auctions is general, we demonstrate specific instantiations using randomized hash commitments, ElGamal encryption, and bulletproof zero-knowledge arguments.

[0045] 2.1.3 Commitment Commitments allow users to commit without revealing values, but without the ability to change their mind later. Commitments are composed of these algorithms (see also Figure 5). SetupCom(1 λ ) generates the system parameters param according to the security parameter λ. ·KeyGen(param) generates the commitment key ck. · Commit(ck,m;r) generates a commitment c and opening data δ for an input message m∈M using a random coin r←R. VerCom(ck,δ,c,m;r) outputs 1 if c is a commitment of m with randomness r for commitment key ck, along with opening data δ.

[0046] Such a commitment scheme must have both the opacity property, that is, not leak any information about m during the commit phase, and the binding property, that is, not open to two different messages during the decommit phase.,The commitment scheme used in our implementation is the randomized SHA3 shown in,Figure 6.

[0047] 2.1.4 SNARKs and Bulletproofs fixed finite fields

number

number

number

[0048] A zkSNARK is complete because Verify always satisfies the input (x; y) ∈ R C If we accept the proof π generated by Prove for |π|=O λ In the case of (1), it is simple and the setup takes 0 λ If it runs on (|x|), then we have a succinct verifier (also called perfectly succinct). If no information about the witness w leaks from the proof, then it is zero-knowledge.

[0049] Soundness of knowledge: For soundness (of knowledge), we must be able to efficiently extract a witness from any (possibly dishonest) prover Prove* that outputs an accepted pair (x,π). More formally, for every polynomial-time opponent Prove*, we must be able to extract a witness from a polynomial-time extractor Extract Prove*and therefore, for every sufficiently large security parameter λ,

number

[0050] 2.1.5 Bulletproofing A Bulletproof is a SNARK that proves interval membership x∈[0,2n). The public input is the commitment key

number

number

number

[0051] The high-level concept is to prove with zero knowledge that the following constraints are satisfied:

number

[0052] In the above, 2 n is 2 n-1 are all powers of 2 up to

number

number

number

number

number

[0053] Soundness. The soundness of Bulletproof relies on the assumption that there is no known relationship between group elements g, g, and h. Recall g is the vector Pedersen key used to commit to the internal message in the BP proof and verification algorithm, and g and h are related by the relationship R. bp The Pedersen key (part of the public instance) used to commit to x in . Whether the results of an auction scheme are publicly verifiable correctness depends on the following theorem.

[0054] Theorem 1. If there is no known relationship between group elements g, g, and h, then pk bp =vk bp =g's BP is intellectually sound.

[0055] For more information on Bulletproofs, see Bunz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell, G.: Bulletproofs: Short proofs for condential transactions and more. In: 2018 IEEE Symposium on Security and Privacy. pp. 315-334. IEEE Computer Society Press, San Francisco, CA, USA (May 21-23, 2018). https: / / doi.org / 10.1109 / SP.2018.00020.

[0056] 2.2 Method Description In this section, we describe the details of the auction method. The interactions between the blockchain and the parties involved in the auction are framed in Figure 3 and Figure 4. The former describes the interactions in an environment without automated auction validation, while the latter describes the interactions in an environment with automated auction validation.

[0057] The auction protocol distinguishes between four distinct phases: setup, bidding, results, and public validation.

[0058] 2.2.1 Setup Phase In this phase, the auctioneer begins the auction with a public statement declaring the auction items, the auction duration, the group generator, the auctioneer's public key, and other cryptographic parameters.

[0059] 2.2.2 Bidding Stage To allow bidders to place bids, we constructed a new protocol, referred to herein as "sealed encryption" and illustrated in Figure 7, which is the sole concern and can be used in any protocol that requires a message to be publicly committed but discloses this message to a selected recipient. In this auction, the selected recipient acts as the auctioneer.

[0060] During the bidding phase, bidders follow the commit and submit steps of the sealing encryption protocol: in the former, bidders encrypt their bid and commit this ciphertext to the blockchain, and in the latter, they publish the ciphertext and the initiation of their commitment.

[0061] 2.2.3 Results Phase At this stage, the auctioneer decrypts all cryptograms and verifies that they were correctly committed to the blockchain. w Identify, then, x w ct w and for each unsuccessful bid x i Regarding "x w >x i " (a total of N-1 comparison proofs). Finally, the auctioneer publishes the proof and the winning bid on the blockchain. Below we explain how these proofs can be generated when using ElGamal cryptography.

[0062] Proof of correct decryption. This is a proof of equal discrete logarithms. Let pk be the auctioneer's ElGamal public key. A =h=g skA and the ElGamal ciphertext is

number

number

number

[0063] Comparison proof. The auctioneer compares the ElGamal ciphertext ct for each i≠w. w =(d w ,e w ) encrypted bid x w But, ct i =(d i ,e i ) encrypted bid x i We need to prove that the bid comparison is greater than B:=2. The bid comparison reduces to an interval membership check, i.e., some fixed bound B:=2. n For ≦p / 2, x w , x i , Δ i :=(x w -x i ) mod p∈[0,B). NP relation R for bidding comparison cmp is as follows:

number

[0064] Using Bulletproofs as building blocks. As mentioned in Section 2.1.5, Bulletproofs use Pedersen Commitments as public inputs.

number

number

number

[0065] The above formula means that the auctioneer receives the ciphertext cti=(d i ,e i ) and the private key sk A The ciphertext is decrypted using i ) is valid in the range [0,2 n ) can be proved by bulletproof. Since ElGamal is an additive homomorphism, the auctioneer can prove that the difference Δ i The ciphertext of

number

[0066] Proof of correct auction results. This proof is an N-1 comparison proof containing two bullet proofs.

number

[0067] 2.2.4 Public Verification In either case, an auditor, which can be implemented as an automated contract, verifies the correct behavior of each party in the auction. This auditor verifies the correct computation of proofs, and the correct computation of commitments and cryptograms. Incorrect proofs or missing proofs for valid commitments and cryptograms imply that the auctioneer is dishonest. Incorrect commitments imply that the bidders are dishonest. If none of this occurs, the auction is valid, the winning bidder wins the item, and receives an amount x w Pay.

[0068] 2.2.5 ElGamal and Bulletproof Implementations In our implementation, we choose the commitment as a random hash, which means δ = s. Linking a commitment to a bidder requires a mechanism to authenticate the bidder and to publish the commitment on the blockchain. In our scheme, both of these aspects are handled by including the commitment in a transaction that consumes an unspent transaction outpoint (UTXO) owned by the bidder. Furthermore, since each UTXO can only be spent once on the public blockchain, a reference to this UTXO is included in the commitment to avoid replay attacks. Figure 9 shows our implementation of the auction.

[0069] 2.3 Reducing the number of comparison proofs In the approach described in Section 2.2, the auctioneer must generate N-1 comparison proofs, one for each non-winning bidder. In this section, we describe a general approach that leverages recursive SNARKs to generate a single comparison proof that proves N-1 comparisons. Note that by reducing the number of comparison proofs, the data uploaded to the blockchain is minimized, simplifying the process of verifying the correctness of the auction results.

[0070] This technique can use any encryption scheme E for which it is possible to prove the correct key pair generation and correct decryption with zero knowledge (i.e., without revealing the decryption key). The high-level idea is to have a comparison predicate C that evaluates to true if and only if cmp The purpose is to define x w >x i and x w is the winning bid, and x i is any other bid. ct i is the decryption key sk A Using x i is correctly decoded. ·sk A is the auctioneer's public key pk A is the decryption key corresponding to

[0071] The informal description above corresponds to the predicate we want to enforce recursively. cmp is extended by logic that implements the recursive SNARK verification algorithm. This circuit can be used to verify some other ciphertext ct (i-1) and bid x (i-1) C against cmp Proof π that proves the satisfiability of cmp,i-1 as an additional input and prove π cmp,i-1 Check that is valid.

[0072] So far, we have explained how comparison proofs can be recursive. Next, we consider the cryptograms posted to the blockchain during the bidding phase.

number

[0073] Sequential recursion. For simplicity, N-1=2 in the following d Assume that: 2 d The ciphertexts are arranged as leaves of a Merkel tree, and the root is given as the public input. cmp An additional gadget is added to , which takes the root of the tree as public input and the Merkel proof of the i-th leaf as private input. This uses the Merkel proof to prove that ct i This approach has the drawback that proof generation is sequential. Therefore, the auctioneer must ensure that π cmp,i to π cmp,i-1 cannot be generated at the same time.

[0074] Parallel recursion, where N-1=2 d To enable batch proof generation, we assume that the ciphertext is a 2-byte integer of a Merkel tree of depth d-1. d -1 root node. Let the hash of node i be h i =Hash(ct i ,h i,0,h i,1 ), where h i,b represents the hash of the two children of node i. Then, C cmp The additional gadget uses the hash h as public input. i and takes as private input two child ciphertexts, two child hashes, and four grandchild hashes. This forces correct hash generation. The drawback to the traditional approach is that it requires a recursive circuit C (rather than verifying a single proof as in sequential recursion). cmp However, note that to generate a proof at layer k of the tree, the recursive prover only needs two proofs from the previous layer k-1, and all proofs at the same layer can be parallelized. Therefore, generating a proof takes 2 (d-1) ,2 (d-2) It can be parallelized with batches of size ,...,2.

[0075] 3. Exemplary System Overview A blockchain is a form of distributed data structure in which copies of the blockchain are maintained and distributed across multiple nodes in a decentralized peer-to-peer (P2P) network (hereafter referred to as the "blockchain network"). A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence that may span one or more blocks and traces back to one or more coinbase transactions. Coinbase transactions are discussed below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often called "mining," in which multiple nodes compete to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, verified pending transactions awaiting inclusion in a new block on the blockchain. Note that a blockchain may be pruned at some nodes, and block publication can be achieved by publishing only the block header.

[0076] Transactions in a blockchain may be used for one or more of the following purposes: to transfer digital assets (i.e., some digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to time-order index pointers. Blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow for the storage of additional user data or indexes to data within a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, allowing for the incorporation of increasingly complex data. For example, a blockchain may be used to store electronic documents, audio data, or video data.

[0077] In an “output-based” model (sometimes called a 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 specifying the amount of a digital asset resulting from an ongoing series of transactions. A spendable output is sometimes called a UTXO (or “unspent transaction output”). An output may further include a locking script that specifies the conditions for the output’s future redemption. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Consider a pair of transactions, called a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0078] In such a model, when a second target transaction is submitted to the blockchain network and propagated and recorded in the blockchain, one of the validity criteria applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another valid transaction that preceded it. Any node that determines that the target transaction is invalid according to either of these conditions will not propagate the transaction (to register an invalid transaction as a valid transaction, or in some cases, to register an invalid transaction) and will not include it in any new block recorded in the blockchain.

[0079] Another type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of a transaction that precedes it in the past chain of transactions, but rather by referencing absolute account balances. The current state of all accounts is stored and constantly updated by nodes separately from the blockchain.

[0080] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 (often referred to as "miners") that 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 also be arranged as a nearly complete graph. Thus, each blockchain node 104 is tightly connected to other blockchain nodes 104.

[0081] Each blockchain node 104 includes a peer computer device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory units using one or more storage media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0082] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, data may be pruned from the blockchain 150, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses a particular transaction protocol throughout.

[0083] A blockchain node 104 may be configured to forward a transaction 152 to other blockchain nodes 104, thereby propagating the transaction 152 throughout the network 106. A blockchain node 104 may be configured to create a block 151 and store respective copies of the same blockchain 150 in its memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid, and the node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0084] For a given current transaction 152j, each input contains a pointer referencing the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the current transaction 152j. Spending or redemption does not necessarily mean the transfer of a financial asset, although that is certainly one common use. 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 the ordered set 154 or any block 151. While a previous transaction 152i does not necessarily need to exist when the current transaction 152j is created or submitted to the network 106, the previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, and not necessarily to a point of creation or transmission in a temporal sequence, and therefore does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i may also be referred to as an antecedent transaction or a predecessor transaction.

[0085] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or an entire data center, although in principle any blockchain node 104 could take the form of a user terminal or a group of networked user terminals.

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

[0087] A given blockchain node may be configured to perform one or more of the following: validating transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node may specialize in a particular operation. For example, a node 104 may focus on validating and propagating transactions or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0088] Also connected to the network 101 are computer devices 102 of multiple parties 103 that act as consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and payees in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or payees. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0089] Some or all of the parties 103 may be connected as part of another network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not fulfill the roles required of blockchain nodes. Instead, each party 103 may interact with, and thereby utilize, the blockchain 150 by connecting to (i.e., communicating with) the blockchain network 106. For illustrative purposes, two parties 103 and their respective devices 102 are shown: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that there may be many more such parties 103 and their respective computer devices 102 present and participating in the system 100, but these are not shown for convenience. Each party 103 may be an individual or an entity. For illustrative purposes only, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to herein as Bob, although it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

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

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

[0092] The client application 105 includes at least a "wallet" functionality, which has two main functions: first, to allow each party 103 to create, approve (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150; and second, to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves reconciling the amounts that belong to that party as defined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0093] While various client functionality may be described as being integrated into a given client application 105, it should be noted that this is not necessarily limiting; instead, any client functionality described herein may be implemented in a suite of two or more different applications, for example, interfacing via an API or one being a plug-in to the other. More generally, client functionality may be implemented at the application layer, or at a lower layer, such as an operating system, or any combination thereof. While the following description is given in terms of a client application 105, it will be understood that this is not limiting.

[0094] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality 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 respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides transaction authenticity in part through its public visibility). The wallet functionality of each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward the transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to one another, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

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

[0096] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as described above, data fields in an account-based transaction may point to a previous transaction, which is equivalent to an input in an output-based transaction referencing the outgoing point of the previous transaction. Thus, both models allow for linking between transactions. As another example, an account-based transaction includes a "recipient" field (which specifies the receiving address of the account) and a "value" field (which may specify the amount of a digital asset). The recipient and value fields are equivalent to the output of an output-based transaction and can be used to assign the amount of a digital asset to a blockchain address. Similarly, account-based transactions have a "signature" field that contains the transaction signature. The signature is generated using the sender's private key and verifies that the sender approved the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the transaction signature. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. In an account-based blockchain, a "smart contract" refers to a transaction that includes a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by a transaction) that satisfy one or more conditions defined by the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions.Thus, in some instances, smart contracts can be thought of as equivalent to locking scripts for output-based transactions, which can be triggered by subsequent transactions to check whether one or more conditions defined by the locking script are met by the inputs of the subsequent transaction.

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

[0098] In a 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) that can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which it came. The transaction data structure may also include a header 201 that may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0099] Suppose Alice 103a wishes to create transaction 152j to send an amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked for Alice in the output 203 of the previous transaction 152i in the sequence and sends at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 could refer to any previous (i.e., preceding) transaction whose unspent output 203 is still locked for Alice.

[0100] As used herein in the context of a sequence of transactions, the terms “predecessor” and “successor” refer to the order of transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transactions. They may also be interchanged with “predecessor” and “successor,” or “predecessor” and “descendant,” “parent” and “child,” etc. This does not necessarily refer to the order in which transactions are created, sent to the network 106, or arrive at any blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or “child”) that points to a predecessor transaction (predecessor transaction or “parent”) is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to await its parent, depending on the node protocol and / or node behavior.

[0101] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be valid and therefore for the UTXO to be successfully redeemed.

[0102] A locking script (aka 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 "script" (capital S) used by blockchain networks. A locking script specifies what information is needed to consume a transaction output 203, for example, requirements for Alice's signature. The locking script appears in the transaction's output. An unlocking script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script's criteria. For example, it might contain Bob's signature. The unlocking script appears in the transaction's input 202.

[0103] So, in the illustrated example, UTXO0 in Tx0's output 203 must have Alice's signature Sig P in order to redeem UTXO0 (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A ]. [Checksig P A ] contains Alice's public key P from her public-private key pair. A, a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., by transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that contains Alice's cryptographic signature, which is created by Alice applying the private key of her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that Alice needs to sign to provide a valid signature may be defined by a locking script, a node protocol, or a combination of these.

[0104] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (which may include one or more criteria).

[0105] Note that script code is often expressed generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in a scripting language. As an example, OP_RETURN is an opcode in a scripting language that, when preceded by OP_FALSE at the beginning of a locking script, creates an unusable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

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

[0107] A locking script is sometimes referred to as a "scriptPubKey," which typically refers to the fact that each transaction contains the public key of the party being locked. An unlocking script is sometimes referred to as a "scriptSig," which typically refers to the fact that it provides the corresponding signature. However, more generally, in all uses of blockchain 150, it is not required that the conditions for a UTXO to be redeemed include authenticating the signature. More generally, any condition or conditions can be defined using a scripting language. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0108] 5. Other findings Other variations or uses of the disclosed techniques will be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

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

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

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

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

[0113] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and general embodiments may use any type of suitable consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-age. As a specific example, proof-of-stake uses a randomization process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes may lock tokens for a certain period of time to gain the opportunity to become a validator. Generally, the node that has locked the largest stake for the longest period of time is most likely to become the next validator.

[0114] It will be understood that the above embodiments have been described by way of example only. More generally, there may be provided a method, apparatus or program according to one or more of the following statements: Statement 1. A computer-implemented method for making a commitment to a message for which an outcome is to be determined, the method being performed by a first participant of a group of participants, a coordinator being associated with a coordinator public key, the method being performed by the first participant; generating a first encrypted message by encrypting the first message with the coordinator public key; generating a first commitment value based on the first encrypted message; making the first commitment value available to a group of participants and a coordinator; making available to the group of participants and the coordinator a first encrypted message and first disclosure data upon determining that each other participant has made their respective commitment value available to the group of participants and the coordinator, the first disclosure data enabling deriving the first encrypted message from the first commitment value; 11. A computer-implemented method comprising: Statement 2. The method of Statement 1, wherein the step of making the first commitment value available to the group of participants and the coordinator includes sending a first commitment transaction to one or more blockchain nodes for publication on the blockchain, the first commitment transaction including the first commitment value. Statement 3. The method of Statement 1 or Statement 2, wherein the step of making the first encrypted message and the first disclosure data available to the group of participants and the coordinator includes sending a first disclosure transaction to one or more blockchain nodes for publication on the blockchain, the first disclosure transaction including the first encrypted message and the first disclosure data. Statement 4. The method of statements 2 and 3, wherein the first disclosure transaction includes a reference to the first commitment transaction. Statement 5. The method of any one of statements 2 to 4, wherein the first commitment transaction includes an input that references an output of a first transaction, and the output of the first transaction is controlled by a first public key associated with the first participant. Statement 6. The method of statement 5, wherein the first commitment value is based on a transaction identifier of the first transaction. Statement 7. The method of any one of statements 1 to 6, wherein the first encrypted message is generated using ElGamal encryption. Statement 8. The method of any one of statements 1 to 7, wherein the first commitment value is either a hash commitment or a Pedersen commitment generated based on the first encrypted message. The hash commitment may be a salted hash or a randomized hash. Statement 9. The method of any one of statements 1 to 8, wherein the first message comprises a vote or a (financial) offer. Statement 10. Making a first commitment value available to a verifier; making the first encrypted message and the first disclosure data available to a verifier; 10. The method according to any one of statements 1 to 9, comprising: Statement 11. A computer-implemented method for determining an outcome based on a respective message from each of a group of participants, wherein a coordinator is associated with a coordinator public key, the method being performed by the coordinator; obtaining each commitment value generated by each participant; obtaining a respective encrypted message generated by each participant, each encrypted message being generated by encrypting the respective message with a coordinator public key; obtaining respective disclosure data generated by respective participants; using the respective disclosure data to verify, for each participant, that each commitment value corresponds to a respective encrypted message; determining, for each participant, each message by decrypting each encrypted message; determining an outcome based on each message; 11. A computer-implemented method comprising: Statement 12. The method of statement 11, wherein the step of determining an outcome includes using only each message where each encrypted message corresponds to a respective commitment value to determine the outcome. Statement 13. The method of statement 11 or statement 12, wherein the result includes or is associated with one of the respective messages. Statement 14. The method of any one of statements 11 to 13, comprising making the results available to a group of participants. Statement 15. The method of statement 14, wherein the step of making the result available to a group of participants includes sending a result transaction to one or more nodes of a blockchain network, the result transaction including at least one of the result, an indication of the result, and a respective participant associated with the result. Statement 16. The step of obtaining each commitment value includes obtaining each commitment value from a blockchain; and / or the step of obtaining each encrypted message comprises obtaining each encrypted message from a blockchain; and / or The step of obtaining each disclosure data includes obtaining each encrypted message from a blockchain. 16. The method according to any one of statements 11 to 15. Statement 17. Generating a result proof that proves that a result is based on each message; making the resulting proof available to the group of participants; 17. The method of any one of statements 11 to 16, comprising: Statement 18. Generating a result proof from each encrypted message that proves that the respective message was decrypted; making the resulting proof available to the group of participants; The method described in statement 13 or any statement subordinate thereto, including: Statement 19. The method of statement 17 or statement 18, wherein the step of making the proof-of-result available to the group of participants includes sending a proof-of-result transaction to one or more nodes of a blockchain network, the proof-of-result transaction including the proof-of-result. Statement 20. The method of any one of statements 17 to 19, wherein the result proof comprises a zero-knowledge proof. Statement 21. For each message that the result does not contain or is not associated with, generating a respective comparison proof that proves that the result does not contain or is not based on the respective message; making each comparison proof available to a group of participants; The method described in statement 13 or any statement subordinate thereto, including: Statement 22. The method of statement 21, wherein the step of making the respective comparison proofs available to a group of participants includes sending a comparison proof transaction to one or more nodes of a blockchain network, the comparison proof transaction including the respective comparison proof. Statement 23. The method of statement 22, wherein each comparison proof includes a respective zero-knowledge proof. Statement 24. The method of statement 23, wherein each zero-knowledge proof includes a respective bullet proof. Statement 25. Generating a single comparison proof based on each message that proves how the result is related to each message; making a single comparison proof available to a group of participants; The method described in statement 13 or any statement subordinate thereto, including: Statement 26. The method of statement 25, wherein the step of making the single comparison proof available to the group of participants includes sending a comparison proof transaction to one or more nodes of a blockchain network, the comparison proof transaction including the single comparison proof. Statement 27. The method of statement 26, wherein the single comparison proof comprises a recursive succinct non-interactive proof of knowledge (SNARK) proof. Statement 28. A computer-implemented method for verifying an outcome determined based on a respective message from each of a group of participants, the method being performed by a verifier; obtaining each commitment value generated by each participant; obtaining a respective encrypted message generated by each participant, each encrypted message being generated by encrypting the respective message with a coordinator public key; obtaining respective disclosure data generated by respective participants; obtaining the results produced by the coordinator; using the respective disclosure data to verify, for each participant, that each commitment value corresponds to a respective encrypted message; verifying the results; making the results of the validation available to the group of participants and / or the coordinator; 11. A computer-implemented method comprising: Statement 29. The step of verifying the result comprises: obtaining a result proof that the result is based on each of the respective messages and / or that the result includes or is associated with one of the respective messages; using the result proof to verify the result; 29. The method according to claim 28, Statement 30. The result includes or is associated with one of the respective messages, and the step of verifying the result includes: for each message that the result does not contain or is not associated with, obtaining a respective comparison proof that proves that the result does not contain or is not associated with the respective message; Using each comparison proof to verify the result; 29. The method according to claim 28, wherein the Statement 31. The step of verifying the result comprises: obtaining a single comparison proof that proves how the results relate to their respective messages; using a single comparison proof to verify the result; 29. The method according to claim 28, wherein the Statement 32. The step of obtaining each commitment value includes obtaining each commitment value from a blockchain; and / or the step of obtaining each encrypted message comprises obtaining each encrypted message from a blockchain; and / or the step of obtaining each disclosure data comprises obtaining each encrypted message from a blockchain; and / or said step of obtaining a result includes obtaining the result from a blockchain; 32. The method of any one of statements 28 to 31. Statement 33. The method of any one of statements 28 to 32, wherein the step of making the result available to the group of participants and / or the coordinator includes sending a result transaction to one or more nodes of a blockchain network, the result transaction including the result. Statement 34. The method of any one of statements 28 to 33, wherein the verifier is implemented as a smart contract stored on the blockchain. Statement 35. A memory including one or more memory units; a processing device including one or more processing units, wherein a memory stores code arranged to be executed on the processing device, the code being configured to perform the method of any one of statements 1 to 34 when executed on the processing device; 1. A computer device comprising: Statement 36. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 34.

[0115] According to another aspect disclosed herein, a method may be provided that includes actions of any or all of the first participant, the coordinator, and the verifier. According to another aspect disclosed herein, a system may be provided that includes computer devices of any or all of the first participant, the coordinator, and the verifier. [Explanation of symbols]

[0116] 100 systems 101 Packet Switched Network 102 Computer Equipment 103 Parties 103a Alice 103b Bob 104 blockchain nodes 106 Blockchain Network 106 Peer-to-Peer (P2P) Networks 150 Blockchain 151 blocks 152 transactions 154 Ordered Sets 201 Header 202 Input Field 203 Output Fields 300 System 301 participants 302 Adjuster 302 Auctioneer 303 Verifier 303 Auditor 310 bidders 400 System

Claims

1. 1. A computer-implemented method for making a commitment to a message for which an outcome is to be determined, the method being performed by a first participant of a group of participants, a coordinator being associated with a coordinator public key, the method being performed by the first participant; generating a first encrypted message by encrypting the first message with the coordinator public key; generating a first commitment value based on the first encrypted message; making the first commitment value available to the group of participants and to the coordinator; making the first encrypted message and first disclosure data available to the group of participants and the coordinator upon determining that each other participant has made a respective commitment value available to the group of participants and the coordinator, the first disclosure data enabling deriving the first encrypted message from the first commitment value; 11. A computer-implemented method comprising:

2. 2. The method of claim 1, wherein making the first commitment value available to the group of participants and the coordinator comprises sending a first commitment transaction to one or more blockchain nodes for publication on a blockchain, the first commitment transaction including the first commitment value.

3. 3. The method of claim 1 or claim 2, wherein the step of making the first encrypted message and the first disclosure data available to the group of participants and the coordinator comprises sending a first disclosure transaction to one or more blockchain nodes for publication on a blockchain, the first disclosure transaction including the first encrypted message and the first disclosure data.

4. The method of claims 2 and 3, wherein the first disclosure transaction includes a reference to the first commitment transaction.

5. 5. The method of claim 2, wherein the first commitment transaction includes an input that references an output of a first transaction, the output of the first transaction being controlled by a first public key associated with the first participant.

6. The method of claim 5 , wherein the first commitment value is based on a transaction identifier of the first transaction.

7. 7. The method of claim 1, wherein the first encrypted message is generated using ElGamal encryption.

8. 8. The method of claim 1, wherein the first commitment value is one of a hash commitment or a Pedersen commitment generated based on the first encrypted message.

9. The method of claim 1 , wherein the first message comprises a vote or an offer.

10. making the first commitment value available to a verifier; making the first encrypted message and first disclosure data available to the verifier; 10. The method according to any one of claims 1 to 9, comprising:

11. 1. A computer-implemented method for determining an outcome based on a respective message from each of a group of participants, wherein a coordinator is associated with a coordinator public key, and wherein the method is performed by the coordinator; obtaining each commitment value generated by each participant; obtaining a respective encrypted message generated by each participant, the respective encrypted message being generated by encrypting the respective message with the coordinator public key; obtaining respective disclosure data generated by respective participants; for each participant, using the respective disclosure data to verify that the respective commitment value corresponds to the respective encrypted message; for each participant, determining said respective message by decrypting said respective encrypted message; determining an outcome based on each message; 11. A computer-implemented method comprising:

12. 12. The method of claim 11, wherein determining the outcome comprises using only the respective encrypted messages, where each encrypted message corresponds to the respective commitment value, to determine the outcome.

13. 13. The method of claim 11 or claim 12, wherein the result comprises or is associated with one of the respective messages.

14. 14. The method of any one of claims 11 to 13, comprising making the results available to the group of participants.

15. 15. The method of claim 14, wherein making the result available to the group of participants comprises sending a result transaction to one or more nodes of a blockchain network, the result transaction including at least one of the result, an indication of the result, and the respective participant associated with the result.

16. the step of obtaining the respective commitment values ​​comprises obtaining the respective commitment values ​​from the blockchain; and / or the step of obtaining each encrypted message comprises obtaining each encrypted message from the blockchain; and / or the step of obtaining the respective disclosure data includes obtaining the respective encrypted messages from the blockchain.

16. The method according to any one of claims 11 to 15.

17. generating a result proof that proves that the result is based on each message; making the proof of results available to the group of participants; 17. The method of any one of claims 11 to 16, comprising:

18. generating a result proof from each of the encrypted messages that proves that each of the messages has been decrypted; making the proof of results available to the group of participants; 14. A method according to claim 13 or any claim dependent thereon, comprising:

19. 19. The method of claim 17 or claim 18, wherein making the proof of result available to the group of participants comprises sending a proof of result transaction to one or more nodes of the blockchain network, the proof of result transaction including the proof of result.

20. 20. The method of claim 17, wherein the result proof comprises a zero-knowledge proof.

21. generating, for each message that the result does not include or is not associated with, a respective comparison proof that proves that the result does not include or is not based on the respective message; making each comparison proof available to said group of participants; 14. A method according to claim 13 or any claim dependent thereon, comprising:

22. 22. The method of claim 21, wherein making the respective comparison proofs available to the group of participants comprises sending a comparison proof transaction to one or more nodes of the blockchain network, the comparison proof transaction including the respective comparison proof.

23. 23. The method of claim 22, wherein each comparison proof comprises a respective zero-knowledge proof.

24. 24. The method of claim 23, wherein each zero-knowledge proof comprises a respective bullet proof.

25. generating a single comparison proof based on each message that proves how the results relate to each message; making said single comparison proof available to said group of participants; 14. A method according to claim 13 or any claim dependent thereon, comprising:

26. 26. The method of claim 25, wherein making the single comparison proof available to the group of participants comprises sending a comparison proof transaction to one or more nodes of the blockchain network, the comparison proof transaction including the single comparison proof.

27. 27. The method of claim 26, wherein the single comparison proof comprises a recursive succinct non-interactive proof of knowledge (SNARK) proof.

28. 1. A computer-implemented method for verifying an outcome determined based on a respective message from each of a group of participants, the method being performed by a verifier; obtaining each commitment value generated by each participant; obtaining a respective encrypted message generated by each participant, the respective encrypted message being generated by encrypting the respective message with the coordinator public key; obtaining respective disclosure data generated by respective participants; obtaining the results generated by the coordinator; for each participant, using the respective disclosure data to verify that the respective commitment value corresponds to the respective encrypted message; verifying the results; making the results of said verification available to said group of participants and / or said coordinator; 11. A computer-implemented method comprising:

29. the step of verifying the results comprises: obtaining a result proof that the result is based on each of the respective messages and / or that the result includes or is associated with one of the respective messages; using the result proof to verify the result; 29. The method of claim 28, comprising:

30. the result includes or is associated with one of the respective messages, and the step of verifying the result comprises: obtaining, for each message that the result does not contain or is not associated with, a respective comparison proof that proves that the result does not contain or is not associated with the respective message; using said respective comparison proofs to verify said results; 30. The method of claim 28 or claim 29, comprising:

31. the step of verifying the results comprises: obtaining a single comparison proof that proves how the results relate to their respective messages; using the single comparison proof to verify the result; 30. The method of claim 28 or claim 29, comprising:

32. the step of obtaining the respective commitment values ​​comprises obtaining the respective commitment values ​​from the blockchain; and / or the step of obtaining each encrypted message comprises obtaining each encrypted message from the blockchain; and / or the step of obtaining the respective disclosure data comprises obtaining the respective encrypted messages from the blockchain; and / or the step of obtaining the result includes obtaining the result from the blockchain.

32. The method of any one of claims 28 to 31.

33. 33. The method of any one of claims 28 to 32, wherein making the result available to the group of participants and / or the coordinator comprises sending a result transaction to one or more nodes of the blockchain network, the result transaction including the result.

34. 34. The method of any one of claims 28 to 33, wherein the verifier is implemented as a smart contract stored on the blockchain.

35. a memory including one or more memory units; a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when executed on the processing device, to perform the method of any one of claims 1 to 34; 1. A computer device comprising:

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

Images