EIP-8142 블록 인 블롭(Block-in-Blobs) (Block-in-Blobs (BiB))

Hegota 포함 제안 (PFI) · 확장성·데이터 · 원문 상태 Draft · 2026-01-29 작성

zkEVM 증명으로 블록을 검증하는 시대에도 실행 데이터가 반드시 공개되도록, 트랜잭션과 블록 접근 목록을 블롭에 담아 같은 비컨 블록에 싣게 하는 제안입니다.

왜 필요한가

지금은 검증자가 블록을 확인할 때 실행 페이로드를 내려받아 직접 다시 실행하고 그 결과를 헤더와 비교합니다. 이 과정 덕분에 블록 데이터가 반드시 공개된다는 보장이 저절로 따라왔습니다. 그런데 zkEVM이 도입되면 검증자는 페이로드 대신 증명(proof)과 헤더만 받아 검사하면 됩니다. 이때 데이터를 내려받아야 한다는 암묵적 요구가 사라지는 것이 문제입니다. 악의적이거나 이기적인 블록 생산자가 올바른 증명만 공개하고 트랜잭션 데이터 자체는 숨길 수 있습니다. 그러면 그 생산자만 다음 블록을 만들 수 있게 됩니다. 증명만으로는 운영할 수 없어 데이터를 직접 재실행해야 하는 RPC 제공자와 인덱서는 멈춥니다. 이 제안은 실행 페이로드 데이터를 블롭에 담아 같은 비컨 블록에 싣도록 강제해서 증명 시대에도 데이터가 항상 공개되게 합니다.

무엇이 바뀌나

지금

EIP-8142 이후

누구에게 영향이 있나

심층 설명

무엇을 블롭에 담는가: 트랜잭션과 BAL

블롭에 담는 ExecutionPayloadData는 blockAccessList(EIP-7928의 BAL, RLP 인코딩)와 transactions 두 가지입니다. 트랜잭션은 페이로드의 다른 구성 요소에서 유도할 수 없고 합의 계층이 제공하지도 않는 유일한 데이터라서 포함합니다. BAL은 원래 실행 결과물이라 재계산할 수 있지만 zkEVM 증명이 의무화되면 검증자가 더 이상 실행하지 않으므로 빌더가 증명만 내고 BAL을 숨길 수 있어 함께 담습니다. 반면 withdrawals는 합의 계층에서 유도가 가능하고 execution requests는 트랜잭션에서 재계산이 가능하며 합의 계층 검증에 이미 필요해서 제외합니다. 헤더는 payload_blob_count를 담고 있는데 이 값이 블롭 개수에 의존하므로, 헤더를 블롭에 넣으면 순환 의존이 생겨 제외합니다.

인코딩 규칙: 필드 엘리먼트당 31바이트와 8바이트 헤더

블롭의 각 32바이트 필드 엘리먼트는 첫 바이트(MSB)를 0으로 두고 나머지 31바이트만 씁니다(USABLE_BYTES_PER_FIELD_ELEMENT = 31). 모든 엘리먼트 값이 BLS_MODULUS보다 작은 정규 필드 엘리먼트가 되도록 보장하기 위해서입니다. 블롭 하나의 가용 용량은 FIELD_ELEMENTS_PER_BLOB(4096) × 31바이트입니다. 데이터 앞에는 8바이트 헤더 [4바이트 BAL 길이][4바이트 트랜잭션 길이]를 빅엔디언으로 붙여서 트랜잭션을 파싱하지 않고도 BAL만 따로 꺼낼 수 있게 합니다. 디코딩 시 선언된 길이 뒤의 나머지는 전부 0 패딩이어야 하고 추가 데이터는 허용되지 않습니다. 인코딩 함수 execution_payload_data_to_blobs와 디코딩 함수 blobs_to_execution_payload_data는 서로 역함수라는 불변식이 성립합니다. 직렬화는 단순함을 위해 RLP를 쓰고 압축은 당분간 쓰지 않기를 권고합니다.

payload_blob_count 필드와 커밋먼트 순서

실행 헤더와 합의 계층 ExecutionPayload에 payload_blob_count(uint64) 필드가 새로 들어갑니다. 비컨 블록이 참조하는 blob_kzg_commitments 목록에서 앞쪽 payload_blob_count개가 페이로드 블롭 커밋먼트이고 나머지가 타입3(EIP-4844 블롭 운반) 트랜잭션의 커밋먼트입니다. 전체 블롭 수는 EIP-7892가 정하는 MAX_BLOBS_PER_BLOCK을 넘을 수 없으므로 빌더는 타입3 트랜잭션을 고를 때 페이로드 블롭 사용량을 함께 계산해야 합니다. 합의 계층은 이 필드로 커밋먼트 순서만 해석할 뿐, 페이로드 블롭에 대한 새 검증 규칙을 추가하지 않고 가용성과 네트워킹에서는 다른 블롭과 똑같이 다룹니다.

Engine API 두 변형: 네이티브와 zkEVM 최적화

newPayload와 getPayload에 동등한 두 가지 방식이 제시됩니다. 네이티브 변형은 blob_to_kzg_commitment로 페이로드 블롭의 커밋먼트를 직접 계산해 payload_blob_count와 버전 해시를 검증하며 증명 의무화 이전 구현에 적합합니다. zkEVM 최적화 변형은 커밋먼트 계산에 드는 멀티스칼라 곱셈(MSM)이 zkEVM 회로 안에서 증명하기 비싸다는 점을 고려해, 대신 verify_blob_kzg_proof_batch로 다항식 열림 증명을 배치 검증합니다. 이를 위해 BlobsBundle에 payload_kzg_proofs 필드가 추가되는데, 이 목록은 페이로드 블롭에 대한 랜덤 포인트 KZG 증명만 담고 길이가 payload_blob_count와 같습니다. 회로에서 페이로드와 커밋먼트, KZG 증명은 비공개 입력이고 버전 해시와 페이로드 헤더는 공개 입력입니다. 두 변형의 유효성 조건은 동일해서 한쪽에서 유효한 블록은 다른 쪽에서도 유효합니다.

수수료: 프로토콜이 받아들이는 비용

페이로드 블롭은 사용자 트랜잭션에서 나온 것이 아니므로 타입3 블롭처럼 블롭당 수수료를 물리지 않습니다. 대신 데이터 가용성 유지에 필요한 비용으로 프로토콜이 받아들입니다. 다만 블롭 가스를 소비하므로 블롭 혼잡과 블롭 기본 수수료에 직접 영향을 줍니다. 빌더가 일부러 큰 페이로드를 만들어 블롭 가스를 부풀리는 공격은 경제적으로 제약됩니다. 페이로드를 키우려면 calldata가 든 트랜잭션을 추가해야 하는데 calldata는 실행 가스를 소모하므로, 블롭 수수료 조작만을 위해 페이로드를 부풀리는 일은 수지가 맞지 않습니다. 페이로드 블롭에 대한 명시적인 프로토콜 수준 가격 책정은 미해결 과제로 남아 있습니다.

네트워킹: 가십 폴백과 브리지 노드

블롭 전파는 기존 메커니즘을 그대로 씁니다. 증명이 의무화되면 전체 페이로드를 받을 경로가 따로 필요한데, EIP-7732가 도입하는 execution_payload 가십 토픽을 쓸 수 있습니다. 다만 지분 절대다수가 헤더 토픽만 듣는 zk 검증자라면, 악의적 빌더가 블롭에만 페이로드를 싣고 execution_payload 토픽에는 가십하지 않을 수 있습니다. zk 검증자는 증언하지만 전체 페이로드가 필요한 노드는 멈추는 상황입니다. 대응으로 각 노드가 토픽에서 페이로드를 못 받으면 앞쪽 payload_blob_count개 블롭에서 재구성해 직접 토픽에 공급하는 폴백을 둘 수 있습니다. 필요할 때마다 모든 노드가 브리지 노드 역할을 하는 구조입니다. 또한 페이로드 블롭은 대부분의 타입3 블롭과 달리 블록 빌드 전에 전파돼 있지 않아 빌더의 대역폭 요구가 커질 수 있습니다.

상태와 포크 논의: 챔피언 철회와 대체안

이 EIP는 Draft 상태라 명세가 아직 바뀔 수 있고 테스트 케이스와 참조 구현은 미작성(TODO)입니다. 콜 기록을 보면 08.06 ACDC #184에서 헤고타(Hegota) 후보로 접수(PFI)됐습니다. 이후 09.21 ACDT #97에서 챔피언이 EIP-8142를 철회하고 대체안으로 EIP-8411(빠른 실행 페이로드 브로드캐스트, Fast Execution Payload Broadcast)을 제안했다는 공지가 있었습니다. 그 콜에서 결정은 없었고 CL 팀들은 다음 ACDC 전에 평점을 매겨 달라는 요청을 받았습니다.

EIP 원문 · ← EIPs