블록체인 확장성 솔루션 시리즈 4–1 :: Sharding 샤딩
서울대학교 블록체인 학회 ‘디사이퍼(Decipher)’에서 블록체인의 스케일링 솔루션에 관한 글들을 시리즈로 연재합니다. 시리즈의 네 번째 주인공은 Ethereum의 “Sharding”입니다. 4–1. Sharding Overview, 4–2.Sharding Q&A 로 나누어 설명합니다.
스케일링 솔루션 네 번째 주제로 이더리움의 확장성 문제 솔루션 중 하나인 샤딩 (Sharding)에 대해 알아보고자 한다. 샤딩은 phase 1부터 6까지 단계별로 로드맵이 제안되어 있다. 현재로서는 가장 구체적으로 spec이 제시된 phase 1이 있으나 RETIRED 되었고, 나머지 phase들이 순차적으로 구체화되고 있다. (2018년 6월 8일 기준) 샤딩 단계별 로드맵은 다음과 같다.
본 글에서는 샤딩의 기본이 되는 phase 1에 대해 중점적으로 다뤄보고, 더 자세한 내용은 4–2 Q&A에서 논의하도록 하겠다.
Sharding 도입배경
샤딩은 플라즈마, 라이덴 네트워크 등과 마찬가지로 확장성 문제를 해결하기 위해 제안된 솔루션이다. 그런데 플라즈마, 라이덴 네트워크는 Off-chain 솔루션인 반면 샤딩은 On-chain 솔루션이다. On-chain 솔루션이란 메인체인 자체의 프로토콜을 변경시켜서 메인체인의 성능을 향상시키는 방법을 말한다. 따라서, On-chain 솔루션을 적용하기 위해서는 메인 네트워크의 하드 포크가 필수적이다. Off-chain 솔루션이 메인체인 바깥에 다른 시스템을 추가하여 해결하기 때문에 하드 포크가 필요없는 것과 대비된다. 샤딩은 확장성 문제 솔루션 중 하나로, 이더리움이 PoS (Proof of Stake) 합의 알고리즘으로 전환할 것을 기반으로 설계되었다.
Sharding이란?
샤딩은 전체 네트워크를 분할한 뒤 트랜잭션을 영역별로 저장하고 이를 병렬적으로 처리하여 블록체인에 확장성을 부여하는 On-Chain 솔루션이다. 쉽게 설명하면 데이터를 샤드라는 단위로 나눠서 저장 및 처리하는 것이다. 샤딩 개념의 근원은 데이터베이스 샤딩에 있다. 데이터베이스 샤딩이란 대용량의 데이터를 처리하기 위해 테이블을 수평 분할하여 데이터를 분산 저장하고 처리하는 것이다.
이더리움에서의 샤딩은 메인 체인을 k개의 샤드로 분할한다. 각 샤드는 네트워크 상의 전체 트랜잭션을 나눠서 병렬적으로 처리한다. 이는 기존에 하나의 메인 체인이 모든 트랜잭션을 순차적으로 처리하던 것과 대비된다. 결과적으로 네트워크의 전체 처리량은 샤드의 배수만큼 향상된다. 예를 들어, 100개의 트랜잭션이 있을 때, 10개의 샤드 체인이 있다면 각각의 샤드 체인이 평균적으로 10개씩의 트랜잭션을 동시에 처리한다.
샤드 체인의 구성요소 및 주요 용어
샤딩에는 새로운 개념과 용어가 많다. 따라서 샤딩을 잘 이해하기 위해서는 이러한 개념과 용어에 대한 이해가 필수적이다. 샤딩의 이해를 돕기 위해 샤드 체인의 구성 요소 및 주요 용어들을 소개해보겠다. 앞서 말했듯이 구성 요소를 지칭하는 용어들 역시 샤딩 연구가 진행됨에 따라 계속해서 달라지고 있지만, 본 글은 phase 1 스펙을 기반으로 하고 있음을 다시 한 번 알린다.
- Collation : Collation은 샤드 체인에서 메인 체인의 블록과 같은 역할을 한다.Collation은 크게 collation header와 트랜잭션 목록으로 구성된다. Collation header는 해당 collation을 구성하는 정보를 담고있으며, proposer의 sign을 거쳐 메인 체인에 제출된다. 트랜잭션 목록은 collation에 담긴 트랜잭션들의 목록이다.
- Proposer : 본래 proposer는 제안자라는 뜻으로 트랜잭션들을 모아 proposal을 만들고 collator에게 제출한다. Proposal은 검증되지 않은 collation이다.
- Collator : Proposer가 제출한 proposal을 검증한다. 특정 period 마다 한 샤드에는 여러 collator들이 배정되는데 이들은 해당 period에 진입하기 일정 기간 이전에 무작위로 선정 된다.
- Executor : Collation header를 메인체인의 SMC (Sharding Manager Contract) 에 전달한다. 이 결과 샤드 체인의 실제 state가 변경된다. (Executor는 샤딩 phase 3에 등장한다)
- Period : 메인 체인에서 샤드 체인의 collation header를 제출 받는 주기를 말한다. 단위는 메인 체인에서의 블록의 개수다. 예를 들어, PERIOD_LENGTH = 5 라면 5개의 블록이 생성되는 것이 1 period이다.
- Lookahead period : Collator는 샤드체인에서 collation을 검증하기 이전에 SMC에 의해 의해 pseudo-random하게 배정된다. 이때, “lookahead period”는 collator가 몇 period에 앞서서 어떤 샤드 체인에 배정되는지를 나타낸다. 예를 들어, LOOKAHEAD_PERIODS = 4이면 4 period 이전에 collator는 샤드 체인에 배정된다. Collator는 사전에 자신이 배정된 샤드 체인의 state 정보를 다운받는 시간을 확보할 수 있다.
- Sharding Manager Contract (SMC)
SMC는 샤드체인에서 가장 중요한 역할을하는 스마트 컨트랙트다. SMC는 메인 체인과 샤드 체인을 연결하며, collator, proposer, collation tree를 관리한다. 샤드체인이 메인체인에 참여하기 위해서는 SMC의 역할이 필수적이다. SMC의 주요 역할은 다음과 같다.
다음 그림을 통해 샤드 체인의 구성과 SMC의 역할을 한 눈에 이해해보자.
1) PoS system : SMC는 collator의 deposit을 관리한다. 만약 collator들이 샤드 체인 내에서 잘못된 행동을 했을 때 deposit을 slash 할 수 있다.
2) Pseudo-randomness sampling : SMC는 collator pool에서 샤드 체인에 collator를 pseudo-random하게 배정한다. 이는 collator가 어떤 샤드에 배정받을지 알 수 없도록 함으로써 collator가 특정 샤드에 대해 공격할 가능성을 낮춰준다.
3) Collation header validation : 샤드 체인이 제출한 collation header를 검증한다. SMC는 addHeader함수를 통해서 검증하고 이 검증을 거쳐야만 collation은 유효해진다.
4) Cross-shard communication : 샤드 간 트랜잭션 전송을 위해서는 메인 체인에 receipt가 생성되어야 한다. SMC는 이 receipt를 관리한다. 샤드 체인의 유저가 receipt를 생성하면 이 receipt는 SMC를 거쳐서 다른 샤드 체인으로 전달되고 소모됨으로써 샤드 간 트랜잭션이 전송된다. 이는 샤딩 phase 4에서 구현될 예정이다.
5) On-chain governance : SMC는 On-chain governance의 중심 역할을 한다. Collator들의 투표가 SMC를 통해서 처리되고, 이 투표가 on-chain에서 이루어질 수 있도록 한다.
샤드 체인 동작 프로세스
다음으로는 샤드 체인이 실제로 어떻게 동작 하는지 알아보도록 하자. 앞서 설명한 샤드 체인의 구성 요소와 용어를 염두해두고 동작 프로세스를 이해해보자.
(1) 먼저 proposer가 되고 싶은 네트워크 참여자는 SMC를 통해 balance를 예치한다.
(2) 마찬가지로 collator가 되고 싶은 네트워크 참여자는 SMC를 통해 deposit을 예치한다.
(3) Collator들은 주기적으로 SMC status를 확인해서, 자신이 collator에 선정되었는지 여부를 확인해야 한다.
(4) Collator들은 SMC에 의해 각 샤드체인에 pseudo-random하게 배정된다. 이들은 lookahead period 동안에 해당 샤드의 이전 기록들(state)을 다운받는다. collator는 선택된 proposal을 제안한 proposer로부터 proposal bid를 받는다.
(5) Proposer는 트랜잭션을 담은 proposal을 collator에게 제출한다. 이 때, proposal은 아직 검증되지 않은 collation을 의미한다. Collator에 의해 선택된 proposal을 제출한 proposer는 트랜잭션 발송자로부터 트랜잭션 fee를 받는다.
(6) Collator들은 해당 proposal에 속한 트랜잭션들이 valid한지를 검증하는 투표를 진행한다.
(7) 투표에서 2/3 이상의 collator들이 proposal에 포함된 트랜잭션이 valid하다고 찬성할 경우, 해당 proposal은 유효한 collation이 된다.
Collator는 add_header 함수를 호출하여, 투표 이후 새롭게 생성된 collation header를 SMC로 보낸다. SMC를 통해 올라간 collation header가 메인체인에 연결된다.
샤딩은 phase를 거듭할수록 executor, cross-shard 트랜잭션과 같은 기능이 추가될 예정이다. 우선은 가장 기본적인 샤드체인 동작프로세스와 인센티브 구조를 살펴보았다. 다음은 샤드 체인의 Fork-choice rule을 알아보자.
Fork-choice Rule of Shard Chain
메인 체인과 마찬가지로 샤드 체인에서도 분기 시 어떤 체인을 선택하느냐는 문제가 있다. 현재 메인 체인은 분기가 일어났을때 가장 긴 쪽을 선택하는 Fork-choice rule을 갖는다. 하지만 샤드 체인 내에서 Fork-choice rule은 좀 더 복잡하다.
샤딩의 경우, 기본적으로는 메인체인과 샤드 체인 둘 모두 긴 쪽을 선택한다. 즉, 1) 샤드 체인이 가장 긴 것을 선택하되 2) 메인체인이 더 긴 것을 우선시한다. 아래의 그림을 보며 자세히 이해해보도록 하자.
샤딩 Phase1에서, 샤드 체인의 Fork choice rule은 가장 긴 메인 체인에 의존한다. 즉, 분기가 일어났을 때, 샤드 체인의 선택은 단순히 ‘가장 긴 샤드 체인’이 아닌 ‘가장 긴 메인 체인 내에 있는 가장 긴 샤드 체인’이어야 한다.
예를 들어, Figure 8을 살펴보면 블록 B3가 포함된 메인 체인이 가장 긴 체인이다. 그러므로 블록 B3가 유효하고, collation C3가 유효함을 알 수 있다. 여기서 score는 블록 혹은 collation의 height를 의미한다.
Figure 9와 같이 블록 B3’가 추가된 상황에서는 위의 체인과 밑의 체인이 동률이다. 이런 상황이라면 메인 체인의 fork choice rule에 따르면 동률시에 유효한 블록은 랜덤하게 정해진다.
이 때 블록 B3이 유효한 블록으로 선정되었고, B3에 속한 collation C3가 유효한 collation이다.
Figure 10에서는 새로운 블록 B4’가 밑의 체인에 추가 되었다. 이제 밑의 체인이 가장 긴 메인 체인이 되었다. 이 때, collation C3와 collation C2의 score를 비교해보면 collation C3 score > collation C2 score이다. 이는 collation C3가 포함된 샤드 체인이 더 긴 샤드 체인임을 의미한다. 하지만 샤드 체인의 선택은 메인 체인에 종속적이다. 가장 긴 메인 체인에 포함된 collation은 collation C3가 아닌 collation C2이다. 그러므로 collation C2의 score가 더 낮음에도 불구하고, collation C2가 유효한 collation이 되고 유효한 샤드 체인으로 선택된다. 이것이 샤드 체인의 Fork-choice Rule이다.
이번 글에서는 샤딩에 대한 전반적인 이해를 돕기 위해 그나마 구체적인 spec이 제시된 phase 1을 중심으로 살펴보았다. 앞서 말했듯이 블록체인에 있어서 확장성 문제는 반드시 해결해야하는 문제이다. 그 중 샤딩은 on-chain 솔루션이라는 점과 이더리움의 PoS 전환 이후에 적용될 것으로 디자인 되고 있다는 측면에서 굉장히 흥미롭지 않을 수 없다.
샤딩의 경우에는 백서가 없기 때문에 참고할만한 공식 문서가 한정적이다. 이더리움 재단에서도 계속해서 샤딩을 구체화하는 과정에 있고, 샤딩 관련 정보는 prysmaticlabs, ethresearch, github 등 여러 곳에 분산 저장되어 있다. 최신 샤딩 정보에 대해 공부하고 싶다면 지속적인 업데이트가 필요한 상황이다.
(이 글의 마지막 부분인 ‘reference’에서 참고한 문서를 정리해 두었으니 참고하길 바란다.)
지금 이 글을 작성하는 시점에도 샤딩은 발전을 거듭하고 있다. 하지만 우리는 여기서 멈출 수 없다! 앞으로도 지속적으로 샤딩 관련 내용을 공부하고, Decipher(@decipher-media)에 글을 업로드할 예정이다.
아직 남아있는 궁금증들은 다음 글인 샤딩 Q&A와 코드리뷰를 통해 더 자세하게 파헤쳐 보도록 하겠다.
SeJin OH (Se Jin OH)
Jongbok Lee(Jongbok Lee)
Geore Han(Han Geore)
Special Thanks to JungWoo Pyo(Jungwoo Pyo) and Geon-gi Mun(Geon-gi Mun)!
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
[References]
[1]https://github.com/ethereum/sharding/blob/develop/docs/doc.md Sharding document, Vitalik Buterin
[2]https://github.com/ethereum/wiki/wiki/Sharding-FAQ#this-sounds-like-theres-some-kind-of-scalability-trilemma-at-play-what-is-this-trilemma-and-can-we-break-through-it Sharding FAQ, Vitalik Buterin, James Ray
[3] https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649 Ethereum Sharding: Overview and Finality, Hsiao-Wei Wang
[4]https://medium.com/prysmatic-labs/how-to-scale-ethereum-sharding-explained-ba2e283b7fce How to Scale Ethereum: Sharding Explained, Raul Jordan
[5] https://ethresear.ch/t/sharding-phase-1-spec-retired/1407/9 Sharding Phase 1 spec, Justin Drake
[6] https://ethresear.ch/t/the-stateless-client-concept/172/6 The stateless client concept, Vitalik Buterin
[7] https://www.youtube.com/watch?v=rLbgwMAv0cY Karl Floersch — Ethereum scaling : Plasma & sharding
[8]https://www.icloud.com/keynote/05Q0CUa8WRPrvPx0tVgLTri_A#Ethereum%5FSharding%5FInfographic
[9] https://github.com/ethereum/sharding
[10]https://medium.com/prysmatic-labs/ethereum-sharding-biweekly-development-update-3-prysmatic-labs-fdf07b6400a2
