Сводка последней встречи основных разработчиков Ethereum: подготовка к реализации EIP 3074, дорожная карта Rollup

Оригинальное название: 《Ethereum All Core Developers Execution Call #186 Writeup》

Оригинальный автор: Christine Kim

Оригинальная компиляция: Frost, BlockBeats

Примечание редактора:

Консультационный звонок всех основных разработчиков Ethereum (ACDE) проходит каждые две недели и в основном обсуждает и координирует изменения в исполняемом слое Ethereum (EL). Это 186-й звонок ACDE, на котором разработчики обсудили подготовку к внедрению Pectra Devnet 0 и EIP 3074. Они подробно рассказали о прогрессе команд клиентов в подготовке Pectra Devnet 0 и обсудили предложения по изменениям в спецификации EIP 3074 и связанные с этим тестовые достижения.

Кроме того, в статье упоминаются и другие важные темы, такие как обсуждение других возможных изменений кода, которые могут быть включены в обновление Pectra, а также обсуждение того, как изменения в процессе EIP Ethereum могут быть затронуты процессом L2/RIP. Вице-президент по исследованиям Galaxy Digital Christine Kim подробно зафиксировала основные моменты этого звонка, и BlockBeats компилировал оригинал следующим образом:

25 апреля 2024 года разработчики Ethereum собрались в Zoom для участия в звонке All Core Developers Execution (ACDE) #186. Звонок ACDE — это серия встреч, которые проводятся каждые две недели, под председательством руководителя протоколов фонда Ethereum Тимом Бейко, на которых разработчики обсуждают и координируют изменения в исполняемом слое Ethereum (EL). На этой неделе разработчики обсудили подготовку к внедрению Pectra Devnet 0 и EIP 3074. Они также обсудили, какие другие EIP следует рассмотреть для включения в обновление Pectra, а также широкие размышления о том, как «дорожная карта, ориентированная на Rollup», повлияет на изменения в управлении.

Последние достижения Pectra Devnet 0

Бейко на звонке попросил команды клиентов поделиться последними достижениями Pectra Devnet 0. Марек Морацыньский из команды Nethermind сообщил, что Nethermind реализовал все EIP Pectra и проводит тестирование. Джастин Флорентин из команды Besu сообщил, что Besu внедряет EIP Pectra и готовит запуск Devnet 0. Эндрю Ашикмин из команды Erigon сказал: «Я не уверен, готов ли Erigon к полному набору EIP для Devnet 0, отчасти потому, что спецификации этих EIP все еще продолжают меняться, и клиент Erigon переходит на новую основную версию Erigon 3, что занимает ресурсы и время команды. Erigon 3 и EIP Pectra будут окончательно определены и встроены в клиент Erigon». Команда Geth «Lightclient» заявила, что Geth потребуется «несколько дней», чтобы подготовиться к Devnet 0. Гаджиндер Сингх из команды Ethereum JS сообщил, что Ethereum JS также будет «готов» к Devnet 0.

EIP -7685

Lightclient объединил EIP 7685, который создает универсальную структуру для хранения запросов, инициированных EL, на уровне консенсуса (CL), и его влияние на EIP 6110 и 7002. Бейко заявил, что разработчики должны включить этот EIP в свою версию Devnet 0 и постоянно улучшать EIP Pectra.

Что касается тестирования, Марио Вега из тестовой команды EF сообщил, что тестирование EIP 6110 и 2537 завершено, а тестирование EIP 7002 и EIP 2935 будет завершено на этой или следующей неделе. Тестирование EIP 3074 еще не готово для Devnet 0. Исследователь EF Антонио Сансо сообщил, что спецификация EIP 2537 обновлена, и в репозиторий GitHub добавлены новые тестовые векторы, он предложил всем взглянуть на GitHub. Исследователь EF Сяо Вэй Ван указал на ошибки в тестовых векторах спецификации CL, и ошибка была быстро исправлена, а новая версия выпущена.

Обновление EIP -3074

На этом звонке ACDE было предложено несколько изменений в спецификации EIP 3074. Ахмад Мазен Битар предложил изменить поведение EIP 3074, чтобы разрешить выполнение DELEGATECALL перед AUTH CALL, что расширит случаи использования EIP. Основатель и генеральный директор операционной системы блокчейн-кошелька ZeroDev Дерек Цзян предложил создать «noncemanager», чтобы облегчить глобальное аннулирование AUTH-сообщений и других изменений по мере необходимости. Некоторые разработчики, участвующие в звонке, считают, что изменения в EIP 3074 следует отложить, так как это значительно усложнит его реализацию.

Бейко предложил разработчикам обсудить предложенные изменения в EIP 3074 на отдельной групповой встрече. Он отметил, что для того чтобы у разработчиков было достаточно времени для внедрения EIP 3074 в Pectra, они должны попытаться «определить его окончательную спецификацию в течение ближайших одного-двух месяцев». Lightclient согласился организовать групповую встречу по EIP 3074. Что касается Devnet 0, Бейко подтвердил, что команды клиентов должны внедрить EIP 3074 без каких-либо изменений, даже если разработчики могут решить внедрить EIP другим способом в будущем или полностью удалить его из обновления.

Помимо деталей реализации EIP 3074, разработчики также серьезно обсудили, есть ли у EIP достаточная поддержка сообщества. Один из разработчиков с именем «Siri» выразил обеспокоенность во время звонка, заявив: «EIP 3074 в принципе ужасен и замедлит нас в достижении полной абстракции аккаунтов». Бейко ответил, что, согласно обсуждениям с Ethereum Magicians и на звонке ACD, команды клиентов, похоже, поддерживают EIP 3074, а не другие предложения, связанные с абстракцией аккаунтов (AA). Бейко сказал: «Это, похоже, наиболее согласованное предложение на данный момент, и мы действительно можем улучшить состояние EOA в следующем форке». На это Siri считает, что команды клиентов не должны принимать это решение изолированно. «Мы должны выслушать мнения других заинтересованных сторон», — сказал Siri, добавив: «Мы не хотим переходить к созданию спорных хардфорков… Я думаю, что лучше понять мнение других заинтересованных сторон и то, как они относятся к этому предложению».

Бейко и Siri также обсудили, как создать более широкое согласие по EIP вне звонка ACD. Чианг предложил сначала провести групповую встречу по EIP 3074, чтобы углубленно обсудить технические спецификации EIP, а затем решить, следует ли сохранять его в обновлении Pectra. Исследователь EF Ансгар Дитрихс заявил: «Мы должны понимать, что, если мы не добьемся достаточного прогресса, EIP 3074 будет отозван».

Соучредитель Ethereum Виталик Бутерин добавил: «В ближайшие годы функции аккаунтов пользователей изменятся, особенно для внешних обладающих аккаунтов (EOA). Активируйте EIP, связанный с абстракцией аккаунтов, такие как EIP 3074 и т.д.»

Другие предложения Pectra

Разработчики продолжили обсуждать, какие другие изменения кода следует рассмотреть для включения в обновление Pectra. Разработчик Geth Мариус ван дер Виден заявил, что это должно зависеть от того, будет ли EIP с высокой сложностью, как EOF, включен в Pectra. «Если мы включим EOF, это приведет к насыщению форка. Если мы не включим EOF, возможно, мы сможем включить больше», — сказал ван дер Виден.

Siri выразил обеспокоенность по поводу включения EIP 3074 в Pectra без проверки безопасности. Бейко предложил отложить это обсуждение до окончательной спецификации EIP 3074.

Битар заявил, что хотел бы видеть добавление EIP 7212 в Pectra. EIP 7212 создаст новый предварительно скомпилированный код для выполнения проверки подписи на эллиптической кривой secp256 r1. Это можно использовать с аппаратными устройствами, поддерживающими биометрическую аутентификацию пользователей. Битар отметил, что поддержка биометрии для подписания транзакций Ethereum станет значительным улучшением пользовательского опыта. Ашикмин также поддержал это предложение. Дитрихс отметил, что это единственное предложение, которое было одобрено для реализации через процесс «Rollup Improvement Proposal» (RIP) командой Layer-2 Rollups.

Другие разработчики, включая Дитрихса, ван дер Видена и Морацыньского, выразили поддержку EIP 7623, который увеличит стоимость данных вызова, тем самым ограничивая максимальный размер блока. Бейко предложил пометить EIP 7623 и EIP 7212 как «рассматриваемые для включения» или CFI в Pectra и пересмотреть пропускную способность команд клиентов для поддержки этих двух предложений после запуска Devnet 0.

Что касается пакета EIP, связанного с обновлением метода сериализации EL до SSZ, ван дер Виден выразил опасения, что это будет слишком сложно для транспортировки в Pectra. Его коллега из команды Geth Гийом Балле также согласился с этой оценкой. Бутерин вставил: «По крайней мере, обновление метода сериализации для квитанций о транзакциях будет иметь «значительную ценность» за пределами самого Ethereum, поскольку оно устраняет дополнительные расходы на безопасность для второго уровня Rollup, построенного на Ethereum». Основной сторонник EIP, связанного с SSZ, Этан Кисслинг из команды Nimbus, не присутствовал на звонке, но он написал подробное объяснение на GitHub, объясняющее, почему эти изменения кода важны и должны быть рассмотрены для включения в Pectra.

Разработчики также снова обсудили EOF. Независимый разработчик протокола Ethereum Дано Феррин сообщил, что команда EOF проводит тестирование спецификаций EL для изменений кода. EVMOne и Reth — две команды клиентов EL, которые, как сообщается, завершили реализацию EOF. Феррин сообщил, что команда Geth добилась «хорошего прогресса» в реализации. Феррин добавил, что Балле работает с «Даниэлем» из команды Solidity, чтобы решить проблемы совместимости с EOF и Verkle.

Балле отметил, что, согласно его разговорам с Даниэлем и другими разработчиками, такими как Дитрихс, трудно сузить область применения EOF, не противореча его цели, и создать больше работы для разработчиков в будущем для реализации другой группы изменений кода, аналогичных EOF.

Разработчик с именем «Charles C» предложил найти способ легко итеративно реализовать EOF через механизм Side Car (например, механизм для Blob-транзакций), а не выбирать между небольшими или большими обновлениями EOF. Дитрихс в чате спросил, будет ли у команды клиентов больший интерес, если снизить сложность EOF в Pectra. Команда Ipsilon отметила, что код, который вызывает наибольшую сложность в EOF (например, «TX create»), уже решен, и удаление конкретных запросов, таких как «EOF create», не значительно снизит общую сложность EOF. Для справки, Ipsilon — это название команды разработки EVM, финансируемой EF. Бейко предложил разработчикам продолжить обсуждение реализации EOF на повторяющихся групповых обсуждениях по EOF.

ACD / EIP и L2 / RIP

В качестве последней темы обсуждения на ACDE #186 разработчики обсудили изменения в процессе EIP Ethereum, учитывая новый процесс RIP. Дитрихс отметил, что с тех пор, как разработчики начали серию встреч по координации Rollup, RollCall и процессу RIP, прошло шесть месяцев. Существует несколько нерешенных вопросов о том, как эти процессы будут и должны влиять на процесс EIP Ethereum. Дитрихс заявил, что одним из исследовательских вопросов, находящихся в стадии разработки на L2, является то, является ли долгосрочная эквивалентность с виртуальной машиной Ethereum (EVM) желательной для Rollup. Он также добавил, что один из нерешенных вопросов заключается в том, в какой степени изменения, внедренные на L2, в конечном итоге повлияют на принятие протокольных решений на первом уровне Ethereum.

Разработчик Geth Петер Силаги заявил, что некоторые функции, предлагаемые на L2, могут не подходить для предоставления на L1, и в некоторых случаях, даже если следовать функциям, предоставляемым на L2, между L2 могут быть различия, что может вызвать путаницу у разработчиков протоколов Ethereum. Исследователь EF Карл Бейкхейзен отметил, что RollCalls и процесс RIP не требуют от разработчиков протоколов Ethereum публикации каких-либо функций на L2, а скорее улучшают коммуникацию между Rollups и разработчиками Ethereum, чтобы избежать путаницы, описанной Силаги. Ван дер Виден выразил обеспокоенность по поводу того, что разработчики протоколов тратят время на поддержку изменений, внедренных на L2, которые в конечном итоге могут стать устаревшими или ненужными, поскольку L2 может закрыться или перестать использоваться.

На эти опасения Дитрихс ответил: «Я думаю, что люди всегда считали, что Layer 2 может экспериментировать и становиться более безумным. Я думаю, что на практике мы видим, что большинство из них решают этого не делать, или, по крайней мере, могут начать это делать, а затем со временем большинство из них останавливаются. Так что сейчас они на самом деле в основном следуют спецификациям первого уровня. Я думаю, что, по крайней мере, учитывая дорожную карту, ориентированную на Rollup, или мы все считаем, что это лучший способ развития экосистемы, мы как минимум обязаны Layer 2 четкими указаниями и коммуникацией о том, каковы лучшие пути вперед здесь.»