[NEAR] Sharding (2) Nightshade, NEAR의 샤딩 솔루션
NEAR의 샤딩 기술에 대한 시리즈 아티클을 연재합니다. 본 글은 시리즈의 2편으로 NEAR의 고유한 샤딩 솔루션인 Nightshade에 대해 다룹니다. 다른 편을 읽고 싶으시다면 아래의 리스트를 확인해주십시오.
- 1편: [NEAR] Sharding (1) 체인 확장성을 위한 샤딩 기술
- 2편: [NEAR] Sharding (2) Nightshade, NEAR의 샤딩 솔루션
- 3편: [NEAR] Sharding (3) Nightshade를 통한 생태계 확장 로드맵
본 글은 저자가 속하고 연계된 어떠한 단체나 개인의 의사와 연관되지 않았으며, 투자 권유, 자문 등의 다른 목적 없이 단순한 정보 전달을 위해 작성되었음을 밝힙니다. 모든 판단과 결정들은 스스로 충분한 근거를 가진 후 결정하시길 바랍니다. DYOR!
TL;DR
- NEAR의 Nightshade는 샤드 체인으로 구성된 이더리움과 달리, 블록이 전체 네트워크에서 한 개씩 생성되지만 블록 내부가 분할되어 각 샤드에서 생성된 데이터의 단위인 Chunk의 Header로 구성되는 차이점을 가진다.
- NEAR는 샤딩 특성상 Asynchronous 하게 이뤄지는 샤드 간 트랜잭션에 대한 문제점을 Randomized Validator, Fisherman, Erasure Code 등의 구현을 통해 극복하려고 한다.
- 이런 Nightshade 방식의 샤딩은 블록체인 데이터의 무결성뿐만 아니라 트랜잭션의 빠른 완결성 보장, Dynamic Resharding 구현 시 사용량에 맞는 무한한 확장성으로 나아갈 수 있다는 장점을 지닌다.
High-level view of Nightshade
NEAR는 Nightshade라고 불리는 고유 아키텍처 및 기술로 샤딩을 구현하고 있다. Nightshade는 각 샤드가 각각의 데이터 배치를 생성하는 기존의 접근 방식과 다른 방식을 사용한다. NEAR는 이더리움과 같이 샤딩 기술을 이용해 블록체인 퍼포먼스를 향상시킨다.
하지만 이더리움과 NEAR의 Nightshade는 다른 방식으로 샤딩 기술을 구현한다. 구체적으로 말하면, 이더리움은 하나의 블록체인을 각각 독립적인 “샤드 체인”으로 나누는 반면, NEAR는 각 블록 내에서 샤드를 분할하고 하나의 전체 블록체인을 유지하는 것에 있어서 차이를 가진다.
Nightshade를 사용하는 NEAR에서는 한 체인이 하나의 블록을 생성하지만, 블록은 그 자체로 내부에 트랜잭션들을 포함하고 있지 않다는 것이 특징적이다. 대신 블록은 ‘Chunk Header’라고 불리는 요소들로 구성된다.
Nightshade를 이해하기 위해 Chunk라는 개념을 이해해야 한다. 각 Chunk는 각 샤드에서 생성되는 트랜잭션 데이터들의 집합이다. 각 샤드 내에서는 샤드를 사용하지 않는 일반 블록체인들처럼 검증자와 네트워크 참여자들에 의해 트랜잭션들이 생성되고 Chunk라는 묶음으로 이를 담는 것이다.
블록과 Chunk는 개별적으로 생성되는 것이지만 블록은 Chunk Header을 포함시킴으로서 블록에 각 샤드에서 처리된 트랜잭션 데이터들인 Chunk를 간접적으로 포함시킬 수 있다. 이를 통해 샤드의 개수가 많아질수록 NEAR는 더욱 확장성을 가지게 될 수 있는 것이다.
Cross-shard Transactions
Nightshade가 도입된 NEAR에서 샤드 간 거래 (Cross-shard Transaction)들이 어떻게 일어나는지 살펴보자. Cross-shard Transaction은 다른 샤드에 있는 계정들간의 트랜잭션들을 의미한다. 샤드 0에 배치된 계정을 가진 앨리스가 샤드 1에 배치된 계정을 가진 밥에게 10 NEAR 토큰을 전송하는 상황을 가정하자.
- 트랜잭션을 일으키는 앨리스에 의해 샤드 0에 트랜잭션 0이 생성된다.
- 시스템은 해당 트랜잭션 위의 앨리스의 서명을 검증하고 그녀의 계좌에서 10 NEAR을 차감한 후 이를 Receipt로 바꾼다.
- 샤드 0은 샤드 1에게 이를 전송하고 일을 마친다.
- 다음 블록이 생성되면 Receipt을 받은 샤드 1은 밥에게 10 NEAR을 보낸다.
기존의 샤딩 솔루션은 샤딩을 사용하지 않는 블록체인에 비해 높은 복잡성을 가지고 있었다. 모든 트랜잭션들이 나열되어 순서대로 처리되는 기존의 Synchronous 한 방식과 달리, 샤드 간 거래가 발생하는 블록체인에서는 Asynchronous 하게 복잡한 방식으로 트랜잭션들이 처리된다. 위의 예시를 봐도 두 블록 생성 시간에 거쳐 송금이 일어나고, 앨리스의 Account 정보가 바뀌는 다른 트랜잭션이 순서상 첫 번째 트랜잭션이 끝나기도 전에 실행될 수 있으므로 이중 지불 문제가 발생할 수 있어 이를 해결하기 위한 솔루션이 필요하기 때문이다.
이는 블록체인 아키텍처 설계와 구현 과정에서의 어려움을 안겨줄 뿐만 아니라 심지어 블록체인을 사용하는 개발자와 유저들의 경험 (Developer Experience, Use Experience)를 저해하는 문제점을 가지고 있었다. NEAR 프로토콜은 이러한 기존 샤딩의 문제점들을 다양한 방식으로 극복하고, 장기적으로는 Synchronous Sharding 등을 고려하며 샤딩의 한계를 궁극적으로 극복하고자 한다.
Nightshade의 Problem Solving
Randomized Validator
샤딩이 적용되지 않은 블록체인에서는 트랜잭션들이 모든 검증자들에게 검증되지만, 샤딩 기술이 적용된 블록체인에는 각 샤드에 전체 검증인들의 일부만이 배치된다. 즉 전체 네트워크의 절반 이상을 장악할 때보다 한 샤드를 장악하는 것에 소모되는 리소스가 적을 것임을 예측할 수 있다.
이는 각 샤드 중 하나에 50% 이상의 악의적 검증자들이 트랜잭션들을 조작할 수 있는 가능성을 내포한다. 이를 Single Shard Takeover 문제라고 한다. Single Shard Takeover 문제는 한 샤드뿐만 아니라 전체 체인의 무결성과 보안 (State Validity & Weakness)에도 영향을 미친다. 하나의 샤드가 잘못되어도 Cross-shard 트랜잭션들에 의해 한 샤드의 상태가 다른 샤드의 상태에게도 영향을 미칠 수 있기 때문이다.
그래서 NEAR는 Randomized Validator라는 솔루션을 고안했다. Randomized Validator는 12시간 단위의 매 epoch의 시작마다 개별 샤드에 배치되는 검증인들을 랜덤으로 배치하는 매커니즘이다.
검증인들은 12시간마다 랜덤으로 배치되기 때문에 서로 협업하여 한 샤드의 상태를 절반 이상으로 속이기가 어려워지며, 각 샤드에 충분한 수의 검증인들이 배치된다면 더더욱 Single Shard Takeover의 가능성이 낮아진다.
Fisherman (to the rescue)
하지만 위의 솔루션은 매우 제한적인 솔루션이다. 샤드에 배치되는 정보는 퍼블릭이고 해당 매커니즘을 잘 이용할 수 있는 사람은 몇 가지의 샤드를 공략하여 여전히 데이터 가용성을 위협할 수 있기 때문이다. 이를 Corrupting Validators 문제라고 한다.
이 문제를 해결하기 위해 NEAR는 Fisherman이라는 솔루션을 고안했다. Fisherman은 시스템 상 어느 노드나 될 수 있는 포지션으로, 검증인이 아니어도 된다. Fisherman은 샤드를 지켜보다가 부적절해 보이는 트랜잭션들을 발견하면 Challenge라는 메시지를 생성한다.
Challenge는 왜 이 트랜잭션이 부적절한지 증거를 포함하고 있으며 Fisherman은 이를 전체 네트워크에 Broadcast 하기 때문에 다른 샤드에 있는 검증인들도 해당 샤드를 확인할 수 있게 한다. 다른 검증인들이 챌린지를 확인하면 해당 트랜잭션들의 데이터 무결성과 Fisherman의 챌린지가 올바른 신고인지 판단한다.
만약 Fisherman의 챌린지가 정확하고 해당 트랜잭션이 정말 악의적이었다면 해당 트랜잭션을 포함시키고 처리한 검증인은 Slashing을 통한 패널티를 받는다. 또한 해당 트랜잭션이 포함된 이후의 블록과 트랜잭션들이 Revoke 되고 블록체인 State가 Restore 된다.
챌린지에는 증거가 포함되어 있기 때문에 해당 샤드 전체의 데이터 다운 없이 원래 샤드의 상태들이 없어도 검증 가능하다는 장점이 있다. 하나의 노드만 각 샤드를 모니터링하고 있어도 전체 네트워크가 안전해질 수 있다는 점이 Fisherman 솔루션의 장점이다.
Erasure Code
하지만 Fisherman까지의 솔루션도 완전한 데이터 무결성에 대한 솔루션이라고 보긴 어렵다. 결국 확인과 챌린지를 위해서 Fisherman은 Chunk의 전체 내용을 확인해야 하는 상황인데, 각 블록은 Chunk Header만 포함하기 때문에 해당 샤드의 내용을 지속적으로 모니터링하지 않는다면 다른 사용자들은 해당 Chunk의 내용이 정확한지 확인하기가 어렵다. 수상한 검증인이 Chunk Header만 블록에 Publish 할 수 있기 때문에 다른 검증인들이나 비검증인들에게는 데이터 가용성 (Data Availability) 문제가 발생하는 것이다.
NEAR는 이를 Erasure Code라는 솔루션으로 해결한다. Erasure Code는 한 샤드의 Chunk에 포함된 모든 트랜잭션들을 여러 파트로 나누고 올바르다고 가정된 일부 파트에 의해 전체 데이터가 복구될 수 있는 기술이다.
Chunk Producer가 Chunk를 Erasure Code를 사용해 검증인들의 수에 해당하는 만큼 여러 파트로 나누고 이 청크 파트들은 모든 검증인들에게 한 파트씩 분배된다. 검증인은 각자 자신의 파트를 확인하고 서명하고, 대부분의 검증인들이 서명을 했을 시 합의에 의해 해당 Chunk의 내용 절반은 올바르다고 가정된다.
이러한 Erasure Code는 다른 노드들이 해당 청크의 내용을 복구하고 싶을 때 절반 이상의 올바른 검증인들의 청크 파트만 받아도 원래 내용의 복구가 가능하게 하는 것을 도와 해당 샤드의 검증인이 아니어도 데이터의 무결성을 확인하는 것에 있다는 장점을 가진다.
Nightshade의 장점 (vs. Ethereum)
이더리움 로드맵 속 샤딩의 핵심은 ‘비콘 체인’으로 불려왔던 샤드 체인이다. 각 샤드들 간의 트랜잭션들은 비콘 체인에 의해 최종적으로 유효성이 확인이 되어야 하기 때문에 거래의 완결성 보장까지 15초 ~ 몇 분 사이가 소모될 수 있다. 또한 샤드 체인은 더 이상 샤딩이 불가능하기 때문에 네트워크의 사용자들이 많아져도 동적으로 더 분할되지 못하고 기존 설계될 시의 비콘 체인의 처리 능력 상한까지 트랜잭션들을 처리할 수 있다는 한계를 가진다.
이런 이더리움의 한계와 달리 NEAR는 각 블록 내에서 Chunk를 통해 샤딩을 수행한다. 샤드 간 트랜잭션 (Cross-Shard Transactions)의 완결을 1–2초 안으로 보장하여 사용자 경험을 크게 개선할 수 있다. 또한 Dynamic Resharding이 구현된다면 샤드 체인의 아키텍처에 의존하지 않고 사용량에 따라 각 블록 내에서 여러 개의 샤드로 더 확장 가능하기 때문에 무한한 확장성을 제공할 수 있다는 기대를 가지고 있다.
지금까지 NEAR의 샤딩 기술인 Nightshade의 원리와 강점에 대해 알아보았다. 다음 3편에서는 NEAR의 샤딩 로드맵과 이를 통한 NEAR 생태계 발전 가능성을 살펴보겠다.
