## EIP-7251: Increase the MAX_EFFECTIVE_BALANCE --- ## Topics - Motivation - Features - Will pools consolidate? - Pros / cons --- ## Motivation Today, an entity with X stake controls X / 32 individual keys voting the same <img src="https://hackmd.io/_uploads/r16h2Cxsp.jpg" alt="dalle" width="400"/> --- ## Motivation That entity could have 1 key holding X stake and cast a single unified vote <img src="https://hackmd.io/_uploads/ryfA2AgiT.jpg" alt="dalle" width="400"/> --- ## Motivation Same security* from the protocol's POV but much more efficient :) --- ## Motivation Inneficiency inherited from the old sharding design: - Ensure high probability of honest majority per shard committee --- ## Motivation Today in mainnet: - 900k active indexes - 33k unique withdrawal credentials --- ## Motivation Too many active indexes cause: - Difficults shipping Single Slot Finality (SSF) - Increases bandwidth and compute costs --- ## Motivation Why do we want SSF? - Finality time: ~15 minutes -> 16 seconds - No re-orgs :) - Retire LMD GHOST + FFG frankenstein _Getting there takes time*_ --- ## Motivation Positive side-effects: - Auto-compounding --- ## Core feature  --- ## Security Considerations - Fork-choice - Shuffling selection - Security of committees - Churn invariants --- ## Fork-choice Everything already scaled by effective balance :) --- ## Shuffling selection Everything already scaled by effective balance :) --- ## Security of committees Balance-based aggregator VRF lottery  --- ## Churn invariants Balance-based activation and exit churn ```python class BeaconState(Container): ... deposit_balance_to_consume: Gwei pending_balance_deposits: List[PendingBalanceDeposit, MaxPendingBalanceDeposits] exit_balance_to_consume: Gwei earliest_exit_epoch: Epoch ``` --- ## Churned top-ups ```python def apply_deposit(...): state.balances.append(0) state.pending_balance_deposits.append( PendingBalanceDeposit(index, amount) ) ``` --- ## In-protocol consolidation  --- ### In-protocol consolidation  --- ### In-protocol consolidation  --- ### In-protocol consolidation  --- ### In-protocol consolidation  --- ### Consolidations and churn limit A consolidation = exit + activation Consolidation of stake $C$ --> safety reduction of $2C$ --- ### Consolidations and churn limit <img src="https://hackmd.io/_uploads/SJKxxgWip.png" alt="exit churn" width="600"/> --- ### Consolidations and churn limit <img src="https://hackmd.io/_uploads/Bklzexbja.png" alt="activation churn" width="600"/> --- ### Time to consolidate <img src="https://hackmd.io/_uploads/r15ZQxZja.png" alt="time to consolidate" width="600"/> --- ## Custom ceilings  --- ## EL triggered partial withdrawals Execution layer triggered exits & partial withdrawals (EIP-7002 extension) --- ## Slashing risks  --- ## Slashing risks  --- ## Slashing risks Partial solution: - Set initial slashing penalty to zero - Rely on the correlation, attestation, and inactivity penalties. --- ## Will pools consolidate? As of today: they agree to - No increased slashing risk - Very low one-time cost - Long-term cost reduction --- ## Implementation complexity _mild medium_ - Mostly a state transition change - Needs re-working committee caches  --- ## Is it time critical? - **Yes**, if SSF requires consolidation - **Somewhat**, if clients can't handle ↑% ETH staked --- ## Pros - Initial reduction in validator set - Future compatibility - Improved solo staking experience --- ## Cons - No guaranteed or incentivized consolidation - Engineering effort --- Thanks :)