Solana 확장 메커니즘 분석: 가용성을 희생하여 높은 효율성을 추구하는 극단적인 시도 | CatcherVC Research

저자: SA, CatcherVC
기술 자문: 리우양, 《임베디드 시스템 보안》 저자

요약

• Solana의 확장은 주로 네트워크 대역폭의 효율적 이용, 노드 간 통신 횟수 감소, 노드 연산 속도 증가의 세 가지 측면에 기반하고 있으며, 이러한 조치는 블록 생성 및 합의 통신 시간을 직접적으로 단축시키지만 시스템의 가용성(안전성)을 저하시킵니다.
• Solana는 블록 생성자 리더 목록을 사전에 공개하여 단일 신뢰 데이터 출처를 드러내고 합의 통신 비용을 줄였습니다. 그러나 이는 뇌물, 표적 공격 등의 보안 위험을 초래할 수 있습니다.
• Solana는 합의 통신(투표 정보)을 거래 이벤트로 처리하며, TPS 구성 요소 중 70% 이상이 합의 메시지이고, 사용자 거래와 관련된 TPS는 약 500---1000입니다;
• Solana의 Gulf Stream 메커니즘은 전역 거래 풀을 폐지하여 거래 처리 속도를 높였지만 쓰레기 거래 필터링 효율성을 저하시켰으며, 리더가 다운되기 쉽습니다.
• Solana의 리더 노드는 실제 블록이 아닌 거래 시퀀스를 발표합니다. Turbine 전송 프로토콜과 결합하여 거래 시퀀스는 조각으로 나누어져 다양한 노드에 배포되며 데이터 동기화 속도가 매우 빠릅니다.
• POH(Proof Of History)는 본질적으로 시간 측정 및 계산 방법으로, 서로 다른 거래 이벤트에 번호를 매기고 거래 시퀀스를 생성합니다. 리더는 거래 시퀀스에서 전 네트워크에 일관된 타이머(시계)를 발표합니다. 짧은 시간 창 내에서 서로 다른 노드의 원장 진행 및 시간 경과는 일관됩니다;
• Solana에는 132개의 노드가 67%의 스테이킹 점유율을 차지하고 있으며, 그 중 25개의 노드가 33%의 스테이킹 점유율을 차지하여 기본적으로 "과두 정치" 또는 "원로원"을 구성합니다. 이 25개 노드가 공모하면 네트워크가 혼란에 빠질 수 있습니다;
• Solana는 노드 하드웨어 수준에 대한 요구가 높습니다, 장비 비용을 대가로 수직 확장을 실현했습니다. Solana 노드를 운영하는 개인은 대부분 고래 또는 기관, 기업으로, 진정한 의미의 탈중앙화에 불리합니다.
• 종합적으로, Solana는 고급 노드 장비, 파괴적인 합의 메커니즘 및 데이터 전송 프로토콜을 통해 Layer1 확장을 극단으로 밀어붙여 기본적으로 무분할 공공 블록체인이 유지할 수 있는 TPS 한계에 도달했습니다. 그러나 여러 차례의 다운타임은 가용성/안전성을 희생하여 효율성을 얻는 결과를 예고하고 있습니다.

서론

2021년은 블록체인과 암호화폐의 전환점이었습니다. Web3와 같은 개념이 주목받으면서 공공 블록체인 분야는 역사상 가장 강력한 트래픽 성장을 경험했습니다. 이러한 외부 환경 속에서 이더리움은 충분한 탈중앙화와 안전성 덕분에 Web3 세계의 중심이 되었지만, 효율성 문제는 "아킬레우스의 발꿈치"가 되었습니다. TPS가 쉽게 천을 넘는 VISA와 비교할 때, 초당 10여 건의 거래를 처리하는 이더리움은 마치 아기처럼 보이며 "세계적 탈중앙화 애플리케이션 플랫폼"이라는 거대한 비전과는 거리가 멉니다.

이에 대해 Solana, Avalanche, Fantom, Near 등 확장을 핵심으로 하는 새로운 공공 블록체인들이 Web3 내러티브의 주요 역할을 맡으며 대량의 자본의 주목을 받았습니다. Solana를 예로 들면, "이더리움 킬러"라고 불리는 이 주요 공공 블록체인은 2021년 시가총액이 170배 급등하며 절정에 달했고, 심지어 기존 공공 블록체인인 Polkadot과 Cardano를 초월하며 이더리움과 경쟁할 기세를 보였습니다.

하지만 이러한 기세는 오래가지 않았습니다. 2021년 9월 14일, Solana는 성능 문제로 인해 처음으로 다운타임 사고를 겪었고, 그 시간은 17시간에 달했으며, SOL 토큰 가격은 빠르게 15% 하락했습니다; 2022년 1월, Solana는 다시 다운타임을 겪었고, 그 시간은 30시간에 달해 매우 광범위한 논의를 촉발했습니다; 이후 5월에는 Solana가 두 번 다운되었고, 6월 초에도 한 번 더 다운되었습니다. Solana 공식에 따르면, 그 메인넷은 최소 8번의 성능 저하 또는 다운타임 사고를 겪었습니다.

（체인문 연합 리우펑의 Solana에 대한 논평）

많은 문제들이 발생함에 따라 이더리움 지지자들을 중심으로 한 비평가들이 Solana에 대해 의문을 제기했으며, 심지어 Solana에 "SQLana"라는 별명을 붙이기도 했습니다( SQL은 중앙 집중식 데이터베이스를 관리하는 시스템). 그 후 대량의 논평과 분석이 이어졌습니다. 오늘날까지 Solana의 실제 가용성에 대한 논의는 끊이지 않고 있으며, 수많은 호기심 많은 관찰자들을 끌어들이고 있습니다. 주류 공공 블록체인에 대한 관심과 주목으로 인해, CatcherVC는 본인의 시각에서 출발하여 Solana의 확장 메커니즘과 다운타임의 일부 원인에 대해 간단히 해석하고자 합니다.

Solana 시스템 아키텍처, 합의 메커니즘, 블록 전송 프로세스

공공 블록체인의 효율성은 주로 거래 처리 능력, 즉 TPS(초당 처리 거래 수)를 의미하며, 이 지표는 블록 생성 속도와 블록 용량의 영향을 받으며, 거래 수수료와 사용자 활동도 영향을 미칩니다. 2018년의 EOS부터 최근 발행된 Optimism까지, 모든 확장 솔루션은 거의 "블록 생성 속도 증가"라는 가장 중요한 요소를 피할 수 없습니다.

블록 생성 속도를 높이기 위해서는 종종 블록 생성 프로세스에서 "조작"을 해야 하며, Solana도 예외는 아닙니다. 그 확장 방식은 주로 네트워크 대역폭의 효율적 이용, 노드 간 통신 횟수 감소, 노드 처리 속도 증가의 세 가지 측면에 기반하고 있으며, 이러한 조치는 블록 생성 및 합의 통신 시간을 직접적으로 단축시킵니다. Solana의 창립자 아나톨리 야코벤코와 그의 팀은 각 세부 사항을 정교하게 다듬어 시스템의 가용성(안전성)을 희생하면서 효율성을 최대한 높이기 위해 노력했으며, 기본적으로 무분할 공공 블록체인의 실제 TPS 한계에 도달하여 "비용이 드는" 혁신을 이루었습니다.

다른 POS를 채택한 공공 블록체인과 비교할 때, Solana의 가장 큰 혁신점은 독특한 합의 프로토콜과 네트워크 노드 통신 방식입니다. 이 합의 프로토콜은 POS와 PBFT(실용적 비잔틴 내결함성)에 기반하며, 독창적인 POH(Proof of History)를 블록체인 원장을 추진하는 메커니즘으로 도입하여 독자적인 합의 체계를 구축했습니다.

형태적인 관점에서 볼 때, Solana의 합의 프로토콜은 Cardano의 초기 Ouroboros(끝이 맞물린 뱀) 알고리즘과 유사하며, Epoch(시대)와 Slot(간격)의 두 가지 시간 단위를 포함합니다. 각 Slot은 약 0.4~0.8초로, 하나의 블록의 시간 간격에 해당합니다. 각 Epoch 주기는 43.2만 개의 Slot(블록)을 포함하며, 길이는 2~4일입니다.

Solana의 시스템 아키텍처에서 가장 중요한 역할은 두 가지로 나뉩니다: 리더(블록 생성자)와 검증자(Validator). 두 역할 모두 SOL 토큰을 스테이킹한 전체 노드이며, 서로 다른 Slot(블록 생성 주기) 내에서 리더는 서로 다른 전체 노드가 맡게 되며, 리더로 선출되지 않은 전체 노드는 검증자가 됩니다.

각 새로운 Epoch 주기가 시작될 때, Solana 네트워크는 각 노드의 스테이킹 가중치에 따라 추첨을 진행하여 블록 생성자 리더 순환 목록을 구성하고, "미리 정해진" 미래의 블록 생성자를 지정합니다. 전체 Epoch (2~4일) 동안 블록 생성자는 목록에 지정된 순서에 따라 순환하며, 4개의 Slot(블록 생성 주기)마다 리더 노드가 한 번 변경됩니다.

（Solana 제313 Epoch 블록 생성 노드 순환 목록의 일부）

미래의 블록 생성 노드를 사전에 공개함으로써 Solana 네트워크는 사실상 확정적이고 신뢰할 수 있는 새로운 블록 데이터 출처를 확보하여 합의 과정에 큰 편의를 제공합니다.

Solana 블록 생성 프로세스 개요

Solana의 확장 메커니즘을 보다 명확히 이해하기 위해 블록 생성 논리에서 시작하여 Solana의 대략적인 구조를 분석해 보겠습니다:

1. 사용자가 거래를 시작하면 클라이언트는 이를 리더 노드에 직접 전송하거나, 먼저 일반 노드가 수신한 후 즉시 리더에게 전송합니다;

2. 블록 생성자 리더는 네트워크 내 모든 대기 거래를 수신하고, 거래 지시를 정렬하여 거래 시퀀스(블록과 유사)를 생성합니다. 일정 시간마다 리더는 정렬된 거래 시퀀스를 검증자 노드에 전송합니다;

3. 검증자는 거래 시퀀스(블록)에 지정된 순서에 따라 거래를 실행하여 해당 상태 정보(State)를 생성합니다(거래 실행은 노드의 상태를 변경할 수 있습니다, 예를 들어 특정 계좌의 잔액을 변경하는 등);

4. N개의 거래 시퀀스를 전송할 때마다, 리더는 정기적으로 로컬 상태(State)를 공개합니다. 검증자는 이를 자신의 상태와 비교하여 긍정/부정의 투표를 제공합니다. 이 단계는 이더리움 2.0 또는 다른 POS 공공 블록체인에서의 "체크포인트"와 유사합니다.

5. 정해진 시간 내에 리더가 전체 네트워크의 2/3 스테이킹 가중치를 차지하는 노드들로부터 긍정 투표를 수집하면, 이전에 발표된 거래 시퀀스와 상태(State)는 확정되며, "체크포인트"가 통과되어 블록이 최종 확인됩니다 Finality;

6. 일반적으로 긍정 투표를 제공한 검증자 노드와 블록 생성자 리더가 실행한 거래 및 실행 후 상태는 동일하며, 데이터는 동기화됩니다.

7. 4개의 Slot 주기가 지나면 리더가 한 번 전환되며, 이는 리더가 매번 약 1.6초~3.2초 동안 네트워크의 "최고 발언권"을 쥐고 있음을 의미합니다.

Solana 확장 메커니즘 세부 분석

표면적으로 볼 때, Solana의 블록 생성 논리는 다른 POS 메커니즘을 채택한 공공 블록체인과 대체로 유사하며, 블록을 발표하고 블록에 투표하는 과정을 포함합니다. 그러나 각 단계를 관찰하면 Solana와 다른 공공 블록체인 간의 차이가 뚜렷하며, 이는 높은 TPS와 낮은 가용성의 근본 원인입니다:

1. 가장 중요한 점: Solana는 각 주기 Slot의 블록 생성자 리더를 사전에 공개하여 합의 과정의 작업량을 대폭 줄였습니다. 다른 POS 공공 블록체인에서는 신뢰할 수 있는 단일 블록 생성 노드가 부족하여 네트워크의 합의 통신 효율이 극히 낮아지며, 발생하는 시간 복잡도는 종종 Solana보다 몇 배 높아져 TPS의 병목 현상이 됩니다.

주류 POS 합의 프로토콜이나 PBFT 알고리즘을 예로 들면, 이러한 알고리즘은 대부분 Solana와 동일한 시간 단위 및 역할 분담을 사용하며, Epoch 시대, Slot 블록 주기, 리더 블록 생성자, 검증자, 투표와 유사한 설정을 가지고 있지만, 매개변수 설정과 명칭만 다를 뿐입니다. 가장 큰 차이는 이러한 알고리즘이 대부분 안전성(가용성)을 전제로 하여 리더 목록을 사전에 공개하지 않는다는 점입니다.

(예를 들어 Cardano는 리더 순환 목록을 사전에 생성하지만 목록은 공개하지 않습니다. 각 선택된 리더는 자신이 언제 블록을 생성해야 하는지 알지만, 다른 시점의 블록 생성자가 누구인지 알지 못합니다. 이로 인해 블록 생성 노드는 외부에서 예측할 수 없습니다.)

공개된 블록 생성자가 없기 때문에 노드 간에는 "상호 불신"과 "각자 제멋대로"의 상황이 발생합니다. 이 경우, 어떤 노드가 합법적인 블록 생성자라고 주장하더라도, 다른 노드들은 그를 신뢰하지 않으며, 관련된 증명(Proof)을 제시해야 합니다. 그러나 이러한 증명의 생성, 전파, 검증은 대역폭 자원을 낭비하고 추가 작업량을 발생시킵니다(심지어 ZK 영지식 증명과 관련이 있을 수 있습니다). Solana는 각 시간대의 리더를 공개하여 이러한 문제를 피할 수 있습니다.

더욱 중요한 것은, 대부분의 POS 합의 프로토콜이나 PBFT 알고리즘에서 새로운 블록에 대한 투표 Vote는 (하나의 블록이 네트워크 내 2/3 노드의 긍정 투표를 받아야 확정됨) 각 노드가 "유언 프로토콜"을 통해 1대1로 소통하여 전송하거나 수집하는 방식으로 이루어지며, 일종의 바이러스식 무작위 확산과 유사하며, 본질적으로 두 노드 간의 통신이 한 번씩 이루어져야 하므로 그 복잡도와 소요 시간은 Solana의 합의 프로토콜보다 훨씬 높습니다.

Tendermint와 같은 PBFT 알고리즘에서는 단일 검증자 노드가 최소한 네트워크 내 2/3의 노드가 발송한 단일 투표를 수집해야 합니다. 전체 네트워크 노드 수가 N이라면, 각 노드는 최소한 2/3×N개의 투표를 수신해야 하며, 전체 네트워크에서 발생하는 통신 횟수는 최소 2/3×N²에 달합니다. 이는 명백히 너무 큰 수치입니다( N의 제곱에 비례). 노드 수가 많을 경우, 그 합의 과정의 소요 시간은 급증할 수 있습니다.

（일반 공공 블록체인에서 단일 노드 투표의 전파 방식, 유사한 과정이 각 노드에서 한 번씩 발생하며, 매번 블록 생성 시 N번의 유사한 전파가 필요함）

(관련 과학적 설명: 《눈사태 DEX 개발자가 Avalanche 합의 메커니즘을 자세히 설명합니다》)

이에 대해 Solana와 Avalanche는 서로 다른 방식으로 노드가 투표를 수집하는 통신 과정을 개선하여 시간 복잡도를 낮추었습니다. 쉽게 말해, 리더는 모든 검증자가 발송한 투표를 집중적으로 수집하여, 이 투표를 패키징하여(거래 시퀀스에 기록하여) 한 번에 네트워크에 전송합니다.

이렇게 하면 노드들은 "유언 프로토콜"을 통해 빈번하게 1대1로 투표 정보를 교환할 필요가 없어지며, 통신 횟수는 상수 N 또는 logN의 수치로 줄어들어, 이는 블록 생성 시간을 크게 단축시키고 TPS를 대폭 향상시킵니다.

현재 Solana의 블록 생성 주기는 기본적으로 단일 Slot의 길이와 일치하며, 0.4~0.8초로, 심지어 Avalanche보다 3배 더 빠릅니다. (Solana 브라우저에 표시된 블록은 사실상 각 Slot 내 리더가 발표한 거래 시퀀스입니다).

그러나 이는 또 다른 문제를 초래합니다: 리더가 거래 시퀀스(블록) 내에서 노드들의 투표 정보를 발표하면 블록 공간을 차지하게 됩니다. Solana의 설정에서, 리더는 본질적으로 합의 투표를 거래 이벤트로 처리하며, 발표된 거래 시퀀스에는 노드 투표가 포함되어 있으며, 이러한 투표는 Solana TPS의 주요 구성 요소입니다(일반적으로 70% 이상을 차지합니다).

Solana 브라우저의 데이터 통계에 따르면, 실제 TPS는 2000~3000 정도를 유지하며, 그 중 70% 이상이 일반 사용자와 무관한 합의 투표 메시지입니다. 사용자 거래와 관련된 실제 TPS는 500~1000을 유지하며, 이는 BSC, Polygon, EOS 등 고성능 공공 블록체인보다 1단계 높은 수치이지만, 여전히 공식에서 주장하는 만 단위에는 미치지 못합니다.

동시에, Solana가 앞으로 탈중앙화 수준을 계속 높이고 더 많은 노드가 합의 투표에 참여하도록 허용한다면(현재 약 2000개의 검증자가 있음), 리더가 발표하는 거래 시퀀스에는 더 많은 투표 정보가 포함될 수밖에 없으며, 사용자 거래와 관련된 TPS 공간이 지속적으로 압축될 것입니다. 이는 Solana가 무분할 상태에서 더 높은 TPS를 달성하기 어려운 것을 의미합니다.

어떤 면에서는, Solana의 초당 500~1000건의 거래 처리 능력은 무분할 공공 블록체인의 정점에 도달했습니다. 노드 수가 많고 무분할이며 스마트 계약을 지원하는 조건에서, 새로운 공공 블록체인이 Solana의 TPS 수준을 초과하기는 어렵습니다. 단, 그들이 "위원회" 모드를 채택하여 소수의 노드만 합의에 참여하도록 하거나 중앙 집중식 서버로 퇴화하지 않는 한입니다. 합의에 참여하는 노드 수가 많으면 Solana보다 더 높은 "검증 가능한 TPS"를 달성하기 어렵습니다.

특히 주목할 점은, 각 Epoch 내 (2~4일)의 블록 생성자 목록이 사전에 공개되기 때문에, Solana의 합의 프로토콜은 원래의 Tendermint 알고리즘과 본질적으로 다르지 않으며, 실제로 예측 불가능성을 블록 생성자에게 부여하지 않습니다. 모든 사람이 미래의 특정 시점에 누가 블록을 생성할지를 예측할 수 있기 때문에, 이는 가용성/안전성에 많은 위험을 초래합니다.
(리더는 계획된 DDoS 공격에 쉽게 노출되어 장애율이 높아지며, 연속적으로 몇 개의 리더가 장애가 발생하면 네트워크가 쉽게 다운될 수 있습니다; 또한 사용자는 리더에게 미리 뇌물을 줄 수 있습니다 등)

**2. Gulf Stream과 네트워크 다운: **Solana가 블록 생성자 리더 목록을 공개하는 또 다른 중요한 목적은 독창적인 Gulf Stream(만 흐름) 메커니즘과 결합하여 네트워크의 거래 처리 속도를 높이는 것입니다.

사용자가 거래를 시작하면, 클라이언트 프로그램은 종종 이를 지정된 리더에게 직접 전송하거나, 먼저 어떤 일반 노드가 수신한 후 해당 노드가 리더에게 빠르게 전송합니다. 이러한 방식은 리더가 거래 요청을 신속하게 수신하여 응답 속도를 높일 수 있습니다. (이것을 Gulf Stream 메커니즘이라고 하며, Solana 다운의 주요 원인 중 하나입니다)

Solana의 이러한 설정은 다른 공공 블록체인과는 전혀 다른 거래 제출 방식입니다. Gulf Stream은 비트코인과 이더리움의 "전역 거래 풀" 설정을 폐지하였으며, 일반 노드는 대용량 거래 풀을 운영하지 않습니다. 한 노드가 사용자의 대기 거래를 수신하면, 이를 리더에게 전달하기만 하면 되며, 다른 노드에 다시 전송할 필요가 없습니다. 이러한 방식은 효율성을 대폭 높였지만, 거래 풀을 폐지함으로써 일반 노드는 쓰레기 거래를 효율적으로 차단할 수 없으며, 리더 노드가 다운되기 쉽습니다.

이 점을 깊이 이해하기 위해 ETH와 비교해 보겠습니다:
·이더리움의 각 전체 노드는 거래 풀(메모리 풀)이라는 저장 영역을 가지고 있으며, 이는 블록에 올라가지 않은 대기 거래 지시를 저장하는 데 사용됩니다.

·노드가 새로운 거래 요청을 수신하면, 먼저 필터링을 수행하여 거래 지시가 적합한지(중복/쓰레기 거래인지 판단) 확인한 후, 이를 거래 풀에 저장하고 다른 노드에 전송합니다(바이러스식 확산).

·결국, 합법적인 대기 거래는 네트워크를 통해 퍼져 모든 노드의 거래 풀에 저장되며, 이는 서로 다른 노드가 동일한 데이터를 얻어 "일관성"을 나타내게 합니다.

이더리움과 비트코인이 이러한 메커니즘을 채택하는 이유는 명확합니다: 미래의 블록 생성자가 누구인지 모르기 때문에, 모든 사람이 새로운 블록을 패키징할 확률이 있습니다. 따라서 서로 다른 노드가 동일한 대기 거래를 수신하도록 해야 블록 패키징을 준비할 수 있습니다.

만약 채굴 풀 노드가 새로운 블록을 발표하면, 블록을 수신한 노드는 거래 시퀀스를 분석하고 순서대로 실행한 후, 이 부분의 거래 지시를 거래 풀에서 제거합니다. 이로써 일련의 대기 거래가 블록체인에 올라갈 수 있습니다.

Solana는 이더리움의 거래 풀을 폐지하여 대기 거래가 네트워크 내에서 무작위로 확산되는 것이 아니라 지정된 리더에게 신속하게 제출된 후 거래 시퀀스로 패키징되어 한 번에 배포됩니다(앞서 언급한 투표 전파 방식과 유사합니다). 결국, 거래는 거래 시퀀스에 포함되어 네트워크 내에서 한 바퀴 전파되면 됩니다(이더리움은 실제로 두 바퀴를 전파합니다). 거래 수가 많을 경우, 이 미세한 차이는 전파 효율을 대폭 향상시킬 수 있습니다.

하지만 거래 풀 TxPool의 관련 기술 설명에 따르면, 거래 풀/메모리 풀은 본질적으로 데이터 버퍼와 필터 역할을 하여 공공 블록체인의 가용성을 높일 수 있습니다. 모든 노드가 거래 풀을 운영하여 네트워크 내 모든 대기 거래를 수집하고, 서로 다른 노드는 독립적으로 쓰레기 요청을 필터링하여 중복 거래를 즉시 차단하고 트래픽 압력을 분담할 수 있습니다. 거래 풀이 블록 생성 속도를 늦출 수 있지만, 사용자가 중복 거래(거래 풀에 기록된 요청)를 시작하거나 다른 유형의 쓰레기 요청을 보낼 경우, 거래를 수신한 노드는 로컬에서 이를 필터링하여 더 이상 전송하지 않게 되어 필터링 작업이 전체 네트워크 노드에 분담됩니다.

（이더리움 네트워크에서 악의적인 사용자가 시작한 중복 거래는 각 노드에서 직접 차단되기 더 쉽습니다）

Solana는 반대로 가고 있습니다. Gulf Stream 메커니즘 하에서 일반 노드는 전체 네트워크에서 일관된 거래 풀을 운영하지 않으며, 중복/쓰레기 거래를 효율적으로 차단할 수 없습니다. 일반 노드가 할 수 있는 것은 거래 데이터 패킷이 올바른 형식인지 확인하는 것뿐이며, 악의적인 중복 요청을 식별할 수 없습니다. 동시에 일반 노드가 거래 지시를 리더에게 "한꺼번에" 전송하는 것은 거래 필터링의 "부담"을 리더에게 넘기는 것이며, 트래픽이 매우 많고 중복 거래가 많을 경우, 리더 노드는 과도한 압력으로 인해 블록을 생성하지 못하게 되어 합의 투표가 원활하게 전파되지 않으며, 네트워크가 쉽게 붕괴될 수 있습니다.

이에 대해 Solana의 창립자 아나톨리 야코벤코는 올해 1월 27일, 일부 인기 프로젝트의 공매도 기간 동안, 초당 최대 200만 건의 거래 요청이 동일한 리더 노드에 도달하며, 그 중 90% 이상이 완전히 동일한 중복 거래로, 결국 Solana가 다운되는 원인이 되었습니다.
(참고 자료: 《심층 조사: 새로운 공공 블록체인들이 왜 자주 다운되는가?》)

종합적으로, 이더리움은 효율성을 희생하여 안전성을 얻는 반면, Solana는 안전성을 희생하여 효율성을 얻고 있으며, 그가 직면한 문제는 다음과 같이 요약될 수 있습니다:
리더의 순환 순서가 정해져 있어 이 순환 체인을 계속 따라가야 합니다. 그러나 트래픽 분담 메커니즘이 불완전하여 리더 노드의 고장 확률이 높고, 특정 시간 동안 사용자 트래픽이 과도할 경우(예: 특정 인기 NFT의 공매도 시작 시), 여러 리더가 연속적으로 고장 날 수 있습니다(예: 향후 40개의 Slot의 리더가 모두 블록을 생성하지 못하는 경우), 이로 인해 합의 과정이 방해받고 네트워크가 분기되며, 리더 순환 체인이 완전히 끊어져 결국 붕괴될 수 있습니다.

3. BT 씨앗과 유사한 Turbine 전송 프로토콜: 앞서 언급한 Gulf Stream 메커니즘과 결합하여, 리더는 일정 시간 내의 모든 거래 요청을 신속하게 수신하고 그 합법성을 확인한 후 거래를 실행합니다. 동시에 리더는 POH(Proof of History)라는 메커니즘을 사용하여 각 거래에 시퀀스 번호를 부여하고 거래 이벤트를 정렬합니다. (세부 사항은 후속 문단에서 설명합니다)

리더가 거래 이벤트를 정렬한 후, 거래 시퀀스를 X개의 서로 다른 조각으로 나누어 스테이킹 자산이 가장 많은 X개의 검증자에게 각각 전송한 후, 그들이 다른 검증자에게 전파합니다. 검증자 집단은 수신한 조각을 서로 교환하여 로컬에서 완전한 거래 시퀀스(블록)를 조합합니다.

이해를 돕기 위해 각 다른 조각을 데이터 양이 축소된 작은 블록으로 간주할 수 있습니다. 리더가 한 번에 X개의 조각을 외부에 배포하는 것은 X개의 서로 다른 작은 블록을 발송하여 서로 다른 노드가 수신하고 추가로 전파하도록 하는 것입니다.

Solana의 이러한 메시지 전파 방식은 매우 특별하며, BT 씨앗에서 영감을 받았습니다. (원리는 글로 설명하기 어렵고, 주된 목적은 여러 노드의 유휴 대역폭을 동시에 활용하여 병렬로 데이터를 전송하는 것입니다). 일반적으로, 거래 시퀀스가 나누어지는 조각 수가 많을수록, 노드 집단이 조각을 전파하고 거래 시퀀스를 조합하는 속도가 빨라지며, 데이터 동기화 효율도 크게 향상됩니다.

다른 공공 블록체인에서는 블록 생성자가 X개의 이웃 노드에게 동일한 블록을 전송하여 X개의 복사본을 발송하는 것이며, X개의 서로 다른 조각(작은 블록)을 배포하는 것이 아닙니다. 이러한 방식은 데이터 중복과 대역폭 낭비가 심각합니다. 그 근본 원인은 전통적인 블록(Block) 구조가 나눌 수 없기 때문에 유연하게 전송할 수 없기 때문입니다. Solana는 거래 시퀀스(Sequence)를 블록 구조 대신 사용하여, BT 씨앗과 유사한 Turbine 프로토콜과 결합하여 고속 데이터 전파를 실현하고 TPS를 크게 향상시켰습니다.

Solana 공식에 따르면, Turbine 전송 프로토콜 하에서 네트워크에 4만 개의 노드가 있을 경우, 0.5초 내에 하나의 거래 시퀀스를 모든 노드에 동기화할 수 있습니다.

동시에 Turbine 프로토콜 하에서 노드는 스테이킹 자산의 가중치에 따라 서로 다른 계층(우선 순위)으로 나뉘며, 스테이킹 자산이 많은 검증자가 먼저 리더가 발송한 데이터를 수신한 후, 이러한 노드가 다음 계층에 전달합니다. 이러한 메커니즘 하에서, 전체 네트워크의 스테이킹 자산 2/3의 가중치를 차지하는 노드 집단이 리더가 발송한 거래 시퀀스를 가장 먼저 수록하여 원장(블록)의 확인 속도를 높입니다.

Solana 브라우저에서 공개된 데이터에 따르면, 현재 2/3의 스테이킹 가중치는 132개의 노드가 차지하고 있으며, 앞서 언급한 전파 메커니즘과 결합하여 이들 노드는 리더가 발송한 거래 시퀀스를 가장 먼저 수신하고, 가장 먼저 투표를 제공합니다. 이 132개의 노드의 투표를 얻기만 하면 리더가 발표한 거래 시퀀스가 확정됩니다. 어떤 관점에서는 이들 노드가 다른 노드보다 먼저 행동하여, 그들이 공모하면 특정 악의적인 상황을 초래할 수 있습니다.

더욱 주목할 점은 현재 Solana에는 25개의 노드가 1/3의 스테이킹 가중치를 차지하고 있으며, 비잔틴 내결함성 이론에 따르면, 이 25개 노드가 집단적으로 공모하면(예: 특정 리더에게 투표를 발송하지 않기로 결정) Solana 네트워크가 혼란에 빠질 수 있습니다. 어떤 면에서는 Solana가 직면한 "과두 정치" 문제는 모든 POS 투표제를 채택한 공공 블록체인이 주의해야 할 사항입니다.

4. POH(Proof Of History): 앞서 언급한 Turbine 프로토콜은 리더가 거래 시퀀스를 조각으로 나누어 서로 다른 조각을 발송할 수 있게 합니다. 이러한 방식은 보장되어야 합니다: 거래 시퀀스가 조각으로 나누어진 후 쉽게 조합될 수 있어야 합니다. 이 문제를 해결하기 위해 Solana는 데이터 패킷에 오류 정정 코드를 삽입하여(데이터 손실 방지) 독창적인 POH(Proof Of History) 메커니즘을 도입하여 거래 이벤트를 정렬합니다.

Solana 백서에서 야코벤코는 해시 함수 SHA256을 사례로 들어 POH의 원리를 설명했습니다. 이해를 돕기 위해 본문에서는 다음과 같은 예를 통해 POH 메커니즘을 설명합니다:

(POH 및 해당 시간 진화 논리는 언어로 설명하기 어렵기 때문에, 먼저 Solana 중국어 백서에서 POH에 대한 해석을 읽고, 본문의 다음 부분을 보조 읽기로 활용하는 것을 권장합니다)

·SHA256 함수의 입력값과 출력값은 유일하게 매핑됩니다(1대1). 입력 매개변수 X 후, 유일한 출력 결과 SHA256(X)=?; 서로 다른 X는 서로 다른 ?=SHA256(X)를 생성합니다;

·SHA256을 반복적으로 계산하면, 예를 들어:
X2=SHA256(X1)로 정의하고, X2를 사용하여 X3=SHA256(X2), X4=SHA256(X3) 등을 반복적으로 계산합니다. 이렇게 반복적으로 수행하면, Xn=SHA256(X[n-1])이 됩니다;

·이 과정을 반복하면, 결국 X1, X2, X3……Xn의 시퀀스를 얻을 수 있으며, 이 시퀀스는 다음과 같은 특징이 있습니다: Xn=SHA256(X[n-1])이며, 뒤에 있는 Xn은 앞에 있는 X[n-1]의 "후손"입니다.

·이 시퀀스를 공개적으로 발표한 후, 외부인이 시퀀스의 정확성을 검증하고 싶다면, 예를 들어 Xn이 정말로 X[n-1]의 "합법적인 후손"인지 판단하고 싶다면, X[n-1]을 SHA256 함수에 대입하여 결과가 Xn과 동일한지 확인할 수 있습니다.

·이러한 방식에서는 X1이 없으면 X2를 얻을 수 없고, X2가 없으면 X3를 얻을 수 없으며…… Xn이 없으면 그 이후의 X[n+1]을 얻을 수 없습니다. 이렇게 되면 시퀀스는 연속성과 유일성을 갖게 됩니다.

·가장 중요한 점: 거래 이벤트는 시퀀스에 삽입될 수 있습니다. 예를 들어:
x3가 생성된 후 x4가 나타나기 전에, 거래 이벤트 T1이 외부 입력으로 사용되어 X3와 결합하여 x4=SHA256(X3+T1)가 됩니다. 여기서 X3는 T1보다 약간 먼저 발생하고, X4는 (T1+X3)로 태어난 후손입니다. T1은 X3와 X4의 "생일" 사이에 끼어 있습니다.

이와 유사하게, T2는 X8이 생성된 후 외부 입력 매개변수로 사용되어 X9=SHA256(T2+X8)로 계산되며, 이 경우 T2의 발생 시간은 X8과 X9의 "생일" 사이에 끼어 있습니다;

•위의 시나리오에서 실제 POH 시퀀스는 다음과 같은 형태입니다:

여기서 거래 이벤트 T1과 T2는 외부에서 시퀀스에 삽입된 데이터로, POH 시퀀스의 시간 기록에서 T1은 X3보다 늦고 X4보다 이릅니다.
T1이 POH 시퀀스에서 차지하는 순서 번호를 제공하면, T1 이전에 얼마나 많은 SHA256 계산이 발생했는지를 알 수 있습니다( T1 앞에는 X1, X2, X3가 있으며, 3번의 SHA256 계산이 발생했습니다).
동일한 원리로, T2 앞에는 X1~X8의 8개 X가 있으며, 8번의 계산이 발생했습니다.

이 과정을 간단히 설명하면: 어떤 사람이 초시계를 가지고 초를 세고 있으며, 그가 편지를 받을 때마다 초시계의 읽은 값을 신봉에 기록합니다. 10개의 편지를 받은 후, 이 10개의 편지에 기록된 초는 반드시 서로 다르며, 선후 구분이 있어 서로 다른 편지에 순서를 매길 수 있습니다. 이로 인해 편지 간의 시간 간격도 알 수 있습니다.

·리더가 거래 시퀀스를 외부에 발표할 때, T1의 데이터 패킷에 X3의 값을 제공하고 X3의 순서 번호를 알려주면, 데이터를 수신한 검증자는 T1 이전의 전체 POH 시퀀스를 해석할 수 있습니다;
T2의 데이터 패킷에 X8의 값을 제공하고 그 순서 번호 8을 제공하면, 검증자는 T2 이전의 전체 POH 시퀀스를 해석할 수 있습니다;

·POH의 설정에 따르면, 각 거래의 POH 시퀀스 내 순서 번호(Counter)를 표시하고 그 옆에 있는 X 값을 제공하면, 각 거래의 순서를 공개할 수 있습니다. SHA256 함수 자체의 특성 덕분에, 이러한 해시 계산을 통해 확정된 순서는 변경하기 어렵습니다.

동시에, 검증자는 리더가 POH 시퀀스를 도출하는 방식을 알고 있으며, 그들은 동일한 작업을 수행하여 전체 POH 시퀀스를 복원하고 리더가 발표한 데이터의 정확성을 검증할 수 있습니다.

예를 들어, 리더가 발표한 거래 시퀀스 데이터 패킷이 다음과 같다면:
T1, 순서 번호 3, X3에 인접;
T2, 순서 번호 5, X5에 인접;
T3, 순서 번호 8, X8에 인접;
T4, 순서 번호 10, X10에 인접;
POH 시퀀스 초기값 X1;

검증자는 위의 데이터 패킷을 수신한 후, X1을 초기 매개변수로 사용하여 SHA256 함수를 반복적으로 대입하여 전체 POH 시퀀스를 해석할 수 있습니다:

이렇게 되면, 시퀀스에 포함된 X의 총 개수를 알기만 하면, 계산자가 몇 번 SHA256 계산을 수행했는지를 알 수 있습니다. 각 해시 계산의 소요 시간을 미리 추정하면, 서로 다른 거래의 시간 간격을 알 수 있습니다(예: T1과 T2 사이에 2개의 X가 있으며, 2번의 SHA256 계산이 소요되었다면 약 ?? 밀리초가 됩니다). 서로 다른 거래 간의 초 간격을 알게 되면, 각 거래의 발생 시간을 대략적으로 추정할 수 있어 많은 편리함을 가져옵니다.

동시에 POH 메커니즘은 각 노드가 투표를 제공한 시간점을 통계적으로 수집하는 데도 용이합니다. Solana 백서에서는 검증자가 리더가 매번 상태 정보를 발표한 후 0.5초 이내에 투표를 제공해야 한다고 제안합니다.

0.5초가 100만 번의 해시 계산에 해당하며(앞서 언급한 100만 개의 X), 리더가 상태를 발표한 후, 이후의 시퀀스에서 연속적으로 100만 번의 해시 계산이 특정 노드의 투표에 포함되지 않으면, 모두가 이 노드가 게으르며 정해진 시간 내에 투표 의무를 이행하지 않았음을 알 수 있습니다. 이때 시스템은 해당 노드에 대해 적절한 처벌 조치를 실행할 수 있습니다 (Tower BFT).

6. Optimism과의 유사성: 위에서 설명한 것이 Solana의 독창적인 POH(Proof Of History)이며, Optimism과 Arbitrum의 거래 정렬 형식과 유사합니다. 두 경우 모두 해시 함수와 관련된 계산을 통해 "변경할 수 없고, 유일하게 결정된" 거래 이벤트 시퀀스를 확립한 후, 리더/시퀀서가 이 시퀀스를 검증자/검증자에게 발표합니다.

Optimism에서도 리더와 유사한 역할이 있으며, 이를 시퀀서(Sequencer)라고 부릅니다. 데이터 전송 과정에서 블록 구조를 폐지하고 정기적으로 이더리움의 특정 계약 주소에 거래 시퀀스를 발표하여 검증자가 스스로 읽고 실행하도록 합니다. 서로 다른 검증자가 동일한 거래 시퀀스를 수신하면, 그들이 실행한 후 얻은 상태(State)도 반드시 동일합니다. 이때 시퀀서의 상태(State)를 비교하면 각 검증자가 스스로 그 정확성을 검증할 수 있으며, 다른 노드와 소통할 필요가 거의 없습니다.

Optimism의 합의 메커니즘에서는 서로 다른 검증자 간의 상호작용을 요구하지 않으며, 투표를 수집하는 단계도 없습니다. "합의"는 사실상 암묵적입니다. 검증자가 거래 시퀀스를 실행한 후 시퀀서/리더가 제공한 상태 정보(State)가 잘못된 것을 발견하면 "도전"을 제기하여 시퀀서/리더에 이의를 제기할 수 있습니다. 그러나 이러한 모드에서는 Optimism이 거래 이벤트에 대해 7일의 확정 창을 제공하며, 시퀀서가 거래 시퀀스를 발표한 후 7일 동안 이의가 없으면 최종 확인됩니다. 이는 분명히 Solana가 수용할 수 없는 것입니다.

Solana는 검증자가 신속하게 투표를 제공하도록 요구하며, 이는 네트워크가 빠르게 합의에 도달하고 거래 시퀀스를 신속하게 확정하도록 하여 Optimism보다 더 높은 효율성을 갖게 합니다.

또한 Solana는 거래 시퀀스를 분배하고 검증하는 방식이 더 유연하여, 하나의 시퀀스를 조각으로 나누어 분배할 수 있도록 하여 Turbine 프로토콜의 시행을 위한 완벽한 토대를 제공합니다;

동시에 Solana는 노드가 여러 계산 부품을 동시에 실행하도록 허용하여 병렬 방식으로 서로 다른 조각의 정확성을 검증하고 검증 작업을 분담하여 시간을 대폭 절약합니다. OP와 Arbitrum에서는 이러한 방식이 허용되지 않으며, Optimism은 1개의 거래가 1개의 실행 후 상태(State)에 대응하도록 하여 거래 시퀀스를 제공하며, 반드시 하나의 CPU 코어가 처음부터 끝까지 단계별로 계산하여 전체 시퀀스의 정확성을 검증해야 하므로 상대적으로 비효율적입니다. Solana의 POH 시퀀스는 임의의 위치에서 검증을 시작할 수 있으며, 여러 계산 단위가 동시에 서로 다른 POH 조각을 검증할 수 있어 다중 스레드 병렬 검증 모드를 위한 기초를 제공합니다.

7. 노드 자체에 대한 수직 확장: 위에서 설명한 것은 Solana의 블록 생성 프로세스, 합의 메커니즘 및 데이터 전송 프로토콜의 개선 사항이며, 그 외에도 Solana는 Sealevel, Pipeline, Cloudbreak라는 메커니즘을 만들어 다중 스레드, 병렬 및 동시 실행 모드를 지원하고 GPU를 실행 계산 부품으로 사용하여 노드의 지시 처리 속도를 대폭 향상시키고 하드웨어 자원의 이용 효율성을 최적화하여 수직 확장의 범주에 속합니다. 관련 기술 세부 사항이 복잡하고 본문의 초점과 관련이 없으므로 여기서는 자세히 설명하지 않겠습니다.

Solana의 수직 확장은 노드 장비의 거래 지시 처리 속도를 대폭 향상시켰지만, 하드웨어 구성에 대한 요구를 높였습니다. 현재 Solana의 노드 구성 요구 사항은 매우 높으며, 많은 사람들이 "기업급 하드웨어 수준"으로 평가하고 "노드 장비가 가장 비싼 공공 블록체인"이라고 비난합니다.

다음은 Solana의 검증자 노드 하드웨어 요구 사항입니다:
CPU 12 또는 24코어, 메모리 최소 128GB, 하드 드라이브 2TB SSD, 네트워크 대역폭 최소 300MB/s, 일반적으로 1GB/s입니다.
현재 이더리움 노드의 하드웨어 요구 사항(전환 전 POS):
CPU 4코어 이상, 메모리 최소 16GB, 하드 드라이브 0.5TB SSD, 네트워크 대역폭 최소 25MB/s입니다.

이더리움이 POS로 전환한 후 노드 하드웨어 구성 요구 사항이 낮아질 것을 고려할 때, Solana의 노드 하드웨어 요구 사항은 전자보다 훨씬 높습니다. 일부 주장에 따르면, Solana 노드의 하드웨어 비용은 POS로 전환된 이더리움 노드 수백 개에 해당합니다. 노드 운영 비용이 너무 높기 때문에 Solana 네트워크의 운영 작업은 고래와 전문 기관, 기업의 전유물이 되었습니다.

이에 대해 이더리움 전 CTO이자 Polkadot 창립자인 가빈 우드는 지난해 Solana가 처음 다운된 후 다음과 같이 논평했습니다: 진정한 탈중앙화와 안전성은 높은 효율성보다 더 가치가 있습니다. 사용자가 네트워크의 전체 노드를 직접 운영할 수 없다면, 이러한 프로젝트는 전통적인 은행과 다를 바 없습니다.

전체 요약

• Solana의 확장은 주로 네트워크 대역폭의 효율적 이용, 노드 간 통신 횟수 감소, 노드 처리 속도 증가의 세 가지 측면에 기반하고 있으며, 이러한 조치는 블록 생성 및 합의 통신 시간을 직접적으로 단축시키지만 시스템의 가용성(안전성)을 저하시킵니다.
• Solana는 각 블록 생성 주기 Slot 내의 블록 생성자 리더 목록을 사전에 공개하여 사실상 단일 신뢰 데이터 출처를 드러내고, 이를 통해 합의 통신 프로세스를 대폭 간소화했습니다. 그러나 리더 정보를 공개하면 뇌물, 표적 공격 등의 잠재적 보안 위험이 발생할 수 있습니다.
• Solana는 합의 통신(투표 정보)을 거래 이벤트로 처리하며, TPS 구성 요소 중 70% 이상이 합의 메시지이고, 실제 사용자 거래와 관련된 TPS는 약 500---1000입니다;
• Solana의 Gulf Stream 메커니즘은 전역 거래 풀을 사실상 폐지하여 거래 처리 속도를 높였지만, 일반 노드는 쓰레기 거래를 효율적으로 차단할 수 없으며, 리더는 큰 압박을 받아 다운될 위험이 큽니다. 리더가 다운되면 합의 메시지가 정상적으로 발표되지 않아 네트워크가 쉽게 분기되거나 붕괴될 수 있습니다;
• Solana의 리더 노드는 실제 블록이 아닌 거래 시퀀스를 발표합니다. Turbine 전송 프로토콜과 결합하여 거래 시퀀스는 조각으로 나누어져 다양한 노드에 배포되며, 최종 데이터 동기화 속도가 매우 빠릅니다.
• POH(Proof Of History)는 본질적으로 시간 측정 및 계산 방법으로, 서로 다른 거래 이벤트에 변경할 수 없는 번호를 부여하여 거래 시퀀스를 생성합니다. 동시에 동일한 시간에 단일 리더만 거래 시퀀스를 발표하므로 POH 타이밍 시퀀스가 포함되어 리더는 사실상 전체 네트워크에 일관된 타이머(시계)를 발표합니다. 짧은 시간 창 내에서 서로 다른 노드의 원장 진행 및 시간 경과는 일관됩니다;
• Solana에는 132개의 노드가 67%의 스테이킹 점유율을 차지하고 있으며, 그 중 25개의 노드가 33%의 스테이킹 점유율을 차지하여 기본적으로 "과두 정치" 또는 "원로원"을 구성합니다. 이 25개 노드가 공모하면 네트워크가 혼란에 빠질 수 있습니다;
• Solana는 노드 하드웨어 수준에 대한 요구가 높으며, 장비 비용을 대가로 수직 확장을 실현했습니다. 그러나 이는 Solana 노드를 운영하는 개인이 대부분 고래 또는 기관, 기업으로 진정한 의미의 탈중앙화에 불리합니다.

어떤 면에서는 Solana가 실제로 공공 블록체인 중 가장 독특한 존재가 되었으며, 고급 노드 하드웨어 수준, 파괴적인 합의 메커니즘 및 네트워크 전송 프로토콜을 통해 Layer1 확장의 내러티브를 극단으로 밀어붙여 기본적으로 무분할 공공 블록체인이 장기적으로 유지할 수 있는 TPS 한계에 도달했습니다. 그러나 Solana의 여러 차례 다운타임은 가용성/안전성을 희생하여 효율성을 얻는 결과의 최종 결론을 이미 암시하고 있습니다.

장기적으로 볼 때, 탈중앙화와 안전성은 항상 공공 블록체인 분야의 핵심 내러티브입니다. Solana가 일시적인 TPS 수치와 SBF 등 금융 거물의 지원 덕분에 한때 자본의 주목을 받는 보물이 되었지만, EOS의 결말은 이미 증명되었습니다. Web3 세계는 단순한 마케팅과 높은 효율성을 필요로 하지 않으며, 오직 진정한 가용성을 갖춘 것만이 역사적 흐름 속에서 굳건히 서고 영원히 존재할 수 있습니다.

(이 자리를 빌어 《임베디드 시스템 보안》의 저자 리우양 씨, Rebase 커뮤니티 및 W3.Hitchhiker 팀의 도움에 깊이 감사드립니다)

참고 문헌
1. Solana 백서中文版
2. Gulf Stream: Solana의 Mempool-less 거래 전달 프로토콜

3. Turbine 블록 전파

4. Solana 조사 보고서

5. Solana의 여정

6. 바이낸스 지갑과 협력하는 고성능 공공 블록체인 Solana는 어떻게 속도를 높였는가?

7. 블록체인을 초당 710,000 거래로 오버클럭: Proof of History 알고리즘 리뷰

8. Solana의 반격의 길 - SQLANA

9. PoS와 Tendermint 합의 설명

10. 이더리움 소스 코드 분석: 거래 버퍼 풀 txpool

11. 이더리움 거래 풀 아키텍처 설계

12. PBFT 기본 프로세스

13. Tendermint-2-합의 알고리즘: Tendermint-BFT 상세 설명

14. Cardano(ADA)의 합의 알고리즘 Ouroboros

15. 심층 조사: 새로운 공공 블록체인들이 왜 자주 다운되는가?

16. Optimism 심층 해석: 기본 아키텍처, 가스 메커니즘 및 도전 과제 | CatcherVC Research

17. 새로운 Metis 분석: 가스 최저 Layer2의 탈중앙화 진행 중 | CatcherVC Research