Skip to content

Conversation

@MoonShiesty
Copy link

No description provided.

@MoonShiesty MoonShiesty changed the title revert-sip-45 SIP: revert SIP-45 Feb 24, 2025
@MoonShiesty
Copy link
Author

MoonShiesty commented Feb 24, 2025

one potential mitigation to MEV that has been proposed are "bait" transactions

these are widely considered illegal transactions in jurisdictions with robust securities laws and are not a viable approach to mitigating MEV for both legal and practical reasons

source: https://www.coindesk.com/policy/2024/05/15/brothers-accused-of-25m-ethereum-exploit-as-us-reveals-fraud-charges

@mystenmark
Copy link
Contributor

Hi and thanks for the sip! There are two purely factual things we need to clear up about this discussion:

  1. Ordering by gas price is not part of SIP 45. That was added very shortly after mainnet launch in this commit: MystenLabs/sui@1009fed
  2. Even if SIP 45 is reverted it is fairly easy for submitters to achieve the low commit latency provided by SIP 45 by submitting multiple transactions.

Explanation of 2:

The way SIP 45 works is by inducing what we call "consensus amplification". Normally, each transaction is submitted to consensus by only one validator. This is done pseudo-randomly based on the transaction digest. SIP-45 simply says that if a transaction has gas price > 5 * reference_gas_price, it will be submitted by more than one validator, according to the RGP factor. This helps the transaction get into the earliest consensus commit possible, instead of being potentially randomly delayed. This means that without SIP-45, you can simply submit multiple versions of the same tx, each with a different gas coin and achieve the same effect, specifically that at least one of them will get committed very early with high probability.

@MoonShiesty
Copy link
Author

MoonShiesty commented Feb 25, 2025

@mystenmark thanks for the response. looks like i have conflated some different issues. after rereading the SIP and rethinking the issues here is are my thoughts, i will update the PR to reflect them if they you think they make sense:

  1. i believe ordering by gas price within a consensus checkpoint is a bad idea

this is largely why i authored this PR. i believe deterministic ordering exposes users the maximal amount of toxic MEV while not achieving its goals of maximizing value to stakers

the specifications sections of the PR were meant to address a replacement to deterministic gas ordering within a consensus checkpoint

  1. i believe SIP-45 is a good idea

as you mention, the alternative is spamming the network in attempts to land a transaction first

however this does provide a mechanism for searchers to predictably land a frontrun and/or backrun within the same consensus checkpoint, exposing users to issues with the design of (1)

at a high-level the issue with the current approach, is that the start of a checkpoint is often not the most valuable position within a checkpoint

for arbitrage and other games that reward the first to land a transaction, the first to access a shared resource will always be the most valuable. as designed, ordering by gas price works in this case except that:

for searchers who want to land a frontrun, or a backrun on a targeted transaction, the most valuable spot is +-1 position from the targeted shared object. its not the start of the block, especially if there's competition for the same target

SIP-45 also has the effect of giving searcher similar jitter to the target if their gas paid has the same amp factor as the target, capping the maximum a searcher can pay to frontrun a target

this should be considered when designing a way to order transactions within a block, because frontrunners can't exceed the target's amplification threshold

in these cases, ordering by gas price does not provide a mechanism for stakers to maximize value, because arbitragers will always pay +-1 unit of gas of the target

and it doesn't provide a mechanism for searchers arbitraging to protect against being frontrun/backrun themselves

an ordering mechanism that can reflect these dynamics is required. the issue with the current order design was exposed by SIP-45 and the combination of the shio speedbump and shio feed, but is not a reason to revert SIP-45

instead we should explore an alternative way to order transactions within a consensus checkpoint, and leave SIP-45 as is

  1. i believe SIP-45 increased the max gas unit price. this is very important for MEV and should not be reverted

@mystenmark
Copy link
Contributor

for searchers who want to land a frontrun, or a backrun on a targeted transaction, the most valuable spot is +-1 position from the targeted shared object. its not the start of the block, especially if there's competition for the same target

If there's competition for the same target, front-running should devolve to blind PGA. The second-in-line attempted front runner will either have to revert or become the new victim, no? So the incentive is to be as early as possible, right?

@MoonShiesty
Copy link
Author

MoonShiesty commented Feb 26, 2025

its worth mention, SIP-45 introduces a cap on bidding wars since frontruns cannot exceed the amp factor of the target

this means if the market is competitive, the first searcher in a block will be decided by tie breaking rules

its not clear to me if the start of the block or -1 position of a target is better

any other position within the block exposes the frontrun itself to MEV

i think a searcher can craft their frontrun, to execute a backrun instead in the case its being frontrun

@mystenmark
Copy link
Contributor

its worth mention, SIP-45 introduces a cap on bidding wars since frontruns cannot exceed the amp factor of the target

I don't think this is really true - bidding the same does not guarantee you get in the same commit round. Even if both transactions are subject to the same amount of jitter, the jitter is independent for each. One or both could be early or late just by chance. You may as well just bid high to ensure that you are in front of the target.

In any case, there is a planned change to the mysticeti commit rule which will stop privileging leader blocks so much, at which point only a small amount of consensus amplification (probably <10x) should be necessary to be committed early.

It's important to understand that the whole topic is highly dependent on implementation details like this which will continue to evolve. The ideal goal is that every transaction is committed as early as possible regardless of gas price. If we can achieve that goal, PGA will be the only relevant mechanism.

@MoonShiesty
Copy link
Author

MoonShiesty commented Feb 27, 2025

if you want to land first, for example running an arbitrage, i agree PGA is optimal

but for targeting a specific transaction, its optimal to land in the same block

for backrunning a targeted tx, if you land the backrun before the target, it reverts. i can see a searchers sending backruns at different amplification levels to mitigate issues with jitter, but in the most likely case the searcher and target have the same amplification factor

SIP-19 faces a similar problem because it requires backruns bundled with a target have the same gas price, limiting extractable value for backruns in soft-bundles as well

If at least one certificate has a different gas price than others, the whole request is denied.

for backrunning a target, if you expect to land in the same block you need to pay less gas than the target. this creates a hard cap on the gas a searcher can pay to backrun a target, otherwise their backrun will be ordered as a frontrun and revert

this is why i believe we need an API to allow validators to order blocks because ordering by gas within blocks doesn't maximize extractable value for validators for the cases where searchers want a transaction at the end of a checkpoint

i believe either the leader should decide ordering, or a separate PBS system decides order

i think the optimal solution is that every validator submits an ordering and a bid for that order to the leader for each checkpoint, and the network always selects the ordering with the highest bid, maximizing extractable value for validators and resulting in maximally efficient block orderings

the downside to these approaches, is they will make atomic sandwiching and frontrunning much more reliable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants