EIP-8015: Remove `deposit` and `eth1data` fields

Abstract

This EIP removes the legacy deposits and eth1_data fields from the BeaconBlockBody structure after EIP-6110 has been fully finalized. These fields become obsolete once all validators have transitioned to the new in-protocol deposit processing mechanism introduced in EIP-6110.

Motivation

EIP-6110 introduced in-protocol deposit processing by moving validator deposits to the execution layer as part of the EIP-7685 request framework. This change eliminated the need for the consensus layer's proposer voting mechanism for deposits. However, during the transition period, both the legacy deposit mechanism (using deposits and eth1_data fields) and the new mechanism coexist to ensure smooth migration.

Once EIP-6110 has been fully finalized and the transition period is complete (when state.eth1_deposit_index == state.deposit_requests_start_index), the legacy deposit fields become permanently unused and can be safely removed. This cleanup provides several benefits:

• Simplified validation: Removes deprecated validation logic and code paths
• Improved maintainability: Eliminates technical debt from the transition period

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Consensus Layer

Activation Conditions

This EIP SHALL only be activated when both of the following conditions are met:

1. EIP-6110 has been fully finalized: state.eth1_deposit_index == state.deposit_requests_start_index
2. EIP-7732 is in effect

BeaconBlockBody Modifications

The BeaconBlockBody container is modified to remove the following fields:

Removed fields:

• deposits: List[Deposit, MAX_DEPOSITS]
• eth1_data: Eth1Data

The updated BeaconBlockBody structure becomes:

class BeaconBlockBody(Container):
    randao_reveal: BLSSignature
    graffiti: Bytes32
    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS_ELECTRA]
    attestations: List[Attestation, MAX_ATTESTATIONS_ELECTRA]
    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
    sync_aggregate: SyncAggregate
    bls_to_execution_changes: List[SignedBLSToExecutionChange, MAX_BLS_TO_EXECUTION_CHANGES]
    # From EIP-7732
    signed_execution_payload_header: SignedExecutionPayloadHeader
    payload_attestations: List[PayloadAttestation, MAX_PAYLOAD_ATTESTATIONS]

Validation Changes

Block processing modifications:

1. Remove process_eth1_data() function calls from block processing
2. Remove process_deposits() function calls from block processing
3. Remove eth1_data voting validation logic
4. Remove legacy deposit validation logic

State transition modifications:

1. Remove eth1_data related fields from state transition functions
2. Remove legacy deposit processing from process_operations()

BeaconState Cleanup

The following fields become unused after activation and MAY be removed in future updates:

• eth1_data: Eth1Data
• eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]
• eth1_deposit_index: uint64

Note: These fields are kept for historical state root verification but are no longer actively used.

Rationale

Timing of Removal

The fields are removed after EIP-6110 finalization to ensure:

• All pending deposits from the legacy system have been processed
• No validator can be affected by the removal
• The transition is complete and irreversible
• State consistency is maintained across all honest nodes

Dependency on EIP-7732

This EIP requires EIP-7732 because:

• EIP-7732 already modified the BeaconBlockBody structure significantly
• It provides the architectural foundation for simplified block bodies
• The timing aligns with the broader consensus layer improvements

Backwards Compatibility

Security Considerations

The removal of legacy fields poses minimal security risk because:

• The fields are already unused after EIP-6110 finalization
• All deposits are processed through the new EIP-6110 mechanism

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as: