솔라나는 세계 최고의 성능을 자랑하는 무허가형 블록체인입니다. 현재 진행 중인 솔라나의 테스트넷은 200개의 독립된 GPU 노드들로 구성되었으며, GPU를 통해 초당 50,000건의 트랜잭션을 처리하고 있습니다. 높은 성능을 달성하기 위해 여러 최적화 및 새로운 기술이 필요로 했으며, 그 결과 블록체인 개발 분야에 있어 기존에는 찾아보지 못할 수준의 네트워크 수용력을 이뤄냈습니다.
솔라나 네트워크를 가능하게 해준 8가지 주요 혁신들은 다음과 같습니다:
- 역사증명 (Proof of History) — 컨센서스 전 단계 시간 검증;
- 타워 BFT (Tower BFT) — 역사증명으로 최적화된 버전의 PBFT;
- 터빈 (Turbine) — 블록 전파 프로토콜;
- 걸프 스트림 (Gulf Stream) — 맴풀이 없는 트랜잭션 포워딩 프로토콜;
- 씨레벨 (Sealevel) — 병렬 스마트 컨트랙트 런타임;
- 파이프라이닝 (Pipelining) — 검증 최적화를 위한 트랜잭션 처리 장치;
- 클라우드브레이크 (Cloudbreak) — 수평으로 확장되는 계정 데이터베이스;
- 아카이버 (Archivers) — 분산 장부 저장소;
이번 블로그 포스팅을 통해 일관성보다 활성화에 좀 더 초점을 두고 있는 솔라나의 커스텀 PBFT인 타워 BFT(Tower BFT)에 대해 알아보도록 하겠습니다. 타워 BFT는 메시지 오버헤드와 지연 속도를 줄이기 위해 솔라나의 역사증명(PoH) 합의 이전의 시계로서 활용합니다.
“만약 현 작업의 요청 처리를 할 수 없다면, 활성화를 위해 사본들은 다른 시점으로 옮겨져야 한다. 하지만, 최소 2f+1의 무결함 사본들이 같은 시야에 있고, 요청된 작업들이 처리되기까지 시간격의 기하급수적 증가가 확실해지기 위해선, 시간격을 최대화하는 것이 중요하다.” (Practical Byzantine Fault Tolerance, Miguel Castro and Barbara Liskov)
솔라나는 PBFT의 파생형을 적용했으나, 일반적인 PBFT와 비교했을 때 한가지 근본적인 차이점이 있습니다. 바로 역사증명(PoH)이 합의 이전의 글로벌 시간으로 활약한다는 점 입니다. 솔라나가 구현한 PBFT는 역사증명을 네트워크 상 시간을 알려주는 시계로서 활용되며, PBFT 사본에 적용된 기하급수적으로 증가하는 타임-아웃을 산출하여 역사증명 자체에 입력하게 됩니다.
역사증명은 순차적 해시 함수로서 적용된 검증가능 지연 함수(Verifiable Delay Function, VDF)입니다. 검증은 (계산 시간)/(코어 수)를 필요하기에, 여기서 VDF에 대한 정의는 엄밀히 하지 않고 있습니다. 역사증명의 기본적인 작동 원리는 다음과 같습니다:
- 각 출력값이 다음의 입력값이 될 만큼 Sha256는 최대한 빠르게 루프됩니다.
- 루프는 샘플화되고, 수정 횟수와 상태들은 기록됩니다.
기록된 샘플들은 검증 가능한 데이터 구조로 코딩되며, 경과된 시간을 나타냅니다. 더하여 이 루프는 이벤트를 기록하는 데에 쓰일 수 있습니다.
- 샘플을 레퍼런스 하고 있는 메시지들은 확정적으로 샘플 이후에 생성된 것입니다.
- 메시지들은 루프 안에 입력되어 상태와 함께 해시될 수 있습니다. 이를 통해 해당 메시지는 다가오는 입력 이전에 생성되었다는 것을 보장합니다.
이러한 데이터 구조를 통해 내장된 시간과 이벤트의 일어난 순서는 보장되고, 이는 솔라나의 주요 기술적 최적화의 기반이 되는 핵심 아이디어입니다.
위 사항들을 다르게 이야기해보면 다음과 같습니다: 섬에 한 사람이 있고, 바다에 USB 드라이브가 들어있는 병이 하나 떠 있다 가정합니다. 드라이브 안엔 솔라나의 역사증명 장부가 들어있습니다. 위 사람은 역사증명 장부만을 통해 네트워크의 노드 전체의 상태를 알아낼 수 있습니다. 예를 들어, 만일 지난 X 해시에서 장부에 대한 투표에서 어떤 노드에 관한 기록이 없다면, 해당 노드는 하자가 있는 노드로 간주됩니다. 여기서 우리는 지난 X 해시들에서 네트워크의 압도적 다수에 의한 서명된 검증 메시지들을 가지고 있다면, 해당 장부는 유효한 것으로 간주할 수 있습니다.
- 이런 데이터 구조를 검사하는 노드들은 그 어떤 P2P 통신 필요 없이 같은 값을 산출해 냅니다.
- 역사증명 해시는 유일한 장부의 포크를 확인합니다; 그리고
- 검증 투표 메시지는 역사증명에서 투표 사실이 장부상에 기입되어 있고, 해시 될 수 있을 때에만 유효합니다.
이제 투표와 PBFT에 대해 알아보겠습니다. 장부 그 자체가 신뢰할 수 있는 네트워크의 시계로서 역할하기 때문에, 솔라나는 PBFT 타임-아웃을 장부에 직접 인코드할 수 있습니다.
1. N 해시의 타임-아웃과 함께 투표가 시작됩니다.
검증인은 역사증명 해시에 대한 투표 실시 후, 투표한 해시의 하위 해시가 아닌 이상, 다른 역사증명 해시에 투표할 수 없습니다 (슬래싱 적용).
2. 모든 이전 투표들에 대한 타임-아웃은 두배가 됩니다.
더 수월한 운영 관리를 위해 투표는 고정된 범위의 해시들로 국한되며, 이를 슬롯이라 칭하고 있습니다. 솔라나는 슬롯이 약 400 밀리초로 표현될 수 있는 해시 수를 가지는 것을 목표로 하고 있습니다. 매 400 밀리초마다 네트워크는 잠재적으로 롤백 될 수 있는 포인트를 가지게 되지만, 해당 투표가 무효화되기까지 네트워크가 정지되어야 하는 실제 시간은 매 투표마다 두 배씩 증가하게 됩니다.
각각의 검증인이 지난 12초 동안 32번의 투표를 진행했다고 가정해 보겠습니다. 12초 이전에 이루어진 투표는 이제 ²³²슬롯, 또는 약 54년 만큼의 타임아웃을 가지게 됩니다. 해당 투표는 실질적으로 네트워크에서 절대 롤백 될 수 없게 됩니다. 예시 상의 가장 최근의 투표는 2 슬롯만큼, 또는 약 800 밀리초 정도의 타임아웃을 가지게 됩니다. 장부에 새로운 블록들이 추가될수록, 이전 투표들이 가지게 되는 슬롯들은 매 슬롯, 또는 매 400 밀리초마다 두 배씩 증가하기 때문에, 이전 블록들은 매우 높은 확률로 확정(Confirm) 될 수 있습니다.
이는 작업증명의 확률적 최종성(Probabilistic Finality)과 같지만, 실제론 그렇지 않습니다. ⅔의 검증인들이 역사증명 해시에 투표했을 때, 해당 해시는 정규화(Canonicalized) 되고 롤백 할 수 없게 됩니다. 이는 정규화라는 개념이 없는 작업증명 방식과 차별되는 부분입니다.
네트워크의 나머지와 동떨어지지 않기 위해선 각 검증인은 네트워크의 압도적 다수가 투표하는 장부에만 투표해야 합니다. 검증인은 지난 투표의 타임아웃이 증가될 정해진 시간- 5분이나 10분 -을 모니터링하며, 네트워크 압도적 다수의 이번 투표가 이전 투표를 내포하는 포크에 이루어지는 것을 확인합니다. 실제 상황에서 검증인들은 다음과 같이 행동합니다:
- 10분의 타임아웃을 가질 슬롯에 네트워크 압도적 다수가 투표했는지를 확인합니다.
- 만일 아닐 시, 투표하지 않습니다.
그러면 네트워크의 분할이나 타임아웃이 실제로 만료되기 시작되면 어떻게 될까요?
- 만료된 투표는 모두 클리어 됩니다.
- 지난 투표들의 타임아웃은 하위 투표의 타임아웃과 같을 때에만 두 배로 증가됩니다.
예를 들어, 현재 다음과 같이 타임아웃이 존재하는 예시를 생각해봅시다:
64, 32, 16, 8, 4, 2
만일 검증인이 17 슬롯 동안 투표를 하지 않고 재개하였을 때, 해당 검증인의 타임아웃은 다음과 같습니다:
64, 32, 2
모든 이전 투표들의 타임아웃이 두 배가 되기 위해선 4번의 투표가 연속적으로 일어나야 합니다.
64, 32, 4, 2
64, 32, 8, 4, 2
64, 32, 16, 4, 2
마지막 4번째 투표로 인해 모든 타임아웃은 두 배가 됩니다.
128, 64, 32, 16, 8, 4, 2
이런 접근 방식은 압도적 다수가 동일한 장부를 관찰할 때까지 블록들이 막힘없이 네트워크 상에서 지속적으로 생성되도록 해줍니다. 눈여겨 볼 또 다른 점은, 모든 네트워크 참여자들은 어떠한 P2P 통신 없이 서로의 타임아웃을 산출해 낼 수 있다는 것입니다. 이를 통해 타워 BFT는 비동기적(Asynchronous) 성질을 갖게 됩니다.
실제 상황에선 네트워크에 수많은 소형 포크들(Micro forks)이 나오고 빠르게 폐기될 것으로 예상하고 있습니다. 검증인이 다수의 포크를 감지했을 시, 정직한 검증인은 각 포크에 걸린 타임아웃의 실질적인 비중을 계산하고, 가장 큰 비중을 가진 포크를 선택합니다. 검증인 보상은 ²³²의 타임아웃을 달성한 투표들에 한해서만 생성됩니다. 그러므로, 가장 큰 비중의 타임아웃이 걸린 포크에서 가장 큰 보상이 생성되기 때문에, 검증인들은 가장 큰 비중을 지닌 포크에 투표를 해야 하는 인센티브를 갖게 됩니다.
