Solana Sealevel: движок параллельной обработки

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

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

Ethereum обрабатывает примерно 15 транзакций в секунду на своем базовом уровне. В документации Solana исторически упоминалось до 65 000 TPS в теоретических или контролируемых условиях; фактическая пропускная способность для пользователей варьируется. Этот разрыв не случаен. Движок, стоящий за этим, называется Sealevel.

Sealevel — это параллельная среда выполнения смарт-контрактов Solana: движок выполнения, который обрабатывает тысячи независимых транзакций одновременно, а не по одной. Он был задуман Анатолием Яковенко, бывшим инженером Qualcomm, который основал Solana Labs (компанию, стоящую за разработкой основного протокола Solana) и написал основополагающий Whitepaper Solana в 2017 году.

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

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

Параллельная обработка Solana Sealevel: краткий обзор

• Sealevel — это параллельная среда выполнения смарт-контрактов Solana, обрабатывающая тысячи транзакций одновременно.
• Как это работает: транзакции заранее объявляют зависимости от аккаунтов; Sealevel запускает неконфликтующие транзакции параллельно.
• Пропускная способность: теоретический максимум ~65 000 TPS; реальные транзакции, не связанные с голосованием, обычно достигают 2 000–4 000 TPS.
• Против Ethereum: виртуальная машина Ethereum (EVM) обрабатывает транзакции по одной; Sealevel обрабатывает независимые транзакции одновременно.
• Честное ограничение: Solana сталкивалась с сбоями в работе сети в 2021 и 2022 годах из-за сбоев приема данных выше по потоку от Sealevel.

Последовательное против параллельного выполнения: основная проблема, которую решает Sealevel

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

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

Потолок пропускной способности, который это создает, вполне реален. Согласно документации Ethereum Foundation, виртуальная машина Ethereum (EVM) обрабатывает примерно 15–30 транзакций в секунду в своей базовой цепочке Layer-1 (L1) без использования роллапов Layer-2 (L2). Эта цифра остается примерно постоянной в течение многих лет, потому что «узкое место» носит архитектурный характер.

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

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

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

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

Как работает Sealevel: модель аккаунтов и предварительное объявление состояния

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

Модель аккаунтов Solana: отделение кода от состояния

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

В Solana программы содержат только исполняемый код и сами не хранят никаких данных. Это программы без сохранения состояния (stateless): они несут инструкции, но не имеют собственного состояния. Данные живут в отдельных объектах аккаунтов, из которых программы могут читать или в которые могут записывать. Такая конструкция отделяет код от состояния на архитектурном уровне. Это отличается от модели Ethereum, где смарт-контракт хранит как свой исполняемый код, так и свое состояние по одному адресу контракта.

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

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

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

Как Sealevel планирует параллельное исполнение

Когда транзакция поступает в Sealevel, процесс планирования проходит четыре отдельных этапа.

1. Транзакция поступает с манифестом: полным списком аккаунтов, которые она будет читать и в которые будет записывать данные.
2. Sealevel строит граф зависимостей (карту того, какие транзакции используют общие аккаунты), одновременно сравнивая манифесты всех ожидающих транзакций.
3. Транзакции, не имеющие общих аккаунтов для записи, являются независимыми. Sealevel одновременно отправляет их на разные ядра процессора, выполняя параллельно на всех доступных ядрах CPU и GPU.
4. Транзакции, заявляющие зависимость по записи от одного и того же аккаунта, находятся в конфликте. Sealevel сериализует эти конкретные транзакции, исполняя их одну за другой в порядке, установленном PoH, в то время как все остальные бесконфликтные транзакции продолжают выполняться параллельно.

Этот подход представляет собой детерминированный параллелизм: Sealevel выявляет конфликты до начала исполнения, а не разрешает их по факту. Она не исполняет транзакции спекулятивно с последующим откатом в случае неудачи. Это отличает её от подходов с оптимистичным параллелизмом, таких как Aptos Block-STM, где транзакции сначала исполняются спекулятивно, а при конфликте запускаются повторно.

Sealevel также может направлять задачи по проверке подписей на ядра GPU, подобно тому как GPU выполняет тысячи расчетов шейдеров одновременно в играх или при нагрузках ИИ. Блок обработки транзакций (TPU) Solana использует конвейеризацию для одновременного запуска этапов валидации транзакций на различных аппаратных узлах, при этом Sealevel отвечает за этап исполнения в этом конвейере.

Sealevel против Ethereum EVM: Прямое архитектурное сравнение

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

Сравнение Sealevel и EVM

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

Solana компилирует программы в модифицированный байт-код eBPF (extended Berkeley Packet Filter) Solana: компактный набор инструкций, адаптированный из хорошо зарекомендовавшего себя нативного формата Linux. Sealevel исполняет этот байт-код на скоростях, близких к нативным. Байт-код EVM, напротив, работает на специализированной программно-эмулируемой виртуальной машине. Подход BPF обеспечивает возможности оптимизации на аппаратном уровне, которых нет у кастомного формата EVM, что способствует преимуществу Sealevel в пропускной способности на уровне исполнения инструкций.

Что отличает архитектуру Solana от Ethereum:

• Модель исполнения: параллельная детерминированная (Sealevel) против последовательной (EVM)
• Архитектура состояния: программы без состояния и отдельные аккаунты данных против контрактов с состоянием
• Подход к масштабированию: параллельное исполнение на L1 против L2 роллапов и шардинга
• Язык разработки: Rust против Solidity

Для понимания того, как различаются модели аккаунтов в архитектурах блокчейнов первого уровня (L1), полезно сравнить подход Solana с предварительным объявлением и другие механизмы ончейн-хранения.

Sealevel против Aptos Block-STM и Monad: отличия в подходах к параллельному исполнению

Sealevel — не единственная архитектура параллельного исполнения в эксплуатации. Сравнение её подхода с Aptos Block-STM, Monad, а также Sui раскрывает различные компромиссы, на которые идет каждый проект.

Aptos использует Block-STM (Software Transactional Memory) — подход с оптимистичным параллелизмом. Он спекулятивно исполняет транзакции параллельно без требования предварительного объявления аккаунтов, затем валидирует результаты и повторно исполняет любые транзакции, вызвавшие конфликты. Преимущество для разработчиков: нет необходимости объявлять зависимости аккаунтов во время формирования транзакции. Компромисс: рабочие нагрузки с большим количеством конфликтов вызывают повторное исполнение, что требует времени. Sealevel полностью избегает повторного исполнения, так как выявляет конфликты до запуска.

Monad нацелен на параллельное исполнение EVM с совместимостью с Ethereum Solidity. Он конвейеризирует этапы исполнения и применяет оптимистичный параллелизм поверх модели EVM. Ставка Monad заключается в том, что совместимость с EVM стоит архитектурных издержек. Sealevel сделала противоположный выбор: модель аккаунтов «с чистого листа» с более высоким чистым параллелизмом, но требующая от разработчиков принятия новой парадигмы программирования.

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

Ни один подход не является универсально превосходящим. Предварительное объявление в Sealevel создает нагрузку на разработчиков. Оптимистичная модель Block-STM несет затраты на повторное исполнение при конфликтах. Monad жертвует запасом чистой производительности ради совместимости с Solidity. Правильный выбор зависит от требований конкретного случая использования и экосистемы разработчиков, в которой уже работает команда.

Роль Sealevel в архитектуре восьми инноваций Solana

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

Архитектура Solana опирается на восемь совместно разработанных инноваций: PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, Archivers. Каждая отвечает за отдельный этап жизненного цикла транзакции. Sealevel — это уровень исполнения: двигатель, который запускает программы.

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

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

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

Остальные инновации играют вспомогательную роль. Tower BFT (механизм консенсуса Solana, оптимизированный под PoH вариант Practical Byzantine Fault Tolerance) проверяет блоки, которые Sealevel создает. Gulf Stream (протокол пересылки транзакций без мемпула) отправляет транзакции валидаторам до подтверждения блока, чтобы Sealevel мог начать обработку следующей партии, пока текущий блок финализируется. Cloudbreak (база данных аккаунтов) разработан совместно с Sealevel для поддержки одновременного чтения и записи в тысячах потоков параллельного исполнения.

Производительность в реальном мире: Что Sealevel действительно обеспечивает (и где он недотягивает)

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

Показатели пропускной способности Solana требуют внимательного изучения, поскольку общепринятое число — около 65 000 транзакций в секунду (TPS) — описывает теоретический архитектурный потолок, а не типичную производительность мейннета.

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

Показатель ~65 000 TPS реален как потолок архитектурного дизайна. Он описывает, сколько Sealevel может обработать в идеальных условиях при оптимальных профилях транзакций. Реальный показатель ниже по ряду задокументированных причин: сложность транзакций, конкуренция за доступ к аккаунтам в популярных программах и сетевые ограничения, расположенные выше Sealevel. Тем не менее, пропускная способность мейннета Solana значительно превосходит базовый уровень Ethereum, составляющий примерно 15–30 TPS (документация Ethereum Foundation).

Возможность параллельного исполнения Sealevel — это задокументированная архитектурная реальность, а не маркетинговое заявление. Теоретический показатель TPS отражает дизайн среды выполнения; реальный показатель отражает рабочую среду вокруг него.

Сетевые сбои и перегрузки: Честная оценка

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

Инцидент в сентябре 2021 года продлился около 17 часов. Ботнет, пытавшийся получить преимущество в запуске токена, перегрузил уровень приема транзакций сети спамом, что привело к его перегрузке. Значительные дополнительные сбои произошли в январе 2022 года и в нескольких точках в течение 2022 года. Это задокументированные исторические события с опубликованными отчетами по итогам расследований.

Сбои не были следствием ошибок логики параллельного исполнения Sealevel. Это были сбои инфраструктуры приема транзакций, расположенной выше Sealevel. Возможности Sealevel в 65 000 TPS описывают, сколько действительных транзакций он может обработать; это не делает сеть невосприимчивой к наводнениям транзакций. Шоссе с 100 полосами движения все равно встанет в пробку, если миллиард машин попытается одновременно въехать на съезд. Потолок обработки и устойчивость к спаму — это отдельные инженерные задачи.

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

С тех пор Solana внедрила несколько инженерных решений: протокол QUIC заменил UDP для приема транзакций (обеспечивая лучший контроль перегрузки), локальные рынки комиссий позволяют приложениям устанавливать приоритетные комиссии при нагрузке, а клиент валидатора Firedancer, разработанный Jump Crypto, как ожидается, улучшит пропускную способность и отказоустойчивость. Эти решения демонстрируют итеративное улучшение, но ни одно обновление не устраняет фундаментальное противоречие между открытым доступом к отправке транзакций и ограниченной пропускной способностью.

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

Является ли Sealevel прочным конкурентным преимуществом для Solana (SOL)?

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

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

Модель аккаунтов также создает реальные издержки при переходе для разработчиков, которые создали производственные приложения вокруг парадигмы Sealevel. Архитектуры программ, разработанные на основе предварительного объявления аккаунтов, шаблонов PDA и фреймворка разработки Anchor, не переносятся на EVM-цепочки без существенной переработки. Растущая библиотека инструментов Rust, ресурсов Anchor, услуг аудита и эталонных реализаций добавляет дальнейшую инерцию.

Аргумент против постоянной долговечности столь же реален. Aptos и Monad демонстрируют, что архитектуры параллельного исполнения могут быть построены на различных технических основах. Экосистема L2 Ethereum (Arbitrum, Optimism, Base) достигает высокой пропускной способности за счет офчейн исполнения с ончейн расчетом, что является иным путем к масштабированию, который полностью обходит ограничения Sealevel. Для многих случаев использования децентрализованных финансов (DeFi) (включая AMM и децентрализованные биржи, такие как Orca и Raydium), пропускной способности L2-роллапов достаточно без необходимости смены парадигмы Sealevel.

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

Sealevel представляет собой реальный и задокументированный архитектурный дифференциатор на базовом уровне. Его конкурентное преимущество реально, но не постоянно. Он сталкивается с давлением со стороны появляющихся параллельных цепочек и расширяющейся экосистемы L2 Ethereum. Долговечность позиции Solana зависит в равной степени от сетевых эффектов (принятие разработчиками, DeFi общая заблокированная стоимость, институциональная инфраструктура), как и от сырой технической архитектуры среды выполнения.

Для контекста позиционирования конкурентов на уровне Layer-1 в сетях блокчейнов и того, как архитектурные компромиссы проявляются в различных дизайнах L1, параллели с проектными решениями Sealevel являются поучительными.

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

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

Sealevel зависит от модели аккаунтов Solana и является частью более широкой архитектуры скорости Solana. Участники рынка могут ознакомиться со страницей цены SOL. Бессрочный контракт SOLUSDT является кредитным производным инструментом и несет риск ликвидации; он не является мерой технической производительности Sealevel.

FAQ: Параллельная обработка Sealevel в Solana

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

Что такое Sealevel в Solana?

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

Как Sealevel обеспечивает параллельную обработку транзакций?

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

Чем Sealevel от Solana отличается от Ethereum EVM?

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

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

Согласно документации Solana Labs, Solana теоретически может обрабатывать до ~65 000 TPS в идеальных условиях. На практике пропускная способность реального мейннета для транзакций, отличных от голосования, обычно составляет от 2000 до 4000 TPS, в зависимости от сложности транзакций, конкуренции за аккаунты и сетевых условий. Это остается существенно выше, чем базовая пропускная способность Ethereum, составляющая примерно 15–30 TPS.

Какой язык программирования используется для разработки на Sealevel?

Программы Solana в основном пишутся на языке программирования Rust, хотя также поддерживаются C и C++. Все программы компилируются в модифицированный формат байт-кода eBPF (extended Berkeley Packet Filter) Solana перед развертыванием ончейн. Фреймворк Anchor является широко используемым инструментом разработки на основе Rust, который абстрагирует управление аккаунтами и уменьшает количество повторяющегося кода для разработки программ Solana.

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

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

Какова связь между Proof of History и Sealevel?

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

Вывод: Что Sealevel означает для будущего Solana

Sealevel — это самый явный ответ Solana на вопрос, с которым сталкивается каждый блокчейн: как обрабатывать больше транзакций, не жертвуя безопасностью или децентрализацией?

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

Запуск клиентского программного обеспечения валидатора Firedancer и развитие конкурирующих параллельных блокчейнов, таких как Monad, обострят конкурентную картину в ближайшие годы. Актуальный вопрос заключается не в том, достижимо ли параллельное выполнение на базовом уровне. Вопрос в том, какой архитектурный подход лучше всего соответствует каждому варианту использования в масштабе.

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

• Выполнение смарт-контрактов Ethereum: 5-этапная торговая структура
• Как работают модели аккаунтов в различных архитектурах блокчейна
• Сравнение архитектур блокчейнов уровня 1: Near Protocol против FetchAI

Источники

1. Анатолий Яковенко, "Solana: новая архитектура для высокопроизводительного блокчейна v0.8.13," 2017. https://solana.com/solana-whitepaper.pdf
2. Документация для разработчиков Solana: модель программирования и модель аккаунтов. https://docs.solana.com/developing/programming-model/accounts
3. Документация по ончейн-программам Solana. https://docs.solana.com/developing/on-chain-programs/overview
4. Ethereum Foundation: документация виртуальной машины Ethereum (EVM). https://ethereum.org/en/developers/docs/evm/
5. Отчеты о сбоях сети и производительности Solana. https://solana.com/news/
6. Документация по параллельному выполнению Aptos Block-STM. https://aptoslabs.com/developer