Workspace IndexDev Notes › When gas stops being one number — data pricing and bandwidth accounting

#24PoC

When gas stops being one number — data pricing and bandwidth accounting

EIP-8131 and EIP-8279 point at charging separately for the resources a transaction actually consumes. A settlement app that posts a lot of bytes and computes very little has been cross-subsidized by the single gas number — and repricing decides which design stays cheap.

Not yet scoped — verification before arithmetic. Read both proposals and write one sentence each on what unit they meter and who pays more under it; if that sentence cannot be written, the card stops there. Then take one month of this project's own transactions, split each into data bytes versus execution, and reprice under separate dimensions. If the total moves a few percent it is a note; if it moves a lot it is a design constraint. Source: 2026-08-26 protocol roundup listing EIP-8131 and EIP-8279 as S-tier L1 scaling (data pricing, bandwidth accounting) — contents and status to confirm at eips.ethereum.org.

Why

A single price for several resources always cross-subsidizes, and the subsidy runs toward whatever is hardest for the network to scale. One gas number covers computation, state growth and bandwidth at once, so somebody is overpaying and somebody is underpaying — and the underpayer is, by construction, the usage pattern the network would most like to discourage. Metering each resource separately is not a fee tweak; it is the network finally charging for what it actually spends.

This already happened once, which is why the card is not speculative. EIP-4844 gave blob data its own market, and the moment it did, rollup cost structure changed and designs that had been optimal stopped being optimal. Nobody had to be convinced by an argument — the bill changed. The proposals in this roundup point the same way for calldata and propagation.

Why it matters for this project in particular. An event or settlement market's on-chain footprint is mostly data — orders, attestations, resolution evidence — against a small amount of computation. That is precisely the profile a data-priced world reprices, and precisely the profile that looks cheapest today. The honest output is not a forecast of gas prices, which nobody can produce, but an elasticity: what share of this project's on-chain cost is bytes. That number is knowable now, and it decides how much attention the proposals deserve.

How it works

One number, five resources

Resource Metered today What separate metering would change Exposure here
Execution — opcodes gas Little; this is what gas was designed for Thin — settlement logic is small
Calldata bytes gas, at a fixed price per byte Its own price, moving with demand Heavy — orders and evidence are bytes
Blob data Its own market since EIP-4844 Nothing — this is the precedent, not the change Already true
State growth gas, and badly The hardest to price honestly; the cost is permanent, the fee is one-off Registries, position maps
Bandwidth / propagation not metered at all A dimension that does not exist yet Large-payload transactions

The measurement, and why it is small

One month of transactions, one split per transaction: bytes versus execution. That produces a single ratio, and the ratio answers the only question that matters before the proposals settle — is this project a data-heavy user or not. If it is, then every design choice that trades computation for calldata (posting evidence rather than recomputing it, storing an order rather than deriving it) is a bet on the current price of bytes staying where it is.

The state-growth footnote worth keeping

Of the five rows, state growth is the one with no honest price anywhere today: the cost is borne forever by every future node, and the fee is charged once. Any card in this catalogue that proposes an on-chain registry — the-record-is-not-the-path, position maps, resolution records — is quietly on the wrong side of that mismatch, and a repricing that fixes it would be aimed at exactly those designs.

Update (2026-09-07) — the blob target is the same decision, upstream

Blobs hit record usage on 2026-09-03 (~6.7 per block, 3-day average 5.9), and the 9/10 inclusion list closes with a quiet line under the FOCIL / 8141-vs-8130 headliners: whether to raise the blob target. Blob fees sit near zero below target and rise exponentially above it, so the two cheap years of data were not protocol generosity — they were demand shortfall. Raising the target is one parameter, but the content is a distribution decision: cheaper rollups, costlier nodes. It is the fourth row of the table above — bandwidth/propagation — finally being priced, and the honest thing to watch on the 9/10 list is not the headliner but how many teams put a blob-parameter proposal near the top. That count reads out rollup unit cost more precisely than any roadmap does.

← All Dev Notes · Workspace Index · Top ↑

가스가 더 이상 숫자 하나가 아닐 때 — 데이터 가격과 대역폭 회계

EIP-8131·EIP-8279가 겨냥하는 것은 트랜잭션이 실제로 쓰는 자원별로 따로 과금하는 방향입니다. 바이트는 많이 쓰고 연산은 거의 안 하는 정산 앱은 그동안 단일 가스 숫자에 교차보조를 받아 왔고, 재가격은 어떤 설계가 계속 싼지를 결정합니다.

아직 범위 미정 — 산수보다 확인이 먼저입니다. 두 제안을 읽고 무엇을 단위로 재는지, 그 아래에서 누가 더 내게 되는지를 각각 한 문장으로 씁니다. 그 문장이 안 써지면 카드는 거기서 멈춥니다. 그다음 이 프로젝트의 실제 한 달치 트랜잭션을 데이터 바이트 대 실행으로 쪼개 분리 차원으로 재가격합니다. 합계가 몇 퍼센트 움직이면 메모이고, 크게 움직이면 설계 제약입니다. 출처: 2026-08-26 라운드업의 S티어 L1 스케일링 항목 EIP-8131·EIP-8279(데이터 가격·대역폭 회계) — 내용과 상태는 eips.ethereum.org 에서 확인.

여러 자원에 가격 하나를 매기면 언제나 교차보조가 생기고, 보조금은 네트워크가 확장하기 가장 어려워하는 쪽으로 흐릅니다. 가스 숫자 하나가 연산·상태 증가·대역폭을 한꺼번에 덮으니 누군가는 더 내고 누군가는 덜 냅니다 — 그리고 덜 내는 쪽은 구조적으로 네트워크가 가장 억제하고 싶은 사용 패턴입니다. 자원별 분리 과금은 수수료 손질이 아니라, 네트워크가 실제로 쓰는 것에 비로소 값을 매기는 일입니다.

이미 한 번 일어난 일이라 이 카드는 추측이 아닙니다. EIP-4844가 블롭 데이터에 자기 시장을 주자마자 롤업의 비용 구조가 바뀌었고, 그때까지 최적이던 설계가 최적이 아니게 됐습니다. 아무도 논증으로 설득될 필요가 없었습니다 — 청구서가 바뀌었으니까요. 이번 라운드업의 제안들은 콜데이터와 전파에 대해 같은 방향을 가리킵니다.

왜 하필 이 프로젝트에 중요한가. 이벤트·정산 시장의 온체인 자국은 대부분 데이터입니다 — 주문, 어테스테이션, 정산 근거 — 반면 연산은 적습니다. 데이터에 값이 붙는 세계가 정확히 다시 매기는 프로필이자, 지금 가장 싸 보이는 프로필입니다. 정직한 산출물은 아무도 만들 수 없는 가스 가격 예측이 아니라 탄력성입니다 — 이 프로젝트 온체인 비용 중 바이트가 차지하는 비중. 그 숫자는 지금 알 수 있고, 제안들에 얼마나 주의를 줄지를 그 숫자가 결정합니다.

동작 방식

숫자 하나, 자원 다섯

자원 지금의 계량 분리 과금이 바꾸는 것 여기서의 노출
실행 — 옵코드 가스 거의 없음. 가스가 원래 설계된 대상 얇음 — 정산 로직은 작다
콜데이터 바이트 바이트당 고정가의 가스 수요에 따라 움직이는 자기 가격 두꺼움 — 주문·근거가 곧 바이트
블롭 데이터 EIP-4844 이후 자기 시장 없음 — 변화가 아니라 선례 이미 해당
상태 증가 가스, 그것도 엉성하게 가장 정직하게 매기기 어려움. 비용은 영구, 수수료는 1회 레지스트리·포지션 맵
대역폭 · 전파 아예 계량되지 않음 아직 없는 차원 큰 페이로드 트랜잭션

측정, 그리고 왜 작은 작업인가

한 달치 트랜잭션, 건당 한 번의 분해 — 바이트 대 실행. 여기서 비율 하나가 나오고, 그 비율이 제안이 확정되기 전에 답할 수 있는 유일한 질문에 답합니다 — 이 프로젝트는 데이터 과다 사용자인가 아닌가. 그렇다면 연산 대신 콜데이터를 쓰는 모든 선택(다시 계산하는 대신 근거를 올리기, 유도하는 대신 주문을 저장하기)은 바이트의 현재 가격이 그대로 있으리라는 베팅입니다.

남겨 둘 상태 증가 각주

다섯 줄 중 상태 증가는 오늘 어디에도 정직한 가격이 없는 항목입니다. 비용은 미래의 모든 노드가 영원히 지고, 수수료는 한 번만 받습니다. 이 카탈로그에서 온체인 레지스트리를 제안하는 카드는 전부 — the-record-is-not-the-path, 포지션 맵, 정산 기록 — 조용히 그 불일치의 잘못된 쪽에 서 있고, 그 불일치를 고치는 재가격은 정확히 그런 설계를 겨냥하게 됩니다.

업데이트 (2026-09-07) — 블롭 목표치도 상류의 같은 결정이다

블롭 사용량이 2026-09-03 사상 최고를 찍었고(블록당 ~6.7, 3일 이평 5.9), 9/10 선호목록에는 FOCIL·8141 대 8130 헤드라이너 아래 조용한 줄이 있습니다 — 블롭 목표치를 올릴 것인가. 블롭 수수료는 목표치 아래에서 0에 수렴하고 위에서는 지수로 오릅니다. 그러니 지난 2년의 싼 데이터는 프로토콜의 선의가 아니라 수요 부족이었습니다. 목표치 상향은 파라미터 한 줄이지만 내용은 분배 결정입니다 — 롤업은 싸지고 노드는 비싸집니다. 위 표의 네 번째 줄 — 대역폭·전파 — 이 비로소 값이 매겨지는 것이고, 9/10 목록에서 볼 정직한 것은 헤드라이너가 아니라 몇 팀이 블롭 파라미터 제안을 상위에 올렸는지입니다. 그 수가 어떤 로드맵보다 롤업 원가를 정확히 읽어 줍니다.

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑