Ethereum Validator Custody Debate: Static or Dynamic?

Validator custody plays a critical role in Ethereum’s Proof-of-Stake (PoS) ecosystem, ensuring the integrity and accountability of network participants. It refers to the responsibility of maintaining state data and historical records necessary for Ethereum's consensus layer.

Validators are responsible for proposing & attesting blocks, meaning they must store relevant data to confirm network security. The way this custody is implemented has major implications for efficiency, decentralization, and performance.

This blog explores the different models of validator custody, the ongoing debates between static & dynamic approaches, the challenges in implementation, and the latest developments from Ethereum’s core developers.

Approaches to Validator Custody

Ethereum’s validator custody is categorized into two models: static custody and dynamic custody.

A. Static Custody

In a static custody system, a validator's data retention responsibilities are predetermined at the time of setup and remain unchanged. This model simplifies implementation but presents challenges when validators enter or exit the network dynamically.

Pros of Static Custody

1. Easier to implement & manage
2. Predictable custody rules that do not change frequently
3. Less risk of network desynchronization

Cons of Static Custody

1. May become outdated as validators adjust their stake
2. Less flexibility for validators who need to scale operations dynamically
3. Could lead to inefficient storage requirements

B. Dynamic Custody

A dynamic custody model allows custody responsibilities to update in real time based on changes in validator status, including stake adjustments, network participation, and validator activations.

Pros of Dynamic Custody

• More flexible & adaptable to validator stake changes
• Ensures validators meet their obligations without manual intervention
• Provides better scalability for growing validator sets

Cons of Dynamic Custody

• More complex to implement & synchronize across clients
• Increased computational load due to frequent updates
• Risk of security loopholes if not properly managed

Challenges in Validator Custody

While dynamic custody presents clear advantages, there are several challenges to address before it can be fully implemented:

1. Lack of Standard Specifications: Ethereum clients (Prysm, Lighthouse, Teku, Nimbus, Lodestar) are currently implementing their own methods, causing inconsistencies.
2. Registration-Based Custody Complexity: If custody updates are linked to validator registrations, this may require significant protocol changes & additional computations.

Custody updates should be frequent enough to remain relevant but not so frequent that they create unnecessary reconfigurations. If validators manipulate custody obligations, they might bypass certain responsibilities, leading to potential security risks.

Static vs. Dynamic Custody

There is an ongoing debate within the Ethereum developer community about whether validator custody should remain static or shift to a dynamic model.

Arguments for Static Custody

Proposed by developer g11tech, the static custody approach aims to simplify validator operations by eliminating the need for dynamic adjustments. Under this model, validators would declare their custody parameters at the beginning using the --supported_validator_stake parameter, ensuring that their custody obligations remain fixed throughout their operation.

Beacon nodes would then register the required stake and enforce custody limits, preventing validators from exceeding their allocated responsibilities. By maintaining a predefined custody structure, this approach significantly reduces UX complexity and minimizes the likelihood of errors in validator implementations, making it a more predictable and manageable solution.

Arguments for Dynamic Custody

Ethereum consensus developers advocate for a dynamic custody system where beacon nodes automatically detect and adjust custody requirements in real time. In this approach, any changes in a validator’s stake would immediately trigger custody updates without requiring manual intervention.

This ensures that custody obligations remain aligned with the validator’s actual stake, improving network efficiency and fairness. However, while dynamic custody enhances adaptability, it also necessitates careful synchronization across all validators to prevent performance issues, such as excessive computational load or network desynchronization.

To accommodate validator changes efficiently, Ethereum core developers have proposed multiple methods for adjusting custody responsibilities.

1. Balance-Based Adjustments: Validator custody should be tied to the amount of ETH staked rather than a fixed value. This ensures that as validators increase or decrease their stake, their custody obligations adjust accordingly.
2. Epoch-Based Updates: Instead of making custody adjustments instantly, the network could periodically re-evaluate requirements at the start of each new epoch.
3. Registration Hooks: This method triggers automatic custody updates whenever a validator adjusts their balance or enters/exits the network.
4. Threshold-Based Adjustments: Custody updates only occur when a validator’s balance crosses a predefined percentage threshold, preventing unnecessary recalculations.

Ethereum developers are actively working on refining validator custody models, with the latest discussions happening in PeerDAS Devnet 5 & 6. Developers are fast-tracking dynamic custody testing from PeerDAS Devnet 6 to Devnet 5 to gather early feedback.

While static custody offers simplicity, it fails to adapt to validator changes. Dynamic custody, on the other hand, provides real-time adaptability but introduces complexity.

The Ethereum community is leaning towards a dynamic model, but with careful testing & optimization before full implementation. As PeerDAS testing progresses, developers will continue refining validator custody mechanisms to ensure a secure, efficient, & scalable Ethereum network.

Resources

1. make validator custody static for beacon node run session
2. Clarify validator custody with PeerDAS
3. consensus-specs/specs/fulu/das-core.md

Related Articles

1. Ethereum’s Institutional & Government Adoption
2. Solving the Puzzle of Duplicate Blocks in Ethereum
3. Ethereum Developers are Rethinking Transaction Signatures & Authority
4. The Debate Over Freezing Ethereum's Core for Good
5. Fixing Ethereum’s Message Signing Chaos

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.