EIP-7251 검증자 최대 유효 잔고 상향 (Increase the MAX_EFFECTIVE_BALANCE)

최종 확정 · 합의·스테이킹 · 원문 상태 Final · 2023-06-28 작성

검증자 하나가 인정받는 유효 잔고 상한을 32 ETH에서 2048 ETH로 올립니다. 최소 기준 32 ETH는 그대로 두면서 대형 운영자의 검증자 통합과 솔로 스테이커의 복리 보상이 가능해집니다.

왜 필요한가

2023년 10월 3일 기준 합의 계층에는 83만 개가 넘는 검증자가 참여하고 있습니다. 검증자 하나의 지분이 32 ETH로 제한되다 보니, 한 주체가 같은 비콘 노드 위에서 서명 키만 다른 '중복 검증자'를 수천 개씩 돌리는 구조가 됩니다. 이 32 ETH 상한은 초기 샤딩 설계에서 소위원회가 다수 정직해야 한다는 가정 때문에 생긴 기술 부채입니다. 지금 소위원회는 증명 집계에만 쓰이기 때문에 정직한 참여자가 한 명만 있으면 충분하고 상한을 낮게 유지할 보안상의 이유가 사라졌습니다. 반면 불어난 검증자 수는 네트워크의 P2P 메시지 수, 매 에포크 집계해야 하는 BLS 서명 수, 비콘 상태(BeaconState)의 메모리 사용량을 계속 키우고 있습니다. 그래서 최소 잔고 32 ETH는 그대로 두고 상한만 올려 검증자 집합의 크기를 줄이자는 제안입니다.

무엇이 바뀌나

지금

EIP-7251 이후

누구에게 영향이 있나

심층 설명

새 상수: 상한 2048 ETH와 최소 32 ETH의 분리

기존에는 MAX_EFFECTIVE_BALANCE 하나가 활성화 최소 기준이자 유효 잔고 상한이었습니다. 이 EIP는 둘을 분리해 MIN_ACTIVATION_BALANCE를 Gwei(2**5 * 10**9)(32 ETH)로, MAX_EFFECTIVE_BALANCE_ELECTRA를 Gwei(2**11 * 10**9)(2048 ETH)로 정의합니다. 상한까지 복리를 적용받으려면 COMPOUNDING_WITHDRAWAL_PREFIX인 Bytes1('0x02') 출금 크레덴셜이 필요하고 has_compounding_withdrawal_credential로 이를 검사합니다. is_eligible_for_activation_queue는 MAX_EFFECTIVE_BALANCE 대신 MIN_ACTIVATION_BALANCE를 기준으로 바뀌어 솔로 스테이킹의 진입 문턱은 그대로 유지됩니다.

통합 요청(consolidation request)의 구조

통합 요청은 EIP-7685의 타입 0x02 요청으로, source_address(Bytes20), source_pubkey(Bytes48), target_pubkey(Bytes48) 세 필드로 구성됩니다. 요청은 CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS(0x0000BBdDc7CE488642fb579F8B00f3a590007251)에 미리 배포된 컨트랙트가 받습니다. 컨트랙트에는 세 가지 경로가 있습니다. 입력이 정확히 96바이트면 요청 추가, 입력 길이가 0이면 현재 수수료 반환, 시스템 주소가 호출하면 해당 블록 몫의 요청을 큐에서 꺼냅니다. 컨트랙트는 CALLER(msg.sender)를 source_address로 기록하므로, 비콘 상태의 0x01 출금 크레덴셜에 기록된 주소가 직접 호출해야 요청이 유효합니다.

수수료 메커니즘과 블록당 한도

요청 수수료는 fake_exponential(MIN_CONSOLIDATION_REQUEST_FEE, excess, CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION)으로 계산합니다. 상수는 MIN_CONSOLIDATION_REQUEST_FEE=1, CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION=17입니다. 블록당 목표(TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK)는 1, 최대(MAX_CONSOLIDATION_REQUESTS_PER_BLOCK)는 2로, 목표를 넘는 사용량이 쌓이면 수수료가 올라갑니다. 목표 1은 통합 요청을 최대한 억제하기 위한 값이고 최대 2는 복리형 크레덴셜 전환과 통합 요청을 같은 블록에 넣을 수 있게 하기 위한 값입니다. 활성화 전에는 excess 슬롯에 EXCESS_INHIBITOR(2**256-1)가 들어 있어 첫 시스템 콜 전 수수료 계산을 막고 첫 갱신 때 0으로 재설정됩니다. 초과 납부한 수수료는 환불되지 않으므로 컨트랙트는 staticcall로 수수료를 먼저 읽어 정확히 내야 합니다. EOA가 직접 요청하면 항상 과납이 발생하므로 원문은 트랜잭션 시뮬레이션으로 적정 금액을 추정하라고 권고합니다.

블록 말미 시스템 콜 규칙

이 EIP가 활성화된 모든 실행 블록은 트랜잭션 처리가 끝난 뒤 SYSTEM_ADDRESS(0xfffffffffffffffffffffffffffffffffffffffe)로 컨트랙트를 호출해야 합니다. 이 호출의 전용 가스 한도는 30_000_000입니다. 소비한 가스는 블록 가스 사용량에 포함되지 않고 블록 가스 한도 검사에서도 제외됩니다. EIP-1559의 수수료 소각 규칙도 따르지 않아 값 전송이 없어야 합니다. 호출은 큐에서 요청을 꺼내고(dequeue_consolidation_requests), 초과 요청 수를 갱신하고(update_excess_consolidation_requests), 블록 카운트를 0으로 되돌립니다(reset_consolidation_requests_count). 꺼낸 요청은 반환된 순서 그대로 EIP-7685 요청 목록에 들어가야 합니다. 해당 주소에 코드가 없거나 호출이 실패하면 블록 자체가 무효가 됩니다.

합의 계층 변경 사항

핵심 변경은 네 가지입니다. 첫째, 상한을 올리되 MIN_ACTIVATION_BALANCE로 하한을 유지합니다. 둘째, 출금·활성화 큐를 거치지 않는 프로토콜 내 통합(process_consolidation)을 추가합니다. 셋째, EIP-7002의 일부로 실행 계층발 부분 출금을 허용해, 예를 들어 100 ETH 검증자가 종료 없이 최대 68 ETH까지 뺄 수 있습니다. 넷째, 초기 슬래싱 페널티를 미미한 수준으로 만듭니다. 기존 페널티는 유효 잔고의 1/32로 잔고에 비례해 커지므로 대형 검증자가 통합을 꺼리는 요인이었습니다. 이를 지원하기 위해 처닝(churn) 한도가 검증자 수가 아닌 가중치(잔고) 기준으로 바뀌고 입금은 PendingDeposit 큐에 쌓여 같은 속도 제한을 받습니다. 잔고 추가 입금(top-up)도 활성화 큐를 거칩니다. 출금 처닝 사용량은 256 ETH(32 ETH 검증자 8개 상당)로 제한되고 남는 처닝은 통합 처리에 돌립니다. 전체 명세는 electra/beacon-chain.md에 있습니다.

통합 큐 하드 리밋

블록당 최대 2건의 요청 반입이 통합 처닝 처리 속도보다 빠를 수 있어 통합 큐가 무한히 자랄 위험이 있습니다. 그래서 큐 크기에 262,144건의 하드 리밋을 둡니다. 이는 비콘 상태에서 4 MB에 해당하는 데이터입니다. 한도를 넘는 통합 요청은 합의 계층이 버리며 다시 제출해야 하고 이때 이미 낸 수수료는 환불되지 않습니다.

보안 분석: 위원회·집계자·제안자 선택

위원회가 전부 통합된 최악의 경우를 가정해도 공격자가 증명 위원회를 장악할 확률은 낮게 유지되고 필요한 정직 검증자 비율은 최종성에 필요한 2/3 초다수보다 충분히 아래에 머뭅니다. 집계자(aggregator) 선택은 기존에 검증자 단위 VRF 추첨이어서 통합하지 않은 공격자가 유리해질 수 있었는데, 이 제안은 추첨을 가중치 기반으로 바꿔 정직한 집계자가 최소 한 명 있을 확률이 나빠지지 않게 합니다. 제안자 선택은 이미 유효 잔고 대비 MAX_EFFECTIVE_BALANCE 비율로 가중되어 있어 그대로 두지만 낮아진 확률 탓에 다음 제안자 계산 시간이 약간 늘어납니다. 싱크 위원회 선택도 이미 잔고 가중이라 라이트 클라이언트 프로토콜 수정이 필요 없습니다. 이 EIP는 상태가 Final로 확정된 명세입니다.

EIP 원문 · ← EIPs