누구나 쉽게 이해하는 플라즈마 EVM
1편 : 블록체인 확장성 문제와 플라즈마 기초
안녕하세요. 철학자(정순형)입니다.
앞으로 총 8편에 걸쳐서 <누구나 쉽게 이해하는 플라즈마 EVM>이라는 제목으로 온더에서 제안한 탈중앙화된 튜링 완전한 사이드체인 <플라즈마 EVM>에 관한 해설글을 시리즈로 연재합니다. 연재의 순서는 다음과 같습니다.
2편 : 전통적인 플라즈마 VS 플라즈마 EVM
3편 : 일반 상태와 그 연산(general state and its computation)
4편 : 진입과 탈출(enter / exit) — 체인간 상태 이전 방법의 문제
5편 : 상태 강제(State Enforcement) — 챌린지와 검증게임
6편 : 데이터 가용성과 공격비용의 문제
7편 : 플라즈마EVM의 경제모델
8편 : 향후 개발 방향과 놓여진 과제들
“사막이 아름다운 것은 어딘가에 샘이 숨겨져 있기 때문이다” -생텍쥐페리
논의 배경 : 퍼블릭 블록체인의 확장성 이슈
2009년 탄생한 비트코인은 당시 하루 처리 거래량 1~2건 수준에서 2016년에는 하루에 10~20만건을 처리하는 거대 네트워크로 성장했습니다(2019년 2월 말 현재는 하루에 34만건정도의 트랜잭션이 발생합니다). 비트코인 블록체인의 거래를 처리해주는 단위블록의 크기는 정해져 있기 때문에(쉽게 말해서 이 시스템이 정해진 시간에 처리할 수 있는 용량의 한계는 정해져 있었기 때문에) 이렇게 급격히 늘어나는 트랜잭션은 비트코인 네트워크에 부담을 주었고, 시스템의 지속가능성을 위해서 이러한 부담을 덜어줄 방법에 관한 엔지니어들의 고민도 깊어졌습니다. 이러한 고민은 비트코인뿐만 아니라 유저가 늘어난 퍼블릭 블록체인들에게 공통으로 나타났는데(거꾸로 확장성 이슈가 없는 퍼블릭 블록체인은 유저가 없는 체인인 것이죠ㅎㅎ 더불어 퍼블릭 체인 프로젝트 로드맵에 이에 관한 고민이 없다면 체인의 확장 의지가 없는 스캠이라고 봐도 무방합니다. )이것을 비트코인의 확장성 문제 혹은 퍼블릭 블록체인의 확장성 문제라고 합니다.
비트코인 커뮤니티는 이러한 문제를 해결하기 위해서 여러 해결책들을 꺼냈고, 이들을 크게 분류하면 결국 1)네트워크 업그레이드(하드포크 혹은 소프트포크)를 통해서 블록 크기를 조정해 처리용량을 키우는 방식과 2) 체인 외부에서 트랜잭션을 처리하고 메인체인에서 이를 정산해 부담을 분산하는 방식으로 나눠지게 됩니다.
1번과 관련된 자료와 논의들은 충분하고, 플라즈마 자체와는 관련이 많이 없기 때문에 이 글에서는 2번 방식에 대해서 주로 이야기를 나누도록 하겠습니다.
온체인 정산과 오프체인 연산 : 라이트닝 네트워크
앞에서 언급했던 비트코인의 확장성 문제 해결을 위해서, 라이트닝 네트워크그룹은 2016년 1월 <The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments>라는 백서를 발간합니다. Joseph Poon과 Thaddeus Dryja 두 사람이 작성한 이 백서에서는 온체인과 오프체인을 구분해서 온체인에서는 비트코인을 잠금(lock, hash time lock)하고 오프체인에서 트랜잭션을 일으킨 이후에 온체인에서 정산하는 방식을 제안합니다. (그리고 이 백서의 1저자인 Joseph Poon은 기억해 두셔야 됩니다. 왜냐하면 몇 년 후에 이더리움의 플라즈마의 개념을 제안한 백서를 쓰게 되니까요.)
그림에서 Alice와 Carol두 사람이 있고, Alice는 Carol에게 주기적으로 지불을 해야하는 상황을 가정해 봅시다. 가운데 다중서명지갑(Multisig Wallet)을 기준으로 좌측에서 Alice는 일정한 금전(여기서는 1 LTC = 1 라이트코인)을 예치해둔 상태로 우측의 라이트닝 네트워크 채널을 열고, 열린 채널에서 거래를 한 뒤에(여기서는 0.1, 0.2LTC를 Alice가 Carol에게 지불)하고 마지막에 채널을 닫을 때 Alice는 0.7 LTC를 가져가게 됩니다(1–0.1–0.2 = 0.7). 다만 이 “소액거래”를 할 때 Alice와 Carol양쪽의 서명을 필요로 합니다. 그리고 이 서명은 블록체인이 아닌 두 사람이 만들어낸 별도의 통로(Channel, 채널)을 통해서 이뤄지죠. 그리고 이 통로는 체인 밖이기 때문에 오프체인(Off-chain)이라는표현을 씁니다.
멀티시그를 기준으로 좌측은 라이트코인 메인체인(온체인 , 멀티시그 지갑 포함)이 되고, 우측은 오프체인이 되죠. 오프체인의 연산은 일일이 온체인에 기록되지 않습니다. 그런 방식으로 온체인의 트랜잭션 처리 부담이 줄어드는 결과를 낳습니다.
여기서 (1.온체인 예치 → 2.오프체인 연산 → 3.온체인 정산)으로 이어지는 라이트닝 네트워크의 트랜잭션 흐름은 매우 중요합니다. 왜냐하면 동일한 방식이 이더리움의 스테이트 채널에 그대로 활용되고 향후 샤딩과 플라즈마에도 영향을 주게 되기 때문입니다.
이더리움의 확장성 문제
튜링 완전한 블록체인을 표방한, 퍼블릭 블록체인 이더리움도 역시나 비트코인과 같은 문제를 겪습니다. 시스템에 유저들이 폭발적으로 늘어나고, 발생시키는 트랜잭션도 기하급수적으로 증가하는 현상이 생긴 것이죠.
2015년 중순에 하루 1300여건 정도 되던 트랜잭션수가 2018년 초에는 하루에 130만건이 발생했습니다(그리고 이 글을 쓰는 현재- 2019년3월2일-도 하루 52만건의 트랜잭션이 발생했고, 하루에만 새롭게 생겨난 어카운트 숫자는 8만4천개를 넘어섰습니다).
트랜잭션이 많이 생겨나면 이걸 처리하는 시스템의 용량(scale)을 늘리면 되는 것 아니냐고 생각하실 수도 있습니다. 이 의견은 기존의 중앙화된 시스템에서는 맞는 말이지만, 퍼블릭 블록체인과 같은 탈중앙화 시스템의 경우에는 무작정 용량을 늘리기에는 제약이 있습니다.
블록체인의 처리용량을 키우는 가장 쉬운 방법은 블록크기를 늘리는 것입니다. 그런데 퍼블릭 체인에서 무턱대고 블록크기를 늘리다가는 시스템의 안정성이 매우 심각하게 저해될 가능성이 높아집니다. 왜냐하면 블록체인의 데이터는 단순히 만들어진다고 다 받아주는 것이 아니라, 참여자들간의 합의(consensus)를 통해 올바른 데이터를 걸러내는데, 블록의 크기가 매우 클 경우 이러한 합의 결과가 분리되어 한동안 경합을 벌이고 그동안 발생한 트랜잭션의 올바름(validity)에 대한 판단을 할 수 없는 문제가 생길 수 있습니다. 다르게 말하면 네트워크 성능이 늘어난 블록 사이즈와 P2P 통신을 감당할 만큼 좋아지지 않는다면 포크가 많이 발생해 네트워크가 불안정해지는 것이죠. 더불어 블록 사이즈가 커지면 마이너의 저장 공간이 많이 필요하니 누구나 풀노드가 되기 어려워 탈중앙성이 저해될 가능성도 있습니다.(Thanks 4000d)
말이 조금 어려운데, 쉬운 예를 들면 블록 크기를 무작정 키울 경우 송금을 하고도 한참을 오래 기다려야 내 송금결과가 확실히 반영된다는걸 알 수 있게 되거나, 혹은 과거에 인정되었던 내 송금기록이 시간이 지나서 거짓이 될 가능성도 높아집니다. 안정적인 시스템은 내가 만들어낸 이체 결과를 바로 확인하고 확신할 수 있는 것이고, 불안정한 시스템은 내가 이체를 하고도 적어도 몇 시간 최악에는 몇 일을 기다릴 필요가 있는 시스템이라고 봤을 때, 블록의 사이즈가 커질수록 후자가 될 수 있다는 것이죠.
블록체인의 용량을 늘리는 두번째 방법은, 트랜잭션 처리에 대한 부담을 분산시키는 것입니다. 그런데 이런 의문이 있을 수 있습니다.
“블록체인은 분산된(혹은 탈중앙화된)시스템이 아닌가요? 이미 분산되어 있는 것 아니에요?”
이 말은 반은 맞고 반은 틀립니다. 왜냐하면 블록체인이라는 시스템은 구조적으로는 분산되어 있지만 논리적으로는 매우 중앙화되어 있기 때문이죠. 말장난 같지만, 이 말은 매우 중요한 의미를 담고 있습니다.
구조적으로 분산되어 트랜잭션이 수없이 많은 노드(컴퓨터)들에 나누어져서처리가 되지만(분산화), 이들이 처리하는 데이터 로직은 모두 동일합니다(중앙화). 예를들어 현재 이더리움 시스템을 구성하는 노드의 숫자는 8500개 정도로(2019년3월 기준) 매우 잘 분산화되어 있지만, 이 노드들은 동일한 스펙과 동일한 로직, 동일한 소스코드로 만들어진 네트워크 프로그램으로 마치 한몸처럼 동작합니다. 노드의 숫자는 8500개지만, 이 시스템은 단1개의 단일 논리로 동작하는 시스템으로 볼 수 있습니다.
만약 이 8500개의 노드가 모두 풀노드(완전노드, 모든 트랜잭션과 블록 생성과정을 검토하는 노드)라면 이 시스템에 100만개의 트랜잭션이 들어오면 100만 * 8500번의 연산이 이뤄질겁니다. 왜냐하면 각각의 노드가 들어온 트랜잭션을 모두 검토해야 하기 때문이죠. 그리고 이 네트워크에 참여할 수 있는 노드의 숫자는 제한이 없기 때문에, 만약 시스템이 더 분산화될수록 트랜잭션 처리에 대한 부담에 이에 비례해서 증가하게 됩니다(네트워크가 활발할때는 노드 숫자가 2만개가 넘었던 적도 있었죠. 그때는 곱하는 배수가 8500이 아니라 2만이 되어야겠죠).
그렇다면 방금 전 이야기한 두번째 방법 트랜잭션에 대한 처리 부담을 “분산”시킨다는 것은 어떤 의미일까요? 여기서 말하는 분산은 단순한 구조적 분산이 넘어선 논리적 분산을 필요로 합니다. 그것도 신뢰가 불필요한 환경이라는 제약(Trustless : 불특정 다수가 참여하지만 서로를 믿을 수 밖에 없는 환경) 내에서 말이죠.
앞으로 살펴볼 플라즈마나 혹은 여기서 다루지는 않았지만 스테이트 채널(state channel) 혹은 샤딩(sharding)도 시작점은 같습니다. 구조적인 분산구조를 넘어선 논리적 분산구조를 Trustless한 환경에서 만들어내자는 공통의 목표를 가지고 있죠. 다만 이를 구현하는 방법과 접근 방식이 다르다고 볼 수 있습니다(이 연재 이후에 시간이 된다면 이 측면에서 세가지 솔루션을 비교해보는 것도 좋을 것 같습니다).
그럼 플라즈마는 어떻게 구조적인 분산을 넘어 논리적인 분산구조를 만들어 내는지 보도록 하겠습니다.
조샙푼과 비탈릭 뷰테린의 플라즈마(Plasma: Scalable Autonomous Smart Contracts)
비트코인의 라이트닝 네트워크를 생각해냈던 조샙푼은 이더리움에도 유사한 방식으로 온-오프체인 방식을 통해 확장성을 넓힐 수 있을 것이라는 아이디어를 냈고, 이더리움 재단의 비탈릭 뷰테린과 이야기가 잘 통했습니다. 특히나 이더리움은 샤딩과 스테이트 채널과 같은 오프체인 솔루션들이 있었지만 샤딩은 대규모의 네트워크 업그레이드(하드포크)를 필요로 했기 때문에 시간이 걸리는 일이었고, 스테이트 채널과 같은 솔루션은 당시로서는 1:1채널을 바탕으로한 단순 결제 수준 정도로만 구현이 되어 있었기 때문에 다양한 비즈니스 로직으로 동작하는 Dapp들이 겪는 확장성 문제를 안고 있는 이더리움 입장에서는 플라즈마는 구원투수와 같았습니다.
2017년 8월에 플라즈마 백서가 발간됩니다. 그리고 연이어 12월에 최소기능플라즈마(Plasma MVP)의 최초 커밋이 찍혔고 이듬해 1월(2018년1월)에 최소기능플라즈마(Minimun Viable Plasma)의 구체적인 스펙이 비탈릭에 의해서 공유됩니다.
플라즈마의 목표는 이더리움 메인체인(부모 체인)에서 발생하는 많은 트랜잭션을, 자식 블록체인(child blockchain)으로 분산시켜 처리 부담을 나누고 메인체인에는 이에 대한 최소한의 요약본만을 기록해 혹시나 자식 블록체인에 문제가 생겼을 경우에도 중요한 데이터를 지키는 구조를 만들어 내는것입니다.
위의 문장은 매우 추상적이지만 사실상 플라즈마 체인의 개념 전부를 담고 있습니다. 크게 보면 두 부분으로 나눌 수 있는데, 현재 다양한 플라즈마의 구현체들이 있지만 다음의 개념들은 일관되게 공유하고 있습니다.
- 자식체인의 트랜잭션 요약본을 부모체인에 기록하는 것
- 자식체인에 문제가 생겼을 때 데이터를 지키는 것
하나씩 간략하게 살펴보도록 하겠습니다.
트랜잭션 요약본 생성과 기록
블록체인에서 사용하는 블록(block)이라는 자료구조는 크게 블록헤더(header)와 블록 바디(body)로 이루어져 있습니다. 블록헤더는 블록바디의 트랜잭션들의 요약본인 머클루트(merkle root)값이 들어가 있습니다. 쉽게말하면, 블록은 <요약본>과 <내용>으로 이뤄져 있는 것이죠. 플라즈마체인은 이 블록의 헤더(요약본)를 주기적으로 부모체인(루트체인, 메인체인)에 기록합니다.
플라즈마 체인의 블록헤더 값이 결국 플라즈마 트랜잭션들의 요약값이기 때문에, 플라즈마 블록의 헤더를 부모체인(루트체인, 메인체인)에 기록한다는 것은 결국 자식체인의 요약본을 주기적으로 부모체인에 기록하는 꼴이 됩니다. 그림에서 보면 플라즈마 체인에서 블록 #1, #2, #3이 생성되었고, 만약 각각의 블록에 트랜잭션이 1000개씩 담겨있다면 3천개의 자식체인의 트랜잭션이 단 3개의 부모체인 트랜잭션 기록(commitment)으로 대체된 것을 볼 수 있습니다. 원래는 부모체인에 발생할 3천개의 트랜잭션을 3개로 줄여 부모체인의 부담을 줄여주는 것이죠.
루트체인 입장에서보면 사실상 플라즈마체인은 오프체인이라고 볼 수 있습니다(녹색 박스는 온체인, 나머지는 모두 오프체인). 왜냐하면 루트체인은 플라즈마 체인 트랜잭션의 구체적인 내용을 알지 못하기 때문입니다. 오직 온체인은 기록된 요약본을 바탕으로 오프체인 기록이 문제가 있는지 없는지 판단 및 근거를 유지하는 용도로써만 활용되죠. 온체인에 올린 기록이 오프체인 기록의 일종의 보증서가 되는겁니다.
이러한 측면에서 보면 라이트닝 네트워크나 스테이트 채널에서 온체인의 다중서명 컨트랙트를 이용해서 오프체인 기록을 정산하는 과정과 맥락은 같지만 개념적으로 더 확장된 것이라고 볼 수 있습니다. 라이트닝 네트워크에서 사용된 다중 서명 컨트랙트는 플라즈마 체인에서 루트체인 컨트랙트가 되었고, 이를 통해 플라즈마체인(채널이 체인이 되었죠)은 정산을 넘어서 플라즈마 체인에 기록된 데이터의 무결성 보장을 가능케 함으로써 확장성 솔루션이 해결할 수 있는 비즈니스의 영역를 확장시킬 수 있었습니다.
자식체인에 문제가 생긴 경우 데이터를 지키는 방법
혹시 맹자의 성악설과 순자의 성선설을 들어보신적이 있는지 모르겠습니다. 인간의 주어진 본성에 관한 동양 사상가들의 이론들입니다. 얼핏 보기에 블록체인과 아무런 상관이 없어보이는 이 주제는 의외로 블록체인 이론과 매우 잘 어울립니다. 질문을 하나 드리겠습니다. 사토시 나카모토의 비트코인 백서는 인간의 본성은 악하다는 성악설에 무게를 두고 쓰여졌을까요 아니면 인간의 본성은 선하다는 성선설을 바탕으로 쓰여졌을까요? 정답부터 말씀드리면 퍼블릭 블록체인은 성악설이 조금 더 잘 어울립니다.
퍼블릭 블록체인은 불특정 다수가 참가하는 오픈된 시스템입니다. 이 시스템에는 착한 사람도 참가 하지만, 매우 악한 사람도 들어올 수 있습니다. 만약 시스템이 착한 사람들만을 기준으로 설계되게 된다면 단 한명의 공격자만 있어도 이 시스템은 심각한 부상을 입게 될 것입니다. 그렇기 때문에 자체적인 블록체인을 만드는 모든 프로젝트는 데이터의 신뢰를 부여하는 사람 혹은 컴퓨터(이 사람은 마이너, 벨리데이터, BP 등등 다양한 이름으로 불립니다)가 공격을 시도할 경우(즉 최악의 상황)를 가정하고 있습니다(이걸 비잔틴 상황이라고 부르더군요). 그리고 비트코인 백서는 적어도 시스템에 참여하는 참가자중 악인이 최소한 절반 이하로 유지만 된다면 이 시스템은 문제없이 동작할 것이라는 논증을 한 후에, 블록보상이라는 자체적인 인센티브 구조(시스템 환경 즉 제도-policy)에 의해서 이러한 일이 일어날 가능성이 매우 낮다는 것을 증명해낸 것으로 볼 수 있습니다.
플라즈마 체인도 비슷한 문제를 안고 있습니다. 루트체인에 붙어있는 플라즈마체인의 마이너(혹은 벨리데이터, 오퍼레이터, 체인 운영자)는 불특정 다수를 상정하고 있고, 이 마이너는 때때로 악인이 되어 체인 자체를 망가뜨려 버립니다. 플라즈마 체인이 망가질 경우에도(비잔틴이 될 경우)이 체인 시스템을 이용하는 유저들의 데이터를 지킬 수 있어야 되겠죠.
조샙푼의 해결책은 매우 간단합니다. 가장 최근에 확정된 블록(Last Finalized Block)을 근거로 중요한 데이터를 지키면 된다는것이죠.
이 탈출(Exit)이라는 개념은 너무 추상적이어서 낯설게 느껴지실 수 있습니다. 이더리움 메인넷에 이미 기발행된 토큰을 유통시키는 플라즈마 체인을 만드는 구체적인 예와 비유를 통해서 탈출의 개념을 살펴보도록 하겠습니다.
토큰을 거래하는 목적의 플라즈마 체인 사례
<갑>, <을>, <병> 세 사람이 있다고 가정해봅니다. <갑>은 플라즈마체인의 운영자(플라즈마 오퍼레이터)이자 게임 개발자이고 <을>은 현재 이더리움 메인넷에 발행된 A라는 토큰 100개를 가지고 있습니다. <병>은 아무런 토큰을 가지고 있지 않습니다. A라는 토큰은 <갑>이 만든 게임에서 사용되는데, A토큰을 만든 메인넷에 올린 게임이 너무 느리고 수수료도 많이 내는것이 부담이 되어 플라즈마체인을 만들었습니다. 그리고 아직 플라즈마 체인에서는 아무런 트랜잭션이 일어나지 않았습니다.
즉 최초의 이더리움 메인 체인과 플라즈마 체인의 잔액 상태는 다음과 같습니다.
최초상태 →
- 메인 체인 = {갑 : 0, 을 : 100, 병 : 0}
- 플라즈마 체인 = {갑 : 0, 을 : 0, 병: 0}
그런데 왜 <갑>은 독자적인 체인을 만들지 않고 왜 이더리움을 쓸까요? 왜냐하면 이더리움의 ERC20은 전 세계 거래소들의 실질적인 표준 규격이 되었기 때문입니다. 자체체인을 만들면 이 표준의 지위를 얻기 위해 별도의 고생을 하게 되죠.
<을>은 <갑>이 만들어둔 플라즈마 체인으로 본인의 토큰을 다 옮깁니다(이 과정을 진입-Enter라고 부릅니다). 일단 옮기면 <을>은 수수료 없이 빠른 속도로 <갑>이 만든 게임을 즐길 수 있습니다. 그리고 이걸 플라즈마 블록 #0라고 가정하겠습니다.
<을>이 본인의 잔액을 플라즈마로 옮긴 상태(진입-Enter 직후, 플라즈마 블록 #0) →
- 메인체인 = {갑 : 0, 을 : 0, 병 : 0}
- 플라즈마체인 = {갑 : 0, 을 : 100, 병 : 0}
지금부터는 플라즈마 체인 자체만 보도록 하겠습니다. 메인체인은 더이상 트랜잭션을 신경 쓸 필요가 없습니다. <을>의 자산이 모두 플라즈마 체인으로 옮겨졌기 때문이죠. 다만 메인체인은 주기적으로 플라즈마 체인의 요약본만 받아보면 됩니다.
플라즈마 체인에서 <을>은 <병>에게 A토큰을 0.1만큼 100번, 100번 나눠서 보냅니다(총200번). 트랜잭션 100개가 1개의 블록에 담겼다고 한다면, 현재 플라즈마체인(자식체인)은 #1, #2블록이 진행된 상태라고 볼 수 있죠. 이를 그림으로 보면 다음과 같습니다.
블록 #1, #2에 각각 을이 병에서 0.1토큰을 보내는 트랜잭션 100개가 담겼고 각 블록의 요약값은 루트체인(메인체인)에 기록되었습니다.
지금까지는 아무런 문제가 없습니다. 그런데 블록 #3에서 문제가 생깁니다. 플라즈마 체인을 운영하는 <갑>이 이중지불(Double Spending)을 시도합니다. 허공에서 본인에게 보내는 토큰 1000개를 자식체인에서 만들어냅니다(즉 가짜기록이 만들어 진 것이죠). 이는 충분히 가능한 상황입니다. 왜냐하면 이 체인은 <갑>이 직접 운영하고 있기 때문이죠. 만약 이 토큰 A가 거래소에서 거래라도 된다면, 이러한 잘못된 장부(블록체인)기록에 의한 이중지불은 순식간에 엄청난 금전적 사고로 이어질 수 있습니다. 일단 이 상황을 그림으로 그려보도록 하겠습니다.
탈출(Exit)은 가장 최근에 확정된 블록(Last Finalized Block)을 근거로 중요한 데이터가 플라즈마 체인을 빠져나오도록 하는것이죠. 공격이 발생한 블록#3을 이전에 마지막으로 확정된 블록인 #2이고, 이 기록에 근거한 #2직후의 상태인
- 메인체인 = {갑 : 0, 을 : 0, 병 : 0}
- 플라즈마체인 = {갑 : 0, 을 : 80, 병 : 20}
을 기준으로 <을>과 <병>은 플라즈마 체인을 빠져나옵니다. 탈출(Exit)이 정상적으로 이뤄진 이후에 만약 <갑>이 100토큰을 탈출하려고 한다면 이는 오류가 납니다. 왜냐하면 이미 <을>과 <병>이 각각 80, 20 토큰만큼 빠져나와서 더이상 메인체인에 예치된 토큰 잔액이 없기 때문이죠. <을>,<병>이 탈출한 직전상태는 다음과 같습니다.
<갑>이 공격하고 <을>과<병>의 탈출한 후의 상태 →
- 메인체인 = {갑 : 0, 을 : 80, 병 : 20}
- 플라즈마체인 = {갑 : 1000, 을 : 0, 병 : 0}
최초에 메인체인에서 자식체인으로 들어간 자산은 100토큰이었고, 이는 성공적으로 지켜졌으며 플라즈마 체인에서 <갑>이 시도한 공격은 무력화된 것을 알 수 있습니다.
현재의 사례에서 플라즈마 체인이 탈출(Exit)과정을 통해 지켜낸 데이터는 토큰 잔액(Token Balance) 입니다. 이 데이터 부분을 다양한 플라즈마 구현체들은 각자만의 독특한 방식으로 이를 관리합니다. 플라즈마EVM도 대상 데이터를 다루는 고유의 프로토콜이 있으며 유연한 정책을 통해 무한대의 가까운 상태를 탈출(Exit)대상으로 지정 할 수 있습니다. 이 부분은 이어지는 연재를 통해 다루는 일반상태(general state)과 상태이전(state transition) 이야기를 나누면서 더 상술토록 하겠습니다.
플라즈마가 확장성을 해결하는 방법 — 논리적 부하 분산과 구조적 부하 분산
분산 : 부담을 나누는 것
부하 : 트랜잭션 처리 부담
구조적인 분산 관점에서 플라즈마는 매우 명확합니다. 플라즈마 체인에서 발생하는 트랜잭션의 구체적인 내용은 부모체인에 일체 기록되지 않죠. 다만 플라즈마 체인에서 발생한 블록의 헤더값(요약값)들만 기록됩니다. 원래는 메인체인에서 전부 일어났어야 할 트랜잭션들이 플라즈마체인으로 나눠지면서 구조적으로 분산된 형태를 띄게 됩니다.
논리적인 분산의 관점으로 보면 플라즈마 체인에서 발생한 기록들의 요약본이 부모체인에 기록되고, 해당 요약 기록을 바탕으로 최근 확정된 상태의 데이터만이 논리적으로 올바른(Valid) 트랜잭션으로 인정됩니다. 예를들어 위의 A토큰의 사례로 보면 플라즈마 체인으로 100토큰이 들어갔으니, 빠져 나올 수 있는 토큰도 100토큰 이내여야만 하죠. 요약된 기록과 플라즈마로 진입한 토큰의 총액 두가지를 비교해서 둘 중 하나라도 잘못되었다면 이는 체인의 내용이 논리적으로 오류가 있다고 볼 수 있습니다.
만약 플라즈마 체인이 없다면 메인체인이 부담해야 할 논리적인 부담은 토큰의 총 발행량이 100토큰을 넘는 트랜잭션은 일어나서는 안된다는 점 입니다. 플라즈마 체인은 부모체인의 이 상태를 동결(freeze)시키고 이 부담을 그대로 가져왔죠. 부모체인이 만들어둔 제약 내에서만 유효한 상태변화를 계속 만들어냅니다. 즉, 총 발행량이 100토큰이기만 하고, 토큰 전송 이후에 양쪽 소유자의 토큰 보유량 변화량만 문제없다면 플라즈마 체인의 모든 상태변화는 유효한(valid)한 것이 되는 것이죠.
부모체인의 발행량 100토큰이 모두가 아닌 60토큰만 플라즈마 체인으로 들어온(enter)한 상황을 가정 해 봅시다. 이 경우 자식체인에게 주어진 논리적인 제약은 “플라즈마 체인으로 내려온 토큰의 총 발행량은 60개가 되어야 한다”라는 점 입니다. 이 제약 하에서 이뤄진 정상적인 트랜잭션은 아무런 문제가 없죠. 부모체인은 아직 플라즈마로 진입한 60토큰을 동결하고 오직 40토큰의 소유권 이전에 대한 논리적 부담만을 지게 됩니다. 결국 토큰 소유권 이전에 관한 논리적 부담을 부모체인과 자식체인이 40:60으로 나눠가지는 것이라고 볼 수 있습니다. 재밌는것은, 논리적인 부하를 분산시켰음에도 불구하고 모든 체인을 합쳐 유통 가능한 토큰이 100개라는 전역 상태(Global State)는 지켜지고 있다는 점 입니다. 이 측면에서 보면 구조적으로는 나눠진 것처럼 보이지면 논리적으로는 마치 하나의 시스템처럼 한치의 오차도 없이 수행되고 있는 것을 알 수 있습니다. 이를 논리적으로는 중앙화 되어 있다고 표현합니다.
사실 구조적 탈중앙화와 논리적 중앙화는 (플라즈마 — 부모체인)관계 뿐만 아니라 (이더리움에 속한 풀노드들간의 블록데이터),(스테이트 채널 — 이더리움체인), (각 샤드체인들), (라이트닝네트워크 — 비트코인)등 블록체인 그 자체와 블록체인의 확장성 문제를 해결하려는 솔루션들에게 공통적으로 적용 가능한 개념입니다. 다만 각 솔루션들은 논리적 중앙화를 이뤄내는 접근 방식과 방법이 조금씩 다를 뿐이라고도 볼 수 있죠. 더불어 이 개념은 블록체인 이전의 기존 P2P시스템(토렌트 등)과 블록체인 P2P시스템의 가장 극명한 차이점이기도 합니다.
플라즈마 군웅할거(群雄割據)
누구나 쉽게 이해하는 플라즈마(1편)에서는 플라즈마라는 솔루션들이 나오게된 배경과 다양한 플라즈마 솔루션들의 공통으로 적용할 수 있는 기초 개념을 살펴보았습니다. 그렇지만 어디까지나 이 내용은 공통의 기본 개념일 뿐이고, 이러한 개념을 응용하고 실제 구현을 하면서 매우 다양한 형태의 구현체들이 등장하는 전국시대(戰國時代)가 펼쳐지고 있습니다. 이러한 각각의 플라즈마 구현체들은 각자의 영역에서 각자의 문제들을 해결하고 있으며 각자의 장단또한 명확합니다. 2편에서는 이러한 플라즈마들을 각자가 다루고자 하는 고유의 도메인과 플라즈마EVM이 해결하고자 하는 도메인을 구분하고, 각각의 영역에서 어떻게 문제를 해결하고자 하는지 차이점 위주로 살펴보도록 하겠습니다.
긴 글 읽어주셔서 감사합니다.
참고할 만한 국문 자료, 영상 등
다음의 국문자료와 영상은 플라즈마의 기본 개념과 구현체들을 이해하는데 많은 도움을 줍니다.
- 플라즈마 백서 국문 번역본, Onther Inc.
- 블록체인 확장성 솔루션 시리즈, Decipher
- 이더리움 확장성 이슈 및 해결 방안 (샤딩, 플라즈마), 이더리움 연구회
- 플라즈마 리뷰, Hashed
- 누구나 쉽게 이해하는 플라즈마EVM(영상), Onther Inc.
- Plasma EVM : State Enforcible Construction(영상), Onther Inc.
- Plasma EVM Implementation(영상), Onther Inc.
- 일반상태(튜링완전) 플라즈마 관련 연구 분석(영상), Onther Inc.
- 플라즈마 vs 샤딩(영상), Onther Inc.
이더리움 블록체인 R&D 스타트업 온더(Onther Inc.)에서는 현재 Ethereum client를 그대로 Plasma chain에 올릴 수 있는 솔루션인 Plasma EVM에 대한 구체적인 설계/개발/연구를 진행하고 있습니다. 사이드체인과 플라즈마 체인에 관심을 가지고 계시는 기업, 이를 실제 서비스에 적용하고자 하는 팀, 여기에 기여하고 함께 연구하고 발전 시키고자 하시는 연구자 분들이 계시면 아래의 채널을 통해 언제든지 연락, 질문, 제안을 해주시기 바랍니다. 온더의 문은 항상 열려있습니다.
Github : https://github.com/onther-tech
Facebook : https://www.facebook.com/OntherInc
Telegram : @onther_blockchain
Blog : https://medium.com/onther-tech
E-mail : info@onther.io
