SolanaVM Explained: Виртуальная машина Solana

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

SolanaVM (также называемая Solana Virtual Machine или SVM) — это среда выполнения блокчейна Solana: программный слой, который обрабатывает и запускает ончейн-программы. Он управляет вычислениями, обеспечивает соблюдение логики программы и фиксирует результаты в сети. SolanaVM не является отдельным продуктом или токеном; это основной движок выполнения, встроенный в протокол Solana.

Примечание к терминологии: В контексте блокчейна SVM означает Solana Virtual Machine. SVM также является сокращением от Support Vector Machine — алгоритма машинного обучения, не имеющего отношения к блокчейну. В этой статье SVM относится исключительно к Solana Virtual Machine.

Содержание: Как работает SolanaVM | SolanaVM против EVM | Разработка на SolanaVM | Многоцепное принятие | Как развивается внедрение SolanaVM | FAQ

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

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

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

Как работает SolanaVM: архитектура и модель выполнения

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

В SolanaVM смарт-контракты называются программами Solana (термин SolanaVM для смарт-контрактов). Это официальный термин Solana Foundation, а не стилистическое отличие. Разница в наименовании отражает реальное архитектурное различие. Смарт-контракты EVM хранят логику программы и данные состояния в одном и том же объекте контракта. Программы Solana являются без сохранения состояния: код программы находится в одном ончейн-аккаунте, а данные, с которыми она работает, — в отдельных аккаунтах данных. Это разделение позволяет масштабировать параллельное выполнение.

Конвейер выполнения SolanaVM проходит пять этапов:

1. Разработчик пишет программу Solana на Rust
2. Код Rust компилируется в байт-код sBPF
3. Скомпилированный байт-код развертывается как ончейн-аккаунт программы
4. Пользователь отправляет транзакцию, которая вызывает программу с данными инструкции
5. Валидаторы Solana (узлы сети, на которых работает SolanaVM) выполняют байт-код sBPF, потребляют вычислительные единицы и фиксируют результат в реестре

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

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

Что такое sBPF? Формат байт-кода SolanaVM

sBPF (Solana Berkeley Packet Filter) — это формат байт-кода, который выполняет SolanaVM: модифицированная версия набора инструкций Berkeley Packet Filter от Solana, адаптированная специально для выполнения программ блокчейна.

Когда разработчик пишет программу Solana на Rust, этот код Rust не выполняется непосредственно ончейн. Компилятор Rust переводит его в байт-код sBPF — компактный низкоуровневый формат инструкций, который движок выполнения SolanaVM может эффективно обрабатывать. Валидаторы выполняют байт-код sBPF напрямую; именно здесь на сети физически происходят вычисления.

sBPF отличается от оригинального BPF (Berkeley Packet Filter) — сетевой технологии, используемой в ядрах операционных систем для фильтрации пакетов. sBPF от Solana — это модифицированный форк, адаптированный для ограничений выполнения виртуальной машины блокчейна. Всегда используйте "sBPF", а не "BPF" отдельно, когда речь идет о формате байт-кода Solana.

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

Параллельное выполнение: как SolanaVM обрабатывает несколько транзакций одновременно

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

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

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

В результате потолок пропускной способности масштабируется вместе с аппаратным обеспечением валидаторов, а не ограничивается фиксированным последовательным узким местом. Теоретическая максимальная пропускная способность Solana достигает примерно 65 000 транзакций в секунду при оптимальных условиях, по сравнению с примерно 15–30 TPS в мейннете Ethereum (Источник: Solana Foundation, solana.com; ethereum.org, по состоянию на 1 квартал 2025 г.). Реальная пропускная способность под нагрузкой ниже для обеих сетей, при этом EVM-совместимые сети уровня 2 (L2), построенные на Ethereum, достигают значительно более высокой пропускной способности, чем сам мейннет Ethereum.

SolanaVM против EVM: сравнение двух сред исполнения

SolanaVM и виртуальная машина Ethereum (EVM) представляют собой два различных архитектурных подхода к исполнению блокчейн-программ, каждый из которых имеет измеримые компромиссы, подходящие для разных сценариев использования. Третий стандарт виртуальных машин, WebAssembly (WASM), используется в таких сетях, как NEAR Protocol и Polkadot, представляя собой архитектурный выбор, отличный как от EVM, так и от SolanaVM.

Виртуальная машина Ethereum (EVM): признанный стандарт

Виртуальная машина Ethereum (EVM), первоначально разработанная Виталиком Бутериным и командой Ethereum, является средой исполнения, общей для Ethereum и всех EVM-совместимых сетей. Полная документация по виртуальной машине Ethereum доступна на ethereum.org.

EVM обрабатывает транзакции последовательно: по одной, в строгом порядке. Каждая транзакция в блоке выполняется после завершения предыдущей. Программы пишутся на Solidity или Vyper и компилируются в опкоды EVM. Эта последовательная модель создает потолок пропускной способности, привязанный ко времени блока, а не к мощности оборудования, но она также упрощает логику состояния. В любой момент выполнения всё состояние является детерминированным и полностью согласованным.

Самым устойчивым конкурентным преимуществом EVM является её сетевой эффект. Более 100 EVM-совместимых сетей, включая Polygon, Arbitrum, Avalanche C-Chain и BNB Chain, используют один и тот же стандарт исполнения. Разработчики, изучившие Solidity, могут развертывать приложения в любой EVM-совместимой сети без переписывания кода. Эта переносимость накапливалась в течение десятилетия, создав экосистему инструментов (Hardhat, Foundry, Remix, OpenZeppelin) и сообщество разработчиков, с которыми SolanaVM еще не сравнялась по масштабу.

SolanaVM против EVM: прямое сравнение

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

Показатели TPS представляют собой теоретические максимумы при оптимальных условиях и значительно варьируются при реальной нагрузке на сеть. EVM-совместимые L2-сети достигают существенно более высокой пропускной способности, чем мейннет Ethereum. Последнее обновление: 1 квартал 2025 г. Источники: Solana Foundation (solana.com), ethereum.org.

Сетевой эффект EVM в более чем 100 сетях является её долгосрочным конкурентным преимуществом. Архитектура параллельного исполнения SolanaVM предлагает измеримые преимущества в пропускной способности для специфических высокочастотных сценариев использования, но «чистая» скорость — это лишь один из аспектов принятия решения о разработке или инвестировании.

Программы Solana против смарт-контрактов Ethereum: в чем разница?

Программы Solana (официальный термин Solana Foundation для смарт-контрактов в SolanaVM) отличаются от смарт-контрактов EVM не только названием, но и структурной архитектурой.

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

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

Разработка на SolanaVM: языки, инструменты и начало работы

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

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

Anchor Framework для разработки на Solana абстрагирует большую часть низкоуровневой сложности Rust и sBPF, функционируя аналогично Hardhat или Foundry в экосистеме EVM. Anchor обеспечивает структурированную валидацию аккаунтов, обработку ошибок и определения интерфейсов программ, значительно сокращая объем шаблонного кода, необходимого для написания корректной программы Solana. Обратите внимание, что Anchor Framework для Solana не связан с Anchor Protocol — протоколом кредитования Terra/Luna DeFi, который потерпел крах в 2022 году.

Архитектура параллельного исполнения SolanaVM делает её особенно подходящей для DeFi приложений, требующих высокой пропускной способности: ончейн-книг ордеров, движков ликвидации и программ оптимизации доходности, которым необходима низкая задержка и высокая плотность транзакций. Основные нативные для SolanaVM протоколы DeFi включают Raydium (автоматический маркет-мейкер), Jupiter (агрегатор DEX) и Kamino (оптимизация доходности). SOL можно приобрести на крупных биржах криптовалюты и использовать для оплаты вычислительных единиц при взаимодействии с программами SolanaVM.

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

Вычислительные единицы: как SolanaVM измеряет исполнение программ

Вычислительные единицы (CU) — это эквивалент газа в Ethereum для SolanaVM: единица, которая измеряет вычислительные ресурсы, потребляемые при исполнении программы Solana.

Каждая транзакция SolanaVM работает в рамках бюджета вычислительных единиц. Текущий максимум составляет 1,4 миллиона CU на транзакцию, как указано в документации Solana Foundation (Источник: docs.solana.com, по состоянию на 1 квартал 2025 г.). Программа, превысившая свой бюджет CU в середине исполнения, прерывается, и транзакция завершается ошибкой. Разработчики запрашивают конкретный лимит CU для каждой транзакции; избыточный запрос тратит потенциальные накопления на комиссиях, в то время как недостаточный запрос приводит к сбоям, которых можно было избежать.

Комиссии за транзакции в Solana оплачиваются в SOL и частично определяются потреблением CU (единиц вычислений). Базовая комиссия применяется ко всем транзакциям; опциональный рынок приоритетных комиссий позволяет пользователям платить больше, чтобы обогнать других в планировании слотов в периоды высокого спроса. Единицы вычислений функционируют аналогично газу Ethereum, поскольку оба измеряют вычислительные затраты, но система CU Solana использует базовую комиссию с фиксированной ценой вместо полностью динамического аукциона, с добавлением приоритетных комиссий поверх.

Можно ли портировать контракты EVM на SolanaVM?

Прямое портирование контрактов EVM на SolanaVM невозможно без переписывания. Программы Solana требуют Rust и байт-код sBPF, а не Solidity и опкоды EVM. Модели выполнения архитектурно достаточно различны, чтобы построчная трансляция отсутствовала.

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

SolanaVM за пределами Solana: многоцепочечное внедрение и экосистема SVM

SolanaVM работает за пределами мейннета Solana, при этом проекты уровня 2 (Layer 2) развертывают ее как автономную среду выполнения на других блокчейнах базового уровня.

Хотя SolanaVM была разработана как среда выполнения уровня 1 (Layer 1), ее внедрение проектами уровня 2 (Layer 2) знаменует собой значительную архитектурную эволюцию. Тезис о переносимости, согласно которому SolanaVM может функционировать как общий стандарт выполнения на нескольких цепочках, подобно тому, как это делает EVM, переходит от теории к практике.

Следующая таблица содержит список текущих SVM-цепочек по типу и статусу:

Последнее обновление: 1 квартал 2025 года. Проверяйте текущий статус проекта перед повторной публикацией. Источники: eclipse.xyz, документация Solana Foundation. Дополнительные SVM-роллапы находятся в разработке; эта таблица требует периодического обновления по мере развития экосистемы.

Во всех SVM-цепочках, приложения DeFi, в частности DEX, протоколы кредитования и программы оптимизации доходности, представляют собой основной вариант использования возможностей параллельного выполнения SolanaVM. Neon EVM представляет собой иное измерение роста экосистемы SVM, позволяя контрактам, совместимым с EVM, работать в SolanaVM Solana и связывая две крупнейшие экосистемы смарт-контрактов.

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

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

Эта архитектура демонстрирует, что SolanaVM может функционировать как переносимый стандарт выполнения за пределами самой сети Solana. Она следует той же архитектурной переносимости, которая позволила EVM распространиться на десятки цепочек. Развертывание Eclipse является наиболее четким текущим свидетельством тезиса о переносимости SVM.

Полные архитектурные детали можно найти в официальной документации Eclipse по адресу eclipse.xyz.

SVM-роллап (решение уровня 2, работающее на SolanaVM) — это блокчейн, который использует SolanaVM в качестве среды выполнения, отправляя данные транзакций в цепочку базового уровня для расчета и доступности данных.

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

Развертывание мейннета Eclipse представляет собой самую передовую архитектуру SVM-роллапов, находящуюся в настоящее время в эксплуатации. Дополнительные проекты SVM-роллапов находятся в разработке, хотя их статус часто меняется. Если внедрение SVM-роллапов продолжится текущей траекторией, многоцепочечное присутствие SolanaVM может приблизиться к широте внедрения EVM, хотя размер экосистемы разработчиков остается ключевым дифференцирующим фактором.

Этот раздел охватывает перспективные разработки экосистемы. Статус проектов требует периодической проверки. Последнее обновление: 1 квартал 2025 года.

Как развивается внедрение SolanaVM за пределами Solana

SolanaVM демонстрирует ранние признаки многоцепочечного внедрения, при этом такие проекты, как Eclipse, развертывают ее в качестве уровня выполнения за пределами сети Solana. Достигнет ли SolanaVM многоцепочечной стандартизации, подобной EVM, зависит от темпов внедрения разработчиками, зрелости инструментов и успеха проектов SVM-роллапов.

Доказательства растущего охвата SolanaVM бетонны. Eclipse управляет действующим мейннетом, используя SolanaVM в качестве среды выполнения на Ethereum. Проекты SVM-роллапов переходят от анонсов к активной работе. Фреймворк Anchor созрел настолько, что разработка на SolanaVM стала существенно доступнее, чем два года назад. Протоколы DeFi на Solana (Raydium, Jupiter, Kamino) демонстрируют, что архитектура параллельного выполнения SolanaVM генерирует реальную экономическую активность, а не просто теоретические показатели пропускной способности.

Препятствия столь же бетонны. EVM имеет десятилетнее преимущество в привлечении разработчиков, зрелости инструментов и многоцепочечном развертывании. Разработчик, знающий Solidity, сегодня может развернуть свой продукт на более чем 100 цепочках; разработчик, знающий Rust и Anchor Framework, может развернуть его на мейннете Solana и Eclipse, с постепенным появлением новых SVM-цепочек. Сетевой эффект EVM представляет собой реальное конкурентное преимущество, а не устаревшую уязвимость, которую SolanaVM автоматически вытесняет. Архитектура параллельного выполнения SolanaVM предлагает измеримые преимущества для высокопроизводительных сценариев использования DeFi, но техническое превосходство в одном измерении не автоматически транслируется в принятие экосистемой.

Рост внедрения SolanaVM в нативной сети Solana увеличивает спрос на SOL как на токен для оплаты комиссий за потребление единиц вычислений. SVM-цепочки, расчеты по которым происходят в других сетях (например, Eclipse, осуществляющий расчеты в Ethereum), могут использовать различные структуры комиссий; зависимость спроса на SOL варьируется в зависимости от архитектуры цепочки.

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

Траектория внедрения SolanaVM в нативной сети Solana, Eclipse и на развивающихся SVM-роллапах будет определяться как ростом сообщества разработчиков, так и архитектурными достоинствами. Архитектурный кейс для SolanaVM хорошо установлен. Кейс экосистемы все еще строится.

Изучите SOL на Bybit

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

Часто задаваемые вопросы: Объяснение SolanaVM

Что такое SolanaVM?

SolanaVM (также известная как Solana Virtual Machine или SVM) — это среда выполнения блокчейна Solana: программный уровень, который обрабатывает программы Solana и фиксирует их результаты в сети. SolanaVM не является отдельным токеном или продуктом; это основной архитектурный компонент Solana. В контексте блокчейна SVM означает Solana Virtual Machine, а не Support Vector Machine.

Чем SolanaVM отличается от EVM?

SolanaVM и виртуальная машина Ethereum (EVM) отличаются по трем основным архитектурным параметрам. Во-первых, SolanaVM обрабатывает неконфликтующие транзакции параллельно с использованием движка Sealevel; EVM обрабатывает транзакции последовательно. Во-вторых, SolanaVM выполняет байт-код sBPF, скомпилированный из Rust; EVM выполняет опкоды, скомпилированные из Solidity или Vyper. В-третьих, SolanaVM измеряет стоимость выполнения в вычислительных единицах (CU); EVM использует газ. EVM имеет значительно более крупную мультичейн-экосистему.

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

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

Является ли SolanaVM быстрее EVM?

Теоретическая максимальная пропускная способность SolanaVM достигает примерно 65 000 TPS в оптимальных условиях; мейннет Ethereum обрабатывает примерно 15–30 TPS последовательно (Источник: Solana Foundation, ethereum.org, на 1 квартал 2025 г.). Параллельное выполнение SolanaVM дает ей ощутимое преимущество в скорости для неконфликтующих рабочих нагрузок транзакций. EVM-совместимые L2-цепочки, такие как Arbitrum и Optimism, достигают показателей пропускной способности, которые значительно сокращают этот разрыв на практике.

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

sBPF (Solana Berkeley Packet Filter) — это формат байт-кода, который выполняет SolanaVM: модифицированная версия Solana набора инструкций Berkeley Packet Filter, адаптированная для выполнения блокчейн-программ. Когда разработчик пишет программу Solana на Rust, компилятор Rust преобразует ее в байт-код sBPF перед развертыванием. Валидаторы затем напрямую выполняют этот байт-код sBPF. sBPF отличается от оригинальной технологии BPF для сетей, используемой в ядрах операционных систем.

Можно ли запускать EVM-контракты на SolanaVM?

Байт-код EVM не выполняется нативно в SolanaVM, поскольку модели выполнения и учета различаются. Отдельная стороннее EVM-среда может поддерживать части рабочего процесса Solidity, в то время как нативная реализация SVM требует совместимого языка и архитектуры. Проверяйте текущую поддержку инструментов и проводите бенчмаркинг фактической рабочей нагрузки перед выбором пути.

Что такое блокчейн Eclipse и как он использует SolanaVM?

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

Что такое программы Solana?

Программы Solana — это официальный термин SolanaVM для смарт-контрактов: самоисполняемый ончейн-код, который SolanaVM обрабатывает при вызове транзакцией. В отличие от смарт-контрактов EVM, которые хранят логику и состояние в одном объекте контракта, программы Solana являются без состояний. Логика программы находится в аккаунте программы; данные, с которыми она работает, находятся в отдельных аккаунтах данных. Такая архитектура без состояний позволяет движку параллельного выполнения SolanaVM безопасно запускать несколько программ одновременно.

Что такое вычислительные единицы в Solana?

Вычислительные единицы (CU) — это эквивалент газа Ethereum в Solana: единица, измеряющая вычислительные ресурсы, потребляемые при выполнении программы Solana. Каждая транзакция SolanaVM работает в пределах бюджета CU, ограниченного 1,4 миллиона CU на транзакцию (Источник: документация Solana Foundation, docs.solana.com, на 1 квартал 2025 г.). Программы, превышающие бюджет CU, прерываются. Комиссии за транзакции в Solana оплачиваются в SOL, частично определяясь потреблением CU, с рынком приоритетных комиссий для периодов высокого спроса.

Становится ли SolanaVM новым стандартом блокчейна?

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

Связанное чтение

• Архитектура Solana
• Совместима ли Solana с EVM?
• Стандарты токенов Solana