Итоги последней встречи разработчиков ядра Ethereum: запуск Devnet 12, процесс планирования обновления

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

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

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

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

Консенсус-колл Ethereum All Core Developer Consensus Call (ACDC) проводится каждые две недели для обсуждения и координации изменений в Ethereum Consensus Layer (CL). Это 123-й конференц-звонок ACDC, посвященный оценке тестовых обновлений Cancun/Deneb и Devnet #12, а также решению проблемы выхода валидатора, возникшей в Devnet #11. Кроме того, разработчики подробно обсудили уточнение спецификаций сети, процесс планирования обновления и статус EIP.

При обсуждении Cancun/Deneb разработчики сделали акцент на стабильности и обсудили, стоит ли начинать теневой форк Goerli. Однако, так как клиент Prysm не был готов к тестированию, было решено подождать, пока он будет готов. В ходе обсуждения инструментов тестирования и реструктуризации цепочки была подчеркнута необходимость более полного охвата тестами и даны рекомендации по использованию наборов тестов Hive и Excosis. Бейко выразил обеспокоенность по поводу статуса EIP и маркировки CFI, и разработчики еще не достигли четкого консенсуса по этому вопросу.

Кристин Ким, вице-президент по исследованиям Galaxy Digital, подробно изложила ключевые выводы встречи, которые BlockBeasts собрал следующим образом:

30 ноября 2023 года разработчики Ethereum собрались в Zoom на встречу #122 All Core Developers Consensus (ACDC). Конференц-звонок ACDC — это серия встреч, которые проводятся раз в две недели под руководством исследователя Ethereum Foundation Дэнни Райана, на которых разработчики обсуждают и координируют изменения в уровне консенсуса (CL) Ethereum. На этой неделе разработчики сосредоточились на последних разработках в тестировании Cancun/Deneb, в том числе:

· Запуск Devnet #12: В настоящее время проводится тестирование клиентского программного обеспечения Teku, Lodestar и Lighthouse на Devnet #12, а также всего клиентского программного обеспечения уровня исполнения (EL). Команда Prysm ожидает, что их программное обеспечение будет готово к тестированию в течение двух-трех недель в последней версии Devnet.

· Проблема с выходом валидатора в Devnet #11: В Devnet #11 разработчики выявили проблему, связанную с выходом валидатора, которая в настоящее время решается клиентской командой Nimbus. Devnet #11 будет продолжать работать в обычном режиме до тех пор, пока проблема не будет решена.

· Уточнение спецификации сети: Разработчики обсудили уточнение спецификации для запросов “BlockByRoot” и “BlobSidecarsByRoot”, прояснив, должны ли узлы уровня консенсуса (CL) отвечать на эти запросы в определенном порядке.

В дополнение к обновлению Cancun/Deneb, разработчики обсудили некоторые технологические проблемы, поднятые Тимом Бейко, главой отдела поддержки протокола Ethereum Foundation, чтобы улучшить координацию обновления Ethereum.

Devnet #12

В среду, 30 ноября 2023 года, обновление Cancun/Deneb было официально запущено в Devnet #12. Марио Вега из команды тестирования Ethereum Foundation сказал, что «на сегодняшний день не было выявлено никаких серьезных проблем» в трех клиентах CL, которые в настоящее время работают в тестовой сети. Барнабас Буса, инженер DevOps в Фонде, упомянул, что в общей сложности существует 225 валидаторов, распределенных по трем узлам между Lighthouse, Teku и Lodestar. Из-за стабильности Devnet #12 Паритош Джаянти, инженер DevOps в Foundation, спросил разработчиков, стоит ли им начать планировать теневой форк Goerli для дальнейшего тестирования Cancun/Deneb. Однако, учитывая, что Prysm, самый популярный CL-клиент на данный момент, еще не присоединился к Devnet #12, разработчики решили приостановить планы по теневому форку Goerli до тех пор, пока клиентское программное обеспечение Prysm не будет готово к тестированию. Бейко предлагает двигаться по теневой развилке Гёрли где-то до конца года. Из-за стабильности Devnet #12 планы приостанавливаются до тех пор, пока клиентское программное обеспечение Prysm не будет готово к тестированию.

Devnet #11

Разработчик Nimbus, известный под псевдонимом «Dustin», поделился подробностями проблемы Devnet #11, над которой работает его команда. Эти проблемы были впервые обнаружены, когда разработчик вышел из трети валидаторов Devnet #11 для использования в Devnet #12. Райан спрашивает Дастина, может ли он обнаружить эти проблемы с помощью дополнительного тестирования. Дастин ответил, что, по его мнению, характер этих ошибок был вызван деталями реализации, выходящими за рамки согласованной спецификации. Тем не менее, он также признает, что существует «явное противоречие» между написанием клиентского программного обеспечения строго в соответствии со спецификацией CL для проверки преимуществ покрытия и проникновением в серые зоны спецификации для достижения лучшей производительности узла.

«Я имею в виду, что больше тестирования — это всегда хорошо, но более систематическое выяснение того, как включить больше клиентских функций в выполнение тестов, возможно, более автоматизировано, будь то использование Hive, Extosis или чего-то еще. Я думаю, что было бы, безусловно, полезно, если бы эти проблемы можно было решить или разбить все достаточно хорошо, чтобы иметь возможность включить больше этих задач», — добавил Дастин, добавив, что еще одна проблема, которую разработчики CL должны решить, — это определение уровня детализации, который спецификация CL должна диктовать и стандартизировать поведение узлов. «Другой проблемой здесь является степень стандартизации, которая на самом деле является не только вопросом разработки программного обеспечения, насколько стандартизированным должно быть поведение?» — спросил Дастин. Все клиенты CL проходят тесты, которые проверяют базовое поведение, но поведение, выходящее за рамки этих тестов, неоднозначно. «Это намеренно расплывчатые вещи? Что должно быть действительно ясно по норме, а что должно быть намеренно неясно?» — спросил Дастин.

По крайней мере, разработчики согласились добавить больше тестов в будущие Devnets и тестовые сети для большого количества выходов валидаторов в Канкуне/Денебе. Райан также признает, что есть возможность для более тщательного и всестороннего тестирования, когда речь идет о клиентах CL и реализации спецификаций CL. Вега предложила Дастину создать пост на HackMD с подробным описанием своих опасений и обсудить эту тему на следующем тестовом звонке в Канкуне/Денебе. Джаянти добавил, что, основываясь на некоторых проблемах, недавно выявленных на Cancun/Deneb Devnets, существует явная потребность в инструментах, которые могут систематически выполнять определенное количество действий, связанных с интеграцией в сети, таких как вывод ETH, вывод средств валидаторов и т. д. Для этого Джаянти рекомендует создать такой инструмент, используя сочетание наборов тестов Hive и Excosis.

Говоря о новом инструменте тестирования для обновления Cancun/Deneb, Джаянти отметил, что разработчики работают над инструментом для надежной активации воссоединений цепочек в Devnets и тестовых сетях. Чтобы убедиться, что этот инструмент работает, Джаянти попросил разработчиков поделиться подробностями об известных ошибках, которые вызвали реорганизацию цепочки в Ethereum. Джаянти объяснил, что он будет использовать эти ошибки для тестирования инструмента и обеспечения того, чтобы он мог надежно определить, когда происходит реорганизация и когда она разрешена.

Уточнение спецификации сети

Разработчики вкратце обсудили открытый запрос на вытягивание, предложенный исследователем Ethereum Foundation Джастином Траглией, относительно порядка ответов, которые клиенты CL должны возвращать при получении запроса «BlockbyRoot» или «BlobSidecarsByRoot». Райан спрашивает, как различные клиентские команды CL уже реализуют эту функцию. Ни один из разработчиков, участвовавших в разговоре, не ответил на этот вопрос. Райан предложил возобновить дискуссию на канале Ethereum Research & Development в Discord, чтобы привлечь более широкий круг разработчиков-клиентов. Райан признает, что в спецификациях этих двух запросов есть неясности, которые «могут быть причиной проблем и странных пограничных случаев» и «заслуживают прояснения и упорядочивания», утверждает Райан.

Райан также упомянул, что выпустит новую версию спецификации CL в ближайшие несколько дней. В последней версии значительно добавлены спецификации о том, когда CL-клиент может предоставлять блоки и блоки через RPC-запрос “byRoot”. Для получения дополнительной информации об обсуждении получения отсутствующих блоков и блоков с помощью запросов “byRoot” RPC, пожалуйста, обратитесь к предыдущему журналу вызовов. Райан подчеркивает, что новые дополнения к спецификации CL, включенные в последнюю версию, не будут иметь каких-либо критических изменений в коде, которые повлияют на код валидаторов, уже работающих в Devnet #11 или #12.

Процесс планирования обновления

Далее разработчики обсудили различные технологические элементы, предложенные Бейко. Бейко сказал, что сообщение в блоге, предупреждающее пользователей тестовой сети Goerli о предстоящем прекращении поддержки в течение 3 месяцев после активации обновления Cancun/Deneb на Goerli или через 1 месяц после активации обновления в основной сети Ethereum, в зависимости от того, что наступит позже, будет опубликовано в блоге Ethereum Foundation 30 ноября. После завершения телеконференции вышеупомянутый пост в блоге был опубликован, и его можно прочитать здесь.

Бейко предлагает создать папку, специфичную для обновления, в репозитории Ethereum «pm», чтобы организовать различные файлы, связанные с конкретным обновлением, в одну папку для последующего использования. Разработчики, участвовавшие в разговоре, согласились с предложением Бейко.

Второй пункт процесса, предложенный Бейко, заключается в создании документа «Meta EIP» для отслеживания полного объема обновлений сети, которые были завершены на Ethereum. «Нет хорошего места, чтобы отслеживать полный объем обновления сети перед развертыванием и объявлением о нем в блоге», — написал Бейко в посте о своем предложении Meta EIP. «Для Dencun, у нас есть EIP EL в труднодоступном файле Markdown 7, а EIP CL являются частью спецификации Beacon Chain 3. Это не очень хорошо, так как их немного трудно найти, они используют разные «форматы» и приводят к дублированию. Поскольку ERC и EIP теперь разделены, я рекомендую (возвращаясь назад) использовать Meta EIP для отслеживания EIP, включенных в обновление сети. Разработчики высказались за создание этих документов. Бейко сказал, что на этой неделе он подготовит документ для пересмотра модернизации Cancun/Deneb.

Наконец, Бейко поднял вопрос о целесообразности пометки предлагаемых изменений в коде, предложений по улучшению Ethereum (EIPs), как «Рассмотреть включение» (CFI). По словам Бейко, CFI — это статус, который разработчики исторически использовали в качестве «мягкого сигнала», указывающего на то, что авторы EIP должны продолжать работать над предложениями, которые могут быть включены в будущие хардфорки. Он используется только для изменения и обновления кода, ориентированного на EL. 「[CFI] выше, чем случайные идеи от случайных людей, но до того, как они будут приняты в форке», — сказал Бейко.

В прошлом маркировка CFI практически не помогала указать, какие EIP на EL будут реализованы при обновлении и когда. Он был применен к широкому спектру EIP с разной степенью готовности кода и поддержкой со стороны клиентских команд. В случае с предложением EVM Object Format (EOF) разработчики используют этот тег, чтобы обозначить свою приверженность внедрению EOF в следующем предстоящем обновлении, Cancun/Deneb. Тем не менее, EOF, а также несколько других предложений, которые также помечены как CFI, были отклонены Cancun/Deneb, и неясно, статус этих EIP, помеченных как CFI в следующем обновлении Prague/Electra.

Бейко сказал, что если это состояние не помогает, разработчики должны удалить его, но если они намерены его сохранить, разработчики CL также должны использовать ту же метку для изменений кода, которые они рассматривают для реализации в обновлениях CL. Неясно, в какой степени процесс рассмотрения CL EIP отражает процесс рассмотрения EL EIP и должны ли они развиваться таким же образом в будущем. Как правило, предлагаемые изменения в коде спецификации CL обсуждаются на конференц-звонке ACDC, в то время как предлагаемые EIP в спецификацию EL обсуждаются на конференц-звонке ACDE.

Данно Феррин (Danno Ferrin) из Swirlds Labs также придумал идею создания поля-заполнителя для всех EIP, независимо от того, связаны ли они с CL или EL, которое определяет их статус в процессе проверки, включая статус CFI. На этом совещании не было четкого решения по вопросу о статусе EIP и маркировке CFI.