Discussion topic for EIP-8198
Update Log
- 2026-02-10: EthMagicians thread on Quick Slots in Hegota
- 2026-03-17: Initial draft
External Reviews
None as of 2026-03-17.
Outstanding Issues
None as of 2026-03-17.
Discussion topic for EIP-8198
None as of 2026-03-17.
None as of 2026-03-17.
I believe this EIP should consider for the slot-time-dependent constants it introduces to follow the same pattern EIP-7892 introduced BPO forks.
Rather than hardcoding the new values in the spec, define a SLOT_SCHEDULE (or extend the fork config) that maps epoch → SLOT_DURATION_MS and its derived parameters:
SLOT_SCHEDULE:
- EPOCH: <FORK_EPOCH>
SLOT_DURATION_MS: 8000
BASE_REWARD_FACTOR: 42
INACTIVITY_PENALTY_QUOTIENT: 37748736
CHURN_LIMIT_QUOTIENT: 98304
MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA: 85333333333
MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT: 170666666666
MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS: 6144
MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS: 6144
The EIP already frames this as Phase 1 (infrastructure) followed by iterative reductions. If we plan to potentially reduce slot time further a schedule-based approach means those future reductions can be deployed as config-only updates the same way blob scaling works today rather than requiring new EIPs with hardcoded constant tables each time. Not only that, any of the other parameters could potentially be updated without any changes in the software purely with a spec file change.