Can First Come First Served-Based Transaction Ordering Prevent Front-Running?

Feedback and discussion on the article. Since this post was created a few days after the article, comments were happening on Twitter so far:


Hey, I thought your article was interesting to read, thanks for writing it.

Have you read Kelkar et al’s latest research regarding Themis?

Would that change anything in your article or would your view stay the same?

1 Like

Great question. I’ve read the Themis paper before, and it is certainly of high quality, improving upon previous work. However, Themis works only in the permissioned setting and the front-runner’s abilities are again not properly defined, so that my view (as argued in the article) remains.

1 Like

It feels like most of this stems from the assumption that the attempted-frontrunner is able to receive and submit a transaction and have it propagated before the original transaction fully propagates. If that is not possible then the later conclusions are trickier to come to.

In which case, I see a couple of requirements/options:

  1. The frontrunner is able to receive the transaction before it has already propagated to a large proportion of the validators.
  2. The frontrunner then has some method of transmitting their transaction to other validators significantly faster than the original propagates.

For these to be the case, it would seem (to me) like there also has to be significant validator collusion. Validators would have to be connected to some optimised connection between themselves and potential frontrunners.

Alternatively, a frontrunner themselves might have a fast connection between point A which is close to the original transactor and point B which is close to some large cluster of validators. Without collusion this seems the most feasible method, so perhaps one answer here is to incentivise geographic/network distribution of validators to avoid these centralisation nodes.

Either way, avoiding the frontrunner having that capability seems one way of cutting this knot.


Why do you say Themis only works in a permissioned setting?

My understanding was that Themis can be theoretically implemented on Ethereum, which is permissionless. I expect Themis to be implemented on an optimistic rollup though and none of them are anywhere near to being permissionless in the short term, but have the potential to be in the longer term, which is maybe too far of a timeframe to think about at this time.

Yes, I think this summarizes front-running nicely.

A front-runner can just optimize its node’s position in the network and connectivity to other validators such that the front-running transaction propagates quicker than the original transaction. Validators don’t need to collude for that, but if they do, the front-runners life gets even easier.

That’s an interesting point. How could such restrictions be enforced in a permissionless system?

Great point! I have to re-read the Themis paper. If it indeed works in a permissionless setting, as you say, I have to retract my statement from before that it only works in a permissioned setting.
Nevertheless, the article doesn’t focus on a specific FCFS implementation but generally on FCFS ordering protocols. The claim is that the achievable granularity in FCFS-ordering is fundamentally limited by end-to-end delay uncertainty. The achievable granularity in permissionless settings is so coarse grained that FCFS-ordering can only mitigate some front-running, but not prevent it. In order to improve the granularity of ordering in FCFS (such that front-running is largely mitigated), end-to-end delay uncertainties need to be reduced, which leads to permissioned and trusted settings.
So there is a trade-off between how permissionless/permissioned a future rollup with FCFS-ordering is and how much front-running it can mitigate.

1 Like

more discussion on the post here that links to the arbitrum post! Designing FCFS-based ordering protocols