EIP-8365 새 0x00 검증자 등록 금지 (Disallow new 0x00 validators)

Hegota 포함 검토 (CFI) · 합의·스테이킹 · 원문 상태 Draft · 2026-07-18 작성

0x00(BLS) 인출 크리덴셜로 새 검증자를 만드는 예치를 더 이상 처리하지 않습니다. 이미 있는 0x00 검증자는 그대로 두고 0x01로 바꾸는 길도 그대로 열어 둡니다.

왜 필요한가

0x00은 비콘 체인 제네시스 시절의 원래 인출 주소 형식입니다. 인출을 BLS 키가 통제하고 실행 계층 주소가 없습니다. 카펠라(Capella) 업그레이드 뒤 0x01로 바꿀 수 있게 되면서 약 60만 개였던 0x00 검증자는 2026년 8월 기준 약 9,200개까지 줄었습니다. 그러나 전환은 월 두 자릿수 수준으로 느려졌고 수백 개는 6개월 넘게 증명에 참여하지 않아 키를 잃어버린 것으로 보입니다. 그런데도 새 0x00 검증자는 지금도 만들어집니다. 2026년에만 58개가 생겼고 3월에는 한 주체가 50개를 한꺼번에 만들었습니다. 이런 검증자는 실행 주소가 없어 실행 계층에서 퇴장을 요청하는 기능(EIP-7002)을 쓸 수 없고 인출 키를 잃으면 잔액이 합의 계층에 영원히 묶입니다. 또 0x00 검증자가 하나라도 남아 있는 한 전환 연산과 그 가십 토픽, 연산 풀, 크리덴셜 검사의 0x00 분기까지 모두 양자내성 전환 때까지 유지하고 보강해야 합니다. 이 EIP는 새 유입을 막아 이 집단이 더 커지지 않게 합니다. 폐기 계획은 공지가 아니라 합의 코드로 알립니다.

무엇이 바뀌나

지금

EIP-8365 이후

누구에게 영향이 있나

심층 설명

단계별 폐기의 첫 단계

이 EIP는 BLS_WITHDRAWAL_PREFIX(0x00) 인출 크리덴셜 종류의 유입만 닫습니다. 0x00 크리덴셜로 새 검증자를 만들게 될 예치는 처리하지 않습니다. 기존 0x00 검증자는 계속 검증하면서 보상과 벌점을 그대로 받습니다. 0x01 실행 크리덴셜로 바꾸는 BLSToExecutionChange 연산도 그대로 쓸 수 있습니다. 원문은 이를 문서화된 일정의 통지 단계로 설명합니다. 다음 포크를 겨냥한 동반 EIP(retirement)가 공개된 에포크부터 남은 0x00 검증자를 상한이 있는 속도로 퇴장시킵니다. 또 다른 동반 EIP(balance sunset)가 퇴장한 잔액을 양자내성 전환 전에 서서히 0으로 줄입니다. 마지막 단계 EIP는 양자내성 포크에서 BLSToExecutionChange와 그 가십 토픽, 연산 풀을 합의 계층에서 제거합니다.

apply_pending_deposit 수정 내용

대기 예치를 적용하는 apply_pending_deposit에 분기 하나를 더합니다. 예치의 pubkey가 state.validators에 없을 때, 즉 새 검증자를 만들게 될 때, withdrawal_credentials의 첫 바이트가 BLS_WITHDRAWAL_PREFIX이면 서명 검증 전에 바로 반환합니다. 첫 바이트가 다르면 기존대로 is_valid_deposit_signature로 소유 증명을 확인한 뒤 add_validator_to_registry를 호출합니다. pubkey가 이미 등록돼 있으면 상단 충전이므로 크리덴셜 종류와 무관하게 increase_balance로 잔액을 더합니다. 0x00 검증자에 대한 상단 충전도 정상 처리됩니다. 거부된 예치는 서명이 틀린 예치와 같은 취급을 받습니다. 조용히 건너뛰고 예치한 ETH는 복구할 수 없습니다. EIP-7732의 0x03 빌더 크리덴셜 라우팅이 적용되는 경우에는 0x00 검사가 그보다 먼저 옵니다.

제출 시점이 아니라 처리 시점에 적용

가드는 대기 예치가 처리될 때 적용되고 제출될 때 적용되지 않습니다. 포크 활성화는 이미 들어와 있는 대기 예치를 예외로 봐주지 않습니다. 따라서 포크 전에 제출한 0x00 예치라도 활성화 뒤에 처리되면 거부됩니다. 원문은 이를 보안 고려 사항에서 '대기 예치 손실'로 따로 다룹니다. 활성화 전에 예치를 넣었다고 등록이 보장되지 않습니다. 0x00 크리덴셜 예치가 활성화 뒤까지 큐에 남아 있으면 합의 계층이 거부하며 예치한 ETH는 돌려받을 수 없습니다. 테스트 케이스에도 '포크 전 0x00 예치가 활성화 시점에 아직 대기 중이면 건너뛴다'가 들어 있습니다.

환불하지 않는 이유

합의 계층에는 거부한 예치를 환불하는 장치가 없습니다. 그래서 새 검증자를 만들게 될 0x00 예치는 건너뛰고 ETH는 예치 계약에 남습니다. 원문은 이것이 새로운 처리가 아니라고 설명합니다. 예치를 조용히 건너뛰고 ETH를 예치 계약에 남기는 방식은 EIP-6110에서 서명이 틀린 예치를 다루는 확립된 방식입니다. EIP-8205도 크리덴셜이 맞지 않는 예치에 같은 영구 거부 의미를 의도적으로 채택했습니다. 카펠라 이후 유지 관리되는 예치 도구 중 0x00 크리덴셜을 만드는 것은 없습니다. 원문은 이 분기가 경계 사례를 판정하려는 것이 아니라 유입을 닫으려는 것이라고 밝힙니다.

남의 예치를 태울 수는 없는가

제3자가 이 가드를 이용해 다른 사람의 자금을 태울 수는 없습니다. 0x00 검증자를 만드는 예치를 구성하려면 예치하는 키로 0x00 크리덴셜에 대해 유효한 소유 증명(proof-of-possession) 서명을 만들어야 합니다. 따라서 키 보유자만 자기 예치를 태울 수 있습니다. 가드가 거부하는 예치는 처음부터 예치자 본인이 0x00 크리덴셜을 골라 서명한 것뿐입니다. 이는 서명이 틀린 예치를 다루는 기존 의미와 같습니다.

테스트 케이스와 호환성

원문은 여섯 가지 동작을 필수로 정합니다. 알려지지 않은 공개키에 대한 유효한 0x00 대기 예치는 건너뜁니다. 같은 조건에서 서명이 틀린 0x00 대기 예치도 건너뜁니다. 포크 전 0x00 예치가 활성화 시점에 아직 대기 중이면 건너뜁니다. 기존 0x00 검증자에 대한 상단 충전은 적용합니다. 0x01이나 0x02 검증자를 만드는 유효한 예치는 적용합니다. 유효한 0x03 예치는 EIP-7732의 빌더 라우팅 규칙을 따릅니다. 호환성 면에서 이 EIP는 합의 계층 상태 전이를 바꾸므로 하드포크로 일정을 잡아야 하고 실행 계층 변경은 없습니다. 기존 예치 도구는 새 0x00 검증자를 만들려 하지 않는 한 영향이 없습니다. 유지 관리되는 도구 중 그런 것은 없습니다.

원문 상태와 포크 일정

원문 상태는 Draft이므로 명세와 설명이 아직 바뀔 수 있습니다. 콜 기록을 보면 08.06 ACDC #184에서 EIP-8365/8367(BLS 인출 크리덴셜 폐기와 잔액 소멸)을 헤고타(Hegota) 후보(PFI)로 접수했습니다. 09.17 ACDC #187에서는 강제 퇴출을 빼고 신규 0x00 예치 차단만 남기는 축소안이 CFI로 유력해졌고 퇴출은 I-Star 포크로 미뤘습니다. 10.01 ACDC #188에서 예치 가드만 남긴 EIP-8365를 헤고타 CFI로 올렸고 강제 퇴출은 별도 EIP로 분리해 미래 포크에서 다루기로 했습니다. 10.12 ACDT #100에서 heze-devnet-2에 EIP-8365를 EIP-7805, EIP-8015, EIP-8198과 함께 포함하기로 확정했습니다. 10.15 ACDC #189에서는 논의만 하고 결정이 없었습니다. 10.29 ACDC #190에서는 포크 이후 0x00 예치의 ETH를 소각할지, 잔액을 0x01 예치로 큐에 다시 넣을지(바르나바스 제안)의 결정이 2주 미뤄졌고 데브콘에서 논의해 다음 콜에서 확정하기로 했습니다. 현재 원문은 ETH를 복구할 수 없다고 쓰고 있으므로 이 부분은 바뀔 수 있습니다.

EIP 원문 · ← EIPs