Workspace Index › Knowledge Notes › Quick Slots (EIP-8198) — the change is not 12 → 10 s, it is making slot time a parameter
#56PoC2026-09-16chatdone 2026-09-16
Quick Slots (EIP-8198) — the change is not 12 → 10 s, it is making slot time a parameter
EIP-8198 "Quick Slots" (Carl Beekhuizen, Draft, 2026-03) makes Ethereum's slot duration a runtime schedule instead of a compile-time constant, then uses that to take the first cut: the EIP text says 8 s, the consensus-specs PR and Ethlabs propose 10 s for Hegotá, and the long-run target is ~6 s. Gas limit and blob targets scale by the same ratio, so throughput per second does not change — only how often a block lands. The "faster" part is the small part. The work is retuning every constant that is denominated in slots or epochs so that its wall-clock meaning stays the same. The schedule is bookkeeping, not a lever: an ordered list of eras (epoch, slot duration, intra-slot deadlines) starting at genesis, kept so that slot ↔ wall-clock conversion stays correct across the boundary. Every later entry must coincide with a network upgrade; the PR is explicit that it is not a way to change slot time between upgrades.
For Jayverse: nothing to ship, one thing to check. The devnet runs Anvil at 1 s blocks, twelve times faster than mainnet, so any Jayverse code that converts blocks to time or hardcodes twelve seconds is already wrong there — market close, oracle staleness, keeper timing, bridge finality should be expressed in seconds or in finalized, never in block counts. Status on 2026-09-16: Draft; consensus-specs PR #5592 open; EF Protocol tier B with four prerequisites (engineering teams rated it D for the retuning cascade); Ethlabs S-tier, 10 s in Hegotá. No inclusion decision yet.
Why
Every "Ethereum killer" of the last decade sold the same line, "Ethereum, but fast", and paid for it with fewer validators, heavier hardware, or a foundation-run sequencer. The claim of 8198 is that Ethereum can get faster without spending any of that, because the binding constraint was never raw speed — it was that a hundred constants silently assume twelve seconds. Rewards per year, the inactivity leak, how long blobs are kept, how many validators may leave per epoch, the attestation deadline inside a slot, gas per second: all of them are written in slots or epochs and would change meaning if only the slot moved. So the EIP's rule is the interesting part: do not adjust a constant unless leaving it unchanged causes a concrete security or economic failure, which leaves four families to retune (issuance, leak, data-availability windows, churn / weak subjectivity) and everything else alone.
The disagreement is about readiness, not direction. The EF Protocol post of 2026-09-07 puts it at tier B — "specifications covering all expected changes, a prototype implementing that full specification, an in-depth assessment of downstream effects, and sign-off that it does not complicate decoupled consensus" before it can be A — and the client engineering teams rated it D because of the retuning cascade. Ethlabs puts it at S with a timing argument: ePBS already restructured the slot into millisecond deadlines in Glamsterdam, decoupled consensus comes later, so Hegotá is the one window where the refactor is cheap — "either commit to 12 s for the next two years minimum, or land 10 s in about a year".
How it works
What the EIP changes, and why each number moves
Constant
12 s
8 s (EIP text)
Why it moves
SLOT_DURATION_MS
12,000
8,000
the change itself; the PR replaces the constant with SLOT_TIMING_SCHEDULE, an ordered list of eras each pinned to a network upgrade, so slot ↔ time conversion stays correct across the boundary. The PR body: it "is simply a way to loop over historical slot durations", not a mechanism for changes between upgrades
BASE_REWARD_FACTOR
64
42
× ratio — more epochs per year would otherwise raise issuance
INACTIVITY_PENALTY_QUOTIENT
16,777,216
37,748,736
× ratio² — keeps the leak curve the same in wall-clock
MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS (and data columns)
4,096
6,144
÷ ratio — the blob retention window stays ~18 days
CHURN_LIMIT_QUOTIENT
65,536
98,304
keeps validator turnover per day, and so the weak-subjectivity period, unchanged
per-epoch churn limits (Gwei)
128 / 256 ×10⁹
85.3 / 170.7 ×10⁹
same reason, other side of the ratio
gas limit, blob target and max
—
× 8/12
set at the fork block, not by the miner-vote mechanism, to avoid hours of convergence; gas per second is unchanged
The 10 s variant in PR #5592 uses the same recipe with ratio 5/6; minimal testnets run 5 s slots so the mainnet-equivalent is 10.
The retuning cascade — why "faster" is the small part
Rewards and penalties are per epoch; more epochs per year means more issuance and a faster leak unless divided back.
Retention windows are in epochs; keep them in epochs and blobs disappear sooner, which shortens the data-availability guarantee L2s rely on.
Churn is per epoch; keep it and validators can exit faster, which shortens the weak-subjectivity period a fresh node needs to sync safely.
Intra-slot deadlines (propose, attest, aggregate, payload) are milliseconds inside the slot; the schedule carries them per era, and the PR deliberately does not scale them with the duration — fixed overheads mean each deadline is tuned on its own, and the values are deferred until testing (the EIP text had them as basis points of the slot that scale automatically).
Gas per slot must fall so gas per second does not rise; otherwise "faster" is a stealth throughput increase with the validator-hardware cost that implies.
The motivation numbers the EIP quotes: arbitrage loss to LPs falls roughly 18 % at 8 s; empty-block option value under ePBS shrinks; preconfirmation protocols matter less; based rollups inherit the faster L1 cadence directly.
Where it lands in Jayverse
The devnet at chainId 313370 runs anvil --block-time 1. That is not a limitation, it is the test. If a service behaves at 1 s blocks and at 12 s on Sepolia, it will behave at 10 s. The checklist is one question per service: does anything convert blocks to time?
Service
Block-denominated risk
Time-denominated form
Verex
"market closes at block N"
close at a timestamp; resolve on the first block whose timestamp ≥ close
Verex feeds.ts
staleness as "N blocks old"
Chainlink updatedAt vs block.timestamp, heartbeat in seconds
Clock keeper
"every 5 blocks"
cron by wall-clock; the trigger reads block.timestamp
Token bridge
"wait 12 blocks" as finality
finalized tag on the devnet and Sepolia; seconds only as a fallback
Wallet preview
"~12 s to confirm"
read the chain's slot time from config, or say "next block"
Rabbit / Game / Number
polling every 12 s
poll on new heads (/ws) or by interval, never by assumed block time
Nothing here depends on 8198 landing. It depends on the devnet running fast blocks, which it already does.
Verified and unverified
Verified on 2026-09-16: the EIP text and constants (Draft, created 2026-03-17); consensus-specs PR #5592 is open, targets 10 s, and replaces the constant with a schedule whose entries must coincide with network upgrades — its description says the schedule "is simply a way to loop over historical slot durations", not a way to change slot time between upgrades; the EF Protocol post rates it tier B with the four prerequisites and reports the engineering teams' D; Ethlabs' writing puts it at S and proposes 10 s in Hegotá. Not verified: whether 8198 is scheduled for Hegotá (no decision as of this writing), Hegotá's date (after Glamsterdam, "waiting for post-Glamsterdam mainnet data"), and whether 8 or 10 s lands first.
Quick Slots (EIP-8198) — 핵심은 12 → 10초가 아니라 슬롯 시간을 파라미터로 만드는 것
EIP-8198 "Quick Slots"(Carl Beekhuizen, Draft, 2026-03)는 Ethereum의 슬롯 길이를 컴파일 타임 상수가 아닌 런타임 스케줄로 바꾸고, 그 위에서 첫 번째 단축을 합니다. EIP 본문은 8초, consensus-specs PR과 Ethlabs는 Hegotá에서 10초를 제안하며, 장기 목표는 약 6초입니다. 가스 한도와 블롭 목표치가 같은 비율로 줄어들어 초당 처리량은 변하지 않고, 블록이 얼마나 자주 나오는지만 바뀝니다. "빨라진다"는 작은 부분입니다. 진짜 일은 슬롯이나 에포크 단위로 적힌 모든 상수를 다시 조정해 실제 시간 기준의 의미를 유지하는 것입니다. 스케줄은 레버가 아니라 장부입니다. 제네시스에서 시작하는 시대(에포크, 슬롯 길이, 슬롯 내 마감)의 정렬된 목록이며, 경계를 넘어서도 슬롯 ↔ 실제 시간 변환이 맞도록 유지하는 용도입니다. 이후의 모든 항목은 네트워크 업그레이드와 일치해야 하고, PR은 업그레이드 사이에 슬롯 시간을 바꾸는 수단이 아니라고 명시합니다.
Jayverse에서는 출시할 것은 없고 확인할 것 하나가 있습니다. devnet은 Anvil을 1초 블록으로 돌리는데, 메인넷보다 12배 빠르므로 블록 수를 시간으로 환산하거나 12초를 하드코딩한 Jayverse 코드는 거기서 이미 틀립니다. 마켓 마감, 오라클 신선도, 키퍼 타이밍, 브리지 최종성은 초 단위나 finalized로 표현하고 블록 수로는 절대 표현하지 않아야 합니다. 2026-09-16 기준 상태: Draft; consensus-specs PR #5592 열려 있음; EF Protocol은 네 가지 전제 조건을 붙여 B 티어(클라이언트 엔지니어링 팀들은 재조정 연쇄 때문에 D); Ethlabs는 S 티어, Hegotá에서 10초. 포함 결정은 아직 없습니다.
왜
지난 10년의 모든 "Ethereum 킬러"는 같은 문장, "Ethereum인데 빠르다"를 팔았고, 그 대가로 더 적은 검증자, 더 무거운 하드웨어, 재단이 운영하는 시퀀서를 지불했습니다. 8198의 주장은 그중 어느 것도 쓰지 않고 Ethereum이 빨라질 수 있다는 것입니다. 진짜 제약은 속도 자체가 아니라 백 개의 상수가 조용히 12초를 전제한다는 점이었기 때문입니다. 연간 보상, 비활성 누수, 블롭 보존 기간, 에포크당 이탈 가능 검증자 수, 슬롯 안의 증명 마감, 초당 가스. 모두 슬롯이나 에포크로 적혀 있어서 슬롯만 움직이면 의미가 바뀝니다. 그래서 EIP의 규칙이 흥미로운 부분입니다. 그대로 두면 구체적인 보안 또는 경제적 실패가 생기는 경우가 아니면 상수를 조정하지 않는다. 그 결과 재조정할 것은 네 가족(발행, 누수, 데이터 가용성 창, 이탈 / 약한 주관성)이고 나머지는 그대로입니다.
의견 차이는 방향이 아니라 준비 상태에 관한 것입니다. 2026-09-07 EF Protocol 글은 B 티어로 두고, A가 되기 전에 "예상되는 모든 코어 변경을 다루는 사양, 그 전체 사양을 구현한 프로토타입, 생태계 전반의 파급 효과에 대한 심층 평가, 분리형 합의(decoupled consensus)를 복잡하게 하지 않는다는 승인"을 요구합니다. 클라이언트 엔지니어링 팀들은 재조정 연쇄 때문에 D를 줬습니다. Ethlabs는 타이밍 논거로 S를 줍니다. ePBS가 Glamsterdam에서 이미 슬롯을 밀리초 단위 마감으로 재구성했고, 분리형 합의는 나중에 오므로, 리팩터링이 싼 유일한 창이 Hegotá라는 것입니다. "최소 2년은 12초에 머물기로 하든지, 약 1년 뒤 10초를 Hegotá에 넣든지."
동작 방식
EIP가 바꾸는 것과 각 숫자가 움직이는 이유
상수
12초
8초 (EIP 본문)
움직이는 이유
SLOT_DURATION_MS
12,000
8,000
변경 자체; PR은 이 상수를 각각 네트워크 업그레이드에 고정된 시대들의 정렬 목록 SLOT_TIMING_SCHEDULE로 대체해 경계를 넘어서도 슬롯 ↔ 시간 변환이 맞게 한다. PR 본문: "과거 슬롯 길이들을 순회하기 위한 단순한 방법"이며 업그레이드 사이의 변경 수단이 아니다
BASE_REWARD_FACTOR
64
42
× 비율 — 연간 에포크가 늘면 발행량이 늘어나므로
INACTIVITY_PENALTY_QUOTIENT
16,777,216
37,748,736
× 비율² — 누수 곡선을 실제 시간 기준으로 동일하게 유지
MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS (데이터 컬럼도)
4,096
6,144
÷ 비율 — 블롭 보존 창을 약 18일로 유지
CHURN_LIMIT_QUOTIENT
65,536
98,304
하루당 검증자 교체율, 따라서 약한 주관성 기간을 그대로 유지
에포크당 이탈 한도 (Gwei)
128 / 256 ×10⁹
85.3 / 170.7 ×10⁹
같은 이유, 비율의 반대편
가스 한도, 블롭 목표·최대
—
× 8/12
채굴자 투표 메커니즘이 아니라 포크 블록에서 직접 설정해 수 시간의 수렴을 피함; 초당 가스는 불변
PR #5592의 10초 버전은 비율 5/6으로 같은 조리법을 쓰고, 최소 테스트넷은 5초 슬롯으로 돌려 메인넷 환산 10초가 됩니다.
재조정 연쇄 — "빨라진다"가 작은 부분인 이유
보상과 벌칙은 에포크당이다. 연간 에포크가 늘면 나눠 주지 않는 한 발행이 늘고 누수가 빨라진다.
보존 창은 에포크 단위다. 그대로 두면 블롭이 더 빨리 사라져 L2가 의존하는 데이터 가용성 보증이 짧아진다.
이탈(churn)은 에포크당이다. 그대로 두면 검증자가 더 빨리 빠져나가 새 노드가 안전하게 동기화하는 데 필요한 약한 주관성 기간이 짧아진다.
슬롯 내 마감(제안, 증명, 집계, 페이로드)은 슬롯 안의 밀리초다. 스케줄이 이를 시대별로 담고, PR은 의도적으로 슬롯 길이에 비례해 줄이지 않는다. 고정 오버헤드 때문에 마감마다 따로 튠하며 값은 테스트 뒤로 미뤄졌다(EIP 본문은 슬롯의 베이시스 포인트로 자동 비례하게 두었다).
슬롯당 가스는 줄어야 초당 가스가 오르지 않는다. 아니면 "빨라진다"는 검증자 하드웨어 비용을 동반한 은밀한 처리량 증가가 된다.
오프체인의 모든 것 — 클라이언트, 익스플로러, 지갑, L2 파생, 블록 수 × 12를 계산하는 모든 코드.
EIP가 인용하는 동기의 숫자: 8초에서 LP의 차익거래 손실이 약 18 % 감소; ePBS에서 빈 블록의 옵션 가치가 줄어듦; 사전확인(preconfirmation) 프로토콜의 필요성 감소; based 롤업은 더 빠른 L1 박자를 그대로 상속.
Jayverse에서의 위치
chainId 313370의 devnet은 anvil --block-time 1로 돌아갑니다. 그건 제약이 아니라 테스트입니다. 서비스가 1초 블록과 Sepolia의 12초에서 모두 제대로 동작하면 10초에서도 동작합니다. 체크리스트는 서비스마다 질문 하나입니다. 블록을 시간으로 환산하는 곳이 있는가?
서비스
블록 단위의 위험
시간 단위의 형태
Verex
"블록 N에서 마켓 마감"
타임스탬프로 마감; timestamp ≥ close인 첫 블록에서 정산
Verex feeds.ts
신선도를 "N블록 전"으로
Chainlink updatedAt 대 block.timestamp, 하트비트는 초 단위
Clock 키퍼
"5블록마다"
실제 시간 크론; 트리거는 block.timestamp를 읽음
Token 브리지
최종성으로 "12블록 대기"
devnet과 Sepolia에서 finalized 태그; 초 단위는 폴백으로만
Wallet 미리보기
"확인까지 ~12초"
체인의 슬롯 시간을 설정에서 읽거나 "다음 블록"이라고 표시
Rabbit / Game / Number
12초마다 폴링
새 헤드(/ws) 또는 인터벌로 폴링, 가정한 블록 시간으로는 절대 아님
여기 있는 어떤 것도 8198이 채택되는지에 달려 있지 않습니다. devnet이 빠른 블록으로 돌아가는지에 달려 있고, 그건 이미 그렇습니다.
확인된 것과 미확인
2026-09-16에 확인한 것: EIP 본문과 상수(Draft, 2026-03-17 생성); consensus-specs PR #5592는 열려 있고 10초를 목표로 하며 상수를 항목이 네트워크 업그레이드와 일치해야 하는 스케줄로 대체 — 설명에 스케줄은 "과거 슬롯 길이들을 순회하기 위한 단순한 방법"이고 업그레이드 사이에 슬롯 시간을 바꾸는 수단이 아니라고 적혀 있음; EF Protocol 글은 네 가지 전제 조건과 함께 B 티어로 평가하고 엔지니어링 팀들의 D를 전함; Ethlabs 글은 S로 두고 Hegotá에서 10초를 제안. 확인하지 않은 것: 8198이 Hegotá에 확정되었는지(이 글 시점에 결정 없음), Hegotá 시기(Glamsterdam 이후, "Glamsterdam 이후 메인넷 데이터를 기다림"), 8초와 10초 중 무엇이 먼저 들어가는지.