a16z / auction-zoo

A menagerie of auction mechanisms implemented in Solidity

The Auction Zoo

Whereas auction formats were once loosely adopted for (and constrained by) the technical limits of blockchains, we’re now starting to see more novel designs adapted especially for blockchains. This repository aims to help bridge the gap between auction theory and practice by showcasing Solidity auction implementations that demonstrate interesting theoretical properties or novel constructions.

How can theoretical principles inform implementation decisions? And how can on-chain implementations, in turn, inform new directions of theoretical research? Though theory can guide us toward a certain auction design, a seemingly innocuous implementation detail itself may be interesting to analyze with a theoretical lens.

The auctions are implemented as single-item (ERC721) auctions, with bids denominated in ETH, though we encourage forking to add or change features, e.g. multi-unit auctions, ERC20 bids, different payment rules.

Contents

• Sealed-bid auctions
  • Overcollateralized Vickrey auction [post]
  • "Sneaky" Vickrey auction [post]
  • Aztec Connect Vickrey auction [post]

Accompanying blog posts

1. On Paper to On-Chain: How Auction Theory Informs Implementations
2. Hidden in Plain Sight: A Sneaky Solidity Implementation of a Sealed-Bid Auction
3. Through the Looking Glass: A Cross-Chain Sealed-Bid Auction Using Aztec Connect

Usage

Requires Foundry.

Install: forge install

Build: forge build

Test: forge test

Disclaimer

These smart contracts are being provided as is. No guarantee, representation or warranty is being made, express or implied, as to the safety or correctness of the user interface or the smart contracts. They have not been audited and as such there can be no assurance they will work as intended, and users may experience delays, failures, errors, omissions or loss of transmitted information. THE SMART CONTRACTS CONTAINED HEREIN ARE FURNISHED AS IS, WHERE IS, WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON- INFRINGEMENT OR FITNESS FOR ANY PARTICULAR PURPOSE. Further, use of any of these smart contracts may be restricted or prohibited under applicable law, including securities laws, and it is therefore strongly advised for you to contact a reputable attorney in any jurisdiction where these smart contracts may be accessible for any questions or concerns with respect thereto. Further, no information provided in this repo should be construed as investment advice or legal advice for any particular facts or circumstances, and is not meant to replace competent counsel. a16z is not liable for any use of the foregoing, and users should proceed with caution and use at their own risk. See a16z.com/disclosures for more info.

auction-zoo's Issues

createAuction for an existing auction does not check msg.sender==auction.seller

nevermind I missed transferFrom call which would revert. Time for some sleep I guess.

Parallelized Auction

Arcology is an EVM compatible L1 that has ability to process multiple transactions simultaneously. We have built Solidity APIs to help contract developers take full use of our parallel design. We have successfully parallelized some applications like CryptoKitties and DSToken using these APIs. We are currently working on parallelizing collateralized auction.

Parallelization
Parallelization means rewriting the code so that the system can process multiple transactions calling the same interface of the same contract in full parallel without having any problem.

Source Code
The source code is here. Please let me know if you have any questions or comments. Will let you know once it is done.

Balance proofs on goerli testnet

I checked and resolved my earlier (unedited) issue.

Just adding quick (other) note:
When running on goerli testnet - ethereumjs throws error "EIP1559 not supported" when genereting proofs. So need to update common parameter to add EIP1599 support.

Thoughts about potentially leveraging ERC-5732 Commit Interface?

Hi, thanks for @sbacha's sharing, I came across this repository.

For this line

auction-zoo/src/sealed-bid/over-collateralized-auction/OverCollateralizedAuction.sol

Line 190 in dd47927

function commitBid(

    function commitBid(
        address tokenContract, 
        uint256 tokenId, 
        bytes20 commitment
    ) ... { ... }

I like to get some feedback about thoughts on considering also supporting ERC5732 Commit Interface

    function commitFrom(
        address _from,
        bytes32 _commitment,
        bytes calldata _extraData)
    payable external returns(uint256 timePoint) {
             ...
    }

For example, it can be done by adding

    function commitFrom(
        address _from,
        bytes32 _commitment,
        bytes calldata _extraData)
    payable external returns(uint256 timePoint) {
             address tokenContract = _extraData[0:20];
             uint256 tokenId = _extraData[20:52];
             _commitBid(address tokenContract, uint256 tokenId, bytes20 commitment);
    }

The benefit is in the future if we want to expand this OverCollateralizedAuction to other type of assets, e.g.
ERC1155, we could also add amount

    function commitFrom(
        address _from,
        bytes32 _commitment,
        bytes calldata _extraData)
    payable external returns(uint256 timePoint) {
             address tokenContract = _extraData[0:20];
             address tokenId = _extraData[20:52];
             uint256 amount = _extraData[52:84];  // Newline to support ERC1155
             /*a newer version of*/ ... _commitBidERC1155(address tokenContract, uint256 tokenId, bytes20 commitment);
    }

And thus mobile or web clients who have been built to commitFrom would be able to support this change with backward compatibility.

Thanks!

Extending to ERC20's

Cool repo. In the case of (create2-based) SneakyAuction, at auction end you could potentially deploy preset bytecode to transfer/sweep an ERC20 to the highest bidder, and similarly for withdrawing to non-winning bids back to the original account. Is it possible/did you consider this and what if any difficulties did you foresee?

80bit collision attack on `bid.commitment`

At the moment, bid commits are truncated to 160 bits: bytes20 bidHash = bytes20(keccak256(abi.encode(nonce, bidValue)));
Bidders control their nonce and bidValue and thus, it is possible to find two bids (one with a large amount and another with a small amount) with the same hash by just offchain retrying/playing with the nonce value.

Then, based on the 2nd highest bid, they can decide if they open the commitment with the large amount (to win the auction item) or the small amount (to get refunded).

Although it's an expensive attack, it's theoretically feasible with today's CPU power. Unfortunately, the attack is also reusable. The current smart-contract design does not apply any domain separation flag in the hash-inputs, which implies that an adversary can find one such collision and reuse it in different auctions. Well, if one reuses commitments between auctions, others can spot this if they do analysis in past transactions for matching commitments, but that's a detail. Including the auctionID in the hash inputs would be preferable as a hygiene solution to avoid such edge cases.

PS: obviously for the attack to make sense, one should consider the energy + resources cost of a 2^80 collision, thus it would only matter in practice for very expensive auctioned items (or reuse many times), but still; cryptographically, the advertised security of the current auction contract is considered to be @80bits, which is not ideal.

To sum up: a straightforward proposal is
a) do not truncate the commitment hashes.
b) add auctionID as hash input to the commitment derivation, to avoid reusing the same commit in different auctions.