Celestia 데이터 가용성 검증: 해시의 한계에서 DAS와 NMT까지

"해시가 맞다"와 "데이터를 실제로 받을 수 있다"는 서로 다른 문제입니다. 이 차이가 데이터 가용성(Data Availability) 문제의 본질이며, Celestia는 이를 EDS(Extended Data Square), DAS(Data Availability Sampling), NMT(Namespaced Merkle Tree)라는 세 요소의 조합으로 해결합니다. 이 글은 왜 단순 해시 검증으로는 부족한지에서 출발해, DAS의 확률적 보장과 NMT의 네임스페이스 검증까지 검증 관점에서 하나의 흐름으로 정리합니다. 데이터 구조와 저장 전략 자체는 자매 글 Celestia 데이터 구조와 저장 전략: ODS, EDS, ODSQ4에서 다룹니다.

단순 해시 검증이 놓치는 것

블록 생산자가 헤더의 해시만 공개하고 본문 데이터를 숨기는 경우를 생각해 봅니다.

무결성 검증(해시 일치 확인)은 통과할 수 있습니다.
하지만 실제 데이터의 재구성이나 검증은 불가능합니다.

즉 해시 검증은 데이터의 "일관성"을 보장할 뿐 "가용성"은 보장하지 않습니다.

Data Withholding 공격

대표적인 시나리오는 다음과 같습니다.

유효한 헤더와 루트를 배포합니다.
일부 본문 데이터를 공개하지 않습니다.
노드는 헤더는 수용하지만 상태를 재검증할 수 없습니다.
결과적으로 체인이나 롤업의 신뢰성이 약화됩니다.

이 공격을 확률적으로 탐지하려면, 실제로 데이터 일부를 무작위로 요청해 응답 가능성을 확인하는 절차가 필요합니다. Celestia가 EDS와 DAS 조합을 쓰는 이유가 여기에 있습니다.

EDS + DAS + NMT: 세 요소의 역할

Celestia의 핵심 질문은 단순합니다. "노드가 전체 데이터를 내려받지 않아도, 데이터가 공개되었음을 어떻게 믿을 것인가?" 답은 세 요소의 조합입니다.

EDS로 복구 가능성 확보: 블록 데이터를 2차원으로 확장해, 일부가 누락되어도 복구 가능한 구조를 만듭니다. 확장 방식과 저장 전략은 자매 글에서 자세히 다룹니다.
DAS로 가용성 샘플 검증: 라이트 노드는 무작위 샘플 몇 개만 검증해도 데이터 은닉 공격을 높은 확률로 탐지할 수 있습니다.
NMT로 선택적 검증 최적화: 네임스페이스 단위 증명으로 필요한 데이터만 검증해 비용을 줄입니다.

검증 흐름

블록 헤더를 수신합니다.
무작위 샘플/증명을 요청합니다.
루트 일치를 확인합니다.
샘플링 정책을 충족하면 가용성을 수용합니다.

운영 리스크

샘플링 실패율이 급등하는 경우(피어 품질 저하)
저장 윈도우 정책 불일치로 인한 저장 전략 혼선
검증 파라미터 변경 시 노드 간 판단 차이

Celestia의 데이터 가용성 증명은 "모든 데이터를 다운로드"하는 대신 "확률적으로 충분한 검증"을 택한 구조입니다. 핵심은 수학 자체보다 운영 파라미터의 일관성입니다.

DAS 샘플링 확률: (1/2)^n의 직관

DAS는 블록 전체를 다운로드하지 않고도 데이터 가용성을 검증하기 위한 방법이며, 핵심은 무작위 샘플링의 확률 보장입니다.

기본 동작

라이트 노드가 EDS 좌표를 무작위로 선택합니다.
샘플과 증명을 요청해 검증합니다.
충분한 샘플이 성공하면 블록 가용성을 높은 확률로 수용합니다.

샘플 개수의 의미

라이트 노드의 기본 샘플 수는 보통 고정값(예: 16)에서 시작합니다. 이 값은 절대적인 정답이 아니라 보안과 비용의 균형점입니다.

샘플 수를 늘리면 탐지 확률은 올라가지만 네트워크·지연 비용도 증가합니다.
샘플 수를 줄이면 반대 효과가 나타납니다.

확률 해석

공격자가 데이터 절반을 숨겼다면, 샘플마다 숨겨진 영역을 찍을 확률은 1/2입니다. 독립적인 샘플 n개에서 모두 실패할 확률은 (1/2)^n입니다. 즉 n이 조금만 늘어도 탐지 실패 확률은 급격히 줄어듭니다. 예를 들어 n=16이면 탐지 실패 확률은 (1/2)^16으로, 사실상 무시할 수 있는 수준까지 떨어집니다.

운영에서 보는 지표

샘플 요청 성공률/재시도율
샘플 응답 지연 p95/p99
블록 크기 구간별 실패율
피어별 샘플 불응 비율

DAS는 "완전 검증"이 아니라 "저비용 확률 검증"입니다. 고정값을 그대로 신봉하기보다, 실제 네트워크 품질과 공격 가정에 맞춰 샘플 정책을 튜닝하는 것이 중요합니다.

NMT 구조와 blob 검증

Namespaced Merkle Tree(NMT)는 Merkle Tree의 변형 구조로, 네임스페이스(namespace)를 기반으로 하는 인증 가능한 데이터 구조입니다. Celestia는 특정 네임스페이스에 속하는 데이터만 검증할 수 있도록 이 구조를 사용합니다.

일반 Merkle Tree와의 차이

일반 Merkle Tree는 특정 데이터가 트리에 포함되어 있는지를 빠르게 증명하는 기능은 제공하지만, 네임스페이스 단위로 검색하거나 검증하는 기능은 제공하지 않습니다. 반면 NMT는 네임스페이스 단위 증명을 지원하므로 특정 네임스페이스에 속하는 데이터를 빠르게 검증할 수 있습니다.

네임스페이스 범위 해싱

NMT의 해싱 규칙은 다음과 같습니다.

각 리프 노드는 (namespace, data_hash) 형태로 저장됩니다.
각 내부 노드는 namespace_min = min(left.namespace_min, right.namespace_min), namespace_max = max(left.namespace_max, right.namespace_max)를 계산해, 자식들의 네임스페이스 범위를 유지하면서 해싱됩니다.

이 구조 덕분에 부모 노드만 봐도 그 하위 트리가 어떤 네임스페이스 범위를 포함하는지 알 수 있습니다.

Absence Proof와 blob 검증

특정 네임스페이스에 속하는 데이터가 포함되어 있는지 검증할 때는 네임스페이스 범위 정보를 가진 Merkle Proof를 사용합니다. 만약 해당 네임스페이스의 데이터가 존재하지 않는다면, 범위 정보만으로 "해당 네임스페이스가 없음(Absence Proof)"을 증명할 수 있습니다. 즉 데이터가 있다는 것뿐 아니라 없다는 것도 효율적으로 증명할 수 있다는 의미입니다.

Celestia에서 트랜잭션과 블록 데이터는 blob 형태로 저장되며, 각 blob은 특정 네임스페이스에 속합니다. NMT를 사용하면 특정 네임스페이스의 blob이 존재하는지를 효율적으로 증명할 수 있고, 이는 앞서 설명한 DAS 샘플링과도 맞물립니다. 라이트 노드가 요청하는 샘플이 특정 네임스페이스의 데이터를 포함하는지도 NMT 증명으로 함께 확인할 수 있기 때문입니다. 모듈형 블록체인 구조에서는 애플리케이션마다 다른 네임스페이스를 사용하므로, 필요한 데이터만 선택적으로 검색·검증할 수 있다는 점이 NMT의 실질적인 이점입니다.

정리

단순 해시 검증은 데이터의 일관성만 보장할 뿐 가용성은 보장하지 못합니다. Celestia는 이 공백을 EDS의 복구 가능한 구조, DAS의 확률적 샘플링, NMT의 네임스페이스 단위 증명으로 메웁니다. DAS의 (1/2)^n 확률 모델이 "얼마나 검증해야 충분한가"에 답한다면, NMT는 "무엇을 검증할 것인가"를 좁혀 검증 비용을 줄이는 역할을 합니다. 두 요소가 결합될 때 라이트 노드는 전체 데이터를 다운로드하지 않고도 데이터 가용성을 실용적인 수준으로 신뢰할 수 있습니다.