How to prevent economic DOS attacks against Plutus contracts

Question

Many people wrote about the eUTXO model and the benefits it brings compared to Ethereum. However, eUTXO also comes with some challenges. In particular, eUTXO is susceptible to "economic denial of service (DOS) attacks".

Let me give you an example of an economic DOS attack. Consider the following NFT-auction from the Plutus pioneer program: https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week1.html This contract is a simple auction where anybody can bid for an NFT until a specified deadline has passed. However, this contract is vulnerable to an economic DOS attack where a malicious bidder creates a sequence of low bids that prevent other people from placing their bids (e.g. 0.001 ADA, 0.002 ADA and so on). Such an attack is possible because each eUTXO can be spent only once, and if the attacker is faster than you, then you fail to place your bid on the Cardano blockchain.

It requires some technical sophistication to execute an economic DOS attack, but an average (non-technical) wallet-user cannot defend against it. Although economic DOS attacks are also possible on Ethereum, it is much harder to execute them successfully within Ethereum's account model.

See the following paper for more details about economic DOS attacks: https://docs.google.com/document/u/0/d/12atK0oEME0y1GHo_HmqhrcZ3pQeEqB_0tFKknhsjsLY/mobilebasic

So my question is: (1.) How would you implement a Plutus-NFT-auction that defends against economic DOS attacks and (2.) how would you generalize a defense-pattern for other Plutus-contracts?

Answer 1

These types of attacks are inherent to the auction model and are not dependent on the technology used. To protect against these, auctions have a minimum bid increase. Other solutions would be (i) a whitelist of known wallets making sure that every participants has at most one wallet, or (ii) bidding fees making DoS attacks expensive.

If you want to run an auction without identity control opened to the general public, minimum bid increases would be the way to go, in my opinion.

Answer 2

I can think of a different way to structure the contract to avoid this attack.

If you allow all the bidders to lock up their funds at the same time, in separate UTxOs, the auctioneer could just choose which to accept when the deadline has past. This works in Plutus because you can redeem multiple datums in a single transaction, and have the validators check that the other UTxO is being spent, i.e. the PickWinner redemption path for a Auction datum would requires a Bid datum get redeemed as well, and vice-versa.

And say someone wants to update their bid, the Bid datum would have a redeemer of Update, otherwise your funds are locked until after some grace-period has passed.

This might come with some drawbacks, like the opportunity cost of all the losing bids being locked up, but I can think of ways to minimize those pain. In many cases, it seems like a reasonable cost to pay regardless.

Answer 3

I think it boils down to the concurrency issue that's been floating around recently. When that's solved (which some projects claim they did), this problem goes away.

Answer 4

How would you implement a Plutus-NFT-auction that defends against economic DOS attacks?

My approach is a little bit complex, since it involves thinking about the problem in a very different way, so sorry for that.

Instead of having a unique UTxO to handle bids, you could create an "account" script. So each user that want's to be part of an auction would need to create an "account", sending the bid value (e.g. 100 ADA) or the auction value (e.g. random NFT) to this account address (creating a new UTxO).

The datum would also be important, since we don't have a way of looking at the value and knowing if it's an auction or a bid and, if it is a bid, we don't know what auction is it bidding on. Therefore the datum could hold a special data type that, if it's an auction, should indicate what is being auctioned and what the deadline is and, if it's a bid, should indicate the value being offered and the auction which it's part of.

Example

data AccountDatum = Auction Value POSIXTime | Bid Value Auction

One problem you could see is that we are still not able to identify who is offering what (since we only have values inside the datum and not public keys). Also, anyone can create any arbitrary Datum in a newly created UTxO. Therefore, we need a way of "authenticating" these UTxOs and "stamp" them, signalizing who the owner of the account is.

This can easily be done with minting policies, as they can execute arbitrary logic without consuming any UTxOs (preserving concurrency). In our case, our policy should make sure that the datum is not corrupted, that the token name it is minting corresponds to the user's public key hash (since we want to identify the owner) and that the minted amount is being transferred (and locked) to the right script (our account script).

After all this is done, the account script can handle transactions however you want. For example, the auction bidders shouldn't be able to change their bid for a smaller amount or retrieve it before the auction deadline is passed. Also, no DOS would be doable since only the owner of this account and the owner of the auction he is bidding on could consume this UTxO (and only if certain conditions are met).

Bidders would be able to compare their bids with other by verifying (off-chain) what other valid accounts are offering. The auction seller would, after the deadline, be able to consume one account UTxO from a bidder by giving it the desired NFT or token of any sort.

how would you generalize a defense-pattern for other Plutus-contracts?

I believe this "account model" (unfortunate name lol) is very general, I'm using it in a project I'm working on that has nothing to do with auctions. The main idea you should keep in mind when designing a validator script is to create multiple UTxOs that can only be consumed by the people interested, so if a DOS would happen, it would only affect the attacker him-self.