Pectra Roadmap

[santi1234567]

Description

The Pectra hard fork is expected to come hopefully in 1Q 2025. Reference: EIP-7600. Goteth will require some updates to support the new hardfork (required changes) and also will have some extra updates for indexing additional data related to the new fork (can be handled after the fork).

Tasks

EIP-7600 (general hardfork update)

Required changes in goteth

• Add new Electra state/metrics structure.
• Update go-eth2-client. Update dependencies #157

EIP-6110 (Supply validator deposits on chain)

Abstract

Appends validator deposits to the Execution Layer block structure. This shifts responsibility of deposit inclusion and validation to the Execution Layer and removes the need for deposit (or eth1data) voting from the Consensus Layer.

Validator deposits list supplied in a block is obtained by parsing deposit contract log events emitted by each deposit transaction included in a given block.

Extra changes in goteth

• Create table t_deposit_requests for new execution payload object DepositRequest in ExecutionRequests.
• Add f_deposit_requests_num/amount to t_epoch_metrics_summary and t_block_metrics.

EIP-7002 (Execution layer triggerable withdrawals)

Abstract

Adds a new mechanism to allow validators to trigger withdrawals and exits from their execution layer (0x01) withdrawal credentials.

These new execution layer exit messages are appended to the execution layer block and then processed by the consensus layer.

Extra changes in goteth

• Create table t_withdrawal_requests for new execution payload object WithdrawalRequest in ExecutionRequests.
• Add f_withdrawal_requests_num/amount to t_epoch_metrics_summary and t_block_metrics.

EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)

Abstract

Increases the constant MAX_EFFECTIVE_BALANCE, while keeping the minimum staking balance 32 ETH. This permits large node operators to consolidate into fewer validators while also allowing solo-stakers to earn compounding rewards and stake in more flexible increments.

Required changes in goteth

• Change MAX_EFFECTIVE_BALANCE to 2048 ETH in electra metrics.

Extra changes in goteth

• Create table t_consolidation_requests for new execution payload object ConsolidationRequest in ExecutionRequests.
• Add f_consolidation_requests_num/amount, to t_epoch_metrics_summary and t_block_metrics.
• Create table t_consolidations containing the consolidations realized on process_pending_consolidations. The processing logic will need to be implemented at the time of state transition.
• Add f_consolidations_num/amount, f_num_compounding_vals to t_epoch_metrics_summary.
• Add f_withdrawal_credentials and f_is_compounding_validator to t_validator_rewards_summary
• Add consolidations_num/amount, num_compounding_validators to t_pool_summary.

EIP-7549 (Move committee index outside Attestation)

Abstract

Move the committee index field outside of the signed Attestation message to allow aggregation of equal consensus votes.

Required changes in goteth

• Create new ProcessAttestations for the electra state structure following the changes in process_attestation.

[tdahar]

Some comments from my side

MIN_ACTIVATION_BALANCE

You mention that the minimum effective balance is 32 ETH, but please review if this is exactly like this. My understand from a brief reading is that 32 ETH is the minimum balance to get active in the network, but your effective balance can drop to 16 ETH before you get ejected from the network. https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#validator-cycle

Attestations

I would carefully measure how many attestations reach the node and the space it will consume in the database

Validator consolidations

I am not sure the current size of the database, but it will probably shrink by several orders of magnitude, as the validators table is the one consuming most of the space. This means you will be able to store more epochs data, which I dont know may you are currently storing.
I would love to have a call about this!

[santi1234567]

Hey @tdahar, thanks for the feedback! Regarding your comments:

MIN_ACTIVATION_BALANCE

You mention that the minimum effective balance is 32 ETH, but please review if this is exactly like this. My understand from a brief reading is that 32 ETH is the minimum balance to get active in the network, but your effective balance can drop to 16 ETH before you get ejected from the network. https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#validator-cycle

The EIP mentions the minimum staking balance being 32 ETH which I'm pretty sure is talking about the minimum stake that is required to be deposited in order for a validator to start participating in the protocol and not about the effective balance of the validator.

(the abstract that I included in the issue is extracted from the EIP)

Attestations

I would carefully measure how many attestations reach the node and the space it will consume in the database

We don't have yet an attestations table. The changes on goteth regarding this EIP will be supporting the new ProcessAttestations function which is an implementation of the modified spec function process_attestation.

Validator consolidations

I am not sure the current size of the database, but it will probably shrink by several orders of magnitude, as the validators table is the one consuming most of the space. This means you will be able to store more epochs data, which I dont know may you are currently storing.

Yes, that is a good observation. At the moment though, goteth stores rewards data on all validators (active and inactive) which is something that we plan on changing in the near future (I created a new issue for this: #158). Once we implement that, then depending on how successful the consolidation process is, then it is expected for the t_validator_rewards_summary table to reduce quite significantly in size.