블록체인 확장성 솔루션 Side chain이란? feat. Plasma
안녕하세요. Joyce라고 합니다. 이 글은 Side Chain을 처음 접해보았거나, 조금 더 깊이 그 구동 방식에 대해 알고 싶은 사람들에게 적합합니다. 어떠한 오류나 이해가 안가는 부분이 있으면 댓글로 남겨주세요. 열심히 쓴다고 썼습니다.(호다닥)
1.Introduction
How does it work?
Side chain(혹은 service chain) 이 계속하여 언급되는 주된 이유는 Blockchain 의 scalability이다. Chapter 2의 plasma를 알아보기 전에 왜 plasma와 같은 sidechain이 필요한지와 side chain의 기본적인 개념을 알아보자. 최근 scalability 문제에 대해서 여러 프로젝트 별로 다양한 해결책을 제시하고 있는데 크게 2가지로 나눠보면
1. Layer 1 scaling: Upgrading the blockchain themselves modifying the base layer.
2. Layer 2 scaling: Building things on the top of existing systems. Not changing the underlying system.
사이드 체인은 Layer 2 scaling 방식으로써 이 방식의 핵심은 하나의 블록체인에서 (더 작은) 블록체인으로 토큰이나 디지털 자산들을 옮기고,옮긴 블록체인 상에서 돈을 운용하다가 필요할 경우에 다시 원래의 블록체인으로 돌아오는 것이다. 즉, 사이드 체인은 parent chain에 two-way pegging을 통해 붙어있는 분리된 별개의 블록체인인 것이다. 어떻게 사이드 체인이 작동하는가에 대해서 간단히 살펴보면 (더 자세한 사이드 체인별 작동 원리는 다음 챕터에서 다루도록 한다),
일단 한 유저가 Main chain에 있는 자신의 코인을 output address로 보내고 그 코인은 다른 곳에서 쓸 수 없게끔 lock이 된다. 트랜잭션이 완료되고 나서 보안을 위한 일정 기간을 거친 이후에 체인들 간에 confirmation이 공유 되면 같은 양의 코인이 사이드 체인에서 발행되는 것이다. Side chain에서 Parent chain으로 넘어갈 때도 똑같은 과정을 거치게 된다. 만약 Root chain으로 디지털 자산을 다시 옮기고 싶다면 Root chain에 플라즈마 체인의 UTXO를 옮기고 싶다고 주장하면 된다. 일정기간의 Challenge period를 거치게 되면 성공적으로 exit 하는 것이 가능해지게 된다. 이 Challenge Period란 누구든 exit하려는 UTXO가 사용되었거나 유효하지 않다고 주장하는 것이다. 만약 이 challenge가 유효하지 않은 exit proposal을 색출해내는데에 성공을 하게 되면 이 exit에 담보로 있었던 bond가 challenger한테 지급이 되게 된다. (아직 이해가 되지 않으셔도 괜찮습니다)
사이드체인이 도입되기 전에는 이더리움에서는 모든 Dapp이 이더리움 메인 체인 위에서 동작해야만 했다. 크립토 키티만 해도 한 트랜젝션을 처리하기 위해서 다소 긴 시간을 기다려야만 했다.
하지만 플라즈마과 같은 사이드 체인을 도입하게 된다면 대부분의 규모가 있는 Dapp 들은 별도로 용도에 맞는 사이드 체인을 운영하여 높은 편리성을 지니게 될 것이다.
2. Plasma
Plasma에 들어가기 앞서
기본적으로 지금까지 나온 모든 Plasma는 3가지 기본적인 규칙을 따른다. 그는 다음과 같다.
- Publish Merklized Root to MainChain
- Security from Exit
- UTXO based similar to bitcoin
첫 번째로는 MainChain에는 Merklized root의 해쉬값만 올린다. 두 번째로 중요한 것은 Plasma는 자신의 Security를 Side chain의 consensus에서 찾지 않는다. “ 음..그래 누군가 나쁜 짓을 할 수 있긴해 근데 그런 일이 일어나도 걱정 하지마~ 네 돈은 안전하게 메인체인으로 뺄 수 있도록 약속할게!” 느낌이다. 즉 네트워크가 악의적인 행동에 의해 망가지는 것을 예방하는 것이 아니라 일종의 자산 보호 Exit Manual이 있는 것이다. 세 번째로는 account state model이 아닌 bitcoin과 같은 UTXO 모델을 (일단은) base로 하고 있다.
Plasma 의 기본적인 구동 방식 (MVP 기준)
1 . Deposit
일단 처음 플라즈마 블록을 만드려면 메인 체인으로부터 자산을 옮겨 와야한다. 현재 플라즈마에서는 모든 사이드 체인의 운용을 스마트 컨트랙트를 통해서 한다. 즉 rootchain.sol이라는 스마트 컨트랙트를 메인 체인에 올리고 그 창구를 통해 메인체인과 사이드 체인간의 소통이 이루어지는 것이다.
자 그럼 본격적으로 어떻게 Deposit이 이루어질까? Alice가 10ETH을 사이드 체인에서 사용하고 싶다고 하자. 그럼 Alice는 rootchain.sol 의 Deposit function을 불러야 하고 그와 동시에 컨트랙트의 Account안에 10ETH이 Lock-In게 된다. (이 때 Alice가 10ETH를 넣었음을 따로 기록하는 부분은 없다. 총량으로만 기록되게 된다.)
root chain에서 이러한 트랜젝션이 블록에 포함된 것을 본 Side chain의 Operator는 Side chain(child chain)에서 블록을 하나 생성하게 된다. 이 때 생성된 transaction은 유효한 것이 아니다. Alice가 제대로 머클루트가 커밋이 된 것을 보고 나서 Signiture을 하고 그 Tx을 다른 블록에 넣고 나서야 그림에 있는 Block #0 있는 Tx는 유효하게 된다.
왜 이러한 귀찮은 일을 할까? 이는 위에서 다루었던 사이드 체인의 두 번째 규칙과 연관이 있다. 사이드 체인은 안전하게 자신의 자산을 다시 메인 체인에서 되돌릴 수 있다는 것에서 Security를 찾는다. 이 Signiture과정은 Exit의 안정성을 지키기 위해 마련된 장치로써 Operator나 다른 유저의 나쁜 행동에서 유저의 자산을 안전하게 지키는 핵심이라고 볼 수 있겠다. (어떤 공격을 어떻게 막을 수 있는가에 대한 내용은 3 . Exit에 더 자세한 설명을 하겠다.)
2 .Transaction
자, 그렇다면 일단 Deposit이 완료가 되었다. 이제 돈을 유저간에 보내고 받는 과정을 알아보겠다. A가 B에게 3 PETH (Plasma에서의 ETH를 구분하기 위해)를 보내고 싶다.
A는 B에게 3PETH를 보내는 Tx를 생성하고 Operator가 이 Tx를 포함시켜 블록을 생성한다. 그리고 머클루트를 Parent chain에 보내게 된다. 이것을 본 A가 “흠 Operator가 진짜 내 Tx를 맞게 보낸것이 맞군!” 하고
Confirmation Signiture Tx를 만들고 그 Tx가 블록에 포함이 되면 이제 공식적으로 B가 새로운 3 PETH의 주인이 되게 된다.
3 . Exit
Exit을 실시하는 경우는 크게 총 2가지가 있을 수 있다. 첫 번째로는 유저나 Operator의 악의적인 행동으로 사이드 체인의 Security에 심각한 결함이 생겼을 경우이고, 두 번째로는 유저가 그냥 더 이상 메인체인에 자산을 보관하기 싫은 경우가 있을 수 있다. 어떤 경우이던 간에 위의 그림과 같은 일련의 과정을 꼭 거쳐야 한다. 그 과정을 좀 더 자세히 보면, A는 Operator가 아닌 메인 체인의 스마트 컨트랙트에 exit 요청을 일종의 담보와 함께 직접 날린다. 그렇게 되면 A가 Exit하고자 하는 UTXO의 블록 넘버, Tx의 인덱스, 보내는 양에 대한 정보가 공개가 된다. 동시에 Challenge기간이 시작되는 데 이때 Operator 혹은 유저들이 A가 부정한 행동 (Double Spending 혹은 Fake UTXO)을 했음을 Merkle proof를 통해 밝혀내게 되면 A는 Exit을 실패하게 되고 Challenger는 A가 exit 요청시에 걸었던 담보를 보상으로 받을 수 있게 된다. 만약 Challenge 기간 동안 아무도 Challenge하지 않거나 Challenge를 실패 했다면, A는 스마트 컨트랙트에 lock-in 되었던 금액을 본인이 Exit을 신청한 만큼 받을 수 있게 된다.
Plasma 의 종류
a.Plasma MVP
Plasma MVP Overview
MVP는 “Minimal Viable Plasma implementation”의 약자로서 가장 단순화 된 방식으로 최소한의 플라즈마의 특징만 구현하여 나온 스펙이다. 기본적으로 모든 컨센서스 방식이 가능하지만 대부분 PoA방식을 사용하고 있어서 User의 자발적인 신뢰가 필요한 부분이 있다. ETH이나 ERC20과 같은 Fungible Token을 사용한다.
그 외에 MVP가 Cash나 Debit과 다른 점이라고 한다면 아마 우선순위 큐(Priority Queue)가 존재한다는 점일 것이다. 이 우선순위 큐는 여러개의Exit들이 안전하고 효율적으로 처리 될 수 있도록 고안된 방식이다. 조금 더 쉬운 이해를 위해 왜 만약 이러한 우선순위가 없다면 일어날 법한 일을 생각해보자.
- Alice는 계속 Plasma Chain 상에서 거래를 하다가 결국 1ETH의 가치를 갖는 하나의 UTXO를 소유하게 되었다.
- Operator는 유효하지 않은 블록을 만들어내고 이 안에는 Operator가 거짓으로 만들어낸 1ETH의 UTXO가 있다.
- Operator는 바로 이 UTXO를 가지고 Exit 신청을 하게 된다. 이러한 Exit은 challenge를 받을 수가 없다. 왜냐하면 유효하기 때문이다 (Operator가 만들었고, 커밋까지 했으니까!). 그럼 Operator는 1ETH를 들고 튀게된다
- 나중에 Alice가 1ETH의 UTXO를 가지고 Exit을 신청하게 된다고 해도, 이미 Smart contract에서 Lock-in 되었던 1ETH는 Operator가 가져갔기 때문에 가져갈 ETH가 없다 :(
그렇다면 만약 우선 순위가 있었다면 어떻게 달랐을까?
- Alice는 계속 Plasma Chain 상에서 거래를 하다가 결국 1ETH의 가치를 갖는 하나의 UTXO를 소유하게 되었다.
- Operator는 유효하지 않은 블록을 만들어내고 이 안에는 Operator가 거짓으로 만들어낸 1ETH의 UTXO가 있다.
- Operator는 바로 이 UTXO를 가지고 Exit 신청을 하게 된다. 이러한 Exit은 challenge를 받을 수가 없다. 왜냐하면 유효하기 때문이다 (Operator가 만들었고, 커밋까지 했으니까!)
- Alice는 Operator의 악의적인 행동을 감지하고 역시 Exit신청을 하게 된다. 이때! Alice의 Exit은 Operator의 Exit보다 우선 순위가 더 높다. 왜냐하면 Alice의 UTXO가 더 오래된 블록에 포함되어 있기 때문이다.
- Operator의 exit은 다른 exit들이 모두 처리되고 나서야만 처리되게 된다. 하지만 결과적으로 Smart contract에 남아있는 ETH가 없으므로 Exit의 의미가 없다.
우선 기본적으로 Exit priority를 정하는 방법은 Block Number가 낮은 것, 이게 같다면 트랜젝션의 인덱스가 낮은 것, 이것도 같다면 Output Index를 따른다.
Plasma MVP 에서는 blockNumber * 1000000000 + txIndex * 10000 + outputIndex를 priority로 정하는 데에 사용하고 있다.
Plasma MVP Use Case — Omisego DEX
일단 Omisego는 2013년도에 설립된 핀테크 기업으로서 분산화된 전자결제 블록체인 오픈소스 플랫폼이다. 이 기업은 플라즈마 MVP 구조를 이용한 이더리움에서 분산된 금융을 위한 확장 솔루션으로 널리 알려져 있다. (비탈릭이 오미세고에 남다른 애정을 보이고 조언자 역할을 하고있다고 한다..) Omisego의 주 목적은 불법 이민자나 노동자들과 같은 소외계층에 금융권의 혜택을 받게 해주는 것이며, 전자 지갑을 원하면 만들고 기존의 플랫폼보다 훨씬 저렴한 수수료로 사용할 수 있도록 했다.
이런식의 탈 중앙화된 거래소 서비스는 반드시 트랜젝션이 많이 일어날 수 밖에 없다. 하지만 현재 이더리움 메인넷으로는 결정적으로 속도가 따라주지 않기 때문에 Plasma MVP를 이용하여 그 문제를 해결하려고 하고 있다. (현재 Plasma Cash 역시 연구 개발단계에 있는 듯 싶다…)
코드를 봐보자. (코드를 보는 것은 선택적으로 읽어주세요 :-D)
위에서 다루었던 우선순위 큐에 대한 내용을 직접 구현했으므로 한 번 그것을 코드로 보고 직접 이해해 보자.
위와 같이 startExit function을 실행하게 되면 마지막에 addExitToQueue function이 실행되게 되고 그 exit이 queue상에 추가되게 된다.
addExitToQueue function을 더 자세히 살펴 보면,
startExit function에서 넘겨받았던 파라미터들을 가지고 priority를 계산함을 알 수 있다. 계산과정이 끝나고 나서야만 ExitStarted Event가 발생이 되게 되고 공식적으로 Exit의 Challenge기간이 시작되게 된다. 그 외 Deposit이나 Challenge에 관한 코드 내용은 위의 출처를 들어가 확인 할 수 있다. 100번 설명을 보는 것보다 코드를 읽는게 이해에 더 도움이 될 것이다. (만약 개발자시라면..?◕ᴗ◕)
b.Plasma Cash
Plasma Cash Overview
: 플라즈마 MVP 와 마찬가지로 컨센서스 매커니즘이 필요하며 PoA와 같은 single부터 PoS와 같은 large set까지 될 수 있다. MVP와 가장 큰 다른 점이라고 한다면 Plasma cash 의 자산은 Non-fungible token(NFT)으로 이루어져 있다. 즉 모든 토큰은 고유한 토큰이며 똑같은 토큰은 있을 수가 없다. 플라즈마 컨트랙트에 Deposit을 하려고 할 때 Plasma cash에서는 총 2가지가 생성되어 스마트 컨트랙트에 저장된다 . 첫 번째로는 코인을 non-fungible하게 만드는 핵심이라고 할 수 있는 unique id, 두 번째로는 key-value 메타데이터가 생성된다. 또 다른점이라고 한다면 블록 생성 방법이 있다.
플라즈마 캐쉬는 각 토큰당 slot이 존재한다. 그림을 보면 현재 블록 #1에 4개의 Non-fungible한 토큰이 존재하고 그에 따라 4개의 슬롯이 존재한다. 토큰 #1, #2, #3은 사용되지 않은 반면에 토큰 #4는 A에서 B로 사용되었음을 확인할 수 있다. 이를 통해 토큰이 어느 블록에서 어떻게 사용되었는지 확인하는 것이 가능해진다. 또 Plasma MVP는 Standard Merkle trees를 사용하지만 Plasma Cash 블럭은 Sparse Merkle trees사용한다.
Sparse Merkle Trees를 살펴보기에 앞서 왜 이러한 방식을 채택했는가에 대해서 잠깐 설명하자면 Standard Merkle Trees는 모두 익히 알다시피 어떤 트랜젝션이 포함되었는가에 대한 증명은 Merkle proof를 통해 전체 트랜젝션에 대한 정보 없이도 손쉽게 가능하다. 하지만 포함 되지 않았음에 대한 증명(Proving Non-inclusion)은 어떻게 해야할까? 물론 모든 트랜젝션을 파헤쳐서 알아낼 수 있겠지만 이것은 Merkle tree를 사용하는 본질에 벗어나게된다.이러한 문제를 풀기위해 나온 것이 Sparse Merkle trees이다.
정말 간단히 Sparse Merkle Trees에 대해 설명을 하자면 각각의 데이터에는 인덱스가 존재하고 그 인덱스에 맞게 leaf로 이동되어 merklized 된다. 위 그림의 예를 들자면 A는 알파벳 순서상 첫 번째이므로 1번 자리이다. 같은 원리로 D는 4번 자리이다. 2번과 3번자리는 그냥 비워둔채로 둔다. 더 정확하게는 B와 C를 채우지 않고 null과 같은 형태로 비워두는 것이다. A가 존재함을 증명하기 위해서는 Standard Merkle Trees에서 하는 것과 같이 Merkle proof를 하면된다. C가 존재하지 않음을 증명하기 위해서는 3번째가 null임을 증명하기만 하면된다. 증명 방법은 기존 방식과 동일하다.
Plasma Cash는 자산에 Unique ID(index)를 부여하기 때문에 Sparse Merkle Trees를 사용할 수가 있고 이를 통해 트랜젝션의 유효성을 검증할 수 있다. 또한 각각 slot으로 나누어져 있기 때문에 모든 토큰을 다 추적할 필요 없이 본인이 알고자 하는 Token만 보면 된다. 이러한 구조를 통해 Scalability를 얻을 수 있었지만 유연성은 다소 떨어지게 되었다. 즉, ERC721과 같은 Non-fungible token은 하나의 토큰을 나누는 것이 불가능하다. (예를 들어 크립토키티에서 고양이 0.3마리를 거래할 수 없는 것처럼) 또한 하나의 leaf는 하나의 token을 가리키기 때문에 토큰의소유권을 옮기는 것은 블록당 오직 단 한 번만 가능하다. 이러한 단점 때문에 Plasma Cash를 작은 단위까지 계산하고 소유권 이전이 빈번한 유즈 케이스에는 적절하지 않은 부분이 있다
Transfer a token and Verifying its History
위에서 살펴봤다시피 Plasma cash에서 각각의 토큰은 고유의 히스토리를 보유하고 있다. 토큰을 받는 사람은 반드시 이 토큰이 유효한 토큰인지를 판별해야하는데, 이를 위해서는 메인 체인에 반영된 plasma block의 Merkle root를 보고 Merkle proof of inclusion and Non-inclusion을 통해 검증하면 된다. 이해를 돕기위해 토큰을 판매자와 구매자가 물건을 사고팔기 위해 토큰을 교환하는 시나리오를 그려보자. (fraud 시도는 없다고 가정한다.)
- 구매자가 판매자에게로의 토큰 transfer transaction을 broadcasting한다. (저 이거 살게요~ 트랜젝션 받아주세요!)
- Transaction이 블럭 속에 포함이 되고 포함 되었음을 알려주는 witness data를 이용하는 것이 가능해진다. (블록에 포함 되었다! 옛다 증거)
- 구매자가 그 transaction이 블록에 포함이 되었다고 verify한다. 그리고 판매자에게 proofs of inclusion and Non-inclusion을 보낸다. (보세요 포함됐죵??)
- 판매자는 토큰의 히스토리를 대조해가며 구매자가 보낸 transaction이 맞나 확인을 한다.(잠만 기다려봐 맞나 보자)
- 확인이 끝나면 판매자는 구매자에게 물품을 보낸다. (맞네여 ㅎㅎ 물품 보내드리겠습니다)
Withdrawals
블럭의 구조가 Plasma MVP와는 굉장히 다르므로 exit하는 과정 또한 상이하다. 일단 exit을 시작하기 위해서는 exitor(exit을 시도하는 사람)가 토큰의 전 소유자로부터 그 토큰을 넘겨받았음을 나타내는 transaction과 그 트랜젝션의 바로 위 parent transaction이 필요하다. 물론 두 트랜젝션에 대한 Merkle proofs of inclusion 역시 필요하다.
그림2–1과 그림 2–2 와 같이 Coin 자체에 다음과 같은 State 모델을 적용시켜 놓았다. Deposit이 되고 Tx에 사용되기 시작할 때에는 DEPOSITED 상태일 것이다. Exit을 시작하게 되면 EXITING 상태일 것이다. Challenge기간이 끝나고 나면 그 토큰은 EXITED 상태로 바뀔 것이고 비로소 exit을 시작한 user가 메인 체인에서 토큰을 사용할 수 있게 된다.
Possible Attacks
이 섹션에서는 Plasma cash에서 발생할 수 있는 공격의 종류에 대해 알아보고 어떤 식으로 방어되고 있는지를 알아본다. (당연히 Cash뿐 만 아니라 Debit에서도 일어날 수 있다)
- Exit of Double Spend:
이러한 종류의 어택은 반드시 operator와 손을 잡아야만 가능하다. 왜냐하면 double spend tx를 operator가 받아줘야하기 때문이다. 예를 들어 Alice가 Bob에게 돈을 보낸다고 하자. 그 트랜젝션이 블록이 포함되고 난 후 Alice는 사용한 UTXO를 또다시 인 Charlie에게 보내게 된다. 이 때 Charlie는 이 tx가 유효하지 않은 것임을 알아채고 다시 돌려보내야 하나 이 때 Charlie는 Alice와 담합을 한 경우이므로 블럭을 생성한다. 블럭을 생성하고 난 이후에는 메인체인 입장에서는 Alice와 Charlie 모두 코인의 주인이 되게 된다. 그럼 이 때 Charlie는 자신의 UTXO가 포함된 transaction과 자신의 parent transaction 을 통해 Exit 할 수가 있다. 이 때 Challenge를 하려면 Bob이 자신의 UTXO가 포함된transaction과 자신의 parent transaction을 통해 본인의 UTXO가 더 먼저 생성이 되었음을 증명하면 된다. 이러한 Double Spend와 관련된 문제를 막기 위해 항상 유저는 coin을 받기 전에 coin의 히스토리를 확인해야 한다. (굉장히 귀찮겠지만) 왜냐하면 그렇지 않으면 본인이 Double Spending된 UTXO를 받았는지 아닌지 알 수 있는 길이 없기 때문이다. 만약 Coin history를 보았을 때 같은 parent를 가진 소유자들이 있을 때에는 반드시 가장 먼저 coin을 가진 소유자의 transaction을 받아야 한다. 그렇지 않으면 Double Spending된 UTXO 를 받는 것 밖에는 되지 않기 때문이다.
- Exit of Spent Coin
이중 지불문제 같은 경우는 누군가의 조력이 필요없이 단독적으로 수행이 가능하다. 예를 들어 Alice가 Bob에게 돈을 보냈다고 가정하자. Alice와 bob은 그 Tx의 inclusion을 확인하고 블럭을 생성한다.
Alice는 돈을 보내자 마자 보냈었던 UTXO를 가지고 Exit을 신청하게 된다. 만약 challenge기간동안 Bob이 UTXO가 쓰여졌다는 증거(Block N + X)를 가지고 challenge를
하지 못하게 되면 Alice는 그 돈을 들고 튈 수 있게 된다.
- Griefing :
다소 생소한 방식의 공격이라고 볼 수 있는데, 간단하게 말하면 Operator가 트랜젝션을 받고나서 witness data를 주지 않는 경우이다. 트랜젝션을 보낸 user가 exit을 하려고 했을 때 operator가 Exit spent coin challenge를 하고 담보로 건 금액을 탈취하는 것을 말한다. 예를 들면, 구매자가 물건을 사기위해 판매자에게 돈을 보내는 트렌젝션을 보냈다고 하자. Operator는 그 트랜젝션을 받고 블록에 넣었으면 검증을 위해 witness data를 주어야 하는데 주지 않는 것이다. 그 결과 구매자와 판매자 모두 구매자가 돈을 보낸 트랜젝션이 올바르게 처리되었는지 알 수 있는 방법이 없다.
그 순간 구매자는 Operator가 bad behavior를 하고 있다고 판단을 하고 exit을 한다. 하지만 구매자의 트랜젝션은 정상 처리 되어있고 단지 Operator가 witness data를 주지 않았을 뿐이므로 exit을 신청했을 때 opreator가 이거 썼던 토큰입니다! 하고 challenge를 건 후 exit시에 판매자가 걸었던 담보를 탈취하게 된다.
이러한 공격을 막기 위해 나온 것이 Reliable Exits of Withheld In-flight Transactions, 즉 오리무중 상태의 트랜잭션을 exit을 하는 방법이 논의중이다.(참고: https://ethresear.ch/t/reliable-exits-of-withheld-in-flight-transactions-limbo-exits/1901)
Plasma Cash Use Case — Loom Network
Loom network의 DAppChain은 DPos 방식을 활용한다. DPoS 방식은 물론 완전하게 탈중앙화 되지는 않은 방식이고 어느 정도의 유저들의 신뢰를 필요로 한다. 하지만 Plasma Cash를 사용함으로써 높은 신뢰 없이도 더 나은 security 와 과감한 운영이 가능하게끔 되었다.
DappChain은 주기적으로 Ethereum mainet에 Merkle Proof를 체크포인트로서 반영하고 그 반영 주기는 상황에 맞게 보안 수준에 따른다. 이 DAppChain은 Ether뿐만 아니라 모든 종류의 토큰 교환이 가능하다. Loom network의 사이드 체인 속의 토큰과 메인넷과의 플로우는 다음과 같다.
현재 이 DappChain을 활용하여 나온 서비스들이 몇 가지 있는데, 첫 번째로는 DelegateCall이다.
이 서비스의 기본적인 내용은 블록체인과 이더리움에 관한 Q&A 사이트로써사용자들의 질문이나 답이 업보트를 받으면 카르마 포인트를 얻게된다. 하지만 네이버 지식IN의 내공과 다른 점은이 카르마 포인트를 이더리움 메인넷에서 거래가 가능한 ERC-20 “DelegateCall Token”으로 교환할 수가 있고 결과적으로 사용자들은 사이트에 기여한 정도에 따라 보상을 받을 수 있게 되는 것이다. 특히 DappChain은 Relay를 통해 이더리움 스마트 컨트랙트에 연결하여 높은처리량을 구현해 낼 수 있었다. 구조와 데이터의 흐름을 보면 이렇다.
기본적으로 이 웹사이트는 기반에 있는 DAppChain 데이터의 캐시를 읽는 Ruby on Rails앱이다. 읽기 전용 캐시는(MySQL, Elasticsearch로 구성됨) 단순히 블록체인 데이터의 복제본이고, 새로운 블록이 생성될 때마다 업데이트가 되게 된다. 이 캐시는 표준 웹 2.0 앱처럼 빠르게 페이지를 표시하는 데에 목적이 있다. 또한 사진 상에 있는 Loom.js는 Loom DAppChain의 공통 인터페이스 계층이다. 클라이언트 측에서 트랜잭션을 서명하고 이 트랜잭션들을 DappChain에 맞는 형식으로 바꾸는 역할을 한다. 즉 사이트에서 답변에 업보트를 하거나 코멘트를 남기는 등의 액션을 취하면 서버로 데이터를 보내는 것이 아니라 Loom.js가 DelegateCall DAppChain으로 직접 트랜잭션을 알린다.
그리고 DelegateCall.com에서 블록체인의 변경을 계속 확인하는 워커 프로세스가 이 새 트랜젝션을 MySQL캐시와 Elasticsearch에 동시에 포스팅하게 된다.
두 번째로는 CryptoZombies BattleGround이다.
이 게임은 Collectible Card Game으로써 좀비카드를 여러장 사고 PvP 배틀을 하며 플레이하는 게임이다. (유희왕이나 포켓몬과 비슷하다고 할 수 있음) 좀비 카드들은 Non-Fungible Token 토큰으로써 각각의 토큰은 유니크하고 식별가능하며 개개인에 귀속되어 있다. 플라즈마 캐쉬를 사용함으로써 유저들은 사이드 체인의 컨센서스 알고리즘을 신뢰할 필요없이 사이드체인을 사용할 수 있다. 왜냐하면 어떠한 거짓된 트랜젝션이 개인에 의해 만들어지더라도 카드의 소유자는 단순히 Exit을 하고 카드를 메인체인으로 다시 옮기면 되기 때문이다.
이것은 무엇을 의미하는가 생각해보면
- 플레이어는 이더리움과 같은 완전히 탈중앙화된 블록체인 위에서 자산(카드)에 대한 소유권을 보장 받을 수 있다.
- 사이드 체인에서 운영이 되기 때문에 매번 비싼 gas fee를 내지 않아도 된다.
- 자산들은 플라즈마를 통해 안전하게 보장된다.
그 외에도 몇 가지 feature들이 있는데 게임 세션이 끝난 후 Ethereum으로 exit back 하는 것을 잊었을 경우를 대비해 미리 만료 기간을 정해놓는다. (예를 들어 한시간, 하루, 일주일과 같이) 또 카드 뿐만 아니라 좀비 역시 ERC721 Non-Fungible Token 형식으로 소유하는 것이 가능하다. 유저들은 이러한 좀비들을 옥션에서 사고 팔 수 있다.
Loom Network에서는 이 Dapp을 올린 사이드 체인을 ZombieChain이라고 이름을 붙였는데, 개발하는 과정에서 ZombieChain의 잠재력을 깨닫고 현재 ZombieChain을 PlasmaChain이라고 리브랜딩한 상태이다. Plasma Chain은 이더리움 메인넷과 Dapp들을 이어주는 중간 다리가 될 것이므로 사이드 체인들이 더 빠르고 저렴한 트랜젝션을 할 수 있도록 도와줄 것이다.
즉 Layer2 Plasma Chain 역시 이더리움의 사이드 체인이므로, Dapp 들의 사이드 체인은 사이드체인의 사이드체인이 되는 것이다.(말이 어려운 것 같다.) 향후 지불 수단으로 BTC를 이용할 예정이고 내장 DEX / 마켓플레이스를 사용 가능토록 할 예정이라고 한다.
c.Plasma Debit (Plasma Cash with partial balnaces)
Plasma Debit은 Plasma Cash와 유사하나 각각의 슬롯이 public key를 트랙킹 할 뿐만 아니라 그 토큰의 현재 value까지 트랙킹한다고 보면 된다. 또 모든 토큰이 각각의 유저와 operator 간의 payment channel 이라는 점이 Plasma Cash와 다르며 이는 atomic transaction을 통해 가능해지는데, atomic transaction이란 sender의 어카운트가 보내는 돈만큼 debit되고, recipient의 어카운트가 받는 돈만큼 credit 되는 것을 의미한다. Plasma Debit 에서는 각각의 토큰을 value가 a만큼 있는 하나의 account라고 보면된다. 거기에는 총 4가지의 규칙이 적용된다.
- 토큰을 처음 deposit 시에는 v = a 이다.
- a <= v
- a 는 토큰 소유주에게 귀속된다.
- v-a 는 operator에 의해 귀속된다.
트랜젝션이 아마 Plasma cash와 가장 다른 부분일 것이다. 전체 토큰을 보내는 대신에 지불을 하고 싶을 때에는 단순히 Payment channel을 사용하면 된다. 즉 Operator가 중개자 역할을 한다고 보면 되는데 A가 B에게 돈을 보내고 싶다고 가정한다면, A가 Operator에게 돈을 지불하고 동시에 Operator가 B에게 돈을 지불해준다고 보면 된다.
하지만 여기서 문제는 B 역시 Operator와 채널이 존재해야한다는 점인데, Operator 입장에서는 언제, 누가 payment channel을 이용할지 모른다. 즉 미리 그 유저와 payment channel을 만들어 놓을 수 없다는 점이다. 이 문제를 풀기위해 debit은 독특한 방식을 사용한다.
예를 들어, A는 이미 payment channel이 있고 B는 payment channel 이 없다. A는 B에게 1 PETH를 보내고 싶다. B는 임의적으로 payment channel을 만들어 낼 수 없는데 왜냐하면 operator가 “1PETH를 보유한” payment channel이 필요하기 때문이다. 이 때, Operator는 새로운 유저가 올 때마다 channel을 만드는 것이 아니라 미리 채널을 여러개 만들어 놓는다. 그리고 처음 거래를 시작한 사람한테 채널을 보내는 방식이다.
d. Plasma Comparison
3.Conclusion
사실상 이더리움이나 현재 존재하는 블록체인 플랫폼으로는 효용성이 떨어지기 때문에 실질적인 상용 서비스를 올리는 데에 무리가 있다. 이더리움의 Dapp중 하나에 불과한 CryptoKitties의 거래량이 거의 이더리움 네트워크를 마비시켰다는 사실만 미루어 봐도 유저 수가 몇 십만, 몇 백만에 이르는 서비스는 올리지 못할 것이라는 것을짐작할 수 있다. 그 대안으로 떠오른 것이 바로 Side Chain이다. 그 내용의 중심은 모든 데이터들이 같은 보안 수준을 요구 하는 것은 아니라는 것에 있다. 즉 상대적으로 중요하지 않은 데이터는 서비스 제공자 입장에서 자의적인 처리가 가능할 수 있을 것이다. 그 뿐만 아니라 Side Chain을 이용해 Dapp의 용도에 맞게 머클루트를 메인체인에 올리는 주기나 데이터 내용을 조정할 수 있다면 올릴 수 있는 서비스의 폭 또한 굉장히 넓어질 것으로 기대한다.
물론 사이드 체인 자체로는 보완 해야할 부분이 많다. 하지만 하루에도 사이드 체인의 성능을 향상시키고 보안성을 보장하기 위해 굉장히 많은 양의 리서치와 토의들이 이루어지고 있고 본인들의 서비스를 직접 Side Chain에 올린 프로젝트들도 점점 많아지는 것으로 보아 사이드 체인은 주목해야 할 기술임이 틀림없다고 생각한다.
