1. Introduction
A distributed ledger of transactions providing a record of consistency and immutability is well admired in the domain of cryptocurrencies. The decentralization inherent to blockchains currently offers several properties including transparency and integrity. These interesting features inspired many other areas such as insurance, cross-border banking, secure medical data, voting and e-auctions. The adoption of salient characteristics is immediate in these applications, however each of them demands several other particular features. For instance, e-voting [
1] and e-auctions [
2] might need privacy besides transparency and integrity. However, privacy in blockchain is still an unconventional asset, intuitively challenging because it seems against its default transparent nature. In blockchain transactions, privacy is achieved with confidentiality and anonymity techniques.
A well designed auction system having a thorough understanding of bidding behaviour can allocate resources in accordance with an expected outcome. There are different types of auctions determined by the particular environments and settings in which they take place. The most popular type of auction is the sealed-bid auction. Each bidder hands over a sealed envelope containing their secret bid to the auctioneer. There are two variations in this category, namely first-price and second-price auctions based on what the winning bidder pays eventually. In first-price, the auctioneer opens all envelopes and declares the highest bidder as the winner, while keeping losing bids secret. For second-price, the winner pays the second highest bid. The second-price sealed-bid is also called the Vickrey auction (named after William Vickrey).
The auction process has to be managed by an auctioneer, who is the designated party responsible for dispatching the auction resources. Ideally, this party is trusted and should not collude with any of the bidders to outcome a biased decision [
3]. However, reducing the trust on the auctioneer is an innovative feature in line with the philosophy of blockchains, this is why our contribution aims to expand the abilities of such blockchain-based auction systems.
1.1. Related Work
The anonymity in sealed-bid auctions is a well investigated area of research. However, these solutions can not directly be endorsed to apply on blockchain-based auctions. In the view of permissioned and permissionless settings, the essential requisites can be different and therefore a tailored solution must be adapted. For instance, the anonymity in Hyperledger Fabric [
4]—a permissioned blockchain—can be achieved with Idemix [
5], and hence anonymity techniques such as ring signatures, which we introduce in what follows, or group signatures may not be needed in such Fabric-based applications. The Idemix technology implements anonymous credential scheme that relies on a blind signature and efficient Zero-Knowledge Proof (ZKP) of signature possession. Such credential systems need a trusted third party to issue these credentials, for example the membership service provider (MSP) in Hyperledger Fabric. Indeed the anonymity or confidentiality support from the underlying blockchain platform can provide a less complicated solution to some complex use cases. To reduce complexity in open blockchains, some emerging solutions rely on a trusted third party (TTP) as a registration authority ensuring that the participants in the application are already registered and therefore malicious participants can be traced back. One example here is ZebraLancer [
6], wherein a decentralized crowdsourcing of human knowledge is implemented on top of Ethereum. The authors implicitly consider a registration authority validating each participant’s unique identity and issuing certificates to them. The common prefix-linkable anonymous authentication scheme provides anonymity to participants as long as they honestly follow the protocol. Such solutions are limited to easy traceability by the registration authority and collusion attack. The malicious auctioneer can easily collude with some bidder and make them win by sharing bids before the auction’s conclusion. Furthermore, Ethereum can easily reveal anonymity while depositing/paying fees for rewards. Removing the trust from the auctioneer is indeed appreciable, however, the overhead seems to be high enough not to be acceptable. Ref. [
7] presented an auction demonstration with only three parties: one seller and two buyers. A helper server assists as a trusted party with access to all the secrets and facilitates communication among chain codes. The time to execute a transaction is around 0.3 s which is expected to grow exponentially with an increasing number of participants. Moreover, this auction does not consider the anonymity of participants.
However, it seems more challenging to deliver a solution for anonymous auction on permissionless blockchain such as Ethereum. Ref. [
8] proposed Hawk, a combination of the privacy of Zcash with the programmability of Ethereum. The privacy preserving Smart Contracts have been employed to handle transactional privacy on Ethereum blockchain. They focused on presenting a framework which can simultaneously support several applications such as sealed-bid auction, rock paper scissor game, crowdfunding application and swap financial instrument. The main limitation of Hawk is that it relies on a manager trusted explicitly not to leak secret inputs to Smart Contract. A recent improvement presented as zkHawk [
9] by Banerjee et al. replaces the trusted manager with an Multi-Party Computation (MPC) protocol wherein the secret inputs are hidden from the blockchain as well as from other participants. To mitigate the overhead incurred with MPC protocol, the authors propose to run MPC off-chain as an interactive protocol. The major limitation here is that all participating bidders have to be online during the whole process to run MPC. A private and verifiable smart contract approach [
10], introduced as a combination of secure MPC and proof-carrying code focusing primarily on correctness, privacy and verifiability guarantees for smart contracts on blockchains. The approach is well applicable to several applications such as private and verifiable crowdfundings, investment funds and double auctions for decentralized exchanges.
Strain [
11] presented a protocol to build a blockchain-based sealed-bid auction, preserving bid privacy against malicious parties. A bulletin board is used to publish the winning bid which is determined by comparing them by pairs. Two different ZKPs ensure that the participants used the original bids under commitment and that the auctioneer declared the winner without manipulation. The malicious participant is punished by opening their commitment as their private key is partly shared among all participants through a distributed key generation process.
Galal and Youssef [
12] presented a smart contract for verifiable first-price sealed-bid auction on the Ethereum blockchain. Bidders submit their bids to a smart contract using Pedersen commitment [
13]. The commitments are secretly revealed to the auctioneer via a Public Key Encryption (PKE) scheme. After declaring the winner, for each losing bid, the auctioneer has to engage into a set of interactive commit-challenge-verify protocols to prove that the winning bid is greater than the losing bid and therefore, the complexity of interaction depends on the number of bidders. Later, Galal and Youssef [
3] improved this protocol and presented a Smart Contract with succinctly verifiable ZKP which enables single proof verification for the whole auction process. Similar to Zcash, they used MPC among auctioneer and bidders to derive Common Reference String (CRS) during Zero-Knowledge Succinct Non-interactive ARgument of Knowledge (zk-SNARK) set up.
Some interesting approaches such as Anon-Pass [
14] and SEAL [
15] can be further tailored for blockchain implementation. Anon-Pass is an anonymous subscription service focusing on trade-off between unlinkability vs. re-authentication epoch. SEAL is an auctioneer-free first-price sealed-bid auction protocol. It securely computes the logical-OR of binary inputs without revealing each individual bit. No secret channel is required among participants. All operations are publicly verifiable and everyone including third party observers is able to verify the integrity of the auction outcome. Finally, a party comes forward with a winning proof.
Following the above discussion, it can be easily inferred that existing research is primarily focused on bids confidentiality and enabling fair auction using ZKP. However, the bidder’s privacy is still missing. The same can be followed from
Table 1. The use case
auction in a fair market that we present in
Section 1.2 requires additional cryptographic primitives in order to be successfully achieved.
1.2. Auction in a Fair Market
We assume a situation where all the sellers or merchants want to offer their products to consumers at competitive prices. In such a competitive environment, merchants do not even want to make their interest public. Even if a merchant is the winner, he might not be interested to disclose it. Only the consumer, auctioneer and merchant are aware about this procurement or purchase. Therefore, it would be a desirable feature for sellers and merchants to be able to offer a sealed-bid auction, without disclosing their identity. Without loss of generality, the auction type we choose here is first price sealed-bid auction. To summarise, auction in a fair market implies that the bidders are able to keep their identities secret and not to disclose their bids, and for the overall auction process to be able to be publicly verified.
Motivation and Contribution. The limitations of traditional auctions are centralization, lack of transparency, no interoperability and malicious behaviour by auctioneer or bidders. A blockchain-based auction can address these issues, however adding anonymity to this feature list is quite challenging. The existing blockchain-based auction solutions are either in permissioned setting or do not satisfy the anonymity of the bidders. We introduce a new protocol allowing to run an auction in a fair market. Our construction presents the advantage of being general and of using only existing cryptographic building blocks. The confidentiality and anonymity properties are achieved by using Designated Verifier Ring Signature (DVRS). Moreover, it is possible to leverage the transparency and auditability of blockchain platforms in order to make the auction process publicly verifiable, which is an interesting feature in the event of a dispute among parties.
Precisely, our sealed-bid auction protocol enables the following properties:
The bidders do not want to disclose their bids (confidentiality of bids).
The bidders do not want to disclose their identity during the whole process (anonymity of bidding parties).
The auctioneer is minimally trusted to assist in the bidding process but not to affect its correct execution.
Bids, once committed, can not be retracted or changed (bid binding).
The auction process is publicly verifiable.
2. Preliminaries
In this section, we recall some standard definitions of commitment schemes PKE, Ring Signature (RS) and ZKP.
Definition 1. A function is negligible
if belonging to the set of positive polynomials, s.t. [
16]
. A negligible function f is denoted . Definition 2. Let be a set. means that an element is randomly selected from a uniform distribution over and assigned to s.
Definition 3. Let be an adversary and let be some oracle. means that is given access to oracle .
Definition 4. Let and be two strings. Their concatenation is denoted as .
2.1. Commitment Scheme
A non-interactive commitment scheme is a set of algorithms
such that:
outputs the public parameters of the system for a given security parameter k
for any message
m belonging to the message space,
outputs a commitment/opening pair
if c is a valid commitment, otherwise ⊥
Correctness: for any
m belonging to the message space,
The commitment scheme should possess the following two properties:
Hiding. For any adversary
,
where
is a state allowing stateful communication between
and
.
Binding. For two distinct strings
s and
and any probabilistic polynomial time (
) adversary
,
2.2. Ring Signature
The Ring Signature technique was introduced by Rivest et al. in 2001 [
17] and allows a party to anonymously sign a message. A ring is a set of possible signers, with each of them being associated with a public key
, and the corresponding secret key
(for the
user). When a
verifier checks the signature, they can only conclude that a member of the ring endorsed it, without being able to determine the identity of the signer. A RS scheme should be unforgeable and anonymous, and consists of a triple of
algorithms
defined as follows:
- 1.
Key Generation: , where k denotes the security parameter, is a list of n public keys, which includes the public key of the signer and decoy public keys, is the secret key of the signer and s is the index of the signer’s public key in .
- 2.
Signature: , where is the signature, and m the message to be signed.
- 3.
Verification: , where outcome indicates the validity of the signature.
Correctness. A RS is said to be correct if for any valid message
m belonging to the message space:
Anonymity. A RS satisfies anonymity if for any
adversary
,
where
is a state allowing stateful communication between
and
.
Unforgeability. A RS is unforgeable if for any
adversary
,
where the adversary
has not been allowed to query the signing oracle
with message
m.
2.3. Public Key Encryption
A PKE scheme consists of a triple of
algorithms
defined as follows:
- 1.
Key Generation: , with k the security parameter, and and the public and secret key, respectively.
- 2.
Encryption: , with c the ciphertext and m the message.
- 3.
Decryption: , with if the decryption fails.
Correctness. A PKE scheme is said to be correct if for any valid message
m belonging to the message space,
Ciphertext Indistinguishability. A PKE scheme satisfies ciphertext indistinguishability if for any
adversary
,
where
is a state allowing stateful communication between
and
and where the adversary
is not allowed to query
c from the decryption oracle
.
2.4. Zero-Knowledge Proof
The ZKP system relies on the construction presented by Galal and Youssef in [
3] which itself is an application of the zk-SNARK introduced by Ben-Sasson et al. in [
18]. Let us recall a few definitions and properties about this proof system. A ZKP system is a triple of algorithms
defined as follows:
- 1.
Key Generation: , with the common reference string, k the security parameter, and the language description.
- 2.
Proof Generation: , with s the statement whose membership to has to be proved, w the corresponding witness, and the proof.
- 3.
Proof Verification: , with the single bit indicating whether the verification succeeded.
The zk-SNARK described in [
18] features the following properties:
Perfect Completeness. An honest prover with a valid witness is always able to convince a honest verifier. Mathematically, let
s be a claim belonging to the language
with
w the corresponding witness:
Computational Soundness. The probability that a
adversary can convince an honest verifier that a false statement is true is negligible. Mathematically, let
be a
adversary and
s be a claim which does not belong to the language
:
Computational Zero-Knowledge. A adversary is not able to extract any information about the witness from the proof. Slightly more formally, let be a simulator knowing the witness w to a statement s in , and let be a simulator not knowing the witness w. For any , there exists an such that their views are computationally indistinguishable.
Succinctness. The proof system should run in polynomial size and time. Mathematically, and , with being the bit-length operator, with belonging to the set of polynomial functions and being the asymptotic time operator.
3. Formal Model and Security Definitions
In this section, the mathematical definition of our Anonymous Fair Auction protocol is introduced, as well as the security properties which it has to fulfill. An Anonymous Bidding System (ABS) is a tuple of
algorithms
defined as follows:
Key Generation: , with k the security parameter, the ring members’ public key, the signer’s private key, s and v the indices of the signer’s and verifier’s public key in , respectively.
Bid submission: , with x the bid value, the verifier’s public key, c the commitment to the bid, the modified signature to the bid, the bid opening token and the identity opening token.
Bid opening: , with the verifier’s private key and a single bit indicating whether the bid opening succeeded.
Identity opening: , with the signer’s public key and a single bit indicating whether the identity opening succeeded.
Our ABS has to feature the following security properties:
Correctness. An ABS is said to be correct if for any valid bid
x, the following two properties hold:
Unforgeability. An ABS satisfies unforgeability if for any
adversary
,
where the adversary
is not allowed to query the bid submission oracle
with bid
x.
An ABS satisfies strong unforgeability if it satisfies unforgeability with the adversary given access to the bidding oracle for bid x as well, but without the ability to obtain as a response.
Signer Anonymity. An ABS satisfies anonymity if for any
adversary
,
where
is a state allowing stateful communication between
and
. If the attacker has an additional access to the list of secret keys, and if signer anonymity is preserved, then the scheme has signer anonymity
against full key exposure.
Unpretendability. An ABS satisfies unpretendability if for any
adversary
,
where the adversary
is not allowed to choose
.
4. Proposed Scheme
Our proposed construction is built upon a DVRS introduced by Saraswat and Pandey [
19]. The resulting scheme provides correctness, unforgeability, unpretendability and signer anonymity. In this context, the auctioneer is the designated verifier trusted to open the bids. However, a collusion between malicious bidders and verifier should not affect the outcome.
There are separate time frames for bid submission (), bid opening () and winner declaration () such that . During the first time interval , the bidders submit ring signed commitments of their bids and of their identities to the auctioneer. In the course of second time interval , the bidders reveal their bids by encrypting them using the public key of the auctioneer (known by anyone). In the last interval , the winning bidder reveals their identity to the auctioneer.
In order to successfully realize our construction, we rely on the following assumptions:
The auctioneer is minimally trusted and assumed not to disclose the bidder’s input
Each participant and auctioneer deposit an amount of cryptocurrency in the Smart Contract. After the auction is concluded, the deposits get refunded to honest participants. This provides an economic incentive to strictly follow the protocol.
We assume the existence of a blockchain providing
anonymity and
confidentiality on the transactions. The first property is required to ensure that the anonymity of the overall scheme is not broken by merely looking at the transaction metadata, such as the fields
from and
to in the context of Ethereum. Without the second property, it would be possible to gain information about the value of the winning bid by looking at currency exchanges on the network. This assumption, which might seem unrealistic at first glance, is not so costly since there already exists protocols providing such features, e.g., Zether [
20] for Ethereum.
4.1. Our Generic Construction
Our construction is built using four algorithms. The first one, represented in Algorithm 1, is the key generation algorithm,
KeyGen, which takes care of generating the keys required to form the rings. It can be used for bidders and verifier. The same keys are used for both signature and encryption.
Algorithm 1 Key generation algorithm. |
- 1:
functionKeyGen() - 2:
- 3:
- 4:
return - 5:
end function
|
The second one is the bid submission algorithm
Bid depicted in Algorithm 2. This algorithm outputs the commitment to the bid
c, the modified signature
, the bid opening token
and the identity opening token
. The modified signature
is used to obtain a proof that all the required information about the bid value and the identity of the bidder are embedded and that they cannot be changed at later time. The bidder needs to send the bid and identity opening tokens for the verifier to be able to retrieve the bid value and the identity, respectively. Two different rings of parties are used in this algorithm. The first one is arbitrarily constructed by the bidder to maintain their anonymity. The second one is used to make sure that the verifier cannot convince anyone that the bidder actually generated a given bid, since the verifier is also included in the ring, which is precisely the designated verifier approach presented by Rivest et al. as an ad hoc application of their RS scheme introduced in their foundational paper [
17]. For the sake of generality, two different RS schemes can be used,
and
in this case.
Algorithm 2 Bid submission algorithm. |
- 1:
functionBid() - 2:
- 3:
- 4:
- 5:
- 6:
- 7:
- 8:
- 9:
- 10:
- 11:
- 12:
return - 13:
end function
|
The third one, depicted in Algorithm 3, is the bid opening algorithm, BidOp, which is used to verify that the bid is valid, and to open its value. The bid opening token generated by the bidder is required. If the signatures and the commitments are successfully verified, the verifier locally stores the bid x and the corresponding opening value d.
Finally, the last one is the identity opening algorithm, I
dO
p, depicted in Algorithm 4, which allows the verifier to check that the identity of the winning bidder is valid and to obtain their public key. The corresponding identity opening token is needed. The RS is verified using the ring made of the public keys of the winning bidder and the verifier only. If the identity is successfully verified, the winning bidder’s public key is locally stored by the verifier.
Algorithm 3 Bid opening algorithm. |
- 1:
functionBidOp() - 2:
- 3:
- 4:
if then - 5:
- 6:
if then - 7:
- 8:
- 9:
if then - 10:
if then - 11:
- 12:
- 13:
- 14:
- 15:
end if - 16:
end if - 17:
end if - 18:
end if - 19:
return b - 20:
end function
|
Algorithm 4 Identity opening algorithm. |
- 1:
functionIdOp() - 2:
- 3:
- 4:
- 5:
if then - 6:
- 7:
- 8:
if then - 9:
if then - 10:
- 11:
- 12:
end if - 13:
end if - 14:
end if - 15:
return b - 16:
end function
|
4.2. Anonymous Fair Auction Protocol
The protocol implemented in our construction is presented in Algorithm 5. It is designed for a fixed number of N bidders. The first step is concerned with the generation of the keys for the auctioneer and the bidders. Regarding the keys and the rings, some notations need to be introduced:
: Verifier’s public key.
: bidder’s ring of public keys.
: Public key at position in bidder’s ring of public keys.
: bidder’s public key.
Algorithm 5 Anonymous Fair Trading protocol. |
1: | | ▹ For auctioneer, . |
2: | for
do | |
3: | | ▹ Generating keys for bidder. |
4: | end for | |
5: | for do | ▹ Time : bid submission. |
6: | | |
7: | | |
8: | | |
9: | end for | |
10: | for do | ▹ Time : bid opening and verification. |
11: | | |
12: | end for | |
13: | for
do | |
14: | | |
15: | if then | ▹ Bid and decommitment stored locally at auctioneer. |
16: | continue | |
17: | end if | |
18: | end for | |
19: | | ▹ Array of size N with the commitments of all the bidders. |
20: | | ▹ is the commitment to the winning bid. |
21: | | |
22: | | |
23: | for do | ▹ Time : opening of winning bidder’s identity and verification. |
24: | | |
25: | if then | ▹ bidder is the winner. |
26: | | |
27: | end if | |
28: | end for | |
29: | | |
30: | if then | ▹ Identity of winning bidder successfully opened and verified. |
31: | continue | |
32: | end if | |
Since all the bidders need to share the same auctioneer, the following condition must hold:
At time , each bidder chooses a bid and executes the Bid algorithm to submit the commitment to their bid and the corresponding signature to the blockchain, and to locally store the opening tokens.
At time , the bidders submit their respective bid opening token to the blockchain. The auctioneer fetches the bid opening tokens, verifies the bids and stores their value. Then, the auctioneer computes the winning bid using the VerifiableAuction algorithm and sends the commitment to the winning bid and the zk-SNARK to the blockchain.
Finally, at time , the winning bidder submits their identity opening token. The auctioneer verifies the identity and stores the winner’s public key.
During the whole auction process, the interactions between the auctioneer, the bidders and the Smart Contract can be listed as follows:
: The auctioneer triggers the auction Smart Contract.
: The commitment c and the modified signature output by Bid are submitted by each bidder to the Smart Contract.
: The bid opening token is submitted by each bidder to the Smart Contract so that the auctioneer can run the algorithm BidOp.
: The auctioneer submits the return value of Algorithm 6 as well as the corresponding zk-SNARK proof .
: The identity opening token is submitted by the winning bidder to the Smart Contract so that the auctioneer can run algorithm IdOp.
Algorithm 6 Returns the commitment to the winning bid. |
- 1:
functionVerifiableAuction() - 2:
- 3:
- 4:
- 5:
for do ▹N is the constant number of bidders. - 6:
if then - 7:
- 8:
return - 9:
end if - 10:
if then - 11:
- 12:
- 13:
end if - 14:
end for - 15:
return - 16:
end function
|
4.3. Zero-Knowledge Proof
As indicated in
Section 2.4, the ZKP system used in our scheme is a slightly modified version of the one proposed in [
3] and can be observed in Algorithm 6. In [
3], they designed their algorithm to handle a Vickrey auction, which implies that they have to return both the highest and the second highest bids. In our approach, we want to implement a first-price sealed-bid auction. Moreover, we do not want to disclose the value of the winning bid, hence the fact that our algorithm only returns the
commitment to this bid. We also assume that all the bids are different.
Practically, as it is suggested in [
3], it is required to translate the algorithm into an Arithmetic Circuit. To do so, an Arithmetic Circuit Generator, as the one designed by Ben-Sasson et al. in [
18], has to be used. More formally, the setup and usage of the ZKP system requires the following operations:
- 1.
The auctioneer has to generate a proof (or an Argument of Knowledge, which is the probabilistic counterpart, as it case for a zk-SNARK) and therefore needs a language description of the algorithm:
With
a mapping between the space of algorithms
to the space of language descriptions over an alphabet
. Intuitively, this mapping can be seen as a compiler and is a black-box representation of the Arithmetic Circuit Generator described in [
18].
- 2.
Having defined the language, it is possible to generate the
, which finalizes the initial setup of the ZKP system:
These first two steps are only required when the proof system is setup for the first time, and the stays valid as long as N, the maximum number of bids, remains the same. is stored on the blockchain.
- 3.
When the bidders have revealed their bids, the auctioneer executes Algorithm 6 and determines
, which is the commitment to the highest bid stored on the blockchain, and is able to compute the proof
. In this situation, the statement, which is publicly known, is the
tuple
, with
c the
N tuple made of the commitments to the bids. The witness, known only to the auctioneer, is
, which is a
tuple made of the value of the bids as well as their opening value. This ensures that the auction is executed correctly without leaking any information about the value of the bids. The proof
is also stored on the blockchain.
- 4.
The Smart Contract verifies the auction thanks to the proof
and to
. Since the
,
and
are stored on the blockchain, one can leverage the auditability inherent to this data structure to be convinced that the auction was executed correctly in a transparent, trustless configuration.
5. Security Analysis
Anonymous Bidding System should be analyzed in two aspects- the security of our proposed cryptographic scheme and its integration in the blockchain platform. Here, we claim that the auctioneer will declare the correct auction winner. However, the validity of our claim depends upon some presumptions: (i) we assume that the blockchain is an ideal public ledger; (ii) the underlying components such as ring signature, public key encryption, commitment scheme and ZKP satisfy their cryptographic properties as mentioned in
Section 2. The immutable and transparent nature of blockchain guarantees smooth integration of our generic scheme, to successfully hold an anonymous blockchain-based auction.
An adversary can break the anonymity of bidders only if during the interaction, a bidder’s blockchain address is identifiable to auctioneer. The unconditional anonymity provided by ring signatures in time interval and prohibits auctioneer to identify the bidder until winning bidder opens their identity. On the other hand, the auctioneer’s identity or blockchain address is public and known to all bidders in advance. Maintaining bid privacy seems challenging in a transparent blockchain environment. We achieve it by using a commitment scheme which is hiding and binding, and submitting this commitment value to smart contract, publicly on blockchain. Moreover, the auctioneer can not access these bid values until the bid submission is closed.
A malicious auctioneer can pose threats in following ways: (i) auctioneer can claim that the ciphertext submitted by bidder did not open to the bid commitment; (ii) auctioneer claims the opening value provided by bidder did not compute the corresponding commitment; (iii) auctioneer can collude with a bidder by sharing bid values of other bidders and assist them to win; (iv) auctioneer can announce a favoured bidder as winner. The first and second threats can be mitigated easily by utilizing blockchain’s transparency feature. The ciphertext and commitment values are submitted as transactions on immutable blockchain by bidders, and therefore the auctioneer cannot cheat in this case. To protect against third threat of collusion with bidder, we introduced the concept of time intervals, the bid opening is initiated only after bid submission is closed. The ZKP protects against the last threat by submitting a public proof on blockchain where anyone can verify it.
A malicious bidder can cheat the system by: (i) submitting arbitrary ciphertext; (ii) not providing correct opening values; (iii) not responding in time interval
. The first two threats are straightforward to mitigate as all the data submitted by bidders is in the form of transactions to the smart contract, and therefore can be verified. Our proposed solution does not cover this third threat and we leave it as an open problem. However, the solution suggested by Strain [
11] can partially fill this gap by allowing the other participants to open the commitments by an honest majority, in the case of a dispute. The auction process is
publicly verifiable as its correctness can be verified using ZKP.
Below, we analyze the security of our proposed cryptographic scheme. Here we prove that the security of proposed cryptographic scheme directly relies on the individual security of the different building blocks.
Theorem 1. Assume be an anonymous and unforgeable ring signature, be a semantically secure encryption scheme and be a hiding and binding commitment scheme, then our constructionrelying on these components is correct, signer anonymous, unforgeable and unpretendable. Proof. In order to prove this, we need to successfully deduce the security requirements of our construction from the corresponding security requirements of the underlying components.
Correctness. The correctness of ABS is implied by successful opening of bids and uncovering the true identity of the winner. For a submitted bid , with modified signature , bid opening token and ring , the correctness of the bid opening algorithm relies on the correctness of , and . Therefore, the following conditions must hold:
where
Similarly, for successful identity verification where is the identity opening token introduced in our proposed construction, the following must hold:
where and where w represents the winner’s index.
Unforgeability. Let us assume that
is the adversary attempting a forgery on
.
Here we construct a new adversary
which has same polynomial time complexity as
, attacking the unforgeability of
with advantage
The adversary has access to the signing oracles and and answers the signing queries coming from as follows:
For any bid , requests its own signing oracle and outputs . Further, computes the RS on message , with .
Computes encryption where message .
Computes commitment .
Computes a RS on message using oracle.
Computes encryption where message .
Computes commitment .
Returns and to adversary , with and .
According to the description of , the above interaction between and is perfectly simulated for by . Following the definition of BidOp, whenever adversary output a forged Zi, τ1,i, it means that successfully forged some intermediate RS σi, Σi or δi. Therefore, a forgery by in implies forgery of by .
Unpretendability. Let
be the adversary breaking the unpretendability of
and having access to the bidding oracle
Bid(
,
s,
v, ·). Here we construct a new adversary
which has the same polynomial time complexity as
, attacking the binding property of commitment scheme
satisfying
The challenger runs and provides it to adversary . further forwards this tuple to adversary . answers the commitment queries of by using its commitment oracle . The unpretendability game runs as follows:
obtains from :
computes: , with , and
obtains from : , with
where
is the identity opening token generated for sender at index
in the ring
by adversary
. Now the adversary
halts with a commitment tuple:
Here the sender’s index
and we claim that unpretendability game for
is perfectly simulated by
. Furthermore, the successful verification
implies the corresponding commitments must hold, i.e.,
. On the other hand, since
by definition, we have
. Since the signer index
,
and therefore
has clearly attacked the binding property of
. Therefore, whenever the adversary
successfully breaks the unpretendability of
,
also breaks the binding property of
.
Signer Anonymity. The signer anonymity relies upon the signer anonymity of the , the semantic security of the encryption scheme and the hiding property of the commitment scheme . The final message Z = (c, ), with = σ||c1||c2, includes a RS σ and three commitments c, c1 and c2. The underlying σ guarantees anonymity and therefore a non-negligible advantage for the adversary can only come from the commitment scheme.
Until the time interval starts and identity token is released, the designated verifier is a potential adversary as well and we ensure the signer anonymity is preserved for that period.
Let
be the adversary attacking the anonymity of
with zero advantage and
be the adversary breaking the anonymity of
and having access to the bidding oracle
Bid(
,
i,
v, ·). Here we construct a new adversary
which has same polynomial time complexity as
, attacking the hiding property of commitment scheme
with advantage
The challenger runs and provides it to adversary . further forwards this tuple to adversary . The adversary answers ’s commitment queries by calling the commitment oracle in its own challenge. The signer anonymity game runs as follows:
provides to :
For a bid x and two signer indexes , requests its own signing oracle and outputs two signatures
further computes on message
Compute encryption where message
further computes on message and outputs the ciphertext as on message
Now, for two different signer identities,
forwards these two ciphertexts
and
to
’s challenger. The challenger chooses a bit
, computes
and
using
oracle and returns to
. Now,
chooses a bit
and provides
) as challenge bid return to adversary
. The adversary
guesses a random bit
and returns to
which
forwards as its own guess to challenger. Here,
perfectly simulates the anonymity game for
and therefore
Here, note that it is unlikely to guess whether
is the commitment for
depending upon
b’s choice by challenger. The adversary
returns
with non-negligible advantage if
is the commitment for
otherwise returns a random
. As
returns
as their response, which is actually received from
, therefore,
’s advantage is equal to the advantage of
. So, before the release of identity verification token, we have
Once the time
is over and identity token
is released to auctioneer, the
scheme semantic security can only protect the signer’s anonymity. However, we assume the
guarantees security against any such attack and therefore, we have
□
6. Performance Analysis and Blockchain Related Issues
In this section, we evaluate the performance of the protocol presented above. A proof of concept has been designed using the Ethereum platform and can be found on a GitHub repository (
https://github.com/lepilotedef22/anonymous-sealed-bid-auction, accessed on 18 August 2021). In order to run the protocol on a full blockchain network, the software
Ganache (
https://www.trufflesuite.com/ganache, accessed on 15 November 2020) has been used. It allows to simulate an arbitrary Ethereum network. At the time of the writing of this paper, 30 November 2020, the exchange value of the ether is 589 US dollars and the gas cost is 20 GWei. The gas and US dollar costs of the functions used during the protocol can be found in
Table 2.
The auction contract code is written in Solidity language and then compiled to EVM byte code and replicated to Ethereum nodes. The smart contract deployment is one of the most expensive tasks (1,861,811 gas units) but since this should be executed only once and can then be reused arbitrarily many times, this is an acceptable overhead. The cost of the function placeBid grows linearly with the number of bidders. This is due to the fact that it takes as an input a ring signature, as well as the ring of users itself, which are both proportional to the number of bidders. This is a practical limitation because if a number of bidders above 15 is reached, it will lead to a gas limit exception. However, a simple solution would be to only store a hash of this data on chain and rely on other off-chain resources, such as for example InterPlanetary File System (IPFS) or Swarm, to actually access the data. More sophisticated solutions will be investigated in future work.
At the current stage of development, the ZKP is still a missing feature. However, it is expected that the overhead linked to this part of the protocol should be close to that of the auction protocol presented by Galal and Youssef [
3], since our
VerifiableAuction algorithm is similar to the one they present. Our new scheme exhibits a major improvement compared to theirs since it enables the bidders to maintain their anonymity by using a DVRS approach. This feature requires a maximum of three interactions with the Smart Contract (bid commitment, bid opening and identity opening for the winning bidder), whereas only two are needed in Galal and Youssef’s protocol.
While comparing our proposed work with [
12], keeping the same number of ten bidders and same blockchain platform, we demonstrate that the Smart Contract deployment cost of our protocol saves 40%, with respect to deployment cost of 3131261 gas units in [
12]. Furthermore, other functions such as openBid, announceWinningCommitment and withdrawDeposit consume less gas while placeBid is marginally more expensive in our case. Therefore we conclude that our proposed protocol is more efficient with additional features.
In
Figure 1, the auction time as function of the number of bidders taking part to the auction is displayed. This time grows monotonically with the number of bidders. This can be explained by the fact that the rings formed in order to perform the ring signature that ensures anonymity is built by selecting a random number of parties among the bidders. Therefore, the more bidders, the larger the rings on average, and the longer the computations involving them, as indicated above.
Handling an auction on blockchain itself raises special challenges. In an conventional online auction with a centralized auctioneer the confidentiality, integrity and authentication can be achieved with standard security protocols such as SSL/TLS. Furthermore, there are several means to achieve privacy as well such as ToR, VPN and proxies. However these safeguards are not easy to leverage in an blockchain environment.
In a blockchain auction scenario, the bidding participants disclose their identity (fully/partially) and even the bid amount is also visible to others, even to non-participants. The naive solution is to adopt our anonymous auction protocol on the top of an existing privacy preserving blockchain. However, there can still be some hidden practical implementation challenges as well. For example, a peculiarity which is linked to our proposed protocol is the necessity to publish the list of possible signers, since our scheme relies on RS.
We strengthen our solution by adopting several blockchain oriented measures, listed below:
In order to protect the wining bid privacy, we store the commitment of bid on the blockchain;
The deposit guarantee provides economic incentive to strictly follow the protocol;
Store the zero-knowledge proof for all the losing bidders, verifiable by anyone.
Instead of relying on a expensive privacy preserving blockchain, the bidders can use pseudonyms to decouple their fixed key pair with freshly generated key pairs (pseudonyms). However, this gives rise to another issue—how to pay the transaction fee for interaction with the Smart Contract. The fund transfer from the bidder’s conventional Ethereum account to newly generated key pair will clearly establish a connection between these accounts. Indeed some solutions exist such as (i) registration of fresh key pairs using blind signature by auctioneer and (ii) ZKP to enable privacy preserving authentication, and to hide the fund trail, the auctioneer transfers some funds to bidders for interacting with the Smart Contract [
11]. However, these solutions are also not very economical to adapt and require further substantial research.
7. Conclusions and Future Work
We have introduced a generic protocol for anonymous fair trade using only standard cryptographic building blocks. The confidentiality and anonymity properties are achieved using DVRS and the transparency and auditability of blockchain platforms is leveraged in order to make the auction process publicly verifiable. In this paper, we assume the existence of a blockchain facilitating anonymous and confidential transactions. We also analyzed the efficiency of using such cryptographic primitives on Ethereum blockchain and investigate the complexity and vulnerabilities that a blockchain environment might introduce during implementation. In a future work, we intend to further analyze the performance of the designed system on an existing privacy preserving blockchain.