EIP-6110 검증자 예치금 온체인 공급 (Supply validator deposits on chain)
최종 확정 · 합의·스테이킹 · 원문 상태 Final · 2022-12-09 작성
검증자 예치 내역을 실행 레이어 블록에 목록으로 담아 합의 레이어에 직접 전달합니다. 기존의 블록 제안자 투표(Eth1Data) 방식은 폐기됩니다.
왜 필요한가
검증자가 되려면 실행 레이어의 예치 컨트랙트에 이더(ETH)를 보내야 합니다. 지금까지 합의 레이어는 이 예치 기록을 직접 보지 못해서 블록 제안자들이 어디까지의 예치가 유효한지를 투표(Eth1Data 투표)로 정하는 우회 방식을 썼습니다. 이 방식은 예치가 비콘 체인에 반영되기까지 약 12시간이 걸리고 지분의 3분의 2 이상을 가진 공격자가 정직한 노드에게 가짜 예치를 믿게 만들 수 있다는 안전성 가정에 기댑니다. 또 합의 클라이언트가 JSON-RPC 조회에 의존하고 예치 컨트랙트 스냅샷(EIP-4881)을 유지해야 하는 등 깨지기 쉬운 부품이 많았습니다. 이 EIP는 예치 내역을 실행 레이어 블록 안에 직접 담아 프로토콜 안에서 검증하게 해서 이 문제들을 없앱니다.
무엇이 바뀌나
지금
- 예치가 비콘 체인에 반영되기까지 약 12시간이 걸립니다
- 블록 제안자 투표(Eth1Data)로 예치를 확정해 지분 2/3 이상이 악의적이면 정직한 노드도 가짜 예치를 받아들일 수 있습니다
- 합의 클라이언트가 JSON-RPC 조회로 예치 기록을 따로 가져옵니다
- 예치 컨트랙트 스냅샷(EIP-4881)을 유지하고 배포해야 합니다
EIP-6110 이후
- 예치 반영까지 약 13분으로 줄어듭니다
- 실행 레이어가 블록 실행과 함께 예치를 직접 검증해 정직한 온라인 노드는 가짜 예치에 속지 않습니다
- 예치 목록이 블록에 포함되어 별도 조회가 필요 없습니다
- 스냅샷 유지·배포 요구가 사라집니다
누구에게 영향이 있나
- 검증자·스테이커: 예치 제출 후 약 13분이면 합의 레이어에 반영되어 대기 시간이 크게 줄어듭니다.
- 합의 클라이언트 팀: Eth1Data 투표와 JSON-RPC 의존 코드를 제거할 수 있지만 검증자 인덱스가 포크마다 달라질 수 있어 (pubkey, index) 캐시 처리를 바꿔야 합니다.
- 실행 클라이언트 팀: 예치 로그를 파싱해 EIP-7685 요청으로 담고 검증하는 블록 유효성 규칙을 새로 구현합니다.
- 일반 사용자: 블록 구조와 검증 규칙이 바뀌지만 사용자 활동과 경험에는 영향이 없습니다.
심층 설명
예치 요청 구조와 EIP-7685 인코딩
새 예치 요청(deposit request)은 pubkey: Bytes48, withdrawal_credentials: Bytes32, amount: uint64, signature: Bytes96, index: uint64 다섯 필드로 구성됩니다. 예치는 EIP-7685가 정의한 범용 요청의 한 종류로 취급되며 요청 타입 바이트는 DEPOSIT_REQUEST_TYPE = b'0'입니다. request_data는 블록 영수증(receipts)에서 get_deposit_request_data로 추출한 예치 요청들을 이어 붙인 바이트열입니다. amount와 index는 로그 데이터에서 8바이트 리틀엔디언 uint64로 읽습니다.
블록 유효성 검사: 로그에서 예치 추출
FORK_BLOCK(이 EIP가 활성화된 뒤 첫 블록)부터, 블록 안에서 발생한 모든 예치는 로그에 나타난 순서 그대로 EIP-7685 요청 목록에 들어가야 합니다. 실행 클라이언트는 영수증의 로그 중 주소가 DEPOSIT_CONTRACT_ADDRESS(0x00000000219ab540356cbb839cbe05303d7705fa)이고 첫 토픽이 DEPOSIT_EVENT_SIGNATURE_HASH인 것만 고릅니다. 세폴리아의 예치 컨트랙트처럼 DepositEvent 외에 Transfer 같은 다른 이벤트를 내보내는 경우가 있어 이 필터링이 필요합니다. 로그 데이터는 전체 길이가 576바이트인지, 다섯 필드의 오프셋이 160, 256, 320, 384, 512이고 크기가 48, 32, 8, 96, 8인지 is_valid_deposit_event_data로 검증하며 어긋나면 지원하지 않는 레이아웃의 잘못된 예치 로그로 처리합니다. 두 상수는 클라이언트 소프트웨어 바이너리 배포본에 반드시 포함되어야 합니다.
합의 레이어 변경과 Eth1Data 투표 폐기
합의 레이어에서는 ExecutionRequests에 deposit_requests 필드가 추가되고, BeaconState에 deposit_requests_start_index가 추가됩니다. 블록 처리 루틴에 process_deposit_request 함수가 새로 들어가고 전환 기간 동안 Eth1Data 투표 사용을 제한하는 블록 유효성 조건이 더해집니다. 각 예치에 담긴 index 값은 deposit_requests_start_index를 결정적으로 초기화하는 데 쓰여 전환 중 같은 예치가 두 번 적용되는 일을 막습니다. state.eth1_deposit_index == state.deposit_requests_start_index가 되면 전환이 끝난 것으로 봅니다. 이후 각 합의 클라이언트는 조율 없이 각자 Eth1Data 투표 코드를 제거할 수 있습니다. 상세 명세는 consensus-specs의 electra/beacon-chain.md, electra/validator.md, electra/fork.md 문서에 있습니다.
검증자 인덱스가 포크에 따라 달라짐
기존 방식은 Eth1Data 투표의 긴 추적 거리 덕분에 새 검증자의 인덱스가 블록 트리의 어느 가지에서나 같았고, 합의 클라이언트의 (pubkey, index) 캐시는 리오그에 영향을 받지 않았습니다. 새 메커니즘은 이 불변성을 깨서 같은 pubkey의 검증자가 블록 트리 가지마다 다른 인덱스를 가질 수 있습니다. 원문에 첨부된 분석에 따르면 포크 의존적인 (pubkey, index) 캐시가 필요한 곳은 process_deposit 함수 하나뿐입니다.
데이터 복잡도와 DoS 분석
문서 최종 갱신 시점 기준 누적 예치는 1,899,120건, 348MB이며 같은 빈도가 유지되면 연간 약 84MB가 늘어나는 수준이라 다른 역사 데이터에 비해 무시할 만하다고 평가합니다. 가장 큰 급증이었던 2023년 6월 1일에도 24시간에 12,000건 이상, 블록당 평균 2건(384바이트) 미만이었습니다. 예치 컨트랙트 실행 비용은 가장 싼 경우 15,650가스이고 현재 규칙으로 30M 가스 블록에 담을 수 있는 예치는 1,271건 미만이지만 미래 견고성을 위해 비콘 체인은 1,916건까지 견딜 수 있어야 합니다. 가장 무거운 작업은 서명 검증으로, 약 1,271건이면 최적화 없이 약 1.2초가 걸리며 블록 처리를 1초 늦추는 데 공격자가 1,000 ETH를 써야 해서 지속 가능한 공격이 아닙니다. 낙관적 동기화 중인 노드는 최대 8,192건(1.5MB, 약 8초 처리)의 예치가 담긴 블록을 받을 수 있지만 공격자가 대체 체인을 만들어 경제적으로 유효한 서명을 해야 하므로 동기화를 크게 늦출 수 없다고 봅니다. 최소 예치가 1 ETH라 예치 데이터 1바이트의 비용은 약 5,208,333 Gwei로, 일반 콜데이터보다 수십 배 이상 비싸 실행 레이어 DoS 표면도 늘지 않습니다.
약한 주관성 기간과 최종 상태
이 EIP는 에포크당 예치 수의 고정 상한을 없애고 블록 가스 한도만 남깁니다. 한도는 MAX_DEPOSITS * SLOTS_PER_EPOCH = 512건에서 30M 가스 블록 기준 max_deposits_per_30m_gas_block * SLOTS_PER_EPOCH ~ 32,768건(블록당 1,024건으로 단순화)으로 바뀝니다. 추가 예치(top up) 횟수는 약한 주관성 기간 계산의 입력값 중 하나지만 원문에 첨부된 분석은 기간이 의미 있게 줄어들지 않는다고 봅니다. 이런 공격은 상당한 지분을 태워야 하는 전제가 있어 유효하지 않다고 평가합니다. 이 EIP의 상태(status)는 Final로 확정되었으며 합의 레이어 명세는 일렉트라(Electra) 문서에 반영되어 있습니다.