Fusaka, PeerDAS, Blob Scaling

도입

L2 수수료는 L2 내부 execution만으로 결정되지 않는다. rollup이 transaction data를 Ethereum에 게시하는 방식, blob capacity, data availability assurance, batch posting 지연이 결제 제품의 economics와 finality policy에 영향을 준다. 그래서 Fusaka와 PeerDAS는 protocol news가 아니라 checkout fee model, paymaster budget, merchant settlement policy의 입력값이다.

2026년 5월 14일 확인 기준 ethereum.org roadmap은 Fusaka가 2025년 12월 3일 production에 들어갔다고 설명한다. 주요 항목에는 PeerDAS, Blob Parameter Only forks, gas limit 및 DoS hardening이 포함된다. 이 강의에서는 "수수료가 낮아진다"는 단순 문장 대신, 어떤 가정을 제품 문서에 넣고 어떤 가정은 monitoring으로 남겨야 하는지 다룬다.

학습 목표

• blob data와 DA assurance가 L2 fee 및 confirmation policy에 주는 영향을 설명한다.
• PeerDAS를 "모든 노드가 모든 blob을 보관하지 않아도 availability를 확인하는 방향"으로 이해한다.
• blob fee 변화가 checkout minimum amount, gas sponsorship, route choice에 미치는 영향을 sensitivity table로 작성한다.
• L2 inclusion, L1 data posting, bridge/CCTP finality를 분리한다.

개념 설명

1. Blob은 싸게 올리는 데이터지만 결제 완료 그 자체가 아니다

Proto-danksharding은 rollup이 calldata보다 저렴한 blob data를 사용해 transaction data를 Ethereum에 게시할 수 있게 만든다. blob data는 EVM에서 직접 읽는 영구 storage가 아니며, rollup 검증과 DA를 위한 별도 데이터 경로다.

2. PeerDAS는 L2 fee를 낮출 수 있지만 fee policy를 없애지 않는다

PeerDAS는 Peer-to-Peer Data Availability Sampling이다. 모든 node가 모든 blob data를 내려받아 보관하는 방식이 아니라, node들이 일부 data를 sampling해 availability를 확인하는 방향으로 확장성을 높인다. 이 방향은 더 많은 blob capacity와 낮은 L2 data cost의 기반이 될 수 있다.

하지만 fee는 여전히 변동한다. rollup batcher 정책, blob market congestion, L2 sequencer fee, paymaster strategy, route provider fee가 함께 작동한다. 따라서 제품 문서에는 "수수료가 내려간다"가 아니라 fee range와 fallback policy가 들어가야 한다.

3. Blob data 흐름

이 흐름에서 app은 두 가지 시간을 본다. 첫째, 사용자가 L2에서 transaction을 본 시간이다. 둘째, rollup data가 L1에 게시되어 더 강한 확인 기준을 만족하는 시간이다. low-value checkout은 첫 번째 기준을 쓸 수 있지만, 고액 merchant settlement나 treasury movement는 두 번째 기준을 요구할 수 있다.

코드로 확인하기

위 신뢰 모델을 코드와 운영 규칙으로 확인한다. 메시지 상태, 최종성, 재시도, 관측 지점이 어디서 분리되는지 보는 것이 목적이다.

백엔드Blob fee 조회 + L2 수수료 시뮬레이션

Ethereum head block에서 blob base fee 를 가져와 L2별 가산 모델로 추정. 사용자에게 노출할 결제 수수료에 변동성 범위를 같이 보여준다.

01import { createPublicClient, http } from "viem";02import { mainnet } from "viem/chains";0304const eth = createPublicClient({ chain: mainnet, transport: http() });0506export async function readBlobBaseFee(): Promise<bigint> {07  // EIP-7516 BLOBBASEFEE opcode 또는 RPC eth_blobBaseFee08  // viem v2 는 별도 method 가 없으므로 raw request 사용09  const fee = await eth.request({ method: "eth_blobBaseFee" as any, params: [] });10  return BigInt(fee as string);11}1213type L2FeeModel = {14  chainId: number;15  l1BlobShareBps: number;   // blob fee 가 L2 transaction cost 에 기여하는 비중16  baseGasOverhead: bigint;  // L2 시퀀서 기본 오버헤드17};1819const FEE_MODELS: Record<number, L2FeeModel> = {20  8453:  { chainId: 8453,  l1BlobShareBps: 7000, baseGasOverhead: 21_000n },  // Base21  42161: { chainId: 42161, l1BlobShareBps: 5000, baseGasOverhead: 30_000n },  // Arbitrum22  10:    { chainId: 10,    l1BlobShareBps: 7000, baseGasOverhead: 21_000n }   // Optimism23};2425export async function estimatePaymentFeeUsd(chainId: number, ethPriceUsd: number) {26  const blobFeeWei = await readBlobBaseFee();27  const model = FEE_MODELS[chainId];28  if (!model) throw new Error(`no fee model for chain ${chainId}`);2930  const blobContribution = (blobFeeWei * BigInt(model.l1BlobShareBps)) / 10_000n;31  const totalWei = model.baseGasOverhead * blobContribution;32  return (Number(totalWei) / 1e18) * ethPriceUsd;33}

운영Blob fee spike 알람 — 변동 50% 초과 시 paymaster 정지

블롭 수수료가 평소의 1.5배를 넘으면 paymaster sponsorship 한도를 자동으로 줄이고 사용자에게 알림.

01type FeeSample = { observedAt: Date; blobBaseFeeWei: bigint };0203export function detectFeeSpike(history: FeeSample[], current: bigint) {04  if (history.length < 12) return { spike: false }; // 1 시간 분량 (5분 간격)05  const recent = history.slice(-12);06  const avg = recent.reduce((a, s) => a + s.blobBaseFeeWei, 0n) / BigInt(recent.length);07  if (avg === 0n) return { spike: false };08  const ratio = Number((current * 100n) / avg) / 100;09  if (ratio > 1.5) {10    return { spike: true, ratio, action: "throttle-paymaster", banner: "현재 네트워크 수수료가 평소보다 높습니다." };11  }12  return { spike: false, ratio };13}

백엔드Confirmation 정책 — L2 inclusion vs L1 blob posting

금액별로 두 시간을 선택. 고액은 L1 blob posting 까지 대기, 일반 결제는 L2 finality 만 본다.

01type ConfirmationPolicy =02  | { kind: "l2-inclusion-only"; blocks: number }03  | { kind: "wait-l1-blob"; minBlobsAfter: number };0405export function pickConfirmationPolicy(amountUsd: number): ConfirmationPolicy {06  if (amountUsd >= 100_000) return { kind: "wait-l1-blob", minBlobsAfter: 1 };07  return { kind: "l2-inclusion-only", blocks: 5 };08}

강의 포인트

실무 예시

백엔드[OPS] Checkout fee sensitivity table

L2별 확인표

흔한 오해와 실패 시나리오

실습 과제

1. 운영Blob dependency checklist 작성: 사용 중인 L2가 Ethereum blobs, calldata, external DA 중 무엇을 쓰는지 확인하고 paid/final/settled 기준에 어떤 영향을 주는지 정리한다.
2. 백엔드Checkout fee sensitivity table 작성: blob fee low/base/spike 시나리오별 checkout minimum amount, gas sponsorship budget, merchant fee, route disable 기준을 표로 작성한다.
3. 운영[INDEXER] Batch delay monitoring 설계: L2 inclusion과 L1 data posting 사이의 지연을 감시하기 위한 metric, alert, 사용자 표시 문구, support action을 설계한다.

완료 기준

1. blob, DA assurance, retrievability, finality를 구분했다.
2. blob fee 변화에 따른 checkout fee sensitivity table을 만들었다.
3. L2 inclusion과 L1 data posting 지연을 감시하는 metric을 정했다.
4. fee spike와 batch delay 때 route disable 또는 settlement hold 조건을 작성했다.

근거 자료

• Fusaka PeerDAS Blob Scaling: 03-크로스체인-L2/07-Fusaka-PeerDAS-Blob-Scaling.md
• Ethereum Roadmap: Fusaka: https://ethereum.org/roadmap/fusaka/
• Ethereum Roadmap: PeerDAS: https://ethereum.org/roadmap/fusaka/peerdas/
• Ethereum Roadmap: Danksharding: https://ethereum.org/roadmap/danksharding/
• Ethereum.org Data Availability: https://ethereum.org/developers/docs/data-availability/