Итоги последней встречи разработчиков ядра ETH Workshop: Активируйте обновление Cancun в тестовой сети в начале января 2024 года

Оригинальное название: Ethereum All Core Developers ution Call #176 Writeup

Оригинальная статья Кристин Ким

Оригинальная компиляция: Luccy, BlockBeats

Примечание редактора:

Каждые две недели проводятся ETH Workshop All Core Developer Consensus Calls (ACDE) для обсуждения и координации изменений в ETH Workshop Execution Layer (EL). Это 176-й конференц-звонок ACDE, и на нем будут обсуждаться вопросы обновления Cancun/Deneb, ход тестирования Devnet #12 и план обновления Prague/Electra.

Разработчики обсудили, как обновление Cancun/Deneb было протестировано в Devnet #12, включая прогресс и некоторые проблемы, обнаруженные различными клиентскими командами, а также технические проблемы с распространением BLOB-объектов, MEV (Maximum Extractable Value) и многое другое. Для предстоящего обновления Prague/Electra разработчики предложили ряд возможных технических изменений.

Кристин Ким, VP исследований в Galaxy Digital, дала подробную заметку об основных моментах встречи, которую BlockBeasts собрал следующим образом:

7 декабря 2023 года ETH разработчики собрались на конференции Zoom for All Core Developers ution (ACDE) #176. Конференц-звонок ACDC — это двухнедельная серия встреч под руководством Тима Бейко, руководителя отдела поддержки протоколов в ETH Foundation, на которых разработчики обсуждают и координируют изменения в исполнительном уровне (EL) ETH Place. На этой неделе разработчики обсуждали тестирование обновления Cancun/Deneb на Devnet #12. Они договорились согласовать дату активации обновления в тестовой сети Гёрли в начале ETH января после окончания праздников. Кроме того, в начале января они планируют начать обсуждение того, какие изменения в коде должны быть включены в следующее обновление мастерской ETH, Prague/Electra.

Обновление Devnet #12

Тестирование обновления Cancun/Deneb на Devnet #12 проходит успешно. Паритош Джаянти, инженер DevOps в Foundation, сообщил, что некоторые ошибки были обнаружены в двух клиентах, Reth и Lighthouse, и что две клиентские команды работают над экстренным исправлением. Для более тщательного тестирования рабочих процессов MEV команды DevOps уделяют больше внимания включению программного обеспечения MEV-Boost на большем количестве валидаторов в Devnet #12. По словам Джаянти, его команда обнаружила по крайней мере одну ошибку в реализации MEV-ретрансляции Flashbots. Дэнни Райан, исследователь ETH Foundation, подчеркнул, что для того, чтобы валидаторы могли переключиться на локальную сборку блока в случае сбоя реле, необходимо дополнительное тестирование для проверки альтернативных механизмов.

Теренс Цао (Terence Tsao), разработчик клиента Prysm, сказал, что его команда работает над обновленным дизайном ACDC #122中讨论的 распространения BLOB-объектов. Цао подтвердил, что клиент Prysm будет готов присоединиться к Devnet #12 для тестирования на следующей неделе, возможно, на следующей неделе. Джастин Флорентайн, разработчик клиента Besu, заявил, что Besu готов перейти с Devnet #12. Представители клиентских команд Nethermind, Erigon, Lodestar и Teku также заявили, что готовы продолжить тестирование обновления в публичной тестовой сети ETH.

Исходя из готовности клиента, Бейко рекомендует согласовывать дату хардфорка, как только разработчики выйдут из отпуска. Предполагая, что в ближайшие несколько недель после присоединения клиента Prysm в Devnet #12 не будет обнаружено никаких серьезных ошибок, Бейко утверждает, что активация Cancun/Deneb на Goerli, скорее всего, произойдет примерно в середине января. Бен Эджингтон (Ben Edgington) из команды Teku спросил разработчиков, уверены ли они в изменении количества больших двоичных объектов на блок с двух до трех. Райан предлагает провести дополнительное тестирование увеличенных мишеней для сгустков во время массивного теневого форка и активации Cancun/Deneb на Goerli. Бейко подтвердил, что активация обновления на Goerli станет «последним значительным испытанием» трех целей для больших двоичных объектов на блок. Предполагая, что проблем не обнаружено, разработчики продолжат использовать увеличенное количество BLOB-объектов для активации основной сети.

В целом, Бейко сказал, что разработчики продолжат тестировать обновления в Devnet #12 до конца праздников. Команда DevOps планирует запустить как минимум один теневой форк Goerli до конца декабря в рамках подготовки к настоящему хардфорку Goerli в январе. Если разработчики соберутся к Новому году, они обсудят дату активации хардфорка Goerli.

Флаги переопределения построителя

Затем Цао спросил команду клиентов о том, как они продвигаются в реализации флага переопределения Builder. Флаг переопределения Builder — это новое логическое поле в обновлении Cancun, которое клиент уровня исполнения может использовать, чтобы указать клиенту уровня консенсуса, что при обнаружении Builder активности цензуры валидатор должен вернуться к локальной генерации блоков вместо использования стороннего Builder. Как подчеркивает Цао, детали реализации того, как обнаружить действия Builder по проверке, субъективны и намеренно оставлены на усмотрение команды клиента. Для получения дополнительной информации о флагах переопределения Builder, пожалуйста, обратитесь к протоколам ACDC#112 и ACDE#165.

Разработчик клиентской команды Geth, выступающий под ником “Lightclient”, заявил, что его команда реализовала флаг, но не будет объединять его в официальном релизе “в ближайшее время”. Представители команд Besu и Nethermind заявили, что этот необязательный флаг еще не реализован в их клиентах. Цао подчеркнул, что флаг может быть полезным инструментом, и лучше всего внедрить его как можно раньше, чтобы отбить у стейкинг-пулов или операторов крупных узлов валидаторов от участия в определенных «играх на время». Цао объяснил, что валидаторы могут заработать больше MEV (Maximum Extractable Value) за счет задержки распространения блоков, и что после введения больших двоичных объектов после обновления Cancun произойдет задержка в распространении блоков. Во время этих задержек валидаторы могут включить в блок более прибыльные транзакции MEV, что не является оптимальным для своевременного распространения BLOB-объектов.

Подтверждая, что транзакции с большими двоичными объектами должны будут конкурировать с обычными транзакциями, разработчик под псевдонимом Prysm, известный под псевдонимом Potuz, добавил: «Большие двоичные объекты должны конкурировать не только с комиссиями, но и с самой задержкой и всеми MEV, полученными за счет задержки блоков. Разрабатывая механизм комиссий для больших двоичных объектов, я думал, что это рынок, который не был заблокирован или принят во внимание. Цао сказал, что снова поднимет этот вопрос в Ethereum Research Discord для дальнейшего обсуждения. Кроме того, Райан выделил недавний пост исследователей Ethereum Foundation Каспара Шварца-Шиллинга и Майка Нойдера об «играх на время» на веб-сайте Ethresearch.

Ход проекта

Затем Бейко поделился тремя новостями, связанными с процессом планирования обновления ETH Workshop. Во-первых, как и в #123上讨论的那样 ACDC, Бейко создал документ Meta EIP для обновления Cancun/Deneb, в котором перечислены все предложения по улучшению ETH (EIP), которые были включены в Cancun/Deneb. Он был создан на GitHub с номером EIP 7569. Кроме того, Бейко создал EIP 7568 в качестве мета-документа EIP для всех предыдущих обновлений, и разработчики не создали специальный документ для отслеживания списка EIP, включенных в обновление. EIP 7568 связан со спецификацией кода обновления.

Во-вторых, Бейко объявил, что он создал новую дискуссионную ветку на веб-сайте Ethereum Magicians, чтобы определить следующее обновление сети, Prague/Electra. Он попросил разработчиков критически подумать о том, стоит ли объединять обновления уровня исполнения (EL) и уровня консенсуса (CL) вместе, как это было сделано в двух предыдущих хардфорках. Активация некоторых изменений кода, таких как EIP 7002, потребует изменений как в EL, так и в CL, поэтому обновления Prague и Electra должны быть скоординированы. Однако для других изменений кода, таких как дерево Verkle, есть способ перепроектировать реализацию, и для этого нужно только обновить CL.

Райан отметил, что разработчики уровня консенсуса (CL), работающие параллельно с деревом Веркла, также вносят изменения в код для поддержки выборки доступности данных. Бейко советует разработчикам не вдаваться в подробности обо всех EIP, которые они хотят видеть в обновлении Prague/Electra, а лучше просмотреть все изменения в коде-кандидатах во время праздников и быть готовыми серьезно обсудить их в январе. Потуз соглашается, добавляя, что EIP, предназначенный для решения растущей проблемы размера набора валидаторов ETH станет важным изменением кода в Праге/Electra. Исходя из сложности изменений в коде, Бейко рекомендует, чтобы для некоторых EIP, таких как Verkle или выборка доступности данных, разработчики организовывали специальные встречи после праздников для подробного обсуждения этих более крупных изменений протокола.