EVM vs non-EVM — cp0x learn

Концепции: EVM Compatibility, Non-EVM Chains, Move, Rust, Solidity, Contract Portability

:::section{mins=2} Что значит «EVM-совместимый» :::

:::lead Фразу «[[gloss:evm|EVM]]-совместимый» используют так, будто это однозначное свойство. Но это не свойство, а спектр, который тянется от полной байт-идентичности с [[gloss:ethereum|Ethereum]] до режима, в котором [[gloss:solidity|Solidity]] компилируется, но всё остальное устроено иначе. Три контракта, каждый из которых заявляет о [[gloss:evm|EVM]]-совместимости, могут дать тебе три совершенно разных опыта деплоя. Понимание, где на этом спектре цепочка лежит на самом деле, отличает пятиминутный передеплой от трёх недель неожиданных багов в продакшене. :::

:::p{html} [[gloss:evm|EVM]] — [[gloss:ethereum|Ethereum]] Virtual Machine — это интерпретатор байткода, который запускает каждая нода [[gloss:ethereum|Ethereum]]. Когда ты пишешь смарт-контракт на [[gloss:solidity|Solidity]] и деплоишь его, компилятор превращает твой код в строку [[gloss:evm|EVM]]-байткода, и каждая нода в сети прогоняет этот байткод опкод за опкодом на собственной копии состояния сети — и приходит к одному и тому же итоговому состоянию. [[gloss:evm|EVM]] задаёт правила [[gloss:ethereum|Ethereum]]: 256-битная стековая машина, учёт газа, детерминированные переходы состояния, никаких syscall'ов. По меркам современного дизайна VM удачной её не назовёшь — это конструкция 2014 года, которой повезло появиться первой. :::

:::p{html} Цепочка называется [[gloss:evm|EVM]]-совместимой, когда на ней работают смарт-контракты в стиле [[gloss:ethereum|Ethereum]]. В этом предложении на одно слово приходится очень много смысла. На одном конце спектра цепочка вроде Scroll исполняет ровно тот же [[gloss:evm|EVM]]-байткод, что и [[gloss:ethereum|Ethereum]], опкод в опкод, с теми же стоимостями газа и теми же [[gloss:precompile|precompile]]-контрактами: твой проаудированный [[gloss:ethereum|Ethereum]]-деплой переезжает на неё без единой строчки изменений. На другом конце цепочка вроде Polygon [[gloss:zkevm|zkEVM]] (Type 4) берёт исходник на [[gloss:solidity|Solidity]] и перекомпилирует его в нечто совершенно иное — большая часть работает, но контракт, опирающийся на конкретное поведение опкодов, может тихо сломаться. Четыре уровня этой классификации для ZK-роллапов мы разбирали в → 2.5 §4; тот же спектр применим к любой цепочке, которая называет себя [[gloss:evm|EVM]]-совместимой, не только к роллапам. :::

:::p{html} Практический вопрос для пользователя намного проще. [[gloss:evm|EVM]]-совместимая сеть значит: тот же кошелёк (MetaMask, Rabby), тот же формат адреса (знакомая hex-строка 0x...), те же токен-стандарты (ERC-20, ERC-721, ERC-1155), те же паттерны approvals и подписей. Привычная ментальная модель переносится. Non-[[gloss:evm|EVM]] значит: другой кошелёк, другой формат адреса, другая схема подписи транзакций, другая ментальная модель. Токен, перемещённый с [[gloss:ethereum|Ethereum]] в [[gloss:solana|Solana]] через мост, — это не тот же токен, а его обёрнутая версия, представленная в другой модели аккаунтов и подписанная другой кривой. :::

:::p{html} К маю 2026 года в продакшене работают десятки [[gloss:evm|EVM]]-совместимых сетей — [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]], все крупные [[gloss:layer 2|L2]] (Arbitrum, OP [[gloss:mainnet|Mainnet]], Base, Linea, Scroll, zkSync Era, Polygon [[gloss:zkevm|zkEVM]]), длинный хвост [[gloss:l1|L1]] и сайдчейнов (BNB Chain, [[gloss:avalanche|Avalanche]] C-Chain, Polygon [[gloss:proof of stake|PoS]], Sonic, Mantle) и свежая волна высокопроизводительных [[gloss:evm|EVM]] [[gloss:l1|L1]] во главе с [[gloss:monad|Monad]], чей [[gloss:mainnet|mainnet]] запустился 24 ноября 2025 года. Им противостоит значительно меньшая, но архитектурно отдельная группа non-[[gloss:evm|EVM]] сетей: [[gloss:solana|Solana]] с её runtime [[gloss:sealevel|Sealevel]], Starknet с [[gloss:cairo|Cairo]], [[gloss:aptos|Aptos]] и [[gloss:sui|Sui]] с [[gloss:move|Move]], [[gloss:ton|TON]] со своей TVM, цепочки [[gloss:cosmos|Cosmos]] с CosmWasm. Эти две группы много лет конкурировали за одних и тех же разработчиков и за одну и ту же ликвидность, и к 2026 году они выглядят уже не столько как соперники, сколько как две сближающиеся традиции — но к этому мы вернёмся в §6. :::

:::callout{icon=💡} [[gloss:evm|EVM]]-совместимость стоит представлять так, как раньше работала совместимость операционных систем на десктопах. Windows-приложение — это не просто формат файла, а целый стек ожиданий о том, как управляется память, как рисуется GUI, как выглядит файловая система, какие системные вызовы доступны. Когда говорят, что программа «Windows-совместимая», обычно имеют в виду, что она запускается на Windows. Но «Windows-совместимая» через эмулятор Wine на Linux — это уже не то же самое, что нативный Windows: большинство работает, граничные случаи ломаются, производительность другая, а программа, опирающаяся на внутренности Windows, тихо упадёт. macOS — это другая крайность: она вообще не пытается быть Windows-совместимой, у неё свой формат приложений, свои инструменты разработки, свой дизайн. Что-то выпускается на обеих, перекомпилировано под каждую. Большинство — нет. [[gloss:evm|EVM]]-совместимость устроена так же: байт-идентичное исполнение на одном конце, компиляция исходника на другом, и совсем другая ОС на стороне non-[[gloss:evm|EVM]] мира. :::

:::keypoints{label="Ключевые моменты"}

«[[gloss:evm|EVM]]-совместимый» — не бинарное свойство, а скользящая шкала. Воспринимать его как «да/нет» — именно та ошибка, из-за которой команды выпускают контракты, проходящие тесты на [[gloss:ethereum|Ethereum]] и падающие на целевой цепочке, которая «поддерживает» тот же код
Для конечного пользователя различие конкретно: [[gloss:evm|EVM]]-совместимая — это «твой уже установленный кошелёк подключится»; non-[[gloss:evm|EVM]] — это отдельный кошелёк, отдельный путь деривации из seed-фразы и отдельная ментальная модель того, что вообще значит «владеть токеном» на этой цепочке
Считать сети и считать активность — это две разные картины. В [[gloss:evm|EVM]]-мире десятки цепочек с распределённой между ними активностью; non-[[gloss:evm|EVM]]-мир — это по сути несколько концентрированных островов. Правильное сравнение — не «40 [[gloss:evm|EVM]]-цепочек против 4 non-[[gloss:evm|EVM]]», а «один [[gloss:evm|EVM]]-стек со многими деплоями против трёх-четырёх независимых экосистем, каждая из которых достаточно большая чтобы иметь значение».
Два лагеря больше не противостоят друг другу однозначно. [[gloss:evm|EVM]]-цепочки получают [[gloss:wasm|WASM]] ([[gloss:stylus|Stylus]] в Arbitrum), параллельное исполнение ([[gloss:monad|Monad]]), и серьёзное предложение от самого Виталика заменить [[gloss:evm|EVM]] на [[gloss:risc-v|RISC-V]]; non-[[gloss:evm|EVM]] сети добавляют [[gloss:evm|EVM]]-мосты и слои совместимости. Конкуренция сходится, а не расходится :::

:::details{badge=Глубже title="Уровни EVM-совместимости"} :::p{html} Самая полезная таксономия [[gloss:evm|EVM]]-совместимости — пятиуровневая, и именно разрыв между уровнями подставляет большинство команд. :::

:::p{html} Уровень 1: байт-идентичный. Цепочка исполняет ровно тот [[gloss:evm|EVM]]-байткод, который выдаёт solc, с теми же стоимостями газа, теми же [[gloss:precompile|precompile]]-контрактами и той же семантикой опкодов. Примеры: Taiko, классические [[gloss:ethereum|Ethereum]]-цепочки. Контракт, проаудированный на [[gloss:ethereum|Ethereum]], не требует повторного аудита. Цена: места для оптимизации нет, и цепочка наследует потолок производительности [[gloss:ethereum|Ethereum]]. :::

:::p{html} Уровень 2: [[gloss:evm|EVM]]-equivalent с оговорками. Цепочка исполняет [[gloss:evm|EVM]]-байткод, но с документированными отличиями — другие timestamp'ы блоков, другие источники случайности, иногда другой список [[gloss:precompile|precompile]]. Примеры: Arbitrum, Base, OP [[gloss:mainnet|Mainnet]], Scroll. Большинство контрактов переезжают без правок, но код, зависящий от гранулярности [[gloss:block|block]].timestamp, от blockhash или от chain-специфичных [[gloss:precompile|precompile]], нужно тестировать. Отличия документированы и широко известны. :::

:::p{html} Уровень 3: [[gloss:evm|EVM]]-совместимый на уровне исходника. [[gloss:solidity|Solidity]] компилируется, но базовая VM другая. [[gloss:storage layout|Storage layout]] может не совпадать, стоимости газа совсем другие, часть опкодов отсутствует или ведёт себя иначе. Примеры: zkSync Era, Polygon [[gloss:zkevm|zkEVM]]. Большая часть [[gloss:solidity|Solidity]] работает; assembly-блоки, глубокие оптимизации и код, зависящий от [[gloss:storage layout|storage layout]], — нет. Обычно нужен повторный аудит. :::

:::p{html} Уровень 4: [[gloss:solidity|Solidity]]-transpiled. [[gloss:solidity|Solidity]] перекомпилируется в non-[[gloss:evm|EVM]] байткод для исполнения на non-[[gloss:evm|EVM]] VM. Пример: [[gloss:neon evm|Neon EVM]] в [[gloss:solana|Solana]]. Обещание — «деплой свой [[gloss:ethereum|Ethereum]]-контракт на [[gloss:solana|Solana]]»; реальность — «принимаем твой [[gloss:solidity|Solidity]], но исполняем его в песочнице, которая транслирует вызовы в [[gloss:svm|SVM]]». Работает для многих контрактов, ломается на всём, что трогает специфичное поведение [[gloss:ethereum|Ethereum]]. :::

:::p{html} Уровень 5: non-[[gloss:evm|EVM]] вообще. Другой язык, другая VM, другая модель аккаунтов. Примеры: нативные программы [[gloss:solana|Solana]], [[gloss:move|Move]] в [[gloss:aptos|Aptos]]/[[gloss:sui|Sui]], [[gloss:cairo|Cairo]] в Starknet. Прямого пути задеплоить [[gloss:solidity|Solidity]]-контракт нет. Либо переписываешь, либо не выходишь на эту цепочку. :::

:::p{html} Итог. Маркетинговая страница всегда подразумевает Уровень 1 или 2. Реальность часто — Уровень 3. Разрыв между Уровнем 2 и Уровнем 3 может стоить команде нескольких недель работы по портированию (перенос контракта с одной [[gloss:evm|EVM]]-цепочки на другую с поправками на их различия) и целого цикла повторного аудита. Лучшее место, где имеет смысл выяснить, к какому уровню относится целевая цепочка, — стадия её выбора, а не момент, когда контракт уже наполовину переписан. ::: :::

:::quiz{id=q-2-6-s1 correct=1 explanation="Верно. zkSync Era — цепочка Уровня 3: [[gloss:solidity|Solidity]] компилируется, но базовая VM достаточно отличается, чтобы [[gloss:storage layout|storage layout]], стоимости газа и детали уровня опкодов ломали что-то неочевидным образом. Большинство production-команд рассматривают деплой на zkSync как повод для повторного аудита."} У команды есть [[gloss:solidity|Solidity]]-контракт, проаудированный на [[gloss:ethereum|Ethereum]], и она хочет задеплоить его на zkSync Era. Чего ожидать?

Деплой в один клик — zkSync исполняет тот же [[gloss:evm|EVM]]-байткод, аудит переходит напрямую
Большинство [[gloss:solidity|Solidity]] сработает, но [[gloss:storage layout|storage layout]], assembly-блоки и логика, зависящая от стоимостей газа, потребуют повторного тестирования и, скорее всего, нового аудита
Контракт нужно полностью переписать на Rust, потому что zkSync — non-[[gloss:evm|EVM]] цепочка
zkSync принимает только Yul, поэтому команде нужно извлечь промежуточное представление Yul из solc :::

:::section{mins=2} EVM-мир: один Solidity, десятки сетей :::

:::lead Главное преимущество [[gloss:evm|EVM]] — не техническое превосходство, а накопленный за десять лет стек инструментов, аудитов, конвенций и общих ментальных моделей, который вырос поверх неё. Каждая новая [[gloss:evm|EVM]]-цепочка получает весь этот стек бесплатно; каждая non-[[gloss:evm|EVM]] сеть вынуждена строить свою версию с нуля. К 2026 году в [[gloss:evm|EVM]]-стеке всё ещё больше разработчиков, чем у любого отдельного конкурента, но его доля уверенно падает шесть лет подряд, и один из трёх крипто-разработчиков сейчас одновременно работает в нескольких цепочках на разных VM. :::

:::p{html} Сетевой эффект [[gloss:evm|EVM]] хорошо виден в цифрах. Отчёт Electric Capital за 2024 год насчитал 8 925 активных разработчиков в широком [[gloss:evm|EVM]]-стеке — [[gloss:solidity|Solidity]], Foundry, Hardhat, OpenZeppelin, обозреватели семейства Etherscan, вся экосистема целиком. Следующий по размеру стек — [[gloss:svm|SVM]] от [[gloss:solana|Solana]] — насчитал 2 499. Если сложить все non-[[gloss:evm|EVM]] цепочки вместе, включая [[gloss:cosmos|Cosmos]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]], Starknet, [[gloss:ton|TON]], Near и весь длинный хвост, [[gloss:evm|EVM]]-стек всё равно оказывался примерно вчетверо больше. К отчёту 2025 года один только [[gloss:ethereum|Ethereum]] показал 31 869 активных разработчиков; [[gloss:solana|Solana]] как вторая по размеру экосистема — 17 708. :::

:::p{html} Что эта цифра скрывает — это тренд. Доля [[gloss:ethereum|Ethereum]] среди всех активных блокчейн-разработчиков составляла около 82% в 2020 году. К 2025 году она опустилась до 31% — падение на 51 процентный пункт за шесть лет. Снижение не из-за того, что разработчики уходили из крипты: общее число активных [[gloss:blockchain|blockchain]]-разработчиков выросло. Дело в том, что новые разработчики всё чаще начинают не с [[gloss:ethereum|Ethereum]]. Среди профессиональных разработчиков доля [[gloss:solana|Solana]] за тот же период выросла с 5% до 20%. И примерно один из трёх крипто-разработчиков сейчас одновременно контрибьютит в проекты на разных цепочках, что значит: вопрос «в каком стеке ты работаешь» имеет всё менее бинарный ответ. :::

:::p{html} Для практикующего разработчика преимущество [[gloss:evm|EVM]] конкретно. [[gloss:solidity|Solidity]] компилируется один раз, и тот же артефакт деплоится на десятки сетей. Те же интеграции кошельков работают везде. Одни и те же аудит-фирмы видели одни и те же паттерны тысячи раз — [[gloss:evm|EVM]]-специализированных аудит-фирм сотни; для [[gloss:move|Move]] их десятки, для [[gloss:cairo|Cairo]] единицы. Библиотека OpenZeppelin проверена в боях на каждом крупном [[gloss:evm|EVM]]-чейне. Обозреватели в стиле Etherscan существуют для каждой [[gloss:evm|EVM]]-сети в той или иной форме. Один и тот же Foundry-тест, который ловит баг на [[gloss:ethereum|Ethereum]], ловит его и на Base. Ничего из этого не верно за пределами [[gloss:evm|EVM]]-мира. :::

:::p{html} Расплата за это — сама [[gloss:evm|EVM]] почти не улучшилась. Байткод, исполняющийся на Base в мае 2026 года, — фундаментально та же система команд, которая работала на [[gloss:ethereum|Ethereum]] в 2015-м, с несколькими новыми опкодами по краям. 256-битные слова — это перерасход почти для всего, что не является хешем или подписью. Учёт газа многословный и хрупкий. Главное практическое ограничение — строго последовательное исполнение. Именно из-за него [[gloss:monad|Monad]] три года проектировал [[gloss:evm|EVM]]-совместимую цепочку, которая исполняет транзакции параллельно. К самой [[gloss:evm|EVM]] накопилось и больше претензий — настолько, что заменить её на [[gloss:risc-v|RISC-V]] предложил сам Виталик (подробнее в §6). Тот же сетевой эффект, который позволяет тысяче цепочек пользоваться одной аудит-экосистемой, одновременно привязывает их все к десятилетнему дизайну. :::

:::callout{icon=💡} Английский в международной авиации работает по тому же принципу. Это не лучший язык для задачи — он полон идиом, неоднозначностей и созвучных слов с разным смыслом, которые приводили к реальным авариям. Есть языки с более чистой фонетической структурой, лучшей системой времён, меньшей двусмысленностью. Ничего из этого не важно. К 1950-м английский уже был дефолтом для авиадиспетчерской службы, и как только целое поколение пилотов, диспетчеров, инструкций, учебных программ, регуляторных документов и аварийных протоколов стандартизировалось на нём, переход стал невозможен. Новые пилоты во всех странах учат английский не потому, что он лучше, а потому что все остальные уже на нём говорят. Языки получше существуют. Просто на них никто не летает. [[gloss:evm|EVM]] находится ровно в этой позиции: технические ограничения реальны, сетевой эффект гораздо сильнее, и стоимость перехода растёт с каждым годом, пока весь остальной стек продолжает накапливаться поверх. :::

:::keypoints{label="Ключевые моменты"}

Сетевой эффект [[gloss:evm|EVM]] держится не на самом языке [[gloss:solidity|Solidity]], а на инфраструктуре вокруг него — то, что новая цепочка получает бесплатно, конкуренту приходится строить с нуля и без шансов догнать.
Доминирование [[gloss:evm|EVM]] реально, но не вечно: доля падает шестой год подряд, и мультичейн-разработка из исключения превратилась в норму.
[[gloss:evm|EVM]] выигрывает не дизайном, а инерцией. Технически она хуже большинства новых VM, но накопленный стек делает любую замену нерентабельной, пока речь не идёт о критическом узком месте.
Последовательное исполнение — то самое узкое место, которое оправдывает выход из [[gloss:evm|EVM]]. Если твоему приложению оно не критично, потеря [[gloss:evm|EVM]]-стека почти всегда дороже, чем выигрыш от другой VM. :::

:::details{badge=Глубже title="Проблема фрагментации внутри EVM"} :::p{html} Сетевой эффект [[gloss:evm|EVM]] делает запуск любой отдельной цепочки проще, но получившуюся экосистему — экономически тяжелее в использовании. К маю 2026 года активных [[gloss:layer 2|L2]] примерно 40, не считая [[gloss:evm|EVM]]-[[gloss:l1|L1]], и один и тот же токен — USDC, USDT, [[gloss:ethereum|ETH]] — существует на каждом из них как отдельный ончейн-объект. Native USDC на [[gloss:ethereum|Ethereum]], native USDC на Base и обёрнутый USDC на Polygon — это три разных ERC-20 контракта с тремя разными адресами, и реестры между ними автоматически не сводятся. :::

:::p{html} Практическое следствие — разделённая ликвидность. Самый глубокий пул USDC/[[gloss:ethereum|ETH]] на Uniswap V3 живёт на [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] — отсюда идёт институциональное ценообразование. Пул второго уровня живёт на Base. Третьего — на Arbitrum. Тот же токен, тот же протокол, три отдельных пула с отдельными fee-tier'ами, отдельными диапазонами и отдельными маркет-мейкерами. Сделка на $50 миллионов обязана идти на [[gloss:l1|L1]]; сделка на $50 может идти куда угодно. Всё, что между, — задача маршрутизации. :::

:::p{html} Стандартные ответы на эту проблему — это [[gloss:intent-based|intent-based]] мосты (Across, Eco Portal — разобрано в → 2.5 §7), слои объединённой ликвидности (Stargate), протоколы абстракции цепочки (NEAR Intents, Particle, Connext) и всё чаще [[gloss:account abstraction|account abstraction]] поверх, чтобы пользователь вообще не видел маршрута. [[gloss:native interop|Native interop]] в [[gloss:superchain|Superchain]] — когда он выйдет — это ставка на то, что ответ лежит в общей инфраструктуре уровня протокола, а не в обходных решениях уровня приложения. Ни одно из этих решений не существует на уровне [[gloss:l1|L1]] в [[gloss:evm|EVM]]-монокультуре; всё это надстройки. :::

:::p{html} В non-[[gloss:evm|EVM]] мире этой конкретной проблемы нет. У [[gloss:solana|Solana]] одна цепочка. У [[gloss:aptos|Aptos]] одна. У [[gloss:sui|Sui]] одна. Ликвидность концентрируется по умолчанию, потому что фрагментировать её просто некуда. Цена концентрации — [[gloss:solana|Solana]] нельзя разделить на [[gloss:solana|Solana]]-[[gloss:layer 2|L2]] + [[gloss:solana|Solana]]-[[gloss:l3|L3]] + [[gloss:solana|Solana]]-L4 так же, как разделили [[gloss:ethereum|Ethereum]]: для non-[[gloss:evm|EVM]] монолитов нет [[gloss:layer 2|L2]]-истории, кроме нескольких вроде [[gloss:eclipse|Eclipse]], пытающихся положить [[gloss:svm|SVM]] поверх [[gloss:data availability|data availability]] [[gloss:ethereum|Ethereum]]. :::

:::p{html} Итог. Победа сетевого эффекта [[gloss:evm|EVM]] была одновременно её проблемой фрагментации. У монолитных non-[[gloss:evm|EVM]] сетей вся активность в одном месте — но и аудиторов, инструментов и разработчиков значительно меньше. У [[gloss:evm|EVM]]-стека огромная экосистема инструментов и людей — но ликвидность размазана между десятками цепочек, и каждый переход стоит транзакции через мост. На 2026 год ни одна сторона этот размен полностью не решила. ::: :::

:::quiz{id=q-2-6-s2 correct=2 explanation="Верно. Сетевой эффект [[gloss:evm|EVM]] — это не сама VM, а накопленный стек: аудит-фирмы, контракты OpenZeppelin, тесты в Foundry, обозреватели в стиле Etherscan, кошельки и разработческие конвенции. Новую цепочку можно форкнуть с [[gloss:evm|EVM]] за выходные; воспроизвести стек — за десятилетие. D на самом деле противоположен правде: [[gloss:evm|EVM]] — один из худших форматов для ZK proving, что и мотивирует предложение про [[gloss:risc-v|RISC-V]] в §6."} Почему [[gloss:evm|EVM]] продолжает доминировать, хотя её архитектура считается устаревшей?

[[gloss:solidity|Solidity]] — уникально хорошо спроектированный язык, который конкуренты не могут воспроизвести
Капитализация [[gloss:ethereum|Ethereum]] вынуждает остальные цепочки копировать её VM по регуляторным причинам
Экосистема [[gloss:evm|EVM]] из аудит-фирм, библиотек, инструментов и конвенций, накопленная за десять лет, незаменима — байткод устарел, а стек поверх него — нет
[[gloss:evm|EVM]]-байткод — единственный формат, который ZK-роллапы могут эффективно доказывать :::

:::section{mins=2} Non-EVM: SVM, Cairo, Move, и зачем они нужны :::

:::lead Каждая non-[[gloss:evm|EVM]] виртуальная машина в продакшене существует потому, что одно конкретное свойство [[gloss:evm|EVM]] не подходило для того, что цепочка хотела делать. [[gloss:svm|SVM]] в [[gloss:solana|Solana]] проектировалась так, чтобы запускать тысячи транзакций параллельно, а [[gloss:evm|EVM]] этого не умеет. [[gloss:cairo|Cairo]] в Starknet проектировался дешёвым для ZK-доказательства, тогда как у [[gloss:evm|EVM]] это дорого. [[gloss:move|Move]] проектировался так, чтобы делать целые категории багов смарт-контрактов невозможными на уровне типов; у [[gloss:evm|EVM]] такого режима нет. Цепочки конкурируют не на «лучшем блокчейне» — каждая делает свою ставку на то, какое свойство было настолько важным, чтобы ради него отказаться от [[gloss:evm|EVM]]-стека. :::

:::p{html} [[gloss:svm|SVM]] ([[gloss:solana|Solana]] Virtual Machine) архитектурно дальше всего от [[gloss:evm|EVM]] и одновременно самая успешная non-[[gloss:evm|EVM]] ставка по любым метрикам, кроме возраста. Определяющий выбор — параллелизм: каждая транзакция [[gloss:solana|Solana]] заранее декларирует, какие аккаунты она будет читать и в какие будет писать, и runtime [[gloss:sealevel|Sealevel]] использует эту декларацию, чтобы планировать неконфликтующие транзакции параллельно по всем доступным CPU-ядрам. [[gloss:evm|EVM]] так не может, потому что [[gloss:solidity|Solidity]]-контракты не декларируют доступ к состоянию заранее — перевод может затронуть один аккаунт, а может сотню, и узнаёшь ты это только в момент исполнения. Этот дизайн-выбор мы разбирали в → 2.3; для VM-сравнения важно, что вся модель программирования отличается от [[gloss:evm|EVM]]-овской. Здесь нет «адреса контракта со storage-слотами»; здесь есть программа (неизменяемый код) и отдельный аккаунт (изменяемое состояние), и одна программа может действовать на множество аккаунтов. Именно поэтому [[gloss:solidity|Solidity]]-разработчик не может просто «задеплоить на [[gloss:solana|Solana]]», не освоив новую ментальную модель. :::

:::p{html} [[gloss:cairo|Cairo]] (Starknet) сделал противоположный выбор: спроектировать VM вокруг ограничения, что всё, что она исполняет, в конечном счёте будет доказано через [[gloss:stark|STARK]]. [[gloss:evm|EVM]] мучительна для доказательства: её 256-битные операции, динамические стоимости газа и stateful опкоды создают огромные доказательные схемы, и измерения Succinct показывают, что ~59% времени proving у [[gloss:zkevm|zkEVM]] тратится на симуляцию исполнения [[gloss:evm|EVM]]. [[gloss:cairo|Cairo]] построили с нуля вокруг алгебраических операций в поле, которые чисто ложатся на [[gloss:stark|STARK]]-ограничения. Цена: ни [[gloss:solidity|Solidity]], ни эквивалента OpenZeppelin той же зрелости нет, а разработчиков на [[gloss:cairo|Cairo]] тысячи, а не десятки тысяч. Преимущество: proving-инфраструктура Starknet опережает любой [[gloss:zkevm|zkEVM]] на годы по эффективности, и Starknet первым из крупных [[gloss:layer 2|L2]] децентрализовал свой секвенсер (это мы разбирали в → 2.5 §4). :::

:::p{html} [[gloss:move|Move]] ([[gloss:aptos|Aptos]], [[gloss:sui|Sui]], [[gloss:movement|Movement]]) сделал ещё один отдельный выбор: спроектировать язык вокруг safety на уровне ресурсов. В [[gloss:solidity|Solidity]] баланс токена — это просто число в mapping, и ничто в языке не запрещает скопировать его, отправить тот же баланс дважды или потерять учёт владельца; эти свойства приходится обеспечивать аккуратным кодом и аудитом. В [[gloss:move|Move]] токен — это ресурс, значение с линейной семантикой типов, которое компилятор отказывается копировать или отбрасывать. Его можно переместить, можно сохранить, можно явно уничтожить — но случайно дублировать не получится. Целые категории багов, обошедшихся [[gloss:evm|EVM]]-миру в сотни миллионов долларов ([[gloss:reentrancy|reentrancy]], double-spend через [[gloss:reentrancy|reentrancy]], integer overflow в арифметике балансов), в [[gloss:move|Move]] невозможно написать. Цена — самый маленький пул разработчиков из трёх: у [[gloss:sui|Sui]] было 954 активных разработчика в месяц в Q1 2026, у [[gloss:aptos|Aptos]] — 465, против десятков тысяч в [[gloss:evm|EVM]]-стеке. :::

:::p{html} Ещё две non-[[gloss:evm|EVM]] ставки заслуживают упоминания, потому что показывают тот же паттерн под другим углом. [[gloss:ton|TON]] (блокчейн Telegram) сделал ставку на асинхронную передачу сообщений: контракты в [[gloss:ton|TON]] не вызывают друг друга синхронно, а отправляют сообщения, которые обрабатываются в следующих блоках. Это упрощает параллелизм, но сильно усложняет привычную для разработчика модель, а экономика [[gloss:ton|TON]] (которую мы разбирали в → 2.4 §5) сильно опирается на Telegram-нативное распространение, а не на [[gloss:evm|EVM]]-инструменты. CosmWasm (Osmosis, Injective и большинство остальных цепочек [[gloss:cosmos|Cosmos]]) пошёл другим путём: взять готовую хорошо спроектированную VM ([[gloss:wasm|WebAssembly]]), обернуть её правильными host-функциями и опираться на модульность [[gloss:cosmos|Cosmos]] SDK для всего остального. Размен почти всегда один и тот же — получаешь свойство, которого у [[gloss:evm|EVM]] нет, теряешь доступ к [[gloss:evm|EVM]]-стеку. :::

:::callout{icon=💡} Подумай про ножевой блок в серьёзной кухне. Там всегда есть поварской нож — большое универсальное лезвие, которое тянет 80% работы. Им можно нарезать лук, можно разделать курицу, можно порубить зелень. Он не оптимален ни для одной конкретной задачи, но достаточен почти для всего, поэтому его и держит каждая кухня и на нём учится каждый повар. [[gloss:evm|EVM]] в мире VM для смарт-контрактов работает точно так же. Дальше идут специализированные клинки: янаги для одного чистого среза сырой рыбы, который поварской нож разорвёт; топорик для разруба кости, на котором обычное лезвие выщербится; нож для очистки фруктов, для которого поварской слишком велик. Каждый из них значительно лучше поварского ножа на своей конкретной задаче и бесполезен для остального. [[gloss:svm|SVM]] построен под параллелизм так же, как янаги под один решительный срез. [[gloss:move|Move]] построен под safety на уровне ресурсов так же, как топорик под один конкретный удар. [[gloss:cairo|Cairo]] построен под ZK proving так же, как нож для очистки под тонкую работу. В профессиональной кухне есть все они; у домашнего повара только поварской нож. Большинство блокчейн-команд — это домашние повара. :::

:::keypoints{label="Ключевые моменты"}

Три non-[[gloss:evm|EVM]] в продакшене не конкурируют друг с другом — они занимают разные ниши: [[gloss:svm|SVM]] закрывает параллелизм, [[gloss:cairo|Cairo]] закрывает ZK-эффективность, [[gloss:move|Move]] закрывает safety на уровне типов. Это сегментация рынка, а не три попытки заменить [[gloss:evm|EVM]].
[[gloss:move|Move]] превращает безопасность контрактов из работы аудитора в работу компилятора. Целые категории [[gloss:evm|EVM]]-уязвимостей в нём не существуют не потому что их забыли написать, а потому что система типов отказывается их компилировать.
Чем сильнее VM специализирована — тем меньше у неё разработчиков. Это не баг, а следствие самой стратегии: узкий пул людей вокруг конкретного преимущества сильнее широкого пула вокруг компромисса.
Правильный вопрос при выборе VM — не «какая лучше», а «какое узкое место [[gloss:evm|EVM]] критично именно для меня». Если ни одно из трёх (параллелизм, ZK-эффективность, type-safety) не блокирует приложение — выходить из [[gloss:evm|EVM]]-стека невыгодно. :::

:::details{badge=Глубже title="Ресурсы Move подробнее"} :::p{html} Ресурсная модель [[gloss:move|Move]] заслуживает более пристального взгляда, потому что это самый чистый пример safety на уровне языка из всех production-платформ смарт-контрактов. :::

:::p{html} В [[gloss:solidity|Solidity]] баланс ERC-20 — это число, хранящееся в mapping. Правила задаёт контракт: balances[from] -= amount; balances[to] += amount; для перевода. Если разработчик забыл сначала проверить, что balances[from] >= amount, [[gloss:integer underflow|integer underflow]] может намайнить токены из воздуха. Если функция transfer вызывает внешний контракт до обновления баланса, [[gloss:reentrancy|reentrancy]]-атака может вычерпать контракт. Эти баги ловятся аудитом, Slither'ом, внимательным code review — но это синтаксически валидный [[gloss:solidity|Solidity]]. Компилятор пропускает такой код молча. :::

:::p{html} В [[gloss:move|Move]] токен — это не число в таблице, а объект в памяти, с которым язык обращается как с физической вещью. Если у тебя в кошельке есть Coin стоимостью 100, это тот самый Coin, а не запись о нём в чьей-то таблице. Когда ты передаёшь его кому-то, у тебя его больше нет — ровно так же, как при передаче монеты из руки в руку. На уровне синтаксиса это выглядит так: :::

:::p{html} Здесь Coin — это тип объекта, value: u64 — его внутреннее поле (число до 2⁶⁴), а маркер has store сообщает компилятору, что объекты этого типа разрешено сохранять в постоянной памяти блокчейна. :::

:::p{html} Дальше работает то, ради чего всё это было придумано — линейная типизация: каждый такой объект должен быть использован ровно один раз. Это даёт три гарантии, которые компилятор проверяет автоматически: :::

:::p{html}

Нельзя продублировать. У тебя не может быть двух переменных, ссылающихся на один и тот же Coin. Попытка скопировать его — ошибка компиляции, а не runtime-баг.
Нельзя потерять. Coin не может «протухнуть» (выйти за границы функции) без явного решения, что с ним делать — сохранить в чьём-то аккаунте или явно уничтожить. Забыть про него нельзя.
Нельзя подделать. Создать новый Coin может только тот модуль, который его определил. Чужой код такого права не имеет.

:::

:::p{html} Компилятор отказывается собирать программу, которая нарушает любое из этих правил. :::

:::p{html} Практический эффект огромен для тех багов, с которыми [[gloss:evm|EVM]]-мир борется десять лет. [[gloss:reentrancy|Reentrancy]] работает в [[gloss:solidity|Solidity]] потому, что состояние может быть несогласованным между началом и концом функции: баланс может быть 100 при входе и 0 при выходе, и внешний вызов в середине функции может выполниться, пока баланс ещё 100. В [[gloss:move|Move]] сам акт перевода ресурса удаляет его у отправителя атомарно — на уровне типов; нет «переменной баланса», которая может быть несогласованной. Double-spend через [[gloss:reentrancy|reentrancy]] в [[gloss:move|Move]] не просто сложно написать — это невозможно выразить в синтаксисе языка. :::

:::p{html} Цена этой безопасности — две вещи. Первая: ментальная модель непривычная для [[gloss:solidity|Solidity]]-разработчика — ты перестаёшь думать о «балансах» и начинаешь думать об «объектах, которые перемещаются». Вторая: экосистема значительно меньше. У [[gloss:move|Move]] есть инструменты формальной верификации ([[gloss:move prover|Move Prover]]), которых нет у [[gloss:evm|EVM]], и контракты на [[gloss:aptos|Aptos]] можно машинно проверить на свойства безопасности, но число формально верифицированных контрактов измеряется десятками. Число аудированных [[gloss:evm|EVM]]-контрактов — сотнями тысяч. :::

:::p{html} Итог. [[gloss:move|Move]] доказывает, что целые категории багов можно устранить на уровне языка — это не маркетинговое заявление, а свойство системы типов. Стоит ли это того, чтобы отказаться от [[gloss:evm|EVM]]-экосистемы, зависит от того, что ты строишь. Для высокоценных [[gloss:defi|DeFi]]-примитивов, где один [[gloss:reentrancy|reentrancy]]-баг стоит миллионов, аргумент сильнее всего. Для всего остального — размен сложнее обосновать. ::: :::

:::quiz{id=q-2-6-s3 correct=3 explanation="Верно. [[gloss:reentrancy|Reentrancy]] в [[gloss:solidity|Solidity]] эксплуатирует разрыв между «баланс был 100» и «баланс стал 0»: внешний вызов в середине функции может выполниться со старым значением. В [[gloss:move|Move]] сам акт перевода ресурса удаляет его у отправителя атомарно на уровне типов, и промежуточного несогласованного состояния просто нет. A и B неверны ([[gloss:move|Move]] разрешает внешние вызовы и не имеет специального «guard»); C неверно, потому что Prover — это опциональный инструмент, а не структурная защита."} Почему [[gloss:reentrancy|reentrancy]]-атаку структурно невозможно написать в [[gloss:move|Move]]?

У [[gloss:move|Move]] встроенный [[gloss:reentrancy|reentrancy]]-guard, который автоматически блокирует каждую функцию
[[gloss:move|Move]] не позволяет внешние вызовы контрактов, поэтому никакой callback не может повторно войти
[[gloss:move prover|Move Prover]] автоматически детектит все [[gloss:reentrancy|reentrancy]]-паттерны и отклоняет деплой
В [[gloss:move|Move]] нет «переменной баланса», которая могла бы быть в несогласованном состоянии — токен это ресурс, который перемещается атомарно на уровне типов, и нет промежуточного состояния, которое можно эксплуатировать :::

:::section{mins=1} Что это значит для пользователя :::

:::lead Для того, кто просто держит крипту и пользуется dApp'ами, различие [[gloss:evm|EVM]] vs non-[[gloss:evm|EVM]] проявляется в трёх конкретных местах: какой кошелёк ты ставишь, как выглядит твой адрес, и что происходит, когда ты пытаешься переместить токен между двумя мирами. Первые два — мелкое трение. Третье место — где ушло большинство реальных денег в хаках мостов за последние четыре года. :::

:::p{html} Внутри [[gloss:evm|EVM]]-мира пользовательский опыт действительно унифицирован. Один раз ставишь Rabby или MetaMask и пользуешься [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]], всеми крупными [[gloss:layer 2|L2]], любым [[gloss:evm|EVM]]-[[gloss:l1|L1]] и любым сайдчейном с той же seed-фразой, тем же приватным ключом и тем же адресом. Твой кошелёк в Arbitrum — это тот же адрес, что и в Base, в BNB Chain, в [[gloss:avalanche|Avalanche]]. Транзакции подписываются одной и той же [[gloss:ecdsa|ECDSA]]-подписью на [[gloss:secp256k1|secp256k1]] независимо от того, на какую [[gloss:evm|EVM]]-сеть направлена транзакция. Балансы видны в одних и тех же обозревателях семейства Etherscan (Arbiscan, BaseScan, BscScan, Snowtrace), с той же раскладкой и теми же полями. :::

:::p{html} Шаг в non-[[gloss:evm|EVM]] означает отдельный кошелёк под каждую экосистему. Phantom для [[gloss:solana|Solana]]. Argent или Braavos для Starknet. Petra или Pontem для [[gloss:aptos|Aptos]]. Suiet или Surf для [[gloss:sui|Sui]]. Keplr для [[gloss:cosmos|Cosmos]]. Tonkeeper для [[gloss:ton|TON]]. У каждой свой формат адреса: [[gloss:solana|Solana]] использует 32-байтовые base58 строки (около 44 символов, без «0x»), [[gloss:cosmos|Cosmos]] — bech32 с chain-специфичными префиксами (cosmos1..., osmo1..., inj1...), [[gloss:aptos|Aptos]] и [[gloss:sui|Sui]] — 32-байтовый hex (0x плюс 64 символа, вдвое длиннее [[gloss:evm|EVM]]), [[gloss:ton|TON]] — base64-кодированные строки с префиксами EQ/UQ. И у каждой своя схема подписи: [[gloss:secp256k1|secp256k1]] [[gloss:ecdsa|ECDSA]] в [[gloss:evm|EVM]], [[gloss:ed25519|Ed25519]] в [[gloss:solana|Solana]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]], [[gloss:secp256k1|secp256k1]] в [[gloss:cosmos|Cosmos]], но на другом пути деривации, [[gloss:ed25519|Ed25519]] в [[gloss:ton|TON]]. :::

:::p{html} История с форматом адреса — не просто эстетика. Одна seed-фраза порождает разные адреса на каждой цепочке потому, что путь деривации разный: [[gloss:bip-44|BIP-44]] описывает структуру «purpose / coin type / account / change / address index», и именно поле coin type отличает [[gloss:evm|EVM]] (60) от [[gloss:solana|Solana]] (501), от [[gloss:cosmos|Cosmos]] (118), от [[gloss:aptos|Aptos]] (637). Один мнемоник, двенадцать разных адресов на двенадцати разных цепочках. Один и тот же приватный ключ не может подписать транзакции и для [[gloss:evm|EVM]], и для [[gloss:solana|Solana]], потому что эллиптическая кривая разная ([[gloss:secp256k1|secp256k1]] vs [[gloss:ed25519|Ed25519]]), и адреса, выведенные из одной seed-фразы на двух цепочках, не имеют между собой никакой ончейн-связи. Мультичейн-кошельки вроде Backpack, OKX или Trust [[gloss:wallet|Wallet]] кладут поверх этих отдельных деривацій единый UI; это помогает, но не меняет того факта, что у тебя несколько отдельных ончейн-идентичностей. :::

:::p{html} Реальная цена проявляется на границе. Переместить USDC с [[gloss:ethereum|Ethereum]] в [[gloss:solana|Solana]] — это не «отправить на адрес»: нет такой транзакции в [[gloss:ethereum|Ethereum]], которая бы породила native USDC в [[gloss:solana|Solana]], потому что у двух цепочек нет общего состояния. Либо идёшь через Circle [[gloss:cctp|CCTP]] (сжигаешь USDC на [[gloss:ethereum|Ethereum]], минтишь native USDC на [[gloss:solana|Solana]] — это разобрано в → 2.5 §7), либо доверяешь стороннему мосту, который заблокирует USDC на одной стороне и сминтит обёрнутую версию на другой. Обёрнутая версия — это не native USDC, а токен, зависящий от того, что контракт моста продолжает его поддерживать. На 2026 год примерно $2,8 миллиарда потеряно в хаках мостов, около 40% всех суммарных потерь в крипте, и худшие падения случались как раз с мостами, которые соединяют [[gloss:evm|EVM]] с non-[[gloss:evm|EVM]] экосистемами, где канонического native-пути нет. :::

:::callout{icon=💡} Представь [[gloss:evm|EVM]]-мир как Шенгенскую зону: один паспорт, одна валюта, единые дорожные знаки, свободное перемещение между странами-членами. Ты едешь из Германии во Францию, в Италию с тем же удостоверением в кармане, с теми же евро в кошельке, с теми же правами. Non-[[gloss:evm|EVM]] экосистемы похожи на отдельные суверенные страны вне Шенгена: у каждой свои паспортные требования, своя валюта, свой пограничный контроль. [[gloss:solana|Solana]] — это одна такая страна, [[gloss:aptos|Aptos]] другая, Starknet третья. Посетить можно все, но к каждой нужен свежий проездной документ и обмен денег на границе. Трение пересечения границ становится трением мостирования токенов. Причина того, что мосты ломали столько раз, та же, что веками делала обменники на границах целью ограблений: большие суммы стоимости находятся в одном месте, ожидая перемещения через границу, которую не контролирует ни одна сторона. :::

:::keypoints{label="Ключевые моменты"}

[[gloss:evm|EVM]] создала иллюзию универсального крипто-кошелька. На самом деле универсальность кончается ровно на границе VM: один адрес работает на тридцати [[gloss:evm|EVM]]-цепочках, и не работает ни на одной non-[[gloss:evm|EVM]].
Разные адреса возникают не из-за оформления, а из-за криптографии: разные цепочки используют разные эллиптические кривые ([[gloss:secp256k1|secp256k1]] vs [[gloss:ed25519|Ed25519]]) и разные пути деривации. Никакой кошелёк не может это «починить» без потери безопасности — это математика, а не UI.
Мультичейн-кошелёк склеивает интерфейс, но не идентичности. Под капотом у тебя по-прежнему N независимых криптографических аккаунтов — это даёт изоляцию атак (взлом одного не открывает остальные), но требует отдельных бекапов и отдельных восстановлений.
$2,8 миллиарда потерь в мостах — это не баг мостов, а плата за разделение VM. Пока цепочки не делят state, мосты неизбежны; пока мосты неизбежны — это постоянная атакующая поверхность. Решение не в «лучших мостах», а в canonical-путях типа [[gloss:cctp|CCTP]], где эмитент сам сжигает на одной стороне и минтит на другой. :::

:::details{badge=Глубже title="Эллиптические кривые и почему seed не переносятся"} :::p{html} Почему один приватный ключ порождает разные публичные ключи в [[gloss:evm|EVM]] и в [[gloss:solana|Solana]], и почему это не просто UX-проблема, которую можно починить? Ответ — в эллиптической кривой. :::

:::p{html} [[gloss:evm|EVM]]-цепочки используют [[gloss:secp256k1|secp256k1]], ту же кривую, что у [[gloss:bitcoin|Bitcoin]], с подписями [[gloss:ecdsa|ECDSA]]. [[gloss:solana|Solana]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]] и [[gloss:ton|TON]] используют [[gloss:ed25519|Ed25519]], другую кривую с подписями EdDSA. [[gloss:cosmos|Cosmos]]-цепочки используют [[gloss:secp256k1|secp256k1]] как и [[gloss:evm|EVM]], но с другим путём деривации в [[gloss:bip-44|BIP-44]]. Кривые не взаимозаменяемы: приватный ключ, валидный на [[gloss:secp256k1|secp256k1]], не может произвести подпись [[gloss:ed25519|Ed25519]], и наоборот. Они даже математически не связаны полезным образом; это два разных математических объекта. :::

:::p{html} [[gloss:bip-44|BIP-44]] обходит это, рассматривая мнемоник как источник энтропии для деривации отдельных приватных ключей для каждой цепочки. Seed-фраза кодирует 128 или 256 бит энтропии. Путь деривации m / purpose' / coin_type' / account' / change / address_index использует HMAC-SHA512 для детерминированной генерации цепочки дочерних ключей из этой энтропии. Поле coin_type и делает [[gloss:evm|EVM]]-ключ отличным от [[gloss:solana|Solana]]-ключа. Сами coin types берутся из реестра (SLIP-44): [[gloss:bitcoin|Bitcoin]] — 0, [[gloss:ethereum|Ethereum]] — 60, [[gloss:solana|Solana]] — 501, [[gloss:cosmos|Cosmos]] — 118, [[gloss:aptos|Aptos]] — 637, [[gloss:sui|Sui]] — 784, [[gloss:ton|TON]] — 607. :::

:::p{html} Практический смысл: «одна seed-фраза, все цепочки» работает только потому, что путь деривации между ними разный, а не потому, что базовая криптография их объединяет. Потеряешь seed — потеряешь кошелёк во всех цепочках. Утечёт seed — утечёт кошелёк во всех цепочках. Но ты не можешь, подписав транзакцию своим [[gloss:ethereum|Ethereum]]-ключом, доказать владение [[gloss:solana|Solana]]-адресом: это независимые идентичности, выведенные из одного корня. :::

:::p{html} [[gloss:account abstraction|Account abstraction]] (ERC-4337 в [[gloss:evm|EVM]], нативная AA в Starknet и [[gloss:aptos|Aptos]], смарт-аккаунты в [[gloss:solana|Solana]]) начинает понемногу решать эту проблему. С AA «кошелёк» — это контракт, и контракт сам решает, какие подписи он принимает. Один AA-кошелёк может принимать подписи и от [[gloss:ed25519|Ed25519]], и от [[gloss:secp256k1|secp256k1]], эффективно позволяя одной пользовательской идентичности охватывать оба мира. На 2026 год это работает на практике, но не повсеместно; большинство пользователей по-прежнему жонглируют отдельными идентичностями. :::

:::p{html} Итог. Фрагментация идентичности между VM — это не UX-баг, который можно починить, а следствие лежащей в основе криптографии. AA может прикрыть это на уровне приложения; сами цепочки остаются раздельными. ::: :::

:::quiz{id=q-2-6-s4 correct=2 explanation="Верно. Цепочки используют математически разные криптографические кривые: [[gloss:secp256k1|secp256k1]] ([[gloss:ethereum|Ethereum]], [[gloss:bitcoin|Bitcoin]], [[gloss:cosmos|Cosmos]]) и [[gloss:ed25519|Ed25519]] ([[gloss:solana|Solana]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]], [[gloss:ton|TON]]). Поверх этого [[gloss:bip-44|BIP-44]] предписывает разное поле coin type в пути деривации для каждой цепочки (60 для [[gloss:ethereum|Ethereum]], 501 для [[gloss:solana|Solana]]), порождая разные ключи из одной и той же энтропии. Seed-фраза общая; полученные ончейн-идентичности математически независимы."} Почему одна seed-фраза даёт разные адреса в [[gloss:ethereum|Ethereum]] и в [[gloss:solana|Solana]]?

Это баг кошельков — современные мультичейн-кошельки постепенно идут к единому адресу
[[gloss:solana|Solana]] намеренно использует хеш [[gloss:ethereum|Ethereum]]-адреса для возможности кросс-чейн привязки
Цепочки используют разные эллиптические кривые ([[gloss:secp256k1|secp256k1]] и [[gloss:ed25519|Ed25519]]) и разные пути деривации [[gloss:bip-44|BIP-44]], поэтому одна и та же seed-фраза детерминированно порождает несвязанные ключевые пары на каждой
Это случайность — даже из одной seed-фразы генерация ключей недетерминирована между цепочками :::

:::section{mins=2} Что это значит для разработчика :::

:::lead Выбор VM — это не выбор языка. Это выбор аудит-фирм, библиотек, инструментов, конвенций и десятилетия накопленного цехового знания, которое идёт в комплекте. [[gloss:solidity|Solidity]]-разработчик за выходные деплоит на десятки [[gloss:evm|EVM]]-цепочек, но добавление хотя бы одной non-[[gloss:evm|EVM]] цели умножает операционную поверхность во что-то между тремя и десятью — выигрыш должен это окупить. :::

:::p{html} Экосистема [[gloss:solidity|Solidity]] в 2026 году — самый крупный, самый скучный и самый утоптанный путь в разработке смарт-контрактов. У языка около 20 000 активных разработчиков; пул Rust (используется в [[gloss:solana|Solana]], [[gloss:stylus|Stylus]], некоторых [[gloss:cosmos|Cosmos]]-цепочках) ближе к 3 миллионам, если считать всех Rust-разработчиков, хотя лишь малая часть имеет крипто-опыт. У [[gloss:solidity|Solidity]] есть Foundry и Hardhat (зрелые тест-фреймворки), OpenZeppelin (проверенная в боях библиотека контрактов), Slither и Mythril (статические анализаторы), Tenderly (симуляция транзакций), Etherscan и его клоны (верификация и обзор), стандарт ABI для общения с контрактами из любого клиента. Почти всё это бесплатно, с открытым исходным кодом и работает одинаково во всех крупных [[gloss:evm|EVM]]-цепочках. :::

:::p{html} Non-[[gloss:evm|EVM]] аналоги существуют, но разрыв в зрелости реальный. У [[gloss:solana|Solana]] есть Anchor (Rust-фреймворк для [[gloss:svm|SVM]]-программ), [[gloss:bankrun|Bankrun]] (тест-фреймворк), [[gloss:solana|Solana]] Explorer и растущий пул Rust-аудиторов. У Starknet — [[gloss:scarb|Scarb]] (сборщик), Starknet-foundry (тест-фреймворк), стандартная библиотека [[gloss:cairo|Cairo]]. У [[gloss:aptos|Aptos]] и [[gloss:sui|Sui]] — [[gloss:move|Move]] CLI и их собственные фреймворки, а у [[gloss:aptos|Aptos]] дополнительно [[gloss:move prover|Move Prover]] для формальной верификации. У [[gloss:cosmos|Cosmos]] — инструментарий CosmWasm, построенный на стандартном Rust. Ничего из этого не лишено ключевых деталей; всё это просто моложе и меньше. [[gloss:evm|EVM]]-аудитор видит один и тот же паттерн тысячи раз; [[gloss:cairo|Cairo]]-аудитор сталкивался с ним десятки. Баги ловятся, но медленнее. :::

:::p{html} Главный практический вопрос для команды — мультичейн-деплой. Деплой одного и того же [[gloss:solidity|Solidity]]-контракта на [[gloss:ethereum|Ethereum]], Arbitrum, Base и Optimism звучит как «в четыре раза больше работы», но ближе к «один деплой плюс три конфиг-файла»: в [[gloss:evm|EVM]]-экосистеме есть инструменты ровно для этого. Добавление [[gloss:solana|Solana]] к этому списку — это не «в пять раз больше», а скорее «параллельный проект, который делит идею с [[gloss:evm|EVM]]-деплоем, но всё остальное собирает заново». Другой язык, другой фреймворк, другая тестовая среда, другой инструментарий деплоя, другие интеграции оракулов (Pyth в [[gloss:solana|Solana]] vs Chainlink в [[gloss:evm|EVM]], хотя оба теперь покрывают несколько цепочек), другие интеграции кошельков. Протоколы, которые это всё-таки сделали, — Uniswap (DEX на [[gloss:solana|Solana]] через UniV4), Aave (лендинг на [[gloss:aptos|Aptos]]), Jupiter и Drift (нативный [[gloss:defi|DeFi]] для [[gloss:solana|Solana]]) — каждый по сути собрал вторую команду под вторую VM. :::

:::p{html} [[gloss:stylus|Stylus]] — самый интересный компромисс в этой картине. [[gloss:wasm|WASM]] VM от Arbitrum работает на Arbitrum One с июня 2024 года. Она позволяет контрактам на Rust, C и C++ исполняться рядом с [[gloss:solidity|Solidity]] на той же цепочке, с кросс-вызовами между двумя VM. RedStone сообщил о 30%+ экономии газа на своём [[gloss:stylus|Stylus]]-оракуле против сильно оптимизированного [[gloss:evm|EVM]]-[[gloss:solidity|Solidity]]. Бенчмарки вычислений показывают ускорения в 10–70 раз на тяжёлых операциях. К февралю 2026 года у Rather Labs появился даже компилятор [[gloss:move|Move]]-в-[[gloss:stylus|Stylus]] в бета-версии, что значит: контракты на [[gloss:move|Move]] можно деплоить на Arbitrum, не покидая [[gloss:evm|EVM]]-экосистему. Такое сосуществование нескольких VM — направление, которое §6 разберёт подробнее. :::

:::callout{icon=💡} Подумай о том, как больничная сеть подходит к найму персонала в разных регионах. Если ты держишь [[gloss:solidity|Solidity]]-практику, ты работаешь в стране с тысячами обученных врачей, национальной системой аккредитации, стандартизированными программами повышения квалификации и десятилетиями судебной практики по медицинским ошибкам. Открыть новую клинику в другом городе той же страны — это административная работа: те же регуляции, та же подготовка, те же страховые компании. Теперь представь, что ты решаешь открыть клинику в другой стране, со своей медицинской системой, своим аккредитационным советом, своим языком и своим фармацевтическим регулированием. Врачи, которых ты уже нанял, не могут просто переехать; тебе нужно набирать местных специалистов, переучивать их под свои протоколы и заново собирать те же сети доверия. Некоторые сети это делают, и новые филиалы выходят отличными, но никто не делает вид, что это та же операционная нагрузка, что открыть ещё одну клинику дома. Деплой из [[gloss:evm|EVM]] в non-[[gloss:evm|EVM]] — это именно такое расширение. :::

:::keypoints{label="Ключевые моменты"}

«Деплой на 10 цепочек» внутри [[gloss:evm|EVM]]-экосистемы — это один конфиг-файл на цепочку. Добавление первой non-[[gloss:evm|EVM]] цепочки ближе к запуску параллельного проекта: другая команда, другие сроки, другой аудит-бюджет
Зрелость аудита — самое недооценённое преимущество [[gloss:evm|EVM]]. Те же фирмы аудировали те же паттерны тысячи раз, и время реакции у них измеряется днями. Non-[[gloss:evm|EVM]] аудит существует, но скамейка маленькая, медленная и дорогая на контракт
Когда проект всё-таки идёт мульти-VM, он обычно платит цену через разделение команд. Uniswap, Aave и крупные [[gloss:solana|Solana]]-нативные DEX-ы не делят код контрактов между своим [[gloss:evm|EVM]] и non-[[gloss:evm|EVM]] присутствием — они делят продуктовую стратегию и бренд
[[gloss:stylus|Stylus]] — рабочий контрпример: [[gloss:wasm|WASM]]-контракты (Rust, C, C++, теперь [[gloss:move|Move]]), исполняемые на Arbitrum рядом с [[gloss:solidity|Solidity]], с кросс-вызовами. Стоимость ухода от [[gloss:solidity|Solidity]] резко падает, если одновременно не нужно уходить из [[gloss:evm|EVM]]-стека :::

:::details{badge=Глубже title="Replay-атаки и chain-специфичное поведение опкодов"} :::p{html} Опасные баги в мультичейн-деплое — это обычно не отсутствующие функции, а функции, существующие во всех цепочках, но ведущие себя слегка по-разному. На практике значимы три категории. :::

:::p{html} [[gloss:chain id|Chain ID]] и replay-атаки. Представь: пользователь подписал [[gloss:permit|permit]] — offchain-разрешение «контракту X можно списать 100 USDC с моего адреса» — на [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]. Если контракт правильно учитывает [[gloss:block|block]].[[gloss:chainid|chainid]] в подписи, эта подпись действительна только на [[gloss:ethereum|Ethereum]]. Если не учитывает — ту же подпись можно отправить в любую [[gloss:evm|EVM]]-сеть, где у пользователя есть тот же адрес и баланс, и повторно списать 100 USDC. [[gloss:eip|EIP]]-155 ввёл [[gloss:chainid|chainid]] именно для того, чтобы такие реплеи стали невозможны: у каждой [[gloss:evm|EVM]]-цепочки свой [[gloss:chain id|chain ID]] ([[gloss:ethereum|Ethereum]] — 1, Arbitrum — 42161, Base — 8453, Optimism — 10), и подпись коммитится к конкретному значению. Но защита работает только тогда, когда контракт сам проверяет [[gloss:chainid|chainid]] в логике подписи. [[gloss:permit|Permit]]'ы, governance-голосование, мета-транзакции (везде, где используется [[gloss:eip-712|EIP-712]] typed-data) могут оказаться уязвимы. Баг невидим на одночейн-деплое; он появляется в тот момент, когда один и тот же адрес контракта существует на двух цепочках. :::

:::p{html} [[gloss:block|Block]] timestamp и случайность. Опкод [[gloss:block|block]].timestamp возвращает Unix-время (секунды с 1 января 1970 года), но частота блоков на разных цепочках сильно различается. Arbitrum производит блок примерно раз в 250 мс; [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] — раз в 12 секунд; Polygon [[gloss:proof of stake|PoS]] — раз в 2 секунды. Контракт, использующий [[gloss:block|block]].timestamp как источник случайности (например, для лотереи) или как тонкое временное ограничение (например, «разрешить вывод только через час после депозита»), ведёт себя совершенно по-разному на разных цепочках. Хуже того: на цепочках с централизованным секвенсером (Arbitrum, Optimism, Base — все они работают через одного оператора) timestamp может быть подкручен секвенсером в небольшом окне. «Случайность от timestamp» в этом случае превращается в «случайность, на которую может повлиять оператор сети». :::

:::p{html} Доступность [[gloss:precompile|precompile]]. У [[gloss:ethereum|Ethereum]] фиксированный набор [[gloss:precompile|precompile]]-контрактов (ecrecover, sha256, blake2f, операции [[gloss:pairing|pairing]] на кривой [[gloss:bn254|bn254]] и т. д.). Большинство [[gloss:evm|EVM]]-цепочек поддерживают тот же набор, но некоторые добавляют свои или пропускают. У Arbitrum собственные [[gloss:precompile|precompile]] из ArbOS для [[gloss:l1|L1]]-[[gloss:layer 2|L2]] коммуникации, которых на [[gloss:ethereum|Ethereum]] нет. У Optimism — [[gloss:precompile|precompile]] с информацией о блоке [[gloss:l1|L1]]. Контракт, обращающийся к неизвестному [[gloss:precompile|precompile]], получает неожиданное поведение (часто: пустой возврат, тихий fail). :::

:::p{html} Практическая контрмера. Реальные мультичейн-деплои относятся к каждой целевой цепочке как к независимому объекту аудита. Chain-специфичный тест-сьют обязан включать: проверку [[gloss:chain id|chain ID]], тесты зависимости от timestamp, тесты доступности [[gloss:precompile|precompile]], [[gloss:fork|fork]]-test воспроизведение любых signature-based взаимодействий. Деплой-скрипты обязаны читать chain-специфичную конфигурацию. Инструменты для этого существуют ([[gloss:fork|fork]] testing в Foundry, мультичейн-симуляции в Tenderly), но команде нужно их сознательно применять. :::

:::p{html} Итог. Тот же [[gloss:solidity|Solidity]]-исходник, скомпилированный в тот же байткод, даёт разное наблюдаемое поведение на разных [[gloss:evm|EVM]]-цепочках. Чем больше поверхность деплоя, тем больше chain-специфичных краевых случаев требует явной обработки. Мультичейн не «бесплатен» и внутри [[gloss:evm|EVM]]-мира — просто намного дешевле, чем переход в non-[[gloss:evm|EVM]]. ::: :::

:::quiz{id=q-2-6-s5 correct=1 explanation="Верно. Добавление non-[[gloss:evm|EVM]] цепочки структурно отличается от добавления ещё одной [[gloss:evm|EVM]]-цепочки. Внутри [[gloss:evm|EVM]] деплой — это конфиг плюс прогон тестов. Переход в [[gloss:solana|Solana]] — это переписывание на Rust под Anchor, поиск [[gloss:solana|Solana]]-специализированных аудиторов, интеграция Phantom вместо Rabby, использование Pyth или Switchboard вместо Chainlink. Протоколы, реально это сделавшие, — Uniswap, Aave — по сути оперируют двумя параллельными кодовыми базами, удерживаемыми вместе продуктовой стратегией."} [[gloss:solidity|Solidity]]-команда выпустила продукт на [[gloss:ethereum|Ethereum]], Arbitrum и Base. Она думает добавить [[gloss:solana|Solana]]. Во что это обойдётся на практике?

Примерно столько же, сколько добавить ещё один [[gloss:evm|EVM]] [[gloss:layer 2|L2]] — Foundry теперь поддерживает кросс-VM деплой
По сути параллельный проект: другой язык (Rust), другой фреймворк (Anchor), другие аудит-фирмы, другие интеграции кошельков, другие провайдеры оракулов и отдельная команда для долгосрочной поддержки
Немного больше, чем ещё один [[gloss:evm|EVM]], в основном на перевод [[gloss:solidity|Solidity]] в Rust — остальной тулинг переносится
Невозможно без протокола абстракции цепочки вроде NEAR Intents :::

:::section{mins=2} Конвергенция: миры сближаются :::

:::lead Самая интересная история про VM в 2025–2026 годах — не «какая выиграет», а то, что оба лагеря начали смотреть на чужие решения и впитывать их. [[gloss:evm|EVM]]-цепочки получают параллельное исполнение и сосуществование с [[gloss:wasm|WASM]]; сам Виталик предложил заменить [[gloss:evm|EVM]] на [[gloss:risc-v|RISC-V]] на уровне протокола [[gloss:l1|L1]]. Non-[[gloss:evm|EVM]] сети получают слои [[gloss:evm|EVM]]-совместимости и мосты. К 2026 году вопрос «какая VM у этой цепочки» становится неправильной рамкой — у многих их больше одной. :::

:::p{html} [[gloss:evm|EVM]] получает параллельное исполнение. [[gloss:monad|Monad]], [[gloss:l1|L1]] с совместимостью на уровне [[gloss:evm|EVM]]-байткода, основанный бывшими инженерами Jump Trading, запустил [[gloss:mainnet|mainnet]] 24 ноября 2025 года после трёх лет тестнета. Архитектурно [[gloss:monad|Monad]] делает то, для чего [[gloss:evm|EVM]] никогда не проектировалась: оптимистическое параллельное исполнение. Транзакции по умолчанию запускаются параллельно; если две из них в итоге касаются одного state-слота, конфликтующая переисполняется последовательно. Итоговое состояние — то же, к которому пришёл бы [[gloss:ethereum|Ethereum]], только намного быстрее. [[gloss:monad|Monad]] нацелен на 10 000 TPS с блоками по 400 мс и финальностью 800 мс, и к апрелю 2026 года цепочка держит около $400,9 миллиона [[gloss:tvl|TVL]]. [[gloss:solidity|Solidity]]-контракты деплоятся без изменений; OpenZeppelin, Foundry и весь стандартный инструментарий работают. [[gloss:evm|EVM]]-стек остаётся; последовательное ограничение уходит. :::

:::p{html} [[gloss:evm|EVM]] также получает сосуществование с [[gloss:wasm|WASM]]. Arbitrum [[gloss:stylus|Stylus]], который работает на Arbitrum One с июня 2024 года, позволяет контрактам на Rust, C и C++ исполняться рядом с [[gloss:solidity|Solidity]] во второй VM, которая прикручена к той же цепочке. Кросс-вызовы между [[gloss:stylus|Stylus]] и [[gloss:solidity|Solidity]] нативные: [[gloss:stylus|Stylus]]-контракт можно вызывать из [[gloss:solidity|Solidity]]-контракта и наоборот. Оракул RedStone, развёрнутый на [[gloss:stylus|Stylus]] в ноябре 2025 года, сообщил о 30%+ экономии газа на реальных нагрузках против сильно оптимизированного [[gloss:evm|EVM]]-кода; на тяжёлых вычислительных операциях [[gloss:stylus|Stylus]] показывает ускорение в 10–70 раз. В феврале 2026 года Rather Labs выпустили компилятор [[gloss:move|Move]] в [[gloss:stylus|Stylus]] в бета-версии, что значит: контракты на [[gloss:move|Move]] теперь могут работать на Arbitrum, вообще не покидая [[gloss:ethereum|Ethereum]]-экосистему. Граница между «[[gloss:evm|EVM]]-цепочкой» и «non-[[gloss:evm|EVM]] цепочкой» — это та граница, которую [[gloss:stylus|Stylus]] размывает. :::

:::p{html} Самый амбициозный шаг — от самого [[gloss:ethereum|Ethereum]]. 20 апреля 2025 года Виталик опубликовал на форуме [[gloss:ethereum|Ethereum]] Magicians предложение заменить [[gloss:evm|EVM]] на [[gloss:risc-v|RISC-V]] на уровне протокола [[gloss:l1|L1]] — это та же open-source система команд, которая используется в современных CPU и внутри большинства ZK-проверщиков. Аргумент: около 59% времени proving в [[gloss:zkevm|zkEVM]] тратится на симуляцию исполнения [[gloss:evm|EVM]], и переход на [[gloss:risc-v|RISC-V]] нативно может улучшить эффективность доказательства в 50–100 раз. Предложение описывает три этапа развёртывания: сначала [[gloss:precompile|precompile]] для отдельных операций, затем пользовательские [[gloss:risc-v|RISC-V]] контракты рядом с [[gloss:evm|EVM]], и в конечном счёте полный вывод [[gloss:evm|EVM]] из эксплуатации через запуск её как интерпретатора внутри новой VM. В follow-up посте 1 марта 2026 года Виталик описал изменения в state tree вместе с заменой VM как составляющие «более 80% узкого места proving» и назвал оба изменения «по сути обязательными» для client-side proving. Offchain Labs (команда за Arbitrum и [[gloss:stylus|Stylus]]) опубликовали в ноябре 2025 года свой собственный rebuttal, аргументируя, что [[gloss:wasm|WASM]] — лучший долгосрочный выбор. Дискуссия живая; ничего не решено. :::

:::p{html} Со стороны non-[[gloss:evm|EVM]] конвергенция тоже движется. [[gloss:eclipse|Eclipse]] запускает [[gloss:svm|SVM]] поверх [[gloss:data availability|data availability]] [[gloss:ethereum|Ethereum]], помещая runtime [[gloss:solana|Solana]] внутрь модели безопасности [[gloss:ethereum|Ethereum]]. [[gloss:sei|Sei]] V2 запустил [[gloss:evm|EVM]]-совместимость рядом со своим нативным CosmWasm. [[gloss:movement|Movement]] запускает [[gloss:move|Move VM]] как [[gloss:layer 2|L2]] для [[gloss:ethereum|Ethereum]] со settlement на [[gloss:l1|L1]] и исполнением на [[gloss:move|Move]]. [[gloss:neon evm|Neon EVM]] разворачивает [[gloss:solidity|Solidity]]-совместимый [[gloss:evm|EVM]] на [[gloss:solana|Solana]]. Ни одна из этих сетей не доминирует; все они существуют и показывают product-market signal. Паттерн стабильный: вместо того чтобы одна VM выиграла, экосистемы всё чаще строят мульти-VM цепочки, где одна и та же цепочка может хостить и [[gloss:evm|EVM]], и non-[[gloss:evm|EVM]] контракты, и выбор смещается от «какая цепочка» к «какая VM на этой цепочке». :::

:::callout{icon=💡} Это похоже на то, что произошло с зарядными разъёмами за последние десять лет. В 2010 году у каждого производителя телефонов был свой порт: у Apple — 30-pin, у Samsung — micro-USB-A, у Nokia — собственный «бочонок», у дешёвых брендов — у каждого что-то своё. Гость не мог одолжить твою зарядку; в зоне ожидания аэропорта к стойке были приклеены скотчем четыре разных дока сразу. У отличий были реальные технические причины (разная сигнализация, разные напряжения, разные патенты), но для пользователя это было просто неудобство. Потом пришёл USB-C, и шаг за шагом каждый лагерь двинулся к нему: сначала Android, потом ноутбуки, в конце концов даже Apple под давлением ЕС. Разъёмы не слились потому, что кто-то выиграл. Они слились потому, что общий стандарт оказался ценнее любого фирменного дизайна — любая компания получила больше от того, что её устройство работает с чужими зарядками, чем от того, что у неё свой уникальный порт. Конвергенция VM идёт по тому же пути: [[gloss:stylus|Stylus]] — это гибридный порт, в котором на одной цепочке сосуществуют [[gloss:solidity|Solidity]]-USB и Rust-USB; [[gloss:eclipse|Eclipse]] — это [[gloss:svm|SVM]]-устройство, работающее на питании от [[gloss:ethereum|Ethereum]]; предложение [[gloss:risc-v|RISC-V]] — это новый универсальный стандарт, пытающийся полностью заменить старый разъём. :::

:::keypoints{label="Ключевые моменты"}

[[gloss:evm|EVM]] 2026 года — это уже не [[gloss:evm|EVM]] 2018-го. [[gloss:monad|Monad]] даёт параллельное исполнение с байт-идентичной совместимостью. [[gloss:stylus|Stylus]] кладёт [[gloss:wasm|WASM]] рядом с [[gloss:solidity|Solidity]] на той же цепочке. Оба сохраняют [[gloss:evm|EVM]]-стек и снимают ограничения, из-за которых она казалась устаревшей
Апрельское 2025 года предложение Виталика про [[gloss:risc-v|RISC-V]] — самое сильное указание на то, что [[gloss:ethereum|Ethereum]] может отказаться от [[gloss:evm|EVM]] как таковой. Трёхэтапный план — [[gloss:precompile|precompile]], пользовательские контракты, полная замена через интерпретатор — достаточно конкретен, чтобы планировать под него уже сейчас, но реализация займёт годы
Non-[[gloss:evm|EVM]] сторона делает зеркальный шаг: [[gloss:eclipse|Eclipse]] кладёт [[gloss:svm|SVM]] на [[gloss:data availability|data availability]] [[gloss:ethereum|Ethereum]], [[gloss:movement|Movement]] делает [[gloss:move|Move]] как [[gloss:layer 2|L2]] для [[gloss:ethereum|Ethereum]], [[gloss:sei|Sei]] добавляет [[gloss:evm|EVM]] рядом с CosmWasm. Архитектурное расстояние между лагерями сжимается с обеих сторон
Рамка «какая VM у этой цепочки» становится неправильным вопросом. Новая рамка — «какие VM эта цепочка хостит, и как они взаимодействуют». Мульти-VM — это паттерн дизайна, который с большой вероятностью определит 2027 год и далее :::

:::details{badge=Глубже title="RISC-V vs WASM как следующий слой исполнения"} :::p{html} Если [[gloss:evm|EVM]] медленно заменяется, вопрос «что заменяет» важнее вопроса «заменяет ли». У двух кандидатов есть серьёзная поддержка: [[gloss:risc-v|RISC-V]] и [[gloss:wasm|WASM]]. :::

:::p{html} [[gloss:risc-v|RISC-V]] (позиция Виталика). [[gloss:risc-v|RISC-V]] — это open-source система команд процессора, изначально спроектированная в Беркли для академических нужд. У неё небольшая core spec, модульные расширения и растущая аппаратная поддержка. Для блокчейнов главное её преимущество — ZK proving: zkVM вроде Succinct SP1, RISC Zero и Polygon Miden уже используют [[gloss:risc-v|RISC-V]] внутри, потому что её система команд ближе к алгебре [[gloss:snark|SNARK]]-ограничений, чем [[gloss:evm|EVM]]-байткод. Аргумент Виталика: если [[gloss:zkevm|zkEVM]] уже транслируют [[gloss:evm|EVM]]-байткод в [[gloss:risc-v|RISC-V]] внутри себя, чтобы его доказать, — давайте просто стандартизируем на [[gloss:risc-v|RISC-V]] на уровне протокола и пропустим шаг трансляции. Оценочный прирост эффективности — 50–100 раз для доказательства. [[gloss:polkavm|PolkaVM]] от [[gloss:polkadot|Polkadot]] использует [[gloss:risc-v|RISC-V]] с августа 2023 года, так что дизайн уже проверен в продакшене и за пределами [[gloss:ethereum|Ethereum]]. :::

:::p{html} [[gloss:wasm|WASM]] (позиция Offchain Labs). [[gloss:wasm|WebAssembly]] — другой open-source формат байткода, изначально спроектированный для браузеров, но теперь используемый как универсальный целевой формат для системных языков. Он уже в продакшене на Arbitrum ([[gloss:stylus|Stylus]]), в большинстве [[gloss:cosmos|Cosmos]]-цепочек (CosmWasm), в pallet контрактов [[gloss:polkadot|Polkadot]], в Near, в Internet Computer. Аргумент Offchain Labs из ноябрьского rebuttal'а 2025 года: у [[gloss:wasm|WASM]] значительно большая база разработчиков, чем у [[gloss:risc-v|RISC-V]], зрелые toolchains (Rust, C++, Go, AssemblyScript компилируются в [[gloss:wasm|WASM]]) и активный процесс стандартизации. Их основной тезис: ISA доставки (то, на чём разработчики пишут код) и ISA proving (то, во что ZK-проверщик транслирует) не обязаны быть одним и тем же — [[gloss:wasm|WASM]] для доставки, [[gloss:risc-v|RISC-V]] для proving. :::

:::p{html} Техническая разница. [[gloss:risc-v|RISC-V]] ближе к голому железу: 32-битные команды, регистровая модель, легко ложится на ZK-схемы. [[gloss:wasm|WASM]] — стековая VM со структурным потоком управления, спроектированная для безопасной песочницы в браузерах. Обе детерминированы; обе можно сделать с учётом газа. Стоимость реализации любой из них на уровне [[gloss:l1|L1]] сопоставимая; экосистемная стоимость очень разная. :::

:::p{html} Что реально вероятно. Наиболее правдоподобный исход — не победитель, а сосуществование. Дорожная карта [[gloss:ethereum|Ethereum]], как Виталик её описал, постепенная: оставить [[gloss:evm|EVM]] для legacy-контрактов, добавить новую VM (какая бы она ни была) рядом, дать разработчикам выбор. [[gloss:glamsterdam|Glamsterdam]] (следующий крупный апгрейд [[gloss:ethereum|Ethereum]], запланированный на первую половину 2026 года) сфокусирован на изменениях в state tree — [[gloss:eip|EIP]]-7864 с заменой на бинарное дерево, — а не на изменениях в VM. Переход VM — это вопрос 2027 года и позже. [[gloss:hegota|Hegota]], апгрейд после [[gloss:glamsterdam|Glamsterdam]], запланирован на вторую половину 2026 года и может всерьёз начать переход на новую VM. :::

:::p{html} Итог. Дискуссия [[gloss:risc-v|RISC-V]] vs [[gloss:wasm|WASM]] — самая важная архитектурная дискуссия в среднесрочном будущем [[gloss:ethereum|Ethereum]]. Оба предложения убедительны; ни одно из них не принято окончательно. Что уже точно: [[gloss:evm|EVM]] в её текущей форме — не долгосрочный execution-слой, и спроектировавшие её люди с этим согласны. ::: :::

:::quiz{id=q-2-6-s6 correct=3 explanation="Верно. Базовый аргумент — эффективность ZK proving. Около 59% времени proving в [[gloss:zkevm|zkEVM]] тратится на симуляцию исполнения [[gloss:evm|EVM]], и современные zkVM вроде Succinct SP1, RISC Zero и Polygon Miden уже используют [[gloss:risc-v|RISC-V]] внутри себя. Переход на уровне протокола убирает накладные расходы трансляции. В follow-up посте Виталика 1 марта 2026 года он описал изменение VM вместе с изменением state tree как совместно дающие «более 80% узкого места proving»."} Виталик предложил заменить [[gloss:evm|EVM]] на [[gloss:risc-v|RISC-V]] в апреле 2025 года. В чём основная техническая мотивация?

[[gloss:solidity|Solidity]] будет компилироваться намного быстрее на более простую систему команд
[[gloss:risc-v|RISC-V]] позволит [[gloss:ethereum|Ethereum]] работать на пользовательском железе без нод
Это маркетинговый ход для синхронизации [[gloss:ethereum|Ethereum]] с движением открытого железа
ZK-проверщики уже транслируют [[gloss:evm|EVM]]-байткод в [[gloss:risc-v|RISC-V]] внутри себя, чтобы его доказать, и эта трансляция отвечает за большую часть накладных расходов proving — переход на [[gloss:risc-v|RISC-V]] нативно может улучшить эффективность доказательства в 50–100 раз :::

:::section{mins=2} Куда идёт индустрия в 2026 :::

:::lead Три траектории видны одновременно, и они не взаимоисключающие: [[gloss:evm|EVM]]-стек адаптируется и впитывает ([[gloss:monad|Monad]], [[gloss:stylus|Stylus]], в перспективе [[gloss:risc-v|RISC-V]]), самые сильные non-[[gloss:evm|EVM]] ставки продолжают расти в свои ниши ([[gloss:solana|Solana]] для пропускной способности, Starknet для ZK-нативного, [[gloss:move|Move]]-экосистема для высокоценного [[gloss:defi|DeFi]]), и над ними поднимается третий слой, который абстрагирует VM от пользователя полностью ([[gloss:account abstraction|account abstraction]], [[gloss:chain abstraction|chain abstraction]], [[gloss:intent-based|intent-based]] UX). К 2028 году вопрос «[[gloss:evm|EVM]] или non-[[gloss:evm|EVM]]» может оказаться тем, который средний пользователь просто не обязан задавать. :::

:::p{html} Первая траектория — та, над которой [[gloss:ethereum|Ethereum]] работает дольше всего и которая привлекает меньше всего внимания. [[gloss:evm|EVM]] остаётся доминирующей платформой смарт-контрактов; она впитывает улучшения, которые компенсируют её дизайн-слабости. [[gloss:monad|Monad]] показывает, что параллельное исполнение можно добавить, не сломав совместимости. [[gloss:stylus|Stylus]] показывает, что сосуществование с [[gloss:wasm|WASM]] можно добавить, не сломав совместимости. Волна 2025–2026 годов с [[gloss:evm|EVM]]-[[gloss:l1|L1]] ([[gloss:monad|Monad]] и конкуренты вроде MegaETH) — доказательство, что «быстрая [[gloss:evm|EVM]]» технически возможна. Если [[gloss:risc-v|RISC-V]] или [[gloss:wasm|WASM]] появятся на уровне протокола [[gloss:ethereum|Ethereum]] в окне [[gloss:glamsterdam|Glamsterdam]]-или-[[gloss:hegota|Hegota]], [[gloss:evm|EVM]] по факту выведут из эксплуатации как отдельную сущность — то, что её заменит, по-прежнему будет запускать все существующие контракты через интерпретатор, но новая модель исполнения будет больше похожа на современную систему команд, чем на стековую машину 2014 года. :::

:::p{html} Вторая траектория интереснее именно потому, что non-[[gloss:evm|EVM]] лагерь рос быстрее с меньшей базы. Число разработчиков [[gloss:solana|Solana]] выросло на 83% год к году в отчёте Electric Capital за 2024 год; активные разработчики [[gloss:sui|Sui]] в месячном выражении росли быстрее, чем у любой другой крупной цепочки, к 2026 году. Non-[[gloss:evm|EVM]] ставки, которые удались — параллелизм [[gloss:solana|Solana]], безопасность [[gloss:move|Move]], ZK-эффективность [[gloss:cairo|Cairo]] — не заменяются; они углубляются. [[gloss:aptos|Aptos]] выпустил крупную перестройку токеномики в марте 2026 года. [[gloss:sui|Sui]] запустил нативный стейблкоин [[gloss:usdsui|USDsui]] и переход на платформу [[gloss:sui|Sui]] Stack (S2). Объём стейблкоин-переводов на [[gloss:solana|Solana]] к 2026 году суммарно перевалил за $1 триллион. Это не цепочки, которые теряют релевантность; это цепочки, которые находят свои категории. :::

:::p{html} Третья траектория, та, что с наибольшей вероятностью реально изменит пользовательский опыт, — это абстракция. [[gloss:account abstraction|Account abstraction]] (ERC-4337 в [[gloss:evm|EVM]], нативная AA в Starknet и [[gloss:aptos|Aptos]], smart accounts в [[gloss:solana|Solana]]) отвязывает «кошелёк» от «приватного ключа», и одна пользовательская идентичность может представляться через несколько VM через контракт, который сам решает, какие подписи принимать. [[gloss:chain abstraction|Chain abstraction]] (NEAR Intents, Particle, Connext плюс работа [[gloss:superchain|Superchain]] над [[gloss:native interop|native interop]]) отвязывает «где мои деньги» от «где я их использую». [[gloss:intent-based|Intent-based]] протоколы вроде Across, Eco Portal и UniswapX позволяют пользователю объявить результат и оставить solver'ам маршрутизацию: пользователь может никогда не узнать, на чём solver всё уладил — на [[gloss:evm|EVM]], на [[gloss:solana|Solana]] или на обоих. Вместе эти абстракции переносят решение «какая VM» из плоскости пользователя в плоскость инфраструктуры. :::

:::p{html} Что у всех трёх траекторий общее — они делают исходную бинарную рамку «[[gloss:evm|EVM]] vs non-[[gloss:evm|EVM]]» всё менее полезной со временем. К концу 2020-х релевантные вопросы, скорее всего, будут другими: как эта цепочка обращается с [[gloss:data availability|data availability]], как с финальностью, как с [[gloss:mev|MEV]], какая у неё модель доверия. VM по-прежнему будет важна разработчикам, которые пишут контракты, но станет меньше важна пользователям этих приложений и тем, кто распределяет капитал по сетям. Это та история о конвергенции, которую заложил §6 — и на этой ноте Часть 2 закрывается, потому что Часть 3 начинается с практического вопроса «какой кошелёк ставить», а этот вопрос раньше полностью зависел от того, какая VM тебе важна. :::

:::callout{icon=💡} Подумай, как вопрос «какую камеру купить» потерял большую часть смысла за последние пятнадцать лет. В 2005 году это было серьёзное решение: полнокадровая зеркалка делала то, что не могла мыльница, мыльница делала то, что не могла зеркалка, плёночная камера делала то, что не делал цифрик. Люди разбирались с компромиссами, шли на форумы, спорили о брендах. К 2020 году вопрос свернулся внутрь телефона в кармане. Флагман снимал фотографии, которые большинство людей не отличали от фото с зеркалки 2010 года, редактор работал на том же телефоне, выкладывание шло через тот же телефон, и вопрос «какая камера» сменился на «какое приложение». Фотографы, которым реально нужна была настоящая камера, продолжали её покупать — все остальные перестали спрашивать. Вопрос про VM в крипте сейчас в ранней стадии того же сворачивания. К 2028 году большинство пользователей не будут выбирать цепочку: их кошелёк выберет за них, их приложение выберет за них, а лежащая под капотом VM станет форматом файла, в который камера сохраняет снимок, — а не решением, которое принимает пользователь. :::

:::keypoints{label="Ключевые моменты"}

Три траектории идут параллельно: [[gloss:evm|EVM]] впитывает улучшения (параллельное исполнение, сосуществование с [[gloss:wasm|WASM]], в перспективе [[gloss:risc-v|RISC-V]]), non-[[gloss:evm|EVM]] углубляет свои ниши (пропускная способность [[gloss:solana|Solana]], [[gloss:defi|DeFi]] на [[gloss:move|Move]], ZK на Starknet) и слои абстракции делают базовую VM менее видимой конечному пользователю
[[gloss:account abstraction|Account abstraction]], [[gloss:chain abstraction|chain abstraction]] и [[gloss:intent-based|intent-based]] протоколы вместе выталкивают выбор VM в инфраструктурный код. Пользователь декларирует «обменяй X на Y»; какая комбинация цепочек и solver'ов это достигает — невидима
Среднесрочные вопросы для тех, кто оценивает экосистемы, смещаются: не «[[gloss:evm|EVM]] или non-[[gloss:evm|EVM]]», а «какой слой [[gloss:data availability|DA]], какая модель финальности, как обстоят дела с [[gloss:mev|MEV]], какое допущение о доверии». VM остаётся одним входным параметром из нескольких, а не определяющим
Эта конвергенция — мост к Части 3 проекта. Кошельки, с которых начинается следующая часть, раньше были строгим VM-за-VM выбором; в 2026 году мультичейн-кошельки и AA-решения начинают это ограничение растворять :::

:::details{badge=Глубже title="Сроки и за чем следить в 2026–2027"} :::p{html} Для читателя, который пытается отслеживать эту область, вот что стоит смотреть и в каких сроках. :::

:::p{html} Апгрейд [[gloss:glamsterdam|Glamsterdam]] [[gloss:ethereum|Ethereum]]. Запланирован на первую половину 2026 года. Главный пункт — [[gloss:eip|EIP]]-7864: замена hexary Merkle Patricia state tree [[gloss:ethereum|Ethereum]] на бинарное дерево, которое Виталик в марте 2026 года описал как половину узкого места proving. Изменения в state tree не меняют VM; они меняют то, как строятся доказательства состояния. Это подготовительная работа перед переходом VM, а не сам переход. :::

:::p{html} Апгрейд [[gloss:hegota|Hegota]] [[gloss:ethereum|Ethereum]]. Запланирован на более поздний срок в 2026-м. Разработчики ещё не финализировали заголовочные [[gloss:eip|EIP]], но изменения слоя исполнения — в центре текущего планирования. Это самое раннее реалистичное окно для появления [[gloss:risc-v|RISC-V]] или [[gloss:wasm|WASM]] [[gloss:precompile|precompile]] на уровне протокола. :::

:::p{html} [[gloss:native interop|Native interop]] [[gloss:superchain|Superchain]]. На devnet с апреля 2026 года; [[gloss:mainnet|mainnet]] запланирован на вторую половину 2026 года (мы это разбирали в → 2.5 §5). Это ответ [[gloss:evm|EVM]]-лагеря на фрагментацию цепочек, и он будет хорошим тестом на то, может ли protocol-level interop заменить bridge-level interop в роллап-экосистеме [[gloss:evm|EVM]]. :::

:::p{html} Первый год [[gloss:monad|Monad]]. [[gloss:mainnet|Mainnet]] запущен 24 ноября 2025 года; к апрелю 2026-го держит $400,9 млн [[gloss:tvl|TVL]]. Вопрос по 2026 году — действительно ли экономика parallel-[[gloss:evm|EVM]] привлечёт [[gloss:defi|DeFi]]-приложения от существующих [[gloss:layer 2|L2]] или просто даст второй ярус. [[gloss:mev|MEV]]-динамика на параллельном [[gloss:evm|EVM]] с 400 мс блоком не проверена на масштабе. :::

:::p{html} Экосистема [[gloss:move|Move]]. 954 активных разработчика [[gloss:sui|Sui]] в Q1 2026 против 465 у [[gloss:aptos|Aptos]] — это самый большой разрыв в активности разработчиков между двумя технически похожими цепочками в индустрии. Запуск стейблкоина [[gloss:usdsui|USDsui]] у [[gloss:sui|Sui]] и институциональная RWA-стратегия [[gloss:aptos|Aptos]] — расходящиеся ставки. [[gloss:movement|Movement]] и Initia продолжают расширять [[gloss:move|Move]] в территорию [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2]] и [[gloss:cosmos|Cosmos]] соответственно. :::

:::p{html} Развёртывание [[gloss:account abstraction|account abstraction]]. ERC-4337 живёт на [[gloss:ethereum|Ethereum]] с марта 2023 года, но в реальном использовании распространялся медленно. [[gloss:eip-7702|EIP-7702]] ([[gloss:pectra|Pectra]], май 2025) сделал переход проще: обычные кошельки ([[gloss:eoa|EOA]]) могут временно делегировать свои действия смарт-контракту без постоянной миграции на новый адрес. По мере того как кошельки начнут включать AA в настройках по умолчанию, его распространение пойдёт быстрее — и именно так вопрос «на какой VM работает приложение» станет невидимым для пользователя. :::

:::p{html} Итог. Самый вероятный исход 2026–2027 годов — не одно драматичное событие, а медленное накопление изменений, которые в совокупности делают вопрос «[[gloss:evm|EVM]]-vs-non-[[gloss:evm|EVM]]» менее чётким, чем он был в 2024. Ни одна из ставок выше не гарантирована. Все они происходят. ::: :::

:::quiz{id=q-2-6-s7 correct=0 explanation="Верно. Наиболее правдоподобный исход на 2028 год — не победа одной VM, а угасание самого вопроса в пользовательском слое. [[gloss:account abstraction|Account abstraction]], [[gloss:chain abstraction|chain abstraction]] и [[gloss:intent-based|intent-based]] протоколы вместе делают выбор VM деталью инфраструктуры. B, C и D — правдоподобно звучащие переоценки: [[gloss:evm|EVM]] не «выигрывает», потому что non-[[gloss:evm|EVM]] продолжает расти; переход VM в [[gloss:ethereum|Ethereum]] — это многолетний процесс; [[gloss:solana|Solana]] к апрелю 2026 года не вытеснила [[gloss:ethereum|Ethereum]] по большинству метрик, и конкретного пути, чтобы вытеснить к 2028-му, не видно."} Что, скорее всего, будет с вопросом «[[gloss:evm|EVM]] vs non-[[gloss:evm|EVM]]» для конечного пользователя к 2028 году?

Вопрос теряет важность для пользователя, потому что [[gloss:account abstraction|account abstraction]], [[gloss:chain abstraction|chain abstraction]] и intent-протоколы всё чаще переносят выбор VM из плоскости пользователя в плоскость инфраструктуры. VM по-прежнему важна разработчикам, но гораздо меньше людям, использующим их приложения
[[gloss:evm|EVM]] окончательно побеждает за счёт сетевых эффектов, и non-[[gloss:evm|EVM]] цепочки перестают быть релевантными
Переход [[gloss:ethereum|Ethereum]] на [[gloss:risc-v|RISC-V]] полностью заменяет [[gloss:evm|EVM]] и делает разделение бессмысленным
[[gloss:solana|Solana]] обгоняет [[gloss:ethereum|Ethereum]] по всем метрикам, и [[gloss:evm|EVM]] становится legacy-стеком :::