이더리움(ETH) EIP-8282 검증, 빌더 계약 불일치 드러나

이더리움재단(Ethereum Foundation)과 Verity가 이더리움(ETH)에서 블록을 구성하는 빌더의 예치·퇴장 계약을 담은 EIP-8282의 실행 바이트코드를 형식 검증해 세 가지 동작 보증을 확인하고, 연구진이 해소해야 할 불일치도 찾아냈다.

크립토브리핑(Crypto Briefing)은 Verity가 2026년 9월 검증을 마쳤으며, 사용자 제출 호출과 프로토콜의 SYSTEM 호출에 관한 실행 경로에서 세 가지 보증을 입증했다고 보도했다. Verity는 공개 연구 설명에서 EIP-8282의 빌더 예치·퇴장 계약 속성을 기계적으로 확인한 사례를 소개했다.

형식 검증은 코드가 정해진 조건을 지키는지 수학적 방법으로 확인하는 작업이다. 이번 검증의 대상은 제안 전체가 아니라 체인에서 실행될 계약의 런타임 바이트코드와 특정 동작이었다.

검증팀은 설정한 속성이 코드 변경을 잡아내는지 확인하기 위해 바이트코드 변형 6가지를 적용했다. 크립토브리핑은 검토 과정에서 연구진이 해결해야 할 불일치도 드러났다고 전했지만, 보도에는 개별 불일치의 세부 내용이 담기지 않았다.

EIP-8282는 2026년 5월 22일 작성됐다. 제안은 블록 빌더를 별도의 예치 기반 참여자로 다루는 EIP-7732가 기존에 활용하던 검증인 등록·퇴장 절차를 빌더 전용 요청으로 바꾸는 내용을 담았다.

제안서에는 빌더 등록과 예치금 추가를 처리하는 계약, 퇴장 요청을 처리하는 계약이 각각 등장한다. 빌더의 첫 등록과 추가 예치는 예치 계약이 맡고, 퇴장 계약은 빌더의 지정 실행 주소에서 발생한 요청을 처리하도록 설계됐다.

실행 코드에는 이용자가 수수료를 내고 보내는 요청과 프로토콜 자체가 보내는 SYSTEM 호출 경로가 있다. SYSTEM 호출은 각 블록이 끝날 때 요청을 모아 합의 계층으로 전달하는 절차다.

예치 요청 하나로 새 빌더 등록과 기존 빌더의 추가 예치를 모두 처리한다. 계약은 요청을 접수해 기록하지만, 첫 등록에 필요한 서명을 직접 검증하지 않는다.

첫 예치의 서명은 합의 계층에서 확인한다. 서명이 유효하지 않은 첫 예치는 처리되지 않고 예치금이 계약에 영구히 묶일 수 있어, 제안서는 제출자가 전송 전 서명을 확인하도록 권고한다.

이미 등록된 빌더의 추가 예치에서는 금액이 반영되고, 요청에 포함된 출금 자격 정보와 서명은 무시된다. 따라서 첫 등록과 추가 예치는 같은 계약을 이용하더라도 합의 계층에서 처리하는 방식이 다르다.

퇴장 요청이 들어오면 계약은 요청을 보낸 주소를 기록한다. 이후 합의 계층이 그 주소와 빌더에게 지정된 실행 주소가 일치하는지 확인해야 퇴장을 처리한다.

크립토브리핑은 연구진이 발견된 불일치를 제안서와 대조해 해결해야 한다고 전했다. 해결 방식은 실행 코드 수정, 제안서 변경 또는 의도한 동작을 명확히 설명하는 것일 수 있다고 보도했다.

제안서에 적힌 Last Call 기한은 2026년 11월 1일이다. Verity의 검증은 기한 전인 9월에 끝났다.

2026년 11월 11일 현재 EIP 페이지는 EIP-8282를 ‘Last Call’ 단계이자 동료 검토가 진행 중인 제안으로 표시한다. 형식 검증 결과와 별개로, 제안의 최종 내용은 이 검토 과정에서 정리된다.