Since the first application of Maximal Extractable Value (MEV) back in Ethereum’s proof-of-work days, it has become an integral part of block production. Today MEV starts entering the Distributed validator technology (DVT) industry to further improve the process.
In this post, we’ll be looking at another first for DVT! For the first time ssv.network will enable stakers in the network to participate in MEV opportunities and have full customization over the relays a distributed validator can opt into. Find out everything you need to know.
TL;DR
- A brief overview of MEV
- Integrating MEV into ssv.network
- How will it work?
- Improving validator liveness with DVT & MEV
Unlocking MEV Potential in the ssv.network
DVT is becoming a household name in the Ethereum staking space. The technology is an essential upgrade to improve validator decentralization, robustness, and now also block production.
At the moment, the ssv.network mainnet rollout, is in the Limited-launch phase. This means testing is live on the Ethereum mainnet, with the Verified Operators (VOs) running validators. During this time, VOs will test Jato v2. This version will give node operators the choice to run MEV and allow stakers to capture more value from block proposals from their chosen operators.
When approved by the SSV DAO the Limited-launch will be followed by the Launch phase. Here ssv.network Launch Partners’ staking applications will go live and enable public TVL. Then last but not least the Permissionless launch where anyone can distribute a validator through the network or become a node operator.
What is MEV?
For those not familiar with Maximal extractable value (MEV), it has been a part of block creation since before ‘The Merge.’ From a high level, it is the process of extracting more value than the standard block reward and gas fee by including, excluding, or reordering the transactions that validators put in a block.
Entities known as “searchers” use complex algorithms to propose a block to validators that they can add to the blockchain to maximize profits — for a percentage of the rewards. By monitoring the mempool for opportunities, searchers can execute various strategies such as front-running transactions, capitalizing on arbitrage opportunities, or even prioritizing certain transactions with higher gas fees over others.
Block builders prepare entire blocks, optimizing for MEV extraction and fair distribution of rewards. They then submit their blocks to relays. Relays aggregate blocks from multiple builders to select the block with the highest fees. A validator can configure one instance of MEV-boost to connect to multiple relays. The consensus layer client of a validator proposes the most profitable block received from MEV-boost to the Ethereum network for block proposal
Generally, validators wanting to participate in MEV must integrate MEV-boost in their Consensus client. This integration enables a validator that will propose a block to communicate with MEV-Boost and receive a quote from their chosen relays. The choice of relay can be based on profit, ethics, compliance, or either.
Integrating MEV Into ssv.network
Being able to participate in MEV has become an integral part of staking. Building an open protocol used to develop staking applications without enabling MEV is like participating in a lottery and destroying each validator’s ticket. That’s why the core-team has allowed ssv.network users to choose if they want to participate in the lottery. This is done with no extra cost other than selecting an operator that uses relays based on a staker’s preferences; why wouldn’t you want to see if you can win?
Enabling MEV is a win-win. It will allow validators in the network to capture more value from proposals; in return, MEV-enabled operators become more favorable by operating validators that want to take part in MEV, which is almost everyone.
At this stage in ETH staking, over 95% of the blocks go through mev-boost, signifying the importance of the technology. Since the ssv.network is an open protocol and public good, it’s important to give users all the functionalities that validator clients usually have. If validators can’t access MEV in DVT, we are pushing away a massive segment of users, which doesn’t align with our vision of running all staked ETH through DVT.
How will it work?
Operators in the ssv.network run an execution-, consensus-, and SSV-client. Enabling MEV-boost has nothing to do with the protocol and is something node operators need to opt in themselves. Once this is done, it will raise a flag in the ssv.network protocol, indicating that a specific operator has MEV enabled.
Operators registered to the ssv.network have the ability to provide metadata regarding their name, location, clients, and now also relays which they have opted to use. This will indicate to stakers that operators have integrated this tech and which relays they use, allowing stakers to see in advance which relays they will be subscribing to.
In the ssv.network, account owners set a single fee recipient address for all of the clusters owned by that account (see clusters). Execution layer rewards are sent directly to the Ethereum address specified by the staker as their fee recipient address and can be accessed immediately. Execution layer rewards can be MEV or non-MEV. In both instances, these are sent to an execution layer address (not strictly the withdrawal address) defined by the proposed block’s validator.
Enhancing Liveness: Achieving Higher Performance than the Industry Standard
In ssv.network, every time a validator is tasked with a block proposal, one operator from its cluster is chosen to assemble the block. Given that MEV-enabled blocks are broadcasted via relays, only those operators who support the selected relay can broadcast it to the network.
This implies that the more overlap there is in the relays supported by the operators in a cluster, the more operators can broadcast the block proposal, thereby enhancing the liveness of the proposal duty. Having multiple operators sign and broadcast the same duty increases liveness on the Beacon chain, a major benefit of distributed validators.
How different node operator setups can affect liveness:
- When all operator nodes use the same relays, each node can sign and broadcast the block, maximizing liveness above the industry standard.
- In situations where there’s no overlap, only the operator proposing the block would broadcast the duty (the standard liveness of non-DVT validators).
- In instances where some operators of the cluster don’t enable MEV at all (when MEV-enabled operators count is below quorum), consensus may not be reached for the duty, potentially leading to the block proposal not being executed at all.
- In cases where a non-MEV operator assembles the block, the proposal would be executed but without any MEV rewards.
What will MEV look like in ssv.network?
Operators:
From the operator’s perspective, they need to integrate MEV-boost in their Beacon client. They will also need to add a “MEV-enabled” flag to their config in ssv client. Failing to do either of these steps will result in that operator not supporting MEV in SSV.
They also need to add which relays they use in their metadata so stakers can make an informed decision. Favorable operators will use the most common relays. Untruthful operators can be easily spotted and may lose their reputation as service providers in the network.
Stakers:
All stakers need to do is check which relays their chosen operators support. Operators that support the same relays get the highest correlation for liveness.
Unleashing MEV Potential in ssv.network: Join the Staking Revolution!
Discover the intersection of Maximal Extractable Value (MEV) and Distributed Validator Technology (DVT) as we integrate MEV into the ssv.network. With the ssv.network Mainnet Limited Launch underway, node operators will have the unprecedented opportunity to participate in MEV and unlock additional value from block proposals. Don’t miss your chance to be at the forefront of this exciting advancement. Join the Discord and unleash the full potential of MEV in the ssv.network ecosystem.
Website | Network Hub | Discord | Dev Center | Documentation | GitHub
