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.
2 Likes
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.
PR opened with the suggestion: Update EIP-8198: Use SLOT_SCHEDULE for slot-time-dependent constants by smartprogrammer93 · Pull Request #11458 · ethereum/EIPs · GitHub
The SLOT_SCHEDULE idea discussed above now has an upstream-facing executable EL implementation:
https://github.com/ethereum/execution-specs/pull/3473
It is currently one commit / eight files over Amsterdam, with exact validation green through static, spec-tools, focused/full EIP-8198 tests, diff check, exact changed-file-set verification, and immutable head/base checks.
EIP-side proposal: https://github.com/ethereum/EIPs/pull/11458
The narrow design question is whether EIP-8198 should pay the EL refactor cost once so later slot-duration reductions become schedule/config changes rather than new duration-specific execution logic.
Current head: f06d972f496ca9325559f840db45a10cfd6f86e1