Addressing lost MEV in Smooth

[Marketen]

The problem

Since the deployment of Smooth, a significant number of vanilla blocks have been proposed. We can define two types of vanilla blocks:

• Vanilla block without MEV Opportunity --> There was no MEV to be extracted for that block. Not a single builder built this block with MEV
• Vanilla block with MEV Opportunity --> There was MEV to be extracted for that block. A builder built and sent the block (with MEV) to a relay, but the proposer didn't use it.

Vanilla blocks with MEV Opportunity are hurting the pool. These come from validators not registered to relays and therefore contributing less to it, but getting the same rewards as others. Proposing a lottery block without being registered to relays is near impossible.

Quantifying the loses

Right now, we know this problem exists but we havent properly quantified it. We can calculate how much ETH the pool has lost from missing MEV-Opportunities by calculating the mev-offset of each block proposed to the pool.

mev-offset: the difference between the max MEV a block could have had and the MEV a block had (0 in case of vanilla). This is the ETH the pool lost in each block.

Note that not only vanilla blocks are losing ETH, but also MEV blocks built by a builder that didnt extract the max MEV possible (a validator registered to only regulated relays will propose these blocks).

Solutions

Penalizing All Vanilla Blocks: This is not a viable option since some vanilla blocks genuinely have no MEV opportunity.

Penalizing Vanilla Blocks with MEV Opportunity: It is a hard task because the oracle (as it is right now) cant identify with 100% accuracy if a block had MEV Opportunity or not. This happens because builders dont always transfer MEV to the proposer as it is defined in the specs (in the latest TX of the block). Sometimes the MEV is transfered through SC calls.

Penalizing Based on Relay Registration Status: it is not possible nor useful. This information is provided only by relays themselves and it is offchain. Altering the state from offchain information would mean losing its capabilities of being "syncable" from scratch with only onchain data. Also, relays only offer the timestamp of the latest time a validator registered. Relays do not know if a validator is currently using the relay or not. Being registered to a relay isnt a guarantee that a validator will use it when its proposal time comes. At the time of writing this, only 10 out of 1960 validators dont have Smooth Fee Recipient in any relay.

DAO/Dappnode Manual Penalization: Manually penalizing any validator that proposes vanilla blocks with MEV opportunity could be an option.

Splitting the Pool: Separate smooth into a max-profit pool and a "vanilla" pool. The max-profit pool could be really agressive on penalizing for validators proposing blocks with mev-offset >0. Splitting has a clear drawback of less validators in each pool.

[MrYukonC1]

The below solutions require identifying "accounts" based on deposit (or withdrawal) addresses, such that an "account" encompasses a collection of validators subscribed to the pool that are associated with a common deposit and/or withdrawal address.

While the above notion of "account" can be sybilled by splitting one's validators into unique deposit/withdrawal addresses, that would be a lot of work just to grief the pool with intentional vanilla blocks. Thus, I think it's not too much of a real concern vs. the benefits of the below proposed solutions.

1. Extend the existing "card" system for use with vanilla blocks and the concept of "accounts"

   • The account's last block proposal was vanilla, but not two in a row. The account earns rewards as if it was in a "green" state.
   • The account's previous two block proposals were vanilla. As a penalty, the account does not earn rewards until its next block is successfully proposed to the pool with MEV. In other words, this account (and ALL of its validators) no longer receive Pending Rewards when somebody else contributes to the pool.
   • A single false positive will put an account in "yellow card" status, but I believe the likelihood of two consecutive false positives is extremely low. If you want to be extra cautious, you could up the trigger for "red card" to three consecutive vanilla blocks, which would almost certainly be a near 0% chance for three consecutive false positives.

2. Set a pool-wide "vanilla block threshold"

   • This method will require more code changes and housekeeping.
   • Specify a reasonable pool-wide POOL_VANILLA_BLOCK_THRESHOLD percentage (10%) that each "account" can choose to either meet/exceed or not.
   • Calculate an account's vanilla_block_percentage over a sliding window of previous N blocks (past 10 blocks).
   • Initialize all accounts with a vanilla_block_percentage of 0 and their array of previous 10 blocks as non-vanilla.
   • When an account makes a valid proposal to the pool, update its array of previous N blocks, calculate its new vanilla_block_percentage, and determine which backend pool it will contribute to and earn from for the current proposal.

      if( Account_Vanilla_Block_Percentage <= POOL_VANILLA_BLOCK_THRESHOLD )
        contribute to / earn from max value pool
      else
        contribute to / earn from vanilla block pool
     

   • This method gracefully segregates "max-value" accounts from "altruistic" accounts on a per-proposal basis.
   • This method also gives both camps the option to migrate in either direction at any time — all that's required to migrate is to consistently propose more or less vanilla blocks than the POOL_VANILLA_BLOCK_THRESHOLD percentage!

[Marketen]

Update on Quantifying Lost ETH in the Pool from Not Subscribing to Relays:

With the help of https://payload.de, we have calculated the MEV-offset for each block proposed in the pool. By summing the MEV-offset of each block, we can determine the total amount of ETH lost in Smooth.

The following stats have been calculated at 25/07/2024, 2229 total blocks proposed, 214 of them considered vanilla by the Oracle.

Lost ETH from vanilla blocks only.

Total Difference Sum: 5.911819556582351
Top 5 Block Differences:
Block 19853883: 0.546500143971024
Block 19575611: 0.1472713096514261
Block 19938038: 0.13867053881303446
Block 20269495: 0.13863243515795087
Block 19883926: 0.13352250179440825

The pool lost approximately 6 ETH from vanilla blocks, which is about 3% of the total.

---

Lost ETH from all blocks (vanilla + mev)

Total Difference Sum: 19.802687141026944
Top 5 Block Differences:
Block 19496723: 1.1376890102514554
Block 19220098: 0.7304494025218496
Block 19687945: 0.6124221634329255
Block 19853883: 0.546500143971024
Block 19380193: 0.38998999985987737

The pool lost almost 20 ETH from all blocks, which is about 9.5% of the total.

Main Takeaway:
There is little difference between a validator proposing vanilla blocks (registered to 0 relays) and one proposing MEV blocks but registered with only 1-2 relays. Both hurt the pool.

Validators not registering to all relays, particularly the top ones like Ultrasound, Bloxroute, and Agnostic (https://mevboost.pics/), significantly impacts the pool's performance. Even if a validator proposes MEV blocks, it can still have a very high mev-offset, as seen with block 19496723 (https://payload.de/data/19496723/), where the validator didnt use a build by rsync-builder of 1.17 ETH, probably because it wasnt registered to the relay where rsync-builder operates.

It’s challenging to penalize validators proposing MEV blocks with a high MEV-offset since this offset is not readable on-chain. Vanilla blocks can be penalized more easily (there is still the problem of vanilla false positives, but these occur rarely).

Not all top relays are OFAC compliant. Agnostic & Ultra Sound are not.

TLDR:

• If validators proposing vanilla blocks had been using all relays, the pool would have 6 more ETH.
• If all validators in smooth had been using all relays, the pool would have 20 more ETH.