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». Подтверждённый блок — это блок, получивший квалифицированное большинство голосов реестра, а финализированный блок — подтверждённый блок, поверх которого создан ещё как минимум 31 подтверждённый блок. Подробнее различия между статусами подтверждения описаны здесь. Эту часть консенсуса мы рассмотрим в следующей статье.

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

На высоком уровне Turbine принимает шреды и отправляет их заранее определённому набору валидаторов, которые затем ретранслируют их следующему набору валидаторов. На схеме ниже показан непрерывный процесс распространения шредов:

В этом примере Validator 1 назначен лидером слота. В течение своего слота (валидаторы назначаются лидерами на четыре последовательных слота) Validator 1 формирует и предлагает блок. Сначала Validator 1 разбивает блок на части, называемые шредами, в рамках процесса шреддинга. Шреддинг делит данные блока на шреды данных размером с максимальную единицу передачи (MTU) — максимальный объём данных, который можно передать от одной ноды другой без фрагментации на меньшие части, — и создаёт соответствующие восстановительные шреды с помощью кода стирания Рида — Соломона. Эта схема помогает восстанавливать данные и обеспечивает их целостность при передаче, что критически важно для безопасности и надёжности сети.

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

Кодирование стираний

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

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

Если лидер передаёт 33% пакетов блока в виде кодов стирания, сеть может потерять любые 33% пакетов без потери блока. Лидеры могут динамически менять это значение — коэффициент FEC — в зависимости от состояния сети. Для этого учитываются такие параметры, как недавно зафиксированный уровень потери пакетов в сети и глубина дерева.

Для простоты рассмотрим группу шредов с коэффициентом FEC 4:4.

Шреды данных — это части исходного блока, сформированного лидером, а восстановительные шреды — блоки с кодом стирания, созданные по схеме Рида — Соломона.

Блоки в Solana обычно используют FEC 32:32 — 32 из 64 пакетов могут быть потеряны без необходимости повторной передачи. Согласно документации Solana, используются следующие консервативные допущения о сети:

• Уровень потери пакетов — 15%
• 50 тыс. TPS генерируют 6400 шредов в секунду

Коэффициент FEC 32:32 обеспечивает вероятность успешной доставки блока около ~99%. Кроме того, лидеры могут увеличить коэффициент FEC, если хотят повысить вероятность успешной доставки блока.

Сейчас Turbine использует UDP для распространения блоков, что даёт значительное преимущество в задержке. По данным оператора валидатора, передача 6 МБ данных вместе с кодами стирания из us-east-1 в eu-north-1 через UDP занимает 100 мс, а через TCP — 900 мс.

Дерево Turbine

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

Каждая группа шредов отправляется в сетевом пакете специальной корневой ноде, которая определяет, какие валидаторы входят в первый уровень — находятся на расстоянии одного перехода. Затем выполняются следующие действия:

1. Создание списка: корневая нода объединяет всех активных валидаторов в список, который затем сортируется по размеру стейка каждого валидатора в сети. Валидаторы с большим весом стейка получают шреды раньше, что позволяет им быстрее отвечать собственными сообщениями голосования для достижения консенсуса.
2. Перемешивание списка: затем список детерминированно перемешивается. Так для каждого шреда из набора нод валидаторов создаётся «дерево Turbine» с использованием начального значения, полученного из идентификатора лидера слота, слота, индекса шреда и типа шреда. Для каждой группы шредов во время выполнения создаётся новое дерево, чтобы снизить потенциальные риски безопасности, связанные со статичной структурой.
3. Формирование уровней: затем ноды разделяются на уровни, начиная с верхней части списка. Разделение основано на значении DATA_PLANE_FANOUT, которое определяет ширину и глубину дерева Turbine. Это значение влияет на скорость распространения шредов по сети. Текущее значение DATA_PLANE_FANOUT равно 200, поэтому большинство валидаторов находятся всего в 2–3 переходах от лидера (лидер -> корень -> L1 -> L2).

Поскольку дерево Turbine известно всем, каждый валидатор точно знает, куда он должен ретранслировать конкретный шред. При текущем значении DATA_PLANE_FANOUT, равном 200, дерево Turbine обычно состоит из двух или трёх переходов в зависимости от числа активных валидаторов.

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

Сравнение распространения блоков в Solana и Ethereum

Распространение блоков в Solana отличается от Ethereum. Вот основные различия:

• Оптимальные требования Solana к пропускной способности каналов (>1 Гбит/с) значительно выше, чем у Ethereum (geth рекомендует >25 Мбит/с). Это связано с большими размерами блоков и меньшим временем их создания в Solana. Архитектура Solana позволяет эффективно использовать всю доступную пропускную способность для ускорения передачи данных и снижения задержки. Хотя потребление иногда достигает пиков в 1 Гбит/с, этот уровень не поддерживается постоянно. Архитектура Solana специально рассчитана на такие скачки спроса на пропускную способность.
• Solana использует Turbine для распространения данных блоков, а Ethereum — стандартный gossip-протокол. В Ethereum данные блоков распространяются напрямую: каждая нода обменивается данными со всеми другими полными нодами сети. При появлении нового блока клиенты проверяют его, отправляя своим пирам и подтверждая входящие в блок транзакции. Этот механизм подходит Ethereum благодаря меньшему размеру блоков и большему времени их создания по сравнению с Solana. Данные роллапов Ethereum L2, за исключением validium, также распространяются через gossip-протокол, а данные блоков хранятся в поле «calldata» блоков Ethereum L1.
• 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 использует коды стирания, но с явной целью обнаруживать и предотвращать атаки с удержанием данных.
• Для L2 на базе Solana Virtual Machine (SVM), таких как Eclipse, Turbine теряет актуальность, поскольку там нет набора валидаторов, между которыми нужно передавать данные. В случае Eclipse данные блоков публикуются в Celestia для обеспечения доступности данных. Это позволяет внешним наблюдателям выполнять доказательства мошенничества и проверять корректность исполнения и переходов состояния. Eclipse станет одной из первых реализаций SVM за пределами самой сети Solana. Pyth также создал форк SVM для собственной сети оракулов под названием «Pythnet», которая фактически работает как отдельный сайдчейн.
• В Solana полные ноды управляют распространением блоков и одновременно участвуют в других частях интегрированного блокчейн-стека, включая упорядочивание транзакций и консенсус. Какими были бы количественные показатели Turbine, если бы он работал как модульный компонент на специализированном оборудовании?
• Turbine отдаёт приоритет нодам с большим весом стейка, чтобы они первыми получали данные блоков. Приведёт ли это со временем к усилению централизации MEV?
• Как различные подходы к доступности данных, например EigenDA — горизонтально масштабируемый ретранслятор одноадресной передачи — и Celestia — выборочная проверка доступности данных, — будут соотноситься с Turbine в продакшене по чистой пропускной способности и минимизации доверия?
• Firedancer стремится дополнительно ускорить распространение данных и оптимизирован для стабильного соединения с пропускной способностью 10 Гбит/с. Как системные оптимизации Turbine, реализованные командой, покажут себя в продакшене на оборудовании потребительского и профессионального уровня?
• Сейчас все ноды Solana являются полными нодами — реализации лёгких клиентов всё ещё находятся в разработке. Недавно Sreeram Kannan из EigenLayer описал реализацию DAS-S поверх Turbine. Появится ли поддержка версии DAS для Turbine? Можно ли реализовать лёгкие клиенты с DAS так, чтобы сохранить высокую пропускную способность данных, а лёгкие клиенты с гораздо меньшими требованиями к ресурсам обеспечивали минимизацию доверия?

Заключение

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

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

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

Благодарим @dubbel06 и @jon_charb за проверку и комментарии.

Дополнительные материалы

• Распространение блоков через Turbine
• Основы кодирования стираний
• Блоки Ethereum
• Обновление сети Pyth Perseus
• Введение в EigenDA: гипермасштабируемая доступность данных для роллапов
• Firedancer