27 февраля 2026 года Виталик Бутерин опубликовал на Ethereum Research длинную статью под названием «Hyper-scaling state by creating new forms of state».
В этой статье Виталик Бутерин подробно изложил путь масштабирования Ethereum. Эта статья не только рассматривает масштабирование Ethereum с технической точки зрения, но и предлагает целостную архитектурную стратегию поэтапного масштабирования, направленную на создание основы для постоянного увеличения пропускной способности сети Ethereum в ближайшие годы.
В то же время он опубликовал твит на X, дополнительно пояснив эту статью. Мы попытаемся понять, что именно представляет собой новое предложение по масштабированию, выдвинутое Виталиком, и зачем ему это нужно.
Краткосрочное и долгосрочное расширение ресурсов выполнения и ресурсов данных
В начале своей подробной статьи Виталик отметил: «Для масштабирования Ethereum в течение следующих пяти лет необходимо масштабировать три ресурса»:
- Ресурсы выполнения: вычисления EVM, проверка подписей и т.д.
- Ресурсы данных: отправитель, получатель, подпись и другие данные транзакции
- Ресурсы состояния: баланс счета, код, хранилище
Первые два имеют краткосрочные и долгосрочные планы развития.
Для вычислительных ресурсов краткосрочный рост в 10–30 раз достигается за счет списка доступа к блокам (BAL), ePBS и переоценки газа, долгосрочный рост в ~1000 раз — за счет ZK-EVM, а для некоторых специфических типов вычислений (подписи, SNARK/STARK) агрегация вне цепочки может повысить производительность примерно в 10 000 раз.
Для ресурсов данных краткосрочный рост в 10–20 раз будет достигнут за счет улучшений P2P и многомерного Gas, а долгосрочный рост в около 500 раз — за счет Blobs + PeerDAS.
Краткосрочное расширение направлено на ускорение работы Ethereum. Сейчас Ethereum работает медленно, потому что текущий способ проверки является последовательным — транзакции проверяются одна за другой. Если какая-либо транзакция застревает, весь процесс проверки останавливается.
Таким образом, в рамках следующего апгрейда Glamsterdam этого года будут внедрены список доступа к блокам (BAL) и ePBS.
Список доступа к блокам позволяет сборщику блоков заранее сообщить валидаторам: «Транзакции в этом блоке будут обращаться к этим аккаунтам и местам хранения». С этой информацией валидаторы могут заранее подготовиться и загрузить эти данные с жесткого диска в память. Затем валидаторы могут параллельно проверять несколько транзакций, а не по одной. Как конвейер на заводе: раньше один рабочий отвечал за весь продукт, теперь несколько рабочих одновременно обрабатывают разные части.
ePBS разделяет процесс упаковки и проверки блоков — сборщик блоков отвечает за упаковку транзакций, предложчик — за предложение блока, а валидаторы — за проверку блока. Каждая роль выполняет свою задачу, поэтому сборщик блоков может более агрессивно упаковывать больше транзакций, так как предложчик и валидаторы проверяют его работу, и ему не нужно беспокоиться о безопасности.
Переоценка комиссий за газ + многомерный газ можно назвать «ключевым приёмом». Сейчас все операции в Ethereum используют одну и ту же комиссию за газ. Но идея Виталика заключается в том, что разные операции должны иметь разную цену.
В частности, для создания нового состояния (например, создания нового аккаунта или развертывания нового контракта) должна взиматься специальная «плата за создание состояния», поскольку создание нового состояния — самая дорогостоящая операция. Она требует не только вычислительных ресурсов, но и ресурсов хранения. При этом эта стоимость является постоянной — после создания состояние будет существовать постоянно.
Таким образом, идея Виталика заключается в том, чтобы сделать создание нового состояния более дорогим, но сделать обычные транзакции более дешевыми.
Метод реализации — «механизм резервуара». Представьте два ведра: одно хранит «плату за создание состояния», другое — «обычную плату за газ». При взаимных вызовах смарт-контрактов газ автоматически заимствуется из обоих резервуаров, что гарантирует отсутствие сбоев.
Торговля обычных пользователей станет дешевле, так как эти транзакции не требуют оплаты «комиссии за создание состояния». Разработчики, желающие создавать новые состояния, должны будут платить более высокую комиссию. Таким образом, общая пропускная способность сети резко возрастает, но рост состояний контролируется, предотвращая переполнение жестких дисков полных узлов.
Долгосрочное расширение заключается в укреплении и развитии основной сети, снижая зависимость от Layer 2. Это включает поэтапный запуск Blobs + PeerDAS и ZK-EVM.
Blobs — это временная система хранения больших файлов, которая сейчас в основном используется Layer 2. В будущем сама основная сеть Ethereum также будет использовать Blobs для хранения данных. Но возникает проблема — если каждый узел должен скачивать все Blobs, сеть будет перегружена.
Здесь на помощь приходит PeerDAS — не нужно скачивать все данные, достаточно скачать лишь небольшую их часть. Как в выборочном опросе: не нужно спрашивать каждого, достаточно опросить небольшую группу, чтобы сделать выводы о всей совокупности. В сочетании с ZK-доказательствами, даже скачав лишь 1/16 всех данных, вы сможете подтвердить их целостность.
Затем следует поэтапный вывод ZK-EVM, благодаря которому проверка блока больше не требует повторного выполнения всех транзакций в блоке — узлы могут просто доверять ZK-доказательству, и стоимость проверки снижается с «выполнения всех транзакций» до «проверки одного ZK-доказательства».
План Виталика заключается в том, что в 2026 году часть узлов начнет экспериментальное использование ZK-валидации. К 2027 году будет поощряться более широкое использование этого метода. В конечном итоге для того, чтобы блок считался действительным, он должен содержать три типа доказательств из пяти различных систем доказательств. Он ожидает, что в конечном итоге все узлы (за исключением индексных узлов) будут полагаться на ZK-EVM-доказательства.
Расширение состояния без «волшебной таблетки»
Теперь давайте рассмотрим «ресурсы состояния», о которых не говорилось в контексте краткосрочного и долгосрочного масштабирования. Хотя в краткосрочной перспективе всё ещё возможно повысить производительность примерно в 5–30 раз за счёт синхронизации со списком доступа к блокам, улучшений P2P и оптимизации базы данных, а в долгосрочной?
Ответ Виталика — нет.
Почему состояние так сложно масштабировать? Состояние Ethereum — это огромная база данных. В этой базе данных хранятся балансы всех аккаунтов, код всех смарт-контрактов и данные всех мест хранения.
Сейчас эта база данных еще небольшая — около 100 ГБ, но если увеличить состояние в 20 раз, получится 2 ТБ. А если время будет еще больше? 8 ТБ?
Проблема не в том, что на жестком диске не хватает места, а в том, что:
Производительность базы данных снижается: современные базы данных используют древовидные структуры (например, деревья Меркла) для организации данных. При записи новых данных необходимо обновлять всё дерево. Это означает, что если вам нужно выполнить X обновлений, на уровне базы данных это будет X операций, а не одна операция обновления, после которой база данных выполняет одну операцию. Чем больше обновлений, тем больше операций, и запись становится настолько медленной, что взрывается.
Сложности с синхронизацией: новый узел, присоединяющийся к сети Ethereum, должен загрузить весь состояние, чтобы проверить новые блоки. Если объем данных достигает 8 ТБ, большинству пользователей потребуется очень много времени для загрузки при текущих скоростях интернета.
Решения существуют, но Виталик считает, что у всех них есть проблемы:
- «Сильная безсостоятельность»: узлы не должны хранить полное состояние, достаточно, чтобы пользователь предоставлял Merkle-доказательства. Виталик считает, что этот подход вызывает проблемы централизации хранения состояния, сбои транзакций из-за динамического доступа к хранилищу и высокие затраты на пропускную способность.
- «Истекший статус»: статусы, которые не часто используются, автоматически удаляются из активных. Узлам необходимо хранить только недавно доступные состояния, что значительно сокращает объем хранимых данных. Виталик считает, что существует фундаментальная «проблема»: как доказать, что некоторое состояние «никогда не существовало» при создании нового состояния. Например, при создании нового аккаунта необходимо доказать, что адрес нового аккаунта никогда ранее не создавался в Ethereum. Это означает, что для создания каждого нового аккаунта необходимо проверять исторические данные за последние 10 лет, что делает создание новых аккаунтов сложным и дорогостоящим.
Финальный подход Виталика заключается в объединении этих двух решений и предложении нескольких новых форм состояния, что представляет собой общее изменение архитектуры ресурсов состояния Ethereum:
- Временное хранилище: хранилище, которое автоматически истекает. Например, можно создать новое дерево, которое автоматически сбрасывается каждый месяц. Такое хранилище подходит для временных данных, таких как стакан заказов, пулы ликвидности, временные счетчики — данные, которые не требуют постоянного хранения. Через месяц старые заказы истекают, а новые пулы ликвидности создаются.
Периодическое хранение: аналогично временному хранению, но с более длительным периодом, например, 1 год.
Ограниченное хранение: некоторые данные можно доступать только определённым способом. Например, баланс ERC20-токена может быть доступен только через определённый интерфейс. Это позволяет системе оптимизировать такое хранение.
В то же время сохраняйте существующий формат состояния. Таким образом, выполнение может быть в 1000 раз дешевле (через ZK-EVM), но создание нового состояния может быть дешевле только в 20 раз.
Виталик считает, что с новой формой состояния у разработчиков появляется выбор: продолжать использовать существующую форму состояния, но платить более высокую комиссию, или переработать приложение, чтобы использовать новую форму состояния и получить более низкие комиссии. Для распространённых сценариев использования (например, балансы ERC20, NFT) будут стандартизированные рабочие процессы, а для более сложных сценариев (например, DeFi) разработчикам нужно будет самостоятельно искать способы оптимизации.
Эта стратегия довольно интересна и напоминает, как разработчики прилагают усилия для снижения затрат, а широкие пользователи Ethereum получают выгоду.