Dealing with spam caused by on-chain searching

We have seen a spamming dynamic on chains like Base and Solana in which searchers will fire off very many transactions, each with a very high probability of reverting and only capturing every now and then.

The exact conditions that lead to this aren’t super well studied but it is likely driven by some combination of

  • cheap gas
  • high uncertainty. E.g. because the chain is very low-latency or because mempool is private

Depending on your goals, blocks filled with reverting transactions can be problematic for chains. Presumably there is some limit on throughput coming from the need to limit state growth, limit block size for propagation, fit data into available blobspace or to allow community-run fault provers to keep up. Thus TPS is limited and ideally the limited resources are used in an effective way. I will proceed assuming that the sequencer (block builder, leader etc) throughput is not the bottleneck. I am also assuming that transactions/the block is simulated before being propagated by the sequencer.

Here I am collecting some ideas to deal with this dynamic. These have all been floating around for a while, but I don’t know if they’ve been written down in a public way before.

1. Separating resources

We can use up more of the sequencer/builder’s resources to protect the actual bottleneck. We do this by offering an opt-in RPC endpoint. Transactions sent to this endpoint can never revert (we can create a new transaction type for this if we want to be more secure). If they revert, they must not be included in the block that is propagated to the network. With regard to ordering, the transactions are treated the same as normal transactions (or “better” - detailed in 2).

Without any additional rules, this endpoint would see an even greater transaction load from searchers who have nothing to lose by sending more transactions. In order to avoid overloading the sequencer, we require each of these transactions to come along with a payment in a payment channel to the sequencer. As long as the fee required is lower than the gas fee, it should make sense for searchers to use this endpoint, letting only successful transactions reach the bottleneck. Another way of handling DoS of non-reverting transactions would be through the reputation systems which builders deploy today, although it feels less clean.

Further work/critiques

  • How do we deal with gas payments for successful non-reverting transactions? Do we require them to pay gas separately from the payment channel or does the get included with the successful tx?
  • One may argue that this is shifting the equilibrium strategy that is less decentralised as there is now a greater trusted relationship with the sequencer not to claim payments without simulating transactions. I am not convinced that this is much stronger than what the sequencer can do already. We can also try to ameliorate this with TEEs down the line.
  • How to set the fee is a bit of an open question. This depends on sequencer capacity.

2. Provide more information

Searchers are firing off transactions hoping that an opportunity opens up before their transactions land and that they will be the first access this opportunity. If the sequencer knew what they were after we could change that dynamic.
We introduce a new transaction type (longer discussion by @dmarz ) in which users declare some conditions under which the transaction must be simulated - e.g. if the ETH-USD Uni pool price moves. Now these transactions will at least execute when there is a higher chance of them succeeding.
However, we now have a new problem: when a user sends a ETH-USD transaction, the sequencer suddenly has to deal with many pent-up transactions. We can deal with this by only ever executing the highest paying k (K=1 being the simplest).
Assuming this works, searchers are much less likely to fire off transactions hoping that they will land in the prime spot because one of these bidding transactions will be prioritised. It makes more sense to directly compete in the auction (ideally).

One alternative design following the same idea is to expose more real-time information to searchers and run the auction in a “just-in-time” manner. One problem with this (see Jito’s mempool) is frontrunning concern, which can be mitigated with MEV-Share like privacy. The other is that doing this kind of processing in the “hot path” can incur additional latency for users. There is a balance to be found between optimal information exposure for auction revenue, latency and user protection.

On the opposite end of the spectrum we find protorev on Osmosis in which there is a fixed backrunning algorithm that is executed after user swaps. This is simpler albeit likely less effective than an auction. Eventually, a similar approach can be used to provide better routes for users instead of collecting arbitrage.

Further work/critiques

  • This idea still needs a bunch more work.
  • How do we optimally partition opportunities? Is it just by state access? What kind of a combinatorial auction works for this setting? We can definitely get quite complicated on the auction if we feel like its worth it…
  • Searchers may still be incentivised to spam given that the auction winner(s) may not succeed in capturing the opportunity.
1 Like

Can the gas be higher for transactions that revert?

1 Like

I am assuming that gas for transactions that CAN revert is higher than for those that can’t.

I say that although I suspect you’re asking if the price per unit gas for a reverting transaction can be higher than for the same tx that did not revert. I suspect that makes sense. If you take it too far you would probably end up with people finding work arounds to do nothing and you punish all the “normal” users.

1 Like

Right, I see the workaround now. Oh this is awful :person_facepalming: please fix :smile:

Hi @Quintus

I’ve been iterating a bit on this subject as well. Uncertainty around the when and what of state deltas can lead to spam, and many of the “auction” paths applied to them may not have enough time to run if there are shared state dependencies.

One flavor of solution that I’ve been intrigued by lately is the ability to increase the cost of spam disproportionately for spammers.

I talked about it in a video and I can’t find the deck but let me know if you’re interested - I’m always down to jam on this subject.


Nice idea! I agree the biggest obvious challenge with your idea is to keep UX good while hampering spambots. I’m curious what those numbers look like in practice.

I would describe your idea as purely tweaking economic mechanisms while those I listed are shifting around the resource consumption between diff roles in network

1 Like

Agreed! I think the two approaches are complimentary.

1 Like