Ethereum Sharding

1. 네트워크 샤딩
2. 트랜잭션 샤딩
3. 상태 샤딩

블록체인 확장성을 위한 3단계 샤딩 전략

By  Yaoqi Jia

댑(DApp) 개발 프로그래머라면 현재의 공개형 블록체인(public blockchain)의 한계, 예를 들어 초당 처리되는 트랜잭션의 수와 같은 가장 중요하고도 분명한 제한적인 처리량이 가지는 문제에 대해 생각해봤을 것이다 실생활에서 요구되는 처리량을 다룰 수 있는 댑을 구현하기 위해서는, 블록체인들이 반드시 확장 가능해져야 한다

블록체인 확장성에 대한 하나의 해결책은 샤딩(sharding)이다 샤딩은 네트워크가 블록의 유효성을 검증하는 방식을 바꿈으로써 처리량의 증대를 가져온다 모든 온체인(on-chain) 확장성 솔루션 가운데 샤딩을 특별하게 만드는 핵심적인 특징은 병렬식 확장성(horizontal scaling)이다 예를 들어, 채굴 네트워크가 확장할수록 처리량이 증가한다 샤딩의 이 독특한 특성은 블록체인의 빠른 채택을 촉진하는 이상적인 촉매재가 될 수 있다

현존하는 블록체인이 가진 확장성 문제들

공개형 블록체인 플랫폼이 오늘날 직면한 가장 큰 문제 가운데 하나는 확장성이다 유명한 모든 플랫폼들이 초당 수많은 트랜잭션들을 처리하기 위해 애쓰고 있다 사실, 현재 이더리움과 비트코인의 공공 네트워크는 초당 평균 7-10개의 트랜잭션을 처리할 수 있다 이 수치는 대략 초당 평균 8,000 개의 트랜잭션을 처리하는 비자(Visa)와 같은 중앙화된 지불 업체들과 비교해서 매우 열악하다

느린 트랜잭션 처리로 인해 중요한 문제를 야기하는데, 네트워크를 경직시켜서 실시간 결제와 같은 애플리케이션으로 블록체인을 사용하기 어렵게 만든다 결제가 처리되는 데 오래 걸릴수록, 최종 사용자들의 불편은 더 커진다 이것이 왜 페이팔과 비자와 같은 신용 카드가 여전히 훨씬 더 매력인지에 대한 중요한 이유 중에 하나이다 복잡한 댑들이 동일한 네트워크에 더 많이 의존하기 시작하면서, 느린 트랜잭션 속도에 의한 문제들은 더 악화될 것이다

좀 더 기술적인 관점에서는, 모든 블록체인 합의 프로토콜은 힘겨운 한계를 가진다 즉, 네트워크에 참여하고 있는 모든 노드가 반드시 모든 트랜잭션을 검증해야 하며 다른 노드들로부터 그것에 대한 합의를 구해야 한다 이것이 바로 분산 원장을 만들고 보안성을 부여하는 블록체인 기술의 구성 요소이다

비트코인, 이더리움과 같은 대다수 체인에서, 노드들의 운영은 공개된다 탈중앙화된 합의 메커니즘이 부분적인 고장에도 시스템이 올바르게 실행되는 오류 허용(fault tolerance), 보안성, 정치적 중립성 및 신뢰성과 같은 필수적인 이점을 제공하지만, 체인을 검증하기 위한 이러한 방식은 확장성에서 대가를 치른다 공개형 블록체인이 커질수록 이러한 블록체인을 검증하기 위해서 점점 더 많은 프로세싱 파워가 요구되며, 이것이 네트워크에서 병목현상을 만들어서 새로운 애플리케이션들의 출시 속도를 늦춘다

샤딩(sharding): 분할과 극복

데이터베이스(database)가 여러 파편으로 분할되고 서로 다른 서버에 저장되는 전통적인 데이터베이스 샤딩 개념에서 영감을 받은 확장성 기술이 샤딩이다 공개형 블록체인의 맥락에서, 네트워크에 올려진 트랜잭션은 네트워크 상의 서로 다른 노드들로 이루어진 여러 샤드(shards)로 분할된다 그 결과, 각각의 노드는 들어오는 트랜잭션들의 일부만을 처리할 수 있게 되고, 네트워크 상에서 병렬식으로 다른 노드들에서도 똑같이 실행된다 네트워크를 여러 샤드들로 쪼개면 동시에 더 많은 트랜잭션을 처리하고 증명할 수 있다 결국, 네트워크가 커질수록 점점 더 많은 트랜잭션 처리가 가능하게 된다 이러한 속성을 병렬식 확장(horizontal scaling)이라고도 한다

Database Sharding

가령 기존 블록체인은 하나의 통행료 부스로 운영되는 톨게이트를 가진 혼잡한 고속도로라고 상상할 수 있다 그 결과는 사람들이 톨게이트를 지나려고 긴 줄을 기다려야 하는 교통 체증이다 샤딩-기반 블록체인의 구현은 고속도로에 15-20개의 통행료 부스를 추가하는 것과 같다 이것은 교통량이 톨게이트를 통과하는 처리 속도를 극적으로 향상시킨다 샤딩은 엄청난 차이를 만들며 트랜잭션 속도를 획기적으로 향상시킬 수 있다

샤딩-기반 블록체인의 구현은 공개형 블록체인에 다양한 이점을 가진다 첫째, 수천 개 또는 그 이상의 트랜잭션도 매 초 마다 처리할 수 있으며, 이것은 결제 수단으로서 암호화폐의 효용성에 대한 사람들의 생각을 변화시킨다 트랜잭션 처리량의 향상으로 점점 더 많은 사용자와 애플리케이션을 탈중앙화 시스템으로 끌어올 것이고, 결과적으로 블록체인의 더 많은 채택을 지지하고, 채굴을 더 수익성 있게 그리고 공공 네트워크로 더 많은 노드들을 끌어들여서 선순환을 만들 것이다

게다가, 샤딩은 하나의 트랜잭션의 유효성을 검증하는 데 필요한 프로세스를 줄이기 때문에 트랜잭션 수수료를 낮추는데 도움이 된다 노드들은 적은 수수료를 부과하고도 여전히 운영하는데 수익성을 유지할 수 있다 낮은 수수료와 높은 트랜잭션 처리 능력이 결합된 공개형 체인은 점점 더 매력적인 실사용 사례를 제공할 것이다 이런 긍정적인 추세가 더 많이 이어질수록, 전체적으로 암호화폐와 애플리케이션의 더 많은 주류 채택을 볼 수 있을 것이다

샤딩 전략

이것은 기본 전략이지만, 네트워크 및 트랜잭션 샤딩, 그리고 상태(state) 샤딩과 같은 샤딩 전략을 구현하는 더 세분화된 방식들이 있다 네트워크 및 트랜잭션 샤딩에서는, 블록체인 네트워크의 노드들이 서로 다른 샤드로 분할되고, 각각의 샤드가 처리 과정을 거쳐 서로 다른 트랜잭션의 부분 집합에 대해서 합의에 도달한다 서로 연결되지 않은 트랜잭션의 부분 집합들이 병렬식으로 처리되는 이 방식에서 트랜잭션 처리량은 수백-수 천 배까지 상당하게 끌어올릴 수 있다

반면, 현재의 주류 공개형 블록체인 상에서는, 트랜잭션, 스마트 컨트랙트 그리고 다양한 상태의 저장(storing)에 대한 책임을 모든 공개 노드들이 떠맡는다 이것은 블록체인을 지속적으로 운영하기 위해 요구되는 저장 공간의 측면에서 엄청난 비용을 발생시킨다

상태 샤딩으로 부르는 하나의 잠재적인 접근법은 이 문제를 해결하기 위해 제시되었다 핵심은 전체 저장소를 여러 파편들로 나누고 여러 샤드들이 서로 다른 파트를 저장하게 하는 것이다 그러면 모든 노드는 전체 블록체인 상태(state)가 아닌 소속된 샤드의 데이터 처리만 책임지면 된다

01 Network Sharding

샤딩에 있어서 가장 우선적인 문제는 샤드(shard)의 생성이다 특정 샤드에서 많은 통제력을 가진 누군가로부터의 공격 가능성을 막기 위해서 어떤 노드들이 어떤 샤드 안에 존재하는지를 한정하기 위한 메커니즘이 개발되어야 한다

적을 이기는 최선의 접근법은 최소한 대부분의 경우 임의성(randomness)을 이용하는 것이다 임의성을 이용해서, 네트워크가 무작위로 표본 노드들이 하나의 샤드를 형성하도록 하는 것이 가능해져야 한다 무작위 표본 추출은 악의적인 노드들이 하나의 샤드에 과도하게 몰리는 것을 방지한다

그러나, 임의성을 어디에서 가져와야 할까? 공개 난수에서 가장 손쉽게 이용 가능한 재료는 블록체인 안에 있는데, 예를 들어, 트랜잭션의 머클 트리 루트(Merkle tree root)이다 블록 안에서 이용 가능한 난수는 공개적으로 확인이 가능하며 일정한 무작위 비트는 난수 추출기를 통해서 추출할 수 있다

그런데, 단순히 샤드에 노드를 할당하는 무작위 메커니즘만으로는 충분하지 않다 누구나 네트워크가 샤드의 구성원들에 대해 동의하는지 확인해야 한다 이것은 작업 증명(PoW)과 같은 합의 프로토콜을 통해서 달성할 수 있다

02 Transaction Sharding

트랜잭션 샤딩은 말처럼 그렇게 간단하지 않다 스마트 컨트랙트가 없는 비트코인과 같은 시스템에서 트랜잭션 샤딩을 도입한다고 생각해보면, 비트코인은 시스템의 상태(state)를 UTXO(Unspent Transaction Output, 아직 소비되지 않은 거래 정보)를 사용해서 정의한다 네트워크가 이미 샤드로 이루어져 있고 한 사용자가 트랜잭션 하나를 보낸다고 가정해보자 이 트랜잭션은 두 개의 입력(input)과 하나의 출력(output)을 가진다 그럼, 어떻게 이 트랜잭션을 샤드에 할당해야 할까?

가장 쉬운 접근법은 트랜잭션 해시(hash)의 마지막 몇 비트에 기반해서 샤드를 결정하는 것이다 예를 들어, 해시의 마지막 비트가 ‘0’이라면, 그 트랜잭션은 첫 번째 샤드에 할당한다, (샤드가 두 개뿐이라는 가정하에) 그 외에는 두 번째 샤드에 할당한다 이것으로 그 트랜잭션은 단일 샤드에서 유효성을 검증받는다 그러나, 만약 사용자가 악의적인 경우에, 그는 동일한 두 개의 입력과 하나의 다른 출력을 가진 또 다른 트랜잭션을 생성할 수 있다 - 바로, 이중 지불(double spend)이다 이 경우에, 두 번째 트랜잭션은 다른 해시를 가질 것이다 따라서, 이 두 트랜잭션은 결국 다른 샤드로 할당된다 각각의 샤드는 수신된 트랜잭션을 따로따로 검증하지만 분명한 이중 지불 트랜잭션이 다른 샤드 내에서 유효성을 가진다

이중 지불을 방지하기 위해서는, 샤드들이 유효성을 검증하는 동안 서로 정보를 교환할 수 있어야 한다 사실, 이중 지불 트랜잭션은 모든 샤드에 있을 수 있기 때문에, 트랜잭션을 받는 샤드는 다른 모든 샤드와 통신을 해야 할 것이다 이러한 조정을 위해 소모되는 자원인 통신 비용(communicaiton overhead)이 사실은 트랜잭션 샤딩의 모든 목적을 해칠지도 모른다 각 구성 요소들의 소통을 위해 계산 능력의 일부가 통신 프로토콜 지원과 처리에 소모된다

반면에, (스마트 컨트랙트가 없는) 계정-기반 시스템( account-based system : 비트코인은 UTXO를, 이더리움은 Account를 사용함)을 가질 때 문제는 훨씬 쉽게 해결된다 각각의 트랜잭션은 발신자의 주소를 가지고 발신자의 주소에 기반해서 샤드에 할당할 수 있다 이렇게 하면 두 개의 이중 지불 트랜잭션이 동일한 샤드에서 검증을 받게 되고 따라서 샤드 간 소통 없이도 쉽게 추적이 된다

03 State Sharding

상태 샤딩의 유망함과 동시에 새로운 난관들에 봉착했다 사실은, 상태 샤딩은 지금까지 모든 샤딩 제안에서 가장 어려운 난제이다

계정-기반 모델을 이어가면 -(지금은 스마트 컨트랙스는 도입하지 않기로 한다)- 상태 샤드 블록체인의 경우, 특정 샤드는 상태(state)의 일부만을 유지하게 된다 예를 들어, 만약 우리가 두 개의 샤드와 두 개의 사용자 계정만을 가진다면, 각각 Alice와 Bob이라 하고, 그러면 각 샤드는 한 명의 사용자 잔고를 보유한다

Alice가 Bob에게 지불하는 트랜잭션을 생성한다고 상상해보자 이 트랜잭션은 첫 번째 샤드가 처리하게 된다 일단 트랜잭션이 검증되면, Bob의 새로운 계좌에 대한 정보가 그의 샤드(두 번째 샤드)와 공유되어야만 한다 만약 두 계정이 서로 다른 샤드에 의해 처리되면, 빈번한 샤드 간 커뮤니케이션과 상태 교환을 수반해야 한다 이러한 샤드-간 소통이 상태 샤드로 얻는 퍼포먼스를 해치지 않도록 하는 것이 여전히 연구 과제이다

샤드-간 커뮤니케이션 오버헤드(communication overhead, 자원 소모)를 줄이는 한 가지 가능한 방법은 사용자들로 하여금 샤드-간 트랜잭션을 제한하는 것이다 다시 예로 돌아가서, 이것은 Alice가 Bob과 직접 거래하는 것이 허용되지 않는다는 것을 의미한다 그럼에도 Alice가 Bob과 거래를 해야 한다면, 그녀는 그 샤드에 계정을 보유해야 한다 이것이 샤드-간 소통을 완전히 제거하지만, 플랫폼의 사용성(usability)을 다소 제한할 수도 있다

상태 샤드가 가진 두 번째 난제는 데이터 유효성(data availability)이다 한 가지 시나리오를 생각해보면, 어떤 이유로 특정 샤드가 공격을 받았고 제어 불능에 빠진다 시스템의 상태는 모든 샤드에 걸쳐 복제를 하지 않기 때문에, 네트워크는 제어 불능 샤드에 속한 트랜잭션들을 더 이상 검증할 수 없다 그 결과, 블록체인은 대규모 사용 불능이 된다 이 문제에 대한 해결책은 데이터 불능으로부터 네트워크를 조정하고 복구할 수 있는 기록 또는 백업 노드(node)를 유지하는 것이다 그러나, 이러한 노드들이 시스템의 전체 상태를 저장해야 하기 때문에 중앙집권화의 위험을 불러올 수 있다

모든 샤딩 메커니즘에서 고려해야 될 또 다른 점은 샤드들이 공격이나 실패점에서 회복 중에 있을 때 확실히 멈추지 않아야 한다는 것이다 즉, 네트워크는 새로운 노드들을 계속 수용하고 그들을 임의적으로 서로 다른 샤드에 할당해야 한다 다시 말해, 네트워크는 때때로 재편되어야 한다

그러나, 상태 샤딩의 경우에 재편을 하기가 까다롭다 각각의 샤드가 상태의 일부만을 유지하기 때문에, 네트워크를 모두 함께 재구성하는 것은 동기화가 완성될 때까지 전체 시스템의 불능을 불러올 수 있다 이런 정지 상태를 피하기 위해, 네트워크는 노드가 제거되기 전에 충분히 오래된 노드들을 가질 수 있도록 점진적으로 재구성되어야 한다

마찬가지로, 새로운 노드가 샤드에 들어오면, 누구나 그 노드가 샤드의 상태와 동기화하기 위한 충분한 시간을 갖도록 해야 한다 그렇지 않으면 들어온 노드는 모든 단일 트랜잭션을 바로 거부하게 된다

뿌셔뿌셔(phuzion7)