В течение следующих 5 лет Виталик расширит возможности Ethereum следующим образом

27 февраля 2026 года Виталик Бутерин опубликовал на Ethereum Research длинную статью под названием «Hyper-scaling state by creating new forms of state (Гипермасштабирование состояния через создание новых форм состояния)».

В этой статье Виталик Бутерин подробно изложил пути расширения Ethereum. Документ не только рассматривает технические аспекты масштабирования, но и предлагает поэтапную архитектурную стратегию, направленную на постепенное увеличение пропускной способности сети в ближайшие годы.

Также он опубликовал в X твит, в котором дал дополнительное объяснение этой статье. Попытаемся простыми словами понять, в чем заключается предложенное Виталиком новый подход к масштабированию и почему он необходим.

Краткосрочное и долгосрочное расширение ресурсов выполнения и данных

Виталик в начале статьи отмечает, что «для масштабирования Ethereum в ближайшие пять лет необходимо расширить три вида ресурсов»:

• Ресурсы выполнения: вычисления EVM, проверка подписей и т.п.

• Ресурсы данных: отправитель и получатель транзакции, подписи и т.п.

• Ресурсы состояния: баланс аккаунта, код, хранилище.

Первые два вида ресурсов имеют планы краткосрочного и долгосрочного расширения.

Для ресурсов выполнения краткосрочно планируется увеличение примерно в 10-30 раз за счет улучшений, таких как список доступа к блокам (BAL), ePBS и перерасчет стоимости газа. В долгосрочной перспективе — использование ZK-EVM, что даст примерно 1000-кратный рост, а для некоторых вычислений (подписи, SNARK/STARK) — агрегирование вне цепочки, что повысит производительность примерно в 10 000 раз.

Для ресурсов данных краткосрочно предполагается рост примерно в 10-20 раз за счет улучшений p2p и многоуровневого газа, а долгосрочно — с помощью Blobs + PeerDAS — примерно в 500 раз.

Краткосрочные меры направлены на ускорение работы сети. Сейчас Ethereum медленный потому, что проверка транзакций происходит последовательно — одна за другой. Если одна транзакция застрянет, весь процесс останавливается.

В этом году в рамках обновления Glamsterdam будут внедрены BAL и ePBS.

Баланс доступа к блокам (BAL) позволяет упаковщику блоков заранее сообщить валидаторам: «В этом блоке будут обращаться к таким-то аккаунтам и хранилищам». Это позволяет валидаторам заранее подготовиться, загрузить нужные данные из диска в память, и проверять несколько транзакций параллельно, а не последовательно. Аналогия — конвейер: раньше один работник делал весь продукт, теперь — несколько одновременно выполняют разные части.

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

Пересчет стоимости газа и многоуровневый газ — это, по сути, «ключевые приемы». Сейчас все операции в Ethereum используют одинаковую плату за газ. Виталик предлагает, чтобы разные операции имели разные цены.

Особенно важна «стоимость создания нового состояния» (например, создание нового аккаунта или деплой контракта), которая должна иметь особую «стоимость создания состояния». Это самая дорогая операция, требующая ресурсов вычислений и хранения, и эта стоимость — постоянная, она сохраняется навсегда.

Идея Виталика — сделать создание нового состояния дороже, а обычные транзакции — дешевле.

Для этого предлагается «механизм водохранилища» (reservoir). Представим два бака: один — для «стоимости создания состояния», другой — для обычного газа. При вызове контрактов газ автоматически списывается из обоих баков, чтобы избежать путаницы.

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

Долгосрочная стратегия — сделать основную сеть более мощной и независимой от Layer 2. В рамках этого планируется поэтапное внедрение Blobs + PeerDAS и ZK-EVM.

Blobs — временное хранение больших файлов, сейчас используется в основном для Layer 2. В будущем основная сеть тоже сможет использовать Blobs для хранения данных. Но возникает проблема: если каждый узел скачает все Blobs, сеть может «захлебнуться».

Здесь помогает PeerDAS — не скачивать все данные полностью, а только часть. Аналогия — выборочное исследование: не опрашиваешь каждого, а выбираешь небольшую выборку, чтобы сделать вывод о всей группе. В сочетании с ZK-доказательствами, даже скачав только 1/16 данных, можно подтвердить их целостность.

Затем — поэтапное внедрение ZK-EVM, что позволит проверять блоки без повторного выполнения всех транзакций. Узлы смогут доверять ZK-доказательствам, и проверка снизится с «исполнения всех транзакций» до «проверки одного ZK-доказательства».

План Виталика — к 2026 году часть узлов начнет тестировать ZK-проверки, к 2027 — расширить их использование. В итоге, чтобы блок считался валидным, он должен содержать как минимум 3 из 5 различных типов доказательств, и, по прогнозам, все узлы (кроме индексных) в конечном итоге будут полагаться на ZK-EVM.

Отсутствие «волшебной таблетки» для расширения состояния

Теперь рассмотрим «ресурсы состояния», о которых в краткосрочной перспективе еще говорили, а в долгосрочной — нет.

Почему расширение ресурсов состояния так сложно? Представим, что состояние — это огромная база данных. В ней хранятся балансы аккаунтов, коды контрактов, данные хранилищ.

Объем базы данных сейчас около 100 ГБ, но при увеличении в 20 раз — уже 2 ТБ, а при дальнейшем росте — до 8 ТБ.

Проблема не в том, что диск не вместит, а в следующем:

• Эффективность базы данных падает: современные базы используют деревья (например, Меркл-дерево). Обновление данных требует пересчета всей структуры, что замедляет операции.

• Сложности синхронизации: новый узел должен скачать весь статус, чтобы валидировать блок. При 8 ТБ это займет очень много времени и ресурсов.

Решения есть, но Виталик считает, что у них есть недостатки:

• «Статус без состояния» (statelessness): узлы не хранят весь статус, а только предоставляют Меркл-открытия. Но это ведет к централизации хранения, сложности с динамическим доступом и высоким затратам по пропускной способности.

• «Истечение срока статуса» (stale states): неиспользуемые статусы автоматически удаляются. Узлы хранят только недавно использованные. Но возникает фундаментальная проблема: как доказать, что новый статус никогда не существовал? Например, при создании нового аккаунта нужно доказать, что этот адрес никогда не был создан ранее. Это усложняет и удорожает создание новых аккаунтов.

Виталик предлагает комбинировать эти подходы и вводить новые формы состояния:

• Временное хранилище: автоматически очищающееся, например, дерево, которое сбрасывается раз в месяц. Подходит для временных данных — ордеров, пулов ликвидности, счетчиков.

• Периодическое хранилище: с более длинным циклом, например, год.

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

При этом сохраняются существующие формы состояния. Это позволит снизить стоимость выполнения примерно в 1000 раз (с помощью ZK-EVM), а создание новых состояний — примерно в 20 раз.

Виталик считает, что наличие новых форм состояния даст разработчикам выбор: либо продолжать использовать существующие, платя за это больше, либо перейти на новые формы и получать меньшие издержки. Для стандартных сценариев (балансы ERC20, NFT) появятся стандартные рабочие процессы, а для сложных — разработчики смогут самостоятельно оптимизировать.

Эта стратегия стимулирует разработчиков думать и снижать издержки, что в конечном итоге выгодно для всей экосистемы Ethereum.