아카이버 — 페타바이트에 달하는 블록체인 데이터에 대한 솔라나의 해법
솔라나를 세계 최고 성능의 블록체인으로 만들어준 8가지 핵심 기술 중 하나인 아카이버에 대해 소개 드립니다
솔라나는 세계 최고의 성능을 자랑하는 무허가형 블록체인입니다. 현재 진행 중인 솔라나의 테스트넷은 200개의 독립된 GPU 노드들로 구성되었으며, GPU를 통해 초당 50,000건의 트랜잭션을 처리하고 있습니다. 높은 성능을 달성하기 위해 여러 최적화 및 새로운 기술이 필요로 했으며, 그 결과 블록체인 개발 분야에 있어 기존에는 찾아보지 못할 수준의 네트워크 수용력을 이뤄냈습니다.
솔라나 네트워크를 가능하게 해준 8가지 주요 혁신들은 다음과 같습니다:
- 역사증명 (Proof of History) — 컨센서스 전 단계 시간 검증;
- 타워 BFT (Tower BFT) — 역사증명으로 최적화된 버전의 PBFT;
- 터빈 (Turbine) — 블록 전파 프로토콜;
- 걸프 스트림 (Gulf Stream) — 맴풀이 없는 트랜잭션 포워딩 프로토콜;
- 씨레벨 (Sealevel) — 병렬 스마트 컨트랙트 런타임;
- 파이프라이닝 (Pipelining) — 검증 최적화를 위한 트랜잭션 처리 장치;
- 클라우드브레이크 (Cloudbreak) — 수평으로 확장되는 계정 데이터베이스;
- 아카이버 (Archivers) — 분산 장부 저장소;
이번 글에서는 페타바이트(Petabytes)에 달하는 블록체인 데이터를 저장하는 솔라나의 분산 원장 저장소인 아카이버(Archiver)에 대해 알아보도록 하겠습니다. 솔라나는 2017년 파일코인(Filecoin)의 복제증명(Proof of Replication)에 대해 접하게 되었으며, 2018년 VDF를 이용해 복제증명의 솔라나 버전을 개발하고 배치 검증을 위한 최적화를 진행했습니다.
솔라나 네트워크가 전력으로 운영된다면 1gb/s*365일의 데이터, 즉 매년 4 페타바이트에 달하는 데이터를 생성해 냅니다. 만일 네트워크의 모든 노드들이 모든 데이터를 저장해야 한다면, 그 정도의 데이터 저장 공간을 갖출 수 있는 소수의 인원들로 인해 중앙화가 일어나고 네트워크에 대한 참여는 제한적으로 변할 것입니다. 저희의 역사증명 기술은 빠르게 검증할 수 있는 복사증명으로 이 문제를 해결할 수 있고, 비트토렌트와 같은 방식으로 전 세계 수백만 레플리케이터(Replicator) 노드들에게 원장을 분산시킬 수 있습니다. 아카이버들은 네트워크 합의에 참여하지 않으며, 이들에겐 매우 낮은 수준의 하드웨어만 요구합니다.
간단하게 말하자면, 솔라나의 레플리케이터는 다음과 같이 작동합니다: 아카이버는 X 바이트 만큼의 저장 공간이 있다는 사실을 네트워크에 알려야만 합니다. 레플리케이터의 수와 가용한 아카이버들의 저장공간에 따라, 네트워크는 때때로 일정한 복제율(현재 목표로는 약 100배)과 장애허용율(이레이져 코딩으로 가능한)을 가지고 원장 내역을 나눕니다. 아카이버:데이터 지정이 완료되면 각 아카이버들은 합의를 맞추는 밸리데이터들로부터 할당된 데이터를 내려받게 됩니다. 아카이버들은 때때로 정말 데이터를 저장하고 있는지에 대해 챌린지를 받게 되고, 이때 복제증명을 할 수 있어야 합니다. 아카이버들은 맡은 역할에 대해 인플레이션의 ~3%까지에 달하는 물량을 보상으로 받게 됩니다.
복제증명에 대한 세부 설명
복제증명의 기본적인 개념은 CBC 암호화를 이용한 대칭 공공 키로 데이터 세트를 암호화하고 이를 해싱 하는 것입니다. 이에 대한 자세한 설명은 파일코인의 복제증명 기술 보고서에 나와있습니다. 하지만 이 방법의 문제점은 바로 공격에 취약하다는 것입니다.
예를 들면, 정직하지 않은 저장 노드는 암호화된 데이터를 스트리밍 하고, 해싱이 끝나면 데이터를 삭제할 수 있습니다. 간단한 해결책으로 암호화의 역순 과정, 또는 랜덤한 과정에서 해싱을 강제하는 것입니다. 이러면 증명의 생성 동안 데이터가 존재한다는 것을 확실히 할 수 있고, 밸리데이터들에게도 모두에게서 나온 모든 증명 검증을 위해 암호화된 데이터 전체를 가지고 있을 것을 요구하게 됩니다. 검증을 위해 필요한 저장 공간은 (CBC 키 갯수)*(데이터 크기)입니다.
저희는 암호화되는 속도보다 더 빠르게 암호화된 블록들을 무작위적으로 샘플링 하고, 샘플의 해시값을 역사증명 원장에 기록하는 방식으로 위의 방식을 개선했습니다. 그렇다면 모든 북제증명에서 블록들은 똑같은 순서로 존재하게 되고, 밸리데이터들은 단일 배치 내에서 데이터를 스트리밍 하고 모든 증명들을 검증할 수 있습니다. 이렇게 저희는 각자의 CUDA 코어를 통해 다수의 증명들을 동시에 검증할 수 있게 됩니다.
현세대 그래픽 카드를 사용한다면, 솔라나 네트워크에선 GPU 카드 당 최대 1,500 개의 복제, 또는 대칭 키를 지원할 수 있습니다. 검증에 필요한 총 저장공간은 (CBC 키 개수)와 같은 코어 수에서 (2 CBC 블록)*(CBC 키 개수)가 됩니다. CBC 블록의 예상 크기는 1MB입니다.
또한 저희는 아카이버들의 증명 생성과 밸리데이터들의 실제 복제증명을 확실히 하기 위해 두 네트워크 참여자 간 일어나는 일종의 게임도 만들었습니다.
원장에 대한 복제증명 생성을 시작하기 위해선, 레플리케이터 클라이언트는 다음과 같은 작업을 시행합니다.
- 클라이언트들은 주기적으로 역사증명 해시에 서명합니다.
- 서명은 원장의 특정 부분 선정에 대한 무작위성을 위한 근원 값으로 쓰입니다.
- 샘플들은 SHA256으로 해싱됩니다.
모든 클라이언트들은 같은 역사증명 해시 값을 서명으로 사용할 것이 강요됩니다. 서명은 역사증명에 관계되어 있기 때문에, 샘플에 대한 해시 결과는 해당 시점과 특정 사본에 따라 각각 고유한 값이 나오게 됩니다.
한편, 밸리데이터들은 클라이언트의 증명을 확인합니다:
- 밸리데이터는 GPU 코어 수에 따라 얼마나 많은 복제증명을 검증할 수 있을지를 선언합니다.
- 밸리데이터는 주기적으로 역사증명 해시에 서명합니다.
- 서명은 원장의 특정 부분을 골라 검증하는 데에 사용됩니다. 밸리데이터는 역량에 한해 얼마나 많은 수의 샘플들을 검증할지 정합니다.
- 밸리데이터는 검증을 실패한 증명들을 업로드합니다.
클라이언트는 밸리데이터가 검증에 실패한 증명에 챌린지를 하여 게으른 밸리데이터를 가려낼 수 있습니다. 그라인딩 공격 방지를 위해 클라이언트는 같은 키 페어를 지속적으로 사용하여야 합니다. 스팸 공격 방지를 위해 프로토콜 내 모든 메시지는 트랜잭션 비용을 발생시킵니다. 아카이버들은 증명 검증에 대해 스테이킹 비중에 따른 보상을 받고, 거짓 증명에 대한 진실한 증명을 출시하는 클라이언트는 해당 밸리데이터가 슬래싱 당하는 코인을 보상으로 받게 됩니다.
