Ethereum на пороге больших изменений: отказ от EVM и переход на бинарное дерево

Ethereum снова обсуждает фундаментальные изменения. На этот раз — не про комиссии или скорость, а про саму основу сети: как хранится состояние. В центре внимания — EIP-7864 и переход к binary state tree. И сразу важный момент: речь не о «выключении EVM завтра», а о долгосрочной эволюции, которая только обретает форму.

Что именно предлагает EIP-7864

EIP-7864 — это предложение по изменению того, как в Ethereum хранится и доказывается состояние сети. Сейчас используется структура Merkle Patricia Trie (MPT), а новая идея — перейти к unified binary tree, то есть единому бинарному дереву.

Если упростить: вместо сложной системы из нескольких взаимосвязанных деревьев предлагается одно общее дерево, где все данные — аккаунты, хранилище контрактов и даже код — лежат в одном пространстве.

Ключевая идея EIP-7864 — заменить текущую многослойную структуру состояния Ethereum на единое бинарное дерево, более простое для доказательств и масштабирования.

Статус предложения — Draft. Это значит, что оно активно обсуждается, но не принято в сеть. Среди авторов и обсуждающих — разработчики, связанные с Ethereum roadmap, включая исследователей уровня Vitalik Buterin и Guillaume Ballet.

Важно: EIP-7864 — не изолированная идея. Она встроена в более широкий контекст развития Ethereum, где одновременно обсуждаются:

• оптимизация state tree;
• упрощение execution layer;
• снижение стоимости zk-proofs (доказательств корректности);
• подготовка к более эффективным stateless и light clients.

Что такое state tree и зачем он нужен

В Ethereum есть понятие state tree — это структура, в которой хранится всё текущее состояние сети:

• балансы аккаунтов;
• данные смарт-контрактов (storage trie);
• код контрактов;
• служебная информация.

Каждая транзакция меняет это состояние. А значит, сеть должна уметь:

• быстро находить нужные данные;
• доказывать, что данные корректны (через Merkle proofs);
• передавать эти доказательства другим участникам.

И вот здесь появляется проблема. Текущая структура была хороша на старте Ethereum, но плохо подходит для современных задач — особенно для zk-proofs и лёгких клиентов.

State tree — это не просто «хранилище», а основа всей проверки данных в Ethereum. Если он неэффективен, тормозит вся сеть.

Почему тема обсуждается именно сейчас

Последние годы Ethereum активно движется в сторону zk-технологий — доказательств корректности без полного пересчёта данных. Это основа для rollups, масштабирования и будущих light clients.

Но есть нюанс. Текущий формат хранения состояния плохо сочетается с такими доказательствами.

Проще говоря: чтобы доказать корректность состояния, приходится передавать слишком много данных. Это увеличивает:

• размер proof;
• нагрузку на сеть (bandwidth);
• стоимость вычислений.

И вот здесь binary tree становится кандидатом на замену.

EIP-7864 — это попытка убрать одно из главных узких мест Ethereum: сложную и тяжёлую структуру состояния.

Почему текущая структура Ethereum считается проблемой

Сегодня в Ethereum используется Merkle Patricia Trie (MPT) — особая структура данных, построенная как hexary tree, то есть дерево с ветвлением на 16 направлений.

На бумаге это выглядит удобно: можно быстро находить данные по ключу и проверять их через Merkle proofs. Но на практике всё сложнее.

И вот где начинается проблема.

Как устроена текущая модель (MPT)

State tree в Ethereum — это не одно дерево, а фактически «дерево из деревьев»:

• account trie — хранит аккаунты;
• storage trie — отдельное дерево для каждого контракта;
• contract code — вообще хранится отдельно, вне основного дерева.

В результате получается разрозненная структура, где данные разбросаны по разным уровням.

Текущий state tree Ethereum — это несколько связанных деревьев, а не единая структура. Это усложняет доказательства и увеличивает объём данных.

Почему MPT плохо подходит для современных задач

Главная проблема — доказательства состояния (validity proofs и Merkle proofs) становятся слишком тяжёлыми.

Причин несколько:

• ветвление на 16 (hexary) → длинные и сложные пути;
• RLP-кодирование (формат сериализации) → дополнительные накладные расходы;
• отдельные деревья для storage → нужно доказывать несколько структур сразу;
• код контрактов вне дерева → ещё один источник данных для proof.

На практике это означает, что witness size (объём данных для доказательства) сильно раздувается.

А теперь добавим zk-proofs.

Каждый байт в доказательстве нужно «прогнать» через вычисления. Чем больше данных — тем дороже proving.

MPT не просто неудобна — она делает zk-доказательства дорогими и медленными.

Почему это критично для light и stateless clients

Лёгкие клиенты (light clients) и stateless clients не хранят всё состояние сети. Они получают только доказательства того, что данные корректны.

И здесь размер proof становится ключевым.

Если доказательства большие:

• растёт нагрузка на сеть (bandwidth);
• увеличивается время синхронизации;
• сложнее запускать клиентов на слабых устройствах.

Проще говоря: текущая модель ограничивает масштабирование.

Сравнение: MPT vs binary tree

Параметр	MPT (hexary tree)	Binary tree (EIP-7864)
Ветвление	16 (hexary)	2 (arity-2)
Структура	Несколько деревьев (account + storage)	Единое дерево (unified)
Размер proof	Большой	Меньше и предсказуемее
zk-friendly	Плохо подходит	Лучше подходит
Хранение кода	Вне дерева	Внутри дерева
Сложность реализации	Высокая	Проще и линейнее

Да, у binary tree больше глубина из-за ветвления на 2. Но структура становится предсказуемой и проще для вычислений.

А для zk это часто важнее.

Ethereum упирается не только в скорость транзакций, а в то, как сложно доказать состояние сети. И именно здесь MPT становится узким местом.

Как работает binary tree в новой модели

Теперь к самому интересному — как именно устроено binary state tree, которое предлагает EIP-7864.

Если убрать лишнюю сложность, идея довольно прямолинейная: всё состояние Ethereum складывается в одно единое дерево с ветвлением на 2 (arity-2).

Никаких отдельных account trie или storage trie. Всё в одном месте.

Binary tree — это единое пространство ключ-значение, где все данные Ethereum живут внутри одной структуры.

Unified tree: объединение account, storage и code

В текущей модели данные разделены. В новой — объединены.

В binary tree:

• аккаунты (balances, nonce);
• storage контрактов;
• код контрактов;

Всё это хранится внутри одного дерева.

Это называется unified binary tree.

На практике это даёт важный эффект — co-location данных. Связанные данные лежат рядом, а не разбросаны по разным структурам.

И вот тут появляется выигрыш.

Когда данные находятся рядом, доказательства становятся компактнее — не нужно «прыгать» между разными деревьями.

Как устроены узлы: leaf, stem и internal

Binary tree состоит из нескольких типов узлов:

• leaf node — конечный узел с данными;
• internal node — промежуточные узлы дерева;
• stem node — дополнительный уровень группировки ключей.

Stem — это важная деталь. Он позволяет группировать данные с похожими префиксами, уменьшая глубину обхода.

Проще говоря: это способ не делать дерево слишком «длинным».

Почему arity-2 меняет правила игры

В hexary tree (MPT) ветвление — 16. В binary tree — 2.

На первый взгляд кажется, что это ухудшение: глубина дерева растёт.

Но в реальности ситуация другая.

• структура становится регулярной и предсказуемой;
• proof строится проще;
• меньше специальных случаев и кодирования.

А главное — такие деревья лучше подходят для zk-friendly hash функций.

И здесь важен выбор хэша.

Роль hash function: BLAKE3, Keccak, Poseidon2

В Ethereum сейчас используется Keccak. Он надёжен, но не оптимален для zk-доказательств.

В контексте EIP-7864 обсуждаются альтернативы:

• BLAKE3 — быстрый и эффективный;
• Poseidon2 — ориентирован на zk-сценарии;
• дальнейшие варианты для post-quantum безопасности.

Выбор hash function напрямую влияет на proving efficiency — стоимость и скорость создания доказательств.

Binary tree раскрывает свой потенциал только вместе с zk-friendly хэшами — иначе эффект будет ограничен.

Почему это важно для witness size

Witness size — это объём данных, который нужно передать, чтобы доказать состояние.

В binary tree:

• меньше разрозненных структур;
• короче и понятнее пути доказательства;
• лучше сжатие данных.

В итоге доказательства становятся компактнее.

А значит:

• меньше нагрузка на сеть;
• дешевле zk-proofs;
• проще запускать stateless clients.

Binary tree — это не просто другая структура. Это попытка сделать Ethereum «доказуемым» быстрее и дешевле.

Что это даст Ethereum

Если убрать технические детали, переход к binary state tree — это попытка упростить жизнь всей сети.

Не косметическое изменение. Скорее — замена фундамента.

Более компактные и дешёвые доказательства

Главный эффект — уменьшение размера доказательств (proof size и witness size).

В текущей модели приходится собирать данные из разных деревьев, учитывать сложное ветвление и кодирование. В binary tree всё проще:

• одно дерево вместо нескольких;
• прямолинейная структура;
• меньше лишних данных в доказательствах.

В результате zk-proofs становятся дешевле и быстрее.

Чем проще структура состояния, тем дешевле доказать, что она корректна. Это ключ к масштабированию Ethereum.

Плюсы для light и stateless clients

Лёгкие клиенты — одна из целей развития Ethereum roadmap.

Binary tree напрямую помогает:

• уменьшается объём данных для синхронизации;
• снижается нагрузка на сеть;
• ускоряется проверка состояния.

Stateless clients тоже выигрывают — им нужно передавать меньше witness-данных.

А значит, запуск узла становится доступнее.

Потенциал для приватности и масштабирования

Есть и менее очевидный эффект.

Более компактные доказательства открывают путь к:

• приватным транзакциям;
• новым форматам rollups;
• более эффективным inclusion lists;
• лучшей работе privacy tools.

Это не мгновенный результат. Но направление понятное.

Binary tree — это инфраструктура под будущие улучшения, а не только оптимизация текущей модели.

Причем здесь EVM и правда ли Ethereum от него откажется

И вот самый обсуждаемый вопрос.

Связан ли EIP-7864 с отказом от EVM?

Короткий ответ: напрямую — нет.

Два параллельных трека развития

В Ethereum сейчас обсуждаются две большие темы:

• state tree (как хранится состояние);
• execution layer (как выполняются транзакции).

Binary tree относится к первому пункту.

EVM — ко второму.

Но между ними есть связь.

Где возникает проблема с EVM

EVM создавался в эпоху, когда про zk-proofs почти не думали.

Сегодня ситуация другая:

• каждую операцию нужно доказать;
• каждый шаг исполнения влияет на стоимость proving;
• некоторые конструкции EVM плохо ложатся на zk.

В итоге появляются два bottleneck:

• state tree (MPT);
• execution model (EVM).

Даже если исправить структуру состояния, EVM всё равно остаётся ограничением для дешёвых zk-доказательств.

Почему говорят про «отказ от EVM»

На фоне этих обсуждений периодически появляется тезис: Ethereum может отказаться от EVM.

Но это слишком сильная формулировка.

На практике речь идёт о другом:

• возможной эволюции execution layer;
• появлении альтернативных VM;
• адаптации под zk-friendly execution.

То есть это долгосрочная дискуссия, а не принятое решение.

И точно не часть EIP-7864.

Важно не путать: binary tree — это изменение структуры данных, а будущее EVM — отдельный исследовательский вопрос.

Binary tree vs Verkle tree

Когда речь заходит о будущем state tree в Ethereum, почти всегда всплывает альтернатива — Verkle trees.

И вот здесь нет простого ответа «что лучше». Это скорее выбор между разными компромиссами.

В чем разница подходов

Binary tree делает ставку на простоту:

• ветвление 2 (arity-2);
• понятная структура;
• hash-based безопасность.

Verkle tree — более сложная конструкция:

• высокое ветвление (большой branch size);
• короткие proof;
• использование криптографии на основе обязательств (commitments).

На практике это выглядит как выбор:

• простота и предсказуемость;
• против максимального сжатия доказательств.

Binary tree проще реализовать и поддерживать, Verkle — эффективнее по размеру доказательств, но сложнее криптографически.

Сравнение: binary tree vs Verkle tree

Параметр	Binary tree	Verkle tree
Ветвление	2 (arity-2)	Высокое (например, 256)
Размер proof	Средний	Меньше
Сложность	Низкая	Высокая
Тип криптографии	Hash-based	Commitment-based
zk-friendly	Хорошо	Очень хорошо
Post-quantum устойчивость	Выше (в теории)	Вопрос открытый

Binary tree часто рассматривают как более «консервативный» вариант. Он проще, лучше понятен и не требует сложной новой криптографии.

Verkle tree — более амбициозный путь, но и более рискованный с точки зрения внедрения.

И спор пока не закрыт.

Какие риски и открытые вопросы остаются

Важно помнить: EIP-7864 находится в статусе Draft.

Это означает, что многие детали ещё не зафиксированы.

Ключевые неопределённости

• какая hash function будет выбрана (Keccak, BLAKE3, Poseidon2 или другая);
• как именно будет реализована структура stem/leaf узлов;
• какой формат proof станет стандартом.

Без этих решений сложно оценить финальную эффективность.

Сложность миграции состояния

Один из самых тяжёлых вопросов — state migration.

Ethereum уже содержит огромное состояние:

• миллионы аккаунтов;
• контракты;
• исторические данные.

Перенести всё это в новую структуру — задача уровня hard fork.

И не просто форка, а очень аккуратного.

Миграция state tree — это не обновление кода, а глубокая перестройка всей сети.

Влияние на экосистему

Любое изменение такого уровня затрагивает:

• клиентов (Geth, Nethermind и др.);
• инструменты разработчиков;
• индексаторы и аналитические сервисы;
• инфраструктуру rollups.

Фактически придётся адаптировать весь стек.

Что это значит для разработчиков, инвесторов и пользователей

Для разработчиков

Для devs это сигнал: модель хранения состояния может измениться.

Это влияет на:

• архитектуру приложений;
• доступ к данным;
• инструменты работы с контрактами.

Пока рано переписывать код. Но игнорировать тренд уже нельзя.

Для инвесторов

Здесь важно не переоценить новости.

EIP-7864 — это исследовательское направление, а не утверждённый апгрейд.

Рынок часто реагирует на заголовки вроде «Ethereum откажется от EVM», но это упрощение.

На текущий момент Ethereum не отказался от EVM — обсуждается долгосрочная эволюция, а не готовое решение.

Для обычных пользователей

С точки зрения пользователя изменения будут почти незаметны.

Речь идёт о «внутренностях» сети:

• как хранятся данные;
• как они проверяются;
• как масштабируется сеть.

Но в долгосрочной перспективе это может привести к:

• снижению комиссий;
• ускорению работы;
• появлению новых функций.

Мнения экспертов

«Если смотреть на развитие Ethereum, переход к более простой структуре состояния выглядит логичным. Слишком сложные модели всегда начинают тормозить рост. Binary tree — это попытка вернуть контроль над базовой логикой сети». — Смирнов Сергей

«Главное здесь — не путать исследование и внедрение. Сейчас Ethereum активно ищет баланс между эффективностью доказательств и надёжностью. И binary tree — лишь один из возможных шагов». — Кононович Николай

Выводы

EIP-7864 — это не просто очередное предложение, а сигнал о направлении развития Ethereum.

Сеть сталкивается с фундаментальными ограничениями:

• сложная структура состояния;
• дорогие доказательства;
• ограничения текущей execution модели.

Binary state tree предлагает один из путей решения — через упрощение и унификацию.

Но это только часть более широкой дискуссии.

Ethereum не «отказывается от EVM» сегодня — он ищет, каким должен быть следующий шаг в развитии всей архитектуры сети.