Skip to main content

Что такое non-EVM блокчейн

Что такое non-EVM блокчейн

Non-EVM блокчейн — это любой блокчейн, который не использует виртуальную машину Ethereum в качестве движка исполнения. Вместо исполнения байт-кода Solidity non-EVM сети используют другие виртуальные машины, другие языки программирования и другие модели исполнения. Примеры: Solana (SVM/Sealevel), сети на базе Cosmos (CosmWasm, application-specific модули), NEAR (среда на базе WebAssembly), Sui и Aptos (MoveVM), а также Bittensor (кастомная среда на базе Substrate).

Различие имеет значение, поскольку выбор виртуальной машины определяет, какие языки программирования используют разработчики, как ведут себя смарт-контракты, какой инструментарий доступен и насколько легко проект может взаимодействовать с другими сетями. Проект, построенный на non-EVM сети, не может просто скопировать Solidity-контракты из Ethereum — ему нужна другая кодовая база, другие навыки разработчиков и другой набор инфраструктурных инструментов.

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

Как исполнение в non-EVM отличается от EVM

EVM — это стековая виртуальная машина, которая последовательно исполняет байт-код Solidity, использует 256-битные целые числа и измеряет вычисления через газ. Non-EVM сети отходят от этой модели различными способами:

Различные виртуальные машины

Сеть / экосистема Виртуальная машина Основной язык Ключевое архитектурное отличие
Solana SVM (Sealevel) Rust Параллельное исполнение транзакций через объявленный доступ к состоянию
Cosmos-сети CosmWasm / нативные модули Rust (CosmWasm), Go (модули) Application-specific блокчейн со встроенной межсетевой коммуникацией (IBC)
NEAR WebAssembly (Wasm) Rust, AssemblyScript Шардированное исполнение с асинхронными межшардовыми вызовами
Sui MoveVM Move Объектно-ориентированная модель состояния, обеспечивающая параллельное исполнение
Aptos MoveVM Move Движок параллельного исполнения Block-STM
Bittensor Substrate runtime Rust ИИ-ориентированная координация; subnet'ы как единицы исполнения

Каждая виртуальная машина предлагает свои компромиссы. SVM Solana требует, чтобы транзакции заранее объявляли, к какому состоянию они будут обращаться, позволяя среде исполнения параллельно обрабатывать неконфликтующие транзакции — то, чего EVM не может делать нативно. Cosmos-сети полностью отказываются от модели общего исполнения: каждое приложение получает собственную сеть с кастомной логикой, подключённую к другим сетям через протокол IBC. Сети на базе Move (Sui, Aptos) используют ресурсно-ориентированную модель программирования, предотвращающую определённые классы ошибок (например, reentrancy) на уровне языка.

Различные языки программирования

Экосистема EVM определяется Solidity — языком, спроектированным специально для смарт-контрактов Ethereum. Non-EVM сети используют языки общего назначения или специализированные альтернативы:

  • Rust — используется Solana (через фреймворк Anchor), Cosmos (через CosmWasm), NEAR и сетями на Substrate, включая Bittensor. Гарантии безопасности памяти Rust и его производительность делают его подходящим для ончейн-программ.
  • Move — изначально разработан в Facebook/Diem, теперь используется Sui и Aptos. Move трактует ончейн-активы как первоклассные ресурсы, которые невозможно дублировать или случайно уничтожить, снижая целую категорию распространённых уязвимостей смарт-контрактов.
  • Go — используется для разработки нативных модулей в Cosmos SDK. Валидаторы запускают Go-скомпилированные бинарники напрямую.
  • AssemblyScript — TypeScript-подобный язык, компилируемый в WebAssembly, используемый как альтернативный язык для разработки на NEAR.

Разнообразие языков означает, что разработчики не могут напрямую перенести навыки Solidity на non-EVM сети. Проекту, строящемуся на Solana, нужны Rust-инженеры; проекту на Sui — Move-инженеры. Пул разработчиков для каждого языка влияет на скорость создания и итерации проекта.

Различные характеристики производительности

Non-EVM сети часто достигают иных профилей производительности:

  • Параллельное исполнение — Solana, Sui и Aptos исполняют неконфликтующие транзакции параллельно, что может обеспечить более высокую пропускную способность, чем последовательная модель исполнения EVM.
  • Более низкие и предсказуемые комиссии — некоторые non-EVM сети имеют структуры комиссий, изначально спроектированные для высокой пропускной способности, избегая волатильных рынков комиссий, которые EVM-сети могут испытывать при перегрузке.
  • Кастомные модели состояния — non-EVM сети могут использовать модели состояния, оптимизированные для конкретных паттернов доступа. Объектно-ориентированная модель Sui, например, обеспечивает пообъектное владение и параллельную обработку, что было бы сложно реализовать на EVM.

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

Почему это важно для крипто-ИИ проектов

Выбор виртуальной машины имеет практические последствия для ИИ-проектов на блокчейне:

  • Гибкость исполнения — non-EVM сети могут поддерживать модели исполнения, лучше подходящие для ИИ-координации. Параллельное исполнение, кастомные конечные автоматы и менее затратные наборы инструкций могут лучше обслуживать высокочастотные ИИ-транзакции (назначение вычислительных задач, отправка результатов, обновления реестра моделей).
  • Языковое соответствие — Rust-сети хорошо сочетаются с ИИ/ML-инфраструктурой, поскольку значительная часть ИИ-инструментов (производительно-критические компоненты, координация GPU, системное программирование) написана на Rust или хорошо с ним интегрируется.
  • Application-specific дизайн — Cosmos-appchain'ы и subnet'ы Bittensor позволяют ИИ-проектам строить кастомную логику исполнения на уровне сети, без ограничений набора опкодов и газовой модели EVM.
  • Экосистемные компромиссы — non-EVM проекты не могут легко использовать большую экосистему EVM с её DeFi-протоколами, токенными мостами и кошельковой инфраструктурой. ИИ-проекты на non-EVM сетях должны либо строить эту инфраструктуру сами, либо полагаться на кросс-чейн мосты, либо принять изначально меньшую экосистему.

В карточках проектов DecAIHub Type: non-EVM говорит читателю, что проект не использует Solidity, не может быть развёрнут на EVM-совместимых сетях без переписывания и работает в другой технической экосистеме.

Где это появляется в карточках проектов DecAIHub

В карточках проектов DecAIHub обозначение non-EVM отображается в:

  • Type — non-EVM указывает, что смарт-контракты или ончейн-логика проекта используют виртуальную машину, отличную от EVM. Это влияет на применяемые инструменты, языки и стандарты.
  • Main chain — указывается конкретная non-EVM сеть (Solana, Bittensor, Cosmos-сеть, Sui и т.д.). У каждой сети своя VM, язык и экосистема.
  • Token standard — non-EVM сети имеют собственные стандарты токенов. Solana использует SPL-токены; Cosmos-сети — нативные деноминации или CW-20 (CosmWasm); сети на Move используют coin/fungible-asset ресурсы. Они не взаимозаменяемы с ERC-20.
  • Smart contracts / on-chain logic — язык программирования и фреймворк отличаются от EVM-проектов. Программы Solana пишутся на Rust (Anchor), контракты Cosmos — на Rust (CosmWasm) или Go, и так далее.

Что классификация non-EVM сама по себе не доказывает

  • Non-EVM не означает лучшую производительность. Хотя некоторые non-EVM сети предлагают параллельное исполнение или более низкие комиссии, производительность зависит от конкретной сети, её инфраструктуры валидаторов и текущей нагрузки — а не только от выбора VM.
  • Non-EVM не доказывает техническую продвинутость. Выбор non-EVM сети — это инфраструктурное решение. Оно не указывает на качество AI component проекта, его кода или продукта.
  • Non-EVM не означает, что проект не может взаимодействовать с EVM-сетями. Многие non-EVM проекты используют мосты, оракулы или обёрнутые токены для связи с Ethereum и другими EVM-экосистемами. Кросс-чейн взаимодействие возможно; оно просто требует дополнительной инфраструктуры.
  • Другая VM не означает другие гарантии безопасности. Ошибки в смарт-контрактах, логические ошибки и риски централизации существуют на всех сетях независимо от виртуальной машины. Non-EVM языки вроде Rust и Move устраняют некоторые классы ошибок, но вводят другие.
  • Метка non-EVM не объясняет, почему проект выбрал эту сеть. Выбор может быть обусловлен требованиями к производительности, экспертизой команды, экосистемными стимулами или просто тем, где основатели начали. Без дополнительного контекста метка сама по себе информативна, но не оценочна.

Не путать с

  • EVM — EVM — виртуальная машина Ethereum. Non-EVM определяется в контрасте с ней: любая сеть, не использующая EVM, попадает в категорию non-EVM.
  • Ethereum — Ethereum — оригинальная EVM-сеть. Non-EVM означает, что сеть — не Ethereum и не использует движок исполнения Ethereum, но может взаимодействовать с Ethereum через мосты или кросс-чейн протоколы.
  • Solana — Solana — один конкретный non-EVM блокчейн со своей виртуальной машиной (SVM). «Non-EVM» — широкая категория, включающая Solana, Cosmos, Sui, Aptos, NEAR, Bittensor и многие другие.
  • «Анти-Ethereum» — non-EVM — это не заявление против Ethereum. Многие non-EVM сети сосуществуют с Ethereum и выигрывают от мостовой ликвидности. Выбор VM отражает разные приоритеты проектирования, а не идеологическое противостояние.
  • Несовместимый — non-EVM сети не могут исполнять байт-код EVM нативно, но это не означает их изоляцию. Кросс-чейн мосты, протоколы обмена сообщениями (IBC, LayerZero, Wormhole) и обёрнутые токены обеспечивают совместимость между EVM- и non-EVM-экосистемами.

Часто задаваемые вопросы

Какие non-EVM сети чаще всего используются крипто-ИИ проектами?

Solana и Bittensor — среди наиболее часто встречающихся non-EVM сетей в сфере крипто-ИИ, отслеживаемой DecAIHub. Высокая пропускная способность Solana и Rust-экосистема привлекают ИИ-проекты, которым нужна быстрая и дешёвая ончейн-координация. Bittensor специально создан для децентрализованного ИИ, с subnet'ами, выделенными под конкретные ИИ-задачи. Cosmos-appchain'ы — ещё один паттерн, особенно для проектов, которым нужна полностью кастомная среда исполнения со встроенной межсетевой коммуникацией через IBC.

Может ли non-EVM проект также развернуться на EVM-сетях?

Да, но это требует отдельной кодовой базы. Проект, написанный на Rust для Solana, нельзя развернуть на Ethereum как есть — его нужно переписать на Solidity (или создать отдельную Solidity-реализацию). Некоторые проекты поддерживают контракты и на EVM, и на non-EVM сетях, но каждое развёртывание требует независимой разработки, аудита и поддержки. Кросс-чейн мосты также позволяют non-EVM проектам иметь токенное представительство на EVM-сетях (например, обёрнутые SPL-токены как ERC-20 на Ethereum).

Non-EVM лучше для ИИ-приложений?

Универсального ответа нет. Non-EVM сети могут предложить преимущества для конкретных ИИ-задач — параллельное исполнение Solana подходит для высокопроизводительной координации, subnet-архитектура Bittensor специально спроектирована для ИИ-стимулов, а Cosmos-appchain'ы допускают полностью кастомную логику исполнения. Однако EVM-сети предлагают более крупную экосистему разработчиков, более зрелый инструментарий, более глубокую DeFi-ликвидность и более широкую поддержку кошельков. Лучший выбор зависит от конкретных требований проекта: какие нагрузки работают ончейн, какая нужна производительность, какую экосистему предпочитает команда и где находятся целевые пользователи.

Есть ли у non-EVM сетей стандарты токенов, как ERC-20?

Да, но другие. Solana использует SPL-токены. Cosmos-сети используют нативные деноминации или CW-20 токены (через CosmWasm). Sui и Aptos используют ресурсы coin и fungible asset языка Move. NEAR использует NEP-141. Каждый стандарт определяет, как токены создаются, передаются и управляются на данной сети. Эти стандарты не взаимозаменяемы с ERC-20 — токен, созданный как SPL на Solana, нельзя использовать напрямую на EVM-сети без обёртки или моста.

Внешние ссылки

  • Solana documentation — Sealevel runtime — технический обзор модели параллельного исполнения Solana и разработки программ.
  • Move language documentation — спецификация и руководство разработчика по языку программирования Move, используемому Sui и Aptos.
  • Cosmos SDK documentation — официальная документация по созданию application-specific блокчейнов с кастомными модулями и интеграцией IBC.

См. также

No comments to display

Back to top