Исходное название: «Призыв к исполнению всех основных разработчиков Ethereum № 184». Первоначальный автор: Кристин Ким. Оригинальная компиляция: Luccy, BlockBeats. Примечание редактора: Консенсус всех основных разработчиков Ethereum (ACDE) проводится каждые две недели, в основном для обсуждения и координации. Изменения в уровне выполнения Ethereum (EL). Это 184-я телеконференция ACDE. Эта конференция была посвящена причинам увеличения количества пропущенных блоков 27 марта, а также новому исследованию команды Paradigm о состоянии и историческом росте Ethereum. На встрече разработчики поделились обсуждениями проблем ретрансляции Bloxroute MEV и двух ретроактивных EIP в Праге/Электре. Кроме того, обсуждались обновления разработки для EIP 7547 (список включения), EIP 5920 (код операции PAY) и EIP 7545 (предварительная компиляция проверки доказательств Verkle). Кристин Ким, вице-президент по исследованиям Galaxy Digital, подробно записала ключевые моменты этой встречи. BlockBeasts скомпилировал исходный текст следующим образом:
28 марта 2024 года разработчики Ethereum собрались в Zoom, чтобы принять участие в совещании № 184 All Core Developers Execution (ACDE). Конференц-звонок ACDE — это серия встреч, проводимых раз в две недели Тимом Бейко, главой отдела поддержки протоколов в Ethereum Foundation, где разработчики обсуждают и координируют изменения в уровне выполнения Ethereum (EL).
На этой неделе разработчики поделились своими мыслями о том, что вызвало рост количества пропущенных блоков 27 марта. Разработчик Prysm Теренс Цао заявил, что рост был вызван проблемой с реле Bloxroute MEV, над которым работает команда Bloxroute. Разработчики также обсудили ключевые моменты нового исследования состояния и исторического роста Ethereum, проведенного командой Paradigm. Разработчики одобрили включение двух ретроактивных предложений по улучшению Ethereum (EIP) в Прагу/Электру, а именно EIP 7610 и 7523.
Наконец, они поделились обновлениями разработки других кандидатов EIP, таких как EIP 7547 (список включения), EIP 5920 (код операции PAY) и EIP 7545 (предварительная компиляция проверки доказательств Verkle).
События отсутствия блоков в сети Mainnet
27 марта количество недостающих блоков увеличилось. Обычно в Ethereum каждые 30 минут пропускаются от 2% до 4% блоков. Однако в периоды, когда в сети происходит большое количество транзакций с большими двоичными объектами, этот процент возрастает до более чем 14% в течение нескольких часов. За этот период цены на Blob выросли более чем в 10 раз. Цао сказал, что проблема с недостающими блоками была немедленно решена, как только команда Bloxroute отключила свое реле MEV. Детали, вызывающие проблему с ретранслятором Bloxroute, неизвестны, и команда Bloxroute работает над исправлением, которым они поделятся вместе с полным анализом проблемы в ближайшие дни.
«Итак, вчерашние пропущенные блоки не означают, что клиенты не могут справиться с этим типом рабочей нагрузки, потому что в основном все пропущенные блоки вызваны проблемами Bloxroute. Но остается фундаментальный вопрос о том, что случилось бы со вчерашним трафиком». Я подозреваю, что клиенты, возможно, импортируют блоки медленнее, чем раньше, но у меня нет убедительных доказательств этого, и это еще предстоит выяснить», — сказал Цао. В ответ на инцидент с отсутствующим блоком команда клиента Lighthouse выпустила «горячее исправление». версия для улучшения производительности и стабильности узла. Кроме того, хотя расследование еще продолжается, заявил генеральный директор Bloxroute Ури Кларман.
Инженер по эксплуатации разработчиков Ethereum Foundation Паритош Джаянти спросил, заставит ли этот инцидент разработчиков переоценить условия автоматического выключателя клиента, которые автоматически заставят узлы валидатора вернуться к локальному производству блоков. В большинстве клиентов значением по умолчанию для состояния автоматического выключателя является событие, которое пропускает пять слотов подряд. Цао отметил, что условия автоматического выключателя, которые срабатывают слишком легко, являются потенциальными векторами атак, которыми могут воспользоваться сложные субъекты MEV.
Инженер по эксплуатации разработчиков Ethereum Foundation Паритош Джаянти спросил, заставит ли этот инцидент разработчиков переоценить условия автоматического выключателя клиента, которые автоматически заставят узлы валидатора вернуться к локальному производству блоков. В большинстве клиентов значением по умолчанию для состояния автоматического выключателя является событие, которое пропускает пять слотов подряд. Цао отметил, что условия автоматического выключателя, которые срабатывают слишком легко, являются потенциальными векторами атак, которыми могут воспользоваться сложные субъекты MEV.
Разработчик Prysm «Potuz» заявил, что, по его мнению, этот инцидент подчеркивает отсутствие реализации многообразия клиентов в ретрансляторах, а также отсутствие связи между разработчиками ретранслятора и протокола. «Теренс говорил об этих каплях уже больше недели, но никто этого не заметил, а как только они взорвутся, потребуется всего несколько телефонных звонков, чтобы заставить нужные реле действительно просмотреть свои журналы. Это неприемлемо», — объясняют Портуцци.
Некоторые разработчики рекомендуют в следующий раз создавать письменные сообщения при сообщении о нарушениях в сети, чтобы повысить видимость экосистемы Ethereum. Чтобы продолжить обсуждение инцидента с пропавшим блоком, исследователь Ethereum Foundation Алекс Стоукс призвал разработчиков принять участие в следующем собрании сообщества MEV-Boost.
Анализ данных о состоянии и историческом росте
Сторм Сливкофф, специалист по данным из Paradigm, предлагает новый анализ статуса и исторического роста Эфириума. Согласно его выводам, рост состояния не является основным узким местом в масштабируемости Ethereum. "Мы обнаружили, что существующее потребительское оборудование может поддерживать текущие национальные темпы роста в течение длительного периода времени, возможно, десятилетий. Обратите внимание, что я говорю здесь только о емкости хранилища и емкости памяти. Это не значит, что чтение или запись должны быть объявлены в разделе эту структуру. По его мнению, «тихий убийца» Эфириума — это исторический рост.
В письменном анализе исследовательская группа Paradigm объяснила: "Состояние — это набор данных, необходимый для создания и проверки новых блоков Ethereum. Состояние состоит из байт-кода контракта, хранилища контракта, баланса аккаунта и одноразового номера аккаунта. История — это данные". набор, необходимый для синхронизации узлов от генезиса до последнего блока. История состоит из блоков и транзакций. Состояние и история представляют собой непересекающиеся наборы данных. Сливкофф добавил, что история растет значительно быстрее, чем состояние Ethereum. Влияние на рост истории Самые большие варианты использования для скорости — это накопительные пакеты и другие типы протоколов, которые необходимо соединить с Ethereum.
Сливкофф рекомендовал разработчикам серьезно рассмотреть возможность ускорения разрешения исторически растущих EIP, таких как EIP 4444 и EIP 7623, в следующем обновлении Ethereum, Prague/Electra. Он также заявил, что будет проведен дальнейший анализ для анализа других узких мест масштабирования в Ethereum, и эти методы будут применены для анализа узких мест масштабирования накопителя в качестве следующего шага в исследованиях его команды. Все данные будут открыты для публичного использования, и обратная связь приветствуется, сказал Сливкофф.
После презентации Сливкоффа разработчики обсудили различные способы решения проблемы исторического роста в краткосрочной перспективе. Как обсуждалось в ACDE #180 , разработчики создают мощные альтернативные сети, в которых исторические данные за определенный период, например, до обновления слиянием, по-прежнему доступны пользователям в случае, если данные недоступны через узлы Ethereum. Эти данные. Для дальнейшего обсуждения исторического срока действия и альтернативных вариантов обслуживания исторических данных разработчик Geth «Lightclient» рекомендовал разработчикам продолжить разговор на канале Discord по исследованиям и разработкам Ethereum в теме подканала под названием «Исторический срок действия».
Прослеживаемость EIPIP7610 и 7523
Разработчики соглашаются реализовать EIP 7610 и 7523. Это ретроактивные EIP, которые добавят правила в протокол Ethereum, которые можно будет применять задним числом с самого начала сети для дальнейшего ограничения определенных типов поведения в цепочке. Преимущество этих EIP заключается в упрощении тестовых случаев Ethereum и ограничении объема различных крайних случаев, таких как крайний случай создания пустой учетной записи. Два EIP, которые были применены задним числом, включают EIPIP2681 и 3607. Разработчик согласился активировать два дополнительных ретроактивных EIP в Праге/Электре. Дополнительную информацию о том, каким поведением управляют эти EIP, см. в предыдущей расшифровке звонка здесь.
EIP 2537, предварительно скомпилированный BLS
Команда клиентов Geth выполнила некоторые тесты для оценки стоимости газа при эксплуатации кривой EIP 2537 BLS. Эти новые услуги будут активированы в обновлении «Прага/Электра», и в настоящее время разработчики взвешивают цены на эти услуги. Представитель команды Reth сообщил, что его команда также проведет дополнительные тесты операций по кривой BLS, чтобы помочь в определении затрат на газ для этих операций.
EIP 7547, включая список
Как обсуждалось в ACDC #130 , разработчики настоятельно рассматривают возможность включения EIP 7547 в обновление Praha/Electra. На этой неделе исследователь Ethereum Foundation Майк Нойдер поделился последней информацией о том, как можно изменить EIP 7547, чтобы обеспечить совместимость с абстракцией учетной записи. Абстракция учетных записей — это постоянная инициатива по обеспечению большей гибкости и программируемости внешних учетных записей (EOA), которые являются управляемыми пользователями учетными записями в Ethereum. Нойдер предложил три различных подхода к решению проблем совместимости между EIP 7547 и EIP абстракции учетной записи. Что касается этих решений, Нойдер сказал: «Это действительно похоже на сложность инклюзивного дизайна, но я думаю, что эти три варианта действительно работают, и я не думаю, что найдется волшебное средство для решения этой проблемы. думаю, что так и будет». Найдите лучший дизайн для решения этих проблем.
Бейко рекомендует продолжить обсуждение включения дизайна списков на отдельных секционных заседаниях в течение ограниченного времени.
Другие кандидаты EIP для Праги/Электры
Затем разработчики просмотрели список других EIP-кандидатов для обновления Прага/Электра. Они включают:
EIP 5920 (код операции PAY): исследователь Ethereum Foundation Сэм Уилсон отметил, что тестирование этого кода операции уже началось.
EIP 7609 (Снижение базовой стоимости TLOAD/TSTORE): участник компилятора Vyper Чарльз Купер подтвердил свое мнение о том, что коды операций TLOAD и TSTORE должны стоить дешевле в EVM.
EIP 2935 и 7545 (сохранение исторических хэшей блоков в состоянии и предварительная компиляция проверки доказательства Verkle): разработчик Geth Гийом Балле предложил эти два предложения в качестве изменений кода, которые обеспечат будущие преимущества реализации Verkle, и в то же время есть Экосистема Ethereum предстоящего обновления Verkle.
Формат объектов Ethereum (EOF): специалист по обслуживанию клиента Besu Данно Феррин рассказал, что EOF EIP реализуется несколькими клиентскими командами, и для них пишутся эталонные тесты. Он попросил разработчиков обратиться к матрице готовности EOF для получения более подробных обновлений.
EIP 7212 и EIP 3074 (поддержка кривой secp256r1 и предварительная компиляция кодов операций AUTH/AUTHCALL): разработчик Besu Мэтт Нельсон выделяет эти два EIP, реализуемые в объединении L2. Он подчеркнул, что для обеспечения совместимости между Ethereum и накопительными пакетами эти два EIP должны быть приняты в Праге.
EIP 7664 (код операции ключа доступа): разработчик OPLabs «Protolambda» предложил замену EIP 3074, которая использует списки доступа для улучшения функциональности кода операции AUTH/AUTHCALL.
EIP 6493 (Схема подписи транзакций SSZ): Protolambda также выразила поддержку изменений кода, связанных с SSZ, для повышения безопасности и эффективности проверки данных Ethereum.
У разработчиков не было времени обсуждать, какие EIP из этого списка должны быть приоритетными для Праги. Бейко сказал, что в начале следующей телеконференции ACDE через две недели будет выделено время для повторного рассмотрения списка. «В течение следующих нескольких недель нам следует более глубоко рассмотреть все поднятые сегодня вопросы и поработать над принятием решения. Я думаю, это означает, что если мы хотим двигаться вперед, через две недели все, что не было полностью выяснено или уточнено: «Ничто не может войти в эту развилку», — сказал Бейко.
Все комментарии