EIP-7685 범용 실행 계층 요청 (General purpose execution layer requests)
최종 확정 · 네트워크·노드 · 원문 상태 Final · 2024-04-14 작성
스마트 컨트랙트가 만든 요청을 블록 헤더의 해시값 하나(requests_hash)로 묶어 합의 계층에 전달하는 범용 통로를 만듭니다. 새 요청 종류가 생겨도 블록 구조를 바꿀 필요가 없습니다.
왜 필요한가
이더리움은 거래를 처리하는 실행 계층(Execution Layer, EL)과 블록을 확정하는 합의 계층(Consensus Layer, CL)으로 나뉩니다. 스마트 컨트랙트로 운영되는 검증자가 늘면서 입출금 같은 관리 작업을 사람이나 중개 서비스 대신 컨트랙트가 직접 합의 계층에 요청하려는 수요가 커졌습니다. 그런데 이런 요청 종류가 하나 생길 때마다 실행 계층의 블록 구조를 뜯어고쳐야 한다면, 새 기능을 넣을 때마다 큰 공사가 됩니다. 이 EIP는 요청의 내용을 실행 계층이 해석하지 않는 범용 데이터로 추상화해서 블록 헤더에 약속값(커밋먼트) 하나만 추가하면 어떤 요청 종류든 실어 나를 수 있게 합니다. 중개자가 끼어들 필요가 없어지므로 최종 사용자에게 더 안전한 구조가 됩니다.
무엇이 바뀌나
지금
- 실행 계층에서 합의 계층으로 보내는 요청 종류가 새로 생기면 블록 구조 자체를 바꿔야 합니다
- 컨트랙트로 운영되는 검증자의 관리 작업에 중개자가 개입해야 하는 경우가 있습니다
- 요청 종류마다 전달 방식을 따로 설계해야 합니다
EIP-7685 이후
- 블록 헤더에 추가된 requests_hash 필드 하나로 여러 종류의 요청을 한꺼번에 약속합니다
- 컨트랙트가 요청을 만들면 합의 계층이 받아서 처리하는 공통 통로가 생깁니다
- 새 요청 종류는 타입 번호만 정해서 얹으면 되고 블록 구조는 그대로입니다
누구에게 영향이 있나
- 클라이언트 팀: 실행 클라이언트는 블록 헤더에 requests_hash를 추가하고 블록 처리 중 요청을 모아 커밋 해시를 계산해야 합니다. 합의 클라이언트는 전달된 요청을 타입별로 처리합니다.
- 스테이킹 서비스·검증자 운영자: 검증자를 다스리는 스마트 컨트랙트가 관리 작업을 직접 요청할 수 있는 기반이 생깁니다. 중개자 없이 동작하므로 더 안전합니다.
- 프로토콜 설계자: 이후 제안되는 실행 계층 발 요청(입금, 출금 등)은 이 틀 위에 타입만 정의해서 올리면 됩니다.
- 일반 사용자: 직접 체감하는 변화는 없지만 컨트랙트 기반 스테이킹을 쓸 때 중개자 개입 없이 작업이 보장되는 구조의 혜택을 받습니다.
심층 설명
requests 객체 구조
하나의 requests 객체는 request_type 1바이트 뒤에 불투명 바이트 배열 request_data를 이어 붙인 형태입니다(requests = request_type ++ request_data). request_data에는 0개 이상의 인코딩된 요청 객체가 들어가며 그 형식은 각 요청 타입이 스스로 정의합니다. 이 EIP 차원에서는 request_data의 내부를 해석하지 않습니다.
블록 헤더 확장과 requests_hash 계산
헤더에 32바이트 커밋 값 requests_hash를 추가합니다. 블록 처리 중 서로 다른 request_type의 requests 객체들이 만들어져 블록 요청 리스트에 쌓입니다. 커밋은 두 단계로 계산합니다. 먼저 request_data가 비어 있지 않은 요소(길이가 1바이트를 넘는 것)만 골라 각각 sha256으로 해시해 중간 리스트를 만듭니다. 이 중간 리스트는 request_type 오름차순으로 정렬되어 있어야 합니다. 최종 커밋은 중간 해시들을 순서대로 sha256에 넣은 결과입니다. 원문의 compute_requests_hash 의사코드가 이 과정을 그대로 보여 줍니다.
빈 요청 제외와 포크 독립적인 빈 해시
request_data가 비어 있는 요소, 즉 request_type 1바이트만 있는 항목은 커밋 계산에서 제외합니다. 이렇게 하면 요청이 하나도 없는 블록의 requests_hash가 어느 포크에서든 동일하게 sha256("")이 됩니다. 활성화된 요청 타입의 개수와 무관하게 안정적인 '빈' 해시 값을 얻기 위한 설계입니다.
정렬 규칙: 타입 간 오름차순, 타입 내 미정의
타입 간 순서는 request_type 오름차순입니다. requests_hash에 약속된 요청들이 모두 일치하는지 검증하는 절차를 단순하게 만들기 위해서입니다. 블록 안에서 생성된 시점 순으로 정렬하는 대안도 있었지만 많은 요청이 블록 끝의 시스템 콜에서 한꺼번에 쌓일 것으로 예상되어 시점 순서를 강제하기 어렵다고 보았습니다. 같은 타입 안의 순서는 이 EIP가 정의하지 않습니다. request_data가 불투명 데이터이므로 각 요청 타입이 개별적으로 정하도록 남겨 두었습니다.
RLP 리스트 대신 불투명 바이트 배열을 쓴 이유
request_data를 RLP 같은 특정 인코딩의 리스트로 고정하지 않고 불투명 바이트로 두었습니다. 덕분에 앞으로 나올 요청 페이로드가 SSZ, LEB128, 고정 폭 형식 등 어떤 인코딩이든 쓸 수 있습니다. 실행 계층은 내용을 모른 채 운반만 하므로, 인코딩 선택이 블록 구조에 영향을 주지 않습니다.
요청의 출처와 유효성: 강제가 아닌 권고
이 EIP는 요청이 어디서 와야 하는지, 언제 어떻게 검증해야 하는지를 강제하지 않습니다. 미래의 프로토콜 설계자에게 최대한의 유연성을 주기 위해서입니다. 저자들은 이렇게 권고합니다. 요청의 출처는 거래 실행, 구체적으로는 지정된 시스템 컨트랙트를 호출해 요청을 계정 저장소에 쌓는 거래가 되어야 하고 블록 처리 후 시스템 콜로 저장소에서 꺼내는 방식이 좋습니다. 속도 제한이 필요 없다면 이벤트를 내보내고 블록 처리 후에 파싱하는 방식도 가능합니다. 또한 요청의 유효성은 실행 계층에서 완전히 검증할 수 없는 경우가 많아, 단독으로 어떤 동작을 일으킬 권한이 없는 '요청'이라고 부릅니다. 시스템 컨트랙트가 실행 계층에서 가능한 검증을 한 뒤 합의 계층에 넘겨 추가 검증을 받는 구조를 기대합니다.
합의 계층 쪽 처리와 현재 상태
합의 계층 쪽 명세는 열어 두었습니다. 새 실행 계층 요청 타입을 비컨 체인 타입에 어떻게 반영할지는 각 제안이 스스로 정합니다. 하위 호환성 문제는 발견되지 않았다고 원문에 적혀 있으며 이 EIP의 상태는 Final로 명세가 확정되었습니다.