Резюме последней встречи основных разработчиков Ethereum: согласие на удаление EIP 3074, включая EIP 7702

Оригинальное название: 《All Core Developers Execution Call #188 Writeup》
Автор: Christine Kim
Составитель: Luccy, BlockBeats

Примечание редактора:
Консенсусный звонок всех основных разработчиков Ethereum (ACDE) проходит каждые две недели и в основном обсуждает и координирует изменения в слое выполнения Ethereum (EL). Это 188-й звонок ACDE, на котором разработчики обсудили и согласовали изменения в слое выполнения Ethereum.

На встрече было рассмотрено множество важных вопросов, включая новые функции API выполнения, минимальные требования к чаевым для Geth, обсуждение сетей разработки Pectra 0 и 1, диапазон форка Pectra и истечение исторических данных. Разработчики провели глубокое обсуждение и обмен мнениями по этим вопросам и достигли некоторого консенсуса по диапазону, графику и конкретным деталям реализации обновления Pectra.

Вице-президент по исследованиям Galaxy Digital Christine Kim подробно зафиксировала основные моменты встречи, и BlockBeats составил оригинал следующим образом:

23 мая 2024 года разработчики Ethereum собрались в Zoom для участия в звонке All Core Developers Execution (ACDE) #188. Звонок ACDE — это серия встреч, которые проводятся каждые две недели, под председательством Тима Бейко, руководителя отдела поддержки протоколов фонда Ethereum, на которых разработчики обсуждают и координируют изменения в слое выполнения Ethereum (EL). На этой неделе разработчики обсудили следующее:

• Добавление новых функций в API выполнения, позволяющих пользователям получать «возвращаемые данные» (returndata) транзакций
• Минимальные требования к чаевым для Geth
• Pectra Devnet 0 и 1
• Диапазон форка Pectra
• Интеграция истечения исторических данных Portal Network.

· Они согласились удалить EIP 3074 из Pectra Devnet 0 и включить EIP 7702 в следующую тестовую сеть Pectra Devnet 1, ориентированную на разработчиков.

Добавление возвращаемых данных (Returndata) в квитанцию о транзакции

Разработчик языка программирования смарт-контрактов Vyper Чарльз Купер предложил изменить одну из конечных точек API выполнения, чтобы пользователи могли получать возвращаемые данные (returndata) транзакций при получении квитанции о транзакции. Купер объяснил, что в настоящее время распространенный способ получения возвращаемых данных разработчиками, такой как отслеживание транзакций, не стандартизирован и не поддерживается во всех клиентах. В ответ на отзывы команд клиентов, таких как Reth, Купер заявил, что другим решением будет создание новой конечной точки в API выполнения для получения возвращаемых данных (returndata) транзакций. Разработчики не смогли достичь консенсуса по этому предложению на звонке. Бейко предложил разработчикам продолжить обсуждение на GitHub и попытаться решить эту проблему асинхронно вне встречи.

Минимальные требования к чаевым для майнеров

Затем разработчик Geth Петер Силаги поднял недавние опасения пользователей по поводу настроек по умолчанию клиента Geth. С момента внедрения EIP 1559 клиент Geth всегда принудительно применял минимальные требования к чаевым по умолчанию для транзакций. После слияния минимальные чаевые в 1 gwei не работали должным образом, и только недавно команда Силаги обнаружила и исправила эту проблему. После восстановления этой настройки по умолчанию пользователи обнаружили, что блоки, созданные с помощью клиента Geth, значительно более пустые, чем другие блоки, поскольку они исключали транзакции с почти нулевыми чаевыми. Это вызвало беспокойство о том, что настройки по умолчанию могут негативно повлиять на динамику предложителей и строителей блоков, поскольку это может привести к задержке обработки действительных транзакций без чаевых.

Разработчик Nethermind Томаш К. Станчак заявил, что минимальные требования к чаевым по умолчанию Geth являются несущественной проблемой, и разработчики протокола не должны пытаться стандартизировать или принуждать к их соблюдению. Исследователь EF Ансгар Дитрихс предложил снизить минимальные чаевые по умолчанию, поскольку в настоящее время базовая стоимость транзакций Ethereum очень низка. Другие разработчики предложили установить минимальные чаевые по умолчанию в Geth как процент от базовой стоимости, а не фиксированную сумму. Однако Бейко выступил против этого, считая, что чаевые не предназначены для того, чтобы быть платой за включение транзакции в блок. Они должны использоваться только для приоритета включения транзакции в следующий блок, и использование минимальных чаевых, основанных на колебаниях базовой стоимости, может исказить изменения базовой стоимости, поскольку часть стоимости будет отражена в чаевых транзакции.

Бейко добавил, что другой аспект обсуждения заключается в том, как поощрять строителей создавать блоки с нулевыми чаевыми и предоставлять предложителям внебюджетные выплаты в качестве компенсации. Эта ситуация может возникнуть как с минимальными требованиями к чаевым, так и без них, но установка значения по умолчанию может создать норму, побуждающую строителей не создавать блоки с нулевыми чаевыми. Силаги отметил, что в некотором смысле вопрос о том, должны ли строители включать транзакции с нулевыми чаевыми в блоки, является философским. С сетевой точки зрения эти транзакции являются действительными и должны быть включены в блоки. Однако с точки зрения финансовых стимулов для предложителей включение транзакций с нулевыми чаевыми в блоки не имеет экономической выгоды, и поэтому они не должны быть включены.

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

Pectra Devnet -0

Разработчик фонда Ethereum (EF) Партхош Джаянти обновил информацию о сети разработки Pectra. Первая сеть разработки была запущена на прошлой неделе в Кении на оффлайн-встрече разработчиков протокола Ethereum под названием Nyota Interop. Джаянти сообщил, что сеть разработки включает всех клиентов слоя выполнения и слоя консенсуса. Однако EIP 3074 еще не прошел интенсивное тестирование и содержит ошибки, которые необходимо исправить. Команды клиентов готовятся к запуску второй сети разработки Pectra Devnet 1, которая будет включать изменения для реализации EIP 2935.

Изменения в диапазоне Pectra

Разработчики затем обсудили изменения в диапазоне обновления Pectra. Независимые разработчики протокола Ethereum Дано Феррин, разработчик Reth Георгиос Констанопулос и представители команды Solidity поддержали включение EOF в Pectra. Разработчик Geth Мариус ван дер Виден сообщил, что он реализует спецификацию EOF. Однако он подчеркнул, что из-за сложности EOF включение его определенно задержит активацию обновления Pectra. Разработчики Lodestar и EthereumJS Гаджиндер Сингх упомянули в чате Zoom, что разработчики должны сосредоточиться на выпуске текущей версии Pectra, а не на расширении диапазона обновления. Исследователи EF Алекс Стокс и Пайпер Мерриам согласились с мнением Сингха.

После обсуждения EOF разработчики обсудили прогресс EIP 7702. EIP 7702 был предложен соучредителем Ethereum Виталиком Бутериным как альтернатива EIP 3074. Важные детали EIP 7702, такие как его отменяемый дизайн, все еще не решены. Один из разработчиков по имени «dror» написал в чате Zoom: «EIP 7002 — это версия EIP 3074, которая ранее принимала только версии с nonce и chain ID. Теперь они были удалены, и нам нужно снова обсудить причины. Я предлагаю начать обсуждение этих ограничений заново.» Разработчик Besu Даниэль Лернер предложил получить больше мнений от разработчиков кошельков о дизайне EIP 7702. Разработчик Erigon Андрей Ашикмин подчеркнул, что необходим способ, позволяющий пользователям обходить кошельки для отмены авторизации.

Бейко предложил продолжить обсуждение деталей реализации EIP 7002 на отдельной встрече группы. В то же время разработчики согласились удалить EIP 3074 из Devnet 0 и включить EIP 7702 в Devnet 1.

Еще два EIP, которые планируется включить в Pectra, это EIP 7623 (увеличение стоимости calldata) и EIP 7212 (поддержка предкомпиляции для кривой secp256 r1). Исследователь EF Тони Вахрштеттер поделился последними новостями о EIP 7623, а разработчик кошельков смарт-контрактов Улаш Эрдоган поделился последними новостями о EIP 7212. Разработчики не достигли согласия по поводу того, должны ли эти два EIP быть включены в Pectra.

Ожидания по графику Pectra

Констанопулос упомянул, когда разработчики должны активировать обновление Pectra в основной сети Ethereum. В документе, который был поделён перед звонком, команда клиента Reth написала, что попытка выпустить обновление до конца 2024 года «не имеет большого значения», и разработчики должны готовиться к выпуску обновления в начале 2025 года. Команда EF Panda Ops (подгруппа команды разработчиков EF) также поделилась документом перед звонком, в котором выразила свое мнение о графике и диапазоне Pectra. Они предложили разделить Pectra на два форка: один активировать в этом году, а другой, включающий MaxEB, EOF и возможный peerDAS, активировать в начале следующего года. Джаянти отметил, что команда EF Panda Ops не единодушна в своих взглядах, но он лично считает, что диапазон Pectra следует разделить на два форка. Он указал, что крайние случаи обновления Pectra и взаимодействие EIP еще не протестированы.

Разработчик Solidity EF Алекс Берегсази выразил беспокойство, что если EOF не будет включен в Pectra, эти изменения кода никогда не будут включены в обновления Ethereum. Разработчики Geth Мариус ван дер Виден и Гийом Балле выступили против этого, считая, что преимущества EOF достаточно значительны, и даже если его задержать на несколько форков, его полезность все равно останется.

Бейко предложил сначала достичь консенсуса о том, как приоритизировать peerDAS и увеличение размера blob, а затем определить оставшийся диапазон обновления. Он предложил разработчикам, которые будут участвовать в следующей встрече All Core Developers Consensus (ACDC), сосредоточиться на этой теме. Он надеется, что разработчики будут готовы окончательно определить диапазон Pectra на следующей встрече ACDE.

Portal Network и истечение исторических данных

Наконец, Мерриам отметила, что команда Portal Network готова сотрудничать с разработчиками протокола для параллельного выпуска версии с истечением исторических данных вместе с Pectra. Дополнительную информацию о Portal Network можно найти здесь.