Архитектура Solana: 8 инноваций, обеспечивающих скорость SOL

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

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

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

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

Архитектура Solana построена на восьми опорах, каждая из которых решает конкретное узкое место производительности:

1. Proof of History (PoH): криптографические часы, которые ставят временные метки событиям до запуска консенсуса
2. Tower BFT: механизм консенсуса, который использует временные метки PoH при голосовании
3. Turbine: распространение блоков, которое разбивает блоки на более мелкие пакеты
4. Gulf Stream: перенаправление транзакций на основе запланированных лидеров
5. Sealevel: среда выполнения параллельных смарт-контрактов
6. Pipelining: поэтапная обработка транзакций
7. Cloudbreak: база данных аккаунтов, разработанная для параллельного доступа
8. Archivers: историческое предложение по распределенному хранению

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

Честный компромисс: Solana испытывала задокументированные сбои сети с момента запуска мейннета в марте 2020 года, а ее аппаратные требования к валидаторам (рекомендуется 128+ ГБ ОЗУ) создают давление на централизацию. Это известные архитектурные компромиссы, а не случайные проблемы.

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

Блокчейны традиционно сталкиваются с фундаментальным ограничением: трилемма блокчейна, концепция, популяризированная Виталиком Бутериным, гласит, что сеть может одновременно достичь максимум двух из трех свойств. Этими свойствами являются масштабируемость (высокая пропускная способность), безопасность (устойчивость к атакам) и децентрализация (распределенный контроль). Представьте это как треугольник, где при вытягивании одного угла всегда втягиваются два других. Bitcoin обрабатывает ~7 TPS с 10-минутными интервалами между блоками, отдавая приоритет безопасности и децентрализации за счет пропускной способности. Ethereum обрабатывал ~15–30 TPS на базовом уровне до добавления решений для масштабирования, также отдавая приоритет безопасности и децентрализации.

Анатолий Яковенко, бывший инженер по распределенным системам в Qualcomm, подошел к этому ограничению иначе. В ноябре 2017 года он опубликовал whitepaper под названием Proof of History: A Clock for Blockchain (Доказательство истории: Часы для блокчейна), описывающий криптографический механизм хронометража, который мог бы значительно снизить накладные расходы на связь в алгоритмах консенсуса. Грег Фицджеральд присоединился в качестве соучредителя и технического директора, и вместе они создали протокол, который стал Solana. Solana Labs, для-прибыльная компания, которую они основали, руководит разработкой основного протокола. Solana Foundation, отдельная некоммерческая организация, базирующаяся в Женеве, финансирует гранты для экосистемы, программы децентрализации валидаторов и образовательные инициативы.

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

Восемь архитектурных опор Solana: Обзор

Историческая восьмичастная структура охватывает Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak и Archivers. Не все элементы следует рассматривать как отдельные развернутые текущие подсистемы, особенно предложение Archivers.

1. Proof of History (PoH): последовательная хеш-цепочка SHA-256, создающая проверяемую временную запись до запуска механизма консенсуса
2. Tower BFT: механизм консенсуса с отказоустойчивостью к византийским сбоям, улучшенный PoH, который использует временные метки PoH для эффективного голосования
3. Turbine: протокол распространения блоков, вдохновленный BitTorrent, который разбивает блоки на небольшие пакеты с кодированием стирания, называемые «шредами» (shreds)
4. Gulf Stream: протокол перенаправления транзакций без мемпула, который направляет транзакции непосредственно к предстоящим лидерам-валидаторам
5. Sealevel: среда выполнения параллельных смарт-контрактов, которая одновременно запускает тысячи неконфликтующих программ
6. Pipelining: система оптимизации проверки транзакций (TVO), которая обрабатывает транзакции через четыре параллельных аппаратных этапа
7. Cloudbreak: горизонтально масштабируемая база данных аккаунтов, использующая файлы с отображением в памяти для поддержки одновременных чтений и записей
8. Archivers: историческое предложение по хранению данных распределенного реестра с использованием концепций доказательства репликации

Каждая опора подробно рассматривается в разделах ниже.

Proof of History (PoH): Система хронометража Solana

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

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

Технически PoH представляет собой последовательную хеш-цепочку SHA-256, где каждый выходной результат становится входным для следующей операции. Поскольку SHA-256 не может быть распараллелен в этой цепочечной форме, длина цепочки является защищенной от несанкционированного доступа записью прошедшего времени. Валидатор, который производит цепочку из N хэшей, явно потратил время, необходимое для вычисления N последовательных хэш-операций. Коротких путей не существует. Анатолий Яковенко впервые описал этот механизм в своей whitepaper от ноября 2017 года, Proof of History: A Clock for Blockchain.

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

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

Критическое уточнение: Solana иногда описывают как «блокчейн Proof of History», подразумевая, что PoH заменяет Proof of Stake (PoS). Это неверно. Solana — это блокчейн Proof of Stake на уровне экономической безопасности. Валидаторы вносят SOL в стейкинг в качестве обеспечения и подвергаются слэшингу за недобросовестное поведение. PoH — это криптографические часы, которые делают консенсус PoS Solana, реализованный через Tower BFT, быстрее и эффективнее. Оба уровня необходимы; ни один не заменяет другой.

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

Tower BFT — это механизм консенсуса Solana: вариант Practical Byzantine Fault Tolerance (pBFT), улучшенный PoH, который использует запись временных меток PoH в качестве общего часового механизма, позволяя валидаторам голосовать за состояние реестра без обмена сообщениями синхронизации часов.

Практическая устойчивость к византийским сбоям (BFT) описывает свойство распределенной системы, которое позволяет ей корректно достигать консенсуса даже при наличии злонамеренного или непредсказуемого поведения некоторых участников, названное в честь задачи византийских генералов в распределенных вычислениях. Традиционные алгоритмы pBFT требуют обширного обмена сообщениями между узлами для установления общего представления о времени, что делает их непрактичными в масштабе. Tower BFT подменяет обмен сообщениями записью PoH. Валидаторы уже имеют общий часовой механизм PoH; им не нужно согласовывать временные метки.

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

Tower BFT устойчив к византийскому поведению до одной трети валидаторов. Если менее одной трети валидаторов действуют злонамеренно, сеть достигает корректного консенсуса. Этот порог следует из математических требований задачи византийских генералов, изначально формализованной Лампортом, Шостаком и Пизом в 1982 году. Линия консенсуса для исследователей: pBFT (Кастро и Лисков, 1999) заложил фундаментальный алгоритм; последующие варианты, включая HotStuff и Tendermint, улучшили его; Tower BFT (2017) делает дальнейший шаг, устраняя накладные расходы на синхронизацию часов через PoH.

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

Turbine: Распространение блоков в масштабе

Трансляция полного блока каждому валидатору при теоретических 65 000 TPS создала бы узкое место по пропускной способности, которое линейно растет с размером сети. Turbine решает эту проблему так же, как BitTorrent решает распространение больших файлов: разбивая данные на мелкие части и распределяя нагрузку по распространению по всей сети.

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

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

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

Gulf Stream: Пересылка транзакций без мемпула

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

В Ethereum неподтвержденные транзакции ожидают в мемпуле: общем пуле неподтвержденных транзакций, ожидающих включения в блок. В периоды высокого спроса этот пул становится источником перегрузки, эскалации комиссий и максимальной извлекаемой стоимости (MEV) — прибыли, извлекаемой путем переупорядочивания, вставки или цензуры транзакций в мемпуле перед их финализацией. Пользователи Ethereum предлагают более высокие комиссии за газ для приоритезации своих транзакций, поэтому комиссии исторически достигали 5–50+ долларов США во время пикового использования.

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

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

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

Sealevel: Параллельное выполнение смарт-контрактов

Sealevel — это среда выполнения параллельных смарт-контрактов Solana, движок, который запускает ончейн-программы (термин Solana для того, что Ethereum называет смарт-контрактами). В отличие от EVM Ethereum, который выполняет контракты последовательно по одному за раз, Sealevel выполняет тысячи неконфликтующих программ одновременно на доступных ядрах GPU и CPU.

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

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

Ончейн программы пишутся в основном на Rust, компилируются в байт-код Berkeley Packet Filter (BPF) и выполняются средой выполнения Sealevel. Параллельное выполнение на ядрах GPU и CPU позволяет достичь теоретических 65 000 TPS на аппаратном уровне.

Что это значит для разработчиков

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

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

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

Конвейеризация: Валидация транзакций как сборочная линия

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

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

Четыре этапа:

1. Получение (Fetch): блок в пространстве ядра извлекает входящие данные транзакции из сети
2. Проверка подписи (Signature Verification, SigVerify): GPU параллельно проверяет криптографические подписи в пакете
3. Банкинг (Banking): ЦП обрабатывает логику транзакций, проверяет балансы учетных записей и обновляет состояние учетных записей
4. Подтверждение записи (Write Confirmation): диск записывает окончательные изменения состояния

Пока партия A находится в Банкинге, партия B — в SigVerify, а партия C — в Получении. Ни одно аппаратное обеспечение не простаивает в ожидании завершения предыдущей партии. Эта непрерывная поэтапная обработка устраняет время простоя ЦП между этапами обработки, которое иначе ограничивало бы пропускную способность.

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

Cloudbreak: Горизонтально масштабируемая база данных учетных записей

Cloudbreak — это файловая система, которая позволяет параллельным процессорам Solana одновременно читать и записывать данные учетных записей без постановки в очередь. Без нее уровень хранения сериализовал бы все операции чтения и записи учетных записей, и выгоды от параллелизма Sealevel испарились бы на границе базы данных.

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

Учетные записи распределены по нескольким структурам данных, доступным параллельно. Операции ввода-вывода с отображением памяти операционной системы позволяют Cloudbreak обращаться к данным учетных записей, находящимся на диске, как если бы они находились в оперативной памяти, устраняя задержку поиска и обеспечивая параллельный доступ на уровне потоков. Когда Sealevel планирует 10 000 параллельных транзакций, Cloudbreak обслуживает 10 000 одновременных операций чтения и записи учетных записей, не сериализуя запросы в очередь.

Архитектура базы данных и среда выполнения взаимозависимы: ни одна из них не обеспечивает пропускную способность без другой. Шаблоны ввода-вывода Cloudbreak требуют высокопроизводительных NVMe SSD. Стандартные вращающиеся диски не могут обеспечить пропускную способность случайного чтения/записи, которую требует модель параллельного доступа Cloudbreak. Понимание модели учетных записей Cloudbreak является основополагающим для проектирования программ Solana: все состояние находится в дискретных объектах учетных записей, программы работают без сохранения состояния с этими учетными записями, а решения по макету учетных записей напрямую влияют на производительность чтения/записи среды выполнения.

Archivers: Предложение по хранению исторических данных

Концепция Archivers появляется в ранних материалах по архитектуре Solana, но ее не следует представлять как развернутую в настоящее время производственную подсистему без подтверждения из первоисточников.

В ранних проектных материалах предлагалось, чтобы Archivers, также называемые Replicators в некоторых описаниях, выступали в роли легковесных участников, хранящих части исторических данных реестра и подтверждающих хранение. Это объясняет первоначальный подход к росту реестра, но это не следует описывать как активную, приносящую вознаграждение производственную сеть без текущего подтверждения из первоисточников. Текущая инфраструктура для хранения и архивирования реестра должна документироваться отдельно.

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

Бенчмарки производительности Solana: TPS, комиссии и финализация блоков

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

Используйте текущие первоисточники и последовательную методологию измерения для сравнения производительности.

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

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

Экосистема Ethereum Layer-2 (включая Arbitrum и Optimism) и будущие обновления шардинга значительно увеличивают эффективную пропускную способность Ethereum по сравнению с показателем базового уровня. Любое полное сравнение должно учитывать эту расширенную мощность при оценке двух платформ для конкретного варианта использования.

От архитектуры к приложению: как дизайн Solana обеспечивает реальные варианты использования

Архитектурные решения Solana приносят конкретные, измеримые результаты для приложений, построенных на их основе, а не абстрактные показатели производительности.

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

DeFi: В среде выполнения Solana можно обрабатывать неконфликтующие транзакции параллельно, а как правило, низкие комиссии могут поддерживать частые взаимодействия. Фактическая задержка и стоимость обмена включают маршрутизацию, проскальзывание, комиссии за приоритет, неуспешные транзакции, вычисления программы и рыночные условия. Gulf Stream не устраняет риск MEV или фронтраннинга.

GameFi и микротранзакции: Как правило, низкие комиссии могут поддерживать действия с малым объемом, но общие затраты на приложение и неуспешные транзакции по-прежнему имеют значение. Затраты на Ethereum L1 и L2 следует сравнивать отдельно, используя актуальные данные.

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

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

Архитектурные компромиссы: надежность сети, децентрализация и скорость

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

Сбои в работе сети

Дизайн Solana с высокой пропускной способностью обрабатывает транзакции с минимальной предварительной фильтрацией, что создает специфическую уязвимость. Когда боты заполняют сеть спам-транзакциями, валидаторы могут исчерпать доступную память до того, как транзакции достигнут этапа фильтрации, вызывая остановку консенсуса. Основные документированные сбои включают сбой в сентябре 2021 года, длившийся около 17 часов, вызванный всплеском объема транзакций от события IDO, управляемого ботом, и сбой в январе 2022 года, связанный с избыточными дублирующимися транзакциями от валидаторов. Дополнительные более короткие сбои произошли в 2022 и 2023 годах.

Solana Labs реализовала два основных архитектурных смягчения. Сетевой протокол QUIC заменил UDP для приема транзакций, обеспечивая контроль потока на уровне соединения, который ограничивает количество транзакций, которые может отправить любой отдельный источник. Система приоритетов обслуживания (QoS), взвешенная по стейку, отдает приоритет пересылке транзакций от валидаторов с большим стейком SOL, делая спам-потоки от источников с низким стейком менее эффективными. Рынки комиссий за вычислительные единицы создают экономическое трение против спама при высоких объемах. Частота сбоев снизилась после внедрения этих мер. История сбоев остается известным фактором риска для приложений, требующих непрерывной высокой доступности.

Проблемы централизации валидаторов

Валидаторы Solana требуют значительного оборудования. Согласно документации Solana Foundation по валидаторам, рекомендуемая спецификация включает 128+ ГБ ОЗУ, высокопроизводительный SSD NVMe и высокоскоростное интернет-соединение. Проверяйте актуальные спецификации на момент прочтения, поскольку требования меняются с обновлениями протокола. Эти требования значительно превышают то, что требуется валидаторам Ethereum для участия в консенсусе PoS.

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

Позиционирование в трилемме блокчейна

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

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

Solana против Ethereum против Bitcoin: Сравнение архитектур

Исторические тесты дают Solana более высокий профиль пропускной способности на базовом уровне, чем у Ethereum mainnet, но измерения не являются аналогичными. PoH предоставляет предварительный порядок консенсуса, Sealevel параллельно выполняет неконфликтующую работу, а переадресация с учетом лидера меняет маршрутизацию транзакций. Часто цитируемые цифры ~65 000 и ~15–30 TPS являются устаревшими, зависящими от методологии точками отсчета, а не постоянными свойствами сети.

Пропускная способность и модель выполнения

EVM Ethereum выполняет контракты последовательно, по одному за блок. Sealevel одновременно выполняет тысячи неконфликтующих контрактов. Это основной источник разрыва в TPS. Ethereum решает проблему пропускной способности за счет масштабирования Layer-2: роллапы, включая Arbitrum и Optimism, обрабатывают транзакции офчейн и выполняют сжатые пакеты на базовом уровне Ethereum, значительно увеличивая эффективную мощность. Подход Solana — это горизонтальное масштабирование на Layer-1, позволяющее избежать дополнительной сложности, которую архитектуры Layer-2 вносят для разработчиков и пользователей.

Сравнение платформ для разработчиков

Экосистема разработчиков Ethereum (Solidity, инструменты EVM, устоявшиеся протоколы DeFi с многолетним аудированным кодом) больше и более зрелая, чем у Solana. Модель Solana на Rust и Sealevel предлагает более высокую пропускную способность на базовом уровне и более низкие комиссии, но требует понимания модели аккаунтов и требования к декларированию доступа к аккаунту, что не имеет прямого эквивалента в Ethereum. Приложения, где пропускная способность и стоимость комиссий являются ограничивающими факторами, хорошо соответствуют архитектуре Solana. Приложения, приоритетом которых является совместимость с EVM, самый широкий пул талантов разработчиков или максимальная децентрализация базового уровня, лучше подходят для базового уровня Ethereum или его экосистемы L2.

Bitcoin как третья точка отсчета

Архитектура Bitcoin отдает приоритет безопасности и децентрализации над пропускной способностью. При ~7 TPS и времени блока 10 минут Bitcoin не предназначен для высокочастотных приложений. Его консенсус Proof of Work по дизайну является вычислительно интенсивным: безопасность через энергозатраты, а не через экономический стейкинг. Solana и Ethereum предлагают платформы программируемых смарт-контрактов, которые Bitcoin нативно не поддерживает. Архитектурная позиция Bitcoin делает его системой другой категории, а не прямым конкурентом для развертывания приложений.

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

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

Что такое Proof of History в Solana?

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

Сколько транзакций в секунду может обрабатывать Solana?

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

Кто создал Solana?

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

Разнице в производительности способствуют несколько архитектурных уровней. PoH предоставляет проверяемый справочный порядок, который может снизить некоторые накладные расходы на координацию, Sealevel выполняет неконфликтующие задачи параллельно, а пересылка с учетом лидера меняет способ доставки транзакций назначенным валидаторам. Исторические показатели TPS зависят от методологии и не должны рассматриваться как неизменные свойства какой-либо сети.

В ранних материалах архитектура группируется по следующим направлениям: Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak и Archivers. Это историческая пояснительная структура, а не доказательство того, что каждый названный элемент (особенно Archivers) остается отдельной развернутой подсистемой сегодня.

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

Gulf Stream описывает пересылку транзакций с учетом лидера, а не обычный глобальный мемпул. Это может уменьшить очереди, но не устраняет конкуренцию за приоритетные комиссии, перегрузки, сбросы транзакций, MEV или риски опережения (front-running). Текущее поведение сети следует проверять по документации по реализации.

Sealevel — это среда параллельного выполнения смарт-контрактов Solana. В отличие от EVM в Ethereum, которая выполняет контракты по одному, Sealevel запускает тысячи неконфликтующих программ одновременно на доступных ядрах CPU и GPU. Параллелизм обеспечивается требованием к каждой транзакции декларировать, к каким аккаунтам она будет обращаться во время отправки, чтобы среда выполнения могла идентифицировать неконфликтующие операции и планировать их одновременное выполнение.

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

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

Основные архитектурные различия заключаются в модели выполнения (параллельная Sealevel против последовательной EVM), маршрутизации транзакций (Gulf Stream без мемпула против глобального мемпула), языке программирования (Rust против Solidity) и пропускной способности базового уровня (~65 000 теоретических TPS против ~15–30 TPS). Оба блокчейна используют Proof of Stake для экономической безопасности. Более крупная экосистема разработчиков Ethereum и опции Layer-2 хорошо подходят для EVM-совместимых проектов; пропускная способность базового уровня и структура комиссий Solana подходят для приложений, где основными ограничениями являются объем и стоимость транзакций.

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

Ончейн-программы Solana в основном пишутся на Rust, компилируются в байт-код Berkeley Packet Filter (BPF) и выполняются средой Sealevel. Также поддерживаются C и C++. Самым широко используемым инструментарием для разработки является фреймворк Anchor на базе Rust, предоставляющий макросы и абстракции, которые упрощают общие шаблоны программ. Актуальные инструменты экосистемы см. в документации для разработчиков Solana.

Стоимость транзакции в Solana включает базовую комиссию и может включать расходы на приоритизацию и вычисления. Стоимость в долларах США меняется вместе с ценой SOL, в то время как перегрузки и поведение приложений влияют на общую стоимость выполнения. Gulf Stream не устраняет конкуренцию за комиссии.

На момент написания статьи у Solana более 1000 активных валидаторов. Проверьте текущее количество и распределение в статистике валидаторов Solana Foundation.). Валидаторы требуют значительных инвестиций в оборудование, включая более 128 ГБ оперативной памяти и высокопроизводительные NVMe SSD, что создает более высокий барьер для входа, чем в большинстве других сетей Proof of Stake, и является основным источником постоянных опасений по поводу децентрализации.

Исследуйте SOL на Bybit

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

Итог: что архитектура Solana значит для экосистемы Web3

Архитектура Solana объединяет несколько взаимосвязанных проектных решений. PoH предоставляет эталон порядка, Sealevel параллелизует выполнение неконфликтующих задач, пересылка с учетом лидера меняет маршрутизацию транзакций, а pipelining, Cloudbreak и Turbine решают задачи обработки, хранения и распространения данных. История задокументированных сбоев и требования к ресурсам валидаторов должны учитываться в той же технической оценке, что и преимущества в производительности.

Для разработчиков, выбирающих платформу, Solana предлагает самую высокую пропускную способность на базовом уровне и одни из самых низких комиссий за транзакции среди всех крупных действующих блокчейнов. Модель учетных записей и требование использовать Rust добавляют сложности в проектирование по сравнению с EVM Ethereum. Требование декларировать доступ к учетным записям изменяет структуру состояния программы, а модель параллельного выполнения вознаграждает программные решения, которые минимизируют общий доступ к состоянию.

Для исследователей, оригинальная работа Анатолия Яковенко [Proof of History: A Clock for Blockchain] (https://solana.com/solana-whitepaper.pdf)) (ноябрь 2017 г.) остается фундаментальным первоисточником для дизайна PoH. Solana Labs поддерживает актуальную архитектурную документацию по адресу docs.solana.com. Фонд Solana публикует статистику валидаторной сети по адресу solana.org/validators. Данные сети в реальном времени доступны через Solana Beach.

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

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

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

• Доказательство истории Solana
• Механизм консенсуса Solana
• SolanaVM
• Скорость Solana