27 февраля 2026 года Виталик Бутерин опубликовал длинную статью под названием «Гипермасштабирование состояния путём создания новых форм состояния» на Ethereum Research.

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

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

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

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

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

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

• Государственные ресурсы: баланс счета, код, хранилище

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

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

Что касается ресурсов данных, улучшение P2P и многомерный газ могут достигать примерно в 10-20 раз большего роста в краткосрочной перспективе и примерно в 500 раз большего за счёт Blobs + PeerDAS в долгосрочной.

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

Поэтому в этом году обновление Glamsterdam запустит Block Access List (BAL) и ePBS.

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

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

Переоценка тарифов за газ + многомерный газ можно назвать «перемещением ядра». Теперь все операции на Ethereum используют одну и ту же газовую комиссию. Но идея Виталика в том, что разные предприятия должны иметь разные цены.

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

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

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

Транзакции для обычных пользователей станут дешевле, потому что им не нужно платить «комиссию за создание штата». Застройщикам, желающим создать новый штат, придется платить более высокую плату. Таким образом, общая пропускная способность сети резко возрастает, но рост состояния контролируется, и жёсткие диски всех узлов не взрываются.

Долгосрочное расширение — это увеличение и укрепление основной сети, а также снижение зависимости от Слоя 2. Это включает поэтапное внедрение Blobs + PeerDAS против ZK-EVM.

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

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

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

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

Нет никакого расширения «волшебной пули»

Теперь давайте посмотрим на «государственные ресурсы», которые не обсуждались в краткосрочной и долгосрочной перспективе. Хотя в краткосрочной перспективе его можно улучшить примерно в 5-30 раз за счёт синхронизации с блоковыми списками, улучшения P2P и оптимизации баз данных, но что насчёт долгосрочной перспективы?

Ответ Виталика — нет.

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

База данных небольшая, всего около 100 ГБ, но если увеличить состояние в 20 раз, это будет 2 ТБ. А как насчёт более длительного времени? 8 ТБ?

Проблема не в том, что жёсткий диск не помещается, а:

• Это влияет на эффективность баз данных: современные базы данных используют древесные структуры, такие как деревья Меркла, для организации данных. Когда записываются новые данные, необходимо обновить всё дерево. Это значит, что если вы хотите сделать X обновлений, вы выполните X операций на уровне базы данных, вместо одного обновления и одной операции базы данных. Чем больше обновлений и чем больше операций, тем медленнее записи идут до взрыва.

• Сложности синхронизации: новый узел, присоединяющийся к сети Ethereum, должен скачать всё состояние для проверки нового блока. Если масштаб данных достигает 8 терабайт, текущая скорость интернета у большинства людей будет значительно ниже.

Есть решения, но Виталик считает, что есть проблемы:

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

• «Status Expired»: Редко используемые статусы автоматически удаляются из активного статуса. Узлам нужно хранить только недавно полученное состояние, что может значительно сократить объём памяти. Виталик считает, что существует фундаментальная «экзистенциальная проблема» — как доказать, что государство «никогда не существовало», когда создаётся новое государство. Предположим, что создан новый аккаунт, тогда нужно доказать, что новый адрес никогда не создавался в Ethereum. Это означает, что каждое создание нового аккаунта требует проверки 10-летних исторических данных, что усложняет и делает создание нового аккаунта сложным и дорогостоящим.

Последний подход Виталика — объединить эти две схемы и предложить несколько новых форм состояний, которые полностью изменяют архитектуру ресурсов состояния Ethereum:

• Временное хранение: тип хранилища, срок действия которого автоматически истекает. Например, вы можете создать новое дерево и автоматически очищать его каждый месяц. Это хранилище может использоваться для временных данных, таких как книги ордеров, пулы ликвидности, временные счетчики и т.д., которые обычно не требуют постоянного хранения, а через месяц старый заказ истекает, и создаётся новый пул ликвидности.

• Периодическое хранение: Похоже на временное хранение, но с более длительным сроком, например, 1 год.

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

В то же время сохраняется существующая форма государства. Таким образом, выполнение может быть в 1000 раз дешевле (через ZK-EVM), но создание новых состояний может быть всего в 20 раз дешевле.

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

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