Резюме последней встречи основных разработчиков Ethereum: активируйте PeerDAS, увеличьте лимиты газа BLOB-объектов

Написал: Кристин Ким

Компиляция: Luccy, BlockBeats

Редакторский комментарий: Все основные разработчики Ethereum созваниваются каждые две недели на конференции ACDC (Agenda, Coordination, and Developer Communication), чтобы обсудить и согласовать изменения в Ethereum Consensus Layer (CL). Это 135-я конференция ACDC, на которой основное внимание было уделено подготовке тестовых сетей Pectra Devnet 1, PeerDAS Devnet 1 и Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Разработчики глубоко обсудили вопросы поддержки пакетов программного обеспечения, EIP, включая процессы и именование нового раунда обновлений консенсусного уровня Ethereum. Кроме того, обсуждался прогресс реализации в рамках спецификации Electra, влияние изменений сети PeerDAS на обработку и проверку данных узлов Ethereum, а также сложные инженерные проблемы, связанные с увеличением ограничений blob gas.

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

13 июня 2024 года разработчики Ethereum собрались на конференции All Core Developers Consensus (ACDC) Call # 135 в Zoom. ACDC телефонная конференция - серия встреч, которые проводятся раз в две недели и на которых исследователь Ethereum Foundation Alex Stokes ведет обсуждения и координацию изменений в консенсус-уровне Ethereum (CL, также известном как блокчейн-маяк). На этой неделе разработчики обсудили подготовку Pectra Devnet 1, PeerDAS Devnet 1 и третьей специальной тестовой сети для простой сериализации (SSZ) Ethereum Improvement Proposals (EIPs).

Объявление

Разработчики начали встречу с двумя объявлениями. Инженер по разработке и поддержке Ethereum Foundation Parithosh Jayanthi сообщил, что команда ethPandaOps, это группа инженеров, работающих в рамках EF DevOps, возьмет на себя обслуживание и разработку модуля ethereum-package Kurtosis. Ранее разработчики использовали этот пакет для запуска тестовых сетей Ethereum и связанных инструментов, таких как панель инструментов Grafana для мониторинга и тестирования различных клиентских реализаций. При переносе этого пакета от команды Kurtosis к команде ethPandaOps могут возникнуть проблемы у пользователей, так как некоторые ссылки будут перенаправлены на репозиторий GitHub, управляемый командой ethPandaOps, а не командой Kurtosis. Jayanthi рекомендует пользователям обновить свои программные ссылки и следить за новыми версиями, выпущенными командой ethPandaOps.

Второе объявление было сделано Протокол Тимом Бейко, главой отдела поддержки протокола в Ethereum Foundation. Бейко сказал, что он работает над внедрением нового процесса включения EIP в обновление Ethereum поэтапно. Он создал проект EIP, в котором определены метки «Предложено для включения», «Рассмотрено для включения» и «Запланировано для включения». Он ожидает, что разработчики рассмотрят документ и предоставят обратную связь. Он надеется завершить работу над этим документом до следующего заседания ACD.

Электра

Кодекс норм поведения для следующей основной версии Electra v1.5.0-alpha.3 скоро будет завершен. Разработчики согласны на объединение запроса на вытягивание (PR) #3768 из репозитория GitHub для спецификации соглашения в следующей версии. Этот запрос был создан разработчиком Nimbus Этаном Кисслингом, который отметил, что поле «committee_bits» должно быть добавлено в конец «Attestation», а не в середину данных, чтобы избежать проблем с сериализацией данных. Кроме PR #3768, Стокс спросил, есть ли еще какие-либо нерешенные вопросы, которые необходимо решить до выпуска следующей основной версии Electra. Джаянти в чате Zoom упомянула, что существуют некоторые нерешенные проблемы с интеграцией проверяющего узла, вызываемые выполнением уровня (EL). Стокс записал вопросы, связанные с состоянием интеграции проверяющего узла, вызываемые выполнением уровня (EL), после проведения встречи.

Относительно последних результатов реализации спецификации Electra большинство команд клиентов на уровне согласия (CL), выступающих на встрече, заявили, что они смогут подготовить новую версию к тестированию в течение одной-двух недель после окончательного утверждения v1.5.0-alpha.3. Разработчики согласились обсудить расписание следующей сети разработки Pectra Devnet 1 через несколько недель.

ПирДАС

Далее разработчики обсудили прогресс внедрения PeerDAS. PeerDAS - это улучшение сети Ethereum, которое увеличит способность узлов обрабатывать и проверять большие произвольные данные, представленные пользователями через транзакции blob. Стокс вспомнил решение, принятое на прошлом собрании ACDC, о том, что разработчики будут параллельно разрабатывать PeerDAS вместе с другими Pectra EIPs и активировать его на тестовой сети в отдельном активационном цикле.

Разработчик Lodestar Gajinder Singh заявил, что на основе последней групповой встречи по PeerDAS разработчики активируют PeerDAS на сети разработки, отделенной от других Pectra EIPs, на базе обновления Deneb. Разработчик Teku Enrico Del Fante заявил, что разработчикам легче строить PeerDAS на стабильных кодовых стандартах, определенных ранее в обновлении Ethereum Deneb, чем на изменяющихся кодовых стандартах Pectra. Jayanthi согласен с тем, что реализация PeerDAS вместе с другими реализациями Pectra EIP может вызвать сложные проблемы в процессе тестирования, особенно при попытке найти источник ошибки. Он предложил отделить эти два рабочих процесса, а затем объединить их после более стабильной реализации каждого из них. Stokes согласен и заявил, что разработчики могут обсудить объединение PeerDAS и других реализаций Pectra EIP примерно через месяц.

Относительно запуска темы PeerDAS Devnet 1 командой клиентов нет четкой оценки того, когда они будут готовы к запуску тестовой сети. Предполагается, что наличие личной оценки на собрании составляет примерно от 2 недель до 1 месяца. Stokes предложил обсудить расписание времени разработки сети через несколько недель после того, как у команды клиентов будет больше времени для реализации PeerDAS.

Затем Beiko указал, что хотя PeerDAS представляет собой улучшение сети, а не изменение основного протокола Ethereum, он все же надеется включить изменения кода в мета EIP обновления Pectra. Документ мета EIP является общедоступным документом, в котором перечислены все изменения основного протокола, включенные в обновление Ethereum. Beiko отметил, что PeerDAS является «крупнейшей особенностью» в Pectra, и хотя для его активации не требуется жесткий форк, он все равно должен быть включен в документ, чтобы показать, что разработчики серьезно готовятся к его своевременной активации на основной сети Pectra. В этом нет разногласий.

Увеличение ограничения газа для блобов

PeerDAS изменяет способ обработки и передачи данных узлами через уровень сети Ethereum. Чтобы пользователи, особенно Layer-2 роллапы, могли воспользоваться этими изменениями, разработчики должны увеличить текущее ограничение на шесть блобов в каждом блоке до более высокого порогового значения, что позволит увеличить пропускную способность блобов (любых данных). Изменение ограничения блобов потребует изменений в основном протоколе Ethereum, как обсуждалось разработчиками на этой неделе, что может потребовать более сложной инженерной работы, чем простое изменение значения константы в техническом стеке протокола.

Stokes предложил отвязать зависимость между слоем выполнения (EL) и слоем согласования (CL) при изменении ограничений на газ blob. В настоящее время любое изменение ограничений на газ blob требует изменения протокола EL и CL. Stokes предложил несколько методов, которые могут разрушить эту зависимость, позволяя разработчикам безопасно удалять жестко закодированные ограничения на газ blob из EL и полностью определять их в CL. Исследователь Фонда Эфириума (EF) Данкрад Фейст указал, что помимо проблем зависимости между EL и CL, изменение ограничений на газ blob имеет важное последствие для вычисления газа в блоке. Фейст сказал: “Лучший способ - изменить способ вычисления. Возможно, ошибка в том, что вычисление цены газа происходит в EL. Это должно происходить в CL, но сейчас это сложнее изменить… Это не просто.”

Разработчики согласились продолжить исследование наилучшего способа ограничения газа в блобах и изменения расчета газа в блоках. Разработчики также согласились продолжить обсуждение увеличения ограничения газа в блобах при активации PeerDAS в Pectra. Разработчики раскололись во мнении, должны ли эти изменения быть реализованы вместе или же поэтапно через несколько жестких форков.

Джаянти говорит, что объединение этих изменений - это “рискованное” решение, поскольку разработчики не будут знать, как оно будет работать в основной сети PeerDAS до ее активации. Инженер по операциям DevOps Фонда Эфириума (EF) Барнабас Буса добавил, что диапазон жесткого форка Pectra уже очень широк и не требует дополнительных изменений в коде. Буса говорит: “Главное, что у нас уже есть много EIP, и я считаю, что если мы продолжим добавлять еще больше контента, это никогда не закончится. Поэтому нам нужно провести черту где-то, вот наша конечная цель. Я думаю, что за полтора года тестирования невозможно будет выпустить PeerDAS и увеличить количество blob.”

Разработчик с именем экрана ‘Francesco’ предложил удалить PeerDAS для ‘снижения риска Pectra’, если изменения в сети не сопровождаются увеличением количества блобов. Франческо спросил: ‘Какова польза от PeerDAS в Pectra, если количество блобов не увеличивается?’

Для дальнейшего объяснения трудностей с тестированием PeerDAS Джаянти указывает на то, что введение блобов в EIP 4844 Ethereum не полностью моделирует фактическое поведение и влияние блобов на основной сети Ethereum. Джаянти говорит: «Проблема заключается в том, что тестовая сеть очень сложна. Мы действительно провели много отличных тестов, связанных с 4844, но поведение блобов на основной сети не полностью совпадает с их поведением в тестовых условиях. Мы действительно видели проблемы с более слабыми узлами. Мы действительно столкнулись с временными вызовами и подобными ситуациями, поэтому даже если мы можем идеально смоделировать PeerDAS и увеличение количества блобов в разрабатываемой сети, это не имеет никакого практического значения для основной сети, и поэтому я считаю, что мы должны делать это постепенно, а не сразу.

Исследователь EF Ansgar Dietrichs заметил, что связывать увеличение количества блобов с PeerDAS неправильно, поскольку уже сам PeerDAS требует от разработчиков выбора значения количества блобов. Хотя разработчики могут выбрать число, соответствующее числу на основной сети Ethereum, решение о том, какое число использовать для PeerDAS, должно быть принято. Единственная причина выбора того же числа - это увеличение сложности PeerDAS, что позволяет ему откатываться к механизму распространения блобов, описанному в текущей спецификации Deneb, в случае ошибки. Dietrichs отметил, что обеспокоенность сложностью тестирования дополнительно подтверждает его мнение о том, что Pectra должна быть активирована через два жестких форка, а не через один, но это не означает, что PeerDAS должен быть отделен от изменения количества блобов.

Обновление SSZ

Kissling поделился тремя обновлениями по прогрессу EIP, связанных с SSZ. Он отметил, что работа над реализацией этих EIP уже началась на нескольких клиентах, включая Teku, Grandine и Lighthouse. Он сказал, что разработчики могут начать обсуждать график разработки этих SSZ EIP и возможно включить их в рамки обновления Pectra на следующем совещании ACDC.

Именование F-Star

На Ethereum Magicians была опубликована статья, посвященная обновлению следующего уровня согласия Ethereum (CL) после Electra. Разработчики уже выбрали название для обновления исполнительного уровня (EL) после Prague: Осака. В качестве кандидатов для обновления CL предложены имена: Fulu, Felis, Formosa и Funi. Эти имена следуют основным соглашениям об именовании звезд, начинающихся с буквы «F», и подходят для шестого общенетворческого обновления Beacon Chain. Stokes просит разработчиков, участвующих в звонке, выразить свое мнение по этой теме на форуме Magicians.