Автор Кристин Ким
Составитель: Luccy, BlockBeats
Примечание редактора: Консенсус всех основных разработчиков (ACDC) Ethereum проводится каждые две недели для обсуждения и координации изменений в уровне консенсуса Ethereum (CL). Это 134-я конференц-звонок ACDC. На этой конференции разработчики обсудили детали реализации и технические проблемы нескольких ключевых EIP, включая EIP 7549, EIP 7251, EIP 6110, EIP 7688 и т. д.
Кроме того, разработчики также подробно обсудили реализацию PeerDAS, технологии выборки доступности данных, которая, как ожидается, значительно улучшит способность сети Ethereum поддерживать объединение и требования к доступности данных. В ходе встречи было сделано предложение разделить Pectra на два хард-форка для обновлений, а также обсуждались вопросы времени активации и взаимозависимости разных EIP.
Кристин Ким, вице-президент по исследованиям Galaxy Digital, подробно записала ключевые моменты этой встречи. BlockBeasts составили исходный текст следующим образом:
30 мая 2024 года разработчики Ethereum собрались в Zoom на конференцию № 134 по консенсусу всех основных разработчиков (ACDC). Телеконференция ACDC — это серия встреч, проводимая раз в две недели исследователем Ethereum Foundation Алексом Стоуксом, где разработчики обсуждают и координируют изменения в уровне консенсуса Ethereum (CL, также известном как Beacon Chain). На этой неделе разработчики обсуждают опыт и открытые проблемы, возникшие с момента запуска Pectra Devnet 0. Они также обсудили возможность расширения объема обновления Pectra, включив в него изменения кода контейнера PeerDAS и SSZ.
Девнет 0 Обзор
В свете запуска Pectra в Devnet 0 команда клиента согласилась сохранить поведение проверки, на которое влияет EIP 7549, без изменений во время активации хард-форка. На предыдущем заседании ACDC разработчики рассмотрели различные варианты, чтобы гарантировать, что влияние EIP 7549 не приведет к большому количеству недействительных проверок во время форка. Чтобы избежать дальнейшего усложнения обновлений, команда клиента решила активировать EIP 7549 в ту же эпоху, что и другие EIP Pectra, без изменения поведения проверки до и после форка.
Что касается EIP 7251, разработчики до сих пор не уверены, следует ли разрешить инициирование слияний поставленных ETH на уровне исполнения (EL). Это было бы идеальной функцией для пулов ставок, таких как Lido, чтобы объединение ставок не приходилось полагаться на операторов узлов, а вместо этого могло быть выполнено с помощью смарт-контрактов. Стоукс рекомендовал проверить прогресс клиентов, реализующих слияние ставок валидаторов, в течение нескольких недель, прежде чем принимать решение о том, должны ли они быть операциями EL или CL.
Затем разработчики обсудили некоторые оставшиеся без ответа вопросы относительно окончательного подтверждения депозитов валидатора по EIP 6110. Разработчик Teku Михаил Калинин изложил направления решения этих проблем в комментарии на GitHub перед конференцией. Разработчик Lighthouse «Шон» поднял вопрос об управлении версиями запроса «GetPayloadBodies» в Engine API. Стоукс рекомендовал разработчикам публиковать свои комментарии в запросе на включение, созданном для этой проблемы на GitHub.
Изменения EIP 7549
Разработчик Nimbus Этан Кисслинг предложил небольшое изменение в реализации EIP 7549. «Речь идет о стабильности обобщенного индекса. Когда мы добавляем новое поле в середине контейнера, последующим полям будет присвоен новый индекс, что нарушит доказательство на основе EIP 4788 на уровне выполнения (EL), и некоторые вводящие в заблуждение… Поэтому я рекомендую перенести новое поле в конец, чтобы избежать обеих проблем», — пояснил Кисслинг. Возражений против этого изменения не было. Стоукс рекомендует разработчикам проверить запрос на включение Кисслинга на GitHub.
Еще одно изменение в EIP 7549, предложенное на встрече, будет заключаться в разработке запросов и других запросов, инициируемых EL, как надстроек к блокам EL. По поводу этого изменения Калинин сказал: «На мой взгляд, это очень хорошее дизайнерское решение, оно упрощает EL… и по сути является альтернативой обобщенным запросам в блоке исполнительного уровня. Рекомендуется эту тему сделать». обсуждается еще раз на следующем заседании CL, чтобы у разработчиков было больше времени для рассмотрения предложения на GitHub.
Обсуждение прицела Pectra
Существуют некоторые EIP, ориентированные на уровень консенсуса (CL), которые не были официально включены или исключены из обновления Pectra. На встрече на этой неделе разработчики обсудили, стоит ли добавлять EIP 7688 и PeerDAS в Pectra. EIP 7688 использует часть структуры данных SSZ «StableContainer» для обеспечения прямой совместимости изменений аттестации EIP 7549. В качестве общего введения отметим, что SSZ — это структура данных, используемая в CL, и разработчики также хотят использовать ее на уровне выполнения (EL). Дополнительную информацию о переходе SSZ см. в протоколе предыдущего собрания. PeerDAS — это реализация выборки доступности данных в Ethereum, которая, как ожидается, значительно расширит возможности сети по поддержке объединений и требований к доступности данных. На практике ожидается, что PeerDAS увеличит количество транзакций больших двоичных объектов, которые валидаторы могут прикрепить к блоку, с 3 до 64 и более на блок.
Барнабас Буса, инженер по эксплуатации разработчиков в Ethereum Foundation, сказал, что разработчики запустили раннюю версию PeerDAS в сети разработки. «Я думаю, что многие клиенты обнаружили множество проблем, и когда мы добьемся существенного прогресса, мы всегда сможем перезапустить новую сеть разработки», — сказал Буса. Стоукс спросил разработчиков, готовы ли они добавить PeerDAS в Pectra, не вызывая задержек при обновлении.
Разработчик по прозвищу «Нишант» возобновил предложение отделить активацию PeerDAS от активации других EIP в Pectra. Хотя это возможно, другой разработчик под ником «atd» подчеркнул, что, если разработчики планируют активировать эти обновления одно за другим в течение короткого периода времени, пользователям все равно придется одновременно обновлять свое программное обеспечение. atd сказал: «Я думаю, что это немного безумие — делать форк через два месяца после очередного обновления. Если мы собираемся координировать всех для обновления клиента, мы не хотим, чтобы все обновляли клиент через два месяца. Это было бы , даже одного цикла выпуска недостаточно».
atd добавил, что, по его мнению, PeerDAS — это самое «интересное» изменение кода в EIP, включенное и обсуждаемое в Pectra. Стоукс сказал, что надеется включить PeerDAS в Pectra, даже если это приведет к задержкам обновления. Разработчик клиента Grandine Саулиус Григайтис предложил удалить EIP 7549 и EIP 7688 из Pectra в пользу PeerDAS. Это побудило к обсуждению деталей реализации EIP 7688. Разработчики не смогли договориться об изменениях кода, и это предложение будет пересмотрено на следующем заседании ACDC.
Что касается PeerDAS, разработчики продолжают обдумывать идею разделения Pectra на два хардфорка. Инженер по опциям разработчиков Ethereum Foundation Паритош Джаянти предупредил, что если разработчики разделят Pectra на два обновления, им следует быть осторожными и не добавлять больше EIP в будущую часть Pectra 2. Джаянти сказал: «Я хочу отметить одну вещь: если мы рассмотрим возможность разделения на два форка, нам нужно быть очень осторожными, чтобы не добавить больше новых EIP в следующем форке. Я не знаю, сможем ли мы это сделать. На данный момент, если мы сможем взять на себя что-то год или полтора назад, потому что у нас всегда появляются новые идеи, приоритеты меняются и так далее».
Продолжая обсуждение двух идей обновления, разработчик Lighthouse «Шон» сказал, что он не предвидит многих взаимозависимостей между PeerDAS и текущим списком Pectra EIP. Таким образом, их можно реализовать по отдельности, а затем легко объединить, когда разработчик станет более уверен в их реализации. Atd согласился, утверждая, что объединение Pectra EIP, PeerDAS и EIP 7688 после их разработки и тестирования по отдельности не будет сопряжено с большим риском.
Буса рекомендует продолжить тестирование Pectra EIP и PeerDAS, но при этом внести изменения в код так, чтобы PeerDAS активировался на одну эпоху позже, чем Pectra EIP в сетях разработки и тестирования. Он отметил, что именно так уже проводится тестирование Pectra EIP и PeerDAS на Devnet 0. «На самом деле нет ничего, что нужно было бы менять», — сказал Буса, добавив, что если PeerDAS не готов, когда другие Pectra EIP готовы, разработчики могут удалить это изменение кода из обновления. Это вызывает несколько вопросов о том, как разные эпохи активации PeerDAS влияют на работу клиентских команд. В конце концов разработчики согласились продолжить разработку PeerDAS и Pectra EIP, но предполагалось, что PeerDAS будет активироваться в разные эпохи в сети разработки и тестовой сети.
Как говорилось ранее, разработчики согласились оставить обсуждение того, будет ли EIP 7688 включен в Pectra, до следующего вызова ACDC.