Модернизация Праги после модернизации Канкуна может быть реализована к концу 2024 года.
Менеджер: Георгиос Константинопулос, технический директор Paradigm
Составлено: Луффи, Foresight News
Цель этой статьи — изложить точку зрения команды Paradigm Reth на то, какой EIP следует включить в хард-форк в Праге (следующее крупное обновление Ethereum после хард-форка в Канкуне), а также наш общий план для «EL Core Dev» на 2024 год. Примечание: EL относится к уровню исполнения, CL относится к уровню консенсуса). Следующие взгляды постоянно развиваются и представляют собой только текущие взгляды команды Reth и не обязательно отражают всю команду Paradigm.
Мы считаем, что хардфорк Праги может быть реализован в тестовой сети Ethereum в третьем квартале 2024 года и завершен в основной сети к концу года. Он должен включать:
- EIP, связанные со стейкингом, например EIP-7002, который поддерживает повторную стейкинг и пулы стейкинга без доверия.
- Отдельные изменения EVM.
- Мы открыты для работы с любой командой, которая хочет продолжить исследование Bragg или других будущих хард-форков EL, и рады предоставить рекомендации и помощь при внесении изменений в кодовую базу Reth.
Что делать:
- Мы считаем, что приоритет должен быть отдан следующим EIP: 7002, 6110, 2537.
- Мы поддерживаем EOF, как описано в спецификации, и надеемся в ближайшее время окончательно определить область действия и создать мета-EIP.
- Мы готовы добавить EIP-4844 Max Blob Gas. У нас нет мнения о точных цифрах, но мы приглашаем специалистов по работе с данными поработать с нами над этой темой.
- Мы хотели бы выпустить версию EIP-7547: она содержит список, помогающий сделать базовый уровень устойчивым к цензуре.
Чего не делать:
- Мы не поддерживаем включение Verkle Tries в хард-форк Праги, но поддерживаем команду клиента, чтобы она начала работу над ним во втором квартале 2024 года и взяла на себя обязательство выпустить его в обновлении Осака в 2025 году.
- Мы не считаем, что лимиты газа для исполнения L1 или размеры контрактов должны быть увеличены, но мы приглашаем специалистов по обработке данных работать с нами, чтобы изучить их влияние на сеть. Мы готовы изменить нашу настройку, поскольку прошлые испытания показали, что узлы Reth могут без проблем справляться с возросшей нагрузкой.
- Мы считаем, что EIP абстракции кошелька/аккаунта нуждаются в дополнительном тестировании друг против друга, чтобы лучше понять пространство компромиссов. В будущем мы были бы готовы развернуть несколько EIP, связанных с AA, если они не являются взаимоисключающими.
- Если сообщество согласится со слухами о бэкдоре АНБ, мы можем обойти линию на EIP-7212 (secp256r1).
- Другие темы дорожной карты: у нас нет реальных знаний о сочетании вилок CL EIP или CL/EL, но EIP 7549 и 7251 выглядят многообещающе. Мы также надеемся внести максимальный вклад в работу PeerDAS со стороны EL. В настоящее время мы хотим избежать введения корней SSZ (EIP 6404, 6465, 6466). Наконец, мы видим возможность предоставить долгосрочное решение для архивирования данных для просроченных больших двоичных объектов, истории и состояния, и поскольку и EIP-4844, и EIP-4444 явно заявляют об этом, еще предстоит определить, готов ли Ethereum предоставить такое решение.
Подробно разверните ниже.
Дела, которые необходимо сделать
Абстрактно мы поддерживаем 1) дальнейшее сокращение разрыва между CL и EL и 2) модификации EVM могут выполняться одним человеком и тестироваться индивидуально и параллельно.
ЭИП-7002
Этот EIP открывает возможность безопасной повторной ставки и пулов ставок, позволяя смарт-контрактам на стороне EL контролировать 1 или несколько валидаторов на стороне CL. По нашему мнению, это, по крайней мере, позволит существующим пулам ставок убрать уровень централизации из смарт-контрактов, которые позволяют осуществлять вывод средств.
Внедрение предварительной компиляции с сохранением состояния в EVM — это новая абстракция, которую нам нужно реализовать в реализации EVM, но в остальном мы считаем, что это EIP, который можно реализовать напрямую.
ЭИП-6110
Этот EIP вводит депозиты в состоянии EL, упрощая управление состоянием, которое необходимо выполнять в состоянии CL. С точки зрения реализации это похоже на отслеживание вывода средств CL, поэтому в целом мы считаем, что это также простой и автономный EIP.
ЭИП-2537
В настоящее время существует несколько реализаций BLS12-381, которая часто используется во многих SNARK, алгоритмах подписи BLS и EIP-4844. Мы считаем, что сложность его реализации очень низка, поскольку он предоставляет алгоритм проверки кривой только через предварительно скомпилированный интерфейс. Нам также могут понадобиться предварительно скомпилированные хеши для кривой BLS12-381.
ЭОФ
*Примечание переводчика: EOF означает «Формат объекта EVM», который переводится как «Формат объекта Ethereum». Он содержит серию EIP и обещает сделать исполнение Ethereum более эффективным, последовательным и обновляемым. Ранние планы были реализованы в обновлении Shanghai, но позже были удалены. *
EOF будет поддерживать как Solidity, так и Vyper. Нет сомнений в том, что корректировки форматирования и проверки кода упростят анализ байт-кода, и мы рекомендуем внимательно отнестись к этому. Ниже мы рекомендовали некоторые EIP, но мы готовы их доработать.
хороший аспект:
- Изменения только для EVM, которые можно протестировать с помощью Ethereum/testnet и реализовать одним человеком.
- Изменения EVM, необходимые Vyper и Solidity
- Помогает повысить производительность и увеличить ограничения на размер контракта.
- Устраняет необходимость EVM выполнять анализ байт-кода во время выполнения. Без использования кэширования время анализа может достигать 50% и увеличивается с размером контракта.
- Включите частичную загрузку кода, чтобы облегчить выполнение больших смарт-контрактов.
- Devex: позволит исправить проблемы «слишком глубокого стека» с помощью dupN/swapN и других улучшений инструмента.
- Перспективность: новые функции можно безопасно внедрять на уровне L2, и инструменты будут знать, какие из них совместимы.
плохая сторона:
- Объем и динамические цели.
- Сторонники не настаивали на его включении.
- Все еще требуется поддержка устаревшего кода.
- До принятия существовало временное расхождение между основной сетью Ethereum и другими цепочками EVM.
Мы считаем, что следующие возможности EOF должны быть развернуты в 2024 году. Мы рекомендуем определить объем и приступить к реализации как можно скорее. Ничто другое не должно рассматриваться при последующих развертываниях. Наш совет:
- EIP-3540 (EOF — формат объекта EVM v1): вводит контейнеры кода и данных, а также добавляет структуру и управление версиями в байт-код Ethereum.
- EIP-3670 (EOF — проверка кода): отклонить любой контракт, который не соответствует формату EOF при развертывании. Выполняйте более структурированный код и отключайте недопустимые и неопределенные инструкции.
- EIP-663 (неограниченное количество инструкций SWAP и DUP): это устраняет проблему «слишком глубокого стека» в надежности и побочных эффектах в виде немедленных значений посредством анализа JUMPDEST. Очень желанная функция для языка evm.
- EIP-4200 (EOF — статические относительные переходы): улучшенный статический анализ, отсутствие неопределенных переходов. Лучше компиляция. Относительные переходы более благоприятны для повторного использования кода.
- EIP-4750 (EOF — функция): Необходимо указать подпрограммы, которые могут использовать динамические переходы, но не статические переходы. Он также позволяет выполнять частичную загрузку кода, что отлично работает с Verkle и позволяет увеличить ограничения на размер контракта.
- EIP-5450 (EOF — проверка стека): проверьте требования к коду и стеку. Удалите проверки на опустошение и переполнение стека во время выполнения для всех инструкций, кроме CALLF (EIP-4750).
- EIP-7480 (EOF — Инструкция доступа к части данных): Разрешить доступ к части данных байт-кода.
- EIP-7069 (Улучшенная инструкция CALL): возможность исключить возможность наблюдения за газом из CALL, что упрощает переоценку газа в будущем. Несмотря на независимость от EOF, мы считаем, что это хорошая возможность представить его.
Мы не столь уверены в EIP-6206 (EOF - JUMPF и невозвратные функции). Хотя он позволяет оптимизировать хвостовые вызовы в функциях EOF, нам все равно нужно увидеть, как язык анализирует, что он делает. Если мы этого не сделаем, мы думаем, что его можно удалить из области применения и включить в последующие обновления EOF.
По нашим оценкам, указанная выше нагрузка требует, чтобы один человек работал полный рабочий день в течение 1-2 месяцев. Мы хотели бы еще больше сузить вышеуказанную сферу.
Примечание о устаревшем байт-коде:
- Хотя мы можем отключить новый устаревший байт-код или не-EOF, мы не можем отказаться от существующего устаревшего байт-кода, который фактически действует как EOF «v0». Устаревший байт-код по-прежнему требует анализа после EOF JUMPDEST, а для его сегментации на фрагменты в Verkle Tries по-прежнему требуется специальная обработка кода.
- Насколько нам известно, невозможно проверить преобразование байт-кода, отличного от 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 может быть сложно распространять больше BLOB-объектов, и мы уважаем мнение команды CL.
Чего нельзя делать
Примерки платьев
TL;DR: Мы не видим попыток развернуть Verkle в конце 2024 — начале 2025 года. Мы рекомендуем команде выделить на это ресурсы во втором квартале 2024 года и взять на себя обязательства по развертыванию хард-форка в Осаке во втором-третьем кварталах 2025 года.
хороший аспект:
- Включите более дешевые легкие клиенты с меньшим объемом хранилища.
- Включите выполнение без сохранения состояния, включив предварительное состояние чтения в заголовок блока, что также может привести к повышению производительности за счет доступа к статическому состоянию.
- Увеличьте лимит размера контракта, разбивая байт-код на части и включив частичную загрузку кода.
- Из-за более низкой стоимости «восстановления» состояний истечение срока действия состояний становится более приемлемым.
Плохое место:
- Влияние изменений, усилий по внедрению и тестированию.
- Изменения в расчете газа: Verkle Tries вводит размер свидетеля в функцию расчета газа. Нас беспокоят изменения в ценах на хранение, которые еще не изучены (например, сколько будет стоить крупнейший потребитель газа после Verkle)?
- Интеграция приложений: что должны делать приложения с валидаторами Merkle Patricia Trie, когда выполняется переход Overlay? Как должен вести себя eth_getProof?
Хотя мы понимаем преимущества Verkle Tries, мы считаем, что необходимо уделить больше внимания тому, как сторонние инструменты/контракты должны адаптироваться, и какое влияние этот переходный период окажет на уровень 2 и т. д. Первоначально у нас были проблемы с политикой миграции, поскольку в ней говорилось, что дерево Verkle должно обновляться при чтении состояния из уже существующего MPT, но, похоже, это уже не так. Поэтому мы поддерживаем подход Overlay как жизнеспособный путь миграции.
Документация по стратегии миграции Verkle кажется устаревшей, поскольку в большинстве ресурсов по-прежнему указывается, что дерево Verkle должно обновляться при чтении состояния из MPT. Мы хотели бы видеть документацию по переходу, в которой используется современный подход, например, эта замечательная документация. Мы также хотели бы увидеть проект EIP по стратегии перехода.
Поэтому мы по-прежнему поддерживаем его запуск в 2025 году, а не развертывание в рамках хард-форка Праги.
Предел газа L1
Мы считаем, что увеличение лимита газа L1 не будет иметь большого значения на практике. Мы также считаем, что большинство клиентов смогут справиться с увеличением средней нагрузки, но мы хотим сохранять бдительность в отношении наихудших сценариев, поэтому в настоящее время мы не рекомендуем увеличивать лимит газа L1. Мы считаем, что увеличение лимита газа-капли является более многообещающим решением в краткосрочной перспективе.
Мы приглашаем других сотрудничать с нами в исследованиях в этом направлении, часто связанных с нарушением измерения ресурсов в EVM. Статья «Сломанный счетчик» является хорошей отправной точкой для исследований в этой области.
Абстракция аккаунта
Мы готовы включить один или несколько EIP, но нам бы хотелось видеть больше сравнений пользовательского опыта и опыта разработчиков между каждым предложением, чтобы лучше понять компромиссное пространство и усилия по интеграции инструментов. Мы рассматриваем следующие EIP/ERC, но, пожалуйста, присылайте нам предложения:
- EIP-3074: коды операций AUTH и AUTHCALL.
- ERC-4337: абстракция учетной записи с использованием Alt Mempool.
- EIP-5806: Комиссионные транзакции.
- EIP-5920: код операции PAY
- EIP-6913: инструкция SETCODE.
- EIP-7377: Перенос транзакций.
- RIP-7560: Собственная абстракция учетной записи — Core EIP — Сообщество волшебников Ethereum
Что нам нужно отметить выше, так это то, что «абстракция учетной записи» аналогична «абстрактной функции проверки, основная цель — добиться ротации ключей, создать ключ с несколькими подписями и предоставить нам путь для автоматического достижения квантового сопротивления».
