Turbine: Solana의 블록 전파

이 글에서는 무엇을 다루나요?

데이터 가용성은 블록체인에서 매우 중요합니다. 검증에 필요한 모든 정보에 노드가 즉시 접근할 수 있도록 하여 네트워크의 무결성과 보안을 유지합니다. 하지만 높은 성능을 유지하면서 데이터 가용성을 보장하기란 쉽지 않습니다. 특히 네트워크가 확장될수록 더 큰 과제가 됩니다.

Solana는 지속적인 블록 생성과 전파를 지원하는 독특한 아키텍처 설계로 이 과제를 해결했습니다. 리더 선정, Gulf Stream(멤풀의 필요성 제거), Turbine(블록 전파 메커니즘)과 같은 몇 가지 핵심 혁신 덕분입니다.

Solana는 연속적으로 작동하므로 모든 검증인이 최신 상태를 신속히 수신할 수 있는 효율적인 시스템이 필요합니다. 가장 단순한 방식은 리더가 모든 블록을 다른 모든 검증인에게 직접 전송하는 것입니다. 하지만 Solana의 높은 처리량을 고려하면 이 방식은 대역폭과 기타 리소스 요구량을 크게 늘리고 탈중앙화를 저해합니다.

대역폭은 희소한 리소스입니다. Turbine은 특정 블록의 리더가 나머지 네트워크로 정보를 효율적으로 전파하도록 최적화한 Solana의 독창적인 솔루션입니다. Turbine은 리더에서 네트워크로 데이터를 내보내는 이그레스 부담을 줄이기 위해 특별히 설계되었습니다.

이 글에서는 Turbine의 작동 방식과 Solana의 전반적인 트랜잭션 포함 과정에서 수행하는 핵심 역할을 자세히 살펴봅니다. 또한 Turbine을 다른 데이터 가용성 솔루션과 비교하고 이 분야에서 아직 열려 있는 연구 주제를 논의합니다.

Turbine이란 무엇인가요?

Turbine은 Solana 클러스터가 원장 항목을 모든 노드에 브로드캐스트하는 데 사용하는 다계층 블록 전파 메커니즘입니다. Turbine의 핵심 아이디어는 학계에서 오랫동안 연구되어 왔습니다. 2004년에 발표된 논문과 최근 연구에서도 이를 확인할 수 있습니다.

블록을 모든 노드에 순차적으로 전송하거나 플러딩하는 기존 블록체인과 달리, Turbine은 통신 오버헤드를 최소화하고 개별 노드의 부하를 줄이기 위해 더 구조적인 방식을 사용합니다. 개괄적으로 보면 Turbine은 블록을 더 작은 조각으로 나누고, 노드 계층 구조를 통해 이 조각들을 배포합니다. 개별 노드는 다른 모든 노드와 연결할 필요 없이 선택된 소수의 노드와만 통신하면 됩니다. 네트워크 규모가 커질수록 이 특성은 더욱 중요해집니다. 기존 전파 방식은 막대한 통신량 때문에 유지하기 어려워지기 때문입니다. 따라서 Turbine은 Solana 전반에 데이터를 빠르고 효율적으로 배포합니다. 블록 전파 및 검증 속도는 Solana의 높은 처리량과 네트워크 보안을 유지하는 데 매우 중요합니다.

또한 Turbine은 데이터 가용성 문제를 해결하여 모든 노드가 트랜잭션 검증에 필요한 데이터에 효율적으로 접근할 수 있도록 합니다. 다른 블록체인 네트워크에서 흔히 병목이 되는 막대한 대역폭도 요구하지 않습니다.

Turbine은 대역폭 병목을 완화하고 블록을 빠르게 전파하여 Solana가 많은 트랜잭션을 처리하면서 간결하고 효율적인 네트워크 구조를 유지하도록 크게 기여합니다. 이 혁신적인 프로토콜은 빠르고 안전하며 확장 가능한 네트워크라는 Solana의 약속을 실현하는 핵심 기반 중 하나입니다.

이제 Turbine의 작동 원리와 Solana 네트워크 전반에 블록을 전파하는 방식을 더 자세히 살펴보겠습니다.

Turbine은 블록을 어떻게 전파하나요?

블록을 전파하기 전, 즉 네트워크의 다른 검증인에게 전송하기 전에 리더는 유입되는 트랜잭션 스트림을 바탕으로 블록을 구성하고 순서를 정합니다. 블록이 완성되면 Turbine을 통해 나머지 네트워크로 전송할 준비가 됩니다. 이 과정을 블록 전파라고 합니다. 이후 검증인 간에 투표 메시지가 전달되며, 이 메시지는 블록 데이터에 포함되어 커밋 상태인 “confirmed” 또는 “finalized”를 충족합니다. confirmed 블록은 원장 투표의 압도적 다수를 확보한 블록입니다. finalized 블록은 confirmed 상태이며 대상 블록 위에 31개 이상의 confirmed 블록이 추가로 생성된 블록입니다. 커밋 상태의 차이는 여기에서 자세히 설명합니다. 합의의 이 부분은 향후 게시물에서 다룰 예정입니다.

리더는 전체 블록을 구성하고 제안하지만, 실제 데이터는 샤드(부분 블록) 형태로 네트워크의 다른 검증인에게 전송됩니다. 샤드는 검증인 간에 전송되는 원자 단위입니다.

개괄적으로 Turbine은 샤드를 미리 정해진 검증인 집합에 전송하고, 해당 검증인들은 다시 새로운 검증인 집합에 샤드를 전달합니다. 다음 다이어그램은 샤드가 지속적으로 전파되는 과정을 보여줍니다.

이 예시에서는 검증인 1이 지정된 슬롯 리더입니다. 자신의 슬롯 동안 검증인 1은 블록을 구성하고 제안합니다. 검증인에게는 연속된 4개 슬롯의 리더 역할이 할당됩니다. 검증인 1은 먼저 shredding이라는 과정을 통해 블록을 샤드라는 하위 블록으로 나눕니다. Shredding은 블록 데이터를 최대 전송 단위(MTU) 크기의 데이터 샤드로 분할하고, Reed-Solomon 소거 코딩 체계를 통해 이에 대응하는 복구 샤드를 생성합니다. MTU는 한 노드에서 다음 노드로 더 작은 단위로 조각내지 않고 전송할 수 있는 최대 데이터양입니다. 이 체계는 데이터 복구를 지원하고 전송 중 데이터 무결성을 보장합니다. 이는 네트워크의 보안과 신뢰성을 유지하는 데 매우 중요합니다.

이러한 샤드 분할 및 전파 과정은 Solana 전반에 블록 데이터를 빠르고 효율적으로 배포하여 높은 처리량과 네트워크 보안을 유지합니다.

소거 코딩

샤드는 Turbine Tree를 통해 전파되기 전에 먼저 다항식 기반 오류 감지 및 수정 체계인 Reed-Solomon 소거 코딩으로 인코딩됩니다. 소거 코딩은 전송 중 일부가 유실되거나 손상되더라도 원본 데이터를 복구할 수 있게 하는 데이터 보호 방식입니다. Reed-Solomon 소거 코딩은 순방향 오류 정정(FEC) 알고리즘의 한 유형입니다.

Turbine은 근본적으로 하위 검증인의 연속적인 패킷 재전송에 의존합니다. 해당 검증인은 잘못된 데이터를 재브로드캐스트하는 악의적인 노드(적대적 Byzantine 노드)일 수 있으며, 불완전한 데이터(네트워크 패킷 손실)를 수신할 수도 있습니다. Turbine의 재전송 트리 구조에서는 네트워크 전반의 패킷 손실이 누적되며, 각 홉을 지날 때마다 패킷이 목적지에 도달하지 못할 확률이 높아집니다.

개괄적으로 리더가 블록 패킷의 33%를 소거 코드로 전송하면, 네트워크는 블록 손실 없이 전체 패킷 중 최대 33%를 유실할 수 있습니다. 리더는 최근 관측된 네트워크 전체의 패킷 손실과 트리 깊이 같은 변수를 고려하여 네트워크 상태에 따라 이 수치(FEC 비율)를 동적으로 조정할 수 있습니다.

단순화를 위해 FEC 비율이 4:4인 샤드 그룹을 살펴보겠습니다.

데이터 샤드는 리더가 구성한 원본 블록의 일부이며, 복구 샤드는 Reed-Solomon으로 생성된 소거 코딩 블록입니다.

Solana의 블록은 일반적으로 32:32 FEC를 사용합니다. 즉, 64개 패킷 중 32개가 유실되어도 재전송할 필요가 없습니다. Solana 문서에 따르면 다음과 같은 보수적인 네트워크 가정을 사용합니다.

• 패킷 손실률 15%
• 50k TPS에서 초당 6,400개 샤드 생성

FEC 비율이 32:32이면 블록 성공률은 ~99%입니다. 또한 리더는 블록 성공 확률을 높이기 위해 필요에 따라 FEC 비율을 높일 수 있습니다.

Turbine은 현재 블록 전파에 UDP를 사용하여 상당한 지연 시간 이점을 제공합니다. 한 검증인 운영자에 따르면 UDP로 us-east-1에서 eu-north-1까지 6 MB와 소거 코딩 데이터를 전송하는 데는 100ms가 걸리지만, TCP로는 900ms가 걸립니다.

Turbine Tree

Turbine Tree는 Solana가 검증인 간에 샤드(인코딩된 블록 데이터)를 효율적으로 전파하기 위해 사용하는 구조화된 네트워크 토폴로지입니다. 샤드가 각각의 샤드 그룹으로 올바르게 인코딩되면 Turbine Tree를 통해 배포할 준비가 됩니다. 이를 통해 네트워크의 다른 검증인에게 최신 상태를 알립니다.

각 샤드 그룹은 네트워크 패킷을 통해 첫 번째 계층(1홉 거리)에 포함될 검증인을 관리하는 특수 루트 노드로 전송됩니다. 그런 다음 다음 단계가 실행됩니다.

1. 목록 생성: 루트 노드는 활성 검증인을 모두 하나의 목록으로 모은 다음, 각 검증인이 네트워크에 보유한 스테이킹 비중에 따라 정렬합니다. 스테이킹 가중치가 높은 검증인이 샤드를 먼저 수신하도록 우선순위를 부여하여, 합의를 위한 자체 투표 메시지를 더 빠르게 보낼 수 있게 합니다.
2. 목록 셔플: 이 목록은 결정론적 방식으로 섞입니다. 슬롯 리더 ID, 슬롯, 샤드 인덱스, 샤드 유형에서 파생된 시드를 사용하여 각 샤드의 검증인 노드 집합으로 “Turbine Tree”를 생성합니다. 정적 트리 구조에 따른 잠재적 보안 위험을 완화하기 위해 각 샤드 그룹마다 런타임에 새로운 트리를 생성합니다.
3. 계층 구성: 그런 다음 목록 상단부터 노드를 여러 계층으로 나눕니다. 분할은 Turbine Tree의 너비와 깊이를 결정하는 DATA_PLANE_FANOUT 값을 기준으로 합니다. 이 값은 샤드가 네트워크를 통해 전파되는 속도에 영향을 줍니다. 현재 DATA_PLANE_FANOUT은 200이므로 대부분의 검증인은 2~3홉 거리에 있습니다(리더 -> 루트 -> L1 -> L2).

모두에게 공개된 Turbine Tree를 통해 각 검증인은 해당 샤드를 어디로 전달해야 하는지 정확히 알 수 있습니다. 현재 DATA_PLANE_FANOUT 값이 200이므로 Turbine Tree는 일반적으로 2홉 또는 3홉 트리입니다. 정확한 홉 수는 활성 검증인 수에 따라 달라집니다.

또한 노드는 충분한 샤드를 받지 못하거나 손실률이 FEC 비율을 초과하면 gossip과 repair를 대신 사용할 수 있습니다. 현재 구현에서 블록을 재구성할 만큼 충분한 샤드가 없는 노드는 리더에게 재전송을 요청합니다. 결정론적 Turbine에서는 전체 블록을 수신한 모든 노드가 요청 노드에 필요한 repair 샤드를 보낼 수 있습니다. 이에 따라 데이터 전송은 데이터를 요청하는 트리 하단 영역까지 이어집니다.

Solana와 Ethereum의 블록 전파 비교

Solana의 블록 전파는 Ethereum과 다릅니다. 주요 차이점은 다음과 같습니다.

• Solana의 이상적인 대역폭 요구 사항(>1 Gbps)은 Ethereum(geth 권장 사양 >25 Mbps)보다 훨씬 높습니다. Solana는 블록 크기가 더 크고 블록 생성 시간이 더 짧기 때문에 더 높은 대역폭이 필요합니다. Solana는 전체 대역폭을 효과적으로 활용하여 데이터 전송 속도를 높이고 지연 시간을 줄이도록 설계되었습니다. 대역폭 사용량이 최대 1 Gbps까지 급증할 수 있지만 계속 1 Gbps를 사용하는 것은 아닙니다. Solana의 아키텍처는 대역폭 수요의 급증을 특별히 지원합니다.
• Solana는 블록 데이터 전파에 Turbine을 사용하지만 Ethereum은 표준 gossip 프로토콜을 사용합니다. Ethereum의 블록 데이터 전파 방식은 단순합니다. 각 노드가 네트워크의 다른 모든 풀 노드와 통신합니다. 새 블록이 생성되면 클라이언트는 이를 피어에게 전송하고 블록 내 트랜잭션을 승인하여 검증합니다. Ethereum은 Solana보다 블록 크기가 작고 블록 생성 시간이 길기 때문에 이 메커니즘이 적합합니다. Ethereum L2 롤업 데이터(validium 제외)도 gossip 프로토콜을 통해 전파되며, 블록 데이터는 Ethereum L1 블록의 “calldata” 필드에 저장됩니다.
• Ethereum은 블록 전파에 TCP(DevP2P 프로토콜를 통해)를 사용하고 Solana는 UDP(QUIC 전환을 지지하는 일부 커뮤니티 의견이 있음)를 사용합니다. UDP와 QUIC 사이에는 몇 가지 절충점을 고려해야 합니다.
• UDP는 단방향이므로 QUIC 스트림이 필요한 QUIC보다 지연 시간이 짧습니다. QUIC에 단방향 스트림을 구현하는 방안이 계속 논의되고 있습니다.
• QUIC 지지자들은 UDP에서도 사용자 지정 제어 흐름을 구현할 수 있지만 상당한 엔지니어링 작업이 필요하며, QUIC은 이러한 기능을 기본 지원하여 이 부담을 줄인다고 주장합니다. 최종 목표는 같지만 QUIC 성능의 상한선(지연 시간, 처리량 등)은 현재 순수 UDP의 성능 수준입니다.

이러한 차이는 Solana와 Ethereum이 채택한 고유한 아키텍처 결정을 보여주며, 각 네트워크의 성능과 확장성, 견고성에 영향을 줍니다. TCP, UDP, QUIC에 대한 더 자세한 분석은 Solana와 QUIC 글에서 확인하세요.

향후 연구 질문

블록 전파와 데이터 가용성은 여전히 열린 연구 분야이며, 수많은 팀이 각자 고유한 접근 방식을 개발하고 있습니다. 지표는 달라질 수 있지만, 여러 접근 방식과 관련 절충점을 간략히 살펴보겠습니다.

• Turbine을 “데이터 가용성”(DA) 메커니즘으로 볼 수 있는지를 두고 몇 가지 논의가 있었습니다. Turbine에서는 전체 블록 데이터가 게시되고 Solana의 다른 모든 검증인이 이를 다운로드하므로 데이터 가용성 메커니즘으로 볼 수 있습니다. 하지만 Turbine은 더 낮은 하드웨어 요구 사항으로 라이트 노드가 상태를 검증하도록 지원하는 데이터 가용성 샘플링(DAS)을 지원하지 않습니다. 이는 Celestia 같은 팀이 활발히 개발 중인 핵심 영역입니다. Turbine과 마찬가지로 DAS도 소거 코드를 사용하지만, 데이터 보류 공격을 감지하고 방지하는 것이 명시적인 목적입니다.
• Eclipse 같은 Solana Virtual Machine (SVM) L2에는 데이터를 전달할 검증인 집합이 없으므로 Turbine의 관련성이 떨어집니다. Eclipse에서는 데이터 가용성을 위해 블록 데이터를 Celestia에 게시합니다. 이를 통해 외부 관찰자가 사기 증명을 실행하여 올바른 실행과 상태 전환을 확인할 수 있습니다. Eclipse는 Solana 네트워크 외부에서 SVM을 구현한 최초 사례 중 하나가 될 것입니다. Pyth도 “Pythnet”이라는 자체 오라클 네트워크를 위해 SVM을 포크했으며, 사실상 자체 사이드체인으로 운영됩니다.
• Solana의 풀 노드는 블록 전파를 관리하는 동시에 트랜잭션 순서 지정과 합의 등 통합 블록체인 스택의 다른 영역에도 관여합니다. Turbine을 특수 하드웨어의 모듈식 구성 요소로 운영한다면 정량적 지표는 어떻게 달라질까요?
• Turbine은 스테이킹 가중치가 높은 노드가 블록 데이터를 먼저 받도록 우선순위를 부여합니다. 시간이 지남에 따라 MEV 중앙화가 심해질까요?
• EigenDA(수평 확장 가능한 단일 유니캐스트 릴레이어)와 Celestia(데이터 가용성 샘플링) 같은 데이터 가용성 접근 방식은 프로덕션 환경에서 순수 처리량과 신뢰 최소화 측면으로 Turbine과 어떻게 비교될까요?
• Firedancer는 데이터 전파 성능을 더욱 높이는 것을 목표로 하며 안정적인 10 Gbps 대역폭 연결에 최적화되어 있습니다. Turbine에 적용한 시스템 수준 최적화는 일반 소비자용 하드웨어와 전문가용 하드웨어의 프로덕션 환경에서 각각 어떤 성능을 보일까요?
• 현재 Solana의 모든 노드는 풀 노드입니다. 라이트 클라이언트 구현은 아직 개발 중입니다. Sreeram Kannan(EigenLayer)은 최근 Turbine 위에 DAS-S를 구축하는 구현 방식을 설명했습니다. Turbine용 DAS가 지원될까요? 훨씬 적은 리소스를 요구하는 라이트 클라이언트가 신뢰 최소화를 충족하면서도 높은 데이터 처리량을 유지하도록 DAS 기반 라이트 클라이언트를 구현할 수 있을까요?

결론

축하합니다! 이 글에서는 Turbine과 Solana의 전반적인 트랜잭션 포함 과정에서 Turbine이 작동하는 방식을 살펴봤습니다. Turbine을 다른 데이터 가용성 솔루션과 비교하고 이 분야에 열려 있는 여러 연구 방향도 논의했습니다. Solana의 Turbine 프로토콜은 구조화된 네트워크 토폴로지를 활용하여 검증인 간에 블록 데이터를 효율적으로 배포합니다. 이는 높은 처리량과 짧은 지연 시간을 달성하려는 네트워크의 의지를 잘 보여줍니다.

데이터 가용성을 높이고 블록 전파를 더 효율적으로 만드는 방법을 찾는 과정은 더 넓은 블록체인 커뮤니티의 혁신을 촉진합니다. Solana와 Ethereum의 블록 전파 메커니즘을 비교 분석하면 각 방식의 강점과 절충점을 이해할 수 있습니다. 또한 EigenDA, Celestia, Firedancer 같은 새로운 블록체인 솔루션이 앞으로 이 생태계를 어떻게 형성할지 더 깊이 논의하는 계기가 됩니다.

효율적인 데이터 전파와 데이터 가용성을 위한 솔루션은 아직 완성되지 않았습니다. 하지만 보안과 신뢰 최소화를 훼손하지 않으면서 네트워크 성능을 최적화하려는 Solana의 접근 방식과 확고한 의지는 환영할 만합니다.

검토와 의견을 제공해 주신 @dubbel06 및 @jon_charb에게 감사드립니다.

추가 자료 / 더 읽어보기

• Turbine 블록 전파
• 소거 코딩 이해하기
• Ethereum 블록
• Pyth Perseus 네트워크 업그레이드
• EigenDA 소개: 롤업을 위한 하이퍼스케일 데이터 가용성
• Firedancer