EIP-8198 - Quick Slots ⚡️🎰

EIPs
1

Discussion topic for EIP-8198

Update Log

External Reviews

None as of 2026-03-17.

Outstanding Issues

None as of 2026-03-17.

2 Likes
2

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.

3

PR opened with the suggestion: Update EIP-8198: Use SLOT_SCHEDULE for slot-time-dependent constants by smartprogrammer93 · Pull Request #11458 · ethereum/EIPs · GitHub

4

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

5

Following up on the EL design question I raised above: I built the competing schedule-free implementation and tried to falsify it against the schedule-driven implementation rather than continuing to argue for the latter.

The experiment covers synthetic 12s → 10s → 8s → 6s eras. The competing EL carries fixed fork-local gas-limit, base-fee and blob parameters and has no runtime slot-duration schedule, epoch lookup or slot lookup. It was tested against the schedule-driven implementation as the behavioral oracle across repeated gas scaling, base-fee response, blob parameters, blob pricing and the integer-rounding boundary.

Result: 109/109 focused tests pass. I did not find an execution invariant that requires the EL to retain slot-duration history at runtime. Fork-local reparameterization can preserve the cumulative wall-clock behavior across the tested transitions.

Experiment and exact evidence: [COMPLETED EXPERIMENT] EIP-8198: schedule-free EL survives falsification by chugarchugarr · Pull Request #5 · chugarchugarr/execution-specs · GitHub
Green focused run: [COMPLETED EXPERIMENT] EIP-8198: schedule-free EL survives falsification · chugarchugarr/execution-specs@4cecc23 · GitHub

So I’m withdrawing the stronger version of my earlier claim. The schedule-driven implementation remains useful as an executable oracle and repeated-era regression harness, but the evidence I have now does not establish that the EL itself needs to own the slot-duration schedule. I’ve left that implementation parked unless a future execution rule exposes an invariant that fork-local parameters cannot preserve.

6

I support adopting a SLOT_DURATION_SCHEDULE (or equivalent fork-config extension) modelled on the BPO pattern introduced by EIP-7892. This approach better matches the phased design of EIP-8198: the initial change establishes the necessary infrastructure, while subsequent slot-duration reductions can be enacted as configuration updates rather than new hard-coded constant tables.

The original single-transition table served mainly as a clear illustration. Replacing it with an explicit schedule keeps the derived parameters (rewards, penalties, churn limits, retention windows, etc.) consistently linked to the active slot duration and reduces long-term coordination cost.

I recommend continuing refinement of the schedule format so that it cleanly supports the piecewise timeline, ratio-based scaling, and the gas-limit transition at the fork boundary. The first activation should remain conservative (current consensus leans toward 10 seconds) pending further performance data.