EIP-7251 adds a notion of "consolidation" so that two 32 ETH validators can combine into a single validator with higher balance. See EIP-7251 for further details and motivation. The EIP currently specifies in-protocol consolidation as a consensus-layer operation, and after talking to various staking pools on mainnet, it has become clear that offering this same functionality from the execution layer is desirable. A direct way to do this is to extend EIP-7002 with a consolidation operation, just like the exit and withdrawal functionality it currently supports. From EIP-7251, the consensus layer operation looks like this: class Consolidation(Container): source_index: ValidatorIndex
4/10/2024Exclude withdrawals to fee recipient when computing a payload's value. Context mev-boost today selects the highest bid by value from a set of bids provided by connected relays in a given slot. This value represents the amount of ETH a builder transfers to a proposer in exchange for the sale of that proposer's execution block space. Relays compute this value in one of two ways, referred to as "payment schemes": PS1. The value of the last transaction in the execution payload, which must exactly match the value claimed by the builder in their submission. PS2. Comparing the balance of the fee_recipient in the post-state after the execution payload to the pre-state amount.
2/19/2024The success of mev-boost since the Merge demonstrates the extreme demand validators have for outsourcing block construction to an external counterparty who can specialize in maximizing execution layer (EL) rewards. This outsourcing function is what we mean by the prhase "proposer-builder separation" (PBS). All else equal, higher EL rewards mean higher validator revenue which directly contributes to chain security as it makes staking more attractive which scales the proof-of-stake security margin as more validators join the L1 consensus set.[^1] While this incentive is nice for validators, it is a double-edged sword as the more MEV extraction becomes the norm, the more validators are required to participate to stay competitive amongst their peers. This pressure to compete is a directly centralizing force which in the long run would fragilize the validator set. The Ethereum community acknowledges PBS as a direct solution to avoid this centralizing pressure as the mechanism moves the competition to the builder counterparty, allowing each individual validator to remain unsophisticated on this front and just as competitive. Given the fundamental nature of MEV and the importance of PBS to address it, the Ethereum community also seeks as robust an implementation as possible. mev-boost is an off-chain implementation of PBS and unforunately requires a weaker trust model to instantiate. In particular, mev-boost introduces a "relay" actor that brokers the blockspace auction between builder and proposer. This relay is mutually trusted to enforce the guarantees of this auction and failures at the relay layer have led to successful hacks calling into question the PBS value proposition. Moreover, relays today are centralized entities subject to regulatory constraints that impinge upon the censorship resistance of this part of the protocol eroding core values of the Ethereum community itself. Taken together, there has been various discussion around how to improve the trust model of the relay actor, possibly enshrining some PBS construction directly into the protocol itself. This track aims to discuss these latest proposals and gain consensus around possible future directions for PBS on Ethereum.
12/12/2023thanks to @lightclient for helpful discussions right now, most of the mev-boost ecosystem relies on the flashbots/builder software to validate block submissions at the mev-boost relay. this software is a fork of geth and this fact implies overhead of maintaining the fork especially an issue when tracking changes around devnets for hard forks, etc
7/13/2023