<100 subscribers
Share Dialog
Share Dialog
Updated cover image → credits to Toni Wahrstätter @ mevboost.pics
With just few a weeks into Ethereum’s Proof-of-Stake era, liquid transaction fees and MEV rewards now on the table, stakers are confronted with a more enriched but also more complex reward scheme for serving the network.
Most recent discussions have revealed a non-trivial decision tree of trade-offs between validator reward maximisation, censorship resistance, and network security (specifically: a decentralised validator set).
“I'm hesitant about MEV and staying away from it.”
- Superphiz
Since the merge, Ethereum effectively makes use of non-native proposer-builder-separation (PBS), leveraging an external builder network in order to mitigate more severe harm to the chain because of MEV opportunities. Its current design utilises relay providers as trusted entities - widely received as at least sub-optimal - and furthermore fuels fear of an endgame that potentially involves one block builder capturing the right for all of the blockspace.
For the attempt to explore and frame the current landscape of MEV extraction options for stakers it is worth to prepend that:
Data sets are still limited, allowing only for early indications
The adoption rate of externally built blocks in comparison to late stage PoW mev-geth is still comparably low (yet slowly increasing)
Block builder markets have yet to form and relay infrastructure needs to harden as they have yet to prove sustained reliability
MEV-boost, the most prominent software to extract MEV as a staker, has suffered from some more or less severe flaws (leading to missed proposals) in its early days of production readiness
When opting for maximal extraction, stakers run MEV-boost (or other relay multiplexers) and ideally register validators to various different relays with the aim to receive the highest possible bid for their blockspace. Their main goal is to maximally extract MEV to benefit from significantly higher immediate validator rewards.
Maximally extracting stakers moreover adhere to the Flashbots school of thought and do not leave MEV on the table for other validators, potentially leading to more extensive concentration of power (i.e. pushing stakers in the hands of centralized staking pools as they can offer comparably higher returns).
Unfortunately, the currently most adopted relay (operated by Flashbots) is censoring TXs - apparently for regulatory compliance reasons.
Nonetheless, it should be remarked that the more limited the scope of includable TXs is due to censoring, the less likely it is for a relay/builder to offer the most profitable bid. Hence, in a competitive builder market censoring also comes at a cost for the censoring entity.
Pool stakers should keep in mind that staking pool operators are incentivised to opt for maximal extraction in order to provide competitive products - Lido node operators, for example, are supposed to run mev-boost.
Altruistic self-builders do not make use of MEV-boost and thus refrain from additional node stack complexity.
Reminder: MEV-boost is a sidecar to Ethereum. Its usage is purely optional.
Although leveraging mev-boost generally increases the risk of software bugs and thus potentially negatively impacts overall validator rewards, this effect is expected to become more and more negligible as the software hardens over time.
Consequently, these validators build their blocks locally (also referred to as “vanilla” blocks) and include TXs dependent on the local execution clients’ view of the public mempool.
Self-builders generally miss out on the majority of MEV opportunities, netting lower overall validator rewards, which arguably degrades network security in a pure economic-rationality model.
However, self-builders know *for fact* that they are not going to censor TXs, thereby fostering Ethereum’s credible neutrality property and adding to ETH’s long-term value proposition.
Partially extracting proposers do not optimise for the most valuable payload. They can rather be attributed to values-based proposers. For the moment there appear to be two main types of partial MEV extractors, both sharing the utilisation of MEV-boost:
Regulated or ethical MEV extraction means registering validators only with a selected list of
regulatory compliant relays (i.e. censoring transactions related to blacklisted addresses according to a given jurisdiction) or
so called ethical relays (i.e. censoring toxic MEV transactions such as sandwiching attacks on users)
In this context it must be added that relays are generally trusted to (not) censor.
→ But how does a staker know for sure?
Obviously there’s a lot of room for improvement regarding relay and builder transparency. It is expected to see further monitoring tools around relay and builder infrastructure in the near future which will hopefully shed more light on these actors.
“If we rely on altruism, don’t make altruism expensive [...]
Proposers should not have to sacrifice large amounts of revenue to help ensure censored transactions get in.”
- Vitalik
The core mechanism of opportunistic MEV-forgoing is straightforward:
Validators provide MEV-boost (or the consensus client) with a minimum required absolute value of an external bid (technically: “payload”, e.g. 0.2 ETH) to be considered for inclusion in a block proposal. Otherwise the proposer falls back on the local execution client’s payload (i.e. self-builds).
Consequently, proposers gain exposure to larger MEV opportunities while still adding to the decentralization of the network (if MEV is small or non-existent).
Even though this extraction tactic is not the most profitable, it offers a way out to achieve less costly altruism. Validators autonomously decide on the price tag for guaranteed censorship resistance, e.g. by setting the threshold requirement slightly higher than the median external payload over a certain timeframe.
One technical caveat: the specified value requires manual adjustment to changing network conditions. A future feature enhancement possibly includes a comparison between the value of the locally built block with the external builder's submission using a relative reward delta instead of a fixed one. In order to compare the bids before signing, a few more standardizations around the communication between the beacon client and the execution client have to be worked out.
The above described options represent short-term approaches to extract MEV for stakers given the current external builder network architecture which is patching temporary shortcomings in Ethereum’s current blockchain design.
It seems worthwhile to closely follow the discussions around mid-term MEV mitigation solutions which will likely be in-protocol and entail:
Making relays obsolete with the help of native separation of builders and proposers, potentially leveraging TX inclusion lists (“crLists”) and MEV-smoothing
Closely linked to PBS: follow-up ideas in order to decentralize the builder role
Cryptography: e.g. native TX encryption or threshold encryption
In the meantime stakers should be aware of current trade-offs and compromises when extracting MEV (or not). It appears reasonable to strive for a healthy balance between sufficiently incentivised, decentralised staking setups and not giving up on censorship-resistance as one of the core properties for a thriving Ethereum ecosystem.
****
This post was supported by a grant from a CLR funding round held by EthStaker, mainly matched by the EF.
Updated cover image → credits to Toni Wahrstätter @ mevboost.pics
With just few a weeks into Ethereum’s Proof-of-Stake era, liquid transaction fees and MEV rewards now on the table, stakers are confronted with a more enriched but also more complex reward scheme for serving the network.
Most recent discussions have revealed a non-trivial decision tree of trade-offs between validator reward maximisation, censorship resistance, and network security (specifically: a decentralised validator set).
“I'm hesitant about MEV and staying away from it.”
- Superphiz
Since the merge, Ethereum effectively makes use of non-native proposer-builder-separation (PBS), leveraging an external builder network in order to mitigate more severe harm to the chain because of MEV opportunities. Its current design utilises relay providers as trusted entities - widely received as at least sub-optimal - and furthermore fuels fear of an endgame that potentially involves one block builder capturing the right for all of the blockspace.
For the attempt to explore and frame the current landscape of MEV extraction options for stakers it is worth to prepend that:
Data sets are still limited, allowing only for early indications
The adoption rate of externally built blocks in comparison to late stage PoW mev-geth is still comparably low (yet slowly increasing)
Block builder markets have yet to form and relay infrastructure needs to harden as they have yet to prove sustained reliability
MEV-boost, the most prominent software to extract MEV as a staker, has suffered from some more or less severe flaws (leading to missed proposals) in its early days of production readiness
When opting for maximal extraction, stakers run MEV-boost (or other relay multiplexers) and ideally register validators to various different relays with the aim to receive the highest possible bid for their blockspace. Their main goal is to maximally extract MEV to benefit from significantly higher immediate validator rewards.
Maximally extracting stakers moreover adhere to the Flashbots school of thought and do not leave MEV on the table for other validators, potentially leading to more extensive concentration of power (i.e. pushing stakers in the hands of centralized staking pools as they can offer comparably higher returns).
Unfortunately, the currently most adopted relay (operated by Flashbots) is censoring TXs - apparently for regulatory compliance reasons.
Nonetheless, it should be remarked that the more limited the scope of includable TXs is due to censoring, the less likely it is for a relay/builder to offer the most profitable bid. Hence, in a competitive builder market censoring also comes at a cost for the censoring entity.
Pool stakers should keep in mind that staking pool operators are incentivised to opt for maximal extraction in order to provide competitive products - Lido node operators, for example, are supposed to run mev-boost.
Altruistic self-builders do not make use of MEV-boost and thus refrain from additional node stack complexity.
Reminder: MEV-boost is a sidecar to Ethereum. Its usage is purely optional.
Although leveraging mev-boost generally increases the risk of software bugs and thus potentially negatively impacts overall validator rewards, this effect is expected to become more and more negligible as the software hardens over time.
Consequently, these validators build their blocks locally (also referred to as “vanilla” blocks) and include TXs dependent on the local execution clients’ view of the public mempool.
Self-builders generally miss out on the majority of MEV opportunities, netting lower overall validator rewards, which arguably degrades network security in a pure economic-rationality model.
However, self-builders know *for fact* that they are not going to censor TXs, thereby fostering Ethereum’s credible neutrality property and adding to ETH’s long-term value proposition.
Partially extracting proposers do not optimise for the most valuable payload. They can rather be attributed to values-based proposers. For the moment there appear to be two main types of partial MEV extractors, both sharing the utilisation of MEV-boost:
Regulated or ethical MEV extraction means registering validators only with a selected list of
regulatory compliant relays (i.e. censoring transactions related to blacklisted addresses according to a given jurisdiction) or
so called ethical relays (i.e. censoring toxic MEV transactions such as sandwiching attacks on users)
In this context it must be added that relays are generally trusted to (not) censor.
→ But how does a staker know for sure?
Obviously there’s a lot of room for improvement regarding relay and builder transparency. It is expected to see further monitoring tools around relay and builder infrastructure in the near future which will hopefully shed more light on these actors.
“If we rely on altruism, don’t make altruism expensive [...]
Proposers should not have to sacrifice large amounts of revenue to help ensure censored transactions get in.”
- Vitalik
The core mechanism of opportunistic MEV-forgoing is straightforward:
Validators provide MEV-boost (or the consensus client) with a minimum required absolute value of an external bid (technically: “payload”, e.g. 0.2 ETH) to be considered for inclusion in a block proposal. Otherwise the proposer falls back on the local execution client’s payload (i.e. self-builds).
Consequently, proposers gain exposure to larger MEV opportunities while still adding to the decentralization of the network (if MEV is small or non-existent).
Even though this extraction tactic is not the most profitable, it offers a way out to achieve less costly altruism. Validators autonomously decide on the price tag for guaranteed censorship resistance, e.g. by setting the threshold requirement slightly higher than the median external payload over a certain timeframe.
One technical caveat: the specified value requires manual adjustment to changing network conditions. A future feature enhancement possibly includes a comparison between the value of the locally built block with the external builder's submission using a relative reward delta instead of a fixed one. In order to compare the bids before signing, a few more standardizations around the communication between the beacon client and the execution client have to be worked out.
The above described options represent short-term approaches to extract MEV for stakers given the current external builder network architecture which is patching temporary shortcomings in Ethereum’s current blockchain design.
It seems worthwhile to closely follow the discussions around mid-term MEV mitigation solutions which will likely be in-protocol and entail:
Making relays obsolete with the help of native separation of builders and proposers, potentially leveraging TX inclusion lists (“crLists”) and MEV-smoothing
Closely linked to PBS: follow-up ideas in order to decentralize the builder role
Cryptography: e.g. native TX encryption or threshold encryption
In the meantime stakers should be aware of current trade-offs and compromises when extracting MEV (or not). It appears reasonable to strive for a healthy balance between sufficiently incentivised, decentralised staking setups and not giving up on censorship-resistance as one of the core properties for a thriving Ethereum ecosystem.
****
This post was supported by a grant from a CLR funding round held by EthStaker, mainly matched by the EF.
No comments yet