EIP-8282 빌더 실행 요청 (Builder Execution Requests)
콜 결정 없음 · 합의·스테이킹 · 원문 상태 Last Call · 2026-05-22 작성
EIP-7732 빌더의 등록(예치)과 퇴장을 검증자 절차에서 떼어내, EIP-7685 요청 버스 위의 전용 프리디플로이 컨트랙트 두 개와 새 요청 타입 두 개(0x03, 0x04)로 처리합니다.
왜 필요한가
EIP-7732(ePBS)는 블록 본문을 만드는 빌더를 검증자와 별도의 스테이킹 참여자로 도입했지만 등록과 퇴장은 기존 검증자 절차를 빌려 씁니다. 빌더가 되려면 검증자 예치 컨트랙트에 0xB0 접두사가 붙은 출금 자격 증명으로 예치해야 하고 합의 레이어는 이 접두사를 들여다보며 검증자 예치와 빌더 예치를 구분해야 합니다. 빌더 예치는 검증자 예치 요청의 높은 블록당 한도를 그대로 물려받는데, 검증자 예치와 달리 서명 검증이 대기열로 미뤄지지 않고 즉시 처리되므로 블록당 검증 부담이 커질 수 있습니다. 퇴장도 문제입니다. 빌더는 입찰에 계속 서명하느라 항상 노출되어 있는 핫 키인 BLS 키로만 퇴장을 승인할 수 있습니다. 이 EIP는 빌더 전용 예치 컨트랙트와 퇴장 컨트랙트, 그리고 전용 요청 타입을 만들어 이 셋을 한꺼번에 해결합니다.
무엇이 바뀌나
지금
- 빌더 등록은 검증자 예치 컨트랙트에 0xB0 접두사 자격 증명으로 예치하는 방식입니다
- 합의 레이어가 자격 증명 접두사를 검사해 검증자 예치와 빌더 예치를 구분합니다
- 빌더 퇴장은 입찰에 쓰는 핫 키인 BLS 키의 서명으로만 가능합니다
- 빌더 예치가 검증자 예치 요청의 높은 블록당 한도를 그대로 따릅니다
EIP-8282 이후
- 전용 빌더 예치 컨트랙트(요청 타입 0x03)가 첫 등록과 추가 예치를 모두 처리합니다
- 요청 타입만으로 대상이 구분되어 접두사 검사가 사라지고 두 레지스트리가 독립적으로 관리됩니다
- 퇴장은 콜드 키인 execution_address가 전용 퇴장 컨트랙트(요청 타입 0x04)로 승인합니다
- 빌더 예치는 블록당 최대 64건, 퇴장은 최대 16건으로 제한됩니다
누구에게 영향이 있나
- 빌더 운영자: 포크 이후에는 반드시 새 빌더 예치 컨트랙트로 등록해야 합니다. 검증자 컨트랙트에 0xB0 자격 증명으로 예치하면 잔고를 출금할 수 없는 검증자가 됩니다. 첫 예치 전에 오프체인에서 소유 증명을 검증하지 않으면 원금을 잃을 수 있습니다.
- 클라이언트 팀: 실행 레이어는 새 프리디플로이 두 개의 시스템 콜과 요청 타입 두 개를, 합의 레이어는 새 SSZ 컨테이너 처리와 EIP-7732 예치·퇴장 경로 변경을 구현해야 합니다.
- 검증자: 검증자 예치 컨트랙트와 기존 요청 프리디플로이는 바뀌지 않습니다. 자발적 퇴장 연산은 검증자 전용으로 단순해집니다.
- 위임 구조의 자본 소유자: 퇴장 권한은 execution_address에 있지만 BLS 키를 쥔 운영자가 입찰에 계속 낙찰되면 대기 잔고가 쌓여 퇴장이 무기한 막힐 수 있으므로 운영자 입찰에 대한 오프체인 통제가 필요합니다.
심층 설명
두 프리디플로이와 요청 타입
예치 컨트랙트는 BUILDER_DEPOSIT_CONTRACT_ADDRESS(0x0000bFF46984e3725691FA540a8C7589300D8282), 퇴장 컨트랙트는 BUILDER_EXIT_CONTRACT_ADDRESS(0x000064D678505ad48F8cCb093BC65613800E8282)에 배포되며 요청 타입은 각각 BUILDER_DEPOSIT_REQUEST_TYPE(0x03)과 BUILDER_EXIT_REQUEST_TYPE(0x04)입니다. 최종 타입 값은 활성 EIP-7685 타입 전체에서 유일해야 하며 consensus-specs에서 조율합니다. 두 컨트랙트는 EIP-7997 CREATE2 팩토리로 배포되고 현재 레퍼런스 바이트코드에서 위 주소가 나오도록 솔트를 채굴했습니다. 포크 활성화 전에 배포되어야 하며 활성화 시점에 어느 쪽이든 코드가 없으면 그 이후 모든 블록이 무효입니다.
요청 큐와 시스템 콜 동작
두 컨트랙트는 EIP-7002, EIP-7251의 설계와 저장소 레이아웃을 따르며 Solidity 호환 ABI가 없습니다. 호출자와 calldatasize만으로 분기합니다. SYSTEM_ADDRESS가 아닌 주소가 정확한 입력 크기로 호출하면 요청 제출이고 빈 콜데이터로 호출하면 상태 변경 없이 현재 수수료를 반환합니다(값이 붙어 있으면 revert). 어느 경우에도 해당하지 않는 호출은 revert해야 합니다. 블록 끝에 SYSTEM_ADDRESS가 호출하면 블록당 최대치(예치 MAX_DEPOSIT_REQUESTS_PER_BLOCK=64, 퇴장 MAX_EXIT_REQUESTS_PER_BLOCK=16)까지 오래된 순서로 꺼내 request_data로 반환하고 한도를 넘는 레코드는 다음 블록으로 넘깁니다. 시스템 콜에 콜데이터가 포함되면 큐가 영구 비활성화됩니다. 시스템 콜은 블록 가스 한도와 별개인 30_000_000 가스로 실행되고 실패하면 블록이 무효입니다.
수요 반응형 수수료
수수료는 EIP-7002와 같이 fee = fake_exponential(MIN_REQUEST_FEE, excess, REQUEST_FEE_UPDATE_FRACTION)으로 계산합니다. fake_exponential은 MIN_REQUEST_FEE * e**(excess / REQUEST_FEE_UPDATE_FRACTION)의 EIP-1559식 정수 근사이고, MIN_REQUEST_FEE는 1 wei, REQUEST_FEE_UPDATE_FRACTION은 17입니다. 블록당 요청이 목표치(예치 TARGET_DEPOSIT_REQUESTS_PER_BLOCK=8, 퇴장 TARGET_EXIT_REQUESTS_PER_BLOCK=2)를 넘으면 수수료가 초선형으로 오르고 넘지 않으면 MIN_REQUEST_FEE로 되돌아갑니다. 수수료는 예치 원금과 별도로 붙고 컨트랙트에 잠긴 채 남습니다. EIP-7002가 블록 끝에 수수료를 갱신하는 것과 달리, 두 컨트랙트는 쓰기 경로마다 수수료 증가분을 적용하도록 수정되었습니다.
예치 요청: 184바이트 레코드
예치 요청은 정확히 184바이트 콜데이터로 제출합니다. 0:48이 pubkey(BLS 공개키 48바이트), 48:80이 withdrawal_credentials(version 바이트 + execution_address), 80:88이 amount(빅엔디언 uint64, gwei 단위), 88:184가 signature(96바이트 BLS 소유 증명)입니다. 첫 예치와 추가 예치를 같은 요청으로 처리합니다. amount * 1 gwei가 BUILDER_MIN_DEPOSIT(1000000000000000000 wei, 1 ETH)보다 작거나 msg.value가 amount * 1 gwei + fee보다 작으면 거부해야 합니다. 초과분은 컨트랙트가 보유하고 빌더에게 적립되지 않습니다. 꺼낼 때 amount는 리틀엔디언으로 변환됩니다. 컨트랙트는 signature를 검증하지 않고 레코드에 실어 보내며 합의 레이어가 검증하므로, 첫 예치 전에 오프체인에서 소유 증명을 검증해야 합니다.
퇴장 요청: execution_address 승인
퇴장 요청은 퇴장시킬 빌더의 pubkey 48바이트만 콜데이터로 보내며 msg.value가 수수료 이상이어야 합니다. 스테이킹되는 값은 없습니다. 성공하면 source_address(20바이트, msg.sender) ++ pubkey(48바이트) 레코드가 큐에 들어갑니다. 컨트랙트는 msg.sender를 기록할 뿐 추가 검사를 하지 않고 합의 레이어가 source_address가 대상 빌더의 execution_address와 같을 때만 요청을 인정합니다. 요청에 서명이 없으므로 이 검사만이 유일한 퇴장 승인 장치이며, 이것이 없으면 아무나 임의의 빌더를 퇴장시킬 수 있습니다. 입찰에 상시 노출되는 핫 키(BLS 키) 대신 콜드 키인 execution_address에 퇴장 권한을 두는 것은 EIP-7002의 검증자 출금 자격 증명 논리와 같습니다.
합의 레이어 처리와 서명 도메인
합의 레이어는 레코드를 BuilderDepositRequest(pubkey, withdrawal_credentials, amount, signature)와 BuilderExitRequest(source_address, pubkey) SSZ 컨테이너로 디코드합니다. BuilderDepositRequest는 EIP-6110 DepositRequest에서 index 필드를 뺀 것입니다. 레지스트리에 없는 pubkey의 예치는 빌더 전용 서명 도메인 DOMAIN_BUILDER_DEPOSIT 아래에서 (pubkey, withdrawal_credentials, amount)에 대한 소유 증명이 유효할 때 새 빌더로 등록됩니다. 서명이 무효면 레코드는 무시되고 예치금은 몰수됩니다. 예치는 검증자의 pending_deposits 큐를 거치지 않고 즉시 적용됩니다. 이미 등록된 pubkey의 예치는 추가 예치로 amount만 적립되고 withdrawal_credentials와 signature는 무시되므로, 제3자가 콜데이터를 재전송해도 출금 주소를 바꿀 수 없습니다. 퇴장은 pubkey가 활성 빌더이고 source_address가 일치하며 대기 중 잔고가 없을 때만 시작되고 그렇지 않으면 재대기 없이 버려져 다시 제출해야 합니다. 검증자용 DOMAIN_DEPOSIT과 도메인이 분리되어 소유 증명을 두 부류 사이에서 재사용할 수 없습니다.
EIP-7732 변경과 포크 전환 온보딩
process_deposit_request의 빌더 분기가 제거되어 검증자 예치 컨트랙트로 들어온 예치는 항상 일반 검증자 예치가 됩니다. 포크 이후 0xB0 자격 증명으로 검증자 컨트랙트에 예치하면 잔고를 출금할 수 없는 검증자가 만들어지므로 빌더 예치는 반드시 빌더 예치 컨트랙트로 보내야 합니다. 다만 포크 시점의 일회성 온보딩, 즉 빌더 자격 증명이 붙은 대기 예치를 빌더로 전환하는 EIP-7732 경로는 유지되어 포크 첫 슬롯부터 빌더가 존재합니다. 이후 0xB0 BUILDER_WITHDRAWAL_PREFIX는 폐기됩니다. process_voluntary_exit의 빌더 분기도 제거되어 자발적 퇴장 연산은 검증자 전용이 되고 빌더는 BUILDER_EXIT_REQUEST_TYPE으로만 퇴장합니다.
리스크와 진행 상태
수수료, 초과 송금분, 그리고 소유 증명이 무효해 합의 레이어가 거부한 첫 예치의 원금은 프리디플로이에 영구히 잠깁니다. 실행 레이어가 BLS 서명을 검증하지 않으므로 오프체인 사전 검증이 유일한 보호 수단입니다. 자본 소유자(execution_address)와 입찰 운영자(BLS 키)가 다른 주체일 때, 운영자가 계속 낙찰되면 대기 잔고가 쌓여 소유자의 퇴장이 무기한 막힐 수 있습니다. 블록당 한도는 큐에서 꺼내는 속도만 제한하므로 큐 자체는 블록을 넘어 커질 수 있지만 예치마다 최소 1 ETH와 수수료가 잠기므로 성장이 자본으로 억제됩니다. 이 EIP의 상태는 Last Call이며 마감(last-call-deadline)은 2026-11-01입니다. 코어 개발자 콜에서는 07.02 ACDE #240, 07.06 ACDT #86, 07.09 ACDC #182, 07.13 ACDT #87에서 논의되었고 포크 포함 결정은 없었습니다.