The Good Tech Companies - EIP-7251: Raising Maximum Effective Balance For Validators

Episode Date: January 14, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/eip-7251-raising-maximum-effective-balance-for-validators. Learn how EIP-7251 increases maximum effective balance (MaxEB) for Ethereum validators and its impact on staking, rewards, and the Ethereum network. Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #ethereum, #ethereum-eips, #ethereum-upgrades, #ethereum-pectra-upgrade, #ethereum-pos, #ethereum-consensus-layer, #2077-research, #good-company, and more. This story was written by: @2077research. Learn more about this writer by checking @2077research's about page, and for more stories, please visit hackernoon.com. EIP-7251 proposes increasing the maximum effective balance (MaxEB) for Ethereum validators, enhancing staking efficiency and overall network performance. This change aims to improve validator rewards and network security by optimizing resource utilization. Read the full article to explore the technical details and implications for Ethereum's future.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. EIP-7251, Raising Maximum Effective Balance for Validators, by 2077 Research. I often talk about rational optimism. I wrote an entire article about the intersection between rational optimism and crypto at the height of 2022's bear market, and like to identify as a rational optimist. But there are many downsides to rational optimism that people like Naval Ravikant and Andreessen Horowitz won't tell you. Being a rational optimist isn't just about working to solve problems, it also involves, a. Acknowledging you might create new problems,

which will only show up later, in the process of solving an existing problem, and b. dealing with the despair that comes from seeing how your previous problem-solving actions led to another problem in the present. As a TED talk once put it, the art of progress is essentially creating new problems to solve greater than, progress does not mean that everything becomes better for everyone everywhere greater than all the time. That would be a miracle, and progress is not a miracle but greater than problem solving. Problems are inevitable and solutions create new problems greater than which have to be solved in their turn. Steve Pinker This semi-philosophical introduction is vital to discussing the next Ethereum improvement proposal, EIP. In the EIPs for Nerd series, EIP-7251. EIP-7251 is apropos change to Ethereum's proof-of-stake

POS consensus protocol that will increase the maximum effective balance for validators on the beacon chain from 32 ETH to 2048 ETH. EIP-7251 also introduces validator consolidation, which will allow large stakers to run fewer validators by consolidating balances from multiple validators into a single validator. While EIP-7251 looks like a simple change, increasing the validator's effective balance is one of the most significant changes to the core protocol, possibly right up with enabling withdrawals, since the merge. This article provides a row overview of EIP-7251, including the advantages and potential drawbacks of implementing the EIP, and includes enough details to help make sense of the WHYND how of increasing for validators. Let's dive in. Setting the stage. A lack of serenity in Ethereum's consensus. Ethereum's transition proof of stake, FKA, Ethereum 2.0 inches, was originally called the serenity upgrade. I don't know why the name,

serenity, was chosen, but many expected the serenity upgrade to fix all of Ethereum's problems, so the name seems fitting. Now, the Ethereum 2.0. Note that I'm using Ethereum 2.0 inches for historical context only, we got isn't quite the Ethereum 2.0 some imagined it would be, i.e. achieving visa-like scale with execution sharding, or transitioning from the EVM to EWASM for more efficiency, but it works. For example, solo stakers currently make up a decent percentage of the beacon chain's validator set. Recall that reducing the barrier to running a validator was a key goal of switching to proof-of-stake. And Ethereum POS has remained World War III resistant, despite concerns around centralization of stake. There are a rough spots, including something about LSDs, not the drug,

but nothing enough to stop the beacon chain from operating as the economically secure, green, decentralized settlement layer it was designed to be. All seems well with Ethereum's consensus, but problems are hiding under the surface. One of those problems is the negative second-order effects of having an extremely large validator set. The beacon chain currently has over 1 million active validators. Having many validators theoretically improves Ethereum's decentralization, especially if you compare it to traditional proof-of-state protocols that limit participation in consensus to 100 to 200 super validators. But an extremely large validator set introduces problems with implications

for network's health and long-term sustainability. Unsurprisingly, many of these problems have only become evident as the validator set on Ethereum increased in the months following the merge and the activation of withdrawals in the Shanghai Capella upgrade. While Ethereum's validator set growth was inevitable, especially with the popularity of liquid staking, the large validator set is partially a consequence of previous design decisions, tech debt, in nerd speak. This explains why I started with a philosophical talk on rational optimism, to show how creating solutions leads to creating complex problems that demand even more complex solutions. The design decision in question, limiting the validator's maximum effective balance, to 32 ETH. In the next section, we'll see what effective balance means and explore how capping the maximum effective

balance at 32 ETH contributes to the beacon chain's growing validator set. Understanding max underscore effective underscore balance in Ethereum. A validator on Ethereum has two balances, an actual balance and an effective balance. The actual balance is simply the sum of the validator's initial deposit and the rewards minus any penalties and withdrawals. The effective balance is derived from the validator's actual balance and represents the maximum amount a validator has at risk from the protocol's perspective. We can further break down this definition to have a better mental model of a validator's effective balance one. The maximum amount a validator has at risk is a reference to the core principle of proof of stake. Economic security is a function of a protocol's capacity

to levy a high cost on actions that can be construed as an attack on the protocol. Whether those actions are deliberate or accidental is irrelevant. By destroying part or all of the collateral pledged by validator before joining the protocol. An example of protocol violating behavior is lying about the validity of a block. Each validator votes for a block and is expected to vote for a block if it has evidence the block includes valid transactions. This is why POS protocols like Ethereum's Gasper are designed to use validator balances to inform decisions like selecting a validator to propose a new block, calculating rewards, and slashing validators that provably deviate from the protocol's rules. The theory is that a validator

with more at stake has less incentive to act dishonestly since the penalty for dishonest behaviors is dynamic and increases in proportion to the collateral pledged by the validator. In the context of the beacon chain, a validator's effective balance determines the validator's weight or influence in the consensus protocol. For instance, a beacon chain block becomes final, i.e. irreversible, if the total stake of validators that voted for a block represents a supermajority, 66% or more, of the total stake of all active validators. To understand how and where a validator's effective balance is used in beacon chain consensus, I encourage reading the economic aspects of effective balance. Backslash dot 2. From the protocol's perspective,

means the beacon chain always sees each validator as having at most 32 ETH, the maximum effective balance, staked in the protocol. Any other amount over the maximum effective balance isn't considered at stake and cannot be slashed, nor does it count towards the rewards a validator earns for carrying out duties correctly, making it ineffective from the protocol's perspective. A validator's actual balance will expectedly increase once it starts receiving rewards and doesn't get slashed. However, the beacon chain conducts a sweep at every block and automatically withdraws amounts over 32 ETH to the execution layer address specified in the validator's withdrawal credentials, CEIPs for NERDS No. 2,

EIP-7002, execution layer triggerable exits, for an in-depth discussion of withdrawal credentials. Not every validator receives partial rewards immediately, but most estimates suggest that a validator will receive partial rewards on a frequency of 5 to 7 days. Why was max underscore effective underscore balance set to 32 ETH initially? The value of 32 ETH is the as a carryover feature from the original S Harding roadmap. At the time, the vision was to split the Ethereum network into 64 sub-networks, shards, with each subnet processing sets of transactions in parallel and the beacon chain serving as a coordination layer for the network.

Under this arrangement, every active validator on the beacon chain was assigned to a committee designated to produce attestations for one of the 32 slots in an epoch. The committee attesting for each slot was broken into 16 subcommittees A.K.A. beacon committees with a target of 64 validators and a maximum of 128 validators per subcommittee. Backslash dot. Each subcommittee would validate one of the 64 shards and attest to blocks from shard proposers. The shard proposer aggregated attestations from at least two-thirds of the validators in a subcommittee before broadcasting the block's header, which included signatures of validators that attested to the block, to the beacon chain. Backslash dot, validators in the

main committee for the slot voted on the validity of shard blocks by checking block headers, described as cross links, and confirming that a majority of validators in the subcommittee signed the block, and those signatures corresponded to public keys of existing validators. Backslash dot, a concern with this sharding design was the susceptibility of a shard to attacks by a dishonest majority of validators, an adversary that controlled enough members of the committee attesting to a shard's transactions, e.g. greater than two-thirds, had a high probability of getting the beacon chain to finalize invalid shard blocks. Thus, it was necessary to ensure that every validator in the protocol had an equal probability of appearing in the committee for a shard blocks. Thus, it was necessary to ensure that every validator in the protocol had

an equal probability of appearing in the committee for a shard. This made it difficult for an attacker to predict if the validators it controlled would end up in a particular shard committee and reduce the likelihood of a malicious takeover of one or more shards. Backslash dot. Validators had roughly the same weight or influence in the consensus protocol. Without this feature, an attacker still had a chance of gaining undue influence in a subcommittee as the protocol used the total validator weight, the amount staked by each validator that attested to a block, and not the validator count, the number of validators that voted for a block, to determine if a block was eligible for finalization. The solution for problem number one was to design a verifiably random function, VRF, and use it as a source of randomness to inform

validator assignments to committees. A visual description of the random assignment of validators is shown below. Solving problem number two meant limiting each validator's effective balance, which represented its weight in the protocol, to a constant of 32 ead. If was variable, an attacker could finalize an invalid block if it controlled two-thirds of the entire stake in a committee, even if two-thirds of validators in the committee were honest. Conversely, giving every validator equal weight in the committee reduced the possibility of a minority of validators exerting outsized influence on a sharts consensus. You may also notice is also the minimum deposit amount, 32 ETH, required to activate a validator. This isn't a coincidence. Unlike the original proposal for a minimum deposit of 1500 ETH, a lower activation balance of 32 ETH increased the likelihood of

more people running beacon chain validators and ensured adversaries had a negligible probability of controlling two-thirds of validators in a committee. Minimum committee size explained provides a formal explanation of this concept and is useful for understanding the original security design of subcommittees. Why is a max underscore effective underscore balance of 32 ETH no longer necessary. Subcommittees became surplus to requirement once Dank sharding replaced the original sharding roadmap. More importantly, the beacon chain security property, e.g. the validity of transactions finalized by the consensus protocol, was no longer reliant on the assumption that two-thirds of validators in every subcommittee were honest. Why the change? In the execution sharding model, each shard was expected to run an instance of the EVM,

Ethereum virtual machine, and process state transitions. An attacker controlling a majority of validators in the subcommittee attesting to a shard could do nasty things, like steal funds from a smart contract by finalizing invalid state transitions. Backslash dot. Similarly, subcommittees in the original data sharding design, before dank sharding, required a majority of validators to be honest. Otherwise, a malicious shard proposer could perform a data withholding attack, refuse to publish blobs posted to the shard, and degrade the liveness and safety of rollups that relied on Ethereum for data availability. Backslash.dank sharding has since superseded both sharding designs and replaces the

multi-proposer model with a single-proposer model. There is precisely one block added to the beacon chain during a slot, and all validators assigned to that vote for this block. Since every subcommittee is voting on the same set of transactions, an attacker needs to control a supermajority of all active validators in the slot to mount a successful attack. Finalizing an invalid block To clarify, validators attesting in a slot are still broken up into subcommittees, however, the only benefit to assigning validators to subcommittees is improving the efficiency of aggregating attestations on the beacon chain. For context, a valid block must include signatures from a quorum of validators whose stakes represent a supermajority, greater than equals two-thirds,

of the total stake in a slot committee. Assuming all validators have the same maximum effective balance of 32 ETH, a block proposer needs signatures from two-thirds of validators at testing in the slot. Aggregators are introduced into the subcommittees, with each subcommittee having 16 aggregators. To reduce bandwidth requirements for proposers and validators, an aggregator collects attestations, signatures, to a block from validators assigned to a subcommittee and creates an aggregate signature using the BLS signature aggregation algorithm. Aggregators from a subcommittee send aggregate attestations to the proposer, and the proposer chooses the best aggregate attestation. Best, meaning, the aggregate attestation with the most signatures. Backslash dot, the upside. Proposers don't have

to aggregate signatures from thousands of validators assigned to a slot. The beacon chain has 800,000 plus validators today, so every slot in a 32-slot EPIC will have approximately 25,000 validators attesting per slot. In addition, validators in the slot committee only verify 64 aggregate signatures instead of verifying thousands of signatures on a block before finalizing the block. We need a subcommittee to have one honest aggregator since a validator can only influence beacon chain consensus if its attestation is included in a block. A dishonest aggregator can manipulate the fork choice rule by refusing to broadcast aggregate attestations to the proposer or excluding attestations from a set of validators. However, if at least one of the 16 aggregators in a subcommittee is honest and doesn't censor attestations, honest validators in the subcommittee

can influence the beacon chain's fork choice mechanism. The observation that subcommittees can operate with honest minority, 1 of n, assumptions implies that setting to a constant of 32eth is no longer necessary. We could leave the maximum effective balance untouched in the spirit of, IFANT broke, don't fix it. But capping the max EB for validators introduces new problems exacerbated by the increasing appeal of staking on Ethereum. Why is capping max underscore effective underscore balance at 32 ETH a problem today? Imagine you're running a staking service and promise stakers I popping APRSON staked ETH. To hold up your end of the bargain and profit from the arrangement, you need

to earn enough rewards from validating to pay back the promised yield and cover operational costs. However, the beacon chain caps the maximum effective balance for each validator at 32 ETH and automatically schedules every additional way for withdrawal. Plus, even if each validator at 32 ETH and automatically schedules every additional way for withdrawal. Plus, even if your validator's balance reaches 33 ETH before the withdrawal sweep activates, the extra 1 ETH is inactive and doesn't figure into the calculation of rewards. Fortunately, there's a simple workaround. You can combine excess balances of multiple validators to fund a new 32-eth validator and start earning fresh rewards. Repeating this process, earn rewards right-pointing arrow withdraw rewards right-pointing

arrow consolidate rewards into 32-eth right-pointing arrow activate a new validator. At intervals compounds staking rewards and ensures compound staking rewards and ensures you can keep stakers happy, pay taxes, and remain profitable. You can even increase profits from economies of scale by running multiple validators on the same machine, a validator, as simply a computer process identified by a public-private keypair. On the surface, this looks like a good business model for an institutional's taking service or staking pool. But it doesn't take a genius to see the problem. A large staking pool is forced to spin up multiple validators to maximize earnings even if the same entity operates those validators. The emphasis on the last part reflects the differences between the

network's notion of a validator and the real-world notion of a validator. The network sees each validator as a unique entity. A validator joins the entry queue after placing a deposit in the deposit contract. The deposit message is indexed with a unique ID. Once activated, the validator sends attestations that must be processed separately from attestations sent by other validators. Also, balances for two validators cannot be merged in protocol. Both validators have to exit before their stakes are combined and used to fund a new validator. The cumulative balances of the two validators must be lower than the of 32 ETH for the new validator to earn rewards for every unit of ETH staked. In real-world scenarios,

multiple validators may be funded by the same address and share the same withdrawal credentials. Additionally, messages, including attestations and voluntary exits, broadcasted on the network may originate from the same entity that controls signing keys for multiple validators. Similarly, the deposit message for two validators may be from the same operator who is simply consolidating rewards from existing validators to activate new validators, with all validators running on the same machine. To illustrate, the biggest staking pool today, Lido, controls more than approximately 275,000 validators and has 40-plus node operators. Seeing the outsized ratio of validators to node operators, it doesn't take a genius to see that Lido's 275,000 validators can be more accurately described as Lido's 6,875 validators. This assumes

each operator controls an equal number of validators and all validators run on the same machine. But the beacon chain still sees Lido as having 275,000 validators in what some describe as artificial decentralization. Artificial decentralization on the beacon chain is problematic for different reasons. Problem number one. More computational resources are spent on processing consensus messages from the same logical entity since, as mentioned previously, deposits and attestations have to be processed on a per-validator basis. This increases the load on the P2P layer, which is now broadcasting redundant messages, and makes it difficult for consensus nodes to sync the chain. Backslash dot.

Problem number two. Staking services and staking pools incur increased overhead from running multiple validators to maximize earnings. The process of consolidating rewards from existing validators into a new validator is also cumbersome. A new validator has to wait in the entry queue for a variable delay, which can be as long as a month or more, depending on the queue's current capacity. While problem number two isn't strictly a concern for protocol developers,

problem number one has negative implications for the health and stability of Ethereum's consensus. Higher bandwidth requirements can disincentivize solo staking due to the additional cost of investing in hardware upgrades. This creates the centralizing effect that the beacon chain's design, e.g. 32ETH as the minimum stake amount, was supposed to prevent. Backslash. Client developers may be forced to implement optimizations to deal with an increase in bandwidth and memory requirements, which increases the risk of bugs from frequent code rewrites and updates. Presently, consensus-related data like deposits, validator pubkeys, and attestations are directly stored in the beacon chain state and consensus

clients must keep this state in memory to compute valid state transitions. Backslash dot. In worst-case scenarios, several validators may not process consensus messages fast enough to keep up with the rest of the chain and temporarily drop off the network. This can stall the beacon chain's ability to finalize blocks, especially if the set of remaining validators doesn't meet the 66% of stake threshold required to attest to a block before it achieves a notion of finality defined by Ethereum's LMD ghost algorithm. These aren't theoretical concerns, with recent incidents highlighting the drawbacks of a large validator set. Cascading network effects on Ethereum's

finality discusses two non-finalization incidents, where the number of attesting validators dropped below 66% on July 22, 2023. While the root cause was a bug that caused consensus clients to spend computational resources on processing valid but old attestations, which prevented validators from processing newer attestations, the issue was likely exacerbated by the number of valid but old attestations processed by clients. If the number of attestations was low, clients could theoretically catch up faster with the network, although not as fast as if they were processing attestations from the current epoch. Backslash. In a DevConnect 2023 talk, Mike Neuter, researcher at the Ethereum

Foundation and one of the authors of EIP-7251, discusses the experience of developers who ran a testnet with 2.1 million validators, where the chain was unable to finalize for long periods due to the inability of consensus clients to process a high number of attestations from validators. To put this discovery into context, the beacon chain is already close to 900,000 validators and, given current rates of deposits, will likely reach 2 million validators in the next few years. Additionally, experiments have put upper bounds on the number of BLS signatures from validators that can be efficiently aggregated using state-of-the-art aggregation schemes like Horn. This has implications for future upgrades on Ethereum's roadmap, such as Single Slot Finality, SSF, and Enshrined Proposer Builder

Separation, EPBS, that rely on a threshold of attestations being broadcast and approved within a short window, EG. Single Slot Finality requires aggregating and verifying signatures from super majority of all validators, 66% or more, in the 12-second duration of a slot. EIP-7251 is a solution for reducing Ethereum's validator set. Proposed solutions to the problem of a beacon chain unbounded validator set include adjusting validator economics, e.g. reducing rewards. Since staking pools can spin up additional validators by combining rewards from old validators, reducing validator rewards can slow down the rate at which new validators are activated on the beacon chain. Backslash dot. Placing limits on the number of valid validators and keep the validator set at the levels required for things like single-slot finality and enshrined PBS to

function correctly. Both approaches involve radical changes with significant consequences. Approach number one requires drastic changes to staking rewards and may have broad knock-on effects for the staking ecosystem. Approach number two has trade-offs depending on what happens when the validator set hits the preset limit. An old validator's stay, OVS, scheme risks entrenching a set of validators, which can have consequences, even for short periods. A new validator's stay, NVS, scheme introduces an MEV auction as validators would compete to enter the beacon chain, even older validators may be incentivized to compete with new entrants in a post-MEV world where MEV revenue exceeds validator rewards. However, there is another option that is simple enough to implement and effective at contracting Ethereum's validator set. This solution is

proposed INEIP-7251 and derives from a simple observation. We can curb artificial decentralization on the beacon chain by allowing multiple validators operated by the same entity to be consolidated into a single validator. Consider a hypothetical node operator running four validators. In the current beacon chain specification, each validator has to individually sign blocks in the current beacon chain specification, which inflates the validator set as the same person controls all four validators eip 7251 proposes a validator consolidation mechanism that allows the node operator to merge the 432 eth validators into one validator with a total stake of 128 ed this makes sense

from the operator's perspective as they only have to sign one message for the one validator they now control. It also makes sense from TheNetwork's perspective. A 96 ETH validator can be treated as one validator instead of 432 ETH validators, which reduces the number of attestations processed by the consensus protocol. Significantly, it doesn't change anything about the protocol. Validators are still slashed and rewarded according to the amount staked, e.g. A 96-eth validator is slashed differently from a 72-eth validator and preserves existing guarantees of economic security. But there are some blockers to implementing validator consolidation on Ethereum.

The current value of is hard-coded into the beacon chain protocol and needs to change for validator consolidation to become a reality specifically has to increase by a significant factor k enough for validator consolidation to decrease the number of validators on the beacon chains validator substantially backslash dot no mechanism for signaling to the protocol that the balance of a validator, validator number one, should be added to the balance of another validator, validator number two, in protocol exists. Validator number one has to exit the beacon chain, after which validator number two's balance can be increased via top-up, with funds from validator number one's withdrawal. This is suboptimal from a UX

perspective as a staking operator wishing to consolidate two or more validators has to exit those validators and combine their stakes to fund a new one. EIP-7251, appropriately named EIP-7251, increase max underscore effective underscore balance, modifies the beacon chain specification and introduces a slew of changes necessary to implement and incentivize consolidation of validators on the consensus layer. In the next section, we'll take an in-depth look at those changes before discussing the pros and cons of implementing EIP-7251, especially the proposal to increase for validators an overview of eip 7251 increase max underscore effective underscore balance eip 7251 introduces a significant change to the core consensus protocol an increase in from 32 ed to 2048 ed where k equals 64 while defining as 32 ed

this removes the biggest blocker to the consolidation of validators and is arguably the most critical component of the plan to contract Ethereum's validator set through validator consolidation. But there are other features, beyond an increased maximum effective balance, that are needed to implement validator consolidation without decreasing existing security mechanisms or increasing operational overhead and risk for solo stakers and staking services. Thus, EIP-7251, contrary to what the EIP's name suggests, does more than increase the maximum effective balance for validators. We'll go through these changes in detail subsequently. Note, this is intended to be

a rough overview of changes proposed by EIP-7251 rather than an intensive explanation of the current specification. For a more detailed overview, I'll encourage reading the draft specification in the FAQ document written by EIP-7251's authors. Increasing max underscore effective underscore balance and creating min underscore activation underscore balance. EIP-7251 updates from the current value of 32 ETH to 2048 ETH, but it doesn't change the minimum amount a validator needs to stake to join the beacon chain. This seems contradictory or impossible, given that a validator's eligibility for activation is currently determined by checking iceeligible underscore for underscore activation underscore q against during beacon chain processing. EIP-7251 resolves this contradiction by introducing a new constant set to 32eth to represent the minimum effective balance required

to activate a new validator and modifies to check against rather than. This ensures solo stakers can continue to stake 32 ETH even with the new value for and preserves the beacon chain's economic decentralization. An important caveat, EIP-7251 is integrated for the other standards. A validator updates the new hexadecimal 02 compounding withdrawal credential introduced by EIP-7685. It will have set to 32 ETH and receive partial rewards in the normal frequency. Introducing a new compounding withdrawal credential, hexadecimal 02, with the usage OFEIP-7685 structure. EIP-7251 introduces a new compounding withdrawal credential, hexadecimal 02, to complement the usage of EIP-7685's

request structure. The compounding withdrawal naming reflects that validators can compound rewards by switching to hexadecimal 02 credentials. Since rewards are computed to scale with effective balances, accruing a higher effective balance, up to the limit of, instead of withdrawing excess balances above the minimum activation balance of 32 ETH, increases the validator's rewards over time. The compounding withdrawal prefix is checked by the, now modified, function that determines if a validator is eligible for an automatic partial withdrawal. If a validator has hexadecimal 0 2 credentials, the function gets the balance of the validator and function checks the validator's balance against and returns any excess as partial

withdrawal amount. Note that max EB can be 2048 ETH or any value below 2048 ETH based on the validator's preference. More on this feature later. If a validator has hexadecimal 0 1 withdrawal credentials, compares the validator's effective balance with and returns any excess as the partial withdrawal amount. This preserves the functionality of automated partial withdrawals for solo stakers and minimizes disruption to the rewards skimming workflow for staking operators that continue to stake 32 ETH instead of staking higher amounts. Note. Details on how the migration from 0x01 withdrawal credentials to 0x02 compounding withdrawal credentials will work are still light.

Validators may be able to do a one-time change in protocol, similar to 0x0 right-pointing arrow 0x01 rotation, or need to withdraw and re-enter with new withdrawal credentials. I'll update this article once core developers settle on a decision. In protocol combination of validator indices, EIP-7251 introduces a new consolidation operation that combines two validators into a single validator without requiring both validators to exit the beacon chain. A consolidation operation moves the balance of a source validator to a target validator and is signed by the source validator's signing key. Here's a sketch of the consolidation operation from the EIP-7251 spec.

This change reduces overhead for solo stakers and staking pools that want to merge multiple validators without going through the cumbersome process of exiting validators from the active set and combining the withdrawn funds to activate a new validator. Consolidation operations are submitted by the source validator and processed like any other beacon chain operation. Deposit and voluntary exit, during each epoch. We'll explain consolidation operations in more detail subsequently. Recap. How does a voluntary validator exit work? Workflow for voluntarily exiting a beacon chain validator. Source. EIP-7251's in-protocol consolidation operation uses elements of the existing voluntary exit operation, so it helps to understand how voluntary exits work before explaining in-protocol consolidation. Here's a rough sketch of the voluntary exit procedure 1. A validator

signs a object and broadcasts it over the peer-to-peer network for inclusion in a beacon block. The function is called during beacon block processing and sets the exiting validators and in the. Having successfully signaled an intent to leave the active validator set, the exiting validator is placed in the exit queue. How long a validator waits in the exit queue before fully withdrawing from the beacon chain depends on the churn limit and the number of pending validator that exists. We'll go over the churn limit specification in a later part of the article and see how it affects validator exits, in the status quo and when EIP-7251 is activated. The validator is expected to continue performing consensus duties,

e.g. attesting to blocks and participating in committees, while waiting to leave the exit queue. This delay is defined by the epic during which an exiting validator becomes inactive and can stop performing beacon chain duties. Note that the validator is still earning rewards while waiting in the exit queue. 1. While validators stop a testing, proposing after exit underscore epic, they cannot withdraw stake dead until the is reached. The withdrawable epic is calculated by adding 2. The minimum validator withdrawable validator delay is set to a constant of 256 epics,

roughly 27 hours, so an exiting validator must wait a duration of before withdrawing completely from the beacon chain. At the beginning of the withdrawable underscore epic the validator's balance is transferred to the execution layer address specified in the withdrawal credentials. Note that the validator doesn't earn rewards after the exit epic, but it can still be slashed for offenses committed in the past until the withdrawal is processed at the withdrawable underscore EPIC. Imposing a minimum delay of 27 hours provides enough time to detect protocol violating behavior and prevents faulty validators from exiting stakes without incurring penalties for historical offenses. The graphic below shows the timeline for a voluntary exit operation. How does in-protocol validator consolidation work? EIP-7251 slightly modifies the mechanics of a voluntary exit operation for validators that

signal a desire to consolidate with another validator. The figure below describes the process of consolidating two validators in protocol. We'll establish some terms. The validator that wishes to allocate its effective balance to a target validator. The validator that accumulates the balance of a source validator. An object signed by the source and target validators to signal an intent to consolidate their balances without exiting the protocol. Here's a sketch of the consolidation process. 1. Like a regular message, the signed consolidation object must be broadcasted over the peer-to-peer network and included in a beacon block to start the process of moving the source validator's

balance to the target validator. The function is called during the processing of the beacon block that includes the signed object and triggers a voluntary exit for the source validator. When is called, the source validator's exit epoch and withdrawable epoch are set in the beacon state. Is also called during block processing to insert A for the source and target validator in the beacon state. 2. While the source validator is waiting in the exit queue, it must continue performing beacon chain duties until the withdrawable epoch. But, instead of sending the validator's balance to the withdrawal address, we allocate it to the target validator and increase the latter's effective balance. The transfer of funds happens during epic processing, right-pointing arrow. Here, is called to move the source validator's balance to the target validator's balance and finalize the consolidation process. Backslash dot 3. The consolidation

operation is authenticated by checking that both source and target validators have the same withdrawal address. Confirming that a source and a target validator have the same withdrawal address is a simple way to determine if both validators are controlled by the same entity. This way, we know that all parties approve of the consolidation operation and no one is forcefully moving a validator's balance without permission. This particular edge case, invalid consolidation operations, can appear if Wessoli rely on signatures from a validator's signing key to authenticate consolidation operation. For example, an attacker can compromise the signing key and sign a rogue object that moves the validator's

balance to the attacker's target validator. However, requiring validators in a pairwise consolidation to share the same withdrawal credentials creates issues for staking pools and staking companies that don't reuse withdrawal credentials or map validators to multiple withdrawal addresses instead of a single withdrawal address. For instance, AS taking pool controlling 232 ETH validators with different withdrawal addresses will need to exit both validators and re-enter the beacon chain with a new 64 ETH validator. An alternative is to verify signatures from the withdrawal key of the source and target validators on the message. Since the withdrawal key has ultimate ownership of state ETH, a signature from the withdrawal

key of either validator provides evidence we need to approve a consolidation, even if source and target validators have different withdrawal credentials. But this requires implementing a mechanism for verifying execution layer signatures on the beacon chain. The consensus layer uses a BLS 12 to 381 curve, while the execution layer uses the SEPC 256K1 curve, or introducing a mechanism for consolidation operations to be verified on the execution layer, similar TOEIP-7002 withdrawals processed on the L. Both approaches introduce extra complexity, which already touches many parts of protocol, as some have described it. It's possible this part of the consolidation operation specification will change,

especially as large staking pools like RocketPool, which uses greater than 1,000 deposit addresses to fund validators controlled by node operators, may find it difficult to consolidate under the current design. If that happens, I'll update this document to reflect changes to the spec. How does slashing work when validators are consolidating? In protocol consolidation doesn't change much about the slashing process. A SWIFT A, the source validator is slashable for its original balance, the initial, until it reaches the assigned withdrawable epoch. The target validator is also slashable for its initial, at least until we reach the of the source validator. At this point, the source validator's balance is transferred to

the target validator and the latter becomes responsible for the aggregate balance of both validators. If the target validator commits a slashable offense during the source validator's withdrawal epoch, after balances have been merged, it is slashed proportionally to its after consolidation. Below is a graphic describing how slashing is attributed during the consolidation period, permitting validators to set custom ceilings for max underscore effective underscore balance. The withdrawal of a validator's balance, once it exceeds, to the withdrawal address is a system-level operation that occurs automatically and doesn't require a validator to initiate a transaction. Notably, the partial withdrawal sweep offers

stakers a gasless mechanism for skimming, rewards from the consensus layer, and provides a reliable source of income stakers rely on to cover operational costs, among other things. Changing from 32 ETH to 2048 ETH potentially increases the delay for partial withdrawal sweep, especially for solo stakers and staking pools that may not immediately reach the 2048 ETH ceiling. You can imagine how long it'll take a solo staker to accrue enough rewards to reach a balance of 2048 ETH. To ensure an increase in doesn't impact stakers negatively, EIP-7251 proposes a new feature that will allow validators to set custom values for and control when the partial withdrawal activates. To clarify, the default maximum effective balance for validators that

migrate to 0x02 compounding withdrawal credentials is still 2048eth. However, an hexadecimal 02 validator can set a custom value below 2048eth for which the beacon chain's modified function can check to determine if a validator is due for a partial withdrawal sweep. A useful, albeit possibly inaccurate, mental model is to think of 0x02 validators as having two types of maximum effective balance. MaxEB, in a post-EIP 7251 world, a constant MaxEB and a variable Max max EB that determine when the partial withdrawal occurs. Partial withdrawals after the constant max EB of 2048 ETH is the default behavior for validators that increase by changing to hexadecimal 02 credentials and don't specify a custom ceiling

for maximum effective balance. Partial withdrawals after the variable max EB for an hexadecimal 02 validator occurs whenever the effective balance crosses the value of set by the validator. EIP-7251 permits validators to set any value for the variable max EB, provided the chosen value doesn't exceed 2048-eth. Permitting variable ceilings for the maximum effective balance ensures stakers can continue to rely on gasless automatic withdrawals, skimming, as a source of income. It also makes adopting EIP-7251 attractive for solo stakers and S-taking services that prefer skimming to the alternative for partially withdrawing validator balances under EIP-7251. Execution Layer Partial partial withdrawals, which we discuss next. Adding execution layer

partial withdrawals, EIP-7002 introduces the concept of execution layer withdrawals. A staker can withdraw their validator from the beacon chain by sending an withdrawal transaction signed with the validator's withdrawal credential to a validator withdrawal recuist contract on the execution layer. Withdrawal messages are added to a queue and the execution payload of a beacon block consumes several withdrawal requests from this queue up to the value of 16. You can read EIP SFOR nerds number 3 EIP 7002 execution layer triggerable withdrawals for a comprehensive overview of execution layer triggered withdrawals, especially to understand how they compare to voluntary withdrawals triggered on the consensus

layer. EIP-7002 is currently designed to work for full validator withdrawals similar to assigned by a validator's signing key. An execution layer withdrawal triggers the withdrawal of a validator's balance to the withdrawal address. However, the authors of EIP-7251 propose an extension to EIP-7002 that will allow a staker to trigger partial withdrawal of a validator's balance by sending a transaction on the execution layer. With this feature, an hexadecimal 02 validator can withdraw arbitrary amounts over 32 ETH without necessarily waiting for the partial withdrawal sweep to activate. This is another attempt to mitigate the effects of an increase in for stakers and reduce the barrier to adopting EIP-7251. To see why this is important,

consider the status quo. The automatic sweep at 32 ETH provides a steady stream of liquidity and enables staking pools to frequently do things like payout rewards to stakers. In comparison, with the maximum effective balance updated to a constant of 2048 ETH per EIP-7251, the automatic sweep will happen less frequently for validators that increase their maximum effective balance. EIP-7251's variable max-EB feature alleviates but doesn't completely fix the problem, either. Suppose an hexadecimal 0-2 validator sets 128-eth as the custom maximum effective balance and receives a partial withdrawal when crosses 128-eth. Now, imagine the same validator's effective balance drops from 128 ETH to 80 ETH for some

reason, e.g. getting slashed for downtime, that validator needs to accrue at least 48-49 ETH to become eligible for another partial withdrawal. This could be better from the perspective of a staker or staking pool that needs enough liquidity to run a profitable staking operation. Allowing stakers to partially withdraw balances via withdrawal credentials, using the mechanism for passing messages between the execution layer and consensus layer provided BYIP7002, fixes this problem. Validators can now withdraw arbitrary amounts from the without exiting contingent on specific requirements. The withdrawer, identified by the withdrawal credential,

pays the required gas fee for the withdrawal transaction on the execution layer. Current estimates peg the cost of a partial L withdrawal at 50,000 gas, inclusive of the fixed base underscore fee of 21,000 gas. The remaining balance is higher than 16 ETH. Any validator whose balance drops below 16 ETH is automatically placed in the exit queue and forcefully exited. We can illustrate the value of execution layer partial withdrawals by considering the previous example of a validator with a variable max EB of 128 ETH. Instead of waiting until 80 ETH increases to 128 ETH to withdraw, the validator can elect to withdraw from the existing balance of 80 ETH, insofar as it doesn't drop below the ejection balance, by triggering a withdrawal operation

from the execution layer. One question that may arise is. What happens if validators start moving large amounts of stake around, what would that mean for Ethereum's economic security? This is a legitimate concern, especially if we consider the possibility of bad actors exploiting the freedom to transfer sizable funds between the consensus and execution layers quickly. But there's an even less theoretical concern. Specific security properties of Ethereum's consensus protocol depend on the assumption that the amount of stake exiting the protocol cannot exceed a defined threshold in a particular time window. Without a mechanism to rate limit partial withdrawals of validator stakes, implementing EIP-7251 may break certain invariants critical to the security of Ethereum's consensus protocol.

Fortunately, the authors of EIP-7251 have considered this edge case and proposed modifications to the mechanism for it limiting withdrawals and deposits on the beacon chain. We will discuss this feature next. Using weight-based rate limiting for exit and deposit queues, proof-of-stake protocols with Byzantine fault tolerance, BFT, have accountable safety if adversarial actions, like finalizing two conflicting blocks, cannot occur without the protocol slashing one-third asterisk n of validator stakes where n is the total active stake since two-thirds asterisk n stake is required to finalize blocks two conflicting blocks appearing at the same height in an epic n means at least one-third of the active stake must have voted twice for different blocks b and b

signatures are cryptographically linked to each validator's public key, so an honest party can prove which validators double-signed during the epic. But, fourth proof-of-stake protocol to slash the offending validators, a supermajority, two-thirds asterisk N. Validators have to finalize a block B plus 1 in the next epic E plus 1 that contains evidence of double-s signing. This means an attacker must not control two-thirds asterisk N or more of the total active stake, or it can choose to finalize a different block that doesn't include evidence from the whistleblower. Thus security relies on the assumption that the total active stake cannot change be more than one-third asterisk N between epics N and N plus 1. Otherwise, an adversary can potentially increase its share of

the total stake N from one-third asterisk N to two-thirds asterisk N. This is why POS protocols like Gasper require a mechanism for rate-limiting inflow and outflow of stake during EPIC transitions. Importantly, rate-limiting parameters must be carefully chosen as they determine the level of economic security the consensus protocol provides. Note that the rate limiting mechanism doesn't care about the number of validators joining or exiting during EPICS and focuses on changes to the validator weight, i.e. the amount of stake during the boundary between EPICS and N plus 1. The importance of this detail will become evident as we discuss changes to the rate limiting mechanism proposed by EIP-7251. Validator churn limits under EIP-7251. Today, the beacon chain's churn limit, i.e., the maximum number of validator activations and exits per epoch,

as determined by the get underscore validator underscore churn underscore limit function is influenced by two parameters min underscore per underscore epic underscore churn underscore limit equals four and churn underscore limit underscore quotient equals 65,536. 2 asterisk asterisk 16. The first parameter indicates that each epic can have at least four validator entries and exits. The second parameter is more critical and limits the maximum validator churn per EPIC by setting it to 165,536, roughly 0.0015% of the active validator set, provided at least four validators are active. However, the current parameters for the functions will become insufficient for Gasper's accountable safety property once EIP-7251 implements variable maximum effective balances. Why? The existing rate limiting mechanism is designed to limit the number of validators exiting

and joining the active validator set and not the weight leaving and entering the active set. We can get away with this currently because setting to a constant of 32 ETH, which is also the minimum activation balance for validators, introduces a rough correlation between validator weights and validator numbers. For example, 165,536th of beacon chain validators, 897,892 validators at the time of writing, is 13 validators since a validator can have at most 32 ETH as max EB. This translates to about 438 ETH flowing in and out of the protocol per EPIC undercurrent churn limit rules. 13 validators asterisk 32 ETH. Calculating 438 ETH as a percentage of the total state, 28,732,281 ETH at the time of writing, gives US roughly 0.0015%

or 165,536, which correlates to the value of. But increasing the constant max EB to 2048 ETH and introducing variable max EBs, which can be higher than the minimum activation balance of 32 eb, breaks this invariant. Suppose we use the previous per-epic churn limit of 13 validator withdrawals, activations and assume all validators scheduled for exiting during an epic end have a max eb of 2048 eb. A total of 13 validators withdrawal per epic would equal 26,624 ETH of stake leaving the active set. 13 asterisk 2048 equals 26,624. Backslash dot. Calculating 26,624 ETH as a percentage of the total stake, 28,732,281 ETH at the time of writing, gives us 0.0092% or roughly 1 1000th of the stake, which is approximately 64x faster than the current churn limit of 1 65 536th.

To put this into into context, it would take just 356 EPICs, approximately 37 hours, to exit 1 3rd XN, 33% of the total total stake at 2048 ETH per validator, compared to the 21,647 EPEX, 96 days, it would take to withdraw 33% of the active stake under the withdrawing churn limit at 32 ETH per withdrawn validator. To preserve the churn limit invariant, EIP-7251 modifies to account for the balances, total weight, of all active validators instead of accounting solely for the number of active validators. Is now a GUI value instead of a UINT64 value and the function for setting the maximum validator churn for an EPIC-USS total underscore active underscore balances, aggregate stake of active

validators, as input instead of, total number of active validators, as input instead of, total number of active validators, as shown below. The churn limit is multiplied by the total active stake to determine the maximum weight that can enter and exit during an epoch. EIP-7251 also modifies the exit and activation queues to use weight-based rate limiting and changes how and, which indicate the epoch for exiting and activating a validator, respectively, are computed. First, it introduces a new value that tracks the balances of the validator at the head of the activation queue and modifies, now in Gui, to track balances of validators to be exited in the current epoch. It also creates two values and

to account for situations where the stake of a joining or exiting validator exceeds the per epic churn limit. We'll see how the new weight-based rate limiting for activation queues and exit queues works shortly. Validator activations under EIP-7251. Validators are activated during the process underscore registry underscore updates phase of the beacon chain's epic transition workflow. The value of is a function of the epic churn limit, activation validator balance, and effective balance of the previously activated validator. We can understand this concept by using details from the previous example. The current epic churn limit is 438 ETH and the effective balance of the validator at the front of the activation queue is 200th. This means is 200th and for the current epic is 238th. Backslash dot. The next validator in the

queue has an effective balance of 100th which is lower than the 238th. We schedule the second validator for activation during this epic and decrease by to leave the epochs at 138th is now 300th backslash dot. The third validator in the queue has an effective balance of 250th and cannot be activated in this epoch as 250th exceeds the current epochs threshold 138th. By extension, this implies that activating the third validator will violate the epic churn limit invariant is, which is above the per-epic churn limit of 438-eth. Backslash dot, we subtract the epics from and roll the remaining validator balance to the next epic. The for-epic n plus 1 is set to 112-eth to reflect the churn caused by the leftover validator balance from the previous epic n. Backslash dot, to get the for epic n plus 1, we subtract from, which gives us 326th. The value of validator number 3's

unprocessed effective balance, 112th, is lower than the epic churn limit, 438th, so we can schedule the validator for activation during epic n plus one validator exits under eip 7251 eip 7251 modifies the initiate underscore validator underscore exit function to account for the validator's weight before computing the ie the epic where the validator can exit and fully withdraw furthermore is modified to accumulate balances of validators leaving in the current epoch and tracks the balance of the validator at the head of the exit queue. Putting these details together provides a picture of how exits, full withdrawals, work in a post-EIP 7251 world. 1. When a validator initiates an exit, the function checks that is within the current

epoch's threshold. If the balance is within limits, is increased by, and the validator's exit queue epoch is set to the current epoch. 2. If a validator's effective balance is larger than, we decrease by to compute the next epochs. During the next epoch, we check if, i.e., the validator's unprocessed balance from the previous epoch, is lower than, if so, the validator's exit queue epoch is the previous epoch is lower than. If so, the validator's exit queue epoch is set that epoch. 3. If still exceeds the per epoch churn limit, we keep increasing and decrease the exit balance until is greater than. At this point, the validator's remaining balance can be processed for exiting in the current epoch without violating the limit imposed by the per

epoch churn limit. We can understand this concept by using a similar example from the section on activations. The epic churn limit is 438th, and the next validator in the exit queue has a max EB of 2048th, is higher than the epic churn limit, so the validator cannot exit in the current epic N. We subtract from at epic N to get the for the next epic n plus 1. At epic n plus 1, the 1172 eth still exceeds. We decrease by once again and repeat the process until we reach epic n plus 3 where, now at 296 eth, is lower than the per epic churn limit. This will be the validator's exit q epic. The for epic n plus 3 is set to to 296th to reflect the churn from processing the remainder of the validator's effective balance, i.e. what's left of, in that

epoch. Changes to the activation and exit queues proposed by EIP-7251 ensure that large validators can be processed for full exits or activation over multiple epochs. More importantly, computing exit and activation epochs mean valid importantly, computing exit and activation epochs mean validators can variable activation balances and effective balances without breaking the property that at most 1 65 536th of the total active state can exit, enter the beacon chain's active set. Partial deposits and withdrawals under EIP 7251. So far, we've discussed how EIP-7251 addresses the problem of variable activation and effective balances among validators exiting and joining the beacon chain and implements measures to preserve Gasper's economic security properties.

But how does it handle partial deposits and withdrawals, as validators potentially have more ETH to partially withdraw once is increased to 2048 ETH and the variable max EB feature is implemented, like validators exiting or joining with enormous stakes, large amounts of stake flowing in and out of the protocol via partial withdrawals and deposits. A. K. A. Validator top-ups can be problematic. For background, partial deposits skip the activation queue and are capped at per block, which is higher than the limit in validator activations. This isn't a problem under the status quo. If an attacker can introduce merethin 1 3rd asterisk n of stake into the protocol via

top-ups, then it must have lost an equal amount of stake previously. Recall that all validators must deposit a minimum of 32 ETH as collateral, and the maximum effective balance cannot exceed 32 ETH. To illustrate, imagine a miniature version of the beacon chain with NINA validators and 288 ETH in total stake. At 32 ETH per validator, two-thirds of validators are A-honest, and one-third of validators are controlled by an adversary, which means 192th of the total active stake is honest, and 96th of the total active stake is adversarial. Suppose the attacker wants to increase its balance by over one-third of the total active stake, 96th, during an epoch. In that case, the three validators it controls must currently have balances of 0th,

and a validator can drop to 0 ETH only if the protocol slashes it. That said, keeping the minimum activation balance at 32 ETH and increasing the maximum effective balance changes the dynamics. To use the previous example, an attacker can deposit 56 ETH per validator to increase the total stake of adversarial validators to 264 ETH and the total active stake to 392 ETH. If the remaining validators don't top up, the adversary now controls greater than two-thirds of the stake and can block a mass slashing event. EIP-7251 requires partial deposits to go through the activation queue and rate limits top-ups with the weight-based rate limiting mechanism introduced earlier to prevent this edge case. This prevents an attacker from using balanced top-ups to circumvent the activation

queue and keeps churn within limits defined by. However, this means validators that don't increase will now experience a variable delay on balanced top-ups, depending on activation queue congestion. An alternative proposal is to cap partial deposits at 32 ETH so that hexadecimal 0-2 validators can only increase effective balances up to via top-ups. This would preserve the original behavior of partial deposits and probably eliminate the need to rate limit top-ups. Plus, validators that don't adopt EIP-7251 can continue to use top-ups to quickly replenish balances and avoid losses from a drop in effective balances. Understanding validator effective balance explains the connection between

effective balance and changes in validator rewards in detail. However, limiting top-ups to 32 ETH has a greater impact on validators that do increase max EB if it reduces due to a slashing or penalty event. 2. Val validators can no longer top up to increase effective underscore balance and typical situations and must exit before activating with a higher effective balance partial execution layer withdrawals under eip 7251 will follow the same pattern of weight based rate limiting as total withdrawals triggered with a validator signing key for context full exits triggered from a validator's withdrawal credentials are rate limited by default. EL triggered withdrawal requests are added to the on-the-beacon chain

and processed the same way as messages. Partial EIP-7002 style exits will go through the as well, so rate limiting partial withdrawals under EIP-7251 is relatively straightforward. Modifying initial slashing penalty and correlation penalties. The initial slashing penalty, applied by the slash underscore validator, function, is the first reduction applied to the balance of a balance of a validator that commits a slashable offense and is linearly proportional to the validator's effective balance. For example, a validator with an effective balance of 32 ETH will have an initial penalty of 1 32nd or 1 ETH. The initial slashing penalty is one part of the beacon chain slashing mechanism but is arguably the most important in the context of EIP-7251. To illustrate, a validator with an

effective balance of 2048 ETH will lose 64 ETH as part of the initial slashing penalty, 1 32nd asterisk 2048 equals 64. This increases the risk for large validators with higher effective balances, which puts us in a difficult situation since EIP 7251 primarily aims to encourage staking pools torn larger validators. The current proposal to address this problem is to modify to apply a constant reduction, 1-eth, or scale sublinearly, instead of linearly, in proportion to the validator's effective balance. The first proposal ensures every validator loses exactly 1-eth the first time they're slashed. However, this is arguably less of a credible threat to disincentivize slashable behaviors compared to the original 1 32nd slashing function, EG.

A 2048 validator loses the same amount of ETH as a 32 ETH validator. In comparison, scaling initial slashing penalty to increase sublinearly preserves the guarantee that validators with larger balances are punished proportionally without necessarily increasing the risk for validators with larger balances. The slashing penalty analysis from Mike Neuter et al. shows how different values for a sublinearly scaling initial slashing penalty can beckon to balance economic security with the goal of encouraging validators to participate in protocolial behavior like validator consolidation. The slashing analysis document also addresses another issue. Under current slashing rules, validators with a larger effective balance are likely to suffer higher correlation penalties.

Upgrading Ethereum has more information on correlation penalties. In the meantime, you can think of a correlation penalty ASA deterrent to disincentivize validators from joining in a coordinated attack on the protocol. If a validator is slashed, and many validators are slashed for a similar offense around the same period, the correlation penalty is applied before the validator's withdrawal epoch. Correlation penalties are critical to the guarantee that the protocol can destroy one-third of the total active stake for offenses like finalizing two conflicting blocks. For example, the correlation penalty is designed so that a validator's entire balance can be slashed if one-third of validators are slashable for the same offense, as one of the inputs to the correlation penalty function, which makes sense in the status quo where every validator has the same maximum effective balance of 32 ETH. The assumption

that every validator has a max EB of 32 ETH breaks down ONCEIP7251 is implemented and validators increase effective balances. But the real concern is that effective underscore balance is one of the inputs to the correlation penalty function, which puts consolidated validators with larger effective balances at a disproportionate risk of suffering higher correlation penalties in a mass slashing scenario. To mitigate this problem, EIP-7251 proposes to modify the correlation penalty to scale quadratically instead of linearly in proportion to the validator's effective underscore balance. The correlation penalty section of slashing penalty analysis shows that quadratically scaling correlation penalties preserves concrete security guarantees, especially in slashable

scenarios, but reduces the risk for individual validators with higher effective balances. To sum up, EIP-7251 doesn't exactly change the slashing penalty to solely favor large validators. A validator with more collateral at stake will still have more EIP-7251 in a slashing penalty to solely favor large validators. A validator with more collateral at stake will still have more to lose in a slashing than a validator with a small stake. This is the expected behavior of any proof-of-stake protocol with meaningful economic security or any arrangement where how much you get is how much you put in, higher risk equals higher rewards. However, adjusting the system of applying penalties achieves the following goals. Aligns crypto-economics of slashing with the new reality of higher effective balances.

Brings down slashing risk to levels that large validators can tolerate and increases the likelihood of more validators opting to consolidate stake. Why EIP-7251, the case for increasing max underscore effective underscore balance. Most of the benefits of implementing EIP-7251 are evident from discussions in previous sections. But a summary of the net benefits of increasing four validators to the network and stakers may be helpful, especially if you skip to the part where you learn what's in it for me for me as a solo staker, staking service operator. Reduced load on the consensus layer. Aditya Asghankar's removing unnecessary stress from Ethereum's P2P network post provides a good overview, from the perspective of a protocol developer, of the burden having a large number of validators places on the beacon chain's P2P

networking layer. For instance, a large validator set increases the number of messages broadcasted and gossiped over the network and the number of ID stations to aggregate and verify in each EPIC. These factors combined could increase compute and bandwidth requirements for validator nodes, degrade network performance, and ultimately hurt decentralization. Similarly, Daplin's beacon node load as a function of validator set size post provides a client developer's perspective on the problem with a large validator set, which is helpful for discussing the intersection of network performance and decentralization. As noted in the document, consensus clients must keep certain parts of the beacon state, e.g. deposit messages and

validator pubkeys, in working memory for consensus clients to process blocks. Increases in the validator set correlate to increases in the size of the beacon state, e.g. More validators equals higher footprint in. Working memory isn't designed to store large amounts of data, unlike disk storage, so investing in performance solid state drives, SSDs, becomes more necessary for beacon nodes to stay in sync with peers. But SSDs aren't cheap, compared to regular hard-disk drives or HDDs, which bumps up the overhead of running a validator and reduces the incentive for participating in Ethereum's consensus, especially for at-home stakers. While we've

seen different proposals to reduce the validator set size, e.g. validator set capping and validator set rotation, EIP-7251 is current lithe-only proposal that reduces validators without requiring massive changes to Ethereum's technical infrastructure or staking economics. We can see how much gains implementing EIP-7251 can provide by using figures from five of the largest staking pools. Lido. 290,000 validators, 31.68%. Coinbase. 137,000 validators, 14.94%. Figment. 38,000 validators, 4.1%. Binance, 33,000 validators, 3.6%. Rocketpool, 27,000 validators, 2.9%. If each staking service in this list consolidated multiple validators into single validators with the maximum effective balance

of 2048 ETH, the result would be. Lido. 141 validators. Coinbase. 66 validators. Figment. 18 validators. Binance. 16 validators. Rocket pool. 13 validators. Given that these staking pools combined control 525,000 validators, a mass consolidation will have a visible contracting effect on the total validator set as the previous calculations show. This is napkin math, as it assumes each validator has exactly 32 ETH, but it is still enough to show the real-world impact of validator consolidation on reducing the beacon chain's validator set. Moreover, it's unlikely staking operators will immediately start running validators with effective balances in the region of 2048 ETH

due to the increased slashing risk. A more realistic assumption is that staking pools will begin with smaller consolidations, e.g. combining 32 ETH validators to create a 64 ETH or 128 ETH validators. This is why Distributed Validator Technology, DVT, needs to become battle-tested enough to be deployed in production staking environments. With DVT, large validators can be run on multiple machines to increase fault tolerance, enable faster recovery from downtime, and contain the effects of client bugs and machine failures to individual nodes. Unlocking future upgrades, as explained in the introductory section, critical upgrades on Ethereum's roadmap, most notably, single-slot finality, SSF,

and enshrined proposer-builder separation, EPBS, can only be implemented if the validator set reduces or at least remains within reasonable bounds, EG. See Vitalik's recent argument for sticking to 8192 signatures in a post-SSF world. EIP-7251 proposes a minimally disruptive solution for validator-set contraction on Ethereum and effectively removes obstacles to activating single-slot finality, proposer-builder separation, and other upgrades that share low validator set as a dependency. A slightly related benefit from EIP-7251 is reducing pressure to accelerate R&D efforts related to dealing with the challenges of an enormous validator set, most of which come with various second-order consequences, as past discussion shaves shown. This minimizes demand for more drastic changes like EIP-7514, which proposes to reduce the validator churn rate

in the future and ensures core developers can spend time working on other aspects of the protocol. Making solo staking competitive. At first glance, EIP-7251 looks like an attempt to make life easier for large staking operators, but there's more to the proposal to increase the maximum effective balance. For example, solo stakers also benefit from EIP-7251 due to the availability of compounding rewards and the opportunity to stake ETH in flexible sizes. Both features are crucial to make solo staking attractive and bolster economic decentralization on the beacon chain. To put things into context, a solo staker with a single 32-eth validator will have to accrue rewards for years before it earns the 32-eth required to activate another validator. Conversely, a staking pool with multiple 32-eth validators

can activate a new validator in a shorter time by consolidating rewards from existing validators. This places the staking pool in an advantageous position as it can earn more rewards from existing validators. This places the staking pool in an advantageous position as it can earn more rewards from the newly activated validator. With EIP-7251, a solo validator that migrates to hexadecimal 0-2 credentials can restake rewards, not to be confused with Eigenlayer's restaking model, and earn higher rewards from having a higher effective balance. This mimics the compounding process adopted by staking pools, which I described earlier, and shows that adopting EIP-7251 is ideal for solo stakers as much as for large staking services. Reducing operational overhead for large staking pools.

A staking service operator today is running anywhere from 1,000 to 10,000 validators, or more more on a single machine, which can problematic from a logistics perspective. Since maximizing ROI on stake death is the primary reason for running many validators, EIP-7251 ensures staking pools can continue to run profitably with fewer validators by consolidating validator balances in protocol. The ability to set variable ceilings for a validator's maximum effective balance seal so reduces the necessity of activating new validators, as rewards can AC crew and compound for more extended periods before the threshold

and the automatic partial withdrawal sweep starts. A potential benefit is that node operators can manage fewer validator keys and scale down the complexity of signing key management. Are there any drawbacks to implementing EIP-7251? Increased slashing penalty risk for large validators The slashing risk borne by validators with higher effective balances is arguably the biggest argument against implementing EIP-7251. Some might even argue that the risk of running a validator with a larger slashable balance outweighs the net benefit from consolidating validators, especially if the linear scaling properties of the initial penalty and correlation penalty remain unchanged.

Nonetheless, I'll play devil's advocate and propose some counter-arguments. EIP-7251 proposes modifications to slashing mechanics, e.g. changing the scaling properties of initial correlation penalties, as described in the slashing penalty analysis document. If the various proposals are implemented, the risk profile for large validators is reduced significantly. In a world where the minimum required stake was higher than 32 ETH, say 1500 ETH per the original proposal, staking pools would still operate, albeit with different heuristics for reasoning about the economic risk of validator slashing. Hedging risk at 320 ETH per validator is more

complex than hedging risk at 32 ETH per validator, but it is within the realm of possibility. The maximum effective balance cannot exceed 32 ETH. Specification has been around since the beacon chain's inception and has informed years of R&D instaking protocols. So changing it will have far-reaching consequences for protocols that decide to adopt EIP-7251. I emphasize, decide, to reflect the opt-in nature of EIP-7251. But it's quite possible protocol designers can come UP with new economic and technical designs for staking pools to account for higher validator balances under EIP-7251. To illustrate, the risk assessment for Lido's community staking module,

the CSM will allow for permissionless entry to Lido's node operator set, currently recommends an operator bond of 4 ETH for security, with a caveat. The recommended bond size can change depending on implementation of proposals L-I-K-E-E-I-P-7-2-5-1. Since validator balances can increase beyond 32 ETH, increasing bond requirements for validator node operators in a trustless staking pool only makes sense. It's also important to note that the decision to have 32 ETH stake sizes was made for altogether different reasons than explicitly to reduce risk for staking pools. Perhaps the 32 ETH stake size, and the lower potential net loss from slashing, is part of the appeal of running an Ethereum staking service, I'm no damn expert. Even so,

staking pool risk is mostly an orthogonal consideration to the goal of making the network secure, healthy, and robust. Regulatory concerns over auto-compounding staking rewards Another argument against implementing EIP-7251 is that introducing auto-compounding validator rewards to the core protocol may attract scrutiny from regulators, especially if it suggests ETH is an interest-bearing security. Here's an excerpt from the relevant comment on ETHRESARCH, a response to increase max underscore effective underscore balance. A modest proposal, greater than, if a validator receives payment for validating, this is and appears to be greater than payment for services. Normal people understand that, regulators understand greater than payment for services. Normal people

understand that. Regulators understand greater than that. If a validator receives a second payment for validating a second greater than thing, same thing, that appears to be payment for services. Greater than greater than greater than let's rewrite that with compounding. Greater than greater than greater than the first time a validator receives payment for validating. Greater than payment for services. Then, the second time, the validator receives payment greater than for validating, and also extra payment for the money that they put into the greater than system, i.e. the payout from the first service. What's that? It's interest. Greater than normal people would call that interest. And regulators would call it that greater than too. William Entrykin, you, full decent. To summarize the ideas in the comment. A validator is currently perceived as a service provider. In return for running node software and

securing the network, the validator receives ETH rewards paid out by the protocol as compensation. This is, payment for service, in the simplest sense. Changing validator rewards model so that a validator receives more rewards for validating with a higher balance may be construed as waiting payment based on a validator's willingness to keep money in the system. E.G. Similar to how banks pay you interest to keep more money in a savings account. I'm not an economic expert, so I'll leave it up to the fiscal policy experts to work out the kinks of this aspect, implications for regulation, of EIP-7251. Ideally, we'd reason about this edge case in advance and avoid giving regulators an excuse to classify Ether as a

security and regulate the hell out of Ethereum's base layer. Despite my lacking a formal degree in economic policy, I'll go ahead and give my 2G WEI on the argument. Auto-compounding validator rewards are a side effect of increasing the maximum effective balance and not the primary rationale. For example, a validator that updates to the new maximum effective balance of 2048 ETH would essentially function as a 32 ETH validator today. Both receive rewards and penalties from the protocol proportional to their balances. For context, the lowest a validator's balance can go before it is ejected from the protocol is 16th. If your validator is at 17th,

you can progressively increase your rewards, provided you don't get slashed, until you reach the 32th limit and withdraw partial rewards. This is a form of compounding since the protocol increases the reward for your attestations each time your validator balance increases by design. Compounding from 17 ETH to 32 ETH may look different from compounding 32 ETH to 2048 ETH in the eyes of a regulator. But if the sole reason for treating ETH as a security is because EIP-7251 merely scales an existing property of the protocol, then we need to have a new conversation with regulators. Also, if a regulator really thought auto-compounding, which registered staking services like Coinbase already do out of protocol by spinning up additional validators from

consolidated rewards, was investment, it could simply require that stakers pay variable taxes on earnings depending on how much and when they compounded rewards for a validator. This solution may be harder to implement, but is arguably better than the man-with-a-hammer approach of rewriting ETH's classification as a commodity. Increasing development overhead for staking PROTOCOLSAs I mentioned, the 32 ETH stake size has been a feature of staking for an extended period, so many protocol decisions have been predicated on this feature. Changing the maximum allowable stake size would require staking protocols to rethink different economic and technical components and potentially increase

R&D overhead in the short term. Moreover, staking protocols that WSDO ossify and make critical components non-upgradable will have to push back timelines to account for changes introduced by EIP-7251. For example, RocketPool recently switched to 8-ETH bonds for node operators in the Atlas upgrade, after starting with 16-32-ETH bonds if eip 7251 i implemented it's safe to assume rocket pool developers and the community will need to reopen the conversation around ideal bond sizes for security once the maximum effective balance is increased note this is the case for any staking service that requires node operators to have financial skin in in the game vs. operating with a trust me bro security model not just rocket pool impact of increasing max underscore effective underscore

balance on proposer selection a potential question that may also arise around the change in max eb is the impact of stake consolidation on proposer selection intuitively it feels L-I-K-E-E-I-P-7-2-5-1 will benefit institutional stakers and staking pools by biasing proposal selection in favor of validators with higher effective balances and make it harder for solo stakers to compete. But, like any intuition, the idea that having a higher ceiling on a validator's maximum effective balance will disproportionately favor large stakers isn't 100% correct. E--7521 doesn't introduce any assumptions or rules on how proposer SARA is selected because proposer selection is already influenced by the ratio of a validator's effective balance to. We can break down the process of being selected as a proposer into two phases.

Getting selected from a randomly shuffled list of validator indices. Passing the proposer eligibility check, the beacon chain uses the swap or not shuffle algorithm to randomize the selection of candidate proposers. Recall that one of the requirements for a beacon chain is making sure an adversary cannot predict if a validator it controls will be selected as the proposer for a slot. The shuffling algorithm is a key part of randomizing the process of selecting a new proposer. The swap or not shuffle is described extensively elsewhere, but we're mostly concerned with the second part of the process, the proposer eligibility check, and we'll focus on that. Proposers are chosen based on the specification described below. The most important thing happening in the specification above is that we go through the list of shuffled indices and run the proposer eligibility check

to choose the proposer for the next slot. If a validator doesn't satisfy the conditions, we move to the next index in the list and run the eligibility check again until we find a validator that meets the requirement. To check if a validator is eligible for proposer duties, we multiply the validator's effective balance by a chosen random value R and compare the result to the value of multiplying by. If the two products match I, E, and are equal, the validator is selected as a proposer. We can analyze the probabilities of a validator getting selected as proposer in the status quo with some examples and see if implementing EIP 7251 changes anything. The subsequent analysis takes the formula for calculating probabilities of proposing from proposer selection with increased max EB, EIP 7251, which presents a

more formal overview of the interplay between increased values of and proposer selection. 1. Suppose we have two validators, one with an effective balance of 28th and the other with an effective balance of 32th, and the, hypothetical, generated random byte R is 255. Multiplying 32, the maximum effective balance, by 255, the random value for R, gives us 8,160. A validator is selected to propose if. 2. If validator A appears in the list of shuffled indices, we calculate its chances of being selected as proposer as 255**2830**255 equals 7,148,160 equals 0 875 we can also calculate validator b's chances of being selected as proposer as 255 asterisk 32 30 seconds asterisk 255 equals 8168 160th equals 1 we observe that validator a with an effective balance of 28thTH has an 0.875, 87, 5% probability of being selected as a propose, while validator B has a 1.0, 100% probability of being selected

as a proposer. Given that a validator's probability of proposing is already weighted based on the ratio off to, an increase or variance in validator effective balances doesn't change anything about proposer selection. But doesn't restricting all validators to the same effective balance mean both big and small validators have equal chances of being selected to propose blocks? If each validator was controlled by a different entity, then, yes, restricting to 32th levels the playing field. More specifically, when all validators have the same effective balance of 32-eth, every active validator has equal chance of passing the proposer eligibility check with probability 1 and has a 100% chance of proposing

the next block if it appears first in the list of candidate indices. However, we have noted that many validators are in fact controlled by the same entity, which naturally skews selection of proposers in favor of large stakers that distribute 32 ETH chunks across multiple validators. To illustrate, if we have a deck made up of 7 red cards and 3 blue cards, the probability of drawing a red card at random is 7 tenths or 0. 70, 70% probability, while the probability of drawing a blue card is 3 tenths or 0.70, 70% probability, while the probability of drawing a blue card is 3 tenths or 0.30. We won't delve into the math, but you can expect that we'll be drawing more red cards than blue cards one iteration, the probabilities only even out when we have exactly 3 red cards and 3

blue cards remaining in the deck. We can apply the same logic to proposer selection. Suppose our validator set has 5 32-eth validators, 4 validators are controlled by a large staker and the last validator is operated by a solo staker. The large staker has a 4 5ths, 0, 9 or 90% probability of appearing in the shuffled list of validator indices and 1.0, 100% probability of being selected as proposer. Meanwhile, the solo staker has a one-fifth probability of appearing in the shuffled list of validator indices and a 1.0, 100% probability of being selected as a proposer if it is chosen first from the shuffled list. This calculation shows that a solo staker's chances of getting selected topropose blocks don't meaningfully decrease after max EB is raised from 32th to 2048th.

We can use numbers from the previous example to illustrate. 1. The large staker decides to consolidate all four 32th validators into a single 128th validator, leaving us with two validators, a 128 ETH validator and a 32 ETH validator. Is now 2048 ETH and is still R equals 255 from the last example. For a validator to be selected as proposer, the product of the validator's effective balance and the random value R must match. For validator A, the chances of being selected as proposer can be calculated as 128 asterisk 255 2048 asterisk 255 equals 32,645 hundred 22,240 equals 0.06, 6% probability. For validator B, the chances of being selected as proposer can be calculated as 32**2552048**255 equals 816522240 equals 0. 15, 0. 15 or 1. 5% probability.

1. We immediately notice that the respective probabilities for both validators of selection as proposers is lower than before. This is an effect of increasing from 32 ETH to 2048 ETH. Although EIP-7251 doesn't change anything about the proposer selection process, it does increase the time required to compute a new proposer underscore index. Selecting a validator to propose a blocks with a of 2048th, we need to perform more iterations to find a validator that meets the criteria required for selection. For example, the previous example shows that a validator of 128th has 6% chance of being selected to propose and a 32th validator has a 1.56% chance of being selected to propose. 2. In this case,

we would need to progressively adjust the random byte r until the product of 1 validator's effective balance and matches the product of n. This is described as a try-and-increment procedure. The exact process is described elsewhere, but the main thing to know is that a. A counter value i is used to pseudorandomly generate the random byte b i is incremented if we reach the end of the shuffled list and no validator is selected for proposer duties which also increases the value of the generated random byte r in our example r will need to increase to 4080 so that one validator the 128th validator has an 100 chance of being selected for proposer duties recalculating validator a's chances of getting selected to propose with a value of 4080 for r

gives us 128 asterisk 4080 2048 asterisk 4088 equals 522 245 22,222,240, equals 1, 0, 100% probability. Recalculating validator B's chances of getting selected to propose with a value of 4,080 for R gives us 128,480,2048, 4088 equals 130,560 522,240 equals 0.25 25 percent percent probability the disparity between the probability of a 32th validator and 128 eth validator respectively being selected as proposers may seem alarming at first sight 100 percent greater than greater than greater than greater than greater than 25%. However, if we think of each 32th validator as having a 25% probability of being selected to propose in this scenario, it makes sense that a large staker controlling 4 32th validators has a 100% probability of proposing a block, 25 times 4 equals 100. In other words, staked consolidation doesn't have an extreme impact on proposer selection. The only thing that's changed is that relationship between

the cumulative effective balance of validators controlled by a staker and the chances of said staker proposing blocks is now explicit. Instead of thinking, or, more accurately, pretending, a small staker with 32 ETH staked and a large staker with 128 ETH spread across 4 validators have equal probabilities of proposing in a slot, we assign a higher probability to the large staker getting picked to propose the next block. Note that the large staker still has a 100% probability of proposing if they leave all 4 32 ETH validators unconsolidated.

The small staker only has a 100% chance of proposing if selected leave all 432 ETH validators unconsolidated. The small staker only has a 100% chance of proposing if selected first from the list shuffled indices, which we know can happen one-fifth or 20% of the time. This another good reason to consolidate validators rather than distribute stake acros smaller validators. It benefits the network since proposer selection happens faster. Higher effective balances for validators means fewer iterations to compute the proposer underscore index for the next slot. It benefits large stakers because the probabilities of being selected as proposer are concentrated into a single consolidated validator. The consolidated validator also earns more staking rewards since the reward for performing consensus duties, e.g. proposing

scales with the effective balance, EIP-7251 and the future of proof of stake in Ethereum. Designing a functional and secure proof of stake consensus protocol like Ethereum's beacon chain is difficult. It means making decisions with limited information and leaving a line of retreat to account for the possibility that estimates and risk estimates may be insufficient for preparing for reality surprises. This is why I started with amusing on rational optimism. Ethereum's journey ice probably the best example of how rational optimists can build things and work together to solve problems that appear. EIP-7251 is a simple and effective solution to a problem even Nostradamus,

if he was a core developer, couldn't have predicted. The technical challenges of an extremely large set of validators. If the debate around the proposal is anything to go by, the community has to work out many issues before EIP-7251 can become widely adopted and the EASE value is realized. In the meantime, you can follow the conversation AROUND EIP-7251 on ETHRESAR.CH and the Fellowship of Ethereum Magicians, Mike Nudersape 7251. Related work served as excellent research material for writing this article and is recommended for anyone who wants to learn more about different aspects of EIP-7251. As usual, I'll ask you to consider sharing this article with someone who may find it helpful and informative. If you enjoyed reading, you can also subscribe at

O2077 Research for more research on proposals coming out of Ethereum's EIP ecosystem. You can connect with me on Twitter at at 2077research. Tip authors note. A version of this article was originally published here. Thank you for listening to this HackerNoon story, read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.