Оригинальное название: «Консенсус всех разработчиков ядра Ethereum № 120».
Автор оригинала: Кристина Ким
Оригинальный сборник: Luccy, BlockBeats
Последняя встреча
19 октября разработчики Ethereum собрались в Zoom на встречу All Core Developers Execution (ACDE) Call #120. Конференц-звонок ACDE — это серия встреч, проводимых раз в две недели исследователем Ethereum Foundation Дэнни Райаном, на которых разработчики обсуждают и координируют изменения в уровне консенсуса Ethereum (CL). На этой неделе разработчики сосредоточены на развитии следующих тем:
1. Версия 1.4.0-beta.3 спецификации CL;
2. Условия запуска Devnet-10;
3. Анализ задержки больших двоичных объектов, проведенный Гаджиндером Сингхом, разработчиком программного обеспечения, который поддерживает клиенты Lodestar и EthereumJS.
Вызов
Дэнни Райан объявил о выпуске новой спецификации кода CL для обновления Канкун/Денеб (Денкун), названной «Призыв». Эта версия официально отмечена как версия 1.4.0-beta.3 в репозитории CL GitHub и содержит два основных изменения:
1. Конфигурация Mainnet KZG: завершена работа по форматированию, необходимая для выходных данных церемонии доверенной установки Ethereum, и включена она в последнюю версию спецификации CL.
2. Новое правило сплетен: разработчик Teku Энрико Дель Фанте создал новое правило сплетен, гарантирующее, что узлы CL не будут распространять больше максимального количества больших двоичных объектов на блок, которое в настоящее время определено в спецификации и равно шести. Это гарантирует, что валидаторы не смогут спамить сеть недействительными сообщениями, превышающими шесть BLOB-объектов на блок.
Девнет-10
Изменения в версии 1.4.0-beta.3 спецификации CL будут протестированы в следующей сети разработки Devnet-10. Однако на пути запуска Devnet-10 есть некоторые препятствия. Барнабас Буса, инженер DevOps в Ethereum Foundation, сказал, что он все еще ждет, пока клиентская команда выпустит новую версию программного обеспечения. Как только они будут готовы, Буса надеется запустить следующую сеть разработки где-то во вторник, 20 октября.
Разработчик клиента Prysm, использующий псевдоним «Potuz», отметил, что конфигурация KZG основной сети, включенная в последнюю спецификацию CL, не может быть объединена с Geth и Prysm, пока не будут внесены изменения в «go-kzg». «go-kzg» — это отдельный репозиторий кода, который реализует схему обязательств KZG на языке программирования Go. Разработчики выразили разочарование по поводу зависимостей между репозиториями go-kzg, Geth и Prysm. Это не первый раз, когда Потуз и другие разработчики поднимают вопросы об использовании библиотеки KZG для EIP 4844.
Паритош Джаянти, DevOps-инженер из Ethereum Foundation, заявил, что разработчики могут запустить Devnet-10 без конфигурации основной сети KZG и новой версии клиента, но это означает, что разработчики не будут тестировать какой-либо новый код на Devnet-10, а вместо этого повторно тестируют выпущенный. код на Devnet-9.
На этой неделе в Devnet-9 разработчики обнаружили проблему в реализации клиента CL. Марио Вега из группы тестирования Ethereum Foundation объяснил, что валидаторы не смогли должным образом обработать недействительные блоки данных (BLOB-объекты). Вега заявила, что если валидатор злонамеренно передает действительные блоки данных одним узлам и недействительные блоки данных другим узлам, узлы, которые получают недействительные блоки данных, не смогут отслеживать главу цепочки. Чтобы решить эту проблему, был создан куст-тест, позволяющий легко воспроизвести эти условия и протестировать новые версии клиентов. Это позволит разработчикам сразу увидеть, работает ли их исправление проблемы.
По поводу этой проблемы Энрико Дель Фанте упомянул, что в некоторых случаях, когда блок содержит один или несколько больших двоичных объектов с индексами, которые не соответствуют существующим обязательствам по двоичным объектам в блоке, клиент Teku не будет импортировать этот фрагмент. Данкрад Файст, исследователь из Ethereum Foundation, отметил, что валидаторы, которые намеренно предлагают блоки, содержащие недопустимые большие двоичные объекты, не имеют других преимуществ, кроме потенциального увеличения вычислительной нагрузки на одноранговую сеть Ethereum и потери синхронизации некоторыми валидаторами, получающими блоки. с сетью. Файст подчеркнул, что от такого поведения нет никакой финансовой выгоды, и даже если бы валидаторы сделали это, дополнительная вычислительная нагрузка на одноранговый уровень Ethereum была бы ограничена максимальным количеством больших двоичных объектов на блок.
Тем не менее, чтобы запретить валидаторам совершать это действие, разработчики обсуждают возможность добавления нового условия косой черты. Новое условие слэшинга будет пытаться отслеживать блоки на предмет включения недействительных больших двоичных объектов, чтобы не дать валидаторам намеренно нагружать одноранговый уровень. Однако из-за высокой стоимости исследований и анализа, необходимых для изменения экономики валидатора Ethereum, Райан предложил продолжить обсуждение этого предложения в контексте Prague/Electra, следующего обновления после Dencun.
Райан добавил, что разработчики могут установить подходящее поведение для этой ситуации в спецификации Dencun CL, а валидаторы по-прежнему должны импортировать блоки, даже если индекс blob не соответствует обязательству блока. Он утверждал, что, поскольку у валидаторов нет финансового стимула для распространения блоков, содержащих недействительные BLOB-объекты, как описано Дель Фанте, потенциальная нагрузка на сеть из-за такого иррационального поведения максимально ограничивается максимальным количеством BLOB-объектов на блок. Таким образом, незначительных изменений в спецификации CL должно быть достаточно, чтобы решить проблему в краткосрочной перспективе, в то время как разработчики могут рассмотреть более постоянные решения для будущих обновлений, такие как новые условия ограничения.
Джаянти и Райан подтвердили, что по крайней мере Devnet-10 не будет запущен на клиенте Prysm до тех пор, пока разработчик не настроит конфигурацию основной сети KZG на клиенте и не решит проблему, поднятую Марио Вегой. Райан подчеркнул, что обсуждения новых условий сокращения велись только в контексте обновления Prague/Electra, а не Dencun, и что изменения в спецификации CL для импорта блоков, содержащих недопустимые большие двоичные объекты, не должны быть препятствием для запуска Devnet-10. Представители клиентских команд Prysm и Lighthouse заявили, что выпустят обновления для своего программного обеспечения завтра, 20 октября.
Анализ задержки блока
В субботу, 14 октября, Гаджиндер Сингх, сопровождающий клиентов Ethereum Lodestar и EthereumJS, поделился новым анализом взаимосвязи между количеством больших двоичных объектов и задержкой импорта блоков, основанным на распространении слухов. Сингх отметил, что в его экспериментах с Devnet-9 задержка блока значительно увеличивалась по мере увеличения количества больших двоичных объектов, полученных валидатором.
В таблице ниже суммированы выводы Сингха. В первом столбце указан процент поступления полных блоков, а значения в таблице представляют количество секунд, затраченных на импорт блока.
Задержка импорта фрагмента в секундах в зависимости от количества больших двоичных объектов, содержащихся в фрагменте. Источник: Гаджиндер Сингх, Twitter.
Сингх написал в Твиттере, что, хотя наличие только одного двоичного объекта на блок создаст незначительную задержку, любое число больше двух приведет к значительной задержке. Данкрад Файст заявил, что данные анализа Сингха сильно отличаются от результатов его экспериментов по распространению больших блоков в сети Ethereum. «Похоже, эти данные никоим образом не верны», — заявил Файст, добавив, что, поскольку большие двоичные объекты обрабатываются параллельно с блоками, добавление задержек обработки больших двоичных объектов ко времени блоков является неточным способом прогнозирования времени распространения блоков в основной сети. Предсказания Сингха о распространении блоков с помощью больших двоичных объектов можно найти по адресу
Сингх сказал в Твиттере, что, хотя наличие только одного BLOB-объекта на блок создаст незначительную задержку, любое число больше двух приведет к значительной задержке. Однако Данкрад Файст отметил, что данные анализа Сингха существенно отличаются от результатов его экспериментов по распространению крупных блоков в сети Ethereum. «Эти данные не могут выглядеть корректно», — заявил Файст, добавив, что, поскольку BLOB-объекты обрабатываются параллельно с блоками, добавление задержки обработки BLOB-объектов ко времени блоков для прогнозирования времени распространения блоков в основной сети является неточным способом. Предсказания Сингха о распространении блоков с помощью больших двоичных объектов можно найти здесь. Файст назвал анализ Сингха «чрезмерно пессимистичным».
Несмотря на разногласия, Файст и Райан согласны с тем, что анализ Сингха действительно может поучиться другим клиентским командам. Райан призвал другие команды CL попытаться воспроизвести эксперименты Сингха на Devnet-9, чтобы посмотреть, смогут ли они получить аналогичные данные и результаты. Если появятся новые данные о задержке блоков после введения больших двоичных объектов, Райан предложил вернуться к этой теме на конференции ACDE на следующей неделе.
«Оригинальная ссылка»