Paradigm CTO: Интерпретация пражского хардфорка после обновления Ethereum Cancun

Слова: Георгиос Константопулос, технический директор, Paradigm

Составитель: Luffy, Foresight News

Цель этой статьи — предоставить обзор взглядов команды Paradigm Reth на то, какие EIP должны быть включены в Prague Hard Fork (следующее крупное обновление Consensus Ethereum после хардфорка Cancun) и наш общий план для «EL Core Dev» в 2024 году. Следующие представления постоянно развиваются и отражают текущие взгляды команды Reth и не обязательно представляют всю команду Paradigm.

Мы считаем, что пражский хардфорк, скорее всего, материализуется в тестовой сети Ethereum в 3 квартале 2024 года и в основной сети к концу года. Он должен включать:

• EIP, связанные со стейкингом, такие как EIP-7002, который поддерживает повторный стейкинг и пулы стейкинга без доверия.
• Отдельные вариации EVM.
• Мы готовы работать с любой командой, которая хочет глубже изучить Прагу или другой будущий хардфорк EL, и будем рады предоставить рекомендации и помощь в изменении кодовой базы Reth.

Что делать:

• Мы считаем, что следующие EIP должны быть приоритетными: 7002, 6110, 2537.
• Мы поддерживаем EOF, описанный в спецификации, и надеемся как можно скорее завершить работу над объемом работ и создать мета-EIP.
• Мы готовы добавить EIP-4844 Max Blob Gas. У нас нет мнения о конкретных цифрах, но мы приглашаем специалистов по работе с данными поработать с нами над этой темой.
• Мы рады выпустить версию EIP-7547: она содержит список, помогающий базовому слою противостоять цензуре.

Чего нельзя делать:

• Мы не поддерживаем включение Verkle Tries в пражский хардфорк, но поддерживаем клиентскую команду, чтобы начать работу над этим во 2 квартале 2024 года с обязательством выпустить обновление в Осаке в 2025 году.
• Мы не думаем, что нам следует увеличивать лимит газа исполнения L1 или размер контракта, но мы приглашаем специалистов по обработке данных работать с нами, чтобы исследовать его влияние на сеть. Мы готовы изменить наше восприятие, потому что прошлые тесты показали, что Reth Node может справиться с возросшей нагрузкой без каких-либо проблем.
• Мы считаем, что EIP Wallet/Account Abstraction необходимо тестировать более состязательно друг с другом, чтобы лучше понять пространство компромисса. Если они не являются взаимоисключающими, то в будущем мы будем готовы развернуть несколько EIP, связанных с AA.
• Если сообщество согласится со слухами о бэкдоре АНБ, мы можем пересечь черту на EIP-7212 (secp256r1).
• Другие темы дорожной карты: У нас нет фактического понимания сопряжения CL EIP или форков CL/EL, но EIP 7549 и 7251 выглядят многообещающими. Мы также хотим внести свой вклад в работу PeerDAS со стороны EL, насколько это возможно. На данный момент мы хотим избежать введения корней SSZ (EIPs 6404, 6465, 6466). Наконец, мы видим возможность предоставить долгосрочное решение для архивирования данных для просроченных BLOB-объектов, истории и состояния, поскольку и EIP-4844, и EIP-4444 ясно дают это понять, и еще предстоит определить, готов ли Ethereum предоставить такое решение.

Подробнее об этом мы поговорим ниже.

Чем заняться

В аннотации мы выступаем за то, чтобы: 1) дальнейшее преодоление разрыва между CL и EL, и 2) модификации EVM могут быть выполнены как самостоятельная работа, так и могут быть протестированы отдельно и параллельно.

EIP-7002

Этот EIP разблокирует не требующий доверия рестейкинг и пулы стейкинга, позволяя смарт-контракту на стороне EL контролировать 1 или более валидаторов на стороне CL. На наш взгляд, это, по крайней мере, позволит существующим стейкинг-пулам удалить уровень централизации из смарт-контракта, который позволяет выводить средства.

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

EIP-6110

EIP вводит депозиты в состоянии EL, упрощая управление состоянием, которое необходимо осуществлять на CL. С точки зрения реализации, это похоже на отслеживание вывода средств CL, поэтому в целом мы считаем, что это также простой и автономный EIP.

EIP-2537

В настоящее время существует несколько реализаций BLS12-381, который является часто используемой кривой во многих SNARK, алгоритмах подписи BLS и EIP-4844. Мы считаем, что он имеет низкую сложность реализации, поскольку предоставляет алгоритм валидации кривой только через предварительно скомпилированный интерфейс. Нам также может понадобиться предварительно скомпилированный хеш кривой BLS12-381.

ЕОФ

*Примечание переводчика: EOF расшифровывается как EVM Object Format, что переводится в формат объекта Ethereum и содержит ряд EIP, которые обещают сделать исполнение Ethereum более эффективным, согласованным и обновляемым. Ранние планы были реализованы в Шанхайской модернизации, которая позже была отменена. *

EOF будет поддерживать как Solidity, так и Vyper. Нет никаких сомнений в том, что настройки форматирования и верификации кода значительно упростят анализ байт-кода, и мы рекомендуем тщательно обдумать все остальное. Ниже мы порекомендовали несколько EIP, но мы готовы доработать их.

Из положительных моментов:

• Изменения только для EVM, которые могут быть протестированы с помощью Ethereum / Testnet и реализованы одним человеком.
• Изменения EVM, которые хотят Vyper и Solidity
• Помогает повысить производительность и увеличить лимиты на размер контракта.
• Устраняет необходимость в анализе байт-кода во время выполнения EVM. Без кэширования время анализа может достигать 50% и увеличиваться по мере увеличения размера контракта.
• Включите частичную загрузку кода для выполнения больших смарт-контрактов.
• Devex: Позволит исправить проблему “слишком глубокого стека” с помощью dupN/swapN и других улучшений инструментов.
• Задел на будущее: новые функции могут быть безопасно внедрены в L2, и инструмент будет знать, что совместимо.

Плохие аспекты:

• Дальность и динамические цели. • Нет сильного давления со стороны сторонников на его включение.
• Поддержка устаревшего кода по-прежнему требуется
• До принятия существовали временные разногласия между EthereumMainnet и другими цепочками EVM.

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

• EIP-3540 (EOF - EVM Object Format v1): Вводит контейнеры кода и данных, а также добавляет структуру и управление версиями в байт-код Ethereum.
• EIP-3670 (EOF - Code Validation): отклоняет любой контракт, который не соответствует формату EOF при развертывании. Выполняйте более структурированный код и отключайте недопустимые и неопределенные директивы.
• EIP-663 (Infinite SWAP & DUP Instructions): Это решает проблему «слишком глубокого стека» в твердости и имеет побочные эффекты в виде мгновенного значения с помощью анализа JUMPDEST. Очень желательная особенность языка EVM.
• EIP-4200 (EOF - Static Relative Jumps): Улучшенный статический анализ без неопределенных скачков. Улучшена компиляция AOT. Переходы более благоприятны для повторного использования кода.
• EIP-4750 (EOF - Функция): Требуется разрешение подпрограмм, которые могут использовать динамические, но не статические переходы. Он также позволяет загружать частичный код, что отлично работает с Verkle для увеличения лимита размера контракта.
• EIP-5450 (EOF - Stack Validation): проверка кода и требований к стеку. Удаление проверок переполнения стека времени выполнения для всех инструкций, кроме CALLF (EIP-4750)
• EIP-7480 (EOF - Data Section Access Instruction): Разрешает доступ к части данных байт-кода.
• EIP-7069 (Improved CALL Directive): Возможность убрать наблюдаемость газа из CALL, что упрощает переоценку газа в будущем. Несмотря на независимость от EOF, мы рассматриваем это как хорошую возможность для его внедрения.

Мы не так уверены в EIP-6206 (EOF - JUMPF и функция невозврата). Несмотря на то, что он позволяет оптимизировать хвостовые вызовы в функциях EOF, нам все еще нужно посмотреть, что для этого делает профилирование языка. Если мы этого не сделаем, мы думаем, что можем удалить его из области действия и включить в последующее обновление EOF.

По нашим оценкам, вышеуказанная нагрузка составляет 1 человек, работающий полный рабочий день в течение 1-2 месяцев. Мы готовы сузить его еще больше.

Примечание о устаревшем байт-коде:

• В то время как мы можем запретить новый устаревший байт-код, мы не можем объявить устаревшим существующий устаревший байт-код, который фактически действует как EOF “v0”. Устаревший байт-код по-прежнему требует анализа JUMPDEST после EOF и по-прежнему требует специальной обработки кода для фрагментации его на фрагменты в Verkle Trys.
• Насколько нам известно, невозможно проверить преобразование байт-кода, отличного от EOF, в EOF без доступа к исходному коду, но мы готовы изучить механизмы, облегчающие это преобразование.
• В качестве альтернативы мы хотели бы изучить способы принудительной миграции штатов на EOF.

Увеличение количества больших двоичных объектов EIP-4844

Мы открыты для этого изменения, которое будет соответствовать увеличению MAX_BLOB_GAS_PER_BLOCK и TARGET_BLOB_GAS_PER_BLOCK. EIP-4844 гласит:

Выберите значения TARGET_BLOB_GAS_PER_BLOCK и MAX_BLOB_GAS_PER_BLOCK, чтобы соответствовать целевому объекту из 3 больших двоичных объектов (0,375 МБ) на блок (до 6 больших двоичных объектов). Эти небольшие начальные ограничения предназначены для минимизации нагрузки на сеть, вызванной EIP, и ожидается, что количество больших двоичных объектов увеличится в будущих обновлениях, поскольку сеть демонстрирует надежность на больших блоках.

На самом деле, это небольшое изменение кода, и нам нужно исследовать его фактическое влияние на пул транзакций, но мы подумали, что можем повторно использовать для этого инфраструктуру стресс-тестирования EIP-4844. Для CL может быть трудно распространить больше блобов, и мы уважаем мнение команды CL.

Не делай

Веркл пытается

Tl; Краткий итог: Мы не видим попыток развернуть Verkle в конце 2024 — начале 2025 года. Мы рекомендуем команде выделить ресурсы для этого во 2-м квартале 2024 года и взять на себя обязательство выполнить развертывание в хардфорке Osaka во 2-3 кварталах 2025 года.

Из положительных моментов:

• Позволяет использовать более дешевые легкие клиенты с меньшими объемами памяти.
• Выполнение без сохранения состояния путем включения предсостояния чтения в заголовок блока, что также может привести к повышению производительности за счет доступа к статическому состоянию.
• Увеличьте предельный размер контракта, разделив байт-код и включив частичную загрузку кода.
• Экспирация статуса стала более приемлемой из-за более низкой стоимости «восстановления» статуса.

Недостатки:

• Влияние изменений и усилий по внедрению и тестированию.
• Изменения в расчете газа: Verkle Tries вводит размер следящего сервера в функцию расчета газа. Мы обеспокоены тем, что изменения в ценообразовании на хранение газа еще не изучены (например, какова стоимость основных потребителей газа после Веркле)?
• Интеграция приложений: Что должно делать приложение с валидатором Merkle Patricia Trie при выполнении перехода Overlay? Как вести себя eth_getProof?

Несмотря на то, что мы понимаем преимущества Verkle Try, мы считаем, что необходимо уделять больше внимания тому, как сторонние инструменты/контракты должны вписываться в систему, и какое влияние это окажет на уровень 2 и тому подобное в течение переходного периода. Первоначально у нас были сомнения по поводу стратегии миграции, потому что в ней говорилось, что попытка Verkle должна обновляться при чтении состояния из ранее существовавшего MPT, но, похоже, это уже не так. Поэтому мы поддерживаем оверлейный подход как жизнеспособный путь миграции.

Документация по стратегии миграции Verkle кажется устаревшей, так как в большинстве ресурсов по-прежнему указано, что Verkle try должен обновляться при чтении состояния из MPT. Мы хотели бы видеть документацию по переходу с новейшими подходами, такими как этот, превосходный. Мы также хотели бы увидеть проект EIP по стратегии перехода.

Поэтому мы по-прежнему поддерживаем его развертывание в 2025 году вместо развертывания в Пражском хардфорке.

Лимит газа L1

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

Мы приглашаем других к сотрудничеству с нами в исследованиях в этом направлении, часто связанных с нарушением учета ресурсов в EVM. Диссертация «Сломанный метр» является хорошей отправной точкой для исследований в этой области.

Абстракция аккаунта

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

• EIP-3074: код операции AUTH и AUTHCALL
• ERC-4337: Использование альтернативного мемпула для абстракции учетной записи
• EIP-5806: Делегированная транзакция
• EIP-5920: Код операции PAY
• EIP-6913: директива SETCODE
• EIP-7377: Транзакции миграции
• RIP-7560: Абстракция собственной учетной записи - Core EIP - Fellowship of Ethereum Magicians

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