블록체인 확장성 솔루션 시리즈 2–2 :: Plasma Code Review / Q&A
Gyeo-Re Han (@kyle_han)
Hyun-Cheol Gong (@hyuncheol0)
Ji-Hyeok Choy (@jchoyeclipse)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
서울대학교 블록체인 학회인 ‘디사이퍼(Decipher)’에서 블록체인의 스케일링 솔루션에 관한 글들을 시리즈로 연재합니다. 시리즈의 두 번째 주인공은 이더리움의 “Plasma: Scalable Autonomous Smart Contracts” 입니다. 2–1. 플라즈마 Overview, 2–2. 플라즈마 — Q&A 및 플라즈마 MVP(Minimum Viable Plasma) 코드 리뷰, 2–3. 플라즈마 캐시로 나누어 설명합니다.
지금까지 Plasma whitepaper와 이외의 자료를 바탕으로, plasma(이하 플라즈마)란 무엇이고 어떻게 동작하는지에 대해 이해하였다. 이번 글에서는 논문을 읽고 글을 정리해나가는 과정에서 생겼던 궁금증들을 Q&A 형태로 공유하고자 한다. 또한 다양한 플라즈마의 구현 중 OmiseGo 팀의 플라즈마 MVP (Minimum Viable Plasma) 구현을 살펴보며 플라즈마에 대해 좀 더 자세히 이해해보도록 하자.
아래에서부터 다음의 5개 질문을 다룰 예정이다.
Q1. 플라즈마에서 아직 해결되지 않은 공격이 있는가?
Q2. Depth가 깊은 플라즈마 체인에서 활동할 유인은 무엇인가?
Q3. 플라즈마 체인의 Depth와 플라즈마 체인의 블록이 루트 체인에 커밋되기까지의 시간간의 상관관계가 어떻게 되는가?
Q4. 외부에서 deposit 없이 플라즈마 child chain의 내용을 확인 할 수 있는가?
Q5. 플라즈마의 현재 구현상태는? (Code Review)
Q1. 플라즈마에서 아직 해결되지 않은 공격이 있는가?
대부분의 공격은 앞의 글에서 설명하였듯 플라즈마 프로토콜 자체적으로 해결이 된다. 하지만 아래의 Sybil Attack 의 경우는 플라즈마에서 아직 해결하지 못한 부분이다.
- 공격자 X는 플라즈마 체인 내에서 child chain을 자체적으로 만들고 address A의 1ETH를 deposit한다. 이 체인은 PoA로 X가 관리한다.
- X는 address A, B, C의 소유자이다.
- X는 체인 내의 블록 정보를 누구에게도 공유하지 않는다. 중요한 것은, block 내 address의 confirm signature가 공개되지 않는 것이다.
- X는 A->B->C의 transaction을 생성하고 confirm을 하지 않는다.
- X는 A에서 1ETH를 exit한다. A->B transaction이 confirm되지 않았으므로 성공적인 인출이 가능하다.
- A->B transaction을 confirm한다. (A, B가 둘 다 confirm signature 제출) A는 해당 체인에서 exit을 했지만, exit 정보는 플라즈마 체인에 반영되지 않는다. 따라서 confirm 사인을 추후에 제출하였을 때 해당 체인에서 그 tx은 유효해진다. 이것을 무효화 시키기 위해서는 challenging이 필요하지만 이를 할 수 있는 관찰자는 존재하지 않는다.
- B에서 1ETH를 exit한다. A와 B의 confirm signature가 있어 성공적으로 가능하다.
- B->C transaction을 confirm한다. (B, C가 둘 다 confirm signature 제출)
- C에서 1ETH를 exit한다. B와 C의 confirm signature가 있어 성공적으로 가능하다.
위 상황은 X가 플라즈마 컨트랙트의 ethereum을 훔치는 결과를 만든다. 다른 사람들은 해당 체인의 블록 정보가 없기 때문에 (confirm signature에 대한 정보) challenge를 할 수 없다. B의 confirm signature가 A의 confirm signature로부터 파생되었단 것을 증명할 수 있으면 되지만, 둘 사이의 연결을 모르기 때문에(블록에 대한 정보 없음) 이는 불가능한 것이다.
위 Attack 상황은 Plasma Cash에서 해결된다. 플라즈마 캐시에서는 각 토큰마다 고유한 id가 있다. 이 경우 위의 상황에서 A, B, C는 모두 같은 토큰(동일한 id를 지닌)에 대하여 출금을 요청하기에, attack이 불가능하다.
Q2. Depth가 깊은 플라즈마 체인에서 활동할 유인은 무엇인가?
플라즈마 백서를 보다 보면 이러한 의문이 들 수 있다. “플라즈마에서 루트 체인이 아닌 parent 체인을 두는, depth 2 이상인 플라즈마 체인을 만들거나 거기서 활동할 유인은 뭐지?”
가장 핵심적인 요인은 트랜잭션 수수료다. depth가 깊으면 깊을수록, 한 트랜잭션당 루트체인에서 연산해야 하는 양이 작아지므로 트랜잭션 수수료가 적어진다. 정말 많은 양의 트랜잭션을 생성해야 하거나, 자금이 별로 없어 트랜잭션 수수료가 부담될 경우 depth가 깊은 플라즈마 체인에서 활동할 충분한 유인이 있을 것이다. 추가적으로 플라즈마 체인의 오퍼레이터 입장에선, parent 체인 하에 여러 child chain을 둬 병렬적으로 트랜잭션을 처리해 효율을 극대화하고 싶을 수 있을 것이다.
Q3. 플라즈마 체인의 Depth와 플라즈마 체인의 블록이 루트 체인에 커밋되기까지의 시간간의 상관관계가 어떻게 되는가?
플라즈마 체인의 블록들은 즉각적으로 parent chain으로 커밋되는게 아니라 주기적으로 commit된다. 모든 플라즈마 체인의 commit 주기는 3블록이고, 내가 depth 3인 플라즈마 체인에 있다고 가정해보자. 트랜잭션 A가 담긴 플라즈마 블록은 2 블록 뒤에 depth 2인 parent chain으로 커밋될 것이다. 마찬가지로 depth2의 parent chain에서도 다시 2블록 만큼의 딜레이가 발생할 수 있다. 이러한 식으로, 플라즈마 체인의 depth가 깊을수록 루트 체인에 커밋되기까지 시간이 오래걸릴 수 있을 것이다. 하지만 depth가 무한정 깊어지는 것도 아니고, 각 체인의 tps도 높은 상태일 것이므로 크게 염려할 사항은 아닐 것이라 생각한다.
Q4. 외부에서 deposit 없이 플라즈마 child chain에 참여 할 수 있는가?
일반적인 블록체인과 마찬가지로 플라즈마 역시, 해당 체인의 노드에 싱크를 요청하면 자유롭게 노드가 될 수 있다. 즉, 해당 체인에 deposit 과정 없이 체인의 내용을 모니터링 할 수 있으며, 이를 통해 challenge를 걸 수 있다. Plasma chain의 기능을 이용하거나 내부에서 tx을 보내기 위해서는 그 체인에서 사용되는 token(e.g. PETH)가 필요하다. Deposit 과정 없이 기능을 이용하기 위해서는 자신의 계좌에 플라즈마 체인의 token이 있으면 된다. 즉, 플라즈마 체인에서 누군가가 자신의 계좌로 token을 보내면, 그 token을 이용해 plasma chain의 기능을 사용할 수 있다. 이는 빠른 인출에서 사용하는 방법이기도 하다.
Q5. 플라즈마의 현재 구현 상태는? (2018년 4월 25일 기준)
현재 플라즈마는 공식적으로 이더리움 재단에서 스펙만이 제시된 상태이며 다양한 팀들이 플라즈마의 구현을 진행중에 있다. 본 장에서는 그 중 OmiseGo 팀의 plasma MVP 구현을 기준으로 구조 및 주요 functionality, 아직 구현이 안된 점들에 대한 내용을 살펴보도록 한다. whitepaper에서는 개념적으로 설명되어있는 부분들이 실제 코드 상에서는 어떻게 구현되었는지를 본다면 조금 더 이해가 명확히 되리라 생각된다.
아래 자료는 온더 정순형님의 Deep Dive Into Plasma MVP 및 OmiseGo github (링크) 를 참고하여 작성되었으며 참고자료를 배포해주신 정순형님께 감사의 말을 전한다.
Plasma MVP 구현은 크게 1) Root Chain (Solidity, a.k.a. Plasma Contract), 2) Child Chain (Python), 3) Client (Python) 으로 나눌 수 있다.
1) Root chain에서는 기타 부수적인 library를 제외하면 RootChain.sol이 실질적으로 대부분의 역할을 한다. Child chain의 block hash를 root chain에 반영하거나(submitBlock), deposit을 내고 plasma chain에 참여하거나(deposit), plasma chain 안에서 돈을 빼오는 exit 과정에 관련된 함수들(startDepositExit, startExit, …), 그리고 이에 대한 challenge와 관련된 함수(challengeExit)가 구현되어 있다.
2) Child chain에는 비트코인보다도 ‘간단한’ UTXO 구조 등 실제로 데이터가 저장되는 파트 및 이를 변경하는 것과 관련된 함수들이 포함되어 있다. Deposit이나 트랜잭션을 apply 하거나 (apply_deposit, apply_transaction), 트랜잭션을 validate 하거나(validate_tx) utxo를 사용했다고 마크하는 부분(mark_utxo_spent), child chain의 블록을 submit 하고 root chain으로 hash를 올려보내는 함수(submit_block) 등이 구현되어 있다.
3) 끝으로 Client에서는 실제로 플라즈마 체인의 유저가 root chain이나 플라즈마 chain 안에 있는 함수들을 외부에서 호출할 수 있도록 각 체인에 대한 연결 및 interface를 제공한다. 아래에서 파일명을 보면, cli.py 와 client.py 가 따로 있다. 전자의 경우 실제 사용자의 커맨드를 전송하기 위한 파일이고 client.py 가 실질적으로 플라즈마 컨트랙트 및 child chain과 통신하며 cli.py 를 통해 전달받은 커맨드를 실행한다고 생각하면 된다.
지금부터는 앞선 오버뷰 글에서 정리한 process를 따라가며 각각이 실제로 코드에 어떻게 반영되었는지 확인해보도록 하자. (너무 자명하거나 흐름상 옆으로 조금 벗어난 부분들은 일부 생략하였다. 더 상세한 코드 확인을 위해서 github의 소스코드를 보는 것을 추천한다.) (각각의 code snippet 아래 해당 코드가 어느파일 안에 있는지를 파일명(함수명).확장자 형태로 마크해놨다. )
1. Deposit (client -> plasma contract -> child chain)
앞선 글에서 봤듯이 플라즈마는 deposit을 하는 것으로 부터 시작된다. 7번째 line에서 depositBlock의 index를 받아와 childChain에 이를 등록하고 (8~11), index를 늘려주는 (12) 과정이 있다. (평범해보이는 currentDepositBlock index에 1을 늘려주는 12번째 line도 3. periodic commitments에서 다시 한번 살펴보자.) 특이점은 13번째 line이다. 여기서의 “Deposit”은 RootChain.sol 내에서 아래와 같이 정의되어 있는 “event”다.
현재의 스마트 컨트랙트 구조상, 컨트랙트 내부에서 외부의 process에 직접적인 function call 을 할 수 없기때문에 event를 이용해 log를 내리고 아래와 같이 child chain에서 이를 가져다 반영하는 형태로 처리된다. (다만, 이 경우 deposit event 처리를 child chain의 활동에 의존해야하기 때문에 child chain이 이를 반영하지 않는다면 문제가 될 수 있다. 현재의 구현에서는 이를 강제할 수 없지만 해당 플라즈마 체인에서의 인출 요청을 통해 빠져나올 수 있다.)
Deposit event가 발생하면 child chain에서 argument를 파싱하고 (2~5), 실제 deposit을 위한 UTXO를 생성후에 (7~11), 이를 deposit block에 담아 저장한다. (12, 14)
2. 플라즈마 체인의 트랜잭션 (client -> child chain)
플라즈마 체인에서의 트랜잭션 과정은 1) 트랜잭션 생성 및 서명 2) child chain 내에서 해당 트랜잭션 반영으로 나눠져있다고 볼 수 있다. 이번 절에서는 MVP에서의 트랜잭션이 어떻게 생겼는지 및 각각이 어떻게 구현되어 있는지를 살펴보자.
MVP에서의 트랜잭션은 (블록 넘버, TX index, output index, signature, newowner, amount, confirmation flag, spent flag) pair 두 개를 담고 있다. (whitepaper에서는 갯수를 명시하고 있지 않으나 구현의 편의상 트랜잭션을 두개만 담고 있는 듯 하다.)
1) 트랜잭션 생성 및 서명
13~18 번째 line에서 어느 블록의 UTXO를 사용하는지 (block number, txindex), 어디로 가야하는지 (output index), 보낼 양 (amount)등의 기본 변수를 할당하여 트랜잭션을 생성하고 해당 트랜잭션을 서명한 후 (21 ~ 24) 다음의 apply transaction으로 넘어가게 된다. (여기서는 cli.py -> client.py로의 function call 이지만 client.py에서 다시 이를 child_chain.py으로 요청한다.)
2) 차일드 체인 내 트랜잭션 반영
client에서 child chain으로 apply_transaction 요청이 되면 실제로는 위와 같이 동작한다. encoding되어 전송된 트랜잭션을 decoding한 후 (2, 여기서의 rlp는 이더리움에서 사용하는 인코딩/디코딩 방식이다. 자세한 내용은 링크 확인), 이것이 유효한 transaction인지 검증한다. (5) 그 후, 해당 UTXO들을 사용했다고 mark 하고 현재 block의 트랜잭션 set에 해당 TX를 추가(7~9) 함으로써 apply 과정을 마치게 된다. 5번째 line의 validate_tx 안에서는 1) 송금의 base가 되는 UTXO가 이미 사용된 것은 아닌지 2) amount는 유효한지 (잔액을 초과해서 send하려고 하진 않았는지) 3) signature는 유효한지 (본인이 주인이 아닌데 송금을 하려고 하지 않는지)를 확인하여 문제없으면 통과시키게 된다.
3. Periodic Commitments (client -> child chain -> plasma contract)
client가 현재 block을 root chain으로 push하고자 할 때 cli.py 에서 submitblock 요청을 하게 된다. 현재 블록을 받아와 디코딩하고 (3~4), 본인의 key로 서명한 후(7~9) 해당 block을 submit 해달라고 요청하게 된다. (11) 여기서 중요한 점은 block을 submit하고자 할 때 client가 “본인의 key로 서명”을 한다는 점이다. 이는 현재의 MVP 구현이 PoA 로 구현되어 있기에 block의 sender가 child chain의 authority 라는 말과 동일하다. 다시 말해, 누구나 submitblock 함수를 호출할 수는 있지만 바로 아래의 코드에서 authority 가 아니면 해당 요청이 걸러지게 된다.
whitepaper에 나오는 “periodic commitments”를 위해서 블록 3개 주기로 각 블록의 hash가 담긴다고 가정한다면, child chain의 authority가 매번 순서대로 세 번의 submitblock 함수 호출을 할 것으로 보여진다.
이 함수는 client를 거쳐 child chain으로 넘어온 block을 root chain으로 submit 하는 역할을 한다. Client에게 전달받은 블록을 디코딩한 후 (2), 전달받은 블록의 내용과 현재 자신이 들고있는 pending 블록의 내용이 동일한지를 머클 비교를 통해 확인한다.(3,4) 그 후 블록 sender가 authority의 서명과 동일한지 여부를 확인하게 되는데(6) 이는 앞서도 설명했지만 MVP 구현이 PoA를 따르기 때문이다. 현재의 sender가 authority 일 경우 바로 블록을 생성할 권한이 있다고 판단하고 넘어가는 것이다. (PoS 를 따르게 되는 경우 앞서의 sending 하는 부분 및 여기서의 해당 서명을 검증하는 부분이 그에 맞춰 변경될 것이나 PoA일 경우 유일한 블록 생성자이기에 추가적인 검증과정없이 넘어간다.)
이 이후에는 root chain으로 해당 블록의 root hash값을 전송하고 (10, 아래에서 설명 예정), child chain의 header에 해당 사실들을 반영한 후 (12,13), 이후의 트랜잭션들을 위한 빈 블럭을 하나 생성하고 끝나게 된다(14). 여기서 13번째 line의 block interval은 현재 1000으로 되어 있는데 이것에 대한 명확한 이유 및 근거는 아직 찾을수 없다. (초기값이 1000이기에, block number는 순서대로 1000, 2000, 3000, … 으로 증가하게 된다! 심지어 앞의 deposit에 쓰이는 block의 index는 1부터 시작하여 1씩 증가하기때문에 deposit이 1000번 이상 호출 될 경우 1000번째 블록을 덮어쓸 것으로 보이나 아직은 코드 상에서 그를 경고하지 않는다. 현재의 MVP 시나리오에서는 deposit을 1000번 이상 호출 하는 것을 생각하고있지 않기 때문으로 보인다.)
child chain으로 부터 전달받은 root hash를 스마트컨트랙트 내의 스토리지에 저장하고 (7~10) 현재 자식 블록의 index를 interval 만큼 증가시켜준다. (11)(1000으로 동일) submitBlock은 지속적으로 호출되는 함수임에도 불구하고 12번째 line에서 currentDepositBlock을 1로 명시하고 있는 것으로 보아 현재는 deposit을 1회만 넣을 수 있는 것 같다.
4. Exit Process (client -> plasma contract)
Overview 글에도 잘 표현이 되었지만 플라즈마 동작에서 가장 중요한 부분은 exit process라고 할 수 있다. 모든 참여자가 플라즈마 체인에서 발생하는 악의적인 행동을 감시함으로써 본인의 잠재적인 손실을 막고 이에 대한 보상을 얻게 된다. 아래에서는 withdrawal을 요청하는 것에서 부터, whitepaper에서는 “오래된 TX 순으로 exit”이라고 만 설명되어있던 부분이 코드로는 어떻게 구현되었는지를 살펴보자.
- MVP 에서의 트랜잭션 ordering
트랜잭션의 우선순위는 다음의 공식으로 계산된다.
utxo_pos = blknum * 1000000000 + txindex * 10000 + oindex * 1
block number에 가장 큰 비중을 두고, 그다음이 트랜잭션의 인덱스, 그 다음으로 output의 인덱스로 둔다. 같은 블록내에 존재하는 트랜잭션이라면 index가 더 큰 트랜잭션이 나중에 발생한 트랜잭션이라는 것이 자명하다. 마찬가지로 서로 다른 블록내에 있는 트랜잭션일 경우 blknum에 매우 큰 수가 곱해지기에 나중에 생긴 트랜잭션의 utxo_pos가 훨씬 크므로 그 순서를 알 수 있다. (하지만, 한 블록내의 트랜잭션 갯수가 10만개 (1B / 10K) 이상일 경우 이는 제대로 동작을 하지않으며 이를 코드에서 방지하는 부분도 없다. MVP의 동작확인을 위한 코드이기에 그러한 상황을 가정하지 않고 있는 것 같다.)
client가 exit 요청을 할 때 현재 블록을 받아와 decoding하고 (5~6), withdraw하기 위한 트랜잭션을 받고 (9), 해당 블록의 root hash를 받아온다. (10) 그 후, 인출을 위한 merkle proof를 함께 제출하기 위하여 merkle proof를 생성한다. (11, 아래의 과정을 통해 leaf에서부터 roof 까지의 proof 를 생성) 그 후, 서명한 후에 인출을 요청하게 된다.
특이점은 인출을 요청하는 사용자가 서명뿐 아니라 본인의 proof를 함께 제출한다는 점이다. 이는 플라즈마 체인의 위변조 여부를 참여자가 직접 판단해야하기때문에 나오는 구현상의 특징인 것 같다. 모든 참여자가 매 exit 요청이 발생할 때마다 각각에 대한 merkle proof 를 서버로 요청해서 받아오는 등의 작업을 피하기위해 exit 요청 자체에 proof를 포함시킴으로써 참여자로 하여금 덜 번거롭게하는 효과가 있다.
4 ~ 9 번째 line에서 전달받은 utxoPos(트랜잭션 ordering을 위한 변수), 인코딩된 트랜잭션을 풀어서 각각 block number, 트랜잭션 인덱스, output 인덱스, 출금 금액, 출금요청자로 분해하여 저장한다.
그 후, 출금요청을 보낸 사람과 트랜잭션을 풀어 얻은 exitor가 동일한지 확인하고 (11), 플라즈마컨트랙트에 저장된 root hash 및 대상 트랜잭션의 merkle hash값을 받아온다. (12, 13) 최종적으로, 서명이 올바른지 확인하고 (14) 제시된 txindex와 merkle proof 를 통해 다시 계산한 root hash가 플라즈마 컨트랙트내에 있는 root hash값과 동일한지를 확인하고 (15) exitQueue에 이를 추가하게 된다. (16)
플라즈마에서는 앞선 장에서 설명했듯이, exit 요청이 일어났을 때 즉각적으로 exit 이 일어나는 것이 아니고 challenge period를 거친후에 실제 exit이 발생한다. 또한 consistency의 보장을 위해 priority queue를 사용하여 먼저 발생한 TX부터 exit이 가능하게끔 하는데, 이 함수는 해당 부분을 담고있다. 우선 6 번째 line에서 해당 block이 2 주 이상이 지났는지 (challenge period가 지났는지) check 한 후 7~10번째 line에서 가장 먼저 빠져나가야할 exit 요청을 받는다. 이는 utxoPos를 통해 sorting 되어있는 priority queue에서 가장 오래된 것을 pop 한다고 이해해도 된다. 그 후, 11~22번째 line의 loop을 돌면서 순서대로 1) 해당 value를 실제로 owner에게 송금하는 함수를 호출, 2) 해당 exit 요청 삭제 (중복된 전송을 막기 위해) 3) 다음 exit 요청 get 을 반복하며 queue 에 있는 모든 exit 요청을 처리하게 된다.
추가로, Deposit과 마찬가지로 Exit 또한 플라즈마 컨트랙트에서 event로 내리게 되는데, 아직 child chain에서 이를 반영하는 부분이 구현되어 있지 않다. (즉, 플라즈마 컨트랙트에서는 exit이 이뤄져도 child chain에서는 해당 UTXO가 unspent로 남아있다는 말이다.) OmiseGo github에 issue를 제기해 확인해보니 아직 구현이 안된 것이 맞으며 현재의 event 방식이 옳은지에 대해서도 여전히 open question이라고 한다.
5. challengeExit
root chain에는 plasma 내부에서 발생하는 개별 tx 정보를 담고있지 않기때문에 각각에 대한 검증이 불가능하다. plasma chain의 참여자가 double spending을 위해 exit 요청하는 것을 검증할 수가 없다. 따라서, plasma chain의 참여자들은 각각의 exit 요청들을 지속적으로 verify 해야하는 유인이 있다. 다른 참여자의 잘못된 exit 요청이 있었을 때 이를 challenge 하여 mal-acting을 막기위한 함수가 바로 이 challengeExit이다. 서명된 sig를 가지고 exitQueue 에 등록된 transaction은 이미 서명이 되었기에 기사용된 tx라는 것을 증명하는 역할을 한다.
challenge를 하기위해 1) challenge 대상 utxo, 2) exit 대상 utxo output position, 3) challenging 대상 transaction, 4) challenge를 위한 TX proof, 5) challenge에 사용되는 TX 서명, 6) confirmation signature의 여섯개 파라미터가 함수의 input으로 들어간다.
코드를 살펴보면 4~6 번째 line에서 parameter로 받은 변수들을 통해 eUtxoPos, 트랜잭션의 index (해달 블록에서의 위치), root hash 값을 받아온다. 마찬가지로 7~10 번째 line에서 parameter로 입력받은 txBytes등을 통해 merkleHash 와 해당 UTXO 주인의 address를 가져온다.
끝으로 이렇게 미리 준비해놓은 정보를 통해 utxo 의 owner가 실제 해당 utxo의 owner가 맞는지, merkle proof 를 계산함에 있어 틀림이 없는지를 각각 12, 13번째 line에서 확인한 후 함수가 끝나게 된다. 13번째 line의 checkMembership 함수는 sign된 message와 그에 맞는 signature를 input으로 받아 해당 message를 서명한 owner의 address를 return하는 함수다.
오버뷰에서 다뤘던 플라즈마의 동작 과정을 따라 순서대로 코드 리뷰를 하다보니 글이 꽤나 길어졌는데 여기까지 읽어준 모든 분들께 감사의 말을 전한다. 아직까지 (2018년 4월 24일 기준) 구현이 덜 됐거나 (submitblock 시의 current deposit block을 항상 1로 고정해둔 부분, Exit event를 child chain에서 보고있지 않는 부분 등), consistency를 해칠 수 있는 부분 (utxoPos 계산공식에 따라 TX 갯수 등을 제한하지 않는 부분 등) 들이 있지만 전반적인 과정을 한번 훑어보는 것에는 큰 문제가 없었던 것 같다.
다음글) 블록체인 확장성 솔루션 시리즈 2–3::Plasma Cash
References
- Plasma whitepaper (http://plasma.io)
- OmiseGo plasma-mvp github (https://github.com/omisego/plasma-mvp)
- 정순형님 플라즈마 MVP 발표자료(https://docs.google.com/presentation/d/1gLgeA6_o1WTz7PtSrzclmx8moZ9oAxTG5ZJl8U1tgqg/edit#slide=id.g368a909e04_0_0)
- Ethereum community (ethresear.ch)
