Defragment: History of EIP-7251 (MaxEB)
======

TL;DR:
------

1. [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) improves MaxEB, and is [scoping](https://eips.ethereum.org/EIPS/eip-7600) into [Electra](https://ethereum.github.io/consensus-specs/specs/electra/beacon-chain/) Upgrade ([~2025/Q1](https://x.com/TimBeiko/status/1793684244612407687)), and with the mission to [sustain validator set size growth](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989), and preparing for [SSF](https://ethereum.org/en/roadmap/single-slot-finality/) and [ePBS](https://ethereum.org/en/roadmap/pbs/).
2. [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) happens with Ethereum evolution due to demand change and information is defragmented. Many heroes have contributed to this development. MaxEB has been changed from Phase0 till now, and is only upgraded from Electra. It is a big change and all contributors should not be forgotten,
3. This article aims to collect pieces of information fragmented here and there, and recover the history of evolution.
4. Welcome suggestion and collaboration.
5. My other relevent articles on EIP-7251:
- [BeaconState and Validator Balance for EIP-7251](https://hackmd.io/@georgesheth/BJGl24HYA)
- [History of EIP-7251](https://hackmd.io/@georgesheth/rJxnQBrtC)
- [Feature Lists of EIP-7251](https://hackmd.io/@georgesheth/HJKkx3NSR)
- [Implement EIP-7251](https://hackmd.io/@georgesheth/Hk2r2BHFC)
- [Develop Push Based Custom Ceiling Partial Feature Withdraw for EIP-7251](https://hackmd.io/@georgesheth/BJ5tkLBtA)

Contributors
============

It is not a completed list and only serves the purpose for readers who want to know who write the content mentioned in the later part of the article.

| Contribuitor | From | Twitter |
| ---- | ---- | ---- |
| Mike Neuder | Ethereum | https://x.com/mikeneuder |
| Francesco | Ethereum | https://x.com/fradamt |
| Mikhail Kalinin | Ethereum | https://x.com/mkalinin2 |
| Lion | Ethereum | https://x.com/dapplion |
| Aditya Asganonkar | OffChainLabs | https://x.com/adiasg |
| Justin Drake | Ethereum | https://x.com/drakefjustin |
| Thomas Thiery | Ethereum | https://x.com/soispoke |
| Sam Mason | Ethereum | https://x.com/samcmau |
| Tim Beiko | Ethereum | https://x.com/timbeiko |
| Mark | Sigp | https://x.com/ethdreamer |
| Phil Ngo | Chainsafe | https://x.com/philngo_ |
| Jim McDonald | Attestant | https://x.com/jgm |
| Adrian Sutton | OpLabs | https://x.com/ajsutton |
| Aris Koliopoulos | RatedNetwork | https://x.com/ariskkol
| Ryan Berckmans | Ethereum | https://x.com/ryanberckmans |
| Christine Kim | Galaxy | https://x.com/christine_dkim |
| Sandra Johnson | Consensys | https://x.com/sandJohnson
| Ben Edgington | OpLabs | https://x.com/benjaminion_xyz |
| Emmanul Awosika | 2077 | https://x.com/eawosikaa |

2022/Sep/15, the Merge was successfully executed.
=================================================

Article by Ethereum Org: https://ethereum.org/en/roadmap/merge/

1. The Merge was the joining of the original execution layer of Ethereum (the Mainnet that has existed since genesis) with its new proof-of-stake consensus layer, the Beacon Chain. It was a truly exciting step in realizing Ethereum vision, more scalability, security, and sustainability.
2. Initially, the [Beacon Chain](https://ethereum.org/en/roadmap/beacon-chain/) shipped separately from Mainnet. Ethereum Mainnet - with all its accounts, balances, smart contracts, and blockchain state - continued to be secured by [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/), even while the Beacon Chain ran in parallel using [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/). The Merge was when these two systems finally came together, and proof-of-work was permanently replaced by proof-of-stake.
3. The Merge did not change anything for holders/users. No history was lost in The Merge. As Mainnet merged with the Beacon Chain, it also merged the entire transactional history of Ethereum.
4. Before the Merge, the terms 'Eth1' and 'Eth2' were used. After merging 'Eth1' and 'Eth2' into a single chain, there is no longer any need to distinguish between two Ethereum networks; there is just Ethereum. The term 'Eth2' has been deprecated. To limit confusion, the community has updated these terms:

1. 'Eth1' is now the 'execution layer', which handles transactions and execution.
2. 'Eth2' is now the 'consensus layer', which handles proof-of-stake consensus.
5. These terminology updates only change naming conventions; this does not alter Ethereum's goals or roadmap.
6. In order to simplify and maximize focus on a successful transition to proof-of-stake, The Merge upgrade did not include certain anticipated features such as the ability to withdraw staked ETH. This functionality was enabled separately with the Shanghai/Capella upgrade.


2022, Upgrading Ethereum
========================

Article from Ben Edgington, https://eth2book.info/capella/part2/incentives/balances/

1. A cookbook to understand how validator effective balance works and other concepts.

2019/Nov/28, Understanding Validator Effective Balance
======================================================

Article from Jim, https://www.attestant.io/posts/understanding-validator-effective-balance/

1. An early article to introduce how validator.effective_balance works, and give analysis on how penalties and rewards work.

2022/Apr/06, Exploring Eth2: Cost of Adding Validators
======================================================

Article by Adrian, https://www.symphonious.net/2022/04/06/exploring-eth2-cost-of-adding-validators/

1. Adrian found that the first 64 validators you add to a node are quite expensive in terms of CPU usage and network traffic, but if you can run 64 validators well, then you can likely run thousands of validators well because you're already processing the bulk of the attestations.

2022/Jun/28, Single Slot Finality, Layer 1 R&D - Day 2
======================================================

Talk by Vitalk, https://www.youtube.com/watch?v=ojBgyFl6-v4&t=755s

1. Vitalk mentioned the path to Single Slot Finality needs to have a health size of validator set.
2. We should focus on bringing more solo-stakers to increase diversity.

2023/May/10, Removing Unnecessary Stress from Ethereum's P2P Network
====================================================================

Article by Aditya, https://ethresear.ch/t/removing-unnecessary-stress-from-ethereums-p2p-network/15547

1. Aditya noticed that Ethereum was processing 2x the number of messages than are required.
2. The root cause of this unnecessary stress on the network is the mismatch between the number of validators and the number of distinct participants (e.g. Staking entities) in the protocol.
3. It analyses the reason and proposes to increase `MAX_EFFECTIVE_BALANCE`.


2023/May/22, Increase MAX_EFFECTIVE_BALANCE minimal spec change #3
==================================================================

Article by Mike, https://github.com/michaelneuder/consensus-specs/pull/3/files

1. First PR and Justin Drake suggested adding `MIN_ACTIVATION_BALANCE`.

2023/May/23, Security Considerations and Spec Changes for a MAX_EFFECTIVE_BALANCE Increase
==========================================================================================

Article by Francesco and Mike, https://notes.ethereum.org/@fradamt/meb-increase-security

1. It analyses the impact on the security model of 3 committees.

1. Slot committees
2. Subcommittees
3. Sync committee
2. It also proposes the changes to the churn invariants to control queue:

1. Validator activations
2. Validator exits
3. Validator balance top-ups
4. Validator withdrawals.

2023/May/24, Solo stakers: The backbone of Ethereum
===================================================

Article by Aris, https://blog.rated.network/blog/solo-stakers

1. It only sees 6.5% of 500k validators as solo staker, and the stake represented by what highly diverse and distributed set of validators that provide a strong backbone for the network as a whole.

2023/Jun/06, Increase the MAX_EFFECTIVE_BALANCE -- a modest proposal
===================================================================

Article by Mike, Franscesco, Aditya and Justin. https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801

Initial draft is here: https://notes.ethereum.org/@mikeneuder/increase-maxeb

1. It is the first discussion formally focused on MAX_EFFECTIVE_BALANCE.
2. It explains why we should increase MaxEB.

1. Part of the path to future roadmap upgrades, mainly SSF and ePBS.
2. Reduce pressure for p2p layer for messaging passing and leave the stakes in the balance to reduce withdrawal load request in auto-withdrawals.
3. Democratization of compounding stake to benefit solo-stakers, and reduce the optional overhead of managing many validators.
3. It also explains why we should not increase MaxEB.

1. Impacts to the simplicity of the current implementation.
2. Impacts on the existing design of consideration around committee.
4. This article drives lots of attention and discussion.

2023/Jun/13, Cascading Network Effects on Ethereum's Finality
=============================================================

Article by Thomas, https://ethresear.ch/t/cascading-network-effects-on-ethereums-finality/15871

1. It also investigated the fact that Ethereum mainnet experienced large-scale network perturbations, which resulted in delays in transaction finalization in 2023/May/11 and 2023/May/12 evening.
2. It analyses the perturbations in the p2p network. It discovered that clients reprocessing valid-but-old attestations and managing deposits caused excessive CPU usage. This consequently affected validators' ability to complete their tasks and to transmit and receive attestations and blocks in a timely manner.

2023/Jun/28, EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
=========================================================

EIP by Mike, Francesco, Lion, Mikhail, Aditya, Justin, lightclient, https://eips.ethereum.org/EIPS/eip-7251

1. Mike published the first EIP version with the description and some suggestions.
2. Lion and Mikhail then PR to add more pseudocode.

2023/Jul/12, Beacon node load as fn of validator set size
=========================================================

Article by Lion, https://hackmd.io/@dapplion/beacon_load_set_size

1. Lion studies the tradeoffs affect resource consumption in this artile.
2. With the increase of validator set size, If client teams are forced to start adding further performance optimizations to handle larger validator set sizes, the risk of bugs and cascading failures increases.
3. Further, if higher bandwidth and compute resources are necessitated, solo-staking becomes more costly, which is a centralization pressure on an already [small set](https://blog.rated.network/blog/solo-stakers) of solo-stakers.

2023/Jul/16, FAQ on EIP-7251; Increasing the MAX_EFFECTIVE_BALANCE
==================================================================

Article by Mike, Francesco, Lion and Mikhail, https://notes.ethereum.org/@mikeneuder/eip-7251-faq

1. It explains how Danksharding design can relax 32 ETH MaxEB restriction.

1. In the original sharding design, the attesting committee for each slot was split into subcommittees (referred to as `committee` in the [spec](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_committee)) that each needed to be majority honest. Capping the `MaxEB` at the relatively low value of 32 ETH allowed stronger guarantees about the safety of the subcommittees. Within the Danksharding design, the subcommittees are no longer levereged as previously expected; they are only used for attestation aggregation. Now we only need a single honest aggregator in each subcommittee, which makes the 32 ETH `MaxEB` unnecessary.
2. It also references the stats of Ethereum reorg from Toni Wahrstatter

1. https://reorg.pics/ and https://x.com/nero_eth/status/1742139964714791078
2. Toni found that Solo stakers miss relatively more slots than professional NOs. And he suggested "Instead of relying on pools, we must find ways to support solo stakers better."
3. It also confirms that MaxEB has no negative impacts to the proposer selection process. He said that the [proposer selection process](https://blog.rated.network/blog/solo-stakers) already uses `effective_balance` to weight the probability that a validator is selected as a proposer. This allows larger validators to continue being selected proportionally to their weight and thus doesn't reduce their rewards for participation (e.g., a 320 ETH validator is selected to propose 10x more frequentlythan a 32 ETH validator).

2023/Jul/31, [EthCC6] Increasing validators maximum effective balance proposal
==============================================================================

Talk by Mike, https://www.youtube.com/watch?v=Qyws8u6TC5U

1. Mike presents EIP-7251 in EthCC6

2023/Aug/10, bigboi-beaconchain-test-2
======================================

Article by Sam, https://notes.ethereum.org/@parithosh/bigboi-beaconchain-test-2

1. Sam did a simulation of large validator size to check on the performance.
2. He find ou that "2.1m validator total with 420 nodes. The proposal rates are extremely healthy at ~80% range (compared to attestations). The attestations however aren't, indicating an issue in performing attestation duties in time or attestation propagation issues."

2023/Aug/30, Slashing Penalty Analysis; EIP7251
===============================================

Article by Mike and Barnabe, https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509

1. Mike studies slash fairness and make the proposed change.


2023/Sep/14, Paths Toward Reducing Validator Set Size Growth
============================================================

Article by Christine, https://www.galaxy.com/insights/research/paths-toward-reducing-validator-set-size-growth/

1. She studies the dangers around a large validator size and the solutions proposed to mitigate this issue.
2. One solution she examined is eip-7251.

2023/Oct/02, eip7251 related work
=================================

Gist by Mike, https://gist.github.com/michaelneuder/cafabcfcfcccc45e44ab9d6b1c7b4e1d

1. Mike created a table to list all information related to eip-7251, but is slightly outdated due to development.

2024/Nov/13, Staking Gathering - Devconnect Istanbul 2023 - Main Stage - Day 1
==============================================================================

Talk by Mike, https://www.youtube.com/watch?v=d_cpJtvv5cE

1. Mike talked again in Devconnect Istanbul 2023

2023/Nov/28, MaxEB slashing risks
=================================

Article by Lion, https://hackmd.io/@dapplion/maxeb_slashing_risks

1. Lion studies the MaxEB slashing risk.

2024/Jan/05, Proposer selection with increased MaxEB (EIP-7251)
===============================================================

Article by Sandy and Anders and others, https://ethresear.ch/t/proposer-selection-with-increased-maxeb-eip-7251/18144

1. Proposer selection is already weighted by the ratio of their effective balance to MAX_EFFECTIVE_BALANCE. Due to the lower probabilities, this change will slightly increase the time it takes to calculate the next proposer index."
2. Sandy undertook some additional analysis of proposer selection which is summarised in this blog post.
3. It exams `compute_proposer_index()`.
4. It then talked on youtube here: https://www.youtube.com/watch?v=l05mWGS-0Y4&t=928s

2024/Jan/08. EIPs For Nerds #2: EIP-7002 (Execution Layer Triggerable Exits)
============================================================================

Article by Emmanul Awosika, https://ethereum2077.substack.com/p/eip-7002-execution-layer-exits

1. This is a detailed analysis of EIP-7002 with lots of related concepts explained.
2. It also talked about other Electra in-scoped EIPs, e.g. EIP-6110, EIP-7002.

2024/Jan/18, EIP-7600: Hardfork Meta - Pectra, EIPs included in the Prague/Electra Ethereum network upgrade
===========================================================================================================

EIP by Tim Beiko, https://eips.ethereum.org/EIPS/eip-7600

1. It lists out all the Pectra in-scoped EIPs, and EIP-7251 is one of them.
2. EIP-6110, EIP-7002 EIP-7251, EIP-7549 and EIP-7594 require changes to Ethereum's consensus layer.
3. EIP-7692, as well as EIP-2537, EIP-2935, EIP-6110, EIP-7685, and EIP-7002 require changes to Ethereum's execution layer.

2024/Jan/23, Validator consolidation in EIP-7251
================================================

Reference by Francessco, Mike and Mikhail, https://notes.ethereum.org/@fradamt/maxeb-consolidation

1. They explained the consolidation request and process for EIP-7251.
2. *"In-protocol consolidation", a key* *[feature](https://notes.ethereum.org/@mikeneuder/eip7251-features)* *in the EIP, allows validators to merge their effective balances (thus becoming a single validator with the combined stake)* *without* *fully exiting and re-entering the protocol through the activation queue.*
3. *Due to the importance of this feature, we present an FAQ document that aims to answer the natural questions about the process and justify the design decisions.*

2024/Jan/23, Lodestar Proposals for Next Electra + Prague Fork
==============================================================

Article by Phil, https://blog.chainsafe.io/lodestar-proposals-for-next-electra-cancun-fork/

1. It summaries AllCoreDevs Execution Meeting 179, https://youtube.com/live/FhMBatolkOM
2. EIP-7251 is included

2024/Feb/29, Endgame 2.0: A Guide to Vitalik's Ethereum Roadmap
===============================================================

Talk by Mike, https://www.youtube.com/watch?v=jqVaycBINdc

2024/Mar/06, promote EIP-7251 should include into Pectra upgrade
================================================================

Tweet by Ryan, https://x.com/ryanberckmans/status/1765072922392367133

2024/Mar, EIP-7251 MaxEB Breakout Call - March 20, 2024
=======================================================

Hosted by Phil Ngo and others,

1. 2024/Mar/21, call #1, https://hackmd.io/@philknows/BkEL0Fu0p
2. 2024/Mar/22, call #2, https://github.com/ethereum/pm/issues/989
3. 2024/Mar/27, call #3, https://hackmd.io/@philknows/BJCaLJf1A
4. 2024/Apr/03, call #4, https://hackmd.io/@philknows/Sy2kQAq1C
5. 2024/Apr/19, call #5, https://hackmd.io/@philknows/S1JbLXmlA
6. 2024/Apr/16, call #6, https://hackmd.io/@philknows/Hywht12eR
7. 2024/Apr/17, call #07, https://github.com/ethereum/pm/issues/1018

2024/Mar/28, Inactivity leak under MaxEB (EIP-7251)
===================================================

Article by Lion, https://lighthouse-blog.sigmaprime.io/maxeb-inactivity-leak.html

1. This article studies inactivity leak under MaxEB. It concluded that we should do nothing under EIP-7251. Leave the parameter at `EJECTION_BALANCE = 16`, ship EIP-7002, and promote client diversity so stakers don't have to worry about the inactivity leak.

1. Does it affect finality recovery? No
2. Does it increase the balance leaked during non-finality? No
3. Does it increase the time to eject offline validators during finality? Yes but long time

2024/Apr/03, MaxEB @ Lido
=========================

Article by Lido, https://hackmd.io/@lido/ryxfTIRFkC

1. Lido talked about the impacts to their protocol when EIP-7251

1. Lido distributes stake and rewards to operators based on the number of active validators, not their balance. The ability to switch to 0x02 allows the node operator to accumulate significantly more stake on the validator than the protocol intended, and the voluntary consolidation of validators on CL allows the operator to significantly reduce the number of active validators for the same amount of stake, which will result in all new deposits being directed to the operator's keys. This opens up an attack vector for operators to attack the protocol accounting.
2. Lido protocol counts the participating validators based on the preuploaded and deposited through the protocol keys, not by withdrawal credential. Consolidation on validators not deposited through Lido contracts but with Lido withdrawal credential allows a malicious actor to break the link between validators and operators and disrupt the accounting of the protocol.
3. The proposed changes alter the way the total balance of locked ETH on the Consensus Layer is determined. In addition to the validators' balance, the lists pending_balance_deposits and pending_partial_withdrawals must also be taken into account.
2. To accommodate the changes proposed in maxEB, a significant portion of the protocol needs to be revisited: accounting, deposits, stake and reward distribution among operators, validator withdrawals, etc.
3. The main issue seems to be the ability to consolidate and switch to 0x02 without the involvement of the withdrawal address.

2024/May/01, MaxEB Slashing Risks: expected loss and variance
=============================================================

Article by Maxim, https://hackmd.io/@5wamg-wlRCCzGh0aoCqR0w/r1aYbH8x0

1. It studies how concentration (number of validators for the same amount of staked ETH) impacts expected losses on double attestation slashing incidents within different network parameters (divergent rate) and reaction time for incident

2024/05, Annotated Electra Spec - The Beacon Chain
==================================================

Article by Francesco, https://notes.ethereum.org/@fradamt/annotated-spec-electra

1. It drafts how EIP-7251 and other EIP should be accommodated into Electra Beacon Chain Spec.

2024/May/24, How to ship Pectra by 2025/Q1
==========================================

Tweet by Tim, https://x.com/TimBeiko/status/1793684244612407687

TODO:
====
1. More history will come over and I will continue to watch and update here.