Исходное название: «Призыв к исполнению всех основных разработчиков Ethereum № 189». Первоначальный автор: Кристин Ким. Оригинальная компиляция: Luccy, BlockBeats. Примечание редактора: Призыв к исполнению всех основных разработчиков Ethereum (ACDE) проводится каждые две недели, в основном для обсуждения и координации. Изменения в уровень исполнения Ethereum (EL). Это 189-я телеконференция ACDE. На этой встрече разработчики обсудили некоторые важные вопросы обновления Pectra, включая изменения, включая EOF и EIP 7702, улучшение возможностей Pectra и подготовку к переходу на Verkle. На встрече также обсуждалось, как упаковываются EOF и другие Pectra EIP и как тестируются эти изменения кода. Кроме того, были внесены некоторые предложения по улучшению процесса обновления сети Ethereum, включая корректировку частоты обсуждения тем конференц-звонков ACD и предложения по новым меткам EIP. Также упоминается прогресс интеграции EIP 4444 и сети порталов. Кристин Ким, вице-президент по исследованиям Galaxy Digital, подробно записала ключевые моменты этой встречи. BlockBeasts составили исходный текст следующим образом:

6 июня 2024 года разработчики Ethereum собрались в Zoom, чтобы принять участие в совещании № 189 All Core Developers Execution (ACDE). Конференц-звонок ACDE — это серия встреч, проводимых раз в две недели Тимом Бейко, главой отдела поддержки протоколов в Ethereum Foundation, где разработчики обсуждают и координируют изменения в уровне выполнения Ethereum (EL). На этой неделе разработчики согласились включить EOF и EIP 7702 в обновление Pectra. Чтобы избежать задержек с многоклиентскими тестовыми обновлениями из-за этих изменений кода, разработчики согласились активировать EOF в сети после разработки, возможно, в другом цикле активации, чем у других EIP, так же, как разработчики планируютпротестировать PeerDAS . Они также обсудили, как вывести из эксплуатации EIP 158 при обновлении в Осаке в рамках подготовки к Verkle, а также следующие шаги по внедрению EIP 4444 посредством интеграции с сетью порталов. Наконец, Бейко и команда EF Developer Operations (DevOps) поделились последними обновлениями процессов управления и каналов связи для планирования обновлений Ethereum.

Область применения Пектры

В преддверии встречи ACD на этой неделе различные клиентские команды EL и команды EF DevOps поделились своими мыслями о возможностях Pectra.

Судя по мнениям, высказанным перед встречей, становится ясно, что большинство клиентских команд поддерживают включение EOF в Pectra. Единственная клиентская команда, которая решительно выступает против EOF, — это Geth. Разработчик Geth Гийом Балле сказал: «Я обеспокоен тем, что чем дольше мы будем ждать, тем больше времени потребуется для перехода Verkle. Действительно ли EOF настолько срочен? Я так не думаю. Я читал несколько аргументов в пользу выпуска EOF в Прага «Чем больше я читал, тем больше понимал, что нет ничего, что действительно доказывало бы необходимость EOF». Некоторые разработчики высказали возражения.

Разработчик по имени Камил Сливак заявил, что EOF станет «огромным улучшением» с точки зрения пользователей, взаимодействующих с компилятором языка программирования смарт-контрактов Ethereum Solidity. Разработчик Reth Драган Ракита добавил, что было бы неискренне думать, что EOF значительно задержит переход на Verkle. «Мы говорим о продлении переходного периода на 10–20%. EOF не увеличит состояние, а дополнительные три месяца для выпуска дополнительных частичных форков не будут существенно задерживать Веркле», — сказал Ракита. Для получения дополнительной информации о том, что такое EOF и как он улучшит виртуальную машину Ethereum (EVM), послушайте этот выпуск подкаста Infinite Jungle .

Бейко спросил разработчиков, предпочтут ли они объединить EOF с другим EIP Pectra или разделить EIP Pectra на два хард-форка. Разработчик Erigon Эндрю Ашихмин заявил, что, по его мнению, разработчикам следует попытаться выпустить все EIP Pectra вместе или отложить EOF до перехода на Verkle. «Меньше всего я хочу, чтобы форк между Pectra и Verkle выпустил EOF. Поскольку я согласен с Гийомом в том, что штат растет, я думаю, что Verkle важнее, чем EOF. Так что, по моему мнению, это худший возможный результат. ", - сказал Ашихмин. Beiko рекомендует выпустить все EIP Pectra, включая EOF, в одной клиентской версии. Однако в целях тестирования, по его словам, разработчикам следует рассмотреть возможность использования сети разработки для поэтапной реализации этих изменений кода. «Используя сеть разработки, мы можем расставить приоритеты с точки зрения многоклиентского тестирования, а затем, если мы увидим, что EOF задерживает работу на долгое время, мы можем решить разделить ее», — сказал Бейко.

На фоне этих дискуссий о том, как включить EOF в Pectra, разработчики Geth продолжали выражать сомнения в чате Zoom и на протяжении всей встречи по поводу того, следует ли включать EOF в обновление. В ответ на продолжающиеся дебаты команды Geth по поводу EOF, разработчик Reth Джордж Константинопулос сказал: «Давайте просто сделаем это. Немного сбивает с толку ход разговора. Мы не против продлить переход Веркла на несколько дней. Данные показывают что статус снижается, так что это сбивает с толку аргумент, и у вас есть куча приложений, которые говорят вам, что это хорошая функция, так почему мы должны даже рассматривать возможность не делать это, когда большинство людей ее поддерживают?»

Бейко согласился и повторил, что EOF следует включить в Pectra, но протестировать поэтапно в сети разработки, то есть клиентские команды должны тестировать EIP Devnet 1, которые уже реализованы в Devnet 0. Затем в будущей сети разработки добавьте EOF для тестирования. Эта стратегия гарантирует, что команда клиента сосредоточится на выпуске части EIP Pectra в те же сроки и сможет продолжать добиваться прогресса в многоклиентской сети разработки. Марио Вега, инженер DevOps в Ethereum Foundation (EF), заявил, что ожидает, что тесты спецификации уровня выполнения (EL) EOF будут готовы в течение двух месяцев. Инженер EF DevOps Паритош Джаянти сказал, что EOF можно тестировать отдельно от других EIP исполнительного уровня (EL) в Pectra. Однако он обеспокоен взаимозависимостью между EIP уровня консенсуса (CL) в Pectra и сложностью тестирования этих изменений кода.

Разработчик компилятора Vyper Чарльз Купер заявил, что, по его мнению, EOF не так актуален, как изменения кода, которые он предложил, чтобы сделать защиту от повторных атак дешевой и распространенной. Бейко напомнила Куперу, что, хотя широкий консенсус по поводу EOF ясен, неясно, хватит ли у клиентских команд энергии для внесения дополнительных изменений в код, например, связанных с атаками повторного входа. «Я думаю, ясно, что если мы будем продвигаться вперед с EOF, у нас останется мало энергии для других дел. Это уже будет самый крупный форк на сегодняшний день», — сказал Бейко.

Помимо включения EOF, разработчики также согласились использовать EIP 7702 в качестве замены EIP 3074. Разработчики все еще обсуждают спецификации EIP 7702 на отдельных групповых собраниях . Beiko рекомендует аналогичный подход к EOF для EIP 7702. «Я бы включил его в форк, но если нас не устраивает спецификация, не делайте ее частью Devnet 1 или 2, а затем потратьте следующий месяц на то, чтобы разобраться в спецификации, чтобы у нас был лучший отзыв. механизм, чем тот, который предлагается сейчас. Не слишком большой EIP будет добавлен позже в процессе», — сказал Бейко. Разработчик Geth «Lightclient» заявил, что, если клиентская команда готова, им следует внедрить EIP 7702 как можно скорее. Нет возражений против включения EIP 7702 в следующую аварийную сеть разработки Pectra, Devnet 1.

Спецификация Пектры

Позже разработчик Teku Михаил Калинин поделился некоторыми обновлениями существующей спецификации Pectra EIP. Первое — это предложение обрабатывать запуск запросов уровня консенсуса (CL) через дополнительный механизм, а не непосредственно в блоке уровня исполнения (EL). Разработчик Prysm «Potuz» отметил, что эта стратегия нарушит логику, необходимую для будущих изменений кода, а именно четкое разделение предлагающего и разработчика (ePBS). «Блок маяка не должен полагаться на уже существующую полезную нагрузку. Поэтому, будь то снятие средств или депозит, вы не хотите, чтобы блок маяка полагался на то, что находится в полезной нагрузке, потому что это нарушит поток ePBS», — Потуз сказал. Из-за этой проблемы Калинин согласился отозвать свою рекомендацию и закрыть запрос на включение на GitHub.

Калинин поделился несколькими другими изменениями в спецификациях Pectra EL и API движка, одно из которых позволяет выполнять слияние по триггеру EL в соответствии с EIP 7251, увеличивая MAX_EFFECTIVE_Balance. Beiko рекомендует разработчикам просмотреть эти изменения перед следующим вызовом ACD, чтобы их можно было завершить и подготовить к тестированию в Devnet 1.

Препарат Веркле

Основываясь на своей работе над переходом Веркла, Баллет сказал, что EIP 158 вызовет аналогичные проблемы с устаревшим опкодом SELFDESTRUCT. Чтобы избежать осложнений в сети после перехода, Ballet рекомендует отключать EIP 158 в обновлениях Pectra. Однако он отметил, что если реализация EIP 7702 будет доработана в Pectra, вывод EIP 158 из эксплуатации может задержаться и совпасть с переходом Веркла. Бейко предложил Гийому начать подготовку предложения по деактивации EIP 158.

Срок действия истории

Помимо Pectra и Verkle, разработчики протокола Ethereum также работают над EIP 4444 — исторической датой истечения срока действия. Как указано в плане и сводном документе EIP 4444 , причина этого изменения кода заключается в том, что «история блоков занимает много места на узле, и как только блок завершен, он необходим только для ограниченного неконсенсуса». критические случаи использования». Далее в документе говорится : «История блоков больше не будет постоянно храниться на полных узлах. Через некоторое время она будет удалена с узла, и субъектам, которым она нужна, придется запросить ее. Сеть порталов — это альтернативная децентрализованная сеть, используемая узлами для запроса исторических данных Ethereum.

Мерриам подтвердил готовность своей команды предоставить поддержку интеграции с Portal Network командам по работе с клиентами EL. По его словам, без какой-либо поддержки интеграция займет около шести месяцев. Однако под руководством и в тесном сотрудничестве он надеется, что в течение следующих двух месяцев можно будет добиться существенного прогресса в работе над EIP 4444. Джаянти спросил, проводился ли аудит безопасности спецификации портальной сети. Мерриам сказала нет. Исследователь Ethereum Foundation Ансгар Дитрихс спросил, могут ли команды клиентов самостоятельно решать, как взаимодействовать с сетью, включая объединение интеграций с существующими клиентами, создание новых клиентов или вообще не выполнять какую-либо интеграцию. Merriam подтверждает, что это решение остается на усмотрение команды клиента.

Во время телефонного разговора Мерриам спросил команду по работе с клиентами EL о ходе работы и намерениях по EIP 4444. Разработчик Nethermind Лукаш Розмей сказал: «В целом, это приоритет. Вчера у нас даже была встреча с командой Portal. Проблема в том, что приоритетов слишком много. Иногда сложно все правильно сбалансировать. Разработчик Besu Мэтт Нельсон сказал, что он чувствует то же самое. Разработчик Geth Гийом Балле заявил, что его команда не обсуждала интеграцию Portal Network.

Улучшение процесса ACD

Улучшения процесса ACD Далее Бейко поделился несколькими предложениями по улучшению процесса обновления сети Ethereum. Сначала он рекомендовал сократить частоту обсуждений во время звонков ACD по темам, которые команда по работе с клиентами еще не рассмотрела подробно. Beiko рекомендует отмечать эти темы для рассмотрения во время звонка ACD, прежде чем разрешить разработчикам участвовать в профессиональных обсуждениях, а затем при необходимости обсуждать их более подробно во время последующих звонков ACD.

Второе предложение, сделанное Бейко, касается статуса «Рассмотрение включения» (CFI), который обычно присваивается предложениям по улучшению Ethereum (EIP), рассматриваемым для включения в хард-форк. Этот статус исторически не был полезным индикатором того, какие EIP с большей вероятностью будут включены в хард-форк. Бейко предложил создать еще один ярлык «Потенциал для включения» (PFI), чтобы разработчики могли лучше различать, какие EIP с большей вероятностью будут включены в хард-форк, а какие нет.

Исследователь Ethereum Foundation Ансгар Дитрихс написал в чате Zoom, что создание нового ярлыка для EIP — это «неправильное направление» и приведет только к тому, что ярлык CFI станет «совершенно бесполезным». Бейко сказал, что разработчики могут продолжить обсуждение улучшения процесса обновления сети на GitHub и EthMagicians.

Кроме того, Марио Вега, инженер DevOps в Ethereum Foundation, заявил, что надеется создать новый подканал Discord для обновлений, связанных с тестированием. Вега сообщила, что в настоящее время в Discord, посвященном исследованиям и разработкам Ethereum, информация о тестовых выпусках разбросана по нескольким каналам. Тем не менее, он надеется, что новый форум станет «универсальным» справочником для команд клиентов, где они смогут получать тестовые обновления от команды DevOps Ethereum Foundation. Он попросил команду по работе с клиентами высказать свое мнение по этому поводу.

Наконец, Бейко напомнил разработчикам, что на ближайшие несколько дней запланированы две групповые встречи: одна по ePBS, которая состоится 7 июня, и другая по PeerDAS, которая состоится 11 июня.