MEV protection

[damip]

Rationale

MEV is a problem: https://ethereum.org/en/developers/docs/mev/

Here we discuss a possible solution for Massa.

General idea

An address A wants to send an operation but needs to hide its contents before execution to prevent reordering.

Prelude: staker registration

Stakers willing to participate in the anti-MEV operation call a "antiMEV" smart contract on-chain to register a public key, and deposit coins.

Step 1: commit

As a first step, A commits the following data to the antiMEV smart contract:

• a salted hash of the operation
• the operation fee
• the operation max_gas
• the operation size

The operation fee is transferred as coins to the smart contract and locked there.
The ordering smart contract sorts the commits by decreasing fee.

If there are too many ops, the least prioritary ones are cancelled, and their fee is reimbursed to their sender.

Step 2: reveal and inclusion

When the operation A arrives in the next batch of the antiMEV contract queue, its sender encrypts the operation with the registered public keys of the upcoming (PoS-selected) few block producers of the operation thread that have put a high enough deposit to cover for potential loss. The encrypted versions of the operation are then propagated.

Only the target stakers can decrypt them, check their hash, and include them in their block.

Step 3: execution

When the antiMEV ops are included in a block by a registered staker, the antiMEV smart contract is called first in the block and checks that:

• the antiMEV operations are at the very beginning of the block (there is nothing before them)
  • if not respected => the deposit of the staker is slashed and their participation is revoked
• that each op hash matches the committed one, and that the relative order of the ops is the one that was committed
  • if not respected => the deposit of the staker is slashed and their participation is revoked
• when the op is executed, the block producer gets the fee of the ops twice: once from the op itself, and once from the locked fee in the antiMEV SC. Note that the block producer can choose not to include an operation. In that case, the block producer does not get the associated fee.

If an op is not included after 10 blocks produced by participating stakers in that thread, it means it has never been revealed => it is removed from the queue and the fee is half-burned and half split and distributed to the stakers that were not able to include it.

Note that the operation itself needs to ensure that it is currently in the antiMEV queue. Otherwise ops removed from the antiMEV could be included out of the antiMEV context.

Analysis

The general idea is that operation ordering is pre-commited blindly, and the clear version is only later revealed to participating stakers chosen for the amount they deposited, and who need to respect the ordering or lose their deposit.

antiMEV-participating stakers cannot produce blocks that don't start with the antiMEV part or they get slashed and eliminated. antiMEV operations include a check to ensure that they cannot be included outside of that antiMEV part within a block created by one of the selected participating stakers, to prevent participating stakers from including the op using another staking account that does not participate in antiMEV.

The selection of stakers by deposit is important because it creates a market pushing deposit prices up.

Ideally, senders need to wait for their commit to be final before revealing. But if they don't it's also ok because the ops won't be executed if they are not listed in the antiMEV smart contract, even if included.

Anti-MEV operations are opt-in and slower/more expensive than normal operations.

[qdrn]

antiMEV-participating stakers cannot produce blocks that don't start with the antiMEV part or they get slashed and eliminated.

How do you enforce that at the smart-contract level ?

[damip]

This can be relaxed to "the antiMEV SC part accepts to run only if it is the first thing to run in a block"

[AurelienFT]

the antiMEV smart contract is called first in the block and checks that:

I don't understand how you can perform this checks at SC level

the fee is half-burned

Why not redistribute everything?

[damip]

the antiMEV smart contract is called first in the block and checks that:

I don't understand how you can perform this checks at SC level

Some form of introspection needs to be added (SCs must be able to read the block)

the fee is half-burned

Why not redistribute everything?

Because otherwise there might be less incentive to include the op at all

[damip]

I am not fully satisfied with this proposal because even if the op is revealed to a target staker t0/2 before block production, that staker might include MEV ops in other threads using some other staking address.

[sydhds]

Can we plan for some denunciation in that particular case?

[damip]

I don't think so, there is no possible proof of that