Questions on the ETH2 MEV analysis update

[elenahoo]

It seems there are three periods (or data collection source) we need to consider since the last analysis for the update:

• Period 1: Post EIP-1559 but pre-merge (still ETH1.0 PoW)
• Period 2: Testnet Sepolia & Goerli - running through pre and post mainnet merge (ETH2.0 PoS)
• Period 3: Post mainnet merge (ETH2.0 PoS)

The main question is whether we focus on all three or only the post mainnet merge for the analysis update. This depends on how much relevance the components in period 1 (i.e. EIP-1559) and period 2 carry on to period 3 because ultimately we want to focus on the mainnet merge.

Here are some questions related to the last analysis and also generic questions for the merge:

1. Does burned fees still exist post-merge? If the deflationary effect doesn’t exit, is it still necessary to analyse this?
2. The block reward from period 1 PoW is different from Period 2 & 3 (PoS). So if burning also becomes irrelevant post-merge, is there any need to collect data for Period 1 and update the analysis based on this data? Should we only focus on Period 2 & 3?
3. How much block reward is allocated to attester and proposer post merge? The best explanation I can find is from ETH2.0 Knowledge Base , where attestation rewards are split into attesting Source, Target, Head. But it’s still unclear to me whether proposer reward will be added upon this, i.e. if the proposer is also the attester, how much reward does he get?
4. In the jupyer notebook, full_reward = [(4 * annualised_base_reward(n)) for n in n_validators], is the multiplier 4 the reward for ticking all three boxes as shown in the last row of the table 'Possible Attestation properties' from ETH2.0 Knowledge Base? If so, shouldn’t 4 be 31/8? Or is it a rounding difference?
5. In the notebook, SECONDS_PER_YEAR = 31556952, shouldn’t it be 365x24x60x60=31536000?
6. When we refer to validator return in %, it is the (total annual return / 32 ETH). Does the total return include MEV and the block reward (attestation+proposer) together? Or do we purely consider block reward?
7. Is block reward different across the three different phases of the the merge - Phase 0, Altair and Bellatrix? I found some info here but struggle to conclude if block reward changes through these stages.
8. How do we define REV post-merge? The formula $REV≥ V{in} - V{out}-s{MEV}*g{tail}$ probably is not feasible any more because there is also the $REV_{B}$ from the builder, which could contain the opportunity cost the builder incurs by not including the MEV-extracting transactions? We’ll need to re-define the REV formula for ETH2.0 in order to collect the right data to calculate REV and use this in the MEV ETH2.0 update analysis.

[mkalinin]

I would recommend reading Rewards chapter of Upgrading Ethereum book, it gives a very good overview of rewards system of the beacon chain which keeps being actual post-Merge.

Is block reward different across the three different phases of the the merge - Phase 0, Altair and Bellatrix?

Proposer's and attester's rewards are not affected by the Merge (Bellatrix) but they underwent changes in Altair, these changes are outlined (with useful links) in the said chapter.

[obadiaa]

Hey! We've had a conversation over the phone about this but posting the answers here too for the benefit of others :)

Answers

Do burned fees still exist post-merge? If the deflationary effect doesn’t exist, is it still necessary to analyse this?

EIP-1559 still exists post-Merge!

The block reward from period 1 PoW is different from Period 2 & 3 (PoS). So if burning also becomes irrelevant post-merge, is there any need to collect data for Period 1 and update the analysis based on this data? Should we only focus on Period 2 & 3?

Given the answer above, I think this is also answered :)

How much block reward is allocated to attester and proposer post merge? The best explanation I can find is from ETH2.0 Knowledge Base , where attestation rewards are split into attesting Source, Target, Head. But it’s still unclear to me whether proposer reward will be added upon this, i.e. if the proposer is also the attester, how much reward does he get?

A proposer cannot be an attester at the same time and yes proposer rewards are added on top of this! Here's a picture from one of Pintail's article that breaks down how the 4*base_reward is distributed to a staker.

The two links below from Pintail go into granular details on this and I recommended checking them out! I also recommend diving into the spec directly and looking for these parameters as the spec is the ultimate source of truth here.

Links:

• https://pintail.xyz/posts/validator-rewards-in-practice/
• https://pintail.xyz/posts/beacon-chain-validator-rewards/
• spec: https://github.com/ethereum/consensus-specs

In the jupyter notebook, full_reward = [(4 * annualised_base_reward(n)) for n in n_validators], is the multiplier 4 the reward for ticking all three boxes as shown in the last row of the table 'Possible Attestation properties' from ETH2.0 Knowledge Base? If so, shouldn’t 4 be 31/8? Or is it a rounding difference?

I'm not sure about this although I believe my answer above applies here too :D

In the notebook, SECONDS_PER_YEAR = 31556952, shouldn’t it be 365x24x60x60=31536000?

This seems to be an error in our notebook, thanks for spotting it!

When we refer to validator return in %, it is the (total annual return / 32 ETH). Does the total return include MEV and the block reward (attestation+proposer) together? Or do we purely consider block reward?

You could look at 2 numbers:

• total annual return without any MEV extraction (so staking fees + priority fees)
• total annual return with MEV extraction (staking fees + priority fees + MEV fees)

Note that in our current analysis, we looked at the 2 numbers above minus priority fees.

Is block reward different across the three different phases of the the merge - Phase 0, Altair and Bellatrix? I found some info here but struggle to conclude if block reward changes through these stages.

It is different in that, until the Merge, there are no execution payloads so proposer rewards don't include priority fees from Ethereum execution-layer transactions. Also, it is different in that the proposer reward is a multiple of base_fee, which changes dynamically with the number of validators. We should focus on the block reward that includes priority fees and that scales with the number of validators in the validator set.

How do we define REV post-merge? The formula probably is not feasible any more because there is also the from the builder, which could contain the opportunity cost the builder incurs by not including the MEV-extracting transactions? We’ll need to re-define the REV formula for ETH2.0 in order to collect the right data to calculate REV and use this in the MEV ETH2.0 update analysis.

Right now, I'd assume builders aren't taking a fee but would make sure this can easily be added in the code.

Additional resources

https://benjaminion.xyz/eth2-annotated-spec/ -- great annotated spec from Ben Edgington https://www.attestant.io/posts/charting-ethereum-issuance/ -- useful short post from Attestant on Ethereum issuance through time. It helped me build my mental model! https://ethereum.github.io/beaconrunner/notebooks/naiveurn.html -- notebook by Barnabe Monnot (RIG) after he'd read the 'MEV in eth2' original analysis, diving deeper into another potential form of inequality from MEV, finding early counter-intuitive results. https://shsr2001.github.io/beacondigest/ -- a collection of fortnightly jupyter notebooks that explore the depths of the beacon chain from Shyam Sridhar (RIG). this is a goldmine imo! (and also something we should maybe consider doing more of - presenting data analysis this way to the public) https://www.cadcad.education/course/masterclass-ethereum -- the free masterclass to use RIG's modular dynamical-systems model of Ethereum's validator economics, based on the open-source Python library radCAD, an extension to cadCAD. This looks super cool and potentially useful to us.

[elenahoo]

Regarding Question 8, based on the two proposed payment proof by @thegostep https://github.com/flashbots/mev-boost/issues/220, here are some initial thoughts on how to calculate REV:

$REV{total} = REV{S} + REV{B} + REV{P}$

where notation S, B, P stand for searcher, builder, proposer respectively; $REV_{total}$ is the total realised extractable value - actual value extracted from the blockchain from MEV opportunities (refer to @fiiiu 's article Quantifying Realized Extractable Value)

$REV{S} = V{in{s}} - V{out{s}} - G * g{bid_{s}}$

where $V{in{s}}$ is the value flowing in to searcher’s address; $V{out{s}}$ is the value flowing out from searcher’s address to builder; $G$ is the unit of gas used; $g{bid{s}}$ is the priority fee paid from searcher to builder.

$REV{B} = (g{bid{s}} - OC{B} - g{bid{p}})*G$

where $OC{B}$ is the opportunity cost for the builder for forgoing other mempool transactions in order to include the searcher’s bundle, which can be estimated by $g{tail}$, the gas price of the last transaction in the block.

Payment proof at transaction level

Assuming proposer only receives payment from builder:

$REV{P}=(g{bid_p}-BaseFee)*G$

where $g{bid{p}}$ is the gas price paid from builder to proposer to bid for block space.

Payment proof at the account balance level

Assuming proposer receives payment from builder and a direct payment from searcher, which could be unobservable:

$REV{P}=(g{bidp}+g{s, pmt}-BaseFee)*G$

where $g{s, pmt}$ is direct payment from searcher to proposer bypassing builder, which could be difficult to track and observe. $(g{bidp}+g{s, pmt})*G$ can be also interpreted as $V{in{p}}-V{out{p}}$ the proposer's ETH account balance difference.

So in the end the total REV is: $REV{total}=V{in{S}}-V{out{S}}-G*(g{tail}+BaseFee+g_{s, pmt}$)

[thegostep]

I believe BaseFee should not be counted in REV since it is not extractable by the validator!

[elenahoo]

Agree! So BaseFee is subtracted in the end from search balance difference and excluded in the REV equation since it's burned and not extractable by any party.

[obadiaa]

As discussed though, you could use base_fee burns as input to calculate Ethereum's issuance and compute inflation-adjusted rewards 🤺

Sounds overly complicated though

[ladidan]

I think this fairly recent analysis by attestant on execution rewards might also be a useful resource: https://www.attestant.io/posts/exploring-execution-block-rewards/

They explicitly separate post-1559 fee recipient rewards (including MEV as priority fee) to give an indication on overall changes to validator rewards post-merge.

Apart from the projected reward increase per their historical on-chain analysis, they also greatly visually demonstrate the sharper decline in execution rewards as the validator set increases (given the constant number of slots per year) compared to consensus rewards (i.e. issuance, where over the long-run the proposer reward makes up for just 1/8 of the overall validator rewards).

[sambacha]

365x24x60x60

sorry to comment on this closed issue, but 31556952 is correct: this is 365.2425 average days in a year (i.e. leap days accounted for).