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

터빈(Turbine)은 솔라나의 블록 배포 방식입니다. 슬롯 리더가 만든 블록을 모든 검증자에게 하나하나 직접 보내지 않고, 작은 조각(shred)으로 쪼개 지분 가중 전파 트리를 따라 여러 갈래로 퍼뜨립니다. 데이터 조각과 리드-솔로몬(Reed–Solomon) 기반 복구 조각을 함께 보내므로 일부 조각이 빠져도 블록을 다시 짜 맞출 수 있습니다. 다만 복구에 필요한 만큼 조각을 받지 못하면 별도의 블록 수리(Block Repair)를 거쳐야 하고, 전파가 늦으면 최종성도 늦어질 수 있습니다. 확인한 날 기준으로 공식 Alpenglow 페이지는 앞으로 로터(Rotor)가 터빈을 대신할 것이라고 밝히지만 일정은 정해지지 않았으니, 이미 끝난 교체처럼 쓰면 안 됩니다.

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

검증자가 N명이고 블록 크기가 B라면, 리더가 검증자마다 블록 전체를 직접 보낼 때 단순 송신량은 대략 N×B입니다. 검증자가 늘수록 리더의 네트워크 카드가 숨이 막힙니다. 터빈의 초기 공식 설명은 이 문제를 풀려고, 비트토렌트처럼 중간 노드가 데이터 일부를 다시 넘겨주는 나무(tree) 구조를 내놓았습니다.

가령 100MB 블록을 1,000명에게 직접 보내면 리더 송신량은 100GB입니다. 한 노드가 20개씩 이어 받는 계층 전달을 쓰면 리더가 처음부터 전체 복사본 1,000개를 보낼 필요가 없습니다. 원리를 보여 주려는 숫자일 뿐, 실제 블록 크기나 갈래 수, 패킷 속도는 아닙니다. 실제 값은 클라이언트 버전과 네트워크 설정에서 확인해야 합니다.

터빈이 규모를 키울 수 있는 것은 리더 혼자 블록을 복제하지 않고 검증자들이 전파 일을 나눠 맡기 때문입니다.

JOBCOIN 해설

그림으로 보기프로토콜 실행의 기본 구조

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

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

2. 02
   조각은 검증자끼리 주고받는 블록의 가장 작은 단위입니다

   솔라나 공식 용어집은 조각(shred)을 블록의 일부이자 검증자 사이에서 오가는 가장 작은 단위로 정의합니다.

3. 03
   조각마다 전파 경로를 흩어 놓는 이유

   초기 터빈 설명은 지분 가중으로 검증자들을 나무의 이웃 묶음(neighborhood)에 배치하고, 패킷마다 출발점을 무작위로 바꿔 경로를 달리하는 구상을 내놓습니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

조각은 검증자끼리 주고받는 블록의 가장 작은 단위입니다

솔라나 공식 용어집은 조각(shred)을 블록의 일부이자 검증자 사이에서 오가는 가장 작은 단위로 정의합니다. 2023년 공식 장애 보고서는 리더가 제안 블록을 최대 전송 단위(MTU) 크기의 데이터 조각으로 나누고, 묶음마다 리드-솔로몬 방식의 복구 조각을 만든다고 설명합니다. 조각이 작으면 네트워크 패킷에 맞춰 흘려보내기 쉽고, 서로 다른 길로 빠르게 퍼질 수 있습니다.

데이터 조각에는 원래 블록 데이터가 나뉘어 담기고, 복구 조각은 빠진 조각을 되살릴 수 있는 여분 정보입니다. 그렇다고 복구 조각만 있으면 어떤 누락이든 되살릴 수 있는 것은 아닙니다. 소거 부호 묶음(erasure batch)이 요구하는 기준 개수 이상의 독립 조각을 모아야 하고, 손실이 복구 능력을 넘으면 다른 피어에게 빠진 자료를 달라고 해야 합니다.

조각마다 전파 경로를 흩어 놓는 이유

초기 터빈 설명은 지분 가중으로 검증자들을 나무의 이웃 묶음(neighborhood)에 배치하고, 패킷마다 출발점을 무작위로 바꿔 경로를 달리하는 구상을 내놓습니다. 위쪽 계층의 악성 노드 하나가 자기 아래 데이터를 몽땅 막아 버리는 위험을 줄이려고, 모든 조각이 똑같은 길을 따르지 않게 합니다. 중간 검증자는 받은 조각을 다음 계층의 여러 피어에게 넘깁니다.

지분 가중 배치는 ‘지분이 크면 내용이 옳다’는 판단이 아닙니다. 전파를 안정시키고 순서를 정하려는 연결 구조입니다. 받는 노드는 조각의 서명과 소거 부호 묶음 관계를 확인하고 블록을 다시 짜 맞춘 뒤 거래를 실행합니다. 전파 경로와 합의 투표 가중치를 같은 보안 장치로 뭉뚱그리면 안 됩니다.

• 슬롯 리더가 어느 블록을 조각냈는지 확인합니다
• 데이터 조각과 복구 조각의 소거 부호 묶음 범위를 맞춥니다
• 받은 조각 수가 재구성 기준을 채우는지 확인합니다
• 재구성에 실패하면 터빈 손실과 블록 수리 응답을 나눠 봅니다
• 블록을 받은 시각과 투표·루트 진행 시각을 따로 적습니다

복구할 수 있다는 것과 바로 받았다는 것은 다른 지표입니다

소거 부호 덕분에 일부 패킷이 사라져도 결국 블록을 다시 짜 맞출 수 있습니다. 하지만 필요한 복구 조각이 늦게 오거나 수리 요청을 거쳐야 한다면, 블록은 복구는 되면서도 합의 시간에는 늦을 수 있습니다. 노드 운영 품질을 볼 때 최종 복구 성공률만 재면 지연을 놓칩니다.

예를 들어 같은 블록을 A 노드는 300ms에, B 노드는 수리를 거쳐 2초에 재구성했다고 해 봅니다. 두 노드 모두 데이터 무결성 검사는 통과하지만, B는 제때 투표할 기회를 놓칠 수 있습니다. 그래서 첫 조각 도착, 재구성 완료, 수리 요청, 투표 시각을 따로 봐야 전파 지연이 합의 지연으로 어떻게 이어지는지 알 수 있습니다.

2023년 장애는 터빈과 외부 전달 서비스의 경계를 드러냈습니다

솔라나 재단의 2023년 2월 사고 보고서에 따르면, 유난히 큰 블록에서 나온 복구 조각이 중복 제거 로직에 부담을 줬습니다. 여기에 별도의 블록 전달 서비스가 이 조각들을 다시 네트워크로 퍼뜨리면서 터빈이 포화됐습니다. 많은 블록 데이터가 느린 예비 경로인 블록 수리로 넘어갔고, 최종 확정이 크게 늦어졌습니다.

보고서는 이 사건을 ‘터빈이 큰 블록을 감당하지 못했다’고 단순하게 요약하지 않습니다. 원인은 터빈 앞단의 전달 서비스와 중복 제거 로직이 맞물린 데 있었습니다. 사고를 분석할 때는 프로토콜, 검증자 클라이언트, 제3자 전달 서비스의 경계를 나눠야 제대로 된 재발 방지책을 찾을 수 있습니다.

로터는 제안·전환 단계로 표시해야 합니다

확인한 날 기준으로 솔라나 공식 Alpenglow 페이지는 보터(Votor) 다음 단계인 로터가 터빈의 나무 구조 전파를 단일 중계 계층으로 바꿀 계획이라고 설명합니다. 같은 페이지에서 로터 일정은 ‘Unscheduled’로 표시됩니다. 방향과 설계를 알려 주는 근거일 뿐, 메인넷 교체가 끝났다는 증거는 아닙니다.

그러니 지금 자료를 쓸 때는 관측한 클라이언트 버전과 기능 활성화 상태를 확인해야 합니다. 터빈 운영 지표에 로터의 목표 지연 시간을 들이대거나, 로터 제안만 보고 터빈 장애 가능성이 사라졌다고 결론지으면 안 됩니다. 과거 설계, 현재 활성 상태, 앞으로의 전환 계획을 세 줄로 나눠 적는 것이 정확합니다.

자주 묻는 질문