블록체인의 확장성 문제와 솔루션 소개 - 2
Scalability 팀
지난 1부에 이어서 이번 2부에서는 샤딩(Sharding), 플라즈마(Plasma), 트루빗(Truebit)에 대하여 이야기 해보도록 하겠습니다.
1부: https://brunch.co.kr/@curg/3
제안된 솔루션 #4: Sharding
블록체인에서의 ‘샤딩(Sharding)’을 설명하기에 앞서, 기존 데이터베이스 시스템에서의 샤딩부터 상기해보자. 데이터베이스에서의 샤딩은 데이터베이스에 있는 “Data”들을 두 개 이상의 데이터베이스로 수평 분할하는 기술이다. 이때 수평 분할된, 기존 “Data”들을 보관하는 각각의 데이터베이스를 ‘샤드(Shard)’라고 부른다. 하나의 데이터베이스에서 처리하는 일을 여러 개의 데이터베이스에 분산시킴으로써 확장성을 상승시킬 수 있다.
마찬가지로 블록체인에서의 샤딩도 유사한 관점으로 해석할 수 있다. 샤딩에 대한 이해를 돕기 위해 이더리움과 같은 “State” 기반의 블록체인을 고려해보자. 모든 노드가 모든 “State”들에 대해 업데이트와 저장을 하는 것이 아니라, “State”들을 샤드라는 각각의 집단으로 분리하여 각각의 샤드를 서로 다른 노드들이 관리하게 된다. 노드들은 자신이 속한 혹은 관리하는 샤드에 할당되는 트랜잭션만을 관리 및 처리함으로써, 모든 노드가 모든 트랜잭션을 처리한다는 구조적 한계를 해결할 수 있다.
그러나 샤딩 구현에서는 몇 가지 주의해야 할 사항이 있다. 우선 각 샤드 간의 통신을 구현해야 한다. 샤딩을 적용할 경우 각 샤드에서는 자신이 포함하고 있는 “State”들에 관련된 트랜잭션을 독립적으로 처리한다. 이로부터 트랜잭션에 대한 분산 처리 혹은 병렬 처리 효과를 얻을 수 있으나, 두 개 이상의 샤드에 연관된 트랜잭션이 발생할 경우, 샤드 사이의 통신을 통해 해당 트랜잭션을 처리해야 할 것이다. “Message-passing”을 해결하는 여러 방법이 있지만, 이더리움에서 제시하는 방법인 “Cross-shard Communication”에 대해 간단히 살펴보자.
“Cross-shard Communication”은 “Receipt”를 개념 혹은 성분을 사용하여 샤드 사이의 통신을 수행하고자 한다. 간단히 말하자면, 두 개 이상의 샤드에 연관된 트랜잭션이 발생할 경우, 하나의 샤드에서 먼저 해당 트랜잭션을 수행하여 자신이 관리하고 있는 “State”를 업데이트하고, 이에 해당하는 “Receipt”를 발생시킨다. “Receipt”는 다른 샤드들이 볼 수 있도록 샤드 간 공유되는 공간에 저장된다. 이후 이와 관련된 샤드들이 해당 “Receipt”를 보고 이전 샤드에서 했던 과정과 같이 자신이 관리하고 있는 “State”를 업데이트 하고 이에 대한 “Receipt”를 발생시킨다.
다음으로, 자신 혹은 자신이 속한 샤드에서 검증하지 않은 트랜잭션에 대한 입증을 해줄 방법이 필요하다. 블록체인 프로토콜은 모든 노드가 서로를 신뢰하지 않는다고 가정한다. 그러나 샤딩의 경우 각각의 노드가 자신이 맡은 샤드에 해당하는 트랜잭션에 대해서만 처리하므로 다른 샤드가 검증한 트랜잭션에 대해 신뢰할 수 없다. 따라서 각 샤드에서 검증한 트랜잭션에 대하여 해당 내용을 입증할 방법이 필요하다.
샤딩을 구현하기 어려운 또 다른 이유는 트랜잭션이 블록체인 네트워크에 대해 병렬적으로 처리되기 때문이다. 이더리움과 같은 “State” 기반 블록체인 플랫폼의 경우 트랜잭션의 실행 순서에 따라서 최종 결과가 달라질 수 있다. 따라서 샤딩에서는 이러한 “Race-condition”을 해결할 수 있는 방법이 고려되어져야 한다.
제안된 솔루션 #5: Plasma
‘플라즈마(Plasma)’는 블록체인의 확장성을 해결하기 위한 오프체인 해결방안 중 하나이다. 트리 구조로 트리들이 구성되어 있는 환경에서 상위의 “Chain”(체인)을 "Parent-child’이고 상위 체인에 연결되어 있는 하위 체인을 ‘Child-chain’이라고 할때 플라즈마에서는 ‘Child-chain’에서 트랜잭션들을 처리하고, 이에 대한 결과를 ‘Parent-chain’에서 반영하는 방법을 통해서 ‘Parent-chain’에서 처리되는 일의 양을 감소시켜 확장성을 상승시키는 방법이다.
먼저 플라즈마의 구조를 살펴보자. 각각의 체인들이 트리 구조로 연결되어 있으며, 트리 구조의 루트 노드는 루트 체인(Ethereum Main Chain)으로 구성된다. 추후 플라즈마가 적용될 경우 아래 그림과 같이 각 ‘Child-chain’에서 각각의 ‘댑(Dapp)’이 실행되고, 실행된 결과 값만이 ‘루트 체인(Root-chain)’에 반영되는 구조를 가지게 될 수 있다. 플라즈마 백서에서 루트 체인을 제외한 모든 ‘Child-chain’에 대해 ‘플라즈마 체인(Plasma-chain)’이라고 칭하고 있으므로, 이하 ‘Child-chain’를 플라즈마 체인으로 언급하도록 하겠다.
다음으로 플라즈마가 어떻게 작동되는지에 대해 간단히 알아보자. 플라즈마에서는 기존의 ‘Pow(Proof of Work)’ 방식이 아닌 ‘Pos(Proof of Stake)’를 사용하여 합의를 진행한다는 사실을 미리 언급하고자 한다. 플라즈마의 경우, 각각의 플라즈마 체인에서 독립적으로 트랜잭션을 처리하고 자신만의 블록을 생성한다. 이후 해당 블록 헤더의 해시 값 만을 상위 체인에 제출하는 과정을 거친다.
플라즈마에서는 샤딩과 마찬가지로 모든 노드들이 모든 트랜잭션을 처리하는 구조적 한계를 플라즈마 체인이라는 구조를 통하여 해결하고자 한다. 특정 노드들이 특정 트랜잭션을 처리하도록 한 것이지만, 이와 같은 해결 방안은 모든 노드에 대한 전체 트랜잭션을 확인하지 못하기 때문에 블록체인 네트워크에 대한 보안 측면이 손상될 수 있다. 이를 보완하기 위해 플라즈마에서는 참가자들이 플라즈마 체인을 주기적으로 확인하여 부정확성의 행위에 대해 블록 생성자를 처벌하는 방법과 플라즈마 체인 자체에 “Block-withholding”과 같은 공격이 발생할 경우 현재의 플라즈마 체인을 벗어나서 다른 체인으로 이동할 수 있는 방법을 제시하고 있다.
제안된 솔루션 #6: Off-chain Computations (TrueBit)
통상의 솔루션들이 이더리움 블록체인의 트랜잭션 증대를 목표하는 반면, ‘트루빗(Truebit)’은 연산(Computation) 증가를 포괄하여 증대 시킴을 목표로 한다. 트루빗은 오프체인 계산을 이용하여 스마트 컨트랙트 사이의 트랜잭션에 대한 확장성을 향상시키는 해결방안이다. 본질적으로 ‘State Channel’과 동일한데, 트루빗은 블록체인 밖에 있는 레이어를 사용하여 “Heavy Lifting”을 수행한다. 즉 온 체인 상에서 수행하면 많은 비용이 소모되는 검증 과정을 오프체인에서 수행하는 시스템이다.
트루빗에서는 모든 노드 대신 “Solvers”라고 불리는 네트워크의 특정 참여자가 스마트 컨트랙트를 수행하고 보증금과 함께 해당 수행 결과를 제출한다. 만약 “Solver”가 정확하다면 “Solver”는 보상금을 받고 보증금을 반환 받는다. 그러지 않고 “Solver”가 부정행위를 할 경우, 보증금은 몰수되며, 블록체인상의 분쟁을 “Verfication Game”을 통해 해결하는 모델이다.
“Verification Game”은 다음과 같이 진행된다. “Challengers”라는 검증자 집합을 통해 “Solver”의 작업을 블록체인에서 확인한다. 만약 “Challenger”가 에러를 표시하지 않으면, 시스템은 해당 결과를 받아들인다. 만약 “Challenger”가 “Solver”의 작업 결과에 대한 정확성의 분쟁을 제기할 경우, 게임은 일련의 라운드를 진행하면서 블록체인에서의 분쟁을 해결하게 된다. 네트워크의 “Judge”는 계산력이 제한된 상태에서 모든 분쟁을 해결한다. 블록체인의 “Judge”가 수행하는 작업은 블록체인에서 실제 작업을 수행하는데 필요한 작업에 비해 작도록 설계되어 있다.
결과적으로, “Solver”가 부정행위를 하였을 경우 해당 사실은 발견되고 처벌이 가해진다. 그렇지 않을 경우 “Challenger”는 “False Alarm”에 의해 소비된 자원에 대한 비용을 지불한다.
“Challenger”들에게 버그가 실제로 존재하고 버그를 찾기 위해 노력할 필요가 있음을 확신시키기 위해서 트루빗은 “Solver”가 가끔 잘못된 결과를 제출하게 하는 흥미로운 일을 수행한다. 해당 과정은 기존 인센티브 시스템과 반대로 작동하는데, “Solver”는 부정확한 결과를 제출할 경우 이익을 얻게 되고 정확한 결과를 제출할 경우에는 불이익을 얻게 된다. 이를 통해 시스템에서 트랜잭션을 검증하는 “Challenger”에게 보상을 제공한다는 것을 보장할 수 있다.
요약하자면, 이 프로토콜은 누구나 계산 작업을 개시할 수 있게 하고, 시스템의 인센티브 구조가 반환된 결과에 대한 정확성을 보장한다. 또한 해당 작업을 완료한 사람은 누구나 보상을 받게 한다. 그리고 계산과 검증 과정을 블록체인 외부로 이동시킴으로써 이더리움의 ‘Gas Limit’에 제약 받지않고 확장성을 상승시킬 수 있다.
결론
본 게시물에서는 블록체인의 확장성 문제를 해결하기 위한 접근 방법들에 대해 간단히 알아보았다. 블록체인의 확장성 문제에 대한 대략적인 이해에 도움이 되었기를 바란다. 블록체인의 확장성 문제는 블록체인이 직면한 가장 큰 문제 중의 하나이며, 흥미로운 소재이다. 앞으로의 게시물에서 본 글에서 언급한 해결방안들에 대해 조금 더 자세히 설명하는 방식으로 확장성에 대한 설명을 진행할 것이다. 비록 아직까지 블록체인의 확장성에 대한 확실한 해답은 존재하지 않는 것으로 보이지만, 분명 활발한 연구를 통해 우리는 그 해답을 찾을 수 있을 것으로 기대한다.
Edit by
맹주현
한양대학교 모바일및네트워크지능연구실 박사과정
maengjuhyun@gmail.com
관심분야: 블록체인, IoT, 인공지능
김상혁
서강대학교 분산처리연구실 석사과정
ksangh228@gmail.com
관심분야: 블록체인, 분산처리시스템, 클라우드컴퓨팅
박상현
서강대학교 컴퓨터공학과 학사과정
twodude@naver.com
관심분야: 블록체인, 이종컴퓨팅, 인공지능
참고 문헌
[1] “Blockchains don’t scale. Not today, at least. But there’s hope”, Medium
[2] “블록체인 확장성 솔루션 시리즈 2-1 :: Plasma Overview”, Medium
[3] “라이트닝 네트워크 이해하기 (1부)”, Medium
[4] “Bitcoin and Blockchain (3)”, Medium
[5] “[케블리] #18. 트루빗(Truebit), 이더리움 확장성(Scalability) 한계의 대안이 될 수 있을까”, Steemit Beta
[6] "몇시간전 비트코인 SegWit의 활성화-가격 상승 요인", Steemit Beta
[7] “비트코인 SegWit2x 그리고 마이너들의 중앙집중화”, Steemit Beta
[8] “세그윗(SegWit)에 대한 간단한 설명”, Steemit Beta
[9] “비트코인과 스케일링 논쟁”, © 2018 Lee Jungmin
[10] “비트코인 스케일링 논쟁 – 빅블록의 문제점”, CoinKorea
[11] “세그윗(Segwit)이란 무엇인가?”, CRYPTOKIWI
[12] “비트코인 SegWit 란 무엇인가?”, THE WANDERER-PAIN 블로그
[13] “상태채널(State Channel)”, Aeternity Community of KOREA
[14] “이더리움의 호재, Raiden Network란?”, 코인 트레이너-비트코인, 이더리움
[15] “Plasma: Scalable Autonomous Smart Contracts”, https://plasma.io/
[16] “ethereum/wiki/wiki/FAQs”, Github
[17] “Making Sense of Ethereum’s Layer 2 Scaling Solutions: State Channels, Plasma, and Truebit”, Medium
[링크 1] https://en.wikipedia.org/wiki/Shard_(database_architecture)
