EIP-8383 합의층 블록 보관 기간 축소 (Reduce CL Block Retention Window)

Hegota 포함 검토 (CFI) · 네트워크·노드 · 원문 상태 Draft · 2026-08-17 작성

합의층 노드가 동료 노드에 제공해야 하는 옛 비콘 블록의 최소 보관 기간을 33,024 에폭에서 8,192 에폭(약 36일)으로 줄입니다. 하드포크 없이 설정값 하나를 바꿉니다.

왜 필요한가

합의층(Consensus Layer, CL) 노드는 최근에 서명된 비콘 블록을 보관하고 다른 노드가 요청하면 내줍니다. 새로 합류하는 노드는 신뢰하는 체크포인트에서 출발해 현재 헤드까지 동기화하는데, 그 뒤에도 규칙상 정해진 기간만큼의 옛 블록을 뒤로 내려받아 채워야 합니다. 지금 이 기간은 33,024 에폭이라서 체크포인트가 몇 시간 전 것이어도 거의 다섯 달치 블록을 내려받아야 합니다. 이 숫자는 약한 주관성(weak subjectivity) 기간을 최악의 경우(MAX_SAFETY_DECAY = 100)로 계산한 값입니다. 그런데 실제 체크포인트 동기화에는 SAFETY_DECAY = 10을 쓰고 지금 메인넷 설정에서 그 기준은 3,532 에폭입니다. 실제 안전 정책이 요구하는 것보다 훨씬 긴 히스토리를 보관하고 있는 셈입니다. 체크포인트가 정책상 허용 기간보다 오래됐다면 어차피 더 새 체크포인트가 필요하므로, 그 뒤의 옛 블록을 더 갖고 있어도 안전해지지 않습니다. 보관 기간을 줄이면 동기화 대역폭, 디스크 사용량, 디스크 쓰기, 채우기 시간, 동료 노드의 업로드 대역폭이 모두 줄어듭니다.

무엇이 바뀌나

지금

EIP-8383 이후

누구에게 영향이 있나

심층 설명

바뀌는 값: MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192

메인넷 블록 제공 설정을 MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192로 둡니다. 그리고 compute_min_epochs_for_block_requests() 함수를 라이브 합의 상태에서 값을 계산하는 대신 Uint64(MIN_EPOCHS_FOR_BLOCK_REQUESTS)를 그대로 돌려주도록 바꿉니다. 이 함수를 쓰는 기존 블록 제공 요건과 뒤채우기 요건은 모두 새 값으로 그대로 적용됩니다. 기간으로 환산하면 8,192 에폭 × 32 슬롯 × 12초 = 3,145,728초, 약 36.4일입니다. 기존 값 33,024 에폭은 거의 다섯 달에 해당합니다.

왜 8,192 에폭인가

기존 33,024 에폭은 약한 주관성 기간을 최악의 경우로 계산한 값으로, MAX_SAFETY_DECAY = 100을 씁니다. 그런데 체크포인트 동기화 정책은 SAFETY_DECAY = 10을 쓰고 현재 메인넷의 churn 파라미터에서는 약한 주관성 기준이 3,532 에폭입니다. 프로토콜이 이 기준에 특정 배수를 요구하지는 않습니다. 3,532보다 큰 가장 작은 2의 거듭제곱은 4,096인데, 이 EIP는 그 다음 2의 거듭제곱인 8,192를 골랐습니다. 33,024에서 처음 줄이는 단계이므로 보수적으로 잡은 값입니다.

라이브 상태 대신 고정 설정값을 쓰는 이유

약한 주관성 기간은 합의 상태에 따라 달라집니다. 반면 고정된 설정값을 쓰면 클라이언트는 가지치기(pruning), 뒤채우기, 제공 경계를 예측할 수 있습니다. 네트워킹 요건을 라이브 합의 상태에서 매번 유도할 필요가 없어집니다. 또 체크포인트가 정책상 허용 기간보다 오래됐다면 그 노드는 어차피 더 새 체크포인트가 필요하므로, 옛 체크포인트 이후의 블록을 더 갖고 있어도 안전해지지 않습니다. 이 점이 보관 기간을 약한 주관성 기준에 가깝게 줄여도 되는 근거입니다.

체크포인트 동기화 뒤의 뒤채우기 부담

체크포인트 동기화 노드는 신뢰하는 확정 상태에서 출발해 앞으로 동기화하며 헤드에 도달합니다. 그런데 블록 제공 요건을 맞추려면 MIN_EPOCHS_FOR_BLOCK_REQUESTS로 정해진 구간도 뒤로 채워야 합니다. 앞으로 동기화는 현재 합의 관점을 세우는 일이고 뒤채우기는 주로 동료 노드에 히스토리를 제공하기 위한 일입니다. 그래서 몇 시간 전 체크포인트로 시작해도 거의 다섯 달치 블록을 내려받게 됩니다. 창을 줄이면 동기화 대역폭, 디스크 사용량, 디스크 쓰기, 뒤채우기 시간, 동료 노드 업로드 대역폭이 줄어듭니다. 또 일부 합의 클라이언트는 실행층을 써서 옛 실행 페이로드를 재구성하므로, 합의층이 보관하는 블록 수는 히스토리를 만료하는 실행층이 보관해야 할 페이로드 수의 하한으로 쓸 수 있습니다.

장기간 비확정 상황에 대한 권고

몇 달치 옛 블록을 보관하는 이유 가운데 하나는 체인이 오랫동안 확정(finality)되지 않는 상황에 대비하는 것입니다. 원문은 이것이 SAFETY_DECAY 상수를 약한 주관성 기간과 히스토리 제공용 블록 두 용도에 겹쳐 쓰는 셈이라고 지적합니다. 그래서 장기간 비확정 상황에서는 실행 클라이언트와 합의 클라이언트가 확정되지 않은 블록을 모두 보관하도록 권고합니다. 그러면 확정 여부와 약한 주관성 기간의 관계가 분리되어 블록 보관 기간을 비확정 대비용으로 길게 잡을 필요가 없어집니다.

호환성과 혼합 배포, 테스트 케이스

이 EIP는 하드포크가 필요 없습니다. 클라이언트는 더 긴 히스토리를 계속 보관해도 됩니다. 다만 동료 노드 간 제공 기대치는 달라져서 새 값과 옛 값이 섞여 돌아가는 기간에는 옛 클라이언트가 8,192에서 33,024 에폭 사이의 블록을 요청할 수 있습니다. 원문은 이미 히스토리를 제공하지 않는 노드가 있고(기본값으로 꺼 둔 클라이언트), 그래서 네트워크에 영향이 없을 것이라고 봅니다. 클라이언트 테스트는 MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192로 다음을 다룰 수 있습니다(MAY). current_epoch = 500_000일 때 491_808부터 500_000까지의 서명된 블록을 반드시 제공해야 하고(MUST), 491_807 에폭 요청에는 ResourceUnavailable을 돌려줄 수 있으며(MAY), 요청한 쪽은 이 응답을 이유로 상대를 벌점 처리하면 안 됩니다(MUST NOT).

보안: 약한 주관성 불변식

이 EIP는 SAFETY_DECAY나 체크포인트 신선도 계산을 바꾸지 않습니다. 부트스트랩에 쓸 블록이 보장되는 창을 좁힐 뿐입니다. 안전을 위해 8,192 에폭이 현재 메인넷 정책상 최대 약한 주관성 기간보다 커야 한다는 조건이 붙습니다. 합의 명세 테스트는 설정된 메인넷 정책에서 최대 약한 주관성 기간이 MIN_EPOCHS_FOR_BLOCK_REQUESTS보다 작다는 것을 반드시 확인해야 하며(MUST), 이때 현재의 약한 주관성 계산식을 써야 합니다. 다른 프로토콜 변경이 약한 주관성 기준을 바꾼다면 활성화 전에 이 불변식이 유지되는지 확인해야 합니다.

원문 상태와 포크 논의

원문 상태는 Draft(초안)이므로 값이나 세부 명세가 아직 바뀔 수 있습니다. 코어 개발자 콜 기록을 보면 08.20 ACDC #185에서 EIP-8383이 헤고타(Hegota) 포함 제안(PFI)으로 접수됐습니다. 09.21 ACDT #97에서는 글램스테르담(Glamsterdam)의 CL 블록 제공 창과 BAL 보관 기간을 그 콜에서 정하지 않고 비동기 논의와 ACDE로 넘겼습니다. 33,024 에폭 유지, 약 14,299로 축소, 8,192로 축소(EIP-8383, 헤고타 후보라 범위 밖) 세 안이 올라왔고 테스트넷 출시는 막지 않기로 했습니다. 09.24 ACDE #246과 10.01 ACDC #188에서는 논의만 있었고 결정은 없었습니다. 10.29 ACDC #190에서 EIP-8383이 헤고타 CFI(포함 고려)로 올라갔습니다.

EIP 원문 · ← EIPs