Solana Turbine: Объяснение распространения блоков

Распространение блоков Solana Turbine описывает, как данные блока разделяются на фрагменты (shreds) и распределяются между валидаторами. Показатели в этой статье являются историческими или целевыми, если явно не указана дата; фактическое время слота, топология, потеря пакетов и поведение реализации могут отличаться.

Введение: почему распространение блоков определяет скорость блокчейна

Отправка полного блока тысячам валидаторов одновременно потребовала бы от каждого валидатора загрузки всего блока из одного источника, создавая узкое место в пропускной способности, которое усугубляется по мере масштабирования сети. Solana (SOL), высокопроизводительный блокчейн уровня 1 (децентрализованная сеть распределенного реестра, которая записывает и проверяет транзакции без центрального органа), решает эту проблему с помощью Turbine — своего выделенного протокола распространения блоков.

Ранние материалы Solana указывают на теоретическую пропускную способность около 65 000 TPS и целевую продолжительность слота около 400 миллисекунд. Это проектные ориентиры, а не гарантированные показатели в реальном времени, и слот не всегда производит блок. Turbine — это механизм распространения данных блока, описанный в рамках исторической архитектуры Solana.

Распространение блоков находится под механизмом консенсуса: валидаторы (серверы, которые хранят копию реестра, проверяют транзакции и голосуют за достоверность блока) не могут голосовать за достоверность блока, пока не получат и не реконструируют его из фрагментов. Эта зависимость означает, что скорость Turbine напрямую способствует производительности консенсуса Solana. Каждое взаимодействие со смарт-контрактом в Solana, от обмена на децентрализованных финансах (DeFi) до создания NFT, зависит от того, насколько быстро блок достигнет валидаторов, чтобы быть подтвержденным в следующем слоте.

Далее будет рассмотрено определение Turbine, его пятишаговый механизм, технические параметры, вклад в производительность, компромиссы в безопасности и сравнение с Ethereum и Avalanche.

В этой статье

• Что такое распространение блоков Solana Turbine?
• Ключевые термины: Краткий справочник по терминологии Turbine
• Как Turbine распространяет блоки: Пошаговое руководство
• Технические параметры Turbine
• Turbine и производительность Solana: Связь распространения блоков с TPS
• Безопасен ли Turbine? Модель безопасности и известные векторы атак
• Solana Turbine против Ethereum и других блокчейнов уровня 1
• Turbine в архитектуре Solana: Все 8 инноваций
• Эволюция Turbine: с 2017 года Whitepaper до наших дней
• Часто задаваемые вопросы о Solana Turbine
• Заключение: Почему Turbine важен для будущего Solana
• Дополнительное чтение и первоисточники

Что такое распространение блоков Solana Turbine?

Определение

Solana Turbine — это протокол распространения блоков Solana, механизм, с помощью которого вновь созданный блок фрагментируется на тысячи пакетов данных фиксированного размера, называемых фрагментами (shreds), и распределяется по сети валидаторов через иерархическую древовидную структуру, называемую деревом соседей (neighborhood tree). Кодирование методом ошибок Рида-Соломона восстанавливает любые потерянные в пути пакеты, гарантируя, что валидаторы смогут реконструировать полный блок даже в неблагоприятных сетевых условиях.

Turbine существует потому, что наивное широковещание не масштабируется. Если лидер блока (валидатор, назначенный для создания блока для данного слота) отправлял бы весь блок непосредственно всем валидаторам одновременно, каждому валидатору пришлось бы загружать полный блок независимо. При более чем 2000 активных валидаторов в сети Solana такой подход потребовал бы O(n) пропускной способности от одного источника, что означает линейный рост затрат на пропускную способность с каждым добавленным валидатором в сеть.

Turbine достигает масштабирования пропускной способности O(log n), заимствуя основной принцип протокола BitTorrent. Протокол распределения файлов BitTorrent peer-to-peer эффективно передает большие файлы, разбивая их на мелкие части и одновременно распространяя эти части по множеству узлов, а не обслуживая их с одного сервера. Turbine применяет ту же идею к распространению блоков блокчейна: вместо того, чтобы лидер блока передавал полный блок каждому валидатору, он фрагментирует блок на части (shreds) и направляет их через слоеное дерево валидаторов, причем каждый слой перенаправляет фрагменты вниз.

Аналогия имеет пределы, которые стоит отметить. BitTorrent работает как плотный peer-to-peer рой, где все участники рассматриваются одинаково. Turbine использует иерархическое дерево с позиционированием, взвешенным по доле (stake-weighted), что означает, что валидаторы с большей долей застейканного SOL располагаются ближе к вершине дерева и получают фрагменты раньше. Это различие важно для понимания как эффективности Turbine, так и его компромиссов в области безопасности.

Turbine был разработан Анатолием Яковенко, соучредителем Solana Labs, и представлен в оригинальной белой книге Solana от Анатолия Яковенко (2017).. Протокол находится в непрерывной эксплуатации с момента запуска мейннета Solana в бета-версии в марте 2020 года.

Ключевые термины: Краткий справочник по терминологии Turbine

Прежде чем мы перейдем к объяснению работы Turbine, вот основные термины, с которыми вы столкнетесь в этой статье.

Как Turbine распространяет блоки: Пошаговое руководство

Turbine распределяет блоки через пятиэтапный процесс: лидер блока разбивает блок, кодирование Рида-Соломона генерирует избыточные пакеты, и полученные фрагменты проходят через взвешенное по стейкингу дерево соседей, пока каждый валидатор не получит достаточно фрагментов для восстановления полного блока. Каждый шаг ниже полностью описывает одну стадию этого процесса.

Шаг 1: Лидер блока создает блок

Каждый блок начинается с лидера блока (также называемого продюсером блока) — узла-валидатора, назначенного для определенного слота и выбранного заранее в соответствии с детерминированным расписанием лидеров Solana. Согласно документации по расписанию лидеров Solana, это расписание основано на часах Proof of History (PoH) — криптографическом механизме отсчета времени Solana. Поскольку расписание лидеров является общедоступным и детерминированным, любой валидатор может проверить, кто будет следующим лидером блока, до начала слота.

Лидер блока собирает транзакции, перенаправленные Gulf Stream (протоколом перенаправления транзакций Solana, который отправляет неподтвержденные транзакции предполагаемому следующему лидеру до финализации текущего блока), и собирает их в полный блок. После сборки лидер блока запускает процесс Turbine.

Шаг 2: Блок разбивается на пакеты данных

Лидер блока разбивает собранный блок на пакеты данных фиксированного размера, называемые фрагментами (shreds), каждый размером примерно 1,5 КБ, согласно технической документации Solana. Эти исходные фрагменты данных блока называются дата-фрагментами (data shreds). Полный блок Solana может породить тысячи дата-фрагментов в зависимости от его размера.

Представьте себе разбиение как разделение большого файла на тысячи маленьких вложений электронной почты и отправку каждого по отдельному пути: полный файл будет собран в месте назначения, даже если несколько вложений прибудут с опозданием. Ключевое преимущество — параллельная передача. Поскольку каждый валидатор в дереве одновременно получает и пересылает разные фрагменты, сеть не ждет одной большой последовательной передачи, прежде чем начать распределение данных.

Разбиение в Turbine — это не шардинг. Шардинг разделяет состояние блокчейна или обработку транзакций между несколькими параллельными подсетями, где разные подмножества валидаторов проверяют разные части состояния. Turbine разбивает блок исключительно для эффективности передачи: вся сеть валидаторов Solana проверяет одно и то же полное состояние блока. Фрагментация — это механизм доставки, а не стратегия разделения.

Кодирование Рида-Соломона генерирует вторую категорию фрагментов, называемых кодирующими фрагментами (coding shreds), которые представляют собой избыточные пакеты, позволяющие любому валидатору восстановить полный блок, даже если часть исходных дата-фрагментов будет потеряна при передаче. Различие важно: дата-фрагменты содержат фактическое содержимое блока; кодирующие фрагменты содержат математически выведенную избыточность, которая может заполнить пробелы.

Полезная аналогия: кодирование Рида-Соломона работает как QR-код. Даже если часть QR-кода скрыта или повреждена, остается достаточно избыточной информации, закодированной в оставшихся частях, чтобы декодировать полное сообщение. Аналогия с QR-кодом имеет одно ограничение: QR-коды — это статические объекты, в то время как кодирование Рида-Соломона в Turbine работает с потоковой группой фрагментов с определенным числовым порогом восстановления.

Согласно реализации Solana, валидаторы могут восстановить полный блок, если они получают примерно две трети всех фрагментов (дата-фрагменты плюс кодирующие). Это означает, что протокол допускает потерю примерно одной трети пакетов до отказа в восстановлении. Кодирование Рида-Соломона — это зрелая технология с десятилетиями производственного использования в CD, DVD, спутниковой связи и других приложениях, что подтверждает утверждение, что механизм отказоустойчивости Turbine основан на проверенной инженерии, а не на экспериментальном дизайне. Технические параметры взяты из Whitepaper Solana) и официальной документации Turbine Solana.

Дерево соседей (также называемое деревом разветвления, fanout tree) — это иерархическая структура маршрутизации, через которую Turbine распределяет фрагменты, организуя валидаторы Solana по уровням, где каждый уровень получает фрагменты от вышестоящего уровня и повторно передает их вниз. Структура ниже показывает, как дерево масштабируется по двум уровням:

Уровень 0 (Лидер блока)
        |
        +-- Уровень 1: ~200 валидаторов (каждый получает уникальное подмножество фрагментов)
                |
                +-- Уровень 2: до ~40 000 валидаторов (200 x 200, каждый валидатор Уровня 1 пересылает примерно 200 другим)

Дерево соседей охватывает полный активный набор валидаторов Solana (приблизительно 2000+ валидаторов по статистике сети Solana Foundation) в пределах двух-трех уровней, учитывая коэффициент разветвления примерно 200 на уровень. С двумя уровнями дерево математически достигает до 40 000 валидаторов (200 x 200), что значительно превышает текущий активный набор.

Представьте эту структуру как почтовую сортировочную сеть: центральный узел отправляет пакеты в региональные сортировочные центры, которые доставляют их в местные почтовые отделения, которые доставляют их по отдельным адресам. Каждый уровень обрабатывает лишь часть общей нагрузки, и ни один узел не несет полной стоимости пропускной способности. Однако, в отличие от нейтральной почтовой системы, дерево соседей Turbine взвешено по стейкингу. Валидаторы с большим объемом стейкинга SOL в соответствии с консенсусным механизмом Solana на основе Proof of Stake (Tower BFT) располагаются ближе к вершине дерева, гарантируя, что они получат фрагменты раньше всех.

Топология дерева также рандомизируется каждый слот с использованием проверяемой случайности, полученной из часов PoH, — источника случайности, который любой валидатор может независимо проверить, не полагаясь на центральную сторону. Поскольку дерево меняется каждый слот, враждебные валидаторы не могут предсказать, кто будет их соседями в следующем раунде. Эта рандомизация является основной защитой Turbine от атак затмения (eclipse attacks), когда злоумышленник пытается окружить целевой валидатор и удержать фрагменты.

Результатом является масштабирование пропускной способности O(log n), что означает, что требования к пропускной способности растут медленно по сравнению с количеством валидаторов. Это свойство делает дизайн Turbine все более ценным по мере роста числа валидаторов Solana.

Как только валидатор получает достаточно фрагментов для достижения порога кодирования Рида-Соломона (примерно две трети всех фрагментов для данного блока), он восстанавливает полный блок и отправляет свой голос в Tower BFT (Tower Byzantine Fault Tolerance) — консенсусный механизм Solana на основе Proof of Stake. Валидаторы не могут голосовать до завершения восстановления, поэтому скорость распространения Turbine напрямую определяет пропускную способность консенсуса.

Процесс распространения разработан с учетом целевого ритма слотов Solana, но фактическое время и охват валидаторов варьируются в зависимости от сетевых условий и реализации. Если распространение завершается в пределах этого окна, консенсус продолжается, и начинается следующий слот. Если нет, слот может быть пропущен, что временно снижает пропускную способность.

Ключевой факт

Когда фрагменты теряются при передаче, кодирование Рида-Соломона Solana позволяет валидаторам восстановить полный блок из полученных кодирующих фрагментов, при условии, что общая потеря пакетов остается ниже примерно одной трети всех переданных фрагментов для этого блока.

Аналогия с QR-кодом применима и здесь: если сохранится достаточное количество узора, полное сообщение будет декодировано. Когда потеря пакетов остается ниже порога восстановления, валидаторы восстанавливают блок из любой комбинации дата-фрагментов и кодирующих фрагментов, которые прибыли.

Когда потери пакетов превышают этот порог, валидатор отправляет запрос на восстановление соседним валидаторам, у которых есть недостающие шреды (shreds). Этот механизм восстановления увеличивает задержку, но не приводит к немедленному пропуску слота, если только восстановление не может быть завершено в течение окна слота.

При сильной перегрузке сети, когда потеря пакетов носит массовый характер во всей сети, а не изолирована на одном пути, сразу несколько валидаторов могут не успеть восстановить свои блоки в течение окна слота. Этот каскад способствует пропускам слотов и, в крайних случаях, приводит к деградации сети, которую Solana наблюдала во время крупных инцидентов с перегрузкой в 2021 и 2022 годах. С тех пор Solana Labs усовершенствовала обработку перегрузок в Turbine в ответ на эти события. Связь между перегрузкой и пропусками слотов рассматривается в разделе безопасности ниже.

Технические параметры Turbine

В следующей таблице обобщены ключевые рабочие параметры Turbine, взятые из официальной документации Solana и Whitepaper Solana. Параметры могут обновляться Solana Labs по мере развития протокола; проверяйте текущие значения в официальной документации Solana по Turbine.

Turbine и производительность Solana: связь распространения блоков с TPS

В Whitepaper Solana и последующих комментариях приводилась теоретическая пропускная способность около 65 000 TPS. Фактическая пропускная способность зависит от даты, рабочей нагрузки, включения голосов, фильтрации и версии программного обеспечения, поэтому диапазон текущих TPS без учета голосов не должен представляться без методики его измерения. Turbine является одним из компонентов результата, а не независимой гарантией TPS.

Причинно-следственная связь работает следующим образом. Turbine распространяет шреды достаточно быстро, чтобы валидаторы по всей сети восстанавливали блоки и голосовали в течение окна слота примерно в 400 мс. Консенсус продолжается. Начинается следующий слот. Solana поддерживает свой ритм слотов. Поскольку каждый слот может содержать тысячи транзакций, поддержание этого ритма и обеспечивает высокий показатель TPS. Прервите этот ритм задержками распространения, и TPS упадет; поддерживайте его, и TPS останется высоким.

Различие между теоретическим и наблюдаемым TPS заслуживает особого внимания. Показатель необработанного TPS Solana (который может достигать более высоких значений) включает транзакции голосования валидаторов, которые являются внутренними сообщениями консенсуса и не представляют собой транзакции, инициированные пользователями. TPS без учета голосов — показатель, более сопоставимый с пропускной способностью других блокчейнов — обычно составляет от 2 000 до 4 000 при реальной нагрузке по состоянию на 2024-2025 годы, согласно документации Solana Labs по производительности. Цифра 65 000 — это теоретический потолок при идеальных условиях; она не является описанием среднего поведения сети.

Дизайн пропускной способности Turbine O(log n) также предотвращает превращение уровня распространения в узкое место по мере роста числа валидаторов. При наивном подходе к рассылке удвоение числа валидаторов удваивает пропускную способность, требуемую от каждого отправляющего узла. Благодаря древовидной структуре Turbine удвоение числа валидаторов добавляет только один дополнительный слой (примерно на 200 валидаторов больше на каждый существующий узел), что означает, что требования к пропускной способности растут медленно, а не линейно.

Ключевой вывод

Turbine не исполняет транзакции; он распространяет данные блоков. Производительность распространения может влиять на голосование и пропускную способность, но Turbine не гарантирует фиксированный показатель TPS, ритм слотов или время завершения (finality).

Безопасен ли Turbine? Модель безопасности и известные векторы атак

Turbine включает в себя три основных механизма безопасности: рандомизированную маршрутизацию, которая перетасовывается в каждом слоте, позиционирование в дереве с учетом стейка и избыточность Рида-Соломона. Каждый механизм устраняет определенную поверхность атаки, хотя каждый также вносит компромисс, который заслуживает честного изучения.

Как рандомизированная маршрутизация защищает от злонамеренных валидаторов

Дерево соседства перетасовывается каждый слот с использованием проверяемой случайности, полученной из часов Proof of History, что означает, что злонамеренные валидаторы не могут предсказать, какие валидаторы будут их соседями в следующем слоте. Это важно, потому что основным вектором атаки на многоуровневое дерево распределения является атака затмения (eclipse attack): злоумышленник размещает валидаторов вокруг целевого валидатора и удерживает шреды, предотвращая восстановление блока этим валидатором и, следовательно, блокируя его голосование.

Поскольку топология дерева меняется каждый слот, атакующий не может надежно поддерживать это окружение. Лидер блока известен заранее (через детерминированное расписание лидеров), но путь распространения — нет. Эта асимметрия является преднамеренным дизайном безопасности: прозрачность в отношении того, кто производит блоки, в сочетании с непрозрачностью того, как эти блоки перемещаются.

У этой защиты есть пределы. Атакующий с достаточным стейком потенциально может появиться в нескольких позициях в ходе последовательных перестановок, сохраняя определенное статистическое присутствие рядом с целевыми валидаторами. Рандомизированная маршрутизация повышает стоимость и сложность атак затмения, не делая их невозможными против хорошо оснащенного противника.

Учет веса стейка и проблемы централизации

Учет веса стейка помещает валидаторов с более высоким стейком ближе к вершине дерева соседства, что означает, что они получают шреды раньше, чем валидаторы с меньшим стейком. Это создает структурное преимущество для крупных стейкинг-операций. Валидаторы, получающие шреды первыми, могут начать восстановление и голосование раньше своих коллег с меньшим стейком, что дает небольшое преимущество по времени в процессе консенсуса.

Честная критика: валидаторы с достаточно большой концентрацией стейка теоретически могут использовать этот ранний доступ для реализации стратегий удержания блоков, задерживая свой голос для получения информационных преимуществ. Правила завершения консенсуса Tower BFT разработаны для ограничения жизнеспособности таких стратегий, а концентрация стейка распределена между более чем 2 000 активных валидаторов (согласно статистике сети Solana Foundation), что сдерживает экстремальную концентрацию. Solana Foundation также запускает программы делегирования стейка, предназначенные для более широкого распределения стейка между более мелкими валидаторами. Тем не менее, структурное преимущество крупных валидаторов реально и его стоит учитывать при любой оценке профиля децентрализации Solana.

Turbine, перегрузка сети и исторические сбои

Большинство крупных сбоев сети Solana в период с 2021 по 2022 год были вызваны перегрузкой конвейера обработки транзакций, а не конкретными сбоями Turbine, хотя экстремальная перегрузка может создавать нагрузку на уровень распространения блоков. Когда объем транзакций переполнял конвейер обработки Solana в эти периоды, объем производимых и разделяемых на шреды блоков также увеличивался, и уровень распространения сталкивался с большим количеством одновременных партий шредов, чем пропускная способность сети могла чисто поглотить.

В результате произошла массовая потеря пакетов, превысившая порог восстановления избыточного кодирования у многих валидаторов одновременно, что привело к каскадам пропуска слотов, а не к единичным сбоям. С тех пор Solana Labs внесла инженерные улучшения в обработку перегрузок, включая изменения в том, как сеть управляет приемом транзакций и как Turbine обрабатывает распространение при высокой нагрузке. Текущий инженерный статус см. в техническом блоге Solana Labs. История сбоев является фактом рабочего опыта Turbine, а не теоретическим риском, и представляет собой соответствующий контекст для любого, кто оценивает техническую отказоустойчивость Solana.

Solana Turbine против Ethereum и других блокчейнов уровня 1

Solana распространяет блоки быстрее, чем Ethereum, главным образом потому, что Turbine использует иерархическое дерево соседей для параллельного распределения фрагментов, в то время как Ethereum использует протокол «слухов», при котором валидаторы транслируют блоки случайному подмножеству узлов, которые, в свою очередь, транслируют их своим узлам, что является принципиально более медленной топологией в масштабе. Таблица ниже сравнивает Solana, Ethereum и Avalanche по параметрам, наиболее важным для распространения блоков.

Важно уточнить одно отличие: сама Solana использует протокол «слухов» для обмена информацией в кластере и метаданными протокола, но Turbine заменяет протокол «слухов» для конкретной задачи распространения блоков. Именно иерархическое дерево Turbine превосходит плоскую топологию «слухов» для распределения блоков в масштабе.

Протокол «слухов» Ethereum (при котором валидаторы транслируют блоки случайному подмножеству узлов, которые, в свою очередь, транслируют их своим узлам, распространяя блок по сети за несколько раундов) проще в реализации и обеспечивает более равномерный выбор узлов, который не отдает предпочтения ни одному валидатору на основе стейка. Такая конструкция отражает приоритет Ethereum в обеспечении широкой децентрализации и разрешительного участия. Компромиссом является скорость распространения: несколько раундов «слухов» в большом наборе валидаторов приводят ко времени блока, измеряемому в секундах, а не в миллисекундах.

Turbine отличается от протокола BitTorrent двумя способами, которые таблица выше не полностью отражает. BitTorrent использует плоскую P2P-сеть (swarm), где все участники равны; Turbine использует иерархическое дерево с позициями узлов, определяемыми стейком. BitTorrent не имеет временных ограничений на сборку файла; Turbine должен доставить его в пределах 400-миллисекундного окна слота, иначе консенсус будет пропущен. Эти расхождения являются ответами на специфические требования блокчейна, с которыми модель BitTorrent не сталкивается.

Распространение DAG Avalanche Snowflake/Snowball использует другой подход: многократный случайный опрос небольших подмножеств валидаторов для достижения вероятностного консенсуса без модели единого лидера блока. Эта конструкция обеспечивает сублинейное масштабирование пропускной способности за счет выборки, а не дерева, и обеспечивает более быструю окончательность, чем Ethereum, при этом принципиально отличаясь от подхода Turbine, основанного на фрагментах. Каждая конструкция делает разные компромиссы между скоростью и децентрализацией, с одной стороны, и отказоустойчивостью и сложностью, с другой. Таблица представляет эти компромиссы; объявить одну архитектуру превосходящей означало бы исказить пространство проектирования.

Turbine в архитектуре Solana: все 8 инноваций

Turbine является одной из восьми архитектурных инноваций, представленных Анатолием Яковенко в техническом документе Solana 2017 года, каждая из которых призвана устранить различные узкие места в производительности инфраструктуры блокчейна. Полный список:

• Proof of History (PoH): Криптографический механизм хронометража Solana, проверяемая функция задержки, которая создает историческую запись порядка событий без необходимости общения валидаторов для согласования времени. PoH не является механизмом консенсуса; это часы. Он определяет структуру слотов, в которой работает Turbine.
• Tower BFT: Консенсусный механизм Solana на основе Proof of Stake, вариант Practical Byzantine Fault Tolerance (PBFT), который использует часы PoH для уменьшения накладных расходов на сообщения при достижении окончательности.
• Turbine: Распространение блоков, тема данной статьи. Turbine распределяет недавно созданные блоки всем валидаторам через фрагменты и дерево соседей.
• Gulf Stream: Протокол пересылки транзакций Solana. Gulf Stream пересылает неподтвержденные транзакции предполагаемому следующему лидеру блока до окончательного формирования текущего блока, сокращая время, необходимое лидеру для составления блока.
• Sealevel: Механизм параллельного выполнения смарт-контрактов Solana, который обрабатывает тысячи непересекающихся смарт-контрактов одновременно, а не последовательно.
• Pipelining: Конвейер обработки транзакций, который назначает различные этапы валидации транзакций выделенному оборудованию, позволяя обрабатывать несколько блоков одновременно на разных стадиях обработки.
• Cloudbreak: Горизонтально масштабируемая база данных аккаунтов Solana, оптимизированная для одновременного чтения и записи на аппаратном обеспечении хранилища валидатора.
• Archivers: Узлы хранения распределенного реестра, которые выгружают исторические данные блокчейна с валидаторов в отдельный слой хранения, снижая требования к оборудованию валидаторов.

Gulf Stream и Turbine работают последовательно на протяжении всего жизненного цикла транзакции. Gulf Stream направляет неподтвержденные транзакции предполагаемому лидеру блока до начала производства блоков; затем Turbine распространяет получившийся блок всем валидаторам после завершения производства. Вместе эти два протокола обрабатывают полный жизненный цикл транзакции от отправки до сетевого распространения.

Эти восемь инноваций были представлены Анатолием Яковенко, соучредителем Solana Labs, в оригинальном техническом документе Solana, опубликованном в 2017 году.

Перспектива валидатора

Позиция валидатора в дереве соседей Turbine влияет на требования к оборудованию. Валидаторы, находящиеся на уровне 1 (ближе к лидеру блока), получают фрагменты первыми и должны пересылать их примерно 200 валидаторам уровня 2, что требует более высокой скорости загрузки по сравнению с валидаторами уровня 2, которые пересылают только в свой назначенный под-соседний кластер. Уровень стейка определяет позицию в дереве: валидаторы с более высоким стейком занимают позиции уровня 1 и должны соответствующим образом подготовить свое оборудование. Операторам следует ознакомиться с текущими рекомендациями Solana Labs по оборудованию, поскольку минимальные спецификации изменились с момента запуска мейннета.

Эволюция Turbine: от 2017 Whitepaper до наших дней

Turbine был впервые описан в оригинальном техническом документе Solana, написанном Анатолием Яковенко из Solana Labs в 2017 году, что делает его одним из основополагающих архитектурных решений протокола, а не функцией, добавленной позже. Спецификация 2017 года заложила основную конструкцию: фрагментацию блоков на основе фрагментов, дерево веера для распространения и избыточное кодирование Рида-Соломона для отказоустойчивости.

Бета-версия мейннета Solana была запущена в марте 2020 года, что впервые вывело Turbine в продакшн. Первоначальное развертывание подтвердило основные свойства дизайна, но также выявило условия реального мира, которые теоретическая спецификация не полностью предвидела, в частности, взаимодействие между перегрузкой транзакций и нагрузкой на распространение.

После событий, связанных с нагрузкой на сеть в 2021 и 2022 годах, Solana Labs внесла инженерные усовершенствования в обработку перегрузок Turbine, включая корректировки в постановке в очередь и передаче пакетов сегментов (shred batches) при высокой сетевой нагрузке. Эти усовершенствования не изменили фундаментальную архитектуру протокола, но улучшили его работу в экстремальных условиях эксплуатации.

Turbine работает в непрерывном продакшне уже более четырех лет в сети, обрабатывающей миллионы транзакций ежедневно. Этот опыт работы дает четкий ответ на вопрос, является ли Turbine проверенным подходом или экспериментальным: это продакшн-протокол, который прошел боевые испытания в масштабе, с задокументированной инженерной историей, прослеживаемой до спецификации 2017 года. Актуальные параметры протокола и последние инженерные изменения см. в инженерном блоге Solana Labs.

Часто задаваемые вопросы о распространении блоков Solana Turbine

Ниже приведены ответы на наиболее распространенные вопросы о дизайне и производительности Solana Turbine.

Что такое Solana Turbine?

Turbine — это протокол, который Solana использует для доставки новых блоков каждому валидатору в сети в пределах окна слота 400 мс. Он работает путем фрагментации блоков на сегменты (shreds) и их маршрутизации через иерархическое дерево соседей, при этом избыточное кодирование Рида-Соломона обрабатывает любые потерянные в пути пакеты. Результатом является быстрое и эффективное по пропускной способности распределение блоков, масштабируемое по мере роста числа валидаторов.

Что такое сегмент (shred) в Solana?

Сегмент (shred) — это основной пакет данных, используемый Turbine для передачи блоков, размером примерно 1,5 КБ. Существует два типа: сегменты данных, которые содержат исходное содержимое блока, и сегменты кодирования, которые являются избыточными пакетами, сгенерированными с помощью избыточного кодирования Рида-Соломона, позволяющего восстановить блок даже при потере некоторых сегментов данных в пути.

Лидер блока разделяет блок на сегменты данных и генерирует сегменты кодирования с помощью кодирования Рида-Соломона. Эти сегменты проходят через дерево соседей: лидер блока отправляет их примерно 200 валидаторам уровня 1, каждый из которых перенаправляет их примерно 200 валидаторам уровня 2, охватывая весь активный набор валидаторов в течение двух-трех уровней и завершаясь в пределах окна слота примерно 400 мс.

Почему Solana быстрее Ethereum в распространении блоков?

Solana использует иерархическое дерево соседей Turbine, которое параллельно распределяет сегменты между множеством валидаторов одновременно, достигая масштабирования пропускной способности O(log n). Ethereum использует протокол распространения (gossip protocol), который требует нескольких последовательных раундов случайного переизлучения между пирами для полного охвата сети, что приводит к времени блока приблизительно 12 секунд по сравнению с временем слота Solana приблизительно 400 мс. Обе конструкции отражают намеренные архитектурные приоритеты.

Turbine включает рандомизированную маршрутизацию (дерево соседей перемешивается каждый слот с использованием проверяемой случайности), избыточность Рида-Соломона (допускает потерю примерно одной трети пакетов) и позиционирование с учетом стейка (stake-weighted positioning). Рандомизированная маршрутизация значительно затрудняет выполнение атак затмения (eclipse attacks). Взвешивание по стейку вносит небольшую компромиссную централизацию: валидаторы с большим стейком получают сегменты раньше, создавая структурное преимущество, которое правила консенсуса Tower BFT частично компенсируют.

Когда потеря пакетов остается ниже примерно одной трети от общего числа сегментов, избыточное кодирование Рида-Соломона позволяет валидаторам восстановить полный блок из уцелевших сегментов данных и сегментов кодирования. При превышении этого порога валидатор отправляет запрос на восстановление соседним валидаторам, у которых есть недостающие сегменты. Если восстановление не может быть завершено в течение окна слота, слот может быть пропущен.

Учет стейка в Turbine действительно создает структурное преимущество для валидаторов с большим стейком, которые получают сегменты раньше и занимают более высокие позиции в дереве соседей. Это реальный компромисс. Смягчающие факторы включают распределение Solana по более чем 2000 активным валидаторам, правила консенсуса Tower BFT, ограничивающие ценность раннего доступа к сегментам, и программы делегирования стейка Solana Foundation, направленные на расширение распределения стейка.

Turbine был разработан Анатолием Яковенко, соучредителем Solana Labs, и впервые описан в Whitepaper Solana, опубликованном в 2017 году. Solana Labs (инженерная организация, отличная от Solana Foundation, которая занимается управлением экосистемой) поддерживает и продолжает развивать протокол.

Gulf Stream и Turbine являются последовательными протоколами в жизненном цикле транзакций Solana. Gulf Stream направляет неподтвержденные транзакции к предполагаемому лидеру блока до начала производства блока, чтобы лидер мог начать сборку блока, не дожидаясь поступления транзакций. Затем Turbine распределяет готовый блок всем валидаторам после завершения производства.

Теоретический максимум Solana составляет примерно 65 000 TPS, согласно Whitepaper Solana, при идеальных условиях. В реальных условиях наблюдаемое количество TPS (кроме транзакций голосования) обычно колеблется от 2 000 до 4 000 транзакций в секунду по состоянию на 2024-2025 годы, согласно документации Solana Labs по производительности. Цифра сырых TPS, иногда упоминаемая с более высокими значениями, включает транзакции голосования валидаторов, которые являются внутренними сообщениями консенсуса, а не пользовательскими транзакциями.

Связанные руководства по Solana

• RPC-узлы Solana
• Слоты и время блока Solana (400 мс) — подробное описание

Читатели могут ознакомиться с актуальной рыночной информацией по SOL) или спот-рынком SOL/USDT.). Эти ссылки предоставляют рыночную информацию и доступ; они не подтверждают технические заявления и не подразумевают, что SOL подходит каждому читателю.

Turbine — это инженерный механизм, который делает возможным достижение времени слота Solana примерно в 400 мс: без быстрого и эффективного по пропускной способности распространения блоков валидаторы Solana не смогли бы получать блоки и голосовать по ним достаточно быстро, чтобы поддерживать частоту слотов, требуемую для высокой пропускной способности. Дизайн решает реальное ограничение масштабируемости, проблему пропускной способности O(n) наивного широковещания, с помощью комбинации фрагментации на основе сегментов, иерархического распределения по дереву и отказоустойчивости Рида-Соломона.

Дизайн имеет свои компромиссы, которые стоит понимать. Позиционирование в дереве с учетом стейка дает структурные преимущества крупным валидаторам. Рандомизированная маршрутизация смягчает атаки затмения, но не устраняет их против хорошо оснащенных противников. Слой распространения может быть перегружен при экстремальной сетевой загрузке, как показали отчеты об отказах Solana в 2021-2022 годах. Ни одно из этих обстоятельств не является дисквалифицирующим; все это архитектурные компромиссы, сделанные в обмен на скорость и эффективность пропускной способности, которые предоставляет протокол.

Turbine работает в основной сети с 2020 года и постоянно совершенствуется с учетом реальных условий. По мере роста числа валидаторов Solana свойство масштабирования O(log n) становится все более важным: каждое удвоение набора валидаторов добавляет лишь один уровень дерева, а не удваивает затраты на пропускную способность. Именно это свойство делает конструкцию долговечной при масштабировании. Скорость и надежность распространения блоков через Turbine — это также то, что делает Solana жизнеспособным уровнем инфраструктуры для высокочастотных приложений децентрализованных (DeFi) финансов, где задержка распространения напрямую влияет на результаты подтверждения транзакций.

Ключевой вывод

Turbine — это инженерный фундамент, который делает заявления Solana о скорости убедительными. Понимание того, как он фрагментирует блоки на шреды (shreds), маршрутизирует их через дерево соседства, взвешенное по доле в стейкинге, и восстанавливает потерянные пакеты с помощью кодирования стирания Рида-Соломона, является самым ясным способом оценить, основываются ли эти заявления о производительности на надежной архитектуре. У этой конструкции есть как реальные сильные стороны, так и реальные компромиссы; и то, и другое заслуживает внимания при любой честной технической оценке инфраструктуры Solana.

Дополнительная литература и первоисточники

Следующие первоисточники обеспечивают техническую базу для утверждений, сделанных в этой статье.

• Распространение блоков через Turbine (Solana Docs): официальная техническая документация по Turbine, поддерживаемая инженерами Solana Labs.
• Оригинальный Solana Whitepaper Анатолия Яковенко (2017): основополагающая спецификация для Turbine и всех восьми архитектурных инноваций Solana.
• Инженерный блог Solana Labs: последние инженерные обновления, улучшения протокола и отчеты об инцидентах от Solana Labs.
• Solana GitHub: исходный код turbine:): исходный код для разработчиков, желающих изучить реализацию Turbine напрямую.
• Статистика сети Solana Foundation: текущее количество валидаторов, данные о распределении стейкинга и метрики состояния сети.

Данная статья предназначена исключительно для образовательных целей и не является финансовой или инвестиционной рекомендацией. Инвестиции в криптовалюты сопряжены со значительным риском. Всегда проводите собственное исследование перед принятием любых инвестиционных решений.