Итоги последней встречи основных разработчиков ETH Place: до конца года состоится теневой форк Goerli и тест обновления Cancun/Deneb

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

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

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

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

Раз в две недели проводятся согласованные звонки для всех основных разработчиков (ACDC) ETH Workshop для обсуждения и координации изменений в уровне консенсуса (CL) ETH Workshop. Это 124-й конференц-звонок ACDC, на котором обсуждаются обновления Devnet #12, прогресс в обновлении Cancun/Deneb и темы, связанные с распространением Slashable. В ходе встречи разработчики активно обсуждали незначительные изменения в сетевом протоколе Libp2p для снижения эффекта усиления больших сообщений на узлах.

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

14 декабря 2023 года ETH разработчиков собрались в Zoom на сессию #124 All Core Developers Consensus (ACDC). Конференц-звонок ACDC — это серия встреч, проводимых раз в две недели под руководством Дэнни Райана, исследователя из ETH Workshop Foundation, на которых разработчики обсуждают и координируют изменения в ETH Workshop Consensus Layer (CL). На этой неделе разработчики сосредоточились на ходе тестирования обновления Cancun/Deneb в тестовой сети Devnet #12. После прошедшего на прошлой неделе совещания по выполнению всех основных компонентов разработчика (ACDE) все комбинации клиентов уровня исполнения (EL) и уровня консенсуса (CL) были подключены к Devnet #12, включая клиент Prysm. Программное обеспечение MEV-Boost включено, но комбинации клиентов с Prysm не включены. Разработчики заявили, что они находятся на пути к планам по запуску теневой ветки Goerli в ближайшие одну-две недели, чтобы протестировать обновление Cancun/Deneb и включить всех клиентов. Кроме того, разработчики обсудили правила распространения информации о Slashable, а также график звонков на ближайшие две недели.

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

Барнабас Буса (Barnabas Busa), инженер DevOps в ETH Foundation, сказал, что все комбинации клиентов EL/CL, включая те, которые используют Prysm в качестве CL-клиента, были успешно интегрированы в Devnet #12. Клиентский портфель, использующий Prysm, не тестировался на наличие программного обеспечения MEV-Boost. Однако в Devnet #12 рабочий процесс MEV тестирует другие клиенты CL. Недавно клиент Lighthouse был обновлен для исправления ошибок, связанных с MEV. Кроме того, Паритош Джаянти, еще один инженер DevOps в Фонде, сказал, что они заметили проблему с узлом Besu в Devnet #12 и что они все еще работают над определением основной причины. В качестве следующего шага разработчики будут намеренно рассылать вредоносные блоки по сети, тестировать генераторы блоков и запускать тесты кустов для вновь добавленных клиентов Prysm для стресс-тестирования комбинаций клиентов в Devnet. Джаянти сообщил в публичном сообщении в Discord во время звонка, что разработчики по-прежнему планируют запустить теневую ветку в тестовой сети Goerli к концу года.

Обновлена слэшируемая информация

Далее разработчики кратко обсудили несколько вопросов, связанных с распространением и временем сообщения Slashable на ETH после обновления Cancun/Deneb. Для фона сведения о косой черте включают распространение повторяющихся или недопустимых блоков и больших двоичных объектов. Dapplion, анонимный разработчик клиента Lodestar, сделал запрос на вытягивание (PR) через GitHub, целью которого является добавление новых событий в API Beacon Chain, чтобы операторы узлов могли быстрее узнавать о событиях Slashable, что было бы особенно полезно при наличии большого количества информации о Slashable. В своем PR-релизе Дапплион отмечает: «Для крупных операторов общая стоимость мероприятия по резке сильно зависит от времени отклика. Если в операционных ошибках участвует много ключей, то может потребоваться некоторое время, чтобы эта информация была включена в цепочку. PR Dapplion был включен в спецификацию API Beacon Chain до вызова и реализуется различными клиентскими командами CL, такими как Prysm и Lighthouse.

Dapplion также предлагает PR, связанный с измерением времени распространения блока. Он отметил, что измерение времени распространения блоков станет более сложным из-за обновления Cancun/Deneb и введения транзакций BLOB-объектов. Дапплион подробно рассказывает о решении, которое он предлагает в своем PR. Как заметили разработчики в ветке PR, они, как правило, решают эту проблему, добавляя поле timestamp к существующим связанным событиям Beacon Chain API.

Третьей темой, которую обсуждали разработчики, была связана с распространением информации Slashable после обновления Cancun/Deneb, были условия распространения BLOB-объектов. Разработчик Lighthouse “sean” (или “realbigsean” на GitHub) указал, что существующие правила распространения больших двоичных объектов приводят к непредвиденным последствиям. Во время звонка Шон сказал: «Если вы используете Beacon API для широковещательной аутентификации, неожиданно, что подход сплетен может привести к допустимым и недействительным сообщениям. Причина этого заключается в том, что технически можно распространить два больших двоичных объекта с разными индексами больших двоичных объектов связанного с ними заголовка Slashable. Вы можете распространять их, но не те, которые имеют одинаковый индекс BLOB-объектов. 」

Шон добавил, что странное поведение, когда дело доходит до распространения информации в больших двоичных объектах, не оказывает существенного влияния на работоспособность сети, кроме просто «странного» результата, который операторы узлов должны понять и проанализировать. Поэтому, несмотря на то, что нет острой необходимости в активации Cancun/Deneb, он предлагает разработчикам рассмотреть возможность внесения изменений в правила обработки распространения информации Slashable в будущих обновлениях. Дэнни Райан соглашается, говоря, что разработчики должны потратить время на то, чтобы «целостно» подумать о том, как решить эту проблему. Райан предлагает вернуться к этой теме в январе, чтобы дать разработчикам время для разработки комплексного плана по обновлению правил распространения BLOB-объектов и блоков Slashable.

Далее разработчики обсудили незначительные изменения в сетевом протоколе libp2p для уменьшения эффекта усиления на узлах, отправляющих большие сообщения, такие как блоки с большим количеством блобов. Шон выделил новое управляющее сообщение “IDONTWANT”, которое может быть использовано для уведомления одноранговых узлов libp2p о приостановке отправки больших сообщений. Райан сказал, что он попытается связаться с командой libp2p, чтобы объединить этот PR, и если будут дальнейшие задержки, этот вопрос будет рассмотрен на конференц-звонке ACDE на следующей неделе.