When Rocket Pool launched on mainnet, the situation around MEV in a PoS world was uncertain and the likes of Flashbots were still actively developing specifications for their solutions. All we knew for certain was that MEV would be present and we needed a way to ensure that Rocket Pool validators would share MEV rewards with the pool that supplied half the capital for their stake. Rocket Pool is designed to protect Node Operators (NO) from a malicious Oracle DAO, so minipool upgrades were designed to be opt-in. Therefore, we needed to include something at launch in the initial minipool delegate contract that could be used to punish non-compliant NO. Otherwise, adding this at a later date would require NO to opt into a new delegate contract that could penalise them. Which NOs could simply refuse to do and bypass any penalty system we implemented. So we added the mechanic of a penalty percentage which would be able to set per minipool by some yet-to-be-designed system along with a max penalty rate which could be set by the guardian account. The purpose of the max penalty was so once the situation around MEV became clearer, we could set this to a value which is just high enough to make cheating -EV and then we could take that power away from the guardian. Essentially, postponing the decision of what that value needed to be into the future.
With the merge fast approaching, we now have to implement the logic behind the penalty system. Both in terms of what amount of a penalty gets applied (contract functionality) and also how we detect non-compliant behaviour (watchtower functionality).
We have included in the merge readiness contract upgrades a system similar to the oDAO balance and price submission systems. In which oDAO members can come to consensus in favour of applying a penalty to a minipool. Each penalty received increases the penalty percentage for that minipool by some amount. There is also a buffer of 2 strikes before the penalty percentage starts to increase to reduce the likelihood of a misconfiguration resulting in a harsh penalty. The consensus percent and the penalty amount are both configurable values which we have initially set to 51% and 10% respectively. 10% was chosen as a trade-off as 1.6 ETH is greater than the majority of MEV opportunities and is a strong enough disincentive to encourage the desired behaviour but also doesnât immediately destroy the validatorâs capital.
For example, if a NO proposes a block that doesnât meet the protocol requirements (i.e. incorrect fee_distributor), the oDAO members watchtower will detect this and vote in favour of applying a penalty to the relevant minipool. Once 51% of oDAO votes in favour, the penalty count for that minipool is incremented. Nothing happens at this stage. If another invalid block is proposed, the same thing happens and the penalty count is incremented again. But once again, nothing else happens. On the third invalid block, once the penalty count is incremented, a 10% penalty rate is set on the minipool. This 10% penalty is applied when the minipool exits. After the NOs share is calculated during distribution, 10% is taken off that value and is given to the deposit pool instead. Each subsequent invalid block increases the penalty rate by another 10% up to the max penalty rate (whose value is TBD).
We suspect that in the future this system might see significant changes. For example, with forced exits and the RPL-first slashing ideas coming out of the LEB research. What Iâd like to focus on is the other side of this system. How we monitor the MEV and report it on-chain via the oDAO voting mechanism.
mev-boost by Flashbots
We propose adopting mev-boost by Flashbots as the MEV service provider for Rocket Pool. Flashbots is the leading MEV research project in the space and they offer the most prominent MEV product on PoW Ethereum today (80% of PoW hashrate accepts Flashbots bundles). We expect it to remain the dominant MEV solutions provider after the merge. mev-boost allows validators to outsource block production to third parties who specialise in MEV extraction and pay the validator who proposes the block for including it in the chain. When itâs a validatorâs turn to propose a block, they query an mev-boost relay for an execution payload which pays the highest and then includes that in their proposed block. Behind the scenes the relay communicates with builders and searchers where an auction is held for the blockspace. Flashbotsâ goal is to have a decentralised system of builders and relays in the future with some sort of reputation system keeping them in check. But the initial launch design has them operating the sole builder and relay on the network.
There is discussion on adding the ability to query the relay for which block they proposed for a given slot. This would allow the querying of Flashbotsâ relay for each block proposed by a Rocket Pool validator to determine if they proposed a Flashbots block or not. (Recently proposed blocks ¡ Issue #120 ¡ flashbots/mev-boost ¡ GitHub).
The mev-boost system is designed as a side car that falls back to local execution client block production in case a relay is down or inaccessible. However, this poses a problem, as distinguishing between a naive, locally-built block and one which contains MEV extraction is challenging. If we cannot distinguish between locally-built blocks and blocks that extract MEV then we cannot effectively punish and discourage cheating. A large NO could run his own searcher and build his own blocks that have back channel MEV extraction and it would be difficult to impossible to detect and therefore penalise. Or NOs could join some other non-Flashbots MEV network and extract MEV that way without detection.
Alternatively, forcing Rocket Pool NOs to propose only Flashbots built blocks and nothing else is not a viable option. As we cannot put the liveliness of Ethereum in the hands of a single centralised Flashbots relay. In time, as the Flashbots network grows to several relays and builders, this may become a viable option.
With these problems in mind, we propose a plan which consists of a short-term, mid-term and long-term solution to the problem.
Short Term
In the short-term, Rocket Pool validators are required to set their fee_recipient to their distributor contract address (or smoothing pool if opted in). We integrate mev-boost into the smartnode stack so that all Rocket Pool validators propose Flashbots-built blocks and fallback to local block production. The oDAOs will monitor the fee_recipient and penalise non-compliant validators via the penalty system mentioned earlier. We will monitor validators and if we discover new methods for extracting MEV that bypass the fee_recipient payment, we will include additional checks to the oDAO monitoring process to penalise these as well. This can be done retroactively so there is risk to even attempt gaming the system now knowing it could be detected later with more sophisticated methods. We can query Flashbotsâ relay for every proposed block and keep record of which blocks are proposed by them and which arenât. This will help detect malicious actors and allow us to react.
This short-term solution has some flaws:
- We are unable to force validators into extracting MEV on behalf of the protocol. It is perfectly legal in the protocol for NOs to only produce blocks locally and if NOs refuse to propose Flashbots blocks it would result in reduced yield for rETH holders. In practice though, the substantial increase in NO yield from MEV is a strong economic incentive to participate so it is unlikely to be widespread.
- Without being able to force validators to propose Flashbots blocks, NOs could opt in to the smoothing pool and receive benefits from it while at the same time not contribute to it. We could kick those not contributing but once again we have no way of knowing if it was an innocent situation and Flashbots relay was simply not available to propose a block for them. This is exacerbated by the fact that block proposals are a rare event so any leniency gives way for exploitation.
- There are sophisticated MEV-extraction methods that are difficult or impossible to detect and therefore punish.
fee_recipientis the most common and simple way to pay validators for blockspace but there are other methods which are indistinguishable from a regular Ethereum transaction.
We donât anticipate these flaws to pose a significant threat to the protocol in the short term as running a profitable builder requires significant scale that is not achievable by most participants. But an actor with enough time and resources could exploit our lower capital requirement for validators to increase their blockspace for their own MEV extraction operation.
And once again, NOs attempting to exploit this do so at a risk to their capital upon being detected.
Mid Term
In the mid-term, Flashbotsâs mission is to build up a decentralised network of builders and relays. At which point, Rocket Pool can decide that the system is decentralised and has sufficient redundancy that we can rely on it entirely for block production and prevent locally-built blocks from being acceptable. At this time, all blocks proposed by Rocket Pool validators must come from one of a set of whitelisted relays. This set of relays would be modifiable by the oDAO so we can add and remove entries from it as needed.
Pros
- By removing the ability to locally produce blocks, we can know for certain whether someone is attempting to cheat the protocol and can punish accordingly.
- Smoothing pool participants that do not propose Flashbots blocks can be punished and kicked.
- Guarantees that minipools (and therefore rETH users) will have higher returns (projected to be almost double) than self-built blocks ensuring Rocket Pool remains competitive with other staking services.
Cons
- Although a decentralised network of relays is more robust, itâs still not as decentralised as everyone being able to build their own blocks from a public mempool.
- In black swan event, we could still negatively impact the liveliness of the Ethereum network.
Long Term
In the long-term, Ethereum is planned to feature in-protocol PBS. This is still an active area of research but Rocket Pool would need to adapt to support this protocol change.
