Механизм консенсуса Solana: PoH, Tower BFT, PoS

Примечание об актуальности: Производительность сети, количество валидаторов, комиссии, особенности протокола, поддержка кошельков и сторонние интеграции меняются со временем. Относитесь к устаревшим данным как к историческим снимкам и проверяйте актуальную первичную документацию.

Механизм консенсуса Solana сочетает Proof of History для упорядочивания по времени, Tower BFT для голосования с учетом стейка и Proof of Stake для участия валидаторов и стимулов.

TL;DR: Solana использует Proof of History для упорядочивания по времени, Tower BFT для голосования с учетом стейка и выбора форка, а Proof of Stake для участия валидаторов и стимулов. Пропускная способность и подтверждение зависят от полного времени выполнения, сетевых условий, набора транзакций и измеряемого уровня приверженности.

Содержание

1. Что такое механизм консенсуса Solana?
2. Проблема, которую призвана решить Solana
3. Proof of History: криптографические часы Solana объяснены
4. Tower BFT: как валидаторы достигают согласия
5. Как Proof of History, Tower BFT и Proof of Stake работают вместе
6. Как транзакция Solana достигает финализации: пошагово
7. Производительность Solana: скорость, пропускная способность и финализация
8. Консенсус Solana против Ethereum, Avalanche, Cardano и Polkadot
9. Сильные и слабые стороны модели консенсуса Solana
10. Как принять участие: стейкинг и валидация в Solana
11. Часто задаваемые вопросы
12. Ключевые выводы

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

Solana запустила свою мейннет-бета-версию в марте 2020 года и быстро привлекла внимание благодаря обработке тысяч транзакций в секунду за доли цента за транзакцию. Протоколы DeFi и маркетплейсы NFT, построенные на Solana, зависят от этой пропускной способности; именно это делает практичными ончейн-операции в реальном времени, массовые минт-операции NFT и платежи с микрокомиссией. Но скорость без надежности — это не фундамент, на котором стоит строить, и несколько громких сбоев в работе сети между 2021 и 2023 годами породили законные вопросы о том, является ли архитектура протокола надежной.

В этой статье честно объясняется механизм: как он работает, почему он быстрый, почему сеть останавливалась и что означают компромиссы для тех, кто оценивает Solana как инвестора, разработчика или участника.

Что такое механизм консенсуса Solana?

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

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

Вот как система работает на высоком уровне:

1. Proof of History создает непрерывную, проверяемую запись времени, которой пользуются все валидаторы в сети.
2. Валидаторам (участникам сети, которые создают и проверяют блоки) назначаются определенные временные интервалы в зависимости от количества застейканных ими SOL.
3. Назначенный ведущий валидатор для каждого интервала использует временную шкалу PoH для отметки времени и сборки транзакций в блок.
4. Все остальные валидаторы проверяют блок и отдают голоса Tower BFT, взвешенные по стейку; когда более двух третей застейканного SOL подтверждает блок, он считается финализированным.

Распространенное заблуждение: Solana — это не блокчейн Proof of Work (здесь нет решения вычислительных головоломок или энергоемких вычислений). Называть Solana просто «блокчейном Proof of Stake» технически верно, но неполно. Это упускает Proof of History и Tower BFT, которые так же важны для достижения консенсуса в Solana. Полное и точное описание: Solana использует гибридную систему, сочетающую PoH, Tower BFT и PoS.

Проблема, которую призвана решить Solana

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

Триалемма масштабируемости блокчейна, фреймворк, популяризированный соучредителем Ethereum Виталиком Бутериным, описывает, почему это сложно. Триалемма гласит, что блокчейн может реально достичь максимум двух из трех свойств одновременно: децентрализация, безопасность и масштабируемость. Биткойн, оригинальный блокчейн, отдает приоритет децентрализации и безопасности. Результатом является сеть, которая достигает примерно 7 транзакций в секунду с 10-минутными интервалами между блоками, свойства, которые безопасны и широко распределены, но делают Биткойн непрактичным для высокочастотных приложений. Ранний Ethereum сталкивался с аналогичными ограничениями до своего собственного пути обновления.

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

Анатолий Яковенко, бывший инженер Qualcomm, посвятивший свою карьеру работе над распределенными системами и синхронизацией часов на аппаратном уровне, выявил эту проблему коммуникации временных меток как фундаментальное узкое место. Его ключевая идея: если бы валидаторы могли использовать единые, криптографически проверяемые часы, которым они все доверяют без необходимости обмениваться временными метками друг с другом, процесс консенсуса мог бы стать значительно быстрее. В ноябре 2017 года Яковенко опубликовал Solana: новая архитектура для высокопроизводительного блокчейна,), описав то, что впоследствии стало Proof of History. Он стал соучредителем Solana Labs (коммерческой компании-разработчика протокола Solana) вместе с Грегом Фицджеральдом и Реем Гокалом, и в марте 2020 года они втроем запустили мейннет-бета-версию.

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

Proof of History: криптографические часы Solana объяснены

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

PoH — это не механизм консенсуса. Это часовой механизм, который делает механизм консенсуса Solana возможным.

Какую проблему решает Proof of History?

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

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

Как работает Proof of History: Хеш-цепочка

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

Технический механизм работает следующим образом:

Технический механизм работает следующим образом:

1. Генератор PoH Solana начинает с начального хеш-значения.
2. Он выполняет криптографическую хеш-функцию SHA-256 над этим значением, получая новый 256-битный выход.
3. Он немедленно подает этот выход обратно в качестве входа для следующей операции SHA-256.
4. Каждый хеш в цепочке записывается вместе со счетчиком, создавая проверяемую последовательность, которая доказывает, что прошло реальное вычислительное время.
5. Транзакции вставляются в хеш-цепочку в определенных позициях, фактически проставляя им постоянную временную метку на основе проверяемой последовательности до того, как какому-либо валидатору потребуется связаться с кем-либо другим.

В результате получается публичная запись о точном времени поступления каждой транзакции в очередь. Любой может проверить целостность цепочки. Никто не может подделать время, которое потребовалось для ее создания.

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

Техническое погружение: SHA-256 — это односторонняя криптографическая хеш-функция: ее легко вычислить в одном направлении, но вычислительно невозможно обратить. Последовательное связывание выходных данных SHA-256 придает PoH свойство "проверяемой задержки": создание цепочки требует реального времени (последовательные вычисления нельзя распараллелить), но может быть проверено параллельно очень быстро любым наблюдателем, проверяющим каждый хеш по сравнению с предыдущим. Это функционально похоже на Verifiable Delay Function (VDF) — криптографическую конструкцию, которая требует минимального объема последовательных вычислений для создания, но может быть быстро проверена. Роль SHA-256 в PoH полностью отличается от его роли в Bitcoin, где он используется как соревновательная головоломка (поиск хеша ниже целевого значения). В PoH SHA-256 используется для последовательного хронометража, а не для соревновательных вычислений.

Proof of History не является механизмом консенсуса Solana. Механизм консенсуса — это процесс, с помощью которого валидаторы достигают соглашения о том, какие транзакции действительны и в каком порядке. PoH этого не делает. PoH записывает порядок и время событий; Tower BFT — это алгоритм, который достигает консенсуса относительно того, действительны ли эти события.

PoH также не является Proof of Stake. Proof of Stake определяет, кто экономически имеет право участвовать в консенсусе и какой вес имеет его голос. PoH не определяет право участия или вес голоса; он предоставляет общий часовой механизм, который ускоряет процесс голосования.

Заблуждение о том, что "Solana использует Proof of History" в качестве своего полного механизма консенсуса, является одной из самых распространенных ошибок в публичных материалах о Solana. Это неточно, и это важно: без Tower BFT и Proof of Stake, PoH сам по себе не обеспечивал бы никаких гарантий безопасности.

Tower BFT: Как валидаторы достигают согласия

Tower BFT — это алгоритм консенсуса Solana, адаптация Practical Byzantine Fault Tolerance (PBFT), разработанная для использования PoH в качестве общего часового механизма. Он позволяет валидаторам достигать согласия о состоянии реестра с использованием голосов, взвешенных по доле. Поскольку валидаторы совместно используют Proof of History как доверенный часовой механизм, Tower BFT требует гораздо меньшего количества раундов связи, чем стандартные реализации BFT, и финализирует блоки примерно за 400–800 миллисекунд при нормальных сетевых условиях.

Что такое отказоустойчивость к византийским сбоям?

Название происходит от "Задачи византийских генералов" — классического мысленного эксперимента в распределенных системах, формализованного Лесли Лэмпортом в 1982 году. Задача гласит: как группе генералов скоординировать атаку, если некоторые из них могут быть предателями, рассылающими ложную информацию? Система является отказоустойчивой к византийским сбоям, если она может достичь корректного консенсуса, даже если некоторые участники действуют злонамеренно, отправляют ложные сообщения или выходят из строя произвольным образом.

Традиционные BFT-системы, включая базовый алгоритм PBFT, опубликованный Мигелем Кастро и Барбарой Лисков в 1999 году, требуют, чтобы менее одной трети всех участников были неисправны или злонамеренны. Для сети со 100 валидаторами до 33 могут быть скомпрометированы, а остальные 67 все равно смогут достичь корректного консенсуса. Это свойство математически доказуемо, что делает BFT-системы привлекательными для критически важных приложений безопасности.

Solana Tower BFT унаследовал это свойство. Злоумышленнику потребуется контролировать более одной трети всего стейка SOL, чтобы остановить сеть, и более двух третей, чтобы переопределить консенсус. В отличие от сетей Proof of Work, где злоумышленнику требуется 51% вычислительной мощности, Solana Tower BFT требует контроля более 33% всего стейка SOL для остановки сети. Этот порог обычно считается более трудным для достижения на практике, поскольку он требует накопления капитала, а не просто вычислительных ресурсов.

Техническое погружение: Стандартный PBFT требует сложности сообщений O(n²), где n — количество валидаторов. Каждый валидатор должен связаться с каждым другим валидатором для подтверждения согласия. Для сетей с тысячами валидаторов это создает непомерные накладные расходы на связь. Tower BFT снижает эти накладные расходы, используя PoH в качестве общего часового механизма: поскольку все валидаторы соглашаются о времени на основе последовательности PoH без обмена сообщениями об этом, Tower BFT требует от валидаторов только голосования по валидности блока, а не по порядку временных меток. Механизм блокировки добавляет еще одну эффективность: когда валидатор голосует за блок, он фиксируется на этом голосе на экспоненциально увеличивающийся период ожидания. Смена голоса требует ожидания окончания периода блокировки, создавая экономическое сдерживание для реорганизаций и уменьшая количество раундов голосования, необходимых для достижения финализации.

Без общего часового механизма валидаторы в стандартной BFT-системе должны отправлять друг другу сообщения с временными метками для установления порядка событий, добавляя коммуникационные накладные расходы на каждом шаге. С PoH порядок уже установлен и может быть проверен каждым валидатором независимо.

Валидаторы подают взвешенные по стейку голоса за блоки, а Tower BFT использует блокировки и супербольшинство голосов при выборе форка. Оптимистичное подтверждение, корневое подтверждение и экономическая финализация на уровне приложений — это различные пороги. Их время варьируется в зависимости от условий кластера и должно проверяться в актуальной документации, а не сводиться к фиксированной миллисекундной цифре.

Расписание лидера: Как Solana выбирает валидаторов

В начале каждой эпохи Solana вычисляет детерминированное назначение того, какой валидатор будет выступать в качестве лидера для каждого предстоящего слота. Назначение пропорционально весу стейка каждого валидатора: валидатор, контролирующий 5% всех застейканных SOL, будет назначен лидером примерно для 5% всех слотов в этой эпохе.

Слот — это базовая единица времени в Solana, составляющая примерно 400 миллисекунд на слот (проверьте текущую цифру в docs.solana.com на момент написания). Эпоха охватывает примерно 432 000 слотов, что составляет около двух-трех дней (проверьте в docs.solana.com на момент написания).

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

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

Как работают вместе Proof of History, Tower BFT и Proof of Stake

Proof of History, Tower BFT и Proof of Stake — это не три отдельных механизма консенсуса, работающих параллельно. Это три взаимозависимых уровня единой интегрированной системы, каждый из которых решает свою часть проблемы распределенного консенсуса.

Proof of Stake является экономическим фундаментом. Валидаторы должны внести в стейкинг (заблокировать) SOL для участия в консенсусе. Этот стейк создает финансовую заинтересованность: валидаторы, которые голосуют некорректно или пытаются манипулировать реестром, рискуют потерять свои застейканные SOL через слэшинг (проверьте текущие детали реализации слэшинга в docs.solana.com, поскольку они меняются с обновлениями протокола). Делегаторы, то есть любой держатель SOL, который не хочет запускать валидатор, может внести свои SOL в стейкинг к валидатору и заработать долю наград этого валидатора, пропорциональную своей делегации.

После того как Proof of Stake определяет, кто участвует и с каким весом, Proof of History предоставляет временную шкалу, которую используют участники. Часы PoH работают непрерывно, производя проверяемую последовательность хэшей, которая присваивает временные метки каждой транзакции. Для установления порядка не требуется межсетевое взаимодействие, поскольку все валидаторы могут независимо проверять последовательность PoH.

Tower BFT — это алгоритм, который используют квалифицированные, синхронизированные по времени валидаторы для голосования. Комбинация общего времени (PoH) и экономически защищенной системы голосования (Tower BFT с весом PoS) обеспечивает консенсус, который является одновременно быстрым и устойчивым к манипуляциям.

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

Как транзакция Solana достигает финализации: шаг за шагом

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

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

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

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

4. Создание блока. В пределах своего примерно 400-миллисекундного окна слота лидер собирает все транзакции с временными метками в блок. Поскольку транзакции поступают предсортированными по последовательности PoH, лидеру не нужно договариваться о порядке с другими валидаторами. Он просто формирует блок в соответствии с установленной временной шкалой.

5. Распространение Turbine. Протокол распространения блоков Turbine в Solana разбивает готовый блок на меньшие пакеты данных, называемые «фрагментами» (shreds), и распределяет их между всеми остальными валидаторами, используя структуру распространения по деревьям, вдохновленную BitTorrent. Вместо одновременной трансляции полного блока всем валидаторам (что потребовало бы огромной пропускной способности при большом объеме), Turbine передает фрагменты через структурированное дерево валидаторов, причем каждый валидатор отвечает за ретрансляцию небольшому числу узлов-партнеров. Это снижает нагрузку на пропускную способность любого отдельного валидатора, обеспечивая при этом быстрое достижение полного блока всеми участниками.

6. Голосование Tower BFT. Получив фрагменты блока и собрав полный блок, другие валидаторы проверяют корректность последовательности PoH и правильность формирования транзакций. Каждый валидатор подает взвешенный по стейку голос Tower BFT о достоверности блока. Валидаторы с большим количеством застейканных SOL имеют пропорционально больший вес в этом голосовании. Голоса распространяются по сети, когда валидаторы сигнализируют о своем подтверждении.

7. Финализация. Когда валидаторы, коллективно представляющие более двух третей всего застейканного SOL, подтвердили блок, он достигает финализации Tower BFT и навсегда записывается в реестр. Этот порог супербольшинства является тем же требованием 2/3+, которое лежит в основе теории византийской отказоустойчивости: оно гарантирует, что консенсус сохраняется, даже если до одной трети участников с весом стейка являются неисправными или злонамеренными.

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

Производительность Solana: скорость, пропускная способность и финализация

Скорость Solana — результат не одного дизайнерского решения. Это совокупный эффект четырех архитектурных решений, работающих в координации: Proof of History, Tower BFT, протокол Solana Gulf Stream и протокол распространения блоков Solana Turbine.

Почему Solana работает быстро? Четыре причины

1. Proof of History (Доказательство истории) предоставляет проверяемую ссылку для упорядочивания, которая может снизить накладные расходы на координацию времени; валидаторы по-прежнему обмениваются голосами и сетевыми данными.
2. Tower BFT требует меньше раундов голосования, чем стандартные реализации BFT, поскольку все валидаторы используют общие часы PoH и им не нужно согласовывать время.
3. Предварительная отправка транзакций известным лидерам (Leader-aware forwarding) отправляет транзакции к будущим лидерам до начала их слотов, что может уменьшить традиционное ожидание в очереди мемпула, но не устраняет полностью задержки или конкуренцию за комиссии.
4. Протокол распространения блоков Turbine от Solana распределяет блоки небольшими фрагментами через древовидную структуру, а не широковещательно рассылает полные блоки всем валидаторам одновременно, снижая требования к пропускной способности в больших сетях.

Теоретическая максимальная пропускная способность Solana — это исторический теоретический показатель примерно в 65 000 транзакций в секунду в идеальных сетевых условиях. Этот показатель является ориентиром, а не описанием типичной производительности. Реальная пропускная способность мейннета исторически составляла в среднем от 2 000 до 4 000 TPS, с пиками в периоды высокого спроса. Разрыв между теоретическим максимумом и реальным средним значением отражает задержки распространения в сети, географическое распределение валидаторов и накладные расходы программного обеспечения, которые не учитываются в идеальных условиях. Проверьте текущие показатели на Solscan (solscan.io) на момент написания.

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

Для сравнения: Ethereum, который перешел с Proof of Work на Proof of Stake в сентябре 2022 года, теперь достигает примерно 15-30 TPS на своем уровне 1 (Layer 1), при этом полная экономическая окончательность занимает около 12-15 минут через контрольные точки (checkpoint epochs) Casper FFG (проверьте на ethereum.org). Консенсус Nakamoto в Bitcoin достигает примерно 7 TPS с вероятностной окончательностью, занимающей около 60 минут через 6 подтверждений блока.

Разрыв в окончательности между Solana и Ethereum уровень 1 (Layer 1) существенен. Важен ли этот разрыв для конкретного варианта использования, зависит от приложения. Сети уровня 2 (Layer 2) Ethereum (Arbitrum, Optimism и другие) предлагают более быструю окончательность, чем Ethereum L1, хотя они работают по другим механизмам, чем консенсус Solana.

Консенсус Solana против Ethereum, Avalanche, Cardano и Polkadot

Solana — не единственный высокопроизводительный блокчейн, и его механизм консенсуса — не единственный подход к быстрой и масштабируемой окончательности транзакций. Вот как система PoH + Tower BFT + PoS Solana сравнивается архитектурно и по метрикам производительности с наиболее заметными альтернативами.

Ethereum (после Merge, сентябрь 2022 г.) теперь использует Gasper — систему консенсуса, объединяющую LMD-GHOST (правило выбора цепочки, которое выбирает цепочку с наибольшим количеством накопленных аттестаций валидаторов) и Casper FFG (механизм окончательности, который периодически создает контрольные точки цепочки). Ethereum перешел с Proof of Work на Proof of Stake 15 сентября 2022 года. Архитектурный контраст с Solana значителен: Gasper от Ethereum обеспечивает безопасность и децентрализацию за счет огромного количества валидаторов (примерно 900 000 или более валидаторов, проверьте на beaconcha.in на момент написания) ценой пропускной способности. Solana достигает высокой пропускной способности за счет механизма часов PoH и эффективности Tower BFT, но со значительно меньшим количеством валидаторов.

Avalanche (C-Chain) использует Snowman consensus — вариант протокола консенсуса Avalanche для линейных цепочек. Snowman является вероятностным и основанным на выборке, а не детерминированным BFT: валидаторы многократно выбирают случайные подмножества других валидаторов для оценки согласия. Публикуемые показатели пропускной способности и окончательности варьируются в зависимости от даты, рабочей нагрузки и метода измерения, поэтому для сравнения следует использовать актуальные основные источники. Архитектурный контраст заключается в том, что Avalanche использует повторную субвыборку, в то время как Solana использует голосование с учетом доли (stake-weighted voting), построенное вокруг ориентира упорядочивания PoH.

Cardano использует Ouroboros Praos — текущую версию Ouroboros PoS консенсусной семьи для мейннета. Ouroboros был первым доказанно безопасным PoS протоколом, опубликованным в рецензируемых научных журналах с формальными математическими доказательствами безопасности. Дизайн Cardano явно отдает приоритет формальной корректности и доказательствам безопасности над чистой пропускной способностью. Реальная TPS на мейннете Cardano составляет приблизительно 250 (проверьте на момент написания). Контраст в философии дизайна с Solana прям: Solana отдает приоритет пропускной способности за счет архитектурных инноваций; Cardano отдает приоритет формальной доказуемости свойств безопасности за счет академической строгости.

Polkadot (релейная цепочка) использует BABE (Blind Assignment for Blockchain Extension) для производства блоков и GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) для окончательности, достигая примерно 1000 TPS на релейной цепочке с окончательностью от 12 до 60 секунд. Архитектура релейной цепочки Polkadot плюс парачейны фундаментально отличается от монолитного дизайна цепочки Solana, что делает прямое сравнение производительности более сложным, чем показывают только цифры в таблице.

Все цифры являются ориентировочными оценками. Метрики производительности зависят от сетевых условий; теоретические максимумы отражают пропускную способность в идеальных условиях. Перед принятием каких-либо решений проверьте актуальные цифры в официальной документации (docs.solana.com, ethereum.org, Solana Beach, beaconcha.in). Количество валидаторов часто меняется.

Преимущества и недостатки модели консенсуса Solana

Архитектура консенсуса Solana обеспечивает измеримые преимущества в скорости и пропускной способности по сравнению с любым основным блокчейном уровня 1 (Layer 1), но эти преимущества сопряжены с реальными компромиссами в области децентрализации и историческим послужным списком надежности, который любая серьезная оценка должна честно рассматривать.

Преимущества:

• Целевые показатели низкой задержки подтверждения. Solana может обеспечивать быстрое оптимистичное подтверждение, но необходимо различать уровень подтверждения (commitment) и экономическую окончательность.
• Дизайн с высокой пропускной способностью. Исторические ориентиры иллюстрируют архитектурную емкость, в то время как фактическая пропускная способность зависит от рабочей нагрузки, учета голосов, валидаторов, загруженности и версий программного обеспечения.
• Низкие комиссии за транзакции. Высокая пропускная способность означает меньшую конкуренцию за комиссии между транзакциями, сохраняя стоимость операций в доли цента для большинства операций.
• Пересылка транзакций без мемпула. Протокол Gulf Stream от Solana устраняет проблему «зала ожидания», сокращая задержку подтверждения путем предварительной маршрутизации транзакций к известным будущим лидерам.
• Энергоэффективность. Proof of Stake не требует энергоемких вычислений, что ставит энергетический след Solana в принципиально иную категорию, чем Proof of Work у Bitcoin.

Недостатки:

• Исторические сбои сети. Solana пережила несколько полных остановок сети между 2021 и 2023 годами, что вызвало реальные опасения по поводу надежности, которые должны учитывать любые инвесторы или разработчики.
• Меньше валидаторов, чем у Ethereum. Относительно небольшое количество валидаторов создает иной профиль децентрализации по сравнению с сетями, имеющими сотни тысяч валидаторов.
• Высокие требования к оборудованию создают барьер для участия. Запуск валидатора Solana требует серверного оборудования, которое большинство частных лиц не могут себе позволить или эксплуатировать, что ограничивает тех, кто может напрямую участвовать в консенсусе.
• Зависимость от одного клиента валидатора (до Firedancer). До недавнего времени почти все валидаторы Solana использовали один и тот же клиентское программное обеспечение, что создавало единую точку отказа, если у этого клиента были ошибки.
• Концентрация стейка среди топ-валидаторов. Значительная часть общего количества застейканных SOL сконцентрирована среди небольшого числа валидаторов, что влияет на коэффициент Накамото.

Почему сеть Solana выходила из строя?

Исторические сбои Solana были вызваны не отказами алгоритмов консенсуса Proof of History или Tower BFT. Сам дизайн консенсуса не ломался. Задокументированные основные причины крупных сбоев заключались в исчерпании ресурсов программного обеспечения и ошибках реализации: спам транзакциями, перегружающий память валидаторов, ошибки программного обеспечения в клиенте валидатора, вызывающие сбои, и исчерпание ресурсов, вызванное событиями высокого спроса, включая массовый выпуск NFT и всплески активности DeFi.

Конкретные события иллюстрируют эту закономерность. В сентябре 2021 года Solana пережила 17-часовой сбой, вызванный наводнением транзакциями от события IDO, которое насытило память валидаторов и вызвало форк сети, потребовавший скоординированного перезапуска. В январе 2022 года второй значительный сбой произошел из-за исчерпания ресурсов при высоких нагрузках. Множество дополнительных частичных сбоев в работе произошли в течение 2022 года (проверьте конкретные даты и продолжительность в отчетах Solana Foundation по итогам инцидентов на момент написания, так как список задокументированных инцидентов расширился). Отличие этих событий от отказа алгоритма консенсуса важно для оценки долгосрочной жизнеспособности Solana: сломанный алгоритм консенсуса потребует перепроектирования протокола, тогда как исчерпание ресурсов программного обеспечения является решаемой инженерной проблемой.

Улучшения, реализованные с момента пикового периода сбоев, включают принятие QUIC в качестве сетевого протокола (заменившего подход на основе UDP, более уязвимый к спаму), систему качества обслуживания с учетом доли стейка (stake-weighted quality-of-service), которая отдает приоритет транзакциям от валидаторов со стейком перед анонимным спамом, а также постоянные улучшения клиентского программного обеспечения валидатора. Клиент Firedancer, независимая высокопроизводительная реализация валидатора, разработанная Jump Crypto, призван обеспечить разнообразие клиентов, которое предотвратит влияние одного программного бага на всю сеть. Проверьте текущий статус разработки Firedancer на официальных источниках на момент написания.

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

Децентрализация и концентрация валидаторов: В Solana насчитывается около 1500 или более активных валидаторов на момент написания (проверьте текущее количество на аналитике валидаторов Solana Beach). В Ethereum насчитывается около 900 000 или более валидаторов (проверьте на beaconcha.in). Разница существенна и отражает барьер для валидации Solana, связанный с оборудованием: запуск валидатора Solana требует примерно 128 ГБ ОЗУ или более, высокопроизводительного NVMe SSD объемом 2 ТБ или более, а также сетевого соединения минимум 1 Гбит/с (проверьте текущие спецификации на docs.solana.com/running-validator на момент написания). По контрасту, валидаторы Ethereum могут работать на потребительском оборудовании в сочетании с 32 ETH.

Коэффициент Накамото Solana (минимальное количество сущностей, которые должны сговориться, чтобы скомпрометировать консенсус) исторически варьировался примерно от 19 до 31 валидатора, хотя эта цифра меняется при изменении распределения стейка. Проверьте текущий коэффициент в отчетах Solana Foundation по децентрализации или на Nakaflow на момент написания. Топ-20 валидаторов исторически контролировали значительную долю общего количества застейканных SOL (проверьте текущий процент концентрации на Solana Beach). Solana Foundation управляет программой делегирования, специально разработанной для распределения стейка среди меньших валидаторов и улучшения этого коэффициента, предоставляя структурную меру противодействия концентрации. Порог безопасности Tower BFT означает, что атакующему потребуется контролировать более одной трети всего застейканного SOL, чтобы остановить сеть, и более двух третей, чтобы переопределить консенсус, — высокие капитальные затраты, которые масштабируются в зависимости от фактической концентрации этого стейка.

Как участвовать: стейкинг и валидация на Solana

Владельцы SOL могут участвовать в механизме консенсуса Solana двумя способами: управляя непосредственно нодой валидатора или делегируя SOL существующему валидатору. Первый путь требует значительных инвестиций в оборудование и технических знаний. Второй доступен любому владельцу SOL с совместимым кошельком.

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

Требования для запуска валидатора Solana

Управление валидатором Solana делает оператора лидером для назначенных слотов и голосующим для всех остальных слотов. Требования к оборудованию значительны и возросли по мере роста сети. Всегда проверяйте текущие спецификации в официальной документации валидатора Solana перед приобретением оборудования:

• ЦП: Высокая производительность одного ядра; конкретные рекомендации по моделям обновляются в официальной документации.
• ОЗУ: Рекомендуется минимум 128 ГБ; 256 ГБ или более для лучшей производительности.
• Хранилище: Высокопроизводительный NVMe SSD; рекомендуется 2 ТБ или более.
• Сеть: Минимальное соединение 1 Гбит/с; 10 Гбит/с рекомендуется для конкурентной производительности.
• SOL stake: Достаточное количество собственных делегированных средств (stake) или делегированных сообществом средств (stake), чтобы сделать работу экономически выгодной. Нет минимального обязательного требования к количеству средств (stake) для запуска валидатора, но валидаторы с очень небольшим количеством средств (stake) получают очень маленькое вознаграждение.

Требования к оборудованию возросли с каждым крупным обновлением сети. Любой, кто планирует управлять валидатором, должен заложить в бюджет текущие расходы на модернизацию оборудования и подтвердить все спецификации в официальной документации перед покупкой оборудования.

Как внести SOL в стейкинг: Варианты нативного и ликвидного стейкинга

Делегирование SOL существующему валидатору — это доступный путь для большинства участников. Механика работы следующая.

Нативный стейкинг: Используя совместимый кошелек, такой как Phantom или Solflare, любой владелец SOL может делегировать свои токены выбранному валидатору. Делегирование приносит долю от вознаграждений за инфляцию этого валидатора, пропорциональную делегированной сумме. Текущая доходность от APY варьируется в зависимости от параметров инфляции сети и общего количества застейканных SOL (проверьте на Solana Beach на момент написания перед принятием каких-либо решений о стейкинге). Существует период ожидания для отмены делегирования (undelegation cooldown period) примерно в два эпохальных периода, что составляет примерно четыре-пять дней, прежде чем делегированные SOL снова станут ликвидными (проверьте на docs.solana.com на момент написания).

Ликвидный стейкинг: Протоколы, включая Marinade Finance (который выпускает токены mSOL) и Jito (который выпускает токены jitoSOL), позволяют пользователям стейкать SOL, сохраняя ликвидность. Вместо прямой блокировки SOL у валидатора и ожидания периода разблокировки для доступа к нему, пользователи ликвидного стейкинга получают ликвидный токен, представляющий их стейкнутый SOL плюс начисленные вознаграждения, который можно торговать в любое время. Эти токены ликвидного стейкинга являются частью протоколов DeFi, работающих на Solana, и несут свои собственные риски смарт-контрактов в дополнение к базовой экономике стейкинга.

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

Часто задаваемые вопросы о механизме консенсуса Solana

Какой механизм консенсуса использует Solana?

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

Является ли Solana блокчейном Proof of Stake?

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

Насколько Solana быстрее Ethereum?

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

Исторические сбои сети Solana были вызваны исчерпанием ресурсов программного обеспечения и ошибками реализации, а не сбоями в алгоритмах консенсуса Proof of History или Tower BFT. Задокументированные причины включают спам транзакций, перегружающий память валидаторов, ошибки программного обеспечения в клиентской части валидатора и исчерпание ресурсов во время событий высокого спроса, таких как минт NFT и пики активности DeFi. Сбой в сентябре 2021 года длился около 17 часов и был вызван наплывом трафика от IDO-мероприятия. Улучшения с момента пикового периода сбоев 2021-2022 годов включают сетевые протоколы QUIC, приоритизацию транзакций с учетом веса стейка и постоянные улучшения клиентской части валидатора. Проверяйте текущий статус надежности сети в блоге Solana Foundation на момент написания.

Proof of History (PoH) — это механизм криптографического учета времени, изобретенный Анатолием Яковенко и представленный в его Whitepaper 2017 года под названием «Solana: новая архитектура для высокопроизводительного блокчейна». PoH создает непрерывную, проверяемую запись о времени событий путем последовательного хеширования выходов SHA-256. Это не механизм консенсуса. Это криптографические часы, которые позволяют фактическому алгоритму консенсуса Solana, Tower BFT, работать с гораздо меньшим количеством раундов связи. Для получения полной информации см. раздел Proof of History выше.

Кто изобрел механизм консенсуса Solana?

Анатолий Яковенко, бывший инженер Qualcomm, представил Proof of History в основополагающем Whitepaper Solana в 2017 году. Яковенко основал Solana Labs вместе с Грегом Фицджеральдом и Раджем Гокалом, которые внесли вклад в более широкую реализацию протокола. PoH предоставляет проверяемую эталонную последовательность, которая может сократить некоторые накладные расходы на координацию времени, но не устраняет коммуникацию для достижения консенсуса.

По состоянию на момент написания Solana насчитывает примерно 1500 или более активных валидаторов; актуальную цифру можно проверить на аналитике валидаторов Solana Beach для получения текущих данных. Для сравнения, Ethereum насчитывает примерно 900 000 или более валидаторов (проверить можно на beaconcha.in). Разница в количестве валидаторов отражает различия в требованиях к оборудованию: валидаторы Solana требуют оборудования серверного класса с 128 ГБ ОЗУ или более, в то время как валидаторы Ethereum могут работать на оборудовании потребительского класса вместе с 32 ETH.

Tower BFT — это алгоритм консенсуса Solana, построенный как адаптация PBFT, которая использует Proof of History в качестве общего тактового генератора. Валидаторы подают взвешенные по стейку голоса за блоки; блок считается окончательным, когда валидаторы, представляющие более двух третей всего стейкнутого SOL, подтверждают его. Этот порог в 2/3+ супербольшинства означает, что сеть терпит до одной трети участников, действующих злонамеренно (взвешенных по стейку), без потери целостности консенсуса.

Стейкинг в Solana технически схож с Delegated Proof of Stake (DPoS), поскольку держатели SOL могут делегировать средства валидаторам, не запуская собственный узел. Однако он отличается от традиционных систем DPoS одним ключевым моментом: нет фиксированного, избранного набора делегированных валидаторов. Любой валидатор может привлечь делегирование с открытого рынка. Точнее, Solana использует систему PoS с весовыми коэффициентами стейка и открытым делегированием, действующую как слой экономической безопасности поверх PoH и Tower BFT, а не традиционную архитектуру DPoS с фиксированным пулом делегатов.

Ни одна из сетей объективно не лучше другой. Каждая идет на разные архитектурные компромиссы, подходящие для разных сценариев использования. Исторические измерения, как правило, показывают более высокую пропускную способность базового уровня и более низкие комиссии в Solana, в то время как время подтверждения зависит от уровня обязательств и сетевых условий. Ethereum имеет большее сообщество разработчиков и обширную экосистему Layer 2. Одно только количество валидаторов не измеряет децентрализацию; также важны распределение стейка, разнообразие клиентов, концентрация операторов и требования к оборудованию. Правильный выбор зависит от приложения и модели риска.

Изучите SOL на Bybit

Читатели могут ознакомиться с актуальной рыночной информацией о SOL) или сравнить доступные продукты SOL Earn.). Bybit Earn — это централизованный продукт, и его не следует описывать как нативный стейкинг валидаторов Solana; условия, хранение, доступность и риски отличаются.

• Механизм консенсуса Solana — это гибридная система: Proof of History (криптографические часы) + Tower BFT (алгоритм достижения согласия) + Proof of Stake (слой экономической безопасности). Ни один компонент сам по себе не составляет механизм.

• Proof of History не является механизмом консенсуса. Это инструмент криптографического учета времени, который устанавливает порядок транзакций перед тем, как валидаторы начнут общаться, позволяя Tower BFT достигать консенсуса за гораздо меньшее количество раундов голосования, чем стандартные реализации BFT.

• Сбои сети Solana были вызваны исчерпанием ресурсов программного обеспечения, а не сбоями в PoH или Tower BFT. Дизайн консенсуса не был нарушен. Улучшения, включая сетевые протоколы QUIC, приоритизацию комиссий с учетом веса стейка и клиент Firedancer, направлены на снижение риска будущих остановок.

• Консенсус Solana быстрее, чем Ethereum Layer 1 и Bitcoin, достигая окончательности менее чем за 1,3 секунды по сравнению с 12-15 минутами для Ethereum L1 и примерно 60 минутами для Bitcoin, но эта скорость достигается за счет компромиссов: меньшее количество валидаторов, более высокие требования к оборудованию и опасения по поводу концентрации стейка.

• Любой держатель SOL может участвовать в механизме консенсуса Solana, делегируя SOL валидатору через нативные протоколы стейкинга или протоколы ликвидного стейкинга. Прямое управление валидатором требует значительных инвестиций в оборудование и технических знаний.

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

Чтобы участвовать в механизме консенсуса Solana, обратитесь к разделам о стейкинге и валидации выше или посетите официальную документацию Solana по адресу docs.solana.com.

Дополнительное чтение:

• Solana: новая архитектура для высокопроизводительного блокчейна:) — Whitepaper Анатолия Яковенко от ноября 2017 г.
• Официальная документация Solana: спецификации протокола, требования к оборудованию, руководства по стейкингу
• Аналитика валидаторов Solana Beach: текущее количество валидаторов, распределение стейка и статистика сети

Связанные материалы

• Solana Proof of History
• Архитектура Solana
• Скорость Solana