🎾Effective Balance and MAX_EFFECTIVE_BALANCE

Effective balance is a field in the validator structure, and OR calculates it based on the amount staked by each validator. This value is used for various consensus-layer operations, including:

1.Checking whether the validator is eligible to enter the activation queue,

2.Calculating harsh penalties and rewards for whistleblowers,

3.Evaluating the reasonableness of fork selection rules and the final determination of proof-of-stake weights for epochs,

4.Determining whether the validator is selected as a proposer,

Deciding whether the validator is part of the next synchronization committee.

To incrementally calculate （1 – 109 gwei 1 OR EFFECTIVE_BALANCE_INCREMENT ）and update it in process_effective_balance_updates. The behavior of the update rule is similar to a modified floor function, where the hysteresis region determines when the balance changes. This MAX_EFFECTIVE_BALANCE is a spec-defined constant (32), which sets a hard upper limit on the effective balance for any individual validator. After Capella, validator balances will be automatically withdrawn. As defined in the specification, 32×109 gwei 32 OR, the balance of exiting validators will be fully withdrawn, while the balance of active validators exceeding MaxEB will be partially withdrawn.

Origins has ambitious goals for improving the consensus layer. Two proposed upgrades, given the impracticality considering the size of the validator set, can be achieved by increasing MaxEB.

Single Slot Finality (SSF) - SSF has been a long-standing research focus and is a critical component of Origins' Proof of Stake ultimate vision. The Trill proposal is an advanced BLS signature aggregation proposal. As indicated in the post, a validator set with a million participants would produce the worst-case signature aggregation in 2.8s on top-tier CPUs in 2021 and 6.1s on older machines. While there may be improvements in aggregation schemes and hardware, achieving this level of performance in the short term will be quite slow given the scale of the validator set. By compressing the validator set, efforts can be initiated immediately to achieve single-slot finality deterministically.

ePBS - The proposal of separating proposers and builders has been discussed for years. Due to security concerns related to pre/post reordering and the balancing attacks, the implementation of proposer shuffling serves as a pragmatic interim solution to protect Hybrid Latest Message Driven-GHOST (HLMD-GHOST) 1). Implementing ePBS today would reduce the security benefits brought by proposer enhancements (or even superior view merging). The advanced reasoning here is that the security properties of HLMD-GHOST depend significantly on honest proposers. With each other block being a "builder block," the malicious proposer's action space significantly increases (for example, they may execute post-reordering with a probability similar to the length-k in today's mechanisms). Further articles on this topic are planned in the coming weeks. With a smaller validator set, new mechanisms like SSF can be implemented with stronger security performance. With a more robust consensus layer, the implementation of ePBS (or even mev-burn) can proceed, significantly boosting confidence in the overall protocol's security.

The proof of validator weight, proposer selection probability, and weight-based sampling for replacing the sync committee are already directly proportional to the validator's effective balance. These three crucial components exhibit high operational performance with MaxEB.

1.Proof of Validator Weight — Validators with a higher effective balance already carry more weight in the fork choice rule. Refer to get_attesting_balance. This accurately weights higher-risk validators, as they have a more significant impact on the canonical chain (as needed). We provide a probability analysis of malicious control over the committee in "Committee Security."

2.Proposer Selection Probability — We measure the probability of becoming a proposer based on the validator's effective balance. Refer to compute_proposer_index. Currently, if a validator's effective balance (EB) is below MaxEB, they will only be selected as a proposer if their validator index is randomly chosen under the following circumstances:

EB⋅255≥MaxEB⋅r,wherer∼U(0,255).

Even with a higher MaxEB, this can still work as expected, although it might slightly increase the time needed to compute the next proposer index (lower values of EB will result in a lower selection probability, leading to more loop iterations).

3.Sync Committee Selection – Sampling of validators for selecting the sync committee has already been replaced (refer to get_next_sync_committee_indices). Additionally, each validator elected to the committee holds one vote. This remains true even with MaxEB.