mods

EIPS/eip-7251.md

@@ -10,25 +10,13 @@ category: Core
 created: 2023-06-28
 requires: 7002
 ---
-
 ## Abstract
 
-Increases the CL constant `MAX_EFFECTIVE_BALANCE` to 2048 ETH. This allows
-home-stakers to earn compounding rewards on their ETH and large staking 
-operators to run fewer validators for the same amount of stake. 
+Increases the constant `MAX_EFFECTIVE_BALANCE`, while keeping the minimum staking balance `32 ETH`. This allows large node operators to consolidate into fewer validators and solo-stakers to earn compounding rewards & stake in more flexible increments. 
 
 ## Motivation
 
-The current `MAX_EFFECTIVE_BALANCE` of 32 ETH is tech debt from the original
-sharding design, where we required majority honest subcommittees. This is no
-longer a requirement, as subcommittes are only used for attestation aggregation,
-and thus have a `1/N` honesty assumption. The current 32 ETH max results in an
-artificially large validator set, where staking operators run thousands of
-essentially redundant validators many of which from the same CL node. 
-
-The large and rapidly growing validator set puts an [unnecessary burden](https://ethresear.ch/t/removing-unnecessary-stress-from-ethereums-p2p-network/15547)
-on the p2p network and blocks critical protocol upgrades such as [SSF](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920). See [a modest proposal](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801) for more context.
-
+The current `MAX_EFFECTIVE_BALANCE` of 32 ETH is tech debt from the original sharding design, where we required majority honest subcommittees. This is no longer a requirement, as subcommittes are only used for attestation aggregation, and thus have a `1/N` honesty assumption. The current 32 ETH max results in an artificially large validator set, where staking operators run thousands of essentially redundant validators many of which from the same CL node. 
 ## Specification
 
 ### Constants
@@ -82,6 +70,10 @@ for a view of the CL spec changes. In summary:
 4. **Rethink ejection balance** (perhaps by reusing the `activation_eligibility_epoch` field in the validator struct). 
 5. **Allow validators to use the withdrawal credentials to specify a custom ceiling for their balance.** Partial withdrawals would kick in past the custom ceiling.
 
+## Rationale
+
+This EIP aims to reduce the total number of validators without changing anything about the economic security of the protocol. It provides a mechanism by which large node operators who control significant amounts of stake can consolidate into fewer validators. 
+
 ## Backwards Compatibility
 
 This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.