Полный обзор эволюции архитектуры EVM: поэтапная стратегия масштабирования Ethereum

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

Эффективность Ethereum EVM в короткий срок: оптимизация Gas и параллелизация проверки блоков

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

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

Запланированная для внедрения в Glamsterdam ePBS (Encrypted Proposer-Builder Separation) обладает несколькими важными функциями. Особенно стоит отметить, что время, отведенное на верификацию блока в каждом слоте, может быть расширено с традиционных нескольких сотен миллисекунд до более значительных временных долей. Это создаст больше пространства в процессе верификации и позволит безопасно обрабатывать больше данных.

Многофункциональная система газа: инновации в дизайне EVM

Механизм перерасчета газа не является просто корректировкой тарифов, он означает коренной поворот в концепции проектирования EVM. Если стоимость газа для различных операций будет точно соответствовать времени их выполнения и соответствующему потреблению ресурсов, это позволит более эффективно распределять сетевые ресурсы.

Введение многомерного газа позволит эволюционировать механизмы газа, которые ранее управлялись в одном измерении, в структуру, обеспечивающую независимое управление верхними пределами для каждой категории ресурсов. На первом этапе в рамках обновления Glamsterdam планируется отделение «стоимости создания состояния» от «стоимости выполнения и calldata».

Конкретно, в текущей операции SSTORE, когда изменяется слот хранения с нуля на ненулевое значение, расходуется 20000 газа. После повторной оценки в Glamsterdam ожидается, что эта стоимость значительно увеличится и достигнет примерно 60000 газа. Это, на первый взгляд, негативное изменение на самом деле имеет стратегическую цель. Расширяя лимит газа одновременно, можно значительно превысить скорость расширения возможностей выполнения проверки блоков по сравнению с темпами увеличения размера состояния блокчейна.

В существующем дизайне EVM газ реализован как единый измеряемый параметр. Поэтому все операции, такие как GAS и CALL, базируются на этом предположении, однако переход на многомерный газ требует изменения этого основного предположения без нарушения обратной совместимости.

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

В конкретной реализации вводятся N+1 газовых измерений. По умолчанию N=1 (создание состояния), а дополнительное измерение называется «резервуаром». Логика выполнения EVM будет придавать приоритет потреблению газа из выделенных измерений, и в случае нехватки будет происходить дополнительное потребление из резервуара.

Например, при ситуации, когда у вас есть газ (100000, газ для создания состояния и резервуар 100000), если использовать SSTORE для создания нового состояния 3 раза, переход газа будет: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000). В этом дизайне опкод GAS возвращает резервуар, и CALL будет передавать указанное количество газа из резервуара, одновременно передавая весь газ, кроме газа из резервуара.

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

Долгосрочный путь масштабирования: Слияние ZK-EVM и Blobs

Корректировка на короткий срок повышает эффективность существующих EVM, в то время как долгосрочная стратегия масштабирования учитывает более фундаментальные изменения в дизайне. Две основные технологические направления, ZK-EVM (EVM-исполнение с нулевыми знаниями) и Blobs (Блобс), будут формировать будущее Ethereum.

На данный момент, в 2026 году, появление клиентов, поддерживающих ZK-EVM, наконец, становится реальностью. Мы находимся на этапе, когда узлы могут участвовать в атестации (подтверждение подписи в сеть), используя ZK-EVM. Однако на этом начальном этапе эти клиенты еще не достигли достаточного уровня безопасности, поэтому сеть не может полностью на них полагаться. Допускается использование ZK-EVM примерно 5% узлов сети, но принятие на более высоком уровне будет отклонено. На этом этапе, если возникают проблемы с доказательством ZK-EVM, вознаграждения за стекинг отдельных узлов не будут конфискованы, но может возникнуть возможность построения недействительных блоков, что может привести к потере дохода этого узла.

В 2027 году рекомендуется перейти к этапу, на котором большее количество узлов будет выполнять ZK-EVM. Это время, когда акцент будет сделан на формальную проверку и постоянное улучшение безопасности. Важно отметить, что всего 20% узлов сети используют ZK-EVM, что позволит обеспечить низкозатратные пути верификации для соло-стейкеров и значительно улучшить лимит газа. Учитывая, что общее число соло-стейкеров составляет менее 20% сети, улучшения на этом этапе принесут пользу многим пользователям.

На этапе, когда технология достаточно созрела, планируется внедрение механизма принудительного доказательства 3 из 5. Это означает, что для того чтобы блок считался действительным, он должен содержать как минимум 3 доказательства из 5 различных систем доказательства. Этот разнообразный механизм доказательства позволяет снизить риски, связанные с зависимостью от единой технологии, и тем самым повысить устойчивость сети. На следующем этапе ожидается, что большинство узлов перейдут на зависимость от ZK-EVM доказательства, за исключением узлов, которым необходима индексная функция.

В долгосрочной перспективе планируется дальнейшее улучшение ZK-EVM, а также проведение более строгой формальной верификации. На этом этапе также рассматриваются структурные изменения на уровне виртуальной машины, включая направления, такие как RISC-V. Это предполагает возможность радикального эволюционирования самого проектирования EVM.

Эволюция Blobs и высокоуровневых слоев данных

Что касается Blobs, то благодаря постоянным улучшениям транспортного уровня PeerDA в конечном итоге планируется достичь пропускной способности данных около 8 МБ/с. Этот уровень обработки данных соответствует масштабу, который может вполне удовлетворить спрос самого Ethereum. Однако Ethereum не намерен становиться глобальным уровнем данных, а лишь удовлетворять потребности как независимая сеть.

В настоящее время Blobs в основном используются для хранения данных в решениях второго уровня (L2). В качестве будущей эволюции рассматривается возможность непосредственной записи данных самого блока Ethereum в Blobs. Цель данного изменения является крайне важной. Это позволит проверять высокомасштабированную сеть Ethereum без необходимости загружать и повторно выполнять всю цепочку.

Для достижения этой цели необходимо сочетание двух важных технологий. Во-первых, благодаря ZK-SNARKs (недоступные доказательства с нулевым знанием), сам процесс повторного выполнения становится ненужным. Во-вторых, благодаря PeerDAS и Blobs становится возможным проверять доступность данных, не загружая все данные. Это сочетание делает возможным полноценное участие в верификации сети даже для легковесных узлов.

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