PeerDAS 이후 롤업 비용을 볼 때, 왜 ‘데이터가 어디에 있나’부터 물어야 할까

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 롤업 수수료가 싸졌다는 말보다 먼저, 그 롤업 데이터가 어떤 가정으로 사용 가능하다고 검증되는지 설명할 수 있는가?
• 핵심 출처:
  • Ethereum.org - PeerDAS - 최종 업데이트 2026-04-22, 확인일 2026-06-08
  • Ethereum Foundation Blog - Protocol Priorities Update for 2026 - 2026-02-18, 확인일 2026-06-08
  • Ethereum Foundation Blog - Checkpoint #8: Jan 2026 - 2026-01-20, 확인일 2026-06-08
  • EIP-7594: PeerDAS - Peer Data Availability Sampling - 생성일 2024-01-12, 확인일 2026-06-08
  • Teku Docs - PeerDAS - 확인일 2026-06-08
  • L2BEAT - Data Availability Summary - 라이브 데이터, 확인일 2026-06-08

1. 왜 지금 봐야 하나

2026년에 롤업을 보는 개발자에게 중요한 질문은 더 이상 “이 L2가 싸냐”에서 끝나지 않는다. 더 정확한 질문은 이 L2가 상태 전이를 검증하는 데 필요한 데이터를 어디에, 어떤 신뢰 가정으로 게시하느냐다. Ethereum은 Fusaka 업그레이드로 PeerDAS를 메인넷에 올렸고, 2026년 1월 Ethereum Foundation의 Checkpoint #8은 BPO1·BPO2가 실제로 활성화되어 blob target이 14, max가 21까지 올라갔다고 정리했다. 같은 글은 세 번째 BPO는 당장 우선순위가 아니며, 현재 확장된 용량을 blob 사용량이 충분히 채울 때까지 기다리는 분위기라고 설명한다.

이 말은 두 가지를 동시에 뜻한다. 첫째, Ethereum DA는 실제로 더 커졌다. 둘째, 확장은 한 번에 끝나는 마법이 아니라 측정하면서 올리는 운영 절차가 됐다. 개발자가 수수료 차트만 보면 “blob 공간이 늘었으니 롤업 비용은 계속 내려가겠지”라고 생각하기 쉽다. 하지만 PeerDAS의 핵심은 가격보다 검증 방식의 변화다. 모든 노드가 모든 blob을 받는 모델에서, 노드가 일부 column만 보관·샘플링하고도 데이터 가용성을 판단하는 모델로 이동했기 때문이다.

L2BEAT의 DA 요약도 이 관점을 강화한다. 2026년 6월 8일 확인 시점, Ethereum DA가 확보하는 value secured는 약 356.2억 달러로 표시되고, EigenDA·Celestia·Avail·Espresso 같은 alt-DA가 별도 범주로 나뉜다. 수수료가 낮은 DA를 쓰는 것은 제품 판단일 수 있지만, 그 순간 bridge, fraud proof, validity proof, exit, indexer가 기대하는 데이터 접근 경로도 같이 바뀐다. 그래서 지금 볼 개념은 “PeerDAS가 싸게 만들었다”가 아니라 데이터 가용성 보증을 어떻게 분산해도 안전하다고 말할 수 있는가다.

2. 핵심 개념

데이터 가용성, 줄여서 DA는 “데이터가 존재한다는 주장”이 아니다. 독립 검증자가 체인 상태를 재구성하거나 분쟁을 제기하는 데 필요한 데이터에 접근할 수 있다는 보증이다. 롤업에서 DA가 깨지면 상태 root가 멋져 보여도 사용자는 그 상태가 어떻게 나왔는지 검증할 수 없다. Optimistic rollup에서는 fraud proof에 필요한 원본 데이터가 사라지고, ZK rollup에서도 증명이 참조한 데이터와 공개 commitment 사이의 연결을 독립적으로 확인하기 어려워진다.

EIP-4844는 이 문제를 위해 blob을 도입했다. blob은 EVM이 실행하지 않는 대용량 데이터 컨테이너이고, 롤업이 L1에 트랜잭션 데이터를 더 저렴하게 올리는 통로가 됐다. 하지만 4844 이후에도 한계는 남았다. 모든 노드가 모든 blob을 다운로드해야 한다면, blob 수를 늘릴수록 home node 운영자의 bandwidth와 storage 부담도 같이 오른다. Ethereum.org의 PeerDAS 문서가 “bandwidth is one of the most sensitive knobs”라고 설명하는 이유가 여기 있다. 싸게 만들겠다고 각 노드의 요구사항을 너무 올리면, 검증자 집합이 데이터센터 중심으로 좁아질 수 있다.

PeerDAS는 이 병목을 샘플링 가능한 데이터 구조로 바꾼다. EIP-7594는 blob을 1차원 erasure coding으로 확장하고, 이를 row와 cell, column으로 나눠 gossip subnet에 배포한다. Ethereum.org 설명에 따르면 확장된 blob data는 128개 column으로 나뉘고, 일반 노드는 최소 8개의 무작위 column subnet에 참여한다. 8/128은 확장 데이터의 1/16이고, 데이터가 2배로 확장됐기 때문에 원본 기준으로는 1/8에 해당한다. Teku 문서는 같은 구조를 “원본 blob은 확장된 128조각 중 아무 64조각으로도 복원 가능하다”고 설명한다.

여기서 중요한 보안 직관은 부분만 봐도 전체가 숨겨졌는지 들킬 확률이 높아진다는 점이다. 공격자가 특정 blob 데이터를 숨기려면, 네트워크의 무작위 샘플링과 column 분산을 동시에 속여야 한다. 또한 EIP-7594는 cell KZG proof를 통해 각 cell이 commitment와 맞는지 검증하게 한다. 즉 PeerDAS는 “믿어라”가 아니라 “작은 조각을 검증하고, 충분한 분산과 복구 가능성으로 전체 가용성을 확률적으로 강제한다”에 가깝다.

3. 최신 이슈와 연결

Ethereum Foundation의 2026년 Protocol Priorities Update는 2025년을 Pectra와 Fusaka의 해로 정리한다. Pectra는 EIP-7702와 blob throughput 확대를, Fusaka는 PeerDAS와 BPO를 가져왔다. 2026년부터는 Scale, Improve UX, Harden the L1이라는 세 트랙으로 재조직됐고, Scale 트랙에는 consensus, execution, blob scaling이 함께 들어간다. 이 배치는 중요하다. DA 확장은 단순히 L2 수수료팀의 일이 아니라 consensus networking, execution resource pricing, node operator 현실이 모두 얽힌 프로토콜 운영 문제라는 뜻이다.

Checkpoint #8은 더 실무적인 상태를 보여준다. Fusaka 이후 BPO forks가 실제 업그레이드 절차로 작동했고, Ethereum은 full hard fork cycle을 기다리지 않고 blob parameter를 조정할 수 있게 됐다. BPO1은 target/max를 10/15로, BPO2는 14/21로 올렸다. 하지만 세 번째 BPO는 blob 사용량이 기존 증가분을 충분히 사용할 때까지 우선순위가 아니라고 했다. 개발자 관점에서는 이 문장이 매우 현실적이다. 프로토콜 capacity는 “가능한 최대치”가 아니라 관측 가능한 수요, p2p 안정성, 클라이언트 준비도에 따라 단계적으로 열리는 자원이다.

EIP-7594의 세부사항도 애플리케이션 개발자에게 영향을 준다. 이 EIP는 transaction-level blob limit, 즉 한 트랜잭션당 6 blob 제한을 도입하고, 클라이언트가 submission, network receive, block production, block processing 단계에서 이를 강제해야 한다고 쓴다. 또 기존 blob transaction wrapper의 proof 구조가 cell proof 중심으로 바뀐다. 롤업 batcher, blob 제출 파이프라인, fee estimator, mempool 모니터링을 만드는 팀은 “Ethereum이 blob을 더 많이 받는다”만 보면 안 된다. 한 tx에 몇 blob까지 넣는지, cell proof 생성 비용이 어디로 이동하는지, client 버전이 어떤 wrapper를 기대하는지까지 봐야 한다.

마지막으로 L2BEAT의 DA 분류는 개발자의 선택지를 현실적으로 보여준다. Ethereum은 enshrined DA bridge로 분류되고, alt-DA는 No Bridge, DACert verifier, Vector 등 서로 다른 bridge risk를 가진다. 어떤 프로젝트가 Ethereum blob 대신 외부 DA를 쓰면 수수료와 throughput은 좋아질 수 있다. 하지만 그때 L1 bridge가 직접 blob data availability를 consensus rule로 거부하는 모델과는 다른 가정이 들어온다. 즉 “DA가 있다”는 말은 항상 어느 validator set, 어느 bridge, 어느 slashing 또는 attestation, 어느 recovery path를 함께 물어야 한다.

4. 개발자 관점 해석

첫 번째 해석은 롤업 비용 최적화는 보안 예산 최적화와 분리할 수 없다는 점이다. blob fee가 낮아지면 batch를 더 자주 올릴 수 있고 사용자 수수료도 내려간다. 그러나 DA를 더 싼 곳으로 옮기거나 압축률을 극단적으로 높이면, 분쟁 시 필요한 데이터 재구성 비용과 운영 의존성이 올라갈 수 있다. 비용 절감은 항상 “누가 데이터를 들고 있고, 누가 검증하며, 누가 실패를 감지하나”와 같이 봐야 한다.

두 번째 해석은 전체 다운로드에서 샘플링으로 바뀌면 관측 지표도 바뀐다는 점이다. 예전에는 blob sidecar를 받았는지, 저장 기간 안에 조회되는지를 보는 것으로 충분해 보였다. PeerDAS 이후에는 column subnet 참여, custody column 수, sampling 실패율, reconstruction 요청, supernode 의존도 같은 p2p 지표가 더 중요해진다. 인프라 팀이 beacon node 로그를 “노드 운영자 영역”으로만 밀어두면, 롤업 제품 장애를 늦게 볼 수 있다.

세 번째 해석은 supernode는 중앙화 위험이자 회복 장치라는 점이다. Ethereum.org와 Teku 문서는 4096 ETH 이상 validator balance와 연결된 노드가 모든 column subnet을 구독하고 모든 column을 custody하는 supernode가 된다고 설명한다. 이들은 데이터 gap을 heal하는 데 도움을 준다. 하지만 제품팀은 동시에 “우리의 blob 관측과 복구가 소수 대형 운영자의 상태에 지나치게 의존하지 않는가”를 봐야 한다. 분산 시스템의 안전장치는 종종 새로운 운영 집중 지점을 만든다.

네 번째 해석은 BPO는 개발 일정표에도 영향을 준다는 점이다. hard fork만 쫓던 팀은 “다음 named upgrade가 언제인가”만 캘린더에 넣는다. 그러나 BPO는 blob parameter만 별도로 바꾸는 절차다. fee estimator, batch sizing, alert threshold, blob inclusion SLA, archive/indexer 비용 모델은 named fork 사이에도 바뀔 수 있다. 롤업이나 데이터 인프라를 운영한다면 BPO를 release note가 아니라 capacity change event로 취급해야 한다.

다섯 번째 해석은 DA 선택은 bridge 보안 문서에 들어가야 한다는 점이다. 사용자에게 “Ethereum-secured rollup”이라고 말한다면, 그 의미는 settlement만 Ethereum인지, DA도 Ethereum인지, 아니면 external DA와 별도 bridge attestation을 쓰는지 분리해서 설명해야 한다. 특히 출금 지연, fraud proof window, proof generation, reorg 대응, data pruning window는 모두 DA 경로와 연결된다.

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

1. 롤업 또는 온체인 앱이 의존하는 DA 경로를 문서화하라. Ethereum blobs, calldata, Celestia, EigenDA, Avail, DAC, committee처럼 이름만 쓰지 말고 bridge와 검증 방식을 같이 적어라.

2. batcher 설정에서 blob target, max blobs per block, per-transaction blob limit, retry policy, fee cap을 분리해라. BPO 이후에는 이 값들이 프로토콜 이벤트에 따라 달라질 수 있다.

3. blob 데이터 조회 경로를 두 개 이상 확인하라. consensus client API, indexer, archiver, 자체 저장소 중 어느 하나만 믿으면 18일 안팎의 pruning window나 provider 장애 때 검증 경로가 막힐 수 있다.

4. DA 실패 모드를 세 가지로 나눠라. 데이터가 늦게 전파됨, 일부 column sampling 실패, 데이터 복구/조회 불가는 대응이 다르다. 모두 “blob missing”으로 묶으면 장애 대응이 흐려진다.

5. BPO 이벤트를 모니터링 항목에 넣어라. target/max 변화는 batch 크기, fee volatility, inclusion latency, indexer 저장량을 바꿀 수 있다.

6. 외부 DA를 쓰는 경우 “어떤 조건에서 Ethereum DA로 fallback할 수 있는가”를 정하라. fallback이 없다면 사용자에게 그 신뢰 가정을 명시해야 한다.

7. 보안 리뷰에서 DA를 별도 섹션으로 다뤄라. bridge validator set, slashing, attestation, data withholding, fraud proof data access, archive strategy를 체크리스트로 만들어야 한다.

6. 오늘 10분 액션

1. 지금 쓰는 롤업 하나를 골라 문서나 L2BEAT에서 DA 항목을 찾아라.

2. 노트에 세 줄로 적어라. 데이터는 어디에 게시되는가, 누가 availability를 검증하는가, 데이터가 없으면 사용자는 어떻게 빠져나오는가.

3. 그다음 Ethereum PeerDAS 문서의 숫자 네 개를 외워보라. 128 columns, 일반 노드 최소 8 subnets, 원본 기준 1/8 sampling, 4096 ETH 이상 supernode.

4. 마지막으로 당신의 프로젝트 alert에 추가할 지표 하나를 고르라. 예: blob inclusion latency, batcher blob fee cap hit, beacon node sidecar retrieval error, DA provider attestation delay. 오늘은 구현하지 않아도 된다. 이름을 붙이는 것이 첫 번째 운영 설계다.

7. 더 볼 자료

• Ethereum.org - PeerDAS
  • PeerDAS의 직관, 128 column 구조, BPO 단계적 확장 설명이 가장 읽기 쉽다.
• EIP-7594
  • gossip, discovery, peer request, cell KZG proof, transaction-level blob limit 같은 구현 세부사항을 확인할 수 있다.
• Teku Docs - PeerDAS
  • full node, validator node, supernode의 custody/storage 차이를 운영자 관점으로 보기 좋다.
• Ethereum Foundation - Checkpoint #8
  • Fusaka 이후 BPO가 실제로 활성화된 상태와 14/21 blob parameter를 확인할 수 있다.
• Ethereum Foundation - Protocol Priorities Update for 2026
  • blob scaling이 2026년 Scale 트랙 안에서 L1 execution, ePBS, hardening과 함께 다뤄지는 맥락을 볼 수 있다.
• L2BEAT - Data Availability Summary
  • DA layer와 bridge risk가 프로젝트별로 어떻게 다르게 분류되는지 비교하기 좋다.

중복 회피 메모

최근 blockchain_dev 글은 Gnosis Pay 모듈 control-plane 보안, Arbitrum Nova 오프보딩, Ethereum 네이티브 AA, Zcash 비상 차단, bridge verifier set을 다뤘다. 이번 글은 특정 사고나 지갑 권한이 아니라 Ethereum PeerDAS와 BPO 이후 롤업 DA 검증·운영 지표가 어떻게 바뀌는가에 집중한다. 2026-06-07 글이 AnyTrust/DAC를 체인 축소 관점에서 언급했다면, 이번 글은 Ethereum enshrined DA 내부의 sampling 구조와 blob capacity 운영을 개발자 체크리스트로 바꾼 점이 다르다.