EIP-8061 탈퇴·통합 처리 한도 상향 (Increase Exit and Consolidation Churn)
콜 결정 없음 · 합의·스테이킹 · 원문 상태 Last Call · 2025-10-17 작성
검증자 탈퇴와 통합 대기열이 에폭마다 처리하는 양을 늘립니다. 탈퇴 한도는 상한을 없애 총 스테이크에 비례하게 만들고 통합에는 전용 한도를 새로 둡니다. 활성화 상한은 그대로입니다.
왜 필요한가
이더리움은 검증자가 들어오고 나가는 양을 에폭마다 제한합니다. 체인이 갈라졌을 때 양쪽이 모두 확정되는 사고를 막으려는 장치입니다. 그런데 그 한도가 너무 보수적입니다. EIP-7514가 활성화에 건 상한을 EIP-7251이 탈퇴에도 적용하면서 탈퇴 한도가 총 스테이크와 상관없이 에폭당 256 ETH에 묶였습니다. 스테이크가 늘수록 줄은 길어집니다. 실제로 Kiln 검증자 대량 탈퇴 때 대기열이 40일을 넘겼습니다. 긴 줄은 사용자 경험을 해치고 운영자가 시장이나 운영 사고에 빠르게 대응하지 못하게 하며 사고 뒤 스테이크를 재배치해 확정성을 되찾는 일도 더디게 합니다. 유동성이 막히면 유동 스테이킹 토큰을 발행하거나 유동성 준비금을 둘 수 있는 중앙화 서비스가 상대적으로 유리해집니다. 검증자 통합(consolidation)도 같은 한도에 눌려 있습니다. 지금 조건에서는 0x01 스테이크 약 3,200만 ETH를 줄이는 데 1.3~1.5년이 걸립니다. 통합이 늦어지면 더 빠른 확정성으로 가는 길도 늦어집니다.
무엇이 바뀌나
지금
- 활성화와 탈퇴가 한 한도를 같이 쓰고 둘 다 에폭당 256 ETH 상한에 묶입니다
- 탈퇴 한도가 총 스테이크와 무관해 스테이크가 늘수록 대기열이 길어집니다
- 통합은 활성화·탈퇴를 쓰고 남은 몫만 쓰며 따로 조정할 수 없습니다
- 약한 주관성 기간이 약 15.7일입니다 (총 스테이크 3,600만 ETH 기준)
EIP-8061 이후
- 탈퇴 한도는 상한이 사라지고 총 스테이크의 1/32,768로 다시 비례합니다 (지금 상한의 약 4배)
- 활성화는 기존대로 에폭당 256 ETH 상한을 유지합니다
- 통합은 전용 한도(총 스테이크의 1/65,536)가 있어 독립적으로 조정할 수 있습니다 (약 2배)
- 약한 주관성 기간이 약 7.0일로 줄어듭니다
누구에게 영향이 있나
- 스테이커·검증자 운영자: 탈퇴 대기열이 짧아져 자금을 빼거나 다른 곳으로 옮기는 시간이 줄어듭니다. 시장이나 운영 사고에 더 빨리 대응할 수 있습니다.
- 검증자 통합을 원하는 운영자: 통합 대기열이 활성화·탈퇴와 분리되어 입금이 몰려도 통합 처리가 막히지 않습니다. 검증자 집합이 더 빨리 작아집니다.
- 노드 운영자·합의 클라이언트 팀: 약한 주관성 기간이 약 15.7일에서 약 7.0일로 줄어듭니다. 클라이언트는 새 상수 세 개와 한도 함수 세 개, 약한 주관성 기간 계산식을 구현해야 합니다.
- 유동 스테이킹·중앙화 스테이킹 서비스: 프로토콜 자체 유동성이 좋아지면서 유동성 부족에서 얻던 상대적 이점이 줄어듭니다.
심층 설명
상수 변경: 하나는 절반으로, 하나는 새로, 하나는 이름만
CHURN_LIMIT_QUOTIENT를 2**16에서 2**15로 절반으로 줄이고 이름을 CHURN_LIMIT_QUOTIENT_GLOAS(32,768)로 바꿉니다. 이 값은 활성화와 탈퇴에만 씁니다. 통합에는 새 상수 CONSOLIDATION_CHURN_LIMIT_QUOTIENT를 2**16(65,536)으로 둡니다. 통합은 활성화와 탈퇴를 합친 것의 절반, 전체 처리량의 3분의 1을 받는 셈입니다. 기존 MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT는 MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT로 바뀌고 값은 2**8(256)으로 같습니다. 이름에서 EXIT가 빠진 이유는 상한이 이제 활성화에만 걸리기 때문입니다. 입금 상한을 그대로 둔 이유도 원문에 있습니다. 활성 검증자 집합의 증가는 EIP-7251로 대부분 해결됐지만 BeaconState의 검증자 배열(비활성 검증자 포함)은 여전히 크고 계속 커지는 중이며 스테이크 자체가 너무 빨리 늘어나는 것도 아직 우려 대상이라고 적었습니다.
처리 한도 함수 세 개
기존 get_activation_exit_churn_limit를 두 함수로 나눕니다. get_activation_churn_limit는 MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA와 get_total_active_balance(state) // CHURN_LIMIT_QUOTIENT_GLOAS 중 큰 값을 EFFECTIVE_BALANCE_INCREMENT 단위로 내림한 뒤, MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT로 상한을 겁니다. get_exit_churn_limit는 같은 계산을 하되 상한이 없습니다. 새로 생긴 get_consolidation_churn_limit는 get_total_active_balance(state) // CONSOLIDATION_CHURN_LIMIT_QUOTIENT를 EFFECTIVE_BALANCE_INCREMENT 단위로 내림하며 최소값도 최대값도 두지 않습니다. 기존에는 통합 한도가 전체 한도에서 활성화·탈퇴 상한을 뺀 남는 몫으로 암묵적으로 정해졌습니다. 탈퇴 상한이 사라지면 남는 몫이라는 개념 자체가 없어지므로 전용 상수가 필요해졌습니다.
약한 주관성 기간 계산식의 가중치
compute_weak_subjectivity_period에서 delta = get_balance_churn_limit(state) 한 줄을 세 한도의 가중합으로 바꿉니다. delta = 2 * get_exit_churn_limit(state) // 3 + get_activation_churn_limit(state) // 3 + get_consolidation_churn_limit(state) 입니다. 이어서 epochs_for_validator_set_churn = SAFETY_DECAY * t // (2 * delta * 100)을 구하고 MIN_VALIDATOR_WITHDRAWABILITY_DELAY를 더해 돌려줍니다. 가중치는 각 작업이 안전성을 깎는 정도에서 나옵니다. 탈퇴 1단위는 4/3, 활성화 1단위는 2/3, 통합 1단위는 탈퇴와 활성화를 합친 2입니다. 통합은 탈퇴 하나와 활성화 하나를 동시에 하는 것과 같기 때문입니다. 안전성 감소 목표 10%를 기준으로 쓰면 WS_epochs = 256 + 0.1·S / (4/3·E + 2/3·A + 2·C) 입니다. 코드의 2 * delta가 이 분모에 해당합니다. 일수로 바꾸려면 에폭 수를 225로 나눕니다.
입금·탈퇴 처리에서 바뀐 부분
입금 처리 process_pending_deposits에서는 available_for_processing을 state.deposit_balance_to_consume + get_activation_churn_limit(state)로 계산합니다. 바뀐 건 함수 이름 하나뿐이고 나머지 흐름(미확정 입금 대기, MAX_PENDING_DEPOSITS_PER_EPOCH 제한, 탈퇴 중인 검증자의 입금 연기, 한도 초과 시 중단, 한도에 닿았을 때만 남은 몫을 이월)은 그대로입니다. 탈퇴 처리 compute_exit_epoch_and_update_churn에서는 per_epoch_churn을 get_exit_churn_limit(state)로 받습니다. 탈퇴 금액이 earliest_exit_epoch에 남은 exit_balance_to_consume보다 크면, 넘치는 양을 per_epoch_churn으로 나눠 올림한 만큼 에폭을 뒤로 미루고 그만큼 소비 가능 잔고를 늘립니다. 원문은 이를 활성화에는 상한이 있고 탈퇴에는 없던 일렉트라(Electra) 이전 상태로 되돌리는 것이라고 설명합니다.
수치로 보는 변화: 15.7일에서 7.0일로
원문은 총 스테이크 S를 작성 시점 기준 약 3,600만 ETH로 두고 계산합니다. 지금은 A = E = min(256, S/2**16) = 256 ETH로 상한에 걸립니다. C = S/2**16 - A ≈ 293 ETH입니다. 약한 주관성 기간은 약 3,533 에폭, 약 15.7일입니다. 이 EIP 뒤에는 E = S/2**15 ≈ 1,098 ETH, A = 256 ETH(상한 유지), C = S/2**16 ≈ 549 ETH가 되고 기간은 약 1,573 에폭, 약 7.0일입니다. Rationale은 이를 탈퇴 한도가 현재 상한 대비 약 4배, 상한이 없던 예전 기준으로는 정확히 2배, 통합 한도는 약 2배 늘어난 것이라고 정리합니다. 앞으로 생길 수 있는 경우도 적어 뒀습니다. 활성화 상한을 없애면 약 6.0일(1,348 에폭), 통합을 끄면 약 10.9일(2,457 에폭), 둘 다 하면 약 8.4일(1,894 에폭)입니다. 활성화 상한을 없애도 하루 정도만 줄어 일주일 수준이 유지되므로, 나중에 상한을 없애기로 해도 이 설정을 그대로 써도 된다고 보았습니다.
설계 근거와 통합이 급한 이유
원문이 드는 근거는 네 가지입니다. 첫째, 통합 한도를 따로 두면 독립적으로 조정할 수 있습니다. 검증자 집합 통합을 더 서두르고 싶으면 올리고 큰 통합 물결이 지나간 뒤에는 내릴 수 있습니다. 둘째, 탈퇴 한도는 총 스테이크에 다시 비례하고 통합 한도도 비례를 유지합니다. 셋째, 활성화는 EIP-7514의 상한을 그대로 둡니다. 넷째, 탈퇴와 활성화가 안전성에 미치는 영향이 다르다는 점을 반영해도 약한 주관성 기간이 일주일 수준이라 안전성과 기능의 균형이 맞는다고 봅니다. Motivation에는 통합이 왜 급한지도 나옵니다. 지금 조건에서는 활성화와 탈퇴만 밤낮으로 꽉 채워 써도 0x01 스테이크 약 3,200만 ETH를 줄이는 데 1.5년쯤 걸리고 통합 대기열을 꽉 채워도 약 1.3년이 걸립니다. 게다가 입금 처리량은 새 스테이크에도 필요해서 통합에 쓸 수 있다는 보장이 없습니다. 최근 100만 ETH가 넘는 자금이 들어와 대기열을 약 20일간 독점한 사례가 그 예입니다.
호환성, 문서 상태, 코어 개발자 콜 기록
합의 규칙이 바뀌므로 하위 호환이 되지 않으며 예정된 네트워크 업그레이드에 포함해 활성화해야 합니다. 상수 이름에 GLOAS 접미사가 붙어 있고 코드 주석도 [Modified in Gloas:EIP-8061]로 표시되어 있어 명세가 Gloas 기준으로 작성됐음을 알 수 있습니다. 원문 상태는 Last Call이고 마감은 2026-11-01입니다. 코어 개발자 콜에서는 아직 포크 포함 결정이 없습니다. 8월 20일 ACDC #185와 9월 24일 ACDE #246에서 논의됐지만 결정은 없었습니다. 9월 21일 ACDT #97에서는 글램스테르담(Glamsterdam) CL 블록 서빙 윈도우와 BAL 보관 기간을 그 콜에서 정하지 않고 비동기 논의와 ACDE로 넘겼습니다. 33,024 에폭 유지, 약 14,299로 축소, 8,192로 축소(EIP-8383, 헤고타 후보라 범위 밖) 세 안이 올라왔고 테스트넷 출시는 막지 않기로 했습니다.