EIP-8252 실행 레이어 재구성 상태 보존 기간 (Execution-Layer Reorg State Retention Window)
콜 결정 없음 · 네트워크·노드 · 원문 상태 Draft · 2026-04-24 작성
실행 레이어 클라이언트가 최근 262,144블록(약 36.4일) 동안의 모든 블록 상태를 다시 만들 수 있게 보관하도록 정하는 정보성 제안입니다. 깊은 체인 재구성이 와도 새로 동기화하지 않고 처리하기 위해서입니다.
왜 필요한가
이더리움 노드는 실행 레이어(Execution Layer, EL)와 합의 레이어(Consensus Layer, CL)로 나뉩니다. 실행 레이어는 거래를 실제로 실행하고 계정 잔액 같은 상태(state)를 들고 있습니다. 그런데 지금은 실행 레이어가 과거 상태를 얼마나 오래 보관해야 하는지 프로토콜 차원의 최소 기준이 없습니다. 오래된 블록 데이터는 히스토리 만료 규칙이 다루지만 상태를 언제 지울지는 클라이언트마다 알아서 정합니다. 노드가 따르던 체인이 다른 가지로 바뀌는 재구성(reorg)이 일어날 때 문제가 생깁니다. 새 가지를 검증하려면 두 가지가 갈라진 지점의 상태에서 다시 실행해야 하는데, 그 상태를 이미 지웠다면 노드는 처음부터 다시 동기화해야 합니다. 갈라진 지점은 마지막으로 최종 확정된 블록보다 깊을 수 없습니다. 최종 확정이 멈추는 기간은 합의 레이어의 비활성 누수(inactivity leak)가 상한을 정합니다. 이 제안은 그 상한에 맞춘 보존 기간 하나를 정해 이 빈틈을 메웁니다.
무엇이 바뀌나
지금
- 실행 레이어 클라이언트가 과거 상태를 얼마나 보관할지 프로토콜 기준이 없습니다
- 상태 정리(pruning) 정책은 클라이언트마다 다릅니다
- 깊은 재구성이 오면 갈라진 지점의 상태가 없어 새로 동기화해야 할 수 있습니다
EIP-8252 이후
- 최근 262,144블록(약 36.4일)의 상태는 모든 클라이언트가 복원할 수 있어야 합니다
- 보관 방식(스냅샷, 역방향 diff, 메모리, 디스크)은 클라이언트가 고릅니다
- 이 기간 안의 재구성은 노드가 혼자서 처리합니다
- 기간보다 깊은 재구성은 범위 밖이며 신뢰 체크포인트에서 새로 동기화할 수 있습니다
누구에게 영향이 있나
- 클라이언트 팀: 상태 정리가 이 기간보다 공격적인 클라이언트는 역방향 diff 같은 방식으로 추가 상태를 보관해야 합니다.
- 노드 운영자: 정리 정책이 공격적이던 클라이언트를 쓰면 보관하는 상태가 늘어납니다. 대신 기간 안의 깊은 재구성은 재동기화 없이 복구합니다.
- 검증자: 최종성이 오래 멈춘 뒤 다시 확정될 때, 노드가 새 가지를 로컬 상태만으로 검증할 수 있습니다.
- 아카이브 노드: 기간보다 오래된 상태는 지금처럼 아카이브 노드가 제공합니다.
심층 설명
보존 기간 상수와 요구 사항
REORG_RETENTION_WINDOW = 262144 블록입니다. 8192 에포크 × 32 슬롯이며 약 36.4일에 해당합니다. 블록 번호 n이 head - REORG_RETENTION_WINDOW ≤ n ≤ head 범위에 있는 모든 정규(canonical) 블록에 대해, EL 클라이언트는 그 블록의 실행 후 상태(post-state)를 동기화 없이 재구성할 수 있어야 합니다(MUST). 표현 방식은 전체 스냅샷, 역방향 상태 diff, 그 밖의 동등한 방식을 모두 허용하고 메모리에 두든 디스크에 두든 상관없습니다. 기간보다 오래된 상태는 버려도 됩니다(MAY). 블록 헤더, 바디, 영수증 보관은 이 제안이 다루지 않으며 히스토리 만료 규칙을 따릅니다.
왜 블록 데이터가 아니라 상태인가
깊은 재구성은 공통 조상까지 상태를 되돌린 뒤 새 가지를 앞으로 다시 실행하는 방식으로 처리합니다. 새 가지의 블록은 엔진 API나 P2P로 도착하므로, 로컬 노드가 밀려난 가지의 헤더, 바디, 영수증을 저장해 둘 필요는 없습니다. 조상 시점의 상태를 재구성하는 능력은 꼭 필요합니다. 그래서 상태 보존이 재구성 복구의 핵심 요구 사항이 됩니다. 블록 데이터 보존은 네트워크에 데이터를 제공하는 별개의 문제이고 히스토리 만료 규칙이 다룹니다.
상수를 정한 근거: 비활성 누수 수식
머지 이후 비활성 누수 매개변수는 INACTIVITY_SCORE_BIAS = 4, INACTIVITY_PENALTY_QUOTIENT_BELLATRIX = 2^24입니다. 계속 오프라인인 검증자의 유효 잔액은 balance(N)/balance(0) ≈ exp(-N²/(2Q))로 줄어듭니다. 처음 오프라인 지분 비율이 f일 때 최종성이 돌아오려면 오프라인 비중이 1/3 아래로 떨어져야 합니다. 이때 필요한 에포크 수는 N > sqrt(2 · Q · ln(2f/(1-f)))입니다(하루 225 에포크 기준). 원문 표에 따르면 f = 0.50이면 약 4,822 에포크(약 21.4일), 0.60이면 약 6,072 에포크(약 27.0일), 2/3이면 약 6,820 에포크(약 30.3일), 0.75면 약 7,754 에포크(약 34.5일)입니다. 누수는 오프라인 지분만 깎고 온라인 지분은 그대로 두므로, 처음 오프라인 비중이 클수록 온라인 쪽이 2/3 초다수를 되찾기까지 더 큰 비율로 줄여야 하고 시간이 더 걸립니다. ln(2f/(1-f)) 항은 f가 1에 가까워질수록 발산합니다.
8192 에포크가 덮는 범위
8192 에포크(2^13, 약 36.4일)는 ln(2f/(1-f)) = 2에 해당하며 처음 오프라인 지분이 f ≈ 0.787(약 79%)인 경우까지 누수로 인한 비최종성 기간을 덮습니다. 그보다 큰 비율에서는 로컬 상태 대신 외부 동기화에 기댈 것으로 예상합니다. 이 값을 8192 × 32 = 262,144 블록(2^18)으로 적으면, EL 클라이언트는 최종 확정된 비콘 상태에 의존하지 않고 블록 단위 값 하나만 보면 됩니다.
재구성 범위와 기간 밖 상태
REORG_RETENTION_WINDOW보다 얕은 재구성은 로컬에서 해결합니다. 기간보다 깊은 재구성은 이 제안의 범위 밖이며 복구에 신뢰할 수 있는 체크포인트에서 새로 동기화하는 과정이 필요할 수 있습니다. 보안 고려 사항에서도 기간보다 오래된 상태의 재구성은 범위 밖이고 아카이브 노드가 제공한다고 밝힙니다. 즉 이 제안은 재구성 복구에 필요한 최소 상태만 정하고 그 밖의 과거 상태 제공은 기존 역할 분담을 그대로 둡니다.
하위 호환성
REORG_RETENTION_WINDOW보다 공격적으로 상태를 정리하던 EL 클라이언트는 이 제안을 따르려면 추가 상태를 보관해야 합니다. 원문은 보통 역방향 diff 형태가 될 것이라고 적습니다. 블록 헤더, 바디, 영수증 보관 정책은 이 제안의 영향을 받지 않고 히스토리 만료 규칙을 그대로 따릅니다. 제안 유형은 Informational로 제출됐습니다.
현재 상태와 콜 논의
원문 상태는 Draft(초안)입니다. 상수 값, 요구 수준(MUST), 적용 범위 모두 아직 바뀔 수 있습니다. 저자는 Toni Wahrstätter, Kevaundray Wedderburn, Jacek Sieka이며 2026-04-24에 만들어졌고 논의는 Ethereum Magicians 포럼에서 이어집니다. 코어 개발자 콜에서는 09.07 ACDT #95와 10.19 ACDT #101에서 논의됐으나 두 번 모두 결정은 없었습니다. 특정 포크에 포함하기로 한 결정도 아직 없습니다.