솔라나 Turbine 블록 전파: 데이터가 작은 조각으로 퍼지는 과정

Turbine은 슬롯 리더가 만든 블록을 네트워크의 모든 검증자에게 직접 반복 전송하지 않고, 작은 shred로 나눠 지분 가중 전파 트리를 따라 fan-out하는 Solana의 블록 배포 방식입니다. data shred와 Reed–Solomon 기반 recovery shred를 함께 보내 일부 조각이 빠져도 블록을 재구성할 수 있게 합니다. 그러나 복구에 충분한 조각을 못 받으면 별도 Block Repair가 필요하고, 전파 지연은 최종성 지연으로 이어질 수 있습니다. 확인일 현재 공식 Alpenglow 페이지는 향후 Rotor가 Turbine을 대체한다고 밝히지만 일정은 미정이므로 Turbine과 Rotor를 현재 완료된 교체로 쓰면 안 됩니다.

리더가 전체 블록을 모든 검증자에게 보내면 병목이 생긴다

검증자가 N명이고 블록 크기가 B라면 리더가 각 검증자에게 전체 블록을 직접 보낼 때 단순 송신량은 대략 N×B입니다. 검증자가 늘수록 리더의 네트워크 카드가 병목이 됩니다. Turbine의 초기 공식 설명은 이 문제를 해결하려고 BitTorrent처럼 중간 노드가 일부 데이터를 다시 전달하는 tree 구조를 제시했습니다.

가정으로 블록 100MB를 1,000명에게 직접 보내면 리더 송신량은 100GB입니다. 20개 fan-out으로 계층 전달하면 리더가 처음부터 1,000개의 전체 복사본을 보내지 않아도 됩니다. 이 수치는 원리 설명용이며 실제 블록 크기, fan-out, packet rate가 아닙니다. 실제 파라미터는 클라이언트 버전과 네트워크 설정을 확인해야 합니다.

Turbine의 확장성은 리더 혼자 블록을 복제하는 대신 검증자들이 전파 작업을 나눠 맡는 데서 나온다.

JOBCOIN 해설

VISUAL GUIDE프로토콜 실행의 기본 구조

1. 01
   리더가 전체 블록을 모든 검증자에게 보내면 병목이 생긴다

   검증자가 N명이고 블록 크기가 B라면 리더가 각 검증자에게 전체 블록을 직접 보낼 때 단순 송신량은 대략 N×B입니다.

2. 02
   shred는 검증자 사이에 전송되는 블록의 최소 조각이다

   Solana 공식 용어집은 shred를 블록의 일부이자 검증자 사이에서 보내는 최소 단위로 정의합니다.

3. 03
   각 shred의 전파 경로가 분산되는 이유

   초기 Turbine 설명은 지분 가중으로 검증자들을 tree의 neighborhood에 배치하고 packet별 무작위 원천으로 경로를 바꾸는 구상을 제시합니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

shred는 검증자 사이에 전송되는 블록의 최소 조각이다

Solana 공식 용어집은 shred를 블록의 일부이자 검증자 사이에서 보내는 최소 단위로 정의합니다. 2023년 공식 장애 보고서는 리더가 제안 블록을 MTU 크기의 data shred로 나누고, 각 묶음에 Reed–Solomon 방식의 recovery shred를 만든다고 설명합니다. 작은 조각은 네트워크 패킷에 맞춰 스트리밍하기 쉽고 서로 다른 경로로 빠르게 퍼질 수 있습니다.

data shred에는 원래 블록 데이터가 나뉘어 들어가고 recovery shred는 누락 조각을 복원할 수 있는 중복 정보입니다. recovery shred만으로 임의의 모든 누락을 복구할 수 있는 것은 아닙니다. erasure batch가 요구하는 임계 수 이상의 독립 조각을 확보해야 하며, 손실이 복구 능력을 넘으면 다른 피어에게 누락 자료를 요청해야 합니다.

각 shred의 전파 경로가 분산되는 이유

초기 Turbine 설명은 지분 가중으로 검증자들을 tree의 neighborhood에 배치하고 packet별 무작위 원천으로 경로를 바꾸는 구상을 제시합니다. 높은 계층의 한 악성 노드가 자기 아래 모든 데이터를 막는 위험을 줄이기 위해 모든 shred가 완전히 같은 경로를 따르지 않게 합니다. 중간 검증자는 받은 조각을 다음 계층의 여러 피어에게 전달합니다.

지분 가중 배치는 ‘지분이 크면 내용이 옳다’는 판단이 아닙니다. 전파 안정성과 우선순위를 위한 topology 구성입니다. 수신 노드는 shred의 서명과 erasure batch 관계를 확인하고 블록을 재구성한 뒤 거래를 실행합니다. 전파 경로와 합의 투표 가중치를 같은 보안 장치로 합치면 안 됩니다.

• slot 리더가 어느 블록을 shredding했는지 식별한다
• data shred와 recovery shred의 erasure batch 범위를 맞춘다
• 수신 조각 수가 재구성 임계치를 충족하는지 확인한다
• 재구성 실패 시 Turbine 손실과 Block Repair 응답을 구분한다
• 블록 수신 시각과 투표·root 진행 시각을 따로 기록한다

복구 가능성과 즉시 수신은 다른 품질 지표다

erasure coding 덕분에 일부 packet이 사라져도 최종적으로 블록을 재구성할 수 있습니다. 하지만 필요한 recovery shred가 늦게 도착하거나 repair 요청을 거치면 블록은 복구 가능하면서도 합의 시간에는 늦을 수 있습니다. 노드의 운영 품질을 볼 때 최종 복구 성공률만 측정하면 지연을 놓칩니다.

예를 들어 같은 블록을 A 노드는 300ms에, B 노드는 repair 후 2초에 재구성했다고 가정합니다. 두 노드 모두 데이터 무결성 검사에는 성공하지만 B는 제때 투표할 기회를 놓칠 수 있습니다. 따라서 first shred, reconstruct complete, repair request, vote 시각을 분리해야 전파와 합의 지연의 연결을 알 수 있습니다.

2023년 장애는 Turbine과 외부 forwarding의 경계를 보여 줬다

Solana Foundation의 2023년 2월 사고 보고서는 비정상적으로 큰 블록에서 나온 recovery shred가 중복 제거 로직에 부담을 주고, 별도 block-forwarding 서비스가 이를 다시 네트워크로 전파하면서 Turbine을 포화시켰다고 기록합니다. 다수 블록 데이터가 느린 fallback Block Repair로 넘어가 finalization이 크게 지연됐습니다.

보고서는 이 사건을 단순히 ‘Turbine이 큰 블록을 못 처리했다’고 요약하지 않습니다. Turbine 앞단의 forwarding 서비스와 중복 제거 상호작용이 원인이었습니다. 사고 분석에서는 프로토콜, validator client, 제3자 forwarding 서비스의 경계를 구분해야 올바른 재발 방지 항목을 찾을 수 있습니다.

Rotor는 제안·전환 단계로 표시해야 한다

확인일 현재 Solana 공식 Alpenglow 페이지는 Votor 다음 단계의 Rotor가 Turbine의 tree 기반 전파를 단일 relay layer로 대체할 계획이라고 설명합니다. 같은 페이지에서 Rotor 일정은 ‘Unscheduled’로 표시됩니다. 이는 방향과 설계를 알리는 근거이지 mainnet 교체 완료의 증거가 아닙니다.

따라서 현재 자료를 쓸 때는 관측한 클라이언트 버전과 feature activation을 확인해야 합니다. Turbine 운영 지표에 Rotor의 목표 지연 시간을 적용하거나, Rotor 제안만 보고 Turbine 장애 가능성이 사라졌다고 결론 내리면 안 됩니다. 과거 설계, 현재 활성 상태, 향후 전환 계획을 세 줄로 분리해 기록하는 것이 정확합니다.

자주 묻는 질문