EIP-8094 블롭 인지 멤풀 (eth/vhash) (eth/vhash - Blob-Aware Mempool)
Hegota 포함 제외 (DFI) · 네트워크·노드 · 원문 상태 Draft · 2025-11-29 작성
블롭 트랜잭션을 블롭 본문(사이드카) 없이 먼저 전파하고 본문은 블롭 해시(vhash)로 따로 요청하게 바꿉니다. 수수료만 바꾸는 교체(RBF) 때 같은 블롭을 다시 내려받지 않게 됩니다.
왜 필요한가
지금 노드 간 통신 규약(devp2p eth/69)에서는 블롭 트랜잭션의 수수료만 바꿔 다시 제출해도(RBF, replace-by-fee) 새 트랜잭션과 똑같이 블롭 본문까지 통째로 다시 전파됩니다. 내용이 거의 같아도 받는 쪽이 전체를 받기 전에는 그 사실을 알 방법이 없기 때문입니다. RBF가 가장 많이 쓰이는 때가 수수료가 급등하는 시기, 즉 네트워크가 이미 과부하인 상황이라는 게 문제입니다. 이미 수요가 높은 때에 이미 배포된 블롭 내용을 다시 돌리는 트래픽이 더해져 상황을 더 나쁘게 만듭니다. 이 EIP는 블롭을 내용 기준 식별자인 vhash로 지목할 수 있게 해서 이미 가진 블롭이면 다시 받지 않아도 되게 합니다.
무엇이 바뀌나
지금
- 블롭 트랜잭션은 블롭 본문(사이드카)과 함께 통째로 전파됩니다
- 수수료만 바꾼 교체(RBF)도 새 트랜잭션과 같은 네트워크 비용이 듭니다
- 받는 쪽은 전체를 받기 전에는 내용이 같은지 알 수 없습니다
- 수수료 급등기에 교체가 몰리면 전파 트래픽이 함께 폭증합니다
EIP-8094 이후
- 블롭 트랜잭션은 사이드카 없이 먼저 전파됩니다
- 블롭 본문은 새 메시지 GetPooledBlobs로 vhash를 지목해 따로 요청합니다
- 이미 가진 블롭(같은 vhash)은 다시 내려받지 않습니다
- 수수료만 바꾼 교체는 작은 트랜잭션 데이터만 다시 돌면 됩니다
누구에게 영향이 있나
- 클라이언트 팀: eth 프로토콜 새 버전을 구현해야 합니다. 두 개의 새 메시지(GetPooledBlobs, PooledBlobs)와 사이드카 분리 전송 로직이 추가됩니다.
- L2·블롭 사용자: 수수료 변동기에 블롭 트랜잭션 수수료를 올려 다시 내도 네트워크 부담이 줄어 교체가 더 효율적으로 처리됩니다.
- 노드 운영자: 블롭 트래픽, 특히 수수료 급등기의 중복 전송이 줄어 대역폭 소비가 감소합니다.
심층 설명
타입 3 트랜잭션은 사이드카 없이 전송
기존 Transactions(0x02)와 PooledTransactions(0x0a) 메시지에서 타입 3(블롭) 트랜잭션은 사이드카 없이 보내도록 바꿉니다. 블롭 본문을 뗀 타입 3 트랜잭션은 크기가 작으므로, 일반 트랜잭션처럼 푸시 전파가 가능해집니다.
새 메시지 GetPooledBlobs / PooledBlobs
GetPooledBlobs는 [request-id: P, [vhash₁: B_32, vhash₂: B_32, ...]] 형식으로, 상대 노드의 트랜잭션 풀에서 vhash로 블롭을 요청합니다. PooledBlobs는 [request-id: P, [blob₁, blob₂...]] 형식으로 요청한 블롭을 돌려줍니다. 블롭은 요청과 같은 순서여야 하지만 없는 블롭은 건너뛸 수 있습니다. 받은 쪽이 어차피 블롭 해시를 vhash와 대조해야 하므로 응답에 vhash 목록을 다시 싣지 않습니다. 메시지 코드는 아직 미정이고 블롭 버전 접두어나 전송/미전송 비트맵, RS 인코딩 재구성을 위한 필드 구성(버전 1의 경우 소거 부호 확장을 뺀 블롭 내용, 커밋먼트, 셀 증명 포함 증명) 같은 선택지가 노트로 열려 있습니다.
EIP-4844 전파 규칙의 변경
EIP-4844는 블롭 트랜잭션을 자동 브로드캐스트하지 말고 NewPooledTransactionHashes로 알린 뒤 요청받아 보내도록 정했습니다. 이 EIP는 이를 바꿔 노드가 블롭 트랜잭션을 사이드카 없이 브로드캐스트하거나 NewPooledTransactionHashes로 알리도록(MUST) 하고, 블롭 내용은 GetPooledBlobs로 요청하게 합니다. 모든 블롭을 받아 검증하기 전에는 블롭 트랜잭션을 전달해서는 안 됩니다(MUST NOT).
왜 사이드카 해시가 아니라 vhash인가
식별자 후보는 블롭 단위 vhash와 사이드카 전체 해시 두 가지였습니다. 사이드카 해시는 원소가 하나라 메시지가 단순해지지만 새 식별자를 만들어야 하고(vhash는 devp2p 밖에서는 이미 자리 잡은 식별자입니다), 수수료 급등 때 블롭을 나눠 적게 보내는 식의 메시지 재구성이 불가능합니다. 그래서 vhash를 씁니다.
세 가지 구현 옵션 중 Option 3 선택
Option 1은 알림(announcement)에 vhash를 싣고 사이드카 포함 여부나 부분 선택을 요청할 수 있게 하는 방식, Option 2는 EIP-8077처럼 알림에 nonce를 실어 같은 nonce의 사이드카를 이미 가졌으면 교체로 가정하는 방식입니다. 선택된 Option 3은 타입 3 트랜잭션을 사이드카 없이 푸시(또는 알림 후 풀)하고 사이드카는 새 메시지로 따로 요청합니다. 홉마다 왕복 지연(RTT)이 하나 늘어 보이지만 사이드카를 뗀 타입 3 트랜잭션은 대부분 작아서 푸시 전파가 가능하고, 블롭이 필요한 수신자만 요청하면 됩니다. 사이드카를 받아 검증하기 전에는 전달이 금지됩니다.
EIP-8077·EIP-8070과의 관계
EIP-8077(출처와 nonce 알림)과는 단순히 결합할 수 있습니다. EIP-8070(스파스 블롭풀)은 같은 블롭 전파 영역을 바꾸지만 목표가 다릅니다. 8070은 평상시의 비례적 대역폭 절감이 목적이고 이 EIP는 추가 대역폭 없는 RBF가 목적입니다. 둘은 결합 가능하지만 도입 순서에 따라 결합 방식이 달라져 원문에서는 미정(TODO)으로 남겨 두었습니다.
하위 호환성
eth 와이어 프로토콜의 새 버전 배포가 필요하지만 여러 버전을 함께 지원하는 것은 통상적인 관행이라 구형 클라이언트는 이전 버전을 계속 쓸 수 있습니다. EVM 합의 규칙을 바꾸지 않으므로 하드포크가 필요 없습니다.
원문 상태와 포크 논의 경과
원문 상태는 Draft로, 명세가 아직 바뀔 수 있습니다. 메시지 코드 배정과 블롭 포맷 선택지 등 TODO가 남아 있습니다. 포크 논의로는 08.13 ACDE #243에서 헤고타(Hegota) 후보로 접수(PFI)됐으나, 09.10 ACDE #245에서 제외(DFI)됐습니다. 저자 본인도 핵심 기능 대부분이 이미 스파스 블롭 풀에 흡수됐다며 제외에 동의했습니다.