Blob 가격이 1 wei에 멈추면 왜 롤업 비용 신호가 깨질까: EIP-7918로 보는 DA 수수료 설계

10분 읽기·2026.06.20·출처 6개·00

오늘의 질문

롤업이 L1에 데이터를 올릴 때, 왜 “blob 공간이 비었으니 거의 무료”라는 상태가 프로토콜 입장에서는 위험한 신호가 될까?

blockchain-dev.md

SURVIVE.exe

Blob 가격이 1 wei에 멈추면 왜 롤업 비용 신호가 깨질까: EIP-7918로 보는 DA 수수료 설계

카테고리: blockchain_dev
예상 읽기 시간: 10분
오늘의 질문: 롤업이 L1에 데이터를 올릴 때, 왜 “blob 공간이 비었으니 거의 무료”라는 상태가 프로토콜 입장에서는 위험한 신호가 될까?
핵심 출처:
- Fulu-Osaka (Fusaka) | ethereum.org - 최종 업데이트 2026-06-06, 확인일 2026-06-20
- EIP-7918: Blob base fee bounded by execution cost - 생성일 2025-03-25, 확인일 2026-06-20
- Fusaka Mainnet Announcement | Ethereum Foundation Blog - 게시일 2025-11-06, 확인일 2026-06-20
- Checkpoint #8: Jan 2026 | Ethereum Foundation Blog - 게시일 2026-01-20, 확인일 2026-06-20
- EIP-7892: Blob Parameter Only Hardforks - 생성일 2025-02-28, 확인일 2026-06-20

1. 왜 지금 봐야 하나

Fusaka 이후 Ethereum의 L2 확장 논의는 “blob을 얼마나 더 많이 넣을 수 있나”에서 끝나지 않는다. ethereum.org의 Fusaka 문서는 PeerDAS가 노드가 모든 blob을 내려받지 않고 샘플링으로 데이터 가용성을 확인하게 해 blob 확장 여지를 만든다고 설명한다. 그리고 같은 페이지는 별도의 항목으로 EIP-7918, blob base fee bounded by execution cost를 다룬다.

핵심은 이렇다. L2가 L1에 데이터를 올릴 때 내는 비용은 하나가 아니다.

blob 공간 자체의 비용, 즉 base_fee_per_blob_gas
blob 트랜잭션과 KZG proof 검증 등이 L1 노드에 요구하는 실행·검증 비용, 즉 execution gas 쪽 비용

만약 두 번째 비용이 훨씬 큰데 첫 번째 blob base fee가 1 wei 근처로 떨어지면, blob fee market은 더 이상 “blob 수요가 얼마나 있는가”를 잘 알려주지 못한다. 가격 신호가 죽은 상태에서 수요가 다시 몰리면, blob base fee가 정상 가격까지 올라오는 데 시간이 걸리고 사용자·롤업 입장에서는 예측하기 어려운 혼잡 구간이 생긴다.

2026년 1월 Ethereum Foundation Checkpoint #8은 Fusaka 이후 BPO fork가 실제로 작동해 target 14, max 21 blobs per block까지 늘어났다고 정리했다. 즉, 이제 개발자가 봐야 할 질문은 단순히 “blob이 싸졌나?”가 아니라 **“blob 가격이 노드에 강제하는 비용과 같이 움직이는가?”**다.

2. 핵심 개념

EIP-7918은 blob에 실행 비용 기반의 reserve price, 즉 바닥 가격을 둔다. 엄밀히 말하면 “절대 이 가격 아래로 거래하지 못한다”는 단순한 최소가 아니라, blob base fee 조정 함수가 너무 낮은 blob fee를 계속 더 낮추지 않도록 calc_excess_blob_gas()의 동작을 바꾼다.

EIP의 핵심 조건은 다음 식이다.

zsh — 생존확인.sh

BLOB_BASE_COST * base_fee_per_gas > GAS_PER_BLOB * base_fee_per_blob_gas

이 조건이 참이면 “현재 blob 가격이 execution base fee에 비해 너무 낮다”고 본다. 이때는 기존처럼 target_blob_gas를 빼서 excess blob gas를 낮추지 않는다. 결과적으로 blob base fee가 1 wei까지 계속 미끄러져 내려가는 상태를 막고, 이후 수요가 생겼을 때 fee market이 더 빠르게 반응할 수 있게 한다.

EIP-7918에서 제안된 BLOB_BASE_COST는 2**13, 즉 8192다. 이 값은 blob 하나가 노드에 강제하는 검증·처리 비용을 execution gas의 일정 비율로 표현하기 위한 상수다. EIP 설명에 따르면 reserve blob base fee는 대략 다음처럼 해석할 수 있다.

zsh — 생존확인.sh

reserve blob base fee = BLOB_BASE_COST * base_fee_per_gas / GAS_PER_BLOB

개발자 관점에서 중요한 점은 “blob fee와 execution fee가 독립이지만 완전히 무관하지는 않다”는 것이다. blob은 별도 시장에서 가격이 정해지지만, blob을 처리하는 노드는 Ethereum 실행·검증 인프라를 같이 쓴다. 그래서 execution gas가 비싼 시기에는 blob 소비자도 노드 compute 비용의 의미 있는 일부를 부담해야 한다는 설계다.

3. 최신 이슈와 연결

Fusaka Mainnet Announcement는 Fusaka의 핵심 EIP 목록에 PeerDAS, transaction gas cap, RLP block size limit, proposer lookahead, secp256r1 precompile과 함께 EIP-7918을 포함했다. 이 조합이 중요한 이유는 Ethereum이 L2 중심으로 확장하면서 동시에 세 가지 안전 경계를 분리하고 있기 때문이다.

DA 경계: PeerDAS와 BPO는 blob 데이터를 더 많이, 더 점진적으로 확장하기 위한 장치다.
실행 경계: transaction gas cap, block size limit, ModExp repricing은 특정 트랜잭션이나 블록이 노드 실행을 과도하게 압박하지 않도록 한다.
가격 신호 경계: EIP-7918은 blob fee가 execution cost와 완전히 괴리되어 1 wei에 고착되는 것을 막는다.

EIP-7892도 이 흐름과 연결된다. BPO fork는 target, max, baseFeeUpdateFraction 같은 blob 관련 파라미터만 config로 조정하는 경량 fork다. Checkpoint #8에 따르면 Fusaka 이후 이미 BPO1, BPO2가 적용되어 blob target/max가 늘었다. blob 용량을 자주 조정할 수 있다면, 가격 조정 함수가 잘못된 신호를 내는 문제도 더 중요해진다. 용량이 늘어난 시장에서 가격이 의미를 잃으면, 롤업·builder·RPC·node operator 모두 잘못된 비용 예측을 하게 된다.

4. 개발자 관점 해석

블록체인 개발자는 수수료를 보통 “사용자가 내는 UX 비용”으로만 보기 쉽다. 하지만 프로토콜 수수료는 동시에 자원 사용량을 제한하는 제어 루프다. EIP-7918은 blob fee market을 하나의 feedback loop로 보면 이해하기 쉽다.

입력: block마다 사용된 blob gas, execution base fee, blob schedule
상태: excess_blob_gas
출력: 다음 block의 base_fee_per_blob_gas
목표: blob 수요가 target 주변에서 안정되도록 가격을 조정

문제는 출력값이 너무 작아지면 제어 루프가 둔감해진다는 점이다. EIP-7918 문서는 blob base fee가 1 wei까지 내려가면 10% 변화가 전체 blob 사용 비용에는 거의 영향을 주지 못할 수 있다고 설명한다. 그러면 실제 수요가 늘어도 가격이 한동안 제대로 올라오지 못하고, 혼잡 구간에서 first-price auction에 가까운 UX가 나타날 수 있다.

L2나 blob 송신 인프라를 만드는 팀에게 이것은 두 가지 의미가 있다.

첫째, “현재 blob fee가 낮다”는 사실만으로 장기 비용을 판단하면 안 된다. EIP-7918 이후 blob fee는 execution base fee에 의해 간접적으로 바닥이 생길 수 있다. L1 실행 수요가 높아지면 blob reserve도 같이 올라갈 수 있다.

둘째, blob 전송 전략은 base_fee_per_blob_gas 하나만 보면 부족하다. base_fee_per_gas, blob target/max, BPO fork 일정, client config의 blobSchedule, tx inclusion 실패율을 함께 봐야 한다. 특히 롤업 batcher는 “blob 가격이 싼 시간”이 아니라 “전체 posting cost가 예측 가능한 시간”을 찾아야 한다.

5. 내 프로젝트에 적용할 체크포인트

L2, rollup batcher, bridge, indexer, fee estimator, RPC infra를 만든다면 아래를 점검해보자.

비용 모델: blob_fee = blob_gas * base_fee_per_blob_gas만 저장하고 있지 않은가? execution gas, priority fee, proof/cell 생성 비용까지 분리해 기록해야 한다.
fee estimator: blob base fee가 낮을 때도 execution base fee가 높으면 reserve 효과로 다음 구간 비용이 달라질 수 있음을 반영하는가?
BPO 대응: target, max, baseFeeUpdateFraction을 하드코딩하지 않고 chain config나 client RPC에서 확인하는가?
alert 기준: blob fee 1 wei만 “싸다”로 표시하지 말고, base_fee_per_gas 대비 blob reserve 비율을 함께 관측하는가?
batch 정책: L2 batcher가 “싸면 무조건 크게 보낸다”가 아니라 inclusion latency, retry, mempool drop, fee cap 초과를 같이 고려하는가?
사용자 안내: 앱의 L2 수수료 설명에서 “DA 비용”과 “L1 실행·정산 비용”을 구분해 보여줄 수 있는가?

6. 오늘 10분 액션

내가 쓰는 L2 또는 rollup의 수수료 breakdown 문서를 열고, DA fee와 execution fee가 분리되어 있는지 확인한다.
최근 block explorer나 fee API에서 base_fee_per_gas와 base_fee_per_blob_gas를 같이 본다.
아래 질문에 답해본다.

zsh — 생존확인.sh

우리 시스템의 fee estimator는 blob base fee가 1 wei에 가까울 때도
execution base fee 상승을 위험 신호로 보고 있는가?

batcher나 relayer가 있다면 config에 blob target/max를 하드코딩한 부분이 있는지 검색한다.
장애 가정 하나를 적는다: “BPO fork 이후 blob max가 바뀌었는데 우리 estimator가 옛 값을 쓰면 어떤 사용자가 손해를 보는가?”

7. 더 볼 자료

중복 회피 메모

최근 blockchain_dev 글은 PeerDAS/data availability, Ethereum gas/block size limits, EIP-7928 block-level access list, OP Stack interop, Chainlink CCIP TokenPool upgrade, ZK settlement mismatch 등을 다뤘다. 이번 글은 PeerDAS의 DA 샘플링 자체나 block gas/RLP size 제한이 아니라, EIP-7918이 blob fee market에 execution-cost 기반 reserve를 넣어 가격 신호를 복구하는 원리에 집중했다. 따라서 기존 DA 확장 글과 연결되지만, 주제의 중심은 “데이터가 있는가”가 아니라 “데이터 사용 가격이 노드 비용을 제대로 반영하는가”다.

오늘 10분 액션+5%