---
title: Data Availability Problem
tags: blockchain, security, scalability
description: 레이어1 확장성 솔루션에서 발생할 수 있는 Data Availability 문제에 대해서 알아본다.
image: https://i.imgur.com/neIqCz8.png
---

<style>

html, body, .ui-content {
background-color: #333;
color: #ddd;
}

.markdown-body h1,
.markdown-body h2,
.markdown-body h3,
.markdown-body h4,
.markdown-body h5,
.markdown-body h6 {
color: #ddd;
}

.markdown-body h1,
.markdown-body h2 {
border-bottom-color: #ffffff69;
}

.markdown-body h1 .octicon-link,
.markdown-body h2 .octicon-link,
.markdown-body h3 .octicon-link,
.markdown-body h4 .octicon-link,
.markdown-body h5 .octicon-link,
.markdown-body h6 .octicon-link {
color: #fff;
}

.markdown-body img {
background-color: transparent;
}

.ui-toc-dropdown .nav>.active:focus>a, .ui-toc-dropdown .nav>.active:hover>a, .ui-toc-dropdown .nav>.active>a {
color: white;
border-left: 2px solid white;
}

.expand-toggle:hover,
.expand-toggle:focus,
.back-to-top:hover,
.back-to-top:focus,
.go-to-bottom:hover,
.go-to-bottom:focus {
color: white;
}

.ui-toc-dropdown {
background-color: #333;
}

.ui-toc-label.btn {
background-color: #191919;
color: white;
}

.ui-toc-dropdown .nav>li>a:focus,
.ui-toc-dropdown .nav>li>a:hover {
color: white;
border-left: 1px solid white;
}

.markdown-body blockquote {
color: #bcbcbc;
}

.markdown-body table tr {
background-color: #5f5f5f;
}

.markdown-body table tr:nth-child(2n) {
background-color: #4f4f4f;
}

.markdown-body code,
.markdown-body tt {
color: #eee;
background-color: rgba(230, 230, 230, 0.36);
}

a,
.open-files-container li.selected a {
color: #5EB7E0;
}

</style>

# Data Availability Problem

배경
---
- 블록체인에서의 확장성(scalability) 솔루션은 블록체인 산업에서 오랫동안 주목하고 있는 가장 핫한 이슈 중 하나이다. 확장성 문제는 어디서부터 시작이 됐을까?
- 블록체인은 거대한 데이터베이스라는 점에서 시작해보자. 블록체인은 분산된 단일 데이터베이스라고 생각할 수 있는데, 노드들은 데이터베이스의 일관성을 유지하기 위해서 데이터를 저장하고, 검증하는 역할을 한다. 처음에는 이 노드들은 작은 데이터만 저장해도 되기 때문에 누구나 참여할 수 있지만, 시간이 흐를수록 블록체인에 많은 양의 데이터가 저장되고, 이를 저장하기 위해서는 범용 PC 이상의 스펙이 요구된다. 예를 들어 이더리움의 노드가 되기 위해서는 7 TB 이상의 스토리지 용량이 필요하다. 그 결과, 노드가 되기 위해서는 점점 더 고스펙의 하드웨어가 요구되고 이는 블록체인의 '탈중앙성'의 가치를 훼손하게 된다.
- 정리하자면, 블록체인에 저장되는 방대한 양의 데이터를 저장하기 위해 요구되는 하드웨어 성능때문에 소수의 참여자만 노드 역할을 할 수 있게 되고, 이는 블록체인의 탈중앙성에 위배된다. 이 이유로, 블록체인의 탈중앙성을 해치지 않으면 확장성은 높일 수 있는 방법 대한 논의가 활발하게 이뤄지고있다.

확장성 솔루션: 라이트 노드
---
- 가장 쉽게 생각할 수 있는 확장성 솔루션은 뭐가 있을까? 소수가 아니라 다수의 노드를 운영할 수 있도록 하면 탈중앙성의 가치가 훼손되지 않을 것 같다. 하지만, 현실적으로 모든 노드들이 수 TB 단위의 용량을 갖고 있을 수 없다. 그러면 작은 용량을 갖고도 블록체인의 노드로 참여할 수 있어야 한다. 이 아이디어에 착안한 방법이 '**라이트 노드 (Light node, Light client)**'다.
- 라이트 노드는 모든 블록체인 데이터를 저장하고 검증하는 *풀노드(Full node)* 와 다르게, 모든 transaction (tx) 에 대한 정보를 갖지 않고, 블록 헤더 정보만 갖고 있다.
- 그러면 여기서 드는 의문은, 라이트 노드는 어떻게 검증을 할까이다. 풀노드는 모든 tx 데이터가 있기 때문에 다른 노드가 보낸 블록과 tx를 모두 검증할 수 있다. 잠깐 여기서 짚고 넘어가자면, 풀노드가 검증을 한다는 행위는 tx를 하나씩 수행해보면서 노드가 전달받은 결과와 비교를 해보는 과정이다. 이를 `Fraud Proof`라고도 부른다.
- Fraud Proof는 블록 안에 있는 tx가 유효한 것인지 검증하는 과정을 의미한다. Fraud proof 를 하는 방법은, tx 를 다시 수행함으로써 state를 다시 계산 (시뮬레이션) 해보고 merkle tree 를 구성한다. 블록 생성자가 보낸 merkle root 와 내가 직접 시뮬레이션했을 때 생성한 merkle root 를 비교한다. (이 과정은 이더리움의 사례를 자세히 설명한 것으로, state와 같은 개념은 이더리움과 같은 smart contract를 다루는 블록체인에 해당된다.)
- 간단히 말하자면, fraud proof는 tx가 유효한 tx인지 직접 시뮬레이션 해보면서 비교하는 과정이다.

> **Merkle Tree**: Merkle Tree는 크기가 매우 큰 데이터에 특정 데이터가 존재하는지 여부를 확인하기 위해서 사용하는 자료구조로, 이진트리 (binary tree)로 구성되어 있다. 블록체인에서는 하나의 블록에 여러 개의 tx가 담기게 되는데, 그 블록에 특정 tx가 담겨있는지 검증하기 위해서 Merkle Tree에서 Merkle Path를 찾는다.

> **Merkle Path**: Merkle Tree 내에서 특정 tx가 존재하는 경로를 의미한다.

> **Merkle Root**: Merkle Tree의 root node를 의미하는 것으로, 특정 블록이 조작되었는지 확인하려면 Merkle Root 만 비교해보면 된다.

[머클 트리](https://www.banksalad.com/contents/%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85%ED%95%98%EB%8A%94-%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8-%EB%A8%B8%ED%81%B4%ED%8A%B8%EB%A6%AC-Merkle-Trees-%EB%9E%80-ilULl)

- 다시 돌아와서, 라이트 노드는 블록 헤더 정보만 갖고 있고, 이를 활용하여 검증을 하려면 스스로 하진 못하고 풀노드를 통한 fraud proof를 통해서만 가능하다. 따라서, 블록 생성자가 블록을 생성해서 전파한다면, 라이트 노드는 신뢰할 수 있는 풀노드에게 검증을 요청하고, 그 결과를 확인하여 블록체인 검증 과정에 참여할 수 있다.
- 이 방법은 블록 생성자가 만약에 특정 tx가 빠진 상태로 보내진 것인지 알 수 없다. 이러한 문제점을 **블록 인질 공격** (block withholding attack) 이라고 부르는데, 특정 tx가 전파되지 않으면 이 블록이 유효한 것인지 아닌지 조차 검증할 수 없다는 것이다. 예를 들어, A라는 사용자가 B라는 사용자에게 50 ETH 를 보냈다는 내역을 빼고 블록이 전파된다면, 라이트 노드는 그 사실을 모른 채 다른 풀노드에게 fraud proof 를 요청하고, 그 블록은 문제가 없다고 판단할 것이다.

확장성 솔루션: 롤업, 샤딩
---
- 이러한 문제는 기본적인 확장성 솔루션인 라이트 노드 외에 최근에 논의되고 있는 *롤업*과 *샤딩* 등 다양한 확장성 솔루션에서도 찾아볼 수 있다. 롤업에 대해서 간단히 이야기하자면, 롤업은 레이어1의 실행 기능 (또는 실행 레이어, Execution Layer)을 별도의 롤업 체인이 수행하도록 분리하고, 롤업 체인에서 수행된 트랜잭션을 모아서 블록 헤더 정보를 레이어1에 기록하는 방법이다. 이 방법은 매 트랜잭션마다 레이어1 체인의 상태를 업데이트 (state change)를 하는 것을 방지하고, 일정 주기로 그때 그때의 상태를 저장함으로써 더 빠른 트랜잭션 처리와 동시에 레이어1 체인의 보안을 활용할 수 있다는 장점이 있다.
- 하지만, 롤업에서도 라이트 노드와 같은 비슷한 문제가 발생할 수 있다. 레이어2의 데이터를 레이어1로 보내주는 `sequencer`가 악의적인 의도를 갖고 특정 블록이나 트랜잭션을 보내지 않는 블록 인질 공격 (block withholding attack)이 있을 수 있다. 위에 언급했던 것처럼 레이어1은 블록 헤더만 전달받기 때문에 레이어1의 검증 노드는 블록 중간에 tx가 빠졌는지 포함되었는지 알 수 없다는 문제점이 있다.

[Rollup 예시](https://messari.io/article/polygon-a-multi-sided-approach-to-zk-scaling)

- 샤딩은 하나의 채굴자 또는 검증자가 블록을 검증할 때, 한 블록의 모든 tx를 검증하는 것이 아니라 블록의 트랜잭션을 여러 개의 chunk 단위로 나눠서 여러 검증자에게 검증을 맡기는 것을 의미한다. 예를 들어, #1000 번 블록에 담겨져 있는 1000개의 tx를 4개의 검증자가 250개씩 나눠서 검증하게 되면 기존 방법보다 4배는 더 빠른 검증 속도를 보여줄 수있다. 이는 블록체인 네트워크의 처리량을 증가시킴으로써 더 많은 트래픽을 처리할 수 있다. 일종의 병렬 처리라고 볼 수 있다.
- 샤딩에서는 어떤 악의적인 사용자가 샤드 내에서 자신에게 할당된 데이터 chunk를 주지 않거나 tx를 왜곡한 상태로 블록을 전달할 수 있다.

Data Availability Problem
---
- 위의 내용을 요약하자면, 라이트 노드, 롤업, 샤딩과 같은 확장성 솔루션에서는 다음의 두 가지 문제점이 있다.
1. 악의적인 노드가 만약에 블록을 보내지 않으면 어떡할까? (= 악의적인 블록 생성자가 블록을 전파하지 않고 메인 체인에 바로 등록하면 어떡할까?)
2. 악의적인 노드가 일부분의 데이터 밖에 못보는 다른 노드 (라이트 노드, 샤딩 노드)에게 일부 tx를 빼거나 조작된 블록을 전달하면 어떻게 그 사실을 알 수 있을까?
- 이 문제를 종합적으로 `Data Availability Problem` 이라고 한다. Data Availability Problem (데이터 가용성 문제)이란, 블록이나 tx를 검증하려고 할 때 거래 내용에 대한 접근이 불가한 경우 발생하는 문제를 의미한다.
- 이를 해결하기 위해서는 `Reed-Solomon Erasure Code`를 활용한 data availability proof 이다. 자세한 내용은 [다음 글](/Hktg2wycc)에서 다룰 예정이다.

참고자료
---
- https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f
- https://whymatters.substack.com/p/data-availability-
- https://medium.com/onther-tech/%ED%94%8C%EB%9D%BC%EC%A6%88%EB%A7%88%EC%99%80-data-availability-%EB%AC%B8%EC%A0%9C-894d66eb2080
- https://arxiv.org/pdf/1809.09044.pdf
- https://coinmarketcap.com/alexandria/article/what-is-data-availability
- https://blog.polygon.technology/the-data-availability-problem-6b74b619ffcc/