EIP-8146 블록 접근 목록 사이드카 (Block Access List Sidecars)
Hegota 포함 제외 (DFI) · 확장성·데이터 · 원문 상태 Draft · 2026-02-03 작성
블록 접근 목록(BAL)을 실행 페이로드에서 떼어내 전용 사이드카로 먼저 전파합니다. 핵심 전파 경로의 블록 크기가 절반이 되고, 실행 클라이언트는 페이로드가 오기 전에 상태를 미리 읽어 둘 수 있습니다.
왜 필요한가
EIP-7928은 블록 접근 목록(BAL)을 실행 페이로드 안에 넣습니다. EIP-7732(ePBS) 체계에서 이 페이로드는 빌더가 슬롯 중에 공개하는 봉투(SignedExecutionPayloadEnvelope)에 실리므로, BAL은 트랜잭션과 같은 토픽에서 같은 마감 시간에 함께 도착합니다. 크기가 문제입니다. 가스 한도 6천만 기준 분석에서 BAL은 약 72.4KiB로 압축된 블록의 나머지 부분(약 71.7KiB)과 거의 같아, 가장 급한 전파 구간을 지나는 객체가 두 배로 무거워집니다. 또 봉투 안에 있는 한 BAL은 페이로드가 도착하기 전에는 쓸 수 없어서 실행 클라이언트가 상태를 미리 읽어 두는(프리페치) 이점을 살리지 못합니다. 이 제안은 BAL을 별도 사이드카로 분리해 페이로드보다 최소 1초 먼저 도착하게 하고 그 사이에 실행 클라이언트가 상태 프리페치와 사후 상태 루트 계산을 시작하게 합니다.
무엇이 바뀌나
지금
- BAL이 실행 페이로드 안에 들어 트랜잭션과 같은 시점에 도착합니다
- 핵심 전파 경로를 지나는 블록 객체가 BAL 때문에 약 두 배 큽니다
- 실행 클라이언트는 페이로드를 받은 뒤에야 상태 읽기를 시작합니다
- 인클루전 리스트 작성자는 현재 블록이 상태를 어떻게 바꾸는지 모른 채 목록을 확정합니다
EIP-8146 이후
- BAL이 전용 가십 토픽의 사이드카로 분리되어 페이로드보다 최소 1초 먼저 도착합니다
- 핵심 전파 경로의 객체 크기가 절반이 되어 더 낮은 네트워크 상한을 DoS 방어로 쓸 수 있습니다
- 실행 클라이언트는 미리 받은 BAL로 상태를 프리페치하고 사후 상태 루트 계산을 시작합니다
- 인클루전 리스트 작성자는 페이로드를 실행하지 않고도 BAL의 사후 값으로 상태를 갱신합니다
누구에게 영향이 있나
- 클라이언트 팀: 합의 클라이언트는 새 가십 토픽과 요청·응답 프로토콜, 포크초이스 핸들러를, 실행 클라이언트는 새 엔진 API 메서드와 프리페치 경로를 구현해야 합니다.
- 블록 빌더: 입찰(bid)에 BAL 해시를 넣고 비컨 블록이 공개되는 즉시 사이드카를 방송해야 합니다. 페이로드 공개 시점까지 미루면 안 됩니다.
- 검증자(PTC): 페이로드 적시성 위원회는 사이드카가 마감 1초 전까지 도착했는지를 알리는 block_access_list_present 투표를 추가로 수행합니다.
- 동기화 노드: 재실행 없이 상태만 따라가는 노드는 트랜잭션 없이 상태 변경분(BAL)만 별도로 받을 수 있습니다.
심층 설명
실행 계층 규칙은 그대로, 전달 경로만 변경
BAL의 구성과 검증, 실행 블록 헤더의 block_access_list_hash 필드는 EIP-7928 명세 그대로 유지됩니다. 바뀌는 것은 전달 방식뿐입니다. BAL이 페이로드 안에 실려 오는 대신 전용 엔진 메서드로 실행 계층에 도달합니다. 합의 계층은 BAL을 불투명한 바이트(ByteList)로만 다루며 RLP를 해석하지 않습니다.
상수와 컨테이너 변경
상수 세 개가 추가됩니다. MAX_BLOCK_ACCESS_LIST_SIZE는 uint64(2**23)(8MiB)로 인코딩된 BAL의 SSZ 상한이고 MIN_EPOCHS_FOR_BLOCK_ACCESS_LIST_SIDECARS_REQUESTS는 uint64(3533)으로 EIP-7928의 BAL 보존 기간과 같으며 BLOCK_ACCESS_LIST_LEAD_TIME은 uint64(1)로 사이드카가 가용으로 인정받기 위해 증명 마감보다 앞서야 하는 초 수입니다. 컨테이너는 세 군데가 바뀝니다. ExecutionPayload에서 EIP-7928이 추가한 block_access_list 필드가 제거되고 ExecutionPayloadBid에 block_access_list_hash(keccak256(rlp(BlockAccessList)))가 추가되며 PayloadAttestationData에 block_access_list_present 불리언이 추가됩니다. 사이드카 자체는 beacon_block_root, slot, block_access_list 세 필드의 BlockAccessListSidecar 컨테이너입니다.
포크초이스: BAL 없이는 페이로드를 실행 계층에 넘기지 않음
Store에 block_access_lists와 block_access_list_availability_vote 두 필드가 추가됩니다. on_block_access_list_sidecar는 사이드카의 해시를 입찰의 block_access_list_hash와 대조한 뒤 저장하고 페이로드를 기다리지 않고 즉시 EXECUTION_ENGINE.notify_block_access_list를 호출합니다. on_execution_payload_envelope에는 해당 블록의 BAL이 로컬에 있어야 한다는 assert가 추가되어, 페이로드가 같은 블록의 BAL보다 먼저 실행 계층에 전달되는 일을 막습니다. 사이드카보다 먼저 도착한 봉투는 버리지 않고 캐시했다가 BAL이 저장되면 핸들러를 다시 실행합니다.
네트워킹: 전용 가십 토픽과 요청·응답 두 가지
block_access_list_sidecar라는 새 글로벌 가십 토픽이 생깁니다. 전달 전에 슬롯 범위, 블록 루트당 하나의 사이드카, 비컨 블록 수신 여부 등의 IGNORE 조건과, 블록 유효성·슬롯 일치·keccak256 해시 일치의 REJECT 조건을 통과해야 합니다. 요청·응답으로는 BlockAccessListSidecarsByRoot v1(블록 루트 목록으로 조회)과 BlockAccessListSidecarsByRange v1(슬롯 구간으로 조회)이 추가되며 클라이언트는 최근 MIN_EPOCHS_FOR_BLOCK_ACCESS_LIST_SIDECARS_REQUESTS 에폭 동안 두 메서드로 사이드카를 제공해야 하고 그보다 오래된 것은 정리할 수 있습니다. 이 기간은 약한 주관성 기간과 같아, 그 안에 동기화하는 노드는 합의·실행 어느 계층에서든 BAL을 받을 수 있습니다.
엔진 API: notify가 newPayload보다 먼저
engine_getPayloadV6는 blockAccessList를 페이로드 구조의 필드가 아니라 응답의 최상위 필드로 돌려줍니다. 새 메서드 engine_notifyBlockAccessListV1은 RLP 인코딩된 BAL과 blockHash를 받아 BAL을 저장하고 선언된 계정·저장소 슬롯의 프리페치를 시작하며 사후 값으로 사후 상태 루트 계산을 시작할 수 있습니다(MAY). 이 호출은 유효성 검사가 아니고 수신 확인만 하며 검증은 페이로드 실행 때 헤더와 대조해 이뤄집니다. engine_newPayloadV5에서는 EIP-7928이 추가한 blockAccessList 필드가 제거됩니다. 같은 blockHash에 대해 합의 계층은 반드시 notify를 newPayload보다 먼저 호출해야 하며 이 두 호출 사이의 시간이 이 EIP가 만드는 선행 시간입니다.
해시 커밋 재사용과 무서명 설계
EIP-7928이 이미 실행 블록 헤더에 keccak256(rlp(BAL))로 BAL을 커밋하므로, 같은 32바이트를 입찰에 실으면 합의 계층은 별도 해싱 체계나 RLP 해석 없이 사이드카를 인증할 수 있습니다. 빌더는 모순된 값을 낼 수 없습니다. bid.block_hash가 헤더를 간접적으로 커밋하므로, 입찰의 BAL 해시가 공개된 페이로드와 다르면 블록 해시 불일치로 봉투가 거부되거나 실행 계층의 BAL 재계산 불일치로 페이로드가 거부됩니다. 빌더가 입찰에 이미 서명했으므로 사이드카에 별도 BLS 서명을 붙이지 않으며 이는 블롭 데이터가 입찰의 커밋으로 검증되는 방식과 같습니다. PTC의 block_access_list_present 투표는 blob_data_available과 같은 패턴의 신호일 뿐 벌칙은 없고 가용성은 on_execution_payload_envelope의 로컬 게이트로 강제됩니다.
보안: 보류, 조기 노출, 네트워크 부하
빌더가 사이드카를 보류하면 PTC가 False로 투표해 실패가 네트워크 전체에 드러나고 어떤 노드도 그 페이로드를 검증할 수 없어 그 위에 블록이 쌓이지 않으므로 보류는 빌더 자신의 블록을 잃는 비용이 됩니다. 조기 노출 쪽은, 사이드카에 서명된 트랜잭션이 없고 접근 목록과 사후 상태 값만 있으므로 같은 슬롯에서 번들을 가로채는 언번들링이 불가능합니다. ePBS에서 봉투를 늦게 공개하는 이유가 바로 이 위험인데, BAL은 그 위험에 노출되지 않습니다. 슬롯당 총 바이트는 그대로이고 부하가 토픽별로 더 넓은 시간 창에 분산됩니다. 사이드카 검증은 최대 8MiB에 대한 keccak256 한 번이라 비용이 미미하며 페이로드가 끝내 오지 않은 BAL 캐시는 슬롯 거리나 완결 시점 기준으로 제한해야 합니다(SHOULD).
진행 상태: Draft, 헤고타 후보에서는 제외
이 EIP는 Draft 상태라 명세가 아직 바뀔 수 있습니다. 콜 기록을 보면 07.02 ACDE #240에서 헤고타 후보로 접수(PFI)되었으나, 09.17 ACDC #187에서 EIP-8237, 8341, 8367, 8321, 8243, 8375와 함께 헤고타 후보에서 제외(DFI)되었습니다. 또 하드포크가 필요한 변경이며 포크 이전 블록의 BAL은 기존대로 실행 페이로드 안에 남아 EIP-7928 방식으로 조회됩니다.