ACDC #185 · EIP-7610 글램스테르담 제외

AllCoreDevs - Consensus #185 · 2026-08-20

성능 부담만 주던 EIP를 빼고 EIP-8253이 대신 푼다

EIP-7610이 글램스테르담(Glamsterdam)에서 공식 취소됐고, 이를 대체하는 EIP-8253을 포함해 4개 EIP가 다음 포크 헤고타(Hegota)의 후보로 접수됐다. 세폴리아 9월 28일, 후디 10월 26일이라는 테스트넷 포크 날짜도 처음 제안됐다.

왜 중요한가

테스트넷 포크 날짜가 제안되면서 글램스테르담의 메인넷 배포가 가시권에 들어왔다. 댑 중심 테스트넷인 세폴리아가 먼저 포크되면 애플리케이션 개발자들이 가스 재산정(repricing) 변경을 미리 시험할 수 있다.

EIP-7610 제외: EIP-7610을 글램스테르담에서 연기가 아니라 완전히 취소했다. 헤고타의 EIP-8253이 근본 원인을 없애 이 규칙 자체가 필요 없어지기 때문이다.
비최종화 데브넷: 비최종화(non-finality) 데브넷을 다다음 주에 띄우기로 했다. 그 전에 모든 클라이언트가 코드를 본(trunk) 브랜치에 올려야 한다.
EIP-8333 PFI: EIP-8333이 헤고타 포함 제안(PFI)으로 접수됐다. 체크포인트 계산의 오프바이원 오류를 고치는 제안이 공식 후보가 됐다는 뜻이다.
EIP-8379 PFI: EIP-8379가 헤고타 포함 제안으로 접수됐다. CL을 동기화의 단일 기준으로 만드는 엔진 API 확장이 후보가 됐다는 뜻이다.
EIP-8383 PFI: EIP-8383이 헤고타 포함 제안으로 접수됐다. CL 블록 보존 기간을 절반으로 줄이자는 제안이 후보로 유지된다는 뜻이다.
EIP-8253 PFI: EIP-7610을 대체하는 EIP-8253이 헤고타 포함 제안으로 접수됐다. 문제가 되는 계정 유형이 상태 트리에 아예 존재할 수 없게 만든다.

콜 6시간 전 데브넷 8에서 글로아스(Gloas) 포크가 활성화되자 약 16,000건의 빌더 예치금(builder deposits) 처리에서 여러 클라이언트가 캐시 문제로 멈췄고, 메인넷에서도 같은 설계가 안전한지를 두고 논쟁이 붙었다.

CL을 동기화의 단일 기준으로 만드는 엔진 API(Engine API) 확장을 Nimbus 쪽에서 헤고타 후보로 제안하면서, 다른 네트워킹 EIP처럼 선택 구현으로 둘 수 있는지가 쟁점이 됐다.

결론: PFI 결정 00:54:23

글램스테르담의 EIP-8061 도입으로 보존 기간의 근거 상수를 절반으로 줄여야 한다는 제안(EIP-8383)이 나왔지만, 애초에 왜 바꿔야 하는지부터 의견이 갈렸다.

결론: PFI 결정 00:54:23

모든 클라이언트 팀이 9월 중순까지 헤고타 후보 EIP를 S/A/B/D 티어로 나눠 공개하기로 하면서, 티어 라벨을 어떻게 읽어야 하는지가 곧바로 논점이 됐다.