솔라나는 세계 최고의 성능을 자랑하는 무허가형 블록체인입니다. 현재 진행 중인 솔라나의 테스트넷은 200개의 독립된 GPU 노드들로 구성되었으며, GPU를 통해 초당 50,000건의 트랜잭션을 처리하고 있습니다. 높은 성능을 달성하기 위해 여러 최적화 및 새로운 기술이 필요로 했으며, 그 결과 블록체인 개발 분야에 있어 기존에는 찾아보지 못할 수준의 네트워크 수용력을 이뤄냈습니다.
솔라나 네트워크를 가능하게 해준 8가지 주요 혁신들은 다음과 같습니다:
- 역사증명 (Proof of History) — 컨센서스 전 단계 시간 검증;
- 타워 BFT (Tower BFT) — 역사증명으로 최적화된 버전의 PBFT;
- 터빈 (Turbine) — 블록 전파 프로토콜;
- 걸프 스트림 (Gulf Stream) — 맴풀이 없는 트랜잭션 포워딩 프로토콜;
- 씨레벨 (Sealevel) — 병렬 스마트 컨트랙트 런타임;
- 파이프라이닝 (Pipelining) — 검증 최적화를 위한 트랜잭션 처리 장치;
- 클라우드브레이크 (Cloudbreak) — 수평으로 확장되는 계정 데이터베이스;
- 아카이버 (Archivers) — 분산 장부 저장소;
확장성 트릴레마
블록체인의 확장성 트릴레마는 모두 대역폭과 관련되어 있습니다. 오늘날 대부분의 블록체인 네트워크의 경우, 고정된 양의 대역폭이 노드에게 주어지기 때문에, 노드의 수가 많아질수록 데이터가 모든 노드에 전파되는 시간은 증가하게 됩니다. 이는 매우 큰 문제입니다.
하지만 데이터 전파 방식은 여러 가지 방법을 통해 최적화할 수 있습니다. 특정 상황에 알맞은 창의적인 데이터 전파 최적화 방식은 이미 많이 존재하고 있습니다. 예를 들어, 비트토렌트(BitTorrent)는 TCP를 사용하여 대용량 파일을 많은 그룹에게 전파하는데 최적화되어있으며, 이전에 참여했던 프로젝트 미디어플로(MediaFLO)는 무선 네트워크 환경에서 효율적인 멀티캐스트가 가능하도록 하드웨어 레이어의 데이터 전파를 최적화시킨 프로토콜입니다.
이번 글에서는 솔라나의 데이터 전파 프로토콜 터빈(Turbine)이 솔라나 네트워크에서 데이터를 어떻게 전파하고 블록체인 확장성 문제를 해결하는지 설명드리도록 하겠습니다.
터빈 — Turbine
고성능 블록체인이 맞이하고 있는 난관 중 하나는 바로 네트워크에서 어떻게 대량의 데이터가 많은 피어(Peers)에게 전파될 수 있는가입니다. 예시로 20,000 명의 밸리데이터가 존재하는 네트워크를 가정해 봅니다. 이때 리더는 128 MB 크기의 블록을(트랜잭션 당 크기가 250 바이트 일 때, 약 500,000 트랜잭션) 20,000 명의 밸리데이터 전부에게 전파해야 합니다. 만약 이 과정을 무식하게 수행한다면, 리더는 모든 밸리데이터에 각각 연결해 128 MB 데이터 전파를 20,000회 실시해야 하며, 실제로 네트워크 상에서 이렇게 많은 연결을 수용할 수 있는 충분한 대역폭이 존재하지 않습니다.
이러한 문제를 해결하고자 터빈(Turbine)을 제시하였으며 비트토렌트로부터 많은 아이디어를 얻었습니다— 하지만 몇몇 중요한 기술적 부분에서 둘의 차이가 있습니다. 터빈은 스트리밍에 최적화되어있으며, UDP만을 사용해 데이터를 전송합니다. 터빈은 리더(블록 프로듀서)가 데이터를 스트리밍 할 때, 전체 네트워크에 걸쳐 패킷 당 랜덤한 경로를 만들어 냅니다. 리더는 64 KB까지의 크기의 패킷으로 블록을 쪼갭니다. 128 MB 크기의 블록이라면, 리더는 이를 64 KB 크기의 패킷 2,000개를 만들어 여러 밸리데이터들에게 전송합니다.
각 단계마다 밸리데이터는 네이버후드(Neighborhood)라 불리는 피어 그룹에 데이터 패킷을 재전송 합니다. 네트워크를 시각화해보면, 네이버후드들은 가지가 뻗어나가는 나무의 모양새를 이루며(Tree), 1,000명 이상의 밸리데이터를 수용할 수 있게 됩니다:
각 네이버후드는 자신의 데이터 일부를 하위 네이버후드에게 각각 전송하게 됩니다.
하나의 네이버후드가 200개의 노드로 이루어져 있고, 네트워크는 3개의 레벨로 구성되며, 뿌리(Root)부터 단 한 명의 리더로부터 시작되고, 리더는 단 두 번의 도약만에 — 또는 각 네트워크 연결이 평균 100 ms 일 때, 약 200 ms 만에 40,000명의 밸리데이터에게 도달할 수 있습니다.
하지만 이러한 방법에서 직면하게 된 문제점은 바로 보안(security)입니다. 예를 들어: 적대적인 노드들은 데이터 재전송을 거부하거나, 잘못된 데이터를 재전송할 수 있습니다. 이러한 적대적인 노드들을 다루기 위해 리더는 리드 — 솔로몬 이레이저 코드(Reed-Solomon Erasure Code)를 생성해냅니다. 이레이저 코드를 통해 밸리데이터는 모든 패킷을 받지 않더라도 한 블록 전부를 재구성할 수 있게 됩니다.
만일 리더가 블록 패킷의 33%를 이레이저 코드로 전송했다면, 네트워크는 블록을 잃지 않으면서도 전송 패킷의 33%를 드롭할 수 있습니다. 리더들은 네트워크 상황에 따라 이 수치를 유동적으로 조정할 수 있습니다. 리더는 이전 블록들의 패킷 드롭률을 참고하여 수치를 조정하게 됩니다.
모든 밸리데이터들은 동등한 위치에 있지 않습니다. 가장 중요한 밸리데이터들은 가장 많은 지분(스테이크)을 가진 이들입니다. 따라서 데이터 전파의 우선순위는 이에 맞춰서 이루어지게 됩니다. 지분 가중 선택(stake-weighted selection) 알고리즘은 더 많은 스테이킹을 한 밸리데이터들이 리더에게 더 가까운 네이버후드에 위치하게 해주는 트리를 구성하게 됩니다. 각 밸리데이터는 같은 트리를 독립적으로 연산합니다. 발생하는 장애는 이레이저 코드에 의해 복구될 수 있지만, 특히 서비스 거부 공격(Denial of Service, DoS)이 동반된 경우 적대적인 노드들은 트리 상에서 자신들의 지분 합으로 인해 발생 가능한 장애 초래의 확률보다 유리한 곳에 위치할 수 있습니다.
그렇다면 이클립스 공격 같은 경우 어떻게 막을 수 있을까요? 솔라나의 산개 알고리즘은 패킷의 디지털 서명을 기반으로 한 무작위 소스에서 지분 가중 트리를 각 패킷을 위해 생성합니다. 모든 패킷은 각각 다른 경로를 통해 전송되고, 경로는 미리 알 수 없기 때문에, 네이버후드 레벨의 이클립스 공격을 성공시키기 위해서는 네트워크 대부분을 장악해야만 합니다.
