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

Первая часть плана касается дерева состояния Ethereum. Если упростить, это как индексная система, через которую система постоянно ищет данные. Проблема в том, что текущая структура — та же шестиугольная Keccak Merkle tree — слишком громоздкая. EIP-7864, который предлагает Vitalik, заменяет её на двоичное дерево. Вместо выбора из шести направлений, вы просто выбираете влево или вправо. Результат? Длина merkle tree сокращается в четыре раза. Для легких клиентов это означает значительное снижение требований к пропускной способности.

Но это ещё не всё. Vitalik хочет изменить и саму хеш-функцию. На столе два кандидата: Blake3, который даёт стабильное ускорение, и Poseidon, который теоретически может увеличить эффективность доказательств в десятки раз, хотя безопасность всё ещё проверяется. Этот план фактически заменяет Verkle Trees, которые годами обсуждались сообществом, но потеряли популярность из-за угрозы квантовых вычислений.

Второй шаг ещё более амбициозный: заменить саму архитектуру EVM на RISC-V. Логика проста — если системы ZK-доказательств уже понимают RISC-V, почему машина должна использовать другой язык? Избавившись от слоя перевода, всё автоматически ускоряется. Vitalik планирует три этапа: сначала переписать 80% предварительно скомпилированных контрактов на новой VM, затем позволить разработчикам развёртывать контракты напрямую, и, наконец, вывести старый EVM из эксплуатации — но не удалять его, а переписать как смарт-контракт на новой машине. Старые контракты продолжат работать, как машина с меняемым двигателем.

Vitalik заявил, что дерево состояния и виртуальная машина вместе составляют более 80% ограничений масштабирования Ethereum. Без этих изменений масштабирование в эпоху ZK просто не сдвинется с места.

Но не все согласны. Команда Arbitrum Offchain Labs опубликовала подробное техническое возражение. Их позиция: RISC-V хорошо для ZK-доказательств, но не обязательно хорошо как формат для контрактов. Они провели разграничение между набором инструкций для доставки (dISA) и набором инструкций для доказательств (pISA). По их мнению, это не должно быть одним и тем же. Они предлагают WebAssembly для уровня контрактов, а затем компиляцию в RISC-V для доказательств. Уже запустили прототип на Arbitrum, и это работает. Плюс они указали на риск: технологии ZK меняются быстро, и если сейчас зафиксировать RISC-V на L1, что будет через два года?

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

Сам Vitalik признал, что консенсус относительно замены EVM ещё нет. Реформа дерева состояния дальше продвинулась — EIP-7864 уже имеет конкретный проект. Но замена на RISC-V? Пока что это на уровне дорожной карты. Хард-форк Glamsterdam ожидался в первую половину 2026 года, за ним Hegota. Конкретные детали ещё не утверждены, но реформа дерева состояния и оптимизация уровня исполнения — это определённые направления.

История Ethereum всегда была о том, что возможно. От перехода PoW к PoS, от L1 к Rollup — система уже доказала, что готова разбирать двигатели на высоте десяти тысяч метров. В этот раз речь идёт о более глубоких вещах: не добавлении функций, а переливании самого фундамента. Это тщательно спланированный ремонт или яма, усложняющаяся? Ответ появится не раньше 2027 года. Но одно ясно: Ethereum не собирается быть старой системой с патчами. Сам этот спор о том, как разобрать патчи и какой двигатель установить — возможно, ценнее любого вывода.