ZK-Auctions Toolkit Grant Proposal and Progress Tracking

Table of Contents


Human ingenuity cannot concoct a cipher which human ingenuity cannot resolve.E. A. Poe, 1841

Status

ITEM STATUS SCHEDULED CLOSED
  Milestone 1 Tasks (2-month period) TODO [2024-04-14 Sun]  
    Milestone 1: (Sprint 1) DONE [2024-02-28 Wed] [2024-03-24 Sun 00:46]
      Milestone 1: Research DONE [2024-02-27 Tue] [2024-02-28 Wed 15:43]
      Milestone 1: Development environment setup DONE [2024-02-27 Tue] [2024-03-24 Sun 00:46]
    Milestone 1: (Sprint 2) TODO [2024-05-06 Mon]  
      Milestone 1: (Sprint 2): Technical specification TODO [2024-05-01 Wed]  
      Milestone 1: (Sprint 2): Test suite development TODO [2024-05-06 Mon]  
    Milestone 1: (Sprint 3) TODO [2024-05-25 Sat]  
      Milestone 1: (Sprint 3): Test suite development (cont'd) TODO [2024-05-15 Wed]  
      Milestone1 1: (Sprint 3): Sketching the Pseudo-code TODO [2024-05-25 Sat]  
    Milestone 1: (Sprint 4) TODO [2024-05-28 Tue]  

(This document is powered by the greatest mode of the greatest software of all time)

1. Project Overview

1.1. Overview

The proposed idea is to develop a toolkit called zk-auctions (which stands for Zero-Knowledge Auctions), aiming to found a practical and versatile primitives for conducting secure and private auctions using zero-knowledge proofs. Although there are distorted efforts to implement similar toolkits, at the time of writing this proposal, there does not seem to be any widely adopted framework, at least not on the idea perception as later described.

The toolkit will prioritize SPARTAN PLONK as the underlying proof system. That being said, we will ensure that a modular implementation is in place to enable the flexibility to integrate alternative proof constructions methods (e.g., STARKs) should the need arise.

The toolkit seeks to address the need for bidder anonymity, transaction security, and decentralized auction processes while ensuring modularity and efficient integration with blockchain platforms. However, the final product is not at all only targeted at the so-called HTTP/3 world. But, the properties described in Project Motivation are the imperative contribution of this toolkit, let it be deployed on a blockchain, message-queue, REST APIs, etc.

Generally speaking, auctions are a very interesting social interaction (and a game), one that inevitably reveals several traits of the participants (and consequently, allows for exploitation).

1.2. Short Rationale

A zero-knowledge-proof-based contract library for First-Bid, Second-Bid, English, Dutch,and SEAL auctions to govern bidder anonymity, decentralization, and integrity while particularly avoiding neopotism.

1.3. Project Details and Motivation

The output of the project will be a Rust-based toolkit that simulates a decentralized auction and governs the following properties:

  • Bidder anonymity: the identity of bidders must remain unknown and the specifics of their bids are kept private.
    • This is important when revealing the bidder’s identity could influence the auction’s outcome or lead to privacy breaches (e.g., real estate, art/collectibles, etc.).

      For example, whether one is the auctioneer or a bidder, a piece of information claiming that, say, Apple is joining a tender may impact one’s strategy to bid.

  • Secure transactions: ensuring the integrity of the auction process as well as protecting against fraud. Questions to be answered:
    • How to prove the actual worth of the bidder claiming that she has? If that's not in the scope of the project, it has to be explicitly stated that such a responsibility is delegated to third-party tools.
    • Will there be an escrow to guarantee that the bid is held securely?
  • Decentralized auctions: facilitate transparent and decentralized auctions (without even an auctioneer in case of SEAL).
    • Decentralized auctions take place on a daily basis1, 2.
    • In the case of SEAL, the system must provide a proof that is computable by each party and asserts the winning result.
  • Integrity: the system must provide a proof that the some bid has won without revealing its value.
    • Why? Revealing the winning bid is an sensitive information. It shows the valuation of item \(i\) by the bidder \(j\). While it may not impact the auction at time \(t\), it could still be abused in an auction at time \(t + 1\)–e.g., as explained in (Hal R. Varian, 1995).

1.3.1. Backend

The backend will be developed using Rust programming language for the following reasons:

  • Wider interoperability to other core systems (especially in cryptography).
  • Rapid performance.
  • Seamless porting to web browsers with `wasm-pack`.

2. Team

2.1. Team members

  • ndrwnaguib (base64 --decode <<< "bmRyd25hZ3VpYkBnbWFpbC5jb20=")

Currently, ndrwnaguib is a graduate student at the Combinatorics and Optimization department, Faculty of Mathematics, University of Waterloo. His interests spans Game Theory, Distributed Optimization, Interactive proofs, Formal verification–among others.

Previously, he earned his Master of Applied Science from the Computer Engineering department at the University of Victoria, where he was working on solving combinatorial optimization problems using statisitcal learning. In his undergraduate studies, Andrew majored in Computer Science at Helwan University.

3. Development Roadmap

3.1. Milestone 1: Research, Proof-sketching, and Algorithm Design

3.1.1. Objectives

  • Establish the core technical framework.
  • Develop the foundational circuits leveraging SPARTAN PLONK as the underlying zero-knowledge proof system.

3.2. TODO Milestone 1 Tasks (2-month period) [1/4]

SCHEDULED: <2024-04-14 Sun>

3.2.1. DONE Milestone 1: (Sprint 1) [2/2]

CLOSED: [2024-03-24 Sun 00:46] SCHEDULED: <2024-02-28 Wed>

3.2.1.1. DONE Milestone 1: Research

CLOSED: [2024-02-28 Wed 15:43] SCHEDULED: <2024-02-27 Tue>

completing a comprehensive literature review of SPARTAN PLONK and zero-knowledge proofs and their intersection with auction theory. What is the current progress on zero-knowledge auctions?

3.2.1.1.1. In (Galal, Hisham S. and Youssef, Amr M., 2019),
  • the bidders submit their sealed-bid as homomorphic commitments on the contract.
  • zero knowledge proof protocols are used to verify the correctness of the claim made by the aucitoneer of some winner.
  • To be precise, no information about the losing bids is leaked
  • The authors also emphasize on how sealed-bid auctions encourage the bidders to bid according to their monetary valuation of the asset. But, at the same time, highlight the conflicting goals of preserving the privacy of the bids and trusting the auctioneer to determine the winner.
  • The authors utilize Pedersen commitment scheme with zero-knowledge proof of interval membership to create the underlying protocol.
  1. Phases of Deployment
    1. Contract Deployment and Parameters Setup
      • Decide \(T_1, T_2, T_3, T_4\), which are the time intervals for four phases:
        • Commitment of bids.
        • Opening the commitments.
        • Verification of the winner.
        • Finalizing the auction.
      • \(F\) defines the amount of initial deposit of ethers received from the bidders and the auctioneer to achieve financial fairness against malicious parties.
      • \(N\) is the maximum number of bidders (they tested their protocol on \(N = 10\))--how does this impact the protocol?
      • \(A_{pk}\) is the auctioneer's public key of an asymmetric encryption scheme.
    2. Commitment of Bids
      • “Each bidder submits a bid commitment using Pedersen commitment scheme along with the initial deposit \(F\) in ethers”
        • A malicious bidder Alice and the auctioneer can eliminate Bob's winning chance by abusing the homomorphic property of the Pedersen commitment--the authors instead use Chaum-Pedersen non-interactive ZKP, details in Section 4.2.
    3. Opening the commitments

      Each bidder \(B_i\) sends the outcome of ciphertext of encrypting \((x_i, r_i)\) by the public key of the auctioneer \(A_{pk}\).

    4. Verification of Comparison Proofs

      The auctioneer orders the bids to determine the wining bid \(x_w\) , the associated account address \(B_w\) and commitment \(C_w\)"

    5. Finalizing the auction

      After the successful verification of correctness, the auctioneer invokes the function VerifyAll […] to change the state of the auction contract so that the winner can pay the winning bid.

  2. Gas Cost

    The upper bound on bid values is up to 250-bit length which is very adequate for financial values. The Pedersen commitment size is 512-bits that represent two points on the elliptic curve.


3.2.1.1.2. \(\star\) In (Zhang, Zijian and Lu, Xin and Li, Meng and An, Jincheng and Yu, Yang and Yin, Hao and Zhu, Liehuang and Liu, Yong and Liu, Jiamou and Khoussainov, Bakh, 2024),
  • The authors emphasize that even though sealed-bid auctions are generally preferred since they do not impact the revenue while maintaining some sort of privacy, the auctioneer can at any time leak the bids or manipulate the results of said auction.

    In a word, the behaviours of the auctioneer can be malicious, once bids are obtained before the bid-opening day.

  • The authors highlight challenges in sealed-bid auctions due to the need to maintain the following four properties at the same time:
    1. All bids cannot be shared to the auctioneer before the bid-opening day.
    2. All bids cannot be exposed to any bidders during the auction.
    3. All the bidders can publicly verify the bid comparison result that is published by the auctioneer.
    4. The whole sealed-bid scheme must be efficient in practice.
  • Particularly highlighted challenges are:
    1. How to compute the winner correctly over ciphertexts while not exposing the bids during the auction?

      How to accurately find the highest bidder among multiple bidders without revealing privacy is the challenge we want to solve.

    2. How to efficiently execute the auction protocol with multiple participants while the underlying secure circuits mechanically compare bids?
    3. How to construct a secure auction protocol while allowing participants to quit during auction?

      Since some users leave halfway may cause the protocol to fail, it is necessary to consider an additional punishment mechanism to restrain their behavior when designing such a system…Therefore, our protocol needs to support the fact that a bidder’s choice to leave the auction even after losing competitiveness will not have an impact on subsequent comparisons.

      Note: The severity (in terms of the computational integrity) of such issue for the zk-auctions toolkit will be determined upon deciding the protocol that will be followed, and the punishment mechanism, should it be needed, will be designed accordingly.


3.2.1.1.3. \(\star\) In (Blass, Erik-Oliver and Kerschbaum, Florian, 2018) , the authors propose a maliciously-secure

blockchain-based auction where all encrypted bids are compared pair-by-pair via homomorphic circuit and the winner is declared by using ZK proofs.

At the heart, we improve Fischlin’s comparison protocol in several key aspects tailored for adoption in blockchains.

  • Very nice work. Section "Dedicated Auction Protocols" could inspire our work.

  • \(\star\) In (Bag, Samiran and Hao, Feng and Shahandashti, Siamak F. and Ray, Indranil Ghosh, 2020), the authors propose an auctioneer-free sealed-bid auction protocol where each bidder has to publish a zero-knowledge eproof about the relationship between com


  • What are the existing gaps?
    • The work of (Galal, Hisham S. and Youssef, Amr M., 2019) does not protect the privacy of bids from all parties including the auctioneer.
  • The output of this task should influence the implementation of the pseudocode in “Algorithm Design”.
    • The following listicle was suggested in (Galal, Hisham S. and Youssef, Amr M., 2019):
      1. "Bid privacy. All bidders cannot know the bids submitted by the others before committing to their own. This property is also guaranteed even in a collusion with a malicious auctioneer."
      2. "Posterior privacy. Given a semi-honest auctioneer, all committed bids are maintained private from the bidders and public users."
      3. "Bid Binding. Once the bid interval is closed, bidders cannot change their commitments."
      4. "Public verifiable correctness. The auction contract verifies the correctness of the auctioneer’s work to determine the auctioneer winner."
      5. "Financial fairness. Bidders or auctioneer may attempt to deviate from the protocol and prematurely abort to affect the behavior of the auction protocol. The aborting parties are financially penalized while honest parties are refunded after a specific timeout."
      6. "Non-Interactivity. Bidders do not participate in complex interactions with the underlying protocol of the auction contract. In fact, no extra communications between the bidders and the auction contract are required aside from the submission of the bid commitments and the associated opening values."
  • <2024-02-15 Thu> 0xisk advised that we steer away from SPARTAN and instead use PSE's Halo2 verifier, which operates on PLONK (Yet to expound on the rationale behind the decision, however it is relevant to this issue).
  • Example of the equations are:

    • \(max(b_1, b_2, \cdots, b_n)\), where \(b_i\) is the bid of participant \(i \in P\), and \(P\) is the set of participants.

    Moreover, the public inputs could either be the winning bid, or the amount the winner required to pay (but the latter may need a different formulation)

3.2.1.2. Questions

(some of which will possibly be answered in later phases of the project)

  • How does the revenue equivalence theorem relate to our work?
  • Will using secure multi-party computation to protect bids from being shared among bidders be efficient?
    • Considered extremely expensive on a blockchain in terms of latency (Blass, Erik-Oliver and Kerschbaum, Florian, 2018).
  • What are the limitations in terms of the number of participants?
  • Will there be any zero-knowledge proofs needed to be designed for particular attribute that a participant must have? E.g., age.
  • How will we handle reserve prices?
3.2.1.3. DONE Milestone 1: Development environment setup

CLOSED: [2024-03-24 Sun 00:46] SCHEDULED: <2024-02-27 Tue>

e.g., configure development tools, version control, package management, and testing modules.

We could use Halo2's simple example as a boilerplate on which we build the other blocks necessary for the toolkit.

3.2.2. TODO Milestone 1: (Sprint 2) [0/2]

SCHEDULED: <2024-05-06 Mon>

3.2.2.1. TODO Milestone 1: (Sprint 2): Technical specification

SCHEDULED: <2024-05-01 Wed>

develop a comprehensive technical specification document, detailing auction types, circuits logic, prospect for integration to larger systems.

  • To the best of our knowledge, there isn't at this point any standard specification for an auction implementation (similar to OpenAPI or VC-Data-Model specifications).

We use the synopsis of the literature review phase to write the Auction Specification Model in an iterative fashion.

3.2.2.2. TODO Milestone 1: (Sprint 2): Test suite development

SCHEDULED: <2024-05-06 Mon>

  • assess the possibility of following TDD for the remaining milestones.
    • <2024-02-24 Sat>: If we use Halo2's simple example, we should be able to follow TDD the moment we complete the Milestone 1, since we will have the equations used in the verifier ready.
    • <2024-03-08 Fri>: Since we've decided the first protocol prototype (meeting on <2024-03-08 Fri>), following TDD is much more doable and is effective for a more accurate progress in Milestone 2.
  • check other open-source projects that could be relevant.

3.2.3. TODO Milestone 1: (Sprint 3) [0/2]

SCHEDULED: <2024-05-25 Sat>

3.2.3.1. TODO Milestone 1: (Sprint 3): Test suite development (cont'd)

SCHEDULED: <2024-05-15 Wed>

  • writing the tests of the circuits which are to be

developed in Milestone 2.

  • The mocking of the identities in testing should handle mainly Ethereum's wallet addresses (potential support for HTTP/2 IP addresses in Milestone 3.
3.2.3.2. TODO Milestone1 1: (Sprint 3): Sketching the Pseudo-code

SCHEDULED: <2024-05-25 Sat>

  • Designing a tentative pseudo-code for the First-Bid and Second-Bid sealed auctions.
  • Explicitly demonstrating how the above-mentioned properties are governed by the circuits in each algorithm.
  • The private and public inputs must be identified.

3.2.4. TODO Milestone 1: (Sprint 4) [0/0]

SCHEDULED: <2024-05-28 Tue>

  • Assess the deliverables of Milestone 1.
  • Reiterate on
    • Algorithm Design
    • Literature Review
  • Lay the schedule and plan for Milestone 2.

3.2.5. Logistics

Estimated Duration: 1 month
FTE: 1
Costs: -
Estimated delivery date: Feb (10-20)th 2024

3.3. Milestone 2: Development

3.3.1. Objectives

  • Develop the core functionality of zk-auctions (e.g., circuits, the various auctions algorithms, etc.).
  • Modular implementation for potential contributions of other auctions types or proof systems.
    • E.g., (circuts/auction_type/protocol/circuit.rs).

3.3.2. Tasks

  1. Core module development: build the main auction system modules, focusing on modular design.
    • At the beginning, we will implement only First-Bid and Second-Bid sealed auction types.
    • Would it be feasible to handle multiple auction protocols? For example:

      zk_auction["type"] = "FPSBA" // First-price sealed-bid acution
      zk_auction["protocol"] = "strain"
      

      or

      zk_auction["type"] = "FPSBA" // First-price sealed-bid acution
      zk_auction["protocol"] = "brandt"
      
  2. Implementation of the auction circuits as specified by the pseudo-code written in Milestone 1.
  3. Modular architecture enhancement: refine the system architecture to easily integrate alternative proof systems.
    • How flexible is it to replace the underlying proof-system?
    • How flexible is it to add a new auction type?
    • How friendly is the codebase for contributors?
  4. Performance Assessment: initial benchmarking for the system performance and privacy. In particular:
    • How long does it take for the proof to be generated and what is its size?
    • Identify performance bottlenecks.
    • How many participants can the system allow before slowing down? What is the potential of the system for being a victim of a DDOS-attack?

3.3.3. Logistics

Estimated Duration: 1 month
FTE: 1
Costs: -
Estimated delivery date: March (10-20)th 2024

3.4. Milestone 3: Optimization, Testing, and Documentation

3.4.1. Objectives

  • Revise the codebase for performance and privacy.
  • Conduct comprehensive testing.
  • Develop detailed documentation.
  • Generate web application.

3.4.2. Tasks

  1. Code optimization: revise code for performance, focusing on the auction logic circuits.
    • Optimize the implementation of the poor-performing components identified in Milestone 2*Performance and Assessment.
    • Compare the number of MAC/TFLOPS operations before and after optimizing a certain piece of code.
  2. Security and functionality testing: perform rigorous security audits and functional testing of all auction types.
    • It will be useful to identify what information has been revealed across the complete auction experience (from participating and bidding to the decision).
  3. Documentation: write technical documentation covering setup, configuration, usage, architecture details, and contributing guide.
    • Using `rustdoc`, write and generate a comprehensive documentation of the implemented toolkit.
  4. Web application:
    • NPM TypeScript library: a Web Worker to port the auction circuits developed in Milestone 2
      • Use `wasm-pack` to generate the corresponding `wasm` code for the auction circuits.
    • Showcase Front-end: create a sample `Next.js` application to the NPM library generated by `wasm-pack`.
  5. Final integration and bug fixes: integrate all components, and address any issues found during testing.
  6. Preparation for release: final preparations for the toolkit's release, including a review of all documentation and code.

3.4.3. Logistics

Estimated Duration: 1 month
FTE: 1
Costs: -
Estimated delivery date: May (20-30)th 2024

4. Additional Information

4.1. Meetings

4.1.1. <2024-02-24 Sat>

4.1.2. <2024-02-28 Wed>

  • We went over the progress of the literature review phase (particularly discussed Strain), raised some questions about the scope of the protocols supported and the engineering design of the toolkit.

4.1.3. <2024-03-08 Fri>

4.1.4. <2024-03-31 Sun>

  • Revised and merged the pull requests regarding the engineering aspect of the repository.
  • Discussed that we might need to use a proving server, however, it is a decision that should be made after benchmarking the runtime of the circuits.
  • The tests should be adapted from the Strain paper and completed by Tuesday.
  • The next step should be outlining the private and public inputs, the equations to be verified by the circuit as a warm up for Milestone 2.

4.1.5. <2024-04-28 Sun>

  • Rescheduled the timeline of the milestones.

Agenda:

  • Andrew would like to discuss the phases of the a with @0xisk as defined in (Galal, Hisham S. and Youssef, Amr M., 2019).
  • Rebase the git-hooks branch against main.
  • Deciding whether we should start with Strain as the first protocol.
  • Outlining the Auction Specification Model

Notes:

  • Andrew to move the index page inside docs.
  • The need for a modular design is put aside for now until we have a mature implementation of at least one protocol.
  • @0xisk: it'd be very nice if we could leverage mobile devices in our framework.
  • We will start by implementing Strain.

4.3. Technical Notes

During the development of this project, technical notes were developed in a separate document as to supplement the current one and in order to have a self-contained documentation of the workflow since day one.

5. Bibliography

Bag, Samiran and Hao, Feng and Shahandashti, Siamak F. and Ray, Indranil Ghosh (2020). SEAL: Sealed-Bid Auction Without Auctioneers, IEEE Transactions on Information Forensics and Security.

Blass, Erik-Oliver and Kerschbaum, Florian (2018). Strain: A Secure Auction for Blockchains, Springer International Publishing.

Galal, Hisham S. and Youssef, Amr M. (2019). Verifiable Sealed-Bid Auction on the Ethereum Blockchain, Springer Berlin Heidelberg.

Hal R. Varian (1995). Economic Mechanism Design for Computerized Agents, USENIX Association.

Zhang, Zijian and Lu, Xin and Li, Meng and An, Jincheng and Yu, Yang and Yin, Hao and Zhu, Liehuang and Liu, Yong and Liu, Jiamou and Khoussainov, Bakh (2024). A Blockchain-based Privacy-Preserving Scheme for Sealed-bid Auction, IEEE Transactions on Dependable and Secure Computing.

Footnotes:

Author: ndrwnaguib and 0xisk

Created: 2024-05-01 Wed 20:21

Validate