How to run NFT auction in Hydra Head?

[ghost]

NFT drops can be a real problem when run on L1, generating a lot of Utxo and transactions in a short amount of time, clogging the network and leading to congestion and general slowdowns. The problem seems to come not much from the NFTs themselves but from the large of number of bidding transactions people post to grab some.

I sketch a way to run NFT auctions inside Hydra Head that would alleviate that problem. Here is an outline of the sequence of transactions involved, both on-chain and off-chain:

• auctioneer forges some "participation tokens "representing participation in an auction for some NFT
• auctioneer commits the PTs in a Head (these are not the PTs of the Head)
• The Auction PTs can be "grabbed" by bidders to bid some amounts for a given NFT auction
• the bidders do not have to be Head parties, they just do "normal" cardano transactions to grab a bid token and then possibly keep bidding until the auction ends
• The auctioneer posts a settlement transaction that consumes all current bids at some point, producing a voucher for the NFT to be sent to Bob if he pays V2'. The voucher is only valid if produced by this script, and there might be some reserve price to ensure price does not fall below some threshold
• Then Head is closed and the voucher is posted on-chain
• Bob can redeem his NFT, paying V2' to the auctioneer.

The auctioneer runs the risk of opening/closing a Head with the winner not reclaiming his NFT. If it does not run the head itself, it runs the risk of the Head parties rigging the auction but worst case, the Head is closed with someone having a voucher to claim the NFT at reserve price, or the NFTs themselves are paid back to auctioneer.

The bidders run the same risk of bidding in a rigged auction but worst case, they can refuse to pay for the NFT.

[kk-hainq]

Nice thread!

• The Auction PTs can be "grabbed" by bidders to bid some amounts for a given NFT auction
• the bidders do not have to be Head parties, they just do "normal" cardano transactions to grab a bid token and then possibly keep bidding until the auction ends

Can you elaborate on these steps? If the bidders aren't, then who are the head parties? How does one "keep bidding", and is that on layer one or two?

[ghost]

If the bidders aren't, then who are the head parties? And does "keep bidding" happen on layer one?

The Head is initialised by the auctioneer. It could be a "Managed Head" or "Head-as-a-Service", eg. the auctioneer does not run a Hydra node but uses some thirdparty provider to run the node. A single-party head might not seem to make much sense but in
this case it's just a way to do Cardano transactions with SCs faster than on the mainchain.

About bidding: My initial idea was that the bidders would connect to the Head through this HaaS thing which would provide them a client connection. This could be achieved through a Lightwallet architecture for example, where the end user is more or les
s unaware she is talking to a Hydra head and is interacting with an application. The auction tokens are Plutus scripts than can be spend by anyone but only if the transaction has a single output to either: another script which pegs the token to a speci
fic user key for the duration of the auction. This script can then be consumed either by the bidder with an obligation to increase her bid, or by the auctioneer as part of the settlement transaction.

Thinking of it, this makes it easy to "game" the auction as nothing prevents the bidders from pledging any amount given they won't be forced to pay for it anyway. A simple countermeasure to this would be to have the bidders be part of the Head and comm
it a "Cap amount Utxo" proving they have enough funds when bidding. The drawback is that this would mean the bidders would also have to sign the snapshots. Given that if the auctioneer does not post the last settlement transaction, nothing happens, the
bidders are not incentivised to cheat and refuse to sign a snapshot.

Another option would be for the bidders to designate a Utxo they own on the mainchain as part of the "grabbing" transaction, proving they can pay for their bid. This could even be done several times during the auction. When posting the settlement trans
action the auctioneer can "easily" verify the existence of the "collateral" Utxo and reject fantasy bids. This does not guarantee the winner will pay, only that he or she can pay for it.

[kk-hainq]

At a glance, I don't think the current Hydra Head protocol can do auctions well. Disclaimer: I've never done auctions before, the following ideas might be straight wrong or miss cases left and right.

If bidders don't commit "payable" assets and join the head themselves, no one can guarantee their commitment as you just pointed out. If off-chain guarantees are in place, like with paper contracts, the auctions can just happen offline. Players not joining the head usually means a centralized or custodial design anyway.

When everyone joins the head.

• If all signatures are required, the first accepted bid can refuse to sign further bids and close the head to claim the NFT at the cheapest possible price. Requiring a settlement transaction with the signature of the auctioneer won't help, as the accepted bidder wouldn't accept to continue anyway, rendering the head useless giving everyone a net loss due to head fees. Therefore, from the auctioneer's perspective, it is okay to accept even just the first bid as it is still a net gain, that is above the starting price. In conclusion, either bidder won't sign others' bids, or the auction will just end with the first bid, making the head overheads wasteful.

• If n - 1 signatures (or fewer) are required, the auctioneer can collude with other bidders to instantly complete the auction with the bidder who has committed the most assets. This leads to everyone committing what they are willing to pay, and the result can be instantly resolved on layer one, the head is again a waste.

From my experience working on ad-hoc variants of Hydra, I think the first step in designing state channel solutions for dApps should be visualizing the "relationship graph" between parties. The complete graph of Hydra Head is difficult to guarantee for obvious reasons. It looks complex and inefficient, too.

(Shamelessly copy-paste from Wiki...)

It would be nicer if we could simplify it, to a tree or something simpler. For instance, our Eco Hydra would approach auctions like so:

(Shamefully draw my own with Paint...)

The key is that all bidders don't have to care or communicate with each other. First, the auctioneer locks the NFT on-chain for a pre-defined amount of time so there are no time-based traps for anyone, and that no one can close the head to kick everyone. Anyone wanting to join the auction can lock assets to the same script to join the P2P Eco Hydra network. Bidders can verify messages from the auctioneer through the public key locked with the NFT, and don't have to care about others. Bidders then constantly send bids in a P2P manner to the auctioneer, a bid is a transaction that claims the NFT and sends back assets to the announced public key. The auctioneer can easily verify a bid, and sign then post one to layer one to complete the auction. In this game, the auctioneer obviously wants to maximize the assets they get, so instead of taking the first one, he can broadcast the best bid thus far to the remaining bidders. Bidders can easily verify these bids and counter-bid if they want. By the time the auction ends the auctioneer signs on the best bid and broadcast it to layer one. The bidders can safely broadcast signed transactions because they indeed require the NFT to be claimed.

This design removes the trust connections between bid nodes, and only requires two signatures and one edge to progress (2m TPS confirmed!?). It's not very cool as it's not complex or general enough for all use cases, but it is indeed a lot easier to guarantee and practical in specific use cases like auctions.

Again, I've never studied auctions in-depth so I might miss a few things, like the auctioneer being a bidder himself to rig things (can be prevented by adding a TTL to each bid?) and whatnot. Interesting game.

[kk-hainq]

A friend at work told me that the head protocol with few modifications can support the tree-shaped design.

Indeed, it can achieve so by opening a head between the auctioneer and every bidder. The overheads are non-trivial, and we would need unnatural hacks like having multiple vouchers to represent the same object at auction, enforcing reputation-based collateral to prevent the auctioneer from accepting several bids to sell several vouchers for the same object, etc. Nevertheless, It can indeed progress with two signatures and one head as edge.

Since this is not our core product, we are happy to use it as the first case study and demo for our Eco Hydra on Nervos, which should be ready next month. We can do the same on Cardano afterwards, hopefully, ready by the end of January.