Data Availability

Published in

Decipher Media ｜디사이퍼 미디어

32 min read5 days ago

Disclaimer: 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 Data Availability를 주제로 Weekly Session에서 발표한 내용을 바탕으로 합니다. 해당 글은 Data Availability에 대한 전반적인 내용을 바탕으로 작성자의 주관적인 의견을 포함하여 작성하였으며, 이 보고서에 포함된 어떠한 내용도 투자 조언이 아니며, 투자 조언으로 해석되어서도 안 됩니다.

Author

이재학(@ARS_LJ) of Decipher

Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)

Reviewed By 신성헌, 이현우, 최재우

개요

Data Availability, DA는 데이터 가용성을 나타내는 의미로 본 아티클에서는 DA에 대한 사전 지식이 없는 입문자를 위해 블록체인에서 Data Availability의 의미와 Data Availability가 중요한 이유, Data Availability Problem과 솔루션을 차례대로 알아보고 DA Layer solution의 프로젝트인 Celestia와 Avail의 전반적인 특징과 차이점을 알아보고자 합니다.

본 아티클은 이더리움과 롤업의 기초지식이 있는 독자들을 대상으로 작성되었습니다.

1. 서론

이더리움의 확장성 솔루션 중 롤업이 주요 솔루션으로 채택된 이후에 많은 롤업들이 생겨나고 있습니다. 롤업의 등장 이후 Execution을 롤업이 담당함으로써 이더리움 네트워크의 부하가 롤업으로 분산화되고 이더리움의 확장성 개선은 어느 정도 이루어진 것으로 보입니다.

그러나 이더리움을 L1으로 사용하고 있는 롤업에는 아직도 해결이 필요한 문제점들이 있습니다. 롤업은 L2의 트랜잭션들을 모아 이더리움에 제출하는데, 이더리움에는 저장할 수 있는 데이터의 크기가 작기 때문에 데이터 저장에 큰 비용이 발생하게 됩니다.

이를 해결하기 위해 이더리움은 Blob을 활용하는 EIP-4844, “Proto-Danksharding”을 적용하여 Data Availability 비용을 대폭적으로 절감하였으며, 실제 2024년 3월 이후로 롤업들의 이더리움 체인으로의 Data Availability 비용이 크게 감소하는 것을 확인할 수 있었습니다.

Proto-Danksharding에 관한 내용은 다음 아티클에서 알아볼 수 있습니다.

https://medium.com/decipher-media/proto-danksharding-톺아보기-상-54f9f5d29e43

이번 아티클에선 L2 체인들이 많은 비용을 감당하면서까지 중요시하는 Data Availability가 무엇인지 알아보고, 이더리움 외에 이 Data Availability Problem을 해결하고자 DA Layer를 표방하는 프로젝트들과 그들의 솔루션은 각각 무엇인지, Proto-Danksharding 이후에도 DA Layer가 왜 필요한지 알아보고자 합니다.

2. Data Retrievability & Data Storage

Data Retrievability와 Data Storage는 Data Availability와 자주 혼동되어 사용되는 개념입니다.

Data Retrievability는 과거 거래 데이터를 검색하고 접근이 가능함을 나타내며, Data Storage는 과거 거래 데이터를 기록하고 유지하는 것을 나타냅니다. Data Retrievability와 Data Storage가 블록체인에서 필요한 목적은 다음과 같습니다.

이전 거래 정보 확인
노드 동기화
트랜잭션 데이터 인덱싱 및 제공
NFT 정보 검색

Data Retrievability와 Data Storage를 이용한 대표적인 사례로 Etherscan이 있습니다. 사용자는 Etherscan을 통해 언제든 이더리움 네트워크의 과거 거래 내역과 데이터를 확인해 볼 수 있습니다.

그러나 Data Retrievability와 Data Storage는 Data Availability와 같은 개념은 아닙니다. 이들은 새로운 블록을 검증하기 위해 필요한 데이터가 아니라 블록체인의 과거 데이터의 접근과 연관되어 있어 블록체인의 보안과는 큰 관련이 없습니다. 과거의 데이터를 저장하고 있지 않아도 새로운 블록을 만들고 검증하는 것에는 문제가 없기 때문입니다.

그렇다면 Data Availability는 무엇일까요?

3. Data Availability

Data Availability는 블록체인에서 처음 등장한 개념은 아닙니다. Data Availability의 본래 개념은 데이터가 필요할 때 해당 데이터가 접근 가능하면서 올바른 상태임을 보장할 수 있는 능력을 뜻합니다.

블록체인에서는 누군가를 믿지 않고 개인 개인이 직접 데이터를 검증함으로써 네트워크를 신뢰합니다. 또한 블록체인 네트워크는 누구나 블록의 유효성을 검증할 수 있기 때문에 보안이 유지될 수 있습니다. 이때, 블록체인이 올바른지 검증하기 위해선 검증에 필요한 데이터에 접근이 가능해야 합니다.

즉, 새로운 블록 검증에 필요한 데이터가 모든 네트워크 참여자들에게 언제나 접근 가능함을 보장하는 것이 블록체인에서 Data Availability가 의미하는 것이라 할 수 있습니다. 만약 Data Availability가 보장되지 않아 접근이 불가능한 데이터가 발생해 새로운 블록을 검증하지 못한다면 이는 사용자 뿐만 아니라 블록체인의 전체 보안에도 큰 위협이 될 수 있으므로 Data Availability를 보장하는 것은 블록체인의 보안에 있어서 매우 중요합니다.

Web2에선 주로 중앙화된 서버가 데이터를 관리하는 시스템을 사용하기 때문에 중앙화된 데이터 제공자가 데이터 가용성이 확보되는 인프라를 구축하면 사용자는 이를 신뢰하는 간단한 방법으로 사용할 수 있습니다.

4. Data Availability Problem

Data Availability가 무엇인지, 블록체인에서 왜 중요한 것인지 간략히 알아보았으니 지금부터는 Data Availability과 관련해 어떠한 문제점들이 발생하는지 알아보도록 하겠습니다.

Data Availability Problem 이란 새로운 블록의 트랜잭션 데이터를 다운로드하고 검증할 수 없을 때 발생하는 문제를 말합니다.

이더리움에선 비콘 체인에 의해 선택된 밸리데이터가 트랜잭션을 선택하여 블록을 생성하고 이를 네트워크에 전파합니다. 이 과정에서 만약 일부 또는 전체 데이터를 숨긴다면 네트워크의 합의 과정에 의해 슬래싱이 이루어지고 새로운 밸리데이터가 블록을 만들게 됩니다. 이후 각 노드들은 전파된 블록 데이터를 통해 직접 트랜잭션을 실행하고 블록을 검증합니다. 즉, 이더리움의 블록 생성 과정에서 블록 생성자는 Data Availability를 보장하는 것이 강제되기 때문에 Data Availability Problem이 발생하지 않습니다.

Data Availability Problem은 주로 블록체인 확장성 솔루션에서 발생합니다. 확장성 솔루션에선 보다 많은 트랜잭션을 적은 비용으로 처리하고자 데이터를 오프체인에 저장하거나 Data Availability 보장을 위해 중앙화된 주체를 신뢰해야 하는 신뢰 모델을 사용합니다.

블록체인 트릴레마에 따르면 확장성과 보안, 탈중앙성 3가지를 모두 만족시키기는 힘들며, 이에 따라 확장성을 크게 개선하는 이더리움 확장성 솔루션은 Data Availability Problem이 발생할 수 있으며 이는 보안에 큰 위협이 됩니다.

4–1. Data Withholding Attack

위에서 언급한 Data Availability Problem의 주요 원인은 블록 생성자가 새로운 블록의 일부 데이터를 공개하지 않는 형태의 공격인 Data Withholding Attack입니다.

라이트 노드를 사용하면 이전 블록의 해시, 머클 루트 등이 포함되어 있는 블록의 헤더만을 다운로드 받기 때문에 더 낮은 하드웨어와 컴퓨팅 파워만으로 트랜잭션 검증이 가능해 블록체인의 확장성을 크게 개선하고 보안과 탈중앙성 확보에도 도움이 됩니다. 그러나 라이트 노드는 블록의 전체 데이터를 다운로드하지 않기 때문에 보안을 풀노드에 의존합니다.

악의적인 블록 생성자가 유효하지 않은 트랜잭션을 블록에 포함시킨 뒤, 라이트 노드에게 헤더가 전달돼도 라이트 노드는 트랜잭션을 실행해 보지 않기 때문에 헤더에 유효하지 않은 트랜잭션이 포함되어 있는지 알 수 없습니다.

풀노드는 위 문제를 해결하고 라이트 노드에게 보안을 제공하기 위해 유효하지 않은 트랜잭션을 발견한 풀노드가 라이트 노드에게 제출하여 알려주는 방식인 Fraud Proof 방식과, 헤더에 올바른 트랜잭션만을 담았다는 증명을 포함시켜 라이트 노드에게 전달하는 Validity Proof 방식 2가지를 사용합니다.

그러나 블록 생성자가 일부 트랜잭션의 데이터를 감추고, Data Availability를 제공하지 않는다면 데이터가 없기 때문에 풀노드는 라이트 노드에게 해당 데이터가 유효하지 않음을 증명할 수 있는 Fraud Proof를 제출할 수가 없습니다. 이를 Data Withholding Attack이라고 부르며, Fraud Proof 방식일 경우에 숨겨진 트랜잭션이 유효하지 않은 트랜잭션일 수도 있기 때문에 매우 위험합니다.

Vailidty Proof의 경우도 Validity Proof를 통해 블록 안의 트랜잭션들이 전부 올바르다는 것에 대한 증명이 있으므로 블록에 유효하지 않은 트랜잭션은 포함될 수 없지만, 증명으로 트랜잭션의 데이터를 추출할 수는 없기 때문에 위와 마찬가지로 Data Availability가 보장되지 않아도 라이트 노드에게 이를 증명할 수 있는 방법이 없습니다.

이더리움 확장성 솔루션 중 가장 많이 사용되는 롤업 체인의 경우 시퀀서가 블록 생성을 담당합니다. 롤업 체인은 이더리움에 데이터를 게시하여 온체인 Data Availability를 제공할 수도 있고, 오프체인 Data Availability를 제공할 수도 있습니다. 즉 DA를 제공하는 방식은 프로젝트의 선택에 의해 결정될 수 있습니다. 이때, 만약 L2시퀀서 가 악의적으로 행동하여 Data Availability를 제공하지 않는다면 위와 똑같은 문제가 발생합니다.

5. Data Availabilty Solution

그렇다면 Data Availability Problem을 해결하기 위한 솔루션은 어떤 것들이 있을까요?

가장 간단한 방식은 라이트 노드가 모든 트랜잭션이 실제로 존재하는지 확인해 보는 것입니다. 그러기 위해선 라이트 노드가 검증에 필요한 데이터를 전부 다운로드해야 하기 때문에 풀노드에 비해 가벼운 검증 방식을 취하는 라이트 노드의 의미가 퇴색되므로 옳지 못한 방법입니다.

다른 방법으로는 Data Availability Committee과 Data Availability Sampling이 있습니다. Data Availability Committee는 허가된 노드들이 Data Availability를 제공하는 방식으로 매우 저렴한 비용으로 이용 가능하지만 비교적 낮은 보안과 탈중앙성을 제공합니다.

이번 아티클에서는 Data Availability Sampling을 중심으로 알아보고자 합니다.

5–1. Data Availability Sampling

Data Withholding Attack을 통해 블록 생성자가 전체 데이터 중 일부를 숨겼다고 했을 때, 이를 라이트 노드가 알아차릴 수 있는 방법은 무엇일까요?

Data Availability Sampling(DAS)을 활용하면 라이트 노드가 모든 데이터를 다운로드하지 않아도 모든 데이터가 네트워크 상에 존재하는지 확인할 수 있습니다.

DAS의 핵심 요소는 Erasure Coding입니다. Erasure Coding은 데이터를 여러 조각으로 분할한 뒤, 데이터를 복구하는 데에 사용되는 패리티 데이터를 추가로 저장하여 데이터 중 일부가 손상이 되어도 보유하고 있는 데이터의 조각들로 전체 데이터를 복구할 수 있도록 하는 기술입니다.

예를 들어 A, B, C 데이터를 저장한다고 할 때, P = A+B+C라는 패리티 데이터를 추가로 저장합니다. 데이터 전송 과정에서 데이터 B가 소실되어도, B = P-A-C이므로 전체 데이터를 복구할 수 있습니다.

Erasure Coding에는 다양한 방식이 있지만, 인기 있는 방식으로는 Reed-Solomon Coding, Low-density parity-check code, Turbo codes 등이 있습니다.

풀노드는 Erasure Coding를 통해 데이터를 분할하고 이를 머클 트리로 구성합니다. 이후 블록 헤더에는 데이터의 무결성을 확인할 수 있는 머클 트리의 루트 해시를 포함하여 블록을 생성합니다.

라이트 노드는 전체 데이터를 다운로드하지 않고 무작위로 선택된 데이터의 일부만 다운로드합니다. 데이터 조각을 다운로드할 때 각 조각에 대한 Merkle Proof도 함께 다운로드합니다. 그 뒤 다운로드한 데이터들과 Merkle Proof를 활용하여 블록 헤더에 포함되어 있는 머클 트리의 루트 해시와 일치하는지 검증합니다. 라이트 노드의 샘플링의 횟수가 늘어날수록 네트워크의 신뢰도는 상승합니다.

이는 동전 던지기의 사례로 쉽게 이해할 수 있습니다.

동전을 던졌을 때 항상 앞면이 나오는 동전과 앞면과 뒷면이 반반의 확률로 나오는 동전 2개가 있습니다. 둘 중 하나를 받았을 때, 이 동전이 어떤 동전인지를 확인할 수 있는 방법은 받은 동전을 여러 번 던져보는 것입니다.

첫 번째 동전의 경우 던졌을 때 앞면이 나올 확률은 100%이고, 두 번째 동전이 앞면이 나올 확률은 50%입니다. 따라서 동전을 던져서 앞면이 나올 때마다 이 동전이 앞면만 있는 동전이라는 확률이 50% 증가합니다. 이 과정을 20번 반복하면 99.9999%의 신뢰도를 갖게 됩니다.

DAS가 작동하는 원리도 마찬가지입니다. 라이트 노드가 다운로드한 데이터의 일부는 검증 과정을 통해 데이터 사용 가능 블록과, 데이터 사용 불가능 블록 2가지의 유형으로 나누어질 것입니다. 라이트 노드는 해당 블록이 사용 가능한지 99.9%의 신뢰를 얻을 때까지 샘플링을 진행하면 됩니다.

6. Data Availability Projects

Data Availability 솔루션 프로젝트들은 대부분 DAS를 활용하여 Data Availability Problem을 해결하고자 합니다. 그러나 여기서 한 가지 문제점이 더 발생합니다. 라이트 노드는 DAS 참여를 위해서 풀노드에게 데이터를 요청하는데, 만약 풀노드가 올바르지 않은 데이터를 전송했을 경우, 그 데이터가 유효한 데이터인지 확인할 수 없습니다.

이에 따라 풀노드가 제공하는 데이터가 실제 코드 워드의 일부분이라는 것에 대한 증명과 검증이 필요하며 각기 다른 솔루션을 활용하고 있는 Celestia 와 Avail의 사례를 통해 알아보고자 합니다.

6–1. Celestia

Celestia는 DAS를 가장 먼저 소개한 Fraud and Data Availability Proofs 의 저자인 Mustafa Al-Bassam이 설립하였으며 모듈형 블록체인을 표방합니다.

Celestia는 실행 레이어를 합의와 분리하고, Data Availability Sampling을 활용하여 확장성을 크게 늘림과 동시에 Data Availability Problem를 해결하고자 하는 DA 레이어 프로젝트입니다.

블록체인에는 Execution, Settlement, Consensus, Data Availability(DA) 4가지의 기능이 필요합니다.

Execution : 상태를 올바르게 업데이트하는 트랜잭션의 실행이 수반됩니다.
Settlement : 실행 계층이 증거를 확인하고 사기 분쟁을 해결하고 다른 실행 계층을 연결하는 환경이 수반됩니다.
Consensus : 트랜잭션 순서에 대한 동의를 수반합니다.
Data Availability : 트랜잭션 데이터를 사용할 수 있게 만드는 것을 의미합니다. Execution, Settlement, Consensus에는 Data Availability가 필요합니다.

기존 블록체인인 모놀리틱 블록체인에서는 네 가지 기능 모두를 단일 체인에서 구현했습니다. 모놀리틱 블록체인의 문제점은 Consensus 계층이 수많은 다른 작업을 수행해야 하기 때문에 시스템 처리량에 제한이 있다는 점입니다.

모듈형 블록체인은 이러한 기능들을 모듈형 스택의 일부로 여러 전문 레이어로 분리합니다. Celestia는 Consensus와 Data Availability 기능을 전문적으로 제공하여 Execution 과정을 Consensus와 분리해 다른 체인이 이를 활용할 수 있도록 합니다.

이를 통해 롤업은 Celestia의 Consensus와 Data Availability를 활용하거나 Celestia의 Data Availability만을 사용하는 등 다양한 구조의 블록체인을 설계할 수 있습니다.

즉, 모든 계층이 해당 기능만 최적으로 수행하도록 특화될 수 있어 시스템의 처리량을 높이고, 롤업들이 동일한 DA 계층을 사용할 수 있게 해줍니다.

위에서 알아본 블록체인의 4가지 기능 중 Celestia는 Consensus와 Data Availability의 기능을 지원합니다. 그중 Celestia DA의 핵심 기능 두 가지는 Data Availaility Sampling(DAS)와 Namespaced Merkle Tree(NMT)입니다.

Celestia는 DAS를 위해 2D Reed-Solomon Encoding을 사용합니다.

2D Reed-Solomon Encoding

Celestia의 풀노드는 Erasure Coding 기법 중 하나인 Reed-Solomon Encoding을 여러 번 적용하여 블록 데이터를 패리티 데이터가 포함된 더 큰 정사각형으로 변환합니다. 연장된 데이터는 원본 데이터의 패리티 데이터이므로 데이터의 복원과 Erasure Coding된 각각의 패리티 데이터가 올바른지도 검증 가능합니다.

그 뒤, 확장된 행렬의 행과 열에 대해 각각의 머클 루트가 계산되며 계산된 머클 루트들의 머클 루트는 블록 헤더의 블록 데이터 Commitment로 사용됩니다.

그러나 올바르지 못한 확장 데이터를 생성하는 악의적인 풀노드가 존재할 경우 확장된 데이터가 유효하지 않기 때문에 라이트 노드가 충분히 많은 횟수에 샘플링을 진행하더라도 원본 데이터를 복구할 수 없다는 문제가 있습니다.

Celestia에선 이를 해결하기 위해 잘못 생성된 확장 데이터에 대한 Fraud Proof를 진행합니다.

풀노드는 원본 데이터를 다운로드하여 인코딩을 재구성하고 재구성된 인코딩과 제공된 데이터가 일치하지 않는지 불일치 검증을 진행하여 Fraud Proof를 생성하고 라이트 노드에게 전파할 수 있습니다. 라이트 노드는 정직한 풀노드에게 Fraud Proof를 수신 받으면 해당 블록을 거부할 수 있습니다.

Namespaced Merkle Tree

다음은 Namespaced Merkle Tree(NMT)입니다.

Celestia에선 모든 애플리케이션이 자체 데이터만 다운로드하고 나머지 애플리케이션의 데이터는 무시할 수 있습니다. 이것이 작동하려면 DA 레이어가 제공하는 데이터가 요청된 애플리케이션의 모든 데이터가 제공되어 완전하다는 것을 증명할 수 있어야 하고, 이를 위해 Celestia는 Namespaced Merkle Tree(NMT)를 사용합니다.

NMT는 네임스페이스 식별자에 따라 정렬된 리프와 트리의 모든 노드가 모든 하위 항목의 네임스페이스 범위를 포함하도록 수정된 해시 함수가 있는 Merkle 트리입니다.

네임스페이스 식별자가 접두사로 붙은 해시 함수인 nsHash(x)는 minNs || maxNs || hash(x)형식을 가지며 여기서 minNs는 해시가 나타내는 노드의 모든 리프에서 발견되는 가장 낮은 네임스페이스 식별자이고, maxNs는 가장 높은 식별자 입니다. hash(x) 는 SHA-256과 같은 해시 함수 입니다. nsHash(x)는 x가 리프인지 트리 노드인지에 따라 달라집니다. x가 리프인 경우 해시는 단일 네임스페이스를 가진 하나의 리프만 포함합니다. 따라서, minNs와 maxNs는 동일하게 ns(x)가 됩니다. 즉, nsHash(x) = minNs || maxNs || hash(x)에서 minNs = maxNs = ns(x)가 됩니다.

x가 두 개의 트리 노드가 연결된 것이라면, x = left || right로 표현됩니다. 여기서 left는 leftMinNs || leftMaxNs || hash(left)이고, right는 rightMinNs || rightMaxNs || hash(right)입니다. 이 경우, nsHash(x)의 출력에서 minNs는 leftMinNs와 rightMinNs 중 작은 값이 되고, maxNs는 leftMaxNs와 rightMaxNs 중 큰 값이 됩니다. 즉, minNs = min(leftMinNs, rightMinNs)이고, maxNs = max(leftMaxNs, rightMaxNs)로,

최종 출력값은 nsHash(x) = min(leftMinNs, rightMinNs) || max(leftMaxNs, rightMaxNs) || hash(left || right) 가 됩니다.

이러한 방식으로 NMT는 각 노드가 그 자손들의 네임스페이스 범위를 포함하도록 하여, 특정 네임스페이스의 모든 요소가 포함되었음을 증명할 수 있는 Merkle 증명을 생성할 수 있게 합니다.

Namespaced Merkle Tree 예시 / 출처 : Celestia

위 그림에서 만약 애플리케이션이 Namespace2의 데이터를 요청하면 DA 레이어는 해당 네임스페이스에 속하는 모든 데이터를 제공해야 합니다. 즉, Namespace2에 해당하는 데이터 D3, D4, D5, D6을 제공해야 하며 해당 데이터가 포함된 머클 증명인 노드 N8, N2, N7 또한 증거로 제시해야 합니다.

애플리케이션은 제공된 데이터와 머클 증명을 사용하여 Namespace2에 속하는 모든 데이터가 제공되었음을 검증할 수 있습니다.

그 결과 애플리케이션은 제공된 데이터가 블록 데이터의 일부인지 확인할 수 있고 모든 데이터가 제공되었는지도 확인할 수 있습니다.

만약 NMT를 사용하지 않았다면, 검증을 위해 전체 블록 데이터를 다운로드하고 검증해야 하지만 위와 같이 애플리케이션은 자신이 요청한 네임스페이스에 속하는 데이터만 다운로드하고 검증할 수 있기 때문에 리소스를 크게 아낄 수 있습니다.

모듈형 블록체인과 Celestia에 대한 더 깊은 리서치를 위해선 디사이퍼의 Celestia 시리즈를 읽어보는 것을 추천합니다.

6–2. Avail

Avail은 Polygon의 코파운더인 Anurag Arjun이 설립하였으며 2020년 폴리곤에서 진행되던 Avail 프로젝트가 2023년 3월에 독립되었습니다. Avail은 Celestia와 유사하게 DAS를 통해 Data Availability Problem을 해결하는 솔루션을 가지고 있으며 Avail DA 뿐만 아니라 Avail Nexus, Avail Fusion을 활용해 Web3를 통합하는 Unification Layer를 구축하고자 합니다.

Unification Layer는 위 3가지 계층으로 구성되어 있는 시장의 분열을 해소하고 점점 더 분산화되고 있는 다양한 생태계의 사용자와 개발자에게 통합된 하나의 플랫폼을 제공하는 것을 목표로 하는 통합 계층입니다.

Avail DA

Avail 또한 Celestia와 유사하게 Erasure Coding을 통한 DAS를 지원합니다.

그러나 Avail은 블록을 생성하기 위한 합의 알고리즘으로 Cosmos의 Tendermint를 사용하는 Celestia와 다르게 Polkadot의 BABE와 GRANDPA를 혼용한 하이브리드 원장을 사용하며 Fraud Proof가 아닌 KZG Commitment를 활용한 Validity Proof를 채택합니다.

이는 Celestia가 Fraud Proof 방식을 사용하기 때문에 풀노드의 Erasure Coding이 제대로 이루어졌는지 확인하는 챌린지 기간 동안은 Data Availability를 완전히 확보했다고 보기 힘든 반면, Avail에선 풀노드가 Erasure Coding을 진행하면서 KZG Commit을 블록 헤더에 포함시키기 때문에 블록이 마무리됨과 동시에 Data Availability까지 완전히 확보했다는 점에서 차별점이 존재합니다.

그러나 Commitment를 생성할 때 블록 생성자에게 더 많은 계산 오버헤드가 필요하므로 블록이 더 커질수록 Celestia보다 더 많은 부담과 높은 하드웨어 사항을 요구합니다.

Avail DA의 경우 Validity Proof 방식을 사용하기 때문에 풀노드의 Erasure Coding 과정에서 유효하지 못한 트랜잭션은 블록에 포함될 수 없습니다. 이에 따라 라이트 노드가 풀노드에 의존하지 않아도 되며 충분한 수의 라이트 노드가 있다면 P2P 네트워크에서 샘플링을 통해 데이터를 복구할 수 있습니다.

Avail Nexus

Avail Nexus는 롤업의 통합 계층 역할을 합니다.

Avail Nexus는 다양한 롤업과 Avail의 DA 레이어 사이에 위치하는 맞춤형 ZK 조정 롤업인 검증 허브 역할을 하고 시퀀서 선택/슬롯 경매 운영과 함께 증거 집계 및 검증 역할을 합니다.

Avail Nexus를 사용한다면 개별 롤업의 유효성 증명을 확인할 필요 없이 각 이해관계자는 Avail Nexus에 유효성 증명을 제출하는 모든 롤업의 유효성 증명을 확인하는 단일 집계 증명만 확인하면 됩니다. Avail Nexus는 주기적으로 이더리움과 Avail DA 모두에 간결한 집계 증명을 제출하며 Avail Nexus에 참여하는 롤업은 Avail에서 증명을 집계하고 검증합니다. 검증된 증명은 Avail에서 Ethereum으로 가기 위한 ZKP 기반 합의 증명 브리지인 Vector 브리지를 통해 Ethereum에 게시됩니다.

이들의 비전은 Avail Nexus 위에서 각 이해관계자들이 다른 롤업에 대한 신뢰가 최소화된 액세스를 가지며 연결된 모든 롤업들이 마치 같은 네트워크에 있는 것처럼 상호작용할 수 있고, 사용자에게 최소한의 유동성 파편화로 마찰 없는 경험을 제공할 수 있는 환경을 만드는 것입니다.

위 그림과 같이 블록체인의 수요가 높아질수록 각 dapp이 자체 롤업이 되어 더 분산화되고 복잡한 구조가 발생하게 됩니다. 이는 각 체인들끼리 소통하고 상호작용하고자 할 때 더 심각한 문제가 되며 Avail Nexus는 Nexus Middleware라는 롤업들의 Hub를 통해 런타임 내에서 특정 조건이 충족되는 모든 유효성 증명을 검증해 해당 지점까지 참여한 모든 롤업의 전체 기록과 유효성을 검증하는 단일 집계 증명을 생성합니다. 참여하는 롤업들은 이 단일 증명을 검증하여 다른 모든 롤업의 상태 검증을 수행할 수 있습니다. 또한 해당 시스템은 비동기적으로 구성되어 있어 롤업들 중 한 체인에 문제가 생기더라도 전체 체인이 중단되지 않습니다.

Avail Nexus의 작동 구조를 사용자가 NFT를 마켓 플레이스에서 구매하는 사례를 통해 더 쉽게 알아보고자 합니다.

NFT는 NFT 앱 체인에서 관리되며, 결제는 결제 앱 체인에서 관리됩니다. 먼저 Avail Nexus를 사용하지 않는 케이스입니다. 사용자가 마켓 플레이스에서 NFT 구매를 요청합니다. NFT 체인은 해당 트랜잭션을 처리하고 내역을 Base 레이어에 게시합니다. 또한 롤업 체인에서 해당 트랜잭션이 유효한지 자체적으로 검증해야 합니다. 이와 동시에 사용자는 결제 체인에게도 결제를 요청합니다. 결제 체인 역시 트랜잭션을 처리하고 내역을 Base 레이어에 게시하면서 결제가 완료되었음을 증명하는 데이터를 생성하고 NFT 체인에 전달합니다. 이때 독립적인 브릿지나 메시지 전달 매커니즘이 필요합니다. 모든 과정이 정상적으로 확인되면 NFT체인은 구매자에게 NFT를 트랜스퍼합니다.

Avail Nexus를 이용한 NFT 구매 플로우 / 출처 : Avail

다음은 같은 상황에서 Avail Nexus를 활용했을 때의 프로세스입니다. 구매자는 마켓 플레이스에서 NFT 구매를, 결제 체인에 결제를 요청합니다. 결제 롤업과 NFT 체인은 해당 트랜잭션을 처리하고 State Root, Receipts, ZK Proof를 블록에 포함시킵니다. 이 정보는 Batch로 묶여서 Nxus Middleware로 전달됩니다. Nexus Middleware는 각 체인의 증명을 집계하여 단일 집계 증명을 생성합니다. 이 증명은 다시 각 체인에 전달되어 올바르게 처리되었음을 확인합니다.

위 과정과 같이 각 체인들은 롤업의 유효성 증명을 개별적으로 확인할 필요 없이 단일 집계 증명을 확인하여 해당 시점까지 참여하는 롤업의 모든 유효성 증명을 확인할 수 있습니다.

Avail Fusion

Avail Fusion은 EigenLayer, Babylon Chain 및 Osmosis와 같은 프로토콜의 기존 아이디어를 결합하여 다른 자산의 경제적 보안을 스테이킹하고 빌리는 아이디어입니다.

Avail Fusion은 Avail 생태계와 web3 통합 레이어에 추가 보안을 제공하여 Avail Unification layer를 완성합니다.

Fusion을 사용하면 비트코인 및 이더리움과 같은 다른 주요 생태계의 자산을 Avail 토큰과 함께 스테이킹 할 수 있습니다. 이를 통해 Avail은 기존의 성숙한 자산들을 활용하여 자체 암호 경제적 보안을 강화할 수 있으며 ETH와 BTC 같은 토큰을 활용해 다른 블록체인에 대한 합의를 강화하는 최초의 사례 중 하나가 될 것이라 주장합니다.

Avail Fusion의 프로토타입은 아직 개발 중에 있으며 Avail Fusion이 취할 수 있는 접근 방식에는 두 가지가 있습니다. 첫 번째는 Avail 블록체인의 스테이킹 모듈로, 해당 모듈은 Avail 노드의 자산 팔레트를 통해 여러 외부 토큰을 지원합니다. 두 번째는 자산 변환을 위한 스테이킹 모듈로 외부 자산을 Avail의 기본 토큰으로 변환하고 변환 시 가격 변환 매핑을 유지합니다. 어떤 접근법을 선택할지는 아직 결정되지 않았으며 다양한 요인을 고려한 후에 결정될 예정입니다.

7. 결론

Data Availability와 자주 혼동되어 쓰이는 Data Storage와 Data Availability의 개념 및 차이점, 블록체인에서 Data Availability가 중요한 이유, DA Problem 및 솔루션, Data Availability Sampling과 이를 활용한 두 프로젝트 Celestia와 Avail에 대해 알아보았습니다. 두 프로젝트 모두 DAS를 활용하여 라이트 노드가 전체 데이터를 다운 받지 않아도 Data Availity를 확인할 수 있도록 했지만 합의 매커니즘과 인코딩 증명 방식에서 차이점이 존재함을 알 수 있었습니다.

Celestia는 Fraud Proof 방식을 사용하고 있습니다. Avail에 비해 블록 생성자에게 더 낮은 하드웨어 사항을 요구한다는 강점이 존재하고 15초라는 매우 빠른 시간 내에 블록을 확정 지을 수 있습니다.

Avail의 경우 Validity Proof를 사용하기 때문에 블록을 확정 지음과 동시에 Data Availability를 보장할 수 있습니다. 또한 라이트 노드가 DA 보증을 확인할 뿐만 아니라 Data Availability 자체에도 기여할 수 있습니다.

두 프로젝트 외에도 Eigen Layer의 Eigen DA, Near의 Nuffle, Arbitrum의 Anytrust 등 각각 다른 방법을 통해 Data Availability Problem을 해결하고자 하는 프로젝트들이 있으니 관심이 있으신 분들은 다양한 프로젝트 사례를 조사해 봐도 좋을 것 같습니다.

또한 Proto-Danksharding 이후에 이더리움의 데이터 저장 비용이 크게 개선되었고, 이더리움 2.0에 따르면 이더리움 프로토콜 내에서도 DAS를 통해 Data Availability Problem을 해결하는 로드맵을 가지고 있습니다. Danksharding 이후에도 위의 DA 프로젝트들의 필요성이 있을지, 그들의 전략은 어떻게 변화할 것인지 관심을 가지고 지켜보면 좋을 것 같습니다.