⏱ 이더리움 블록 간격 12초 — 블록 600개 실측 평균 12.06초와 최종 확정까지 780~1,032초

"이더리움은 12초마다 블록이 하나씩 나온다"는 문장은 거의 모든 안내서에 실려 있어요. 그런데 이 문장에서 12초가 붙는 자리가 사실은 블록이 아니에요. 규격이 12초로 못 박아 둔 것은 슬롯이고, 블록은 그 슬롯 위에서 나올 수도 있고 안 나올 수도 있는 결과예요.

차이가 말장난처럼 들리지만 재 보면 바로 갈려요. 슬롯은 정해진 기준 시각에서 12초씩 세는 시계라서 블록 제안자가 자리를 비워도 번호가 그대로 올라가요. 그래서 블록 타임스탬프의 차이는 12초 근처에서 흔들리는 것이 아니라 12초의 정수배로만 찍혀요. 11초도 13초도 나오지 않아요. 이번에 잰 표본에서는 12초와 24초 둘뿐이었어요.

이 글은 그 시계와 결과가 갈리는 자리를 직접 재요. 공개 비컨 API로 규격값과 현재 슬롯을 받아 벽시계와 대조하고, 공개 실행 RPC로 블록 600개를 연속으로 내려받아 간격을 값별로 세고, 비컨 슬롯 640개를 전수로 두드려 비어 있는 슬롯을 찾아요. 마지막으로 확정까지 걸리는 시간을 두 구간에 나눠 열여덟 번 표본으로 떴어요. 값은 요약하지 않고 조회 시각과 함께 그대로 옮길게요.

12초는 블록 간격이 아니라 슬롯 길이예요

먼저 규격값부터 받아 볼게요. 공개 비컨 노드의 설정 조회 주소예요.

https://ethereum-beacon-api.publicnode.com/eth/v1/config/spec

2026년 8월 18일 11시 21분 40초(한국 시각)에 받은 응답은 6,831바이트였고 본문의 키가 183개였어요. 그중 이 글에 필요한 값만 뽑으면 이래요.

여기서 첫 번째로 이상한 것이 보여요. 같은 12초가 두 이름으로 살아 있어요. SECONDS_PER_SLOT 은 12이고 SLOT_DURATION_MS 는 12000이에요. 라이브 노드는 둘 다 돌려주는데, 규격 저장소 원문을 열면 이야기가 달라져요.

이더리움 합의 규격 저장소의 메인넷 설정 파일을 그대로 내려받아 봤어요.

https://raw.githubusercontent.com/ethereum/consensus-specs/master/configs/mainnet.yaml

6,628바이트짜리 이 파일에서 줄 단위로 찾아보니 SECONDS_PER_SLOT 이라는 이름의 줄이 나오지 않았어요. 대신 두 줄이 나란히 있었어요. 앞줄이 주석이고 뒷줄이 값이에요.

# 12000 milliseconds

SLOT_DURATION_MS: 12000

같은 값을 클라이언트 배포용 설정 저장소에서도 열어 봤어요.

https://raw.githubusercontent.com/eth-clients/mainnet/main/metadata/config.yaml

5,874바이트짜리 이 파일에는 SECONDS_PER_SLOT 12 와 SLOT_DURATION_MS 12000 이 둘 다 들어 있었어요. 정리하면 이래요.

그래서 "규격에 SECONDS_PER_SLOT 이 12라고 적혀 있다"고만 쓰면 어느 문서를 열었느냐에 따라 어긋나요. 위 세 줄은 전부 2026년 8월 18일 오전에 직접 내려받아 확인한 것이고, 값 자체는 세 곳 모두 12초로 같아요. 이름만 갈려 있어요.

SLOTS_PER_EPOCH 도 자리가 따로예요. 위 두 설정 파일에는 이 이름의 줄이 없고, 프리셋 파일에 있어요.

https://raw.githubusercontent.com/ethereum/consensus-specs/master/presets/mainnet/phase0.yaml

2,342바이트짜리 이 파일에 SLOTS_PER_EPOCH 32 가 들어 있었어요. 설정 파일만 열고 "없다"고 적었으면 틀릴 뻔한 자리예요.

여기서 이 글이 계속 쓸 산식이 나와요. 32슬롯 곱하기 12초는 384초이고, 그게 1에폭이에요. 384초는 6분 24초예요. 하루로 늘리면 86,400초를 12초로 나눠 슬롯 7,200개, 에폭으로는 225개예요.

이 384초가 뒤에 나올 확정 이야기의 기본 단위예요. 확정은 블록 단위가 아니라 에폭 단위로 움직여요.

슬롯 번호는 블록이 아니라 시계에서 나와요

슬롯이 시계라는 말을 숫자로 확인해 볼게요. 기준 시각은 제네시스 주소에 있어요.

https://ethereum-beacon-api.publicnode.com/eth/v1/beacon/genesis

응답에 들어 있던 값 세 개예요.

genesis_time 이 1606824023이에요. 앞 절 라이브 설정 응답에 들어 있던 MIN_GENESIS_TIME 은 1606824000이었어요. 같은 값이 consensus-specs 의 configs/mainnet.yaml 에도 MIN_GENESIS_TIME 1606824000 으로 적혀 있어요. 두 값이 23초 다르다는 점이 중요해요.

이제 같은 순간에 현재 슬롯을 물어보고, 벽시계로 계산한 값과 맞춰 볼게요. 2026년 8월 18일 11시 21분 41초(한국 시각), 유닉스 시각 1787019701에 헤더 주소를 호출했어요.

genesis_time 을 쓴 계산은 노드가 알려준 슬롯과 정확히 같았고, MIN_GENESIS_TIME 을 쓴 계산은 2슬롯, 그러니까 24초 앞서 나왔어요. 23초 차이가 12초로 나뉘면서 2슬롯을 밀어 버린 거예요. 다만 이 어긋남이 늘 2슬롯인 것은 아니에요. 23초는 12초와 11초로 쪼개지니, 슬롯이 막 시작한 1초 동안에는 1슬롯 차이가 되고 나머지 11초 동안에는 2슬롯 차이가 돼요. 이 조회는 그 11초 쪽에 걸린 순간이었어요.

그래서 슬롯 번호를 직접 계산할 일이 있으면 반드시 genesis_time 을 쓰셔야 해요. 규격 파일에 적힌 MIN_GENESIS_TIME 은 이름 그대로 최소값이고, 실제 체인이 출발한 시각이 아니에요.

이 계산이 성립한다는 것 자체가 슬롯의 성격을 보여 줘요. 슬롯 번호를 구하는 데 블록 정보가 하나도 들어가지 않았어요. 필요한 것은 기준 시각과 지금 시각, 그리고 12라는 나눗수뿐이에요. 블록이 몇 개 나왔는지는 슬롯 번호에 영향을 주지 않아요.

블록 600개를 재 봤어요 — 12초 596회, 24초 3회

이제 실행계층으로 내려가서 블록 타임스탬프를 직접 재 볼게요. 공개 JSON-RPC 주소에 eth_getBlockByNumber 를 연속으로 던졌어요.

https://ethereum-rpc.publicnode.com

표본은 블록 25778139부터 25778738까지 600개예요. 앞뒤 타임스탬프는 이래요.

간격 599개를 값별로 세었더니 나온 값이 딱 두 가지였어요.

11초, 13초, 13.4초 같은 값은 이 599개 간격 안에서 한 번도 나오지 않았어요. 이 문장의 범위는 블록 25778139부터 25778738까지 600개, 구간 7,224초 안에서라는 뜻이에요. 다른 시간대나 다른 구간까지 그렇다는 말은 아니에요.

왜 이렇게 되는지는 타임스탬프를 제네시스 기준으로 나눠 보면 보여요. 표본 600개 전부에 대해, 타임스탬프에서 1606824023을 빼고 12로 나눈 나머지를 구했어요. 600블록 중 600블록이 나머지 0이었어요.

즉 모든 블록의 타임스탬프가 슬롯 경계에 정확히 붙어 있어요. 블록 타임스탬프는 제안자가 실제로 블록을 만든 순간을 적는 자리가 아니라, 그 블록이 실린 슬롯의 시작 시각을 적는 자리예요. 그러니 간격이 12의 배수 말고 다른 값으로 나올 여지가 없어요.

표본과 별도로, 480초 뒤에 다시 받아 본 블록 5개도 같은 성질을 보였어요. 이건 표본 구간이 아니라 나중에 따로 조회한 확인용 5개예요.

같은 표본에서 가스 한도도 같이 읽었어요. 흔히 도는 "이더리움 블록 가스 한도 3,000만"과는 자릿수가 달라요.

빠진 슬롯이 평균을 12초 위로 밀어 올려요

24초 간격이 3회 나왔다는 것은 그 앞 슬롯에 블록이 없었다는 뜻이에요. 슬롯은 12초씩 계속 올라갔는데 블록이 하나 건너뛴 자리예요. 이렇게 비어 있는 슬롯을 결슬롯이라고 불러요.

결슬롯 비율을 서로 다른 세 방법으로 재 봤어요.

첫째, 비컨 슬롯을 전수로 두드리기

슬롯 번호를 하나씩 헤더 주소 끝에 붙여서 물어보면, 블록이 없는 슬롯은 404를 돌려줘요. 슬롯 15015389부터 15016028까지 640개를 전부 두드렸어요.

404가 난 슬롯 번호와 그 시각이에요.

나머지는 슬롯 번호를 32로 나눈 값이라 0부터 세요. 나머지 25는 에폭의 26번째 칸이라는 뜻이에요.

200도 404도 아닌 응답은 640회 중 0회였어요. 즉 이 결과는 조회 실패를 센 것이 아니라 실제 응답을 센 것이에요.

둘째, 실행계층 600블록 표본으로 되짚기

앞 절의 표본을 결손 관점으로 다시 쓰면 이래요.

셋째, 24시간 통계로 교차확인

공개 통계 API로 하루치를 받아 봤어요.

https://api.blockchair.com/ethereum/stats

2026년 8월 18일 11시 33분 42초(한국 시각) 조회 결과예요.

세 방법이 0.319%에서 0.498% 사이로 모였어요. 표본이 다르고 구간 길이가 다르니 값도 다르게 나오는 것이 정상이에요. 다만 세 번째는 성격이 하나 더 달라요. 앞의 둘은 2026년 8월 18일 오전에 직접 훑은 구간이지만, blocks_24h 는 이름 그대로 조회 직전 24시간을 세는 이동 통계라 8월 17일 낮부터의 하루를 덮어요. 그러니 이 범위를 이더리움의 상시 결손율로 읽으면 안 되고, 덮는 창이 서로 다른 세 표본이 그랬다까지가 이 글이 말할 수 있는 범위예요.

결손율과 평균 간격은 같은 이야기예요

여기서 산수 하나가 딱 맞아떨어져요. 평균 간격은 경과 슬롯에 12초를 곱한 값을 생성 블록 수로 나눈 것이고, 이걸 정리하면 12초를 "1 빼기 결손율"로 나눈 값이 돼요. 세 표본 중 결손율과 평균 간격을 모두 가진 둘에 넣어 보면 이래요.

즉 평균 간격이 12초를 넘는 폭이 곧 결슬롯 비율이에요. 12.06초라는 값은 어떤 블록이 12초보다 늦게 나와서 생긴 것이 아니라, 몇 개가 아예 안 나와서 생긴 값이에요. 여기가 "12초마다 블록"이라는 어림값이 무너지는 자리예요. 블록 하나하나는 늦은 적이 없는데 평균은 12초 위에 있어요.

한 슬롯 12초 안에서 다시 갈리는 세 시각

슬롯 12초는 통짜 덩어리가 아니에요. 그 안에서 해야 할 일의 마감이 다시 나뉘어 있어요. 예전에는 이 마감이 초 단위 상수였는데, 지금 규격은 베이시스 포인트 비율로 적어요. 라이브 응답과 규격 파일에서 받은 값이에요.

주석은 configs/mainnet.yaml 원문에서 각 값 바로 윗줄에 붙어 있고, 값 자체는 라이브 설정 응답에도 같은 이름으로 들어 있어요. 초로 환산하면 약 2.0초, 약 4.0초, 약 8.0초예요. 12초를 2초 단위로 쪼개서 2초 지점과 4초 지점과 8초 지점에 마감을 걸어 둔 모양이에요.

같은 규격 파일에 SYNC_MESSAGE_DUE_BPS 3333 과 CONTRIBUTION_DUE_BPS 6667 도 같은 비율로 들어 있었어요. 초 단위 상수를 비율로 바꿔 둔 이유는 슬롯 길이가 바뀌어도 상대 위치가 유지되게 하려는 것으로 읽혀요. 슬롯이 12초에서 다른 값이 되면 이 마감들도 같은 비율로 따라 움직여요.

그래서 독자 입장에서 기억할 것은 하나예요. 12초는 블록이 나오기까지의 시간이 아니라, 이 슬롯에서 할 일을 다 끝내기까지의 예산이에요. 블록 제안과 증명 제출과 집계까지가 이 12초 안에서 순서대로 끝나야 해요.

확정까지 실제로 몇 초 걸리는지 열여덟 번 재 봤어요

블록이 나왔다고 되돌릴 수 없게 된 것은 아니에요. 프로토콜이 이제 못 되돌린다고 표시하는 지점이 따로 있고, 그게 최종성이에요. 상태 조회 주소로 물어볼 수 있어요.

https://ethereum-beacon-api.publicnode.com/eth/v1/beacon/states/head/finality_checkpoints

마지막 표본에서 받은 응답의 값이에요.

지연을 재는 방법은 이래요. 지금 head 슬롯이 몇 번인지 받고, 확정된 에폭에 32를 곱해 그 에폭의 첫 슬롯 번호를 구한 다음, 두 슬롯 번호의 차이에 12초를 곱해요. 두 구간에 나눠 표본을 떴어요. 첫 구간은 8회, 둘째 구간은 10회예요.

첫 구간 — 10시 37분 45초부터 10시 46분 16초까지 8회

이 구간은 조회를 시작한 시각과 끝낸 시각만 적어 두고 행마다의 조회 시각은 따로 기록하지 않았어요. 그래서 시각 열에는 그 자리에 채워 넣을 수 있는 값, 즉 head 슬롯이 시작한 시각을 적었어요. genesis_time 1606824023에 슬롯 번호 곱하기 12를 더해서 나온 값이라 누구나 다시 계산할 수 있어요. 조회는 그 시각과 12초 뒤 사이 어딘가에서 이뤄졌어요.

이 8회의 폭이 780초에서 1,032초, 그러니까 13분 0초에서 17분 12초예요. 이 글 제목에 넣은 값이 이 구간이에요.

둘째 구간 — 11시 26분 14초부터 11시 31분 31초까지 10회

둘째 구간의 폭은 768초에서 1,116초, 그러니까 12분 48초에서 18분 36초예요. 두 구간을 합치면 표본 18회의 폭이 768초에서 1,116초예요.

18회 전부에서 성립한 규칙 두 가지

표를 세로로 훑으면 규칙이 두 개 보여요. 18회 모두에서 성립했어요.

규칙 2를 확인해 볼게요. 둘째 구간에서 아홉 번째 표본은 head 슬롯이 15016352였고, 15016352를 32로 나누면 469261이 딱 떨어져요. 나머지가 0이니 지연은 64 더하기 0으로 64슬롯이고, 실제 값도 64슬롯이었어요. 바로 앞 표본은 head 15016349였고 32로 나눈 나머지가 29라서 64 더하기 29로 93슬롯이었어요. 실제 값도 93슬롯이었어요.

여기서 널리 도는 "약 12분 48초"의 정체가 나와요. 64슬롯에 12초를 곱하면 768초, 즉 12분 48초예요. 규칙 2가 말해 주듯 이 값은 head 가 에폭의 첫 슬롯에 있을 때만 나와요. 에폭은 32슬롯이니 그런 순간은 32번에 한 번이에요. 실제로 첫 구간 8회에서는 한 번도 나오지 않았고, 둘째 구간 10회 중 11시 30분 56초 표본 한 번에서만 나왔어요.

규칙 2를 끝까지 밀면 이론상 폭도 나와요. 나머지는 0에서 31 사이니 지연은 64슬롯에서 95슬롯, 초로는 768초에서 1,140초예요. 표본 18회에서 관측한 나머지는 0, 1, 3, 4, 7, 8, 9, 11, 13, 14, 15, 17, 20, 22, 23, 26, 29 로 32개 자리 중 17개였어요. 남은 15개 자리는 이번 표본에 들어오지 않았어요.

내 거래 하나 기준으로는 13분에서 19분 12초 사이예요

앞 절에서 잰 것은 지금 head 와 확정 지점 사이의 거리예요. 내가 방금 보낸 거래가 확정될 때까지의 대기 시간은 이것과 조금 달라요. 여기서부터는 실측이 아니라 위 규칙에서 끌어낸 산수예요.

확정 체크포인트는 어떤 에폭의 첫 슬롯을 가리켜요. 확정된 에폭이 F라면 F 이전 에폭들이 되돌릴 수 없게 굳은 상태예요. 그러니 내 거래가 에폭 E의 블록에 실렸다면, 확정된 에폭이 E 더하기 1 이상이 되어야 내 거래가 굳어요. 그리고 앞에서 본 규칙 1이 확정 에폭은 현재 에폭에서 2를 뺀 값이라고 알려 줬어요. 둘을 합치면 현재 에폭이 E 더하기 3에 도달하는 순간, 그러니까 슬롯 번호로는 E 더하기 3에 32를 곱한 자리에서 확정이 붙어요.

내 거래가 에폭 안의 몇 번째 슬롯에 실렸는지에 따라 대기가 이렇게 갈려요.

같은 12초짜리 슬롯인데도, 에폭 첫 칸에 실린 거래와 마지막 칸에 실린 거래가 6분 12초 차이가 나요. 어느 칸에 실릴지는 내가 고르는 것이 아니에요.

그래서 "이더리움 확정은 약 12.8분"이라는 안내는 하한이지 평균이 아니에요. 12분 48초는 앞 절에서 본 대로 head 관점의 최솟값이고, 내 거래 하나 관점에서는 아예 나올 수 없는 값이에요. 거래 관점의 최솟값은 65슬롯, 780초예요.

그리고 이 산수는 규칙 1이 계속 성립한다는 전제 위에 있어요. 표본 18회에서는 예외 없이 성립했지만, 증명 참여가 떨어지면 확정 에폭이 더 뒤처질 수 있어요. 그 경우까지 이번 표본으로 확인한 것은 아니에요. 코인을 보내고 거래소 잔고에 반영되기까지의 실무 대기 시간은 또 다른 층의 이야기예요. 사업자마다 요구하는 확인 횟수 기준이 달라서, 그 갈래는 코인 입금 얼마나 걸리나에 따로 정리해 두었어요.

슬롯이 6초가 되는 건 아직 규격이 아니에요

"이더리움 슬롯이 곧 6초가 된다"는 이야기를 보셨다면 그 출처는 EIP-7782예요. 원문을 그대로 내려받아 봤어요.

https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-7782.md

4,695바이트짜리 문서의 머리 부분에서 이 글에 필요한 줄만 뽑았어요. 뽑은 줄은 원문 표기 그대로이고, 사이에 있던 author 와 discussions-to 두 줄은 뺐어요.

eip: 7782

title: Reduce Block Latency

description: Reduce Ethereum's slot time from 12s to 6s to decrease latency by 50%, distribute bandwidth usage, and improve UX.

status: Draft

type: Standards Track

category: Core

created: 2024-10-05

requires: 7623, 7778

여기서 볼 것은 status 줄이에요. 값이 Draft, 그러니까 초안이에요. 이 글을 쓰는 2026년 8월 18일 기준으로 그렇습니다. 본문에는 이런 문장도 있어요.

Epochs shrink from 384 s (32 × 12 s) to 192 s (32 × 6 s)

앞에서 계산한 384초가 그대로 나오고, 그것이 192초로 줄어든다는 서술이에요.

그럼 언제 적용되는지는 어디를 봐야 할까요. 먼저 이 EIP 자신이 답을 미뤄 두었어요. Specification 절은 SLOT_SCHEDULE 이라는 설정 항목을 새로 두고 에폭마다 SECONDS_PER_SLOT 을 갈아 끼우자고 적은 다음, 바로 아래에 이 문장을 붙여요.

The parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.

위에 적은 값과 일정은 순전히 예시이고, 실제 값과 일정은 이 규격이 다룰 범위 밖이라는 뜻이에요. 즉 이 문서만으로는 적용 시점을 알 수 없어요.

그래서 다음 업그레이드에 무엇이 실리는지 적어 둔 메타 문서를 따로 열었어요.

https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-7773.md

5,753바이트짜리 이 문서가 EIP-7773, 제목은 Hardfork Meta - Glamsterdam 이에요. 안에는 목록이 여러 개 있는데, EIP-7782 가 놓인 자리가 실릴 목록이 아니었어요.

### Declined for Inclusion

* [EIP-7782](./eip-7782.md): Reduce Block Latency

같은 문서의 실릴 목록(EIPs Scheduled for Inclusion)에는 EIP-7732, 그러니까 Enshrined Proposer-Builder Separation 이 올라 있어요. 합의계층 규격 저장소의 specs/gloas/beacon-chain.md 를 내려받아 세어 보니 7732 라는 번호가 59번 나오고 7782 는 0번 나왔어요. Gloas 는 이 EIP-7732 를 담는 합의계층 포크이지, 6초를 담는 포크가 아니에요.

정리하면 슬롯 6초는 초안 상태이면서, 지금 예정된 업그레이드에서는 빠지는 쪽으로 분류돼 있어요. 포크 이름과 6초를 이어 붙인 설명을 보시면 그 자리를 한 번 의심해 보셔야 해요.

한편 아직 시각이 정해지지 않은 포크가 설정 파일에 어떻게 적히는지는 그 자체로 읽는 법이 돼요.

18446744073709551615는 부호 없는 64비트 정수의 최댓값, 그러니까 2의 64제곱에서 1을 뺀 값이에요. 아직 정하지 않았다는 뜻을 숫자로 적는 관례적인 방식이에요. GLOAS_FORK_EPOCH 의 이 값은 라이브 설정 응답과 configs/mainnet.yaml 양쪽에서 똑같이 나왔어요.

대조가 되는 것이 Fulu예요. 411392에는 실제 날짜 주석이 붙어 있고, 이 글을 쓰는 시점의 에폭은 469261 근처라 이미 지났어요. 주석에 날짜가 붙어 있으면 지난 포크이고, 2의 64제곱에서 1을 뺀 값이면 미정이라고 눈으로 갈라 읽을 수 있어요.

한 가지 더 흥미로운 자리가 있어요. configs/mainnet.yaml 에는 Gloas 에서 쓸 값이 이미 이름을 달고 들어와 있었어요.

값이 파일에 적혀 있는 것과 그 값이 지금 돌고 있는 것은 다른 이야기예요. 위 네 줄은 파일에 존재하지만 GLOAS_FORK_EPOCH 가 미정인 이상 적용 시점은 정해지지 않았어요. 그리고 이 네 줄은 6초와 관계가 없어요. 주석이 전부 SLOT_DURATION_MS 대비 비율로 적혀 있고, 같은 파일의 SLOT_DURATION_MS 는 12000 그대로예요. 슬롯 길이를 바꾸는 값이 아니라 12초 안에서 마감 위치만 옮기는 값이에요.

그래서 이 글은 6초가 된다고 적지 않고, 6초로 줄이자는 초안이 status Draft 상태로 있고, 다음 업그레이드 목록에서는 빠지는 쪽으로 분류돼 있다까지만 적어요.

직접 재보는 순서 — 공개 엔드포인트 두 개면 돼요

지금까지 쓴 값은 전부 키 없이 열리는 공개 주소에서 나왔어요. 순서만 옮겨 둘게요. 값은 조회하는 순간마다 달라지니, 어떤 값을 적든 조회 시각을 같이 적어 두시는 편이 나중에 도움이 돼요.

비컨 쪽 기본 주소는 https://ethereum-beacon-api.publicnode.com 이고 실행계층 쪽은 https://ethereum-rpc.publicnode.com 이에요. 앞의 셋은 브라우저 주소창에 그대로 붙여 넣어도 응답이 떠요.

한 가지 주의할 것은 head 가 벽시계보다 1슬롯 뒤에 있을 수 있다는 점이에요. 실제로 둘째 구간 표본 10회 중 5회에서, 벽시계로 계산한 슬롯 번호가 노드가 알려준 head 보다 1 컸어요. 슬롯이 막 시작해서 그 슬롯의 블록이 아직 도착하지 않은 순간에 물어보면 이렇게 나와요. 이걸 오차로 보고 계산을 고치실 필요는 없어요.

또 하나, 과거 시점의 확정 상태는 이 노드로는 되짚을 수 없었어요. 위 세 번째 주소에서 head 자리에 지난 슬롯 번호를 넣어 여덟 번 호출해 봤는데 전부 HTTP 403이 돌아왔어요. 그래서 첫 구간 8회 표본은 그 시각에 받아 둔 응답으로만 남아 있고, 이 글을 읽는 시점에 같은 값을 다시 뽑을 수는 없어요. 둘째 구간의 방식, 그러니까 지금 head 로 반복해서 조회하는 방식은 누구나 재현할 수 있어요.

블록 안에서 수수료가 어떻게 매겨지고 데이터가 어떻게 실리는지는 간격과는 다른 층의 이야기예요. 그쪽은 블롭 수수료와 EIP-4844에서 따로 다뤘어요. 그리고 확정을 기다리지 않고 결과를 앞당기려는 구조가 왜 나왔는지는 레이어1과 레이어2의 차이에 정리해 두었어요.

이 글에서 확인하지 못한 것

범위를 밝혀 둘게요.

• 결슬롯 3건의 원인. 15015929, 15015949, 15015998 세 슬롯이 왜 비었는지는 헤더 주소의 404 응답만으로는 가를 수 없어요. 제안자가 꺼져 있었는지, 블록이 늦게 퍼져서 채택되지 못했는지, 다른 사정인지 이번 조회로는 구분하지 못했어요.
• 결손율의 상시값. 0.319%에서 0.498%라는 폭은 덮는 창이 서로 다른 표본 셋에서 나온 값이에요. 앞의 둘은 2026년 8월 18일 오전 구간이고, 24시간 통계는 조회 직전 하루를 덮어요. 그 하루가 정확히 어느 시각에서 시작하는지는 API 문서에 정의가 적혀 있지 않아 확인하지 못했어요. 이 폭을 이더리움의 평상시 값으로 옮겨 적으면 안 돼요.
• 확정 지연 분포의 양끝. 표본 18회에서 관측한 에폭 안 위치는 32개 자리 중 17개였어요. 이론상 최댓값인 95슬롯, 1,140초에 해당하는 자리는 이번 표본에 들어오지 않았어요.
• 증명 참여가 떨어질 때의 확정. 확정 에폭이 현재 에폭에서 2를 뺀 값이라는 규칙은 표본 18회 전부에서 성립했지만, 참여율이 낮아질 때도 그런지는 이번에 확인하지 못했어요. 거래 기준 대기 시간 산수는 이 규칙을 전제로 한 것이에요.
• 노드 한 곳만 봤다는 점. 비컨과 실행계층 모두 publicnode 한 곳의 공개 주소만 썼어요. 다른 노드가 보는 head 와 1슬롯 차이가 날 수 있고, 실제로 둘째 구간 10회 중 5회에서 벽시계 계산과 1슬롯 차이가 있었어요.
• PAYLOAD_DUE_BPS 의 두 값. 같은 이름이 라이브 설정 응답에서는 7500이었고 configs/mainnet.yaml 에서는 5000이었어요. 어느 쪽이 왜 다른지는 이번에 가르지 못해서 본문 계산에는 쓰지 않았어요.
• 과거 시점의 확정 상태. 지난 슬롯을 지정한 상태 조회는 이 노드에서 403이 돌아왔어요. 다른 노드나 보관용 노드에서는 열리는지 이번에 확인하지 못했어요.

오해와 원문을 한 표로

자주 묻는 질문 (FAQ)

Q. 블록이 안 나온 슬롯에 들어갈 예정이던 거래는 어떻게 되나요?

취소되는 것이 아니라 다음 슬롯으로 밀려요. 슬롯이 비었다는 것은 그 12초 동안 블록이 만들어지지 않았다는 뜻이고, 대기 중이던 거래는 그대로 남아 있다가 다음 블록에 실릴 기회를 다시 얻어요. 이번 표본에서 24초 간격이 3회 나온 자리가 바로 그런 경우예요. 앞 슬롯이 비어서 다음 블록이 24초 뒤에 나온 것이지, 그 사이에 거래가 사라진 것이 아니에요.

Q. 거래소가 요구하는 확인 횟수와 최종성은 같은 건가요?

다른 층의 이야기예요. 최종성은 프로토콜이 정한 값이라 위에서 잰 것처럼 초 단위로 계산이 나와요. 반면 확인 횟수는 각 사업자가 자기 기준으로 정하는 정책이라, 같은 코인이라도 사업자마다 다를 수 있어요. 그러니 프로토콜이 확정했다는 것과 내 계정에 반영됐다는 것은 같은 순간이 아니에요.

Q. 왜 13초나 14초 같은 간격은 안 보이나요?

블록 타임스탬프가 그 블록이 실린 슬롯의 시작 시각으로 붙기 때문이에요. 실제로 표본 600블록 전부에서, 타임스탬프에서 1606824023을 빼고 12로 나눈 나머지가 0이었어요. 슬롯 경계에 정확히 붙어 있으니 두 블록의 타임스탬프 차이는 항상 12의 배수로만 나와요. 12초가 아닌 값이 나왔다면 그건 늦어진 것이 아니라 중간에 슬롯이 비었다는 뜻이에요.

Q. 슬롯 번호를 직접 계산하려면 어떤 값을 써야 하나요?

제네시스 조회가 돌려주는 genesis_time, 즉 1606824023을 쓰셔야 해요. 규격 파일에 있는 MIN_GENESIS_TIME 1606824000을 쓰면 23초 차이가 12초로 나뉘면서 대개 2슬롯, 24초 앞선 값이 나와요. 슬롯이 막 시작한 1초 동안에만 1슬롯 차이가 되고, 나머지 11초 동안에는 2슬롯 차이예요. 실제로 같은 순간에 두 값으로 계산해 보니 15016306과 15016308로 갈렸고, 노드가 알려준 값은 앞쪽이었어요.

Q. 확정을 기다리지 않고 거래 결과를 믿어도 되나요?

이 글은 그 판단을 대신하지 않아요. 다만 숫자로 정리하면 이래요. 블록에 실리는 데는 평균 12.06초가 걸렸고, 프로토콜이 되돌릴 수 없다고 표시하기까지는 표본 18회에서 768초에서 1,116초가 걸렸어요. 그 사이 구간은 블록에는 실렸지만 아직 확정 표시가 붙지 않은 상태예요. 얼마나 기다릴지는 금액과 용도에 따라 각자 정할 문제예요.

Q. 결슬롯이 0.5% 가까이 나오면 문제가 있는 건가요?

이 글은 그 판정에 필요한 기준선을 갖고 있지 않아요. 확인한 것은 세 표본에서 0.319%와 0.469%와 0.498%가 나왔다는 사실, 그리고 그 비율이 평균 간격을 12초 위로 밀어 올리는 크기와 정확히 맞아떨어진다는 점까지예요. 평상시 값이 얼마인지, 어느 수준부터 이상 신호인지는 훨씬 긴 구간을 재야 답이 나와요.

정리

• 12초가 붙는 자리는 블록이 아니라 슬롯이에요. 슬롯은 genesis_time 1606824023에서 12초씩 세는 시계라서 블록이 나오든 안 나오든 번호가 올라가요.
• 그래서 블록 간격은 12초의 배수로만 찍혀요. 표본 600블록(25778139부터 25778738까지, 7,224초)에서 나온 값은 12초 596회와 24초 3회 둘뿐이었고 평균은 12.0601초였어요.
• 평균이 12초를 넘는 폭은 곧 결슬롯 비율이에요. 세 표본에서 결손율은 0.319%와 0.469%와 0.498%였고, 12를 1 빼기 결손율로 나눈 값이 실제 평균 간격과 그대로 맞았어요.
• 슬롯 12초 안에도 마감이 나뉘어 있어요. 1667과 3333과 6667 베이시스 포인트가 각각 약 2.0초, 약 4.0초, 약 8.0초예요.
• 확정 지연은 표본 18회에서 768초에서 1,116초였고, 18회 전부에서 지연 슬롯 수가 64에 head 슬롯을 32로 나눈 나머지를 더한 값이었어요.
• 내 거래 하나 기준으로 옮기면 780초에서 1,152초, 그러니까 13분 0초에서 19분 12초예요. 이건 위 규칙에서 끌어낸 산수이지 직접 잰 값이 아니에요.
• 슬롯 6초는 아직 규격이 아니에요. EIP-7782 는 status 값이 Draft 이고, 다음 업그레이드 메타 문서(EIP-7773)의 Declined for Inclusion 목록에 올라 있어요. Gloas 에 실리는 변경이 아니에요.

조회는 2026년 8월 18일 오전 8시 37분부터 11시 33분 사이(한국 시각)에 했어요. 다만 표본마다 덮는 구간이 달라요. 실행계층 600블록은 오전 8시 37분 47초부터 10시 38분 11초, 비컨 슬롯 640개는 오전 8시 18분 11초부터 10시 25분 59초, 확정 지연 18회는 오전 10시 37분 45초부터 11시 31분 31초 구간이고, 24시간 통계만 조회 직전 하루를 덮어요. 다른 시각에 다시 재면 다르게 나와요. 그래서 이 글의 목적은 특정 숫자를 외우게 하는 것이 아니라, 어디를 열어서 어떻게 계산하면 지금 값이 나오는지를 남기는 것이에요.

이 글은 공개 API 응답과 규격 저장소 원문을 직접 내려받아 정리한 정보 제공 글이며 매매를 권유하는 글이 아니에요. 특정 자산을 사거나 팔라는 뜻으로 읽지 말아 주세요. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 거래와 보유의 판단과 책임은 본인에게 있어요.

같은 실행계층 응답에서 블롭 쪽 칸만 따로 세어 본 기록도 있어요. 연속 30블록에서 블롭이 142개였고 블록당 0개에서 11개까지 흔들렸는데 가스 사용률과는 함께 움직이지 않았어요.

확인한 자료: 라이브 비컨 API 의 설정 조회 응답(6,831바이트, 본문 키 183개), 제네시스 조회, 헤더 head 조회, 슬롯 지정 헤더 조회 640회, 상태 조회의 확정 체크포인트 18회. 이더리움 실행계층 공개 JSON-RPC 의 eth_getBlockByNumber 605회(표본 600블록과 확인용 5블록). ethereum/consensus-specs 저장소의 configs/mainnet.yaml(6,628바이트)과 presets/mainnet/phase0.yaml(2,342바이트), eth-clients/mainnet 저장소의 metadata/config.yaml(5,874바이트), ethereum/EIPs 저장소의 EIPS/eip-7782.md(4,695바이트)와 EIPS/eip-7773.md(5,753바이트), ethereum/consensus-specs 저장소의 specs/gloas/beacon-chain.md. Blockchair 공개 통계 API 의 ethereum/stats. 모두 2026년 8월 18일 오전과 낮에 직접 내려받아 확인했어요.