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?


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.

  • 1
    My point is that those attacks are much easier with eUTXO/Cardano than on Solidity. It is incredibly expensive to "stall" the Ethereum-mainnet for multiple blocks, whereas it is much cheaper to re-generate a single Cardano-UTXO over multiple blocks. So the defense becomes more important because the attack-tresholds are lower.
    – Mike76
    Sep 13 at 9:39
  • 1
    Minimum bid increases are doable, but I still find it problematic if you compare it with Ethereum. I strongly believe that there should be a more general solution which increases the cost of conducting DOS attacks. Those attacks will always be theoretically possible, but we need to think about the cost of performing the attacks.
    – Mike76
    Sep 13 at 9:49
  • 1
    Many of the people complaining about the UTxO model only think that Ethereum has less problems because they don't understand what happens there behind the scenes. I personally think that the issues of Ethereum are unfixable. The fact that you can write your question above shows how transparent the Cardano model is and how it allows developers to reason about it and think about what could go wrong and what can be done about it. The only way to prevent DoS in open networks is to make them expensive or difficult. UTxO are not more vulnerable than other models.
    – Jey
    Sep 13 at 10:52
  • 1
    I am definitely not a chain maximalist since different models have different tradeoffs. I would not claim that Ethereum is better, but I am interested in this particular concurrency-attack.
    – Mike76
    Sep 13 at 11:51
  • 1
    He would gain by winning the auction when the deadline is reached.
    – Jey
    Sep 13 at 12:28

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.

  • People are talking about how order-book style DEXs are going to be more popular on Cardano because it fits the UTxO model better than the Ethereum accounts model. It would work similarly to what I just explained, however a DEX has a Many-to-Many market, unlike an auction which is Many-to-One. So a DEX is a little more difficult to architect than an auction. Sep 18 at 4:14
  • Thanks for your detailed answer. I see several drawbacks with separate UTXOs. Firstly, the need of longer locking periods. Secondly, the highest bider does not automatically win, which might lead to more corruption. Sure, all of this can be solved, but I don‘t know whether all those eUTXO troubles are worth the effort.
    – Mike76
    Nov 17 at 0:30
  • I don't see the eUTxO model as a problem to be solved. I see it as a way to move the complexity of safety to a lower level. There have been billions of dollars lost in Solidity contracts that could have been prevented with the restrictions Plutus has. And those Solidity contracts aren't less complex, Solidity just has a lower barrier to entry to Plutus. Best of all, it gives an dApp developer options. Nov 17 at 0:49
  • I agree that Solidity has too many bugs right now, but those can be solved. For example, reentrancy bugs can be prevented with compiler-inserted locks, although those locks have some gas-cost-overhead. For Plutus, however, we still need to ask the feasibility question: Is it even feasible to build an atomically composable DeFi-ecosystem with Plutus? I mean not only a DEX, but a composition of complex protocols like flash-loans
    – Mike76
    Nov 17 at 21:39
  • One more sidenote: Just because someone like SundaeSwap has a workaround for the concurrency-problem does not mean that the problem is solved. In contrast, the following "Scooper model" questions the ability of eUTXO to run a truly decentralized DEX without any off-chain-sequencer or sidechain: sundaeswap-finance.medium.com/…
    – Mike76
    Nov 17 at 21:44

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.

  • 1
    Yes it is related to the concurrency issue, but it's not exactly the same. For example, I could imagine a DEX that solved the regular concurrency issue with a decentralized auction-order-book, but is still vulnerable to economic DOS attacks within its order-book.
    – Mike76
    Sep 13 at 15:11

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.


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.

  • Thanks for the detailed proposal. One more question about your proposal: How can you withdraw a losing bid very fast? It would not be good to lock all losing bids until the the entire auction is finished
    – Mike76
    Nov 17 at 0:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.