데이터 가용성은 블록이나 롤업 상태가 유효한지 독립적으로 검증하는 데 필요한 원본 데이터가 네트워크 참여자에게 실제로 제공됐다는 보장입니다. 데이터가 맞다는 증명, 영구 보관, 빠른 조회와는 다른 문제이며 게시 위치에 따라 신뢰 가정이 달라집니다.
요약값만 공개해서는 검증할 수 없다
블록 제작자가 새 상태 루트만 제시하고 그 상태를 만든 거래 데이터를 숨긴다고 가정해 보자. 해시가 형식상 존재해도 다른 참여자는 거래를 다시 실행하거나 잘못된 상태 전이를 입증할 수 없다. 데이터 가용성 문제는 ‘요약의 뒤에 있는 전체 데이터가 공개됐는가’를 다룬다.
Ethereum data availability는 전체 거래 데이터가 독립 블록 검증에 필요하지만 모든 노드가 전부 내려받게 하면 확장성이 제한된다고 설명한다. 가용성 체계는 전체를 저장하지 않는 참여자도 데이터 공개를 높은 확률로 확신하게 만드는 방법을 찾는다.
| 속성 | 묻는 질문 | 충족되지 않을 때 |
|---|---|---|
| 가용성 | 검증 데이터가 공개됐나 | 재실행·사기 증명 불가 |
| 정확성 | 데이터와 계산이 규칙에 맞나 | 잘못된 상태 수용 위험 |
| 지속성 | 나중에도 조회 가능한가 | 역사 재구성·감사 어려움 |
| 접근성 | 사용자 도구로 쉽게 찾나 | 공개돼도 실무 확인 곤란 |
롤업에서 데이터가 자산 회수와 연결되는 이유
옵티미스틱 롤업의 감시자는 게시 데이터로 배치를 재실행해야 잘못을 도전할 수 있다. ZK 롤업은 유효성 증명이 계산의 옳음을 보이지만, 사용자가 상태를 재구성하고 운영자 없이 이어 가거나 출금하려면 데이터가 필요하다.
따라서 ‘증명이 있으니 데이터가 불필요하다’는 말은 지나치게 단순하다. 어떤 최소 데이터가 게시되고 그것으로 계정 잔액과 머클 경로를 재구성할 수 있는지, 운영자 전용 정보가 남는지 문서에서 확인한다.
L1 게시와 외부 DA의 신뢰 가정
데이터를 이더리움 calldata나 blob에 게시하면 이더리움 합의와 데이터 제공 규칙을 활용한다. 외부 DA 네트워크는 별도 합의와 샘플링을 사용하고, 데이터 가용성 위원회는 정해진 서명자 집합의 응답에 의존할 수 있다. 비용·처리량과 신뢰 경계가 함께 바뀐다.
같은 ‘롤업’ 브랜드 안에서도 모드에 따라 데이터 위치가 달라질 수 있다. validium이나 특정 앱 체인은 유효성 증명을 L1에 올리면서 데이터는 외부에 둘 수 있다. 네트워크 이름 대신 현재 배치의 게시 거래와 공식 문서의 DA 모드를 대조한다.
데이터 가용성 샘플링의 직관
샘플링은 각 노드가 전체 데이터를 내려받는 대신 무작위 일부 조각을 요청해 데이터가 널리 공개됐는지 높은 확률로 판단하는 접근이다. 데이터가 오류정정 부호로 확장돼 있으면 제작자가 큰 부분을 숨기면서 임의 샘플 요청을 계속 통과하기 어려워진다.
샘플링은 ‘내가 일부를 받았으니 전체를 영구 보관한다’는 약속이 아니다. 네트워크 크기, 샘플 수, 인코딩 검증, 데이터 보존 창에 따라 보장이 달라진다. 프로토콜 명칭보다 어떤 노드가 샘플링하고 누가 전체를 복구·보관하는지 확인한다.
- 프로젝트 문서에서 DA 모드 이름 확인
- 최근 L1 배치에서 calldata/blob 존재 확인
- 외부 DA라면 검증자 집합·샘플링·보존 규칙 확인
- 운영자 중단 시 상태 복구 도구와 절차 확인
blob은 영구 파일 저장소가 아니다
EIP-4844 blob은 롤업 데이터에 별도 수수료 시장과 제한된 프로토콜 제공 기간을 마련한다. 실행 계층 계약이 blob 본문을 직접 읽는 구조가 아니며, 커밋먼트를 통해 데이터와 연결한다. 롤업은 필요한 기간 데이터가 제공되면 상태를 재구성하고 증명을 처리할 수 있다.
프로토콜의 최소 제공 기간 이후 장기 조회는 아카이브 서비스나 별도 보관자에 의존할 수 있다. 이는 당시 합의가 데이터 가용성을 보장하지 않았다는 뜻과는 다르지만, 수년 뒤 원문을 쉽게 찾는 문제는 별도다. 가용성과 역사 보존을 구분한다.
공개됐다는 보장과 영원히 저장된다는 보장은 같은 말이 아니다.
JOBCOIN 해설
독자가 실제 배치를 확인하는 방법
L2 탐색기에서 배치 또는 상태 업데이트를 선택하고 연결된 L1 거래를 연다. 거래 유형, blob 수 또는 calldata, 제출자, 상태 루트를 기록한다. 공식 문서에서 해당 데이터로 상태를 재구성하는 노드 소프트웨어와 보존 조건을 확인한다.
탐색기가 ‘Data available’이라고 표시해도 판정 기준을 읽어야 한다. 외부 DA 커밋먼트만 L1에 기록된 것인지 데이터 자체가 이더리움에 제공된 것인지 다를 수 있다. 확인 결과에는 체인, 배치 번호, L1 거래 해시, 조회 날짜를 남긴다.
복구 가능성을 더 확인하려면 노드 문서의 데이터 소스 설정을 본다. 새 노드가 과거 상태를 동기화할 때 L1만으로 충분한지, 특정 아카이브 엔드포인트나 스냅샷이 필요한지 구분한다. 스냅샷이 편의 기능인지 필수 신뢰점인지도 확인한다.
데이터 게시 중단은 상태가 즉시 잘못됐다는 뜻은 아니지만 새 거래 처리와 안전한 출금에 영향을 줄 수 있다. 프로젝트의 중단 모드가 거래를 멈추는지, 마지막으로 확인된 상태에서 출금을 허용하는지, 위원회 개입이 필요한지 문서와 계약에서 찾아야 한다.
자주 묻는 질문
데이터 가용성은 클라우드 서버가 온라인이라는 뜻인가요?
그보다 강한 프로토콜 개념입니다. 독립 검증에 필요한 데이터가 참여자에게 공개됐다는 보장을 다루며 단순 웹 API 가동 여부와 다릅니다.
유효성 증명이 있으면 데이터 가용성이 필요 없나요?
증명은 상태 전이의 옳음을 검증하지만 상태 재구성, 검열 저항, 무허가 출금에는 공개 데이터가 여전히 중요할 수 있습니다.
blob 데이터는 사라지면 롤업 자산도 사라지나요?
정상적인 롤업은 제공 기간 동안 데이터를 처리해 상태를 이어 갑니다. 다만 과거 원문 장기 조회와 복구 주체는 별도 보관 구조를 확인해야 합니다.
