EIP-8198 퀵 슬롯: 슬롯 시간 12초에서 10초로 (Quick Slots)
포함 제외 (DFI) · 합의·스테이킹 · 원문 상태 Draft · 2026-03-17 작성
슬롯 시간을 코드에 고정된 상수가 아니라 에폭별 일정표(SLOT_DURATION_SCHEDULE)로 바꾸고 그 장치로 블록 간격을 12초에서 10초로 줄입니다. 보상, 페널티, 블롭 보관 기간은 실제 시간 기준으로 그대로 유지합니다.
왜 필요한가
지금 이더리움은 12초마다 블록 하나가 나옵니다. 송금, 거래소 입금, 결제를 할 때마다 이 12초가 체감됩니다. 원문은 문제를 몇 가지로 나눠 설명합니다. 탈중앙 거래소(DEX)의 유동성 공급자가 차익거래로 잃는 손실은 블록 간격의 제곱근에 비례해서 12초를 10초로 줄이면 약 9% 줄어듭니다. 슬롯이 짧아지면 최종 확정까지 걸리는 시간도 앞당겨지고 같은 시간 안에 블록 제안자가 더 많아져 거래를 검열하기 어려워집니다. 12초 지연을 가리려고 쌓아 올린 사전 확정(preconfirmation) 장치의 필요성도 줄어듭니다. L2가 입금을 처리하려고 L1 블록 몇 개를 기다리는 시간도 함께 짧아집니다. 그런데 정작 병목은 숫자 고르기가 아닙니다. 모든 합의 클라이언트와 실행 클라이언트 곳곳에 '슬롯은 12초'라는 가정이 박혀 있습니다. 이 EIP는 먼저 그 가정을 걷어내 슬롯 시간을 설정값으로 만들고 그다음 보수적으로 10초로 줄이는 두 가지를 함께 합니다.
무엇이 바뀌나
지금
- 슬롯 시간 12초가 클라이언트 코드에 상수(SLOT_DURATION_MS)로 고정돼 있습니다.
- 블록 간격을 바꾸려면 합의·실행 클라이언트 전체를 손봐야 합니다.
- 기본 수수료가 블록마다 최대 1/8씩 움직이며 이 값은 12초 블록에 맞춰져 있습니다.
- 블롭 데이터 보관 기간이 에폭 수(4,096 에폭)로 정해져 있습니다.
EIP-8198 이후
- 슬롯 시간이 에폭별 일정표(SLOT_DURATION_SCHEDULE)에 기록되고 메인넷에서는 HEZE_FORK_EPOCH부터 10초가 됩니다.
- 다음에 슬롯 시간을 바꿀 때는 일정표에 항목 하나를 더하고 마감 규칙만 정하면 됩니다.
- 기본 수수료 최대 변동 폭이 블록 간격에서 계산되어 10초 슬롯에서는 5/48이 됩니다.
- 블롭 데이터 보관 기간이 밀리초(MIN_BLOB_DATA_RETENTION_MS)로 정해져 실제 시간으로는 그대로입니다.
누구에게 영향이 있나
- 사용자: 거래가 블록에 담기는 시간, 거래소 입금, L2 입금 대기가 실제 시간으로 짧아집니다.
- 검증자·클라이언트 팀: 합의 클라이언트는 12초 가정을 없애고 구간별 시간표로 바꿔야 합니다. 업그레이드 전에 가스 한도를 미리 낮추는 조율도 필요합니다. 초당 연산·대역폭 부담은 올라가지만 블록당 부담은 내려갑니다.
- 앱·컨트랙트 개발자: 블록 수로 세는 타임록, 투표 기간, TWAP 창이 실제 시간으로 약 17% 짧아집니다. block.timestamp 기반 로직은 영향이 없습니다.
- L2·브리지: L1 블록 수로 세는 지연·챌린지 기간이 짧아지고 기반 롤업(based rollup)은 아무 수정 없이 더 빨라집니다.
심층 설명
슬롯 시간 일정표(SLOT_DURATION_SCHEDULE)
SLOT_DURATION_MS 상수를 없애고 SLOT_DURATION_SCHEDULE 목록으로 바꿉니다. 각 항목은 활성화 에폭과 슬롯 시간(ms) 두 값뿐입니다. get_slot_duration_ms(epoch)이 해당 에폭에 적용되는 값을 돌려줍니다. 일정표는 네 조건을 지켜야 합니다. 첫 항목은 GENESIS_EPOCH에 12,000ms여야 하고 이것이 비율 계산의 기준입니다. 항목은 에폭 오름차순이어야 합니다. 이후 항목은 HEZE_FORK_EPOCH 이상의 네트워크 업그레이드 에폭에서만 활성화됩니다. 업그레이드 사이의 변경(BPO 방식)은 지원하지 않습니다. 슬롯 시간은 1,000ms의 양의 배수여야 해서 모든 슬롯 경계의 타임스탬프가 정수 초입니다. 메인넷에는 HEZE_FORK_EPOCH에 10,000ms 항목이 추가됩니다. 슬롯 시간 비율 r은 get_slot_duration_ms(epoch) / get_slot_duration_ms(GENESIS_EPOCH)로, 10초 시대에는 5/6입니다. r은 따로 계산하지 않고 공식마다 분자를 곱한 뒤 마지막에 분모로 나눕니다. 모든 산술은 정수 나눗셈입니다.
슬롯 안 마감 시각과 구간별 시간표
증명, 집계, 동기화 메시지, 제안자 리오그 컷오프 같은 슬롯 안 마감은 지금처럼 슬롯 시간의 bps(basis points) 값(ATTESTATION_DUE_BPS, PROPOSER_REORG_CUTOFF_BPS 등)으로 둡니다. 밀리초로 바꾸는 get_slot_component_duration_ms는 현재 적용 중인 값 대신 포크 시점의 슬롯 시간 get_slot_duration_ms(HEZE_FORK_EPOCH)에 bps를 적용합니다. 일정표에는 마감 정보가 없고 나중에 슬롯 시간을 또 바꾸는 업그레이드는 자기 마감 규칙을 따로 정해야 합니다. 전파, 집계, 블록 생성에는 고정 오버헤드가 있어 모든 구성 요소가 슬롯 시간에 비례해 줄지 않기 때문입니다. 시간과 슬롯 번호의 대응도 달라집니다. 제네시스부터 12초 곱하기가 아니라 시대(era)별로 각자 슬롯 시간으로 이어지는 구간별 시간표에서 구해야 합니다. compute_time_at_slot로 하는 실행 페이로드 타임스탬프 검증, 포크 초이스 저장소 시계(compute_slot_at_time_ms, compute_time_at_slot_ms, 체크포인트 동기화 초기화 포함), 슬롯 안 적시성 측정(time % SLOT_DURATION_MS 대신 슬롯 시작 시각 기준), 가십 슬롯 범위 검증, 만료·점수 창, 라이트 클라이언트 시계 유도가 모두 여기 해당합니다. 듀티 스케줄러는 밀리초 정밀도를 유지해야 합니다.
합의 경제: 상수는 그대로, 비율 r로 재조정
합의 상수 값은 하나도 바뀌지 않습니다. 대신 시간에 의존하는 에폭당 비율 세 가지를 r로 재조정합니다. 증분당 기본 보상은 × r이라 BASE_REWARD_FACTOR 64가 실효값 64 × 5/6 = 53.33이 됩니다. 반올림한 53이 아니라 정확한 비율이라 발행량이 체계적으로 어긋나지 않습니다(잘림 오차는 계산당 최대 1 Gwei). 비활성 페널티는 누적치가 에폭 수의 제곱이라 × r²이고 페널티 분모에 접어 넣어 실효 분모가 36/25배가 됩니다. INACTIVITY_SCORE_BIAS는 분자와 분모에서 상쇄되어 손대지 않습니다. 활성화·탈퇴·통합 churn 한도는 × r이며 최소·최대 경계를 먼저 적용한 뒤 비율을 곱하고 EFFECTIVE_BALANCE_INCREMENT 반올림은 마지막에 한 번만 합니다. 이미 배정된 탈퇴·통합 에폭은 그대로 둡니다. 보상과 페널티는 처리하는 에폭이 아니라 '값을 치르는 에폭'의 슬롯 시간으로 계산합니다. 이렇게 하지 않으면 전환 직후 첫 에폭이 12초짜리 증명을 10초 단가로 쳐서 약 17% 적게 주고 비활성 페널티는 약 31% 작게 나옵니다. 출금 가능 지연, 슬래싱 창, 동기화 위원회 주기, SLOTS_PER_EPOCH(32) 같은 에폭·슬롯 단위 값은 개수를 유지해 실제 시간이 줄어듭니다. 에폭은 약 5.3분, 최종성은 약 13분에서 약 10.7분이 됩니다.
데이터 가용성 보관 기간
데이터 컬럼 사이드카 보관 창을 에폭 수(MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS) 대신 실제 시간 MIN_BLOB_DATA_RETENTION_MS로 정의합니다. 값은 1,572,864,000ms(약 18.2일)로, 12초 슬롯 4,096 에폭과 같습니다. 새 헬퍼 compute_blob_data_retention_start_epoch(epoch)이 구간별 시간표에서 그만큼 앞선 시점이 속한 에폭을 돌려줍니다. 보관 창 시작은 max(그 값, FULU_FORK_EPOCH)이고 Status v2의 earliest_available_slot, DataColumnSidecarsByRange v1과 DataColumnSidecarsByRoot v1의 data_column_serve_range 하한이 이 값을 씁니다. 챌린지 기간이 약 7일인 옵티미스틱 롤업처럼 외부 소비자는 에폭 수가 아니라 실제 시간으로 데이터를 기대하기 때문입니다. 10초 전환 뒤 창이 덮는 에폭 수는 한 에폭씩 늘어 약 4,916까지 가고 시작점은 뒤로 가지 않습니다. 그래서 노드는 미리 더 보관하거나 나중에 다시 받을 필요가 없습니다. 반면 블록 보관 창 compute_min_epochs_for_block_requests()(메인넷 33,024 에폭)와 다른 에폭 단위 창은 에폭 수를 유지해 실제 시간이 약 146.8일에서 약 122.3일로 서서히 줄어듭니다. 블롭 사이드카 Req/Resp는 이미 폐기된 상태라 손대지 않습니다.
실행 계층: 가스 한도와 기본 수수료
실행 계층은 슬롯 시간을 읽지 않습니다. 가스 처리량은 합의 규칙이 아니라 사전 조율로 지킵니다. 업그레이드 전에 GAS_LIMIT_SCHEDULE과 제안자 target_gas_limit로 목표를 × r(예: 100M에서 약 83.3M)로 낮춰 두면 평소의 ±1/1024 조정만으로 몇 시간 안에 도달합니다. 조율에 실패해도 초당 가스가 최대 20% 잠시 넘칠 뿐 합의 유효성에는 영향이 없습니다. 기본 수수료의 블록당 최대 변동 1/8은 12초 기준이라 그대로 두면 실제 시간당 20% 빨리 반응합니다. 그래서 상수를 바꾸는 대신 헤더의 timestamp와 slot_number(EIP-7843)로 부모와의 간격을 재서 구합니다. 분모는 BASE_FEE_MAX_CHANGE_DENOMINATOR × BASE_FEE_REFERENCE_SLOT_SECONDS × slots_elapsed이고 seconds_elapsed는 BASE_FEE_REFERENCE_SLOT_SECONDS × slots_elapsed를 상한으로 둡니다. BASE_FEE_REFERENCE_SLOT_SECONDS는 새 상수 12, BASE_FEE_MAX_CHANGE_DENOMINATOR는 8 그대로입니다. 최대 변동은 min(slot_duration, 12) / 96이 되어 12초면 정확히 1/8, 10초면 정확히 5/48입니다. 업그레이드부터 header.slot_number > parent_header.slot_number가 아니면 블록이 무효이고 EIP-7843이 먼저 켜져 있어야 합니다. 빈 슬롯은 비율을 바꾸지 않습니다. 복리 때문에 완전히 같지는 않아 10초에서는 가득 찬 블록일 때 초당 약 1.0% 빠르게 오르고 빈 블록일 때 약 1.1% 느리게 내립니다.
블롭 일정, 시스템 컨트랙트, 네트워킹
이 EIP는 블롭 파라미터를 바꾸지 않습니다. 슬롯 시간 변경에는 EIP-7892 방식의 블롭 전용 포크, 즉 같은 에폭에 활성화되는 BLOB_SCHEDULE 항목이 따라붙어 블롭 목표, 최대치, BLOB_BASE_FEE_UPDATE_FRACTION을 새 슬롯 시간에 맞춥니다. 슬롯 시간을 바꾸지 않는 네트워크는 항목을 넣지 않으면 됩니다. EIP-4788 비콘 루트 컨트랙트와 EIP-2935 블록 해시 히스토리 컨트랙트의 8,191칸 버퍼는 배포된 컨트랙트의 일부라 일부러 바꾸지 않습니다. 네트워킹에서는 토픽이 업그레이드 포크 다이제스트로 평소처럼 다시 키를 받고 클라이언트는 업그레이드 에폭 전에 새 토픽을 구독하는 것이 좋습니다. ATTESTATION_PROPAGATION_SLOT_RANGE는 32슬롯, EPOCHS_PER_SUBNET_SUBSCRIPTION은 256 에폭을 유지해 실제 시간만 줄어듭니다(서브넷 구독 회전은 약 27.3시간에서 약 22.8시간). MAXIMUM_GOSSIP_CLOCK_DISPARITY와 TTFB_TIMEOUT, RESP_TIMEOUT 같은 절대 시간 허용치는 재조정하면 안 됩니다. 가십섭 seen_ttl은 두 에폭이라는 정의식을 구간별 시간표에서 계산합니다.
앱과 도구에 미치는 영향
블록 수를 실제 시간으로 환산하던 모든 로직이 전환 시점에 달라집니다. block.timestamp 기반 로직은 영향이 없습니다. 12초에서 10초면 N블록짜리 기간은 약 17% 짧아지고 블록당 수량은 약 20% 빨리 소모됩니다. EIP-4788과 EIP-2935 버퍼는 8,191칸 그대로라 되돌아볼 수 있는 시간이 약 27.3시간에서 약 22.8시간으로 줄어 '하루치는 있다'고 가정한 컨트랙트는 더 이상 그렇지 않습니다. 업그레이드를 가로지르는 구간에서는 12초와 10초 간격이 섞여 2 × 8,191초 떨어진 두 타임스탬프가 같은 EIP-4788 버퍼 칸을 쓸 수 있어 업그레이드 직전 8,191개 비콘 루트 중 약 3분의 1이 일찍 덮어써집니다(가장 빠른 것은 약 4.6시간 뒤). 조회는 잘못된 루트를 주지 않고 되돌립니다(revert). 블록 번호로 세는 타임록, 베스팅, 거버넌스 투표·지연 기간, 쿨다운은 일찍 끝나고 블록당 이자·보상·발행·속도 제한은 시간당 늘어나며 블록 수로 잡은 TWAP 창은 더 짧은 기간을 평균합니다. genesis_time + 12 × slot로 계산하는 오프체인 도구는 구간별 시간표나 블록 타임스탬프로 바꿔야 합니다. L1 블록 수로 잰 L2·브리지의 최종성 지연, 챌린지 기간, 타임아웃은 짧아지고 초 단위는 그대로입니다. 클라이언트가 실제 시간 타이머로 보관을 구현했다면 전환 전에 계산한 타이머는 필요보다 오래 보관할 뿐 규격에는 맞습니다.
단계별 접근, 대체안, 진행 상황
원문은 작업을 세 단계로 나눕니다. 1단계는 가변 슬롯 시간 인프라로, 12초 가정을 지우고 compute_time_at_slot 같은 함수와 포크 전환 로직을 일정표 기반으로 바꾸는 것입니다. 2단계는 데브넷과 벤치마크로 합의 계층 병목(블롭 전파, 증명 집계, 로컬 블록 생성 시간)을 재는 CL 성능 특성화입니다. 3단계는 그 결과에 따라 슬롯 시간을 반복해서 줄이는 것입니다. 10초는 보수적인 자리표시자이며 2단계 결과에 따라 배포 전에 바뀔 수 있습니다. 2단계에서 10초가 아직 어렵다고 나오면 HEZE_FORK_EPOCH 항목의 슬롯 시간을 최대 12초까지 올릴 수 있고 그때 r = 1이라 모든 재조정 값과 기본 수수료 규칙이 지금과 정확히 같아집니다. 원문 상태는 Draft라 내용이 더 바뀔 수 있습니다. 코어 개발자 콜 기록으로는 08.06 ACDC #184에서 헤고타 후보(PFI)로 접수되었고 슬롯 시간을 줄이면 블록당 가스 한도와 블롭 수도 같이 줄여 초당 처리량을 유지하기로 확정했습니다. 10.01 ACDC #188에서 헤고타 포함 검토 대상(CFI)으로 올랐으며 실제 12초에서 10초 단축은 포함 확정 전에 추가 검증을 거쳐야 합니다. 10.12 ACDT #100에서는 heze-devnet-2에 EIP-7805(FOCIL), EIP-8015, EIP-8365와 함께 EIP-8198을 포함하되 슬롯 길이는 12초로 유지하기로 확정했습니다. 기능은 넣고 실제 단축은 클라이언트 준비를 더 보고 한다는 뜻입니다.