플라즈마와 데이터 가용성(Data availability) 문제 — Part 1 문제 정의와 UTXO

시작하기 전에…

블록체인이라는 기술 영역에 있어서 이를 이해하고자 하는 대중의 시선과 최일선에서 문제를 풀어가는 요즘 기술자들의 고민 간의 높이 차는 항상 존재 해 왔습니다만, 요즘 들어 성능의 문제(Scalability)를 해결하기 위해 매일 하루에도 수없이 쏟아져 나오는 연구들은 이 둘 사이에 완전한 장벽을 만들어 놓은 것처럼 보입니다.

이 글은 여기저기서 피어나는 수많은 기술 가운데서도 이더리움 연구자들이 확장성 해결을 위해서 고민하는 사이드 체인(Plasma)의 데이터 가용성(Data Availability)문제에 관한 연구 진행 상황을 대중 및 다른 분야의 연구자들과 눈높이를 맞추기 위해 작성되었습니다.

온더에서는 앞으로 3부로 나누어 데이터 가용성(Data availability) 문제가 무엇이고 플라즈마에서 이 문제가 왜 중요한지, 그리고 어떻게 해결하려고 하는 지에 대해서 다뤄보도록 하겠습니다.

이 글을 통해 현재 진행중인 기술 진보(technical progress)의 일부 장면을 들춰볼 수 있는 좋은 기회의 장이 마련되기를 희망합니다.

1부: 데이터 가용성의 정의와 기존의 UTXO 모델의 해결 방법

2부: 일반 상태 연산(general computation) 모델에의 적용

3부: 일반 상태 연산(general computation) 모델에서의 해결 방법

• 일반 상태 연산(General computation) 모델: 이더리움과 같이 계정당 state를 가지고 있고 이더리움 가상 머신(Ethereum Virtual Machine; EVM)을 통해 연산 및 저장할 수 있는 모델.

데이터 가용성(Data availability)이란 뭘까요?

데이터 가용성(Data availability) 문제는 블록이나 거래를 검증하려고 할 때 거래 정보를 바탕으로 증거를 만들어야 하는데 거래 정보에 접근하지 못하여 검증하지 못하는 문제를 말합니다.

데이터 가용성 문제는 두 가지로 구분할 수 있습니다.

• 정직하지 못한 풀 노드(dishonest full node)의 정보를 받은 라이트노드(light node)가 검증을 못 하는 경우
• 블록 데이터 인질 상황(block withholding)인 경우로 블록생성자가 블록을 만든 후 사용자들에게 공개를 하지 않은 경우

두가지 경우 모두 플라즈마 구현단계에서 고려해야 할 문제이지만 정직하지 못한 풀-노드(dishonest full node)의 경우는 플라즈마 체인에서 라이트 노드(light node)를 구현 했을 때 고려해야 할 문제입니다. 한편 블록 데이터 인질 상황(block withholding)은 플라즈마의 핵심 기능이라고 할 수 있는 탈출 프로세스(exit process)를 구현 할 때 고려할 문제라고 할 수 있습니다.

따라서 둘 다 문제가 될 수 있지만 구현단계에서는 데이터 인질 문제(block withholding)를 해결한 후에 정직하지 못한 풀-노드(dishonest full node) 문제를 해결해야 하는 선후관계가 있다고 볼수 있습니다.

현재 플라즈마 구현의 경우 개념 증명(Proof of Concept ;POC)만 제시되어 있는 초기 단계이기 때문에 블록 데이터 인질(block withholding) 문제가 주목 받고 있고 연구도 활발히 이루어지고 있습니다.

따라서 이 글에서는 데이터 인질 문제에 한한 데이터 가용성 문제를 다뤄 보도록 하겠습니다.

데이터 가용성 이해의 시작 — 거짓 증명(fraud proof)

데이터가용성(Data availability) 문제를 이해하려면 거짓 증명(fraud proof)이라는 개념부터 이해해야 합니다. 만약 어떤 악의적인 사용자가 유효하지 못한(invalid) 블록(e.g. 거래가 실행되고 난 후의 state root인 post-state root가 다르다거나 트랜잭션(transaction) 정보가 유효하지 않은 것)을 보낸다면 사용자는 이러한 유효하지 못한 블록에 대한 거짓 증명(fraud proof)을 만들 수 있습니다.

거짓증명(fraud Proof)을 만드는 과정은 검증이 필요한 트랜잭션(transaction) 정보를 바탕으로 state를 다시 계산해 보고 state에 대한 머클 루트를 만들어 보는 것입니다. 이 과정에서 오류가 있는 지 확인합니다. 만약 오류가 있다면 유효하지 못한(invalid) 것입니다.

플라즈마에서는 거짓 증명(fraud proof)을 바탕으로 다음과 같은 탈출 게임(exit game)을 할 수 있게 됩니다.

Figure 1. 거짓 증명(fraud proof)을 이용한 탈출 게임(exit game)

(1) 사용자 A는 유효하지 않은 거래를 바탕으로 예치금을 걸고 탈출(exit)을 신청합니다.

(2) 유효하지 않은 거래라는 것을 아는 사용자 B는 거짓 증명(fraud proof)을 만들어 예치금을 걸고 이의를 신청(challenge)합니다.

(3) 메인체인에서는 거짓 증명(fraud proof)이 유효하다는 것을 확인 후 탈출 신청(exit request)을 기각하고 A의 예치금을 몰수합니다.

(4) 이의 제기(challenge)가 성공한 B는 몰수한 금액의 일정 비율을 보상 받습니다.

또는 아래와 같은 상황이 있을 수 있겠죠.

(1) 사용자 A는 유효한 거래를 바탕으로 예치금을 걸고 탈출(exit)을 신청합니다.

(2) 사용자 B는 유효하지 않은 거짓 증명(fraud proof)을 만들어 예치금을 걸고 이의를 제기합니다(challenge).

(3) 메인체인에서 거짓 증명(fraud proof)이 유효하지 않다는 것을 확인 후 A의 탈출 신청(exit request)을 받아들여 메인체인에 반영하고 예치금을 되돌려 줍니다.

(4) 유효하지 않은 거짓 증명(fraud proof)을 제출한 B의 예치금을 몰수합니다.

플라즈마에서의 데이터 가용성 문제

이 방법은 간단하면서도 완벽해 보입니다. 누구도 유효하지 않은(invalid) 거래정보를 바탕으로 탈출(exit)을 할 수 없고 공정한 탈출 게임(exit game)을 할 수 있는 것처럼 보입니다. 하지만 이 탈출 게임(exit game)에는 심각한 결함이 있습니다.

만약 블록생성자(오퍼레이터)가 유효하지 않은(invalid) 거래 정보를 넣은 블록을 만들어 메인체인에 제출하고 사용자에게 전파하지 않는다면 어떻게 될까요? 사용자는 거짓 증명(Fraud proof)을 만들 수 없어 유효하지 못한(invalid) 거래 정보가 있다는 것을 검증할 수 없게 됩니다.

간단한 예를 들어 보면

Figure 2. 오퍼레이터가 블록 데이터 인질극(block withholding)을 한 경우

(1) 사용자 A가 사용자 S에게 10PETH를 보냈습니다.

(2) 오퍼레이터 O는 블록에 유효하지 않은 거래(e.g. A가 O(오퍼레이터인 자신)에 10PETH를 보내는 거래)를 기록하고 메인체인에 제출한 다음 A와 S에게 블록을 전파하지 않습니다.

(3) 오퍼레이터 O는 유효하지 않은 거래를 바탕으로 exit을 시도합니다.

(4) 사용자 S는 블록 인질(block withholding) 공격이라는 것을 알았지만 1번의 거래를 바탕으로 탈출(exit)을 할 수가 없습니다. 블록을 전파받지 않았으니 거래 기록이 없기 때문입니다.

(5) 사용자 A도 블록 인질(block withholding) 공격이라는 것을 알고 기존 거래를 바탕으로 exit을 시도합니다. 하지만 이것은 오퍼레이터 O에 의해 이의제기(chllenge) 당할 수 있습니다.(유효하지 않은 거래 기록을 바탕으로 오퍼레이터는 거짓 증명(fraud proof)을 만들 수 있습니다.)

예에서 보듯 데이터 가용성(data availability) 문제는 검증자가 거짓 증명(fraud proof)을 만들 수 없다는 데 있습니다.

오퍼레이터 O가 A에게 블록을 전파하지 않았으니 유효하지 않은 거래(e.g. A가 O(오퍼레이터인 자신)에 10PETH를 보내는 거래)가 있는 지 알 수도 없고 거짓 증명(fraud proof)을 만들 수 도 없는 것입니다.

오퍼레이터는 유효하지 않은 거래를 만들지 않아도 단순히 사용자에게 전파하지 않은 것만으로 탈출(exit)을 막을 수 있는 상황도 생길 수 있습니다.

만약 그렇다면 오퍼레이터의 악의적인 행동을 찾아낼 방법이 있을 까요? 매우 어렵습니다.

플라즈마 차일드 체인의 풀노드를 운영하고 있는 사람은 블록을 전파하지 않는다는 의심을 제기할 수 있습니다.

하지만 의심일 뿐 악의적인 행동을 했는 지 알 수 없습니다. 왜냐하면 오퍼레이터는 블록을 전파하지 않은 상황에도 블록을 전파 했다고 얘기할 수 있기 때문입니다.

비동기적인 환경에서 블록을 전파하기 때문에 네트워크 환경에 따라 블록전파는 차이가 날 수 있기 때문에 오퍼레이터가 블록 인질극(block withholding)을 하고 있는지 정확히 판단할 수 없습니다. 예를 들면

1. 오퍼레이터 O가 유효하지 않은 거래를 기록한 블록을 생성만 하고 인질극(withholding)을 한다.
2. 풀-노드 사용자 S는 블록 인질 상황(block withholding)을 의심하고 문제를 제기한다.
3. 오퍼레이터 O는 유효하지 않은 거래를 기록한 블록을 지우고 유효한 블록을 만들어 제출하고 전파한다.

이렇듯 일반 사용자는 물론이고 풀노드를 가지고 있는 사용자들도 오퍼레이터가 실제로 블록 인질극(block withholding)을 하고 있는 지 정확히 알 수가 없습니다.

UTXO(Unspent Transaction Output) 모델에서 데이터 가용성 해결 방법

지금까지 블록 데이터 인질(block withholding) 문제를 해결하기 위해 많은 연구가 이루어져 왔습니다.

Plasma MVP — 확인서명(conformation sig)

prepare / commit 방식으로 데이터 가용성 문제를 완화하려 합니다.

예를 보면,

Figure 3. Plasma MVP — 확인 서명(Conformation Sig)

(1) 사용자 A가 사용자 S에게 10PETH를 보냈습니다. (TX_1) — prepare 단계

(2) 오퍼레이터 O는 블록 B_1에 TX_1을 포함하고 제출합니다.

(3) A는 메인체인에서 TX_1이 있는 지 루트해시를 통해 확인하고 S에게 거래를 보냈다는 확인 서명을 합니다. — commit 단계

(4) S가 A에게 5PETH를 보냈습니다.(TX_2)

(5) 이번에는 오퍼레이터 O가 블록 B_2에 TX_2를 receiver를 O로 바꿔 기록하고 제출한 다음 블록 인질극(block withholding)을 합니다.

(6) 오퍼레이터 O가 exit을 시도하지만 불가능합니다. S가 TX_2에 대한 확인 서명을 하지 않았기 때문입니다.

(7) S는 블록 인질 상황(block withholding)이라는 것을 알고 TX_1과 A의 확인 서명을 가지고 탈출(exit)할 수 있습니다.

하지만 이 모델은 UTXO 에서만 가능하다는 제약이 있고 거래를 보낼 때 서명을 2번해야 한다는 점에서 번거롭다는 단점이 있습니다.

David Knott plasma map without confirmation

서명을 2번하는 것을 없애는 대신 탈출 게임(exit game)에 두 가지 새로운 룰을 적용한 방법입니다.

1. 거래는 생성되고 메인체인 2블록 이내에 기록되어야 한다.

2. 거래 인풋은 최소 자식체인 3블록 전에 생성되어야 한다.

첫 번째 규칙은 블록 인질극(block withholding)을 계속 하는 것을 막기 위해서이고 두 번째 규칙은 탈출 게임(exit game)을 최대 3단계(exit request, challenge, rechallenge)까지 만들기 위함입니다.

가능한 시나리오는 다음과 같습니다.

Figure 4. no confirmation 시나리오

t+0: (1) 사용자 A가 사용자 S에게 10 PETH를 보냈습니다. (TX_1)

t+1: (2)오퍼레이터 O는 TX_1을 withhold합니다.

t+2: (3)오퍼레이터 O는 유효하지 않은(invalid) 블록을 만들고 해쉬를 메인체인에 제출. 블록을 전파하지 않음

t+2: (4) S는 블록 B가 인질이 된 것(withholding)을 인지했지만 TX_1의 거래데이터가 없으므로 탈출(exit) 못 함

t+2: (5) A는 이전의 거래를 바탕으로 탈출(exit) 요청

t+3: (6) O가 TX_1의 거래를 기록한 블록 생성 후 메인체인에 제출

t+4: (7) O가 A의 탈출 이의 제기(exit challenge)

t+4: (8) S는 TX_1의 거래를 알게 되었으므로 O의 이의제기(challenge)를 다시 이의 제기(rechallenge)

하지만 이 모델 역시 UTXO 기반으로 한계가 있고 위 시나리오와 같이 최대 3번 머클 루트(merkle root)를 연산해야 된다는 단점이 있습니다.

UTXO 모델, 일반 상태 연산(General computaion) 모델, 데이터 가용성

지금까지 제안한 방법은 UTXO 모델에서 데이터 가용성 문제를 어느정도 해결했다고 볼 수 있습니다. 하지만 기존의 UTXO모델에서는 현재 이더리움에서 구현할 수 있는 탈중앙화어플리케이션(dapp)을 만들기 어렵습니다.

이해를 위해 거칠게 비유를 들자면 비트코인의 스크립트(script) 언어로 스마트 컨트랙트을 만드는 것과 비슷하다고 볼 수 있습니다. 플라즈마 자식체인을 기존 이더리움과 동일한 구조로 만든다면 솔리디티(solidity)나 바이퍼(vyper)와 같은 고-수준(high level) 언어로 스마트 컨트랙트를 만들 수 있습니다. 또한 기존에 사용했던 개발 도구들도 그대로 사용할 수 있습니다.

이러한 장점이 있는 데 왜 state 구조를 쓰지 않고 예전 모델인 UTXO를 쓰는 걸까요? 문제는 데이터 가용성(data availabilty) 문제로 인해 기존의 탈출 절차(exit process)가 제대로 작동하기 하기 힘들다는 데 있습니다. (Why Smart contracts are NOT feasible on Plasma 참조)

따라서 전혀 새로운 방식의 탈출 절차(exit process)를 마련할 필요성이 생겼습니다.

다음 편에는 왜 일반 상태 연산(general computation)을 구현하는게 중요하고 이것이 데이터 가용성(Data availability)과 관련하여 구현하기 쉽지 않은지, 그리고 그 문제를 어떻게 해결하려고 하는지 이야기 해 보도록 하겠습니다.

참고자료

Vitalik — A-note-on-data-availability-and-erasure-coding

ethresear.ch — Why Smart contracts are NOT feasible on Plasma

PARSEC — PLASMA FROM MVP TO GENERAL COMPUTATION

David Knott — Plasma MVP without Confirmations