<p>Сводка последнего собрания основных разработчиков Ethereum: EIP-2935 и EIP-3074 будут включены в обновление Pectra.</p>

Команды клиентов поддерживают EOF в Праге. БейкоО предложил разработчикам перенести обсуждение на другие EIP и вернуться к обсуждению EOF позже в ходе конференц-звонка. EIP 3074, Опкоды AUTH и AUTHCALL Бейко спросил у команды клиентов их мнение по поводу EIP 3074, в частности введение опкодов AUTH и AUTHCALL. Эти опкоды позволят смарт-контрактам авторизовывать транзакции от внешних учетных записей (EOA) и добавлять больше программирования в учетные записи, управляемые пользователями. Многие разработчики на звонке, включая Георгиоса Константопулоса, Данно Феррина и "protolambda", поддержали этот изменения кода. Protolambda вновь представил свое предложение EIP 7664, направленное на исправление логики EIP 3074 при взаимодействии с списками доступа. Разработчики Geth и соавтор EIP 3074, Мэтт Гарнетт, также известный как "Lightclient", выразили поддержку EIP 7664. Другой разработчик поинтересовался, как EIP 3074 повлияет на опкод ORIGIN, который возвращает адрес, инициировавший транзакцию. Бейко отметил, что эти влияния перечислены в EIP, и спросил, есть ли у разработчиков возражения против включения этого изменения кода в Прагу. Возражений не было. EIP 2935, Сохранение исторического состояния хэша блока Балет представил EIP 2935 в ACDE #184, изменение кода, которое принесет будущие выгоды для реализации Verkle. Команда клиентов Reth выразила "нейтрально-положительное" отношение к этому EIP и упомянула, что, учитывая его простоту, они не противятся его включению в Прагу. Команда клиентов Erigon выразила схожее отношение, но отметила, что их уверенность включить его в Прагу будет ниже, если включены более крупные изменения кода, такие как EOF. Бейко предложил продолжить обсуждения других EIP и вернуться к EIP 2935 позже в ходе конференц-звонка. EIP 7667, Увеличение стоимости газа для хэш-функций Сооснователь Ethereum Виталик Бутерин предложил EIP 7667 для увеличения стоимости газа для опкодов хэш-функций и предвычислений, чтобы согласовать их с затратами на выполнение через системы нулевого знания (ZK) как ZK EVMs. Для получения дополнительной информации о ZK EVMs обратитесь к отчету исследовательской группы Galaxy Research. Относительно мотивации для переоценки операций хэширования Ethereum Бутерин написал в документе EIP 7667: "Стоимость газа для опкодов хэш-функций и предвычислений изначально устанавливалась на основе времени их выполнения на обычном ЦП. Однако впоследствии появился еще один равно важный случай использования: системы доказательств нулевого знания (ZK-SNARK). По этому стандарту эти опкоды и предвычисления недооценены по сравнению с другими операциями." Бутерин также упомянул в ходе конференц-звонка, что легко недооценить увеличивающееся распространение ZK-доказательств, не только для проверки Layer-2 роллапов, но и включая блокчейны Layer-1, такие как Ethereum. Он заявил: "Я думаю, что даже через год или два у нас может появиться возможность делать доказательства в реальном времени для Ethereum L1. Поэтому я считаю важным адаптироваться к тому факту, что больше нет различий между ZK-цепями и неЗК-цепями. Мы фактически входим в режим, где каждая серьезная цепь является ZK-цепью." Учитывая, что обновление Verkle в хардфорке Осака изменит ценообразование газа и расписания, Феррин предложил внедрить этот EIP параллельно с Verkle. Исследователь EF Карл Бикхуизен отметил, что для этого EIP требуется обширное исследование, и разработчики должны тщательно проанализировать, как эти изменения газа повлияют на смарт-контракты на Ethereum. Ван дер Вайден согласился с осторожным подходом Бикхуизена к продвижению этого EIP. Феррин также предложил потенциально сначала внедрить эти изменения на Layer-2 роллапах, а затем изучить их влияние на Layer-1 Ethereum далее. Бейко согласился с этим подходом и предложил разработчикам рассмотреть включение EIP 7667 с Verkle в обновление Осака, дав ему статус "CFI" или "рассматривать для включения". Возражений не было. EIP 7623, Увеличение стоимости calldata Соавтор EIP 7623, исследователь EF Тони Варштеттер, поделился своим предложением увеличить стоимость calldata и спросил мнение команды клиентов. Исследователь EF Ансгар Дитрихс и разработчик Nethermind Ахмад Битар выразили своиПоддержка. Бикхейзен добавил, что не было возражений против внедрения EIP 7623, когда он был предложен на последнем собрании Rollcall, серии встреч между командами Layer-2 rollup. Бейко предложил продолжить обсуждения других EIP и вернуться к этому EIP позже во время конференц-звонка. EIP 7645, Переименование ORIGIN в SENDER Бейко поинтересовался мнением команды клиентов относительно EIP 7645, направленного на изменение поведения операции ORIGIN для предотвращения злоупотребления смарт-контрактами. Кайрус Адкиссон, ранний инвестор Ethereum и автор EIP 7645, отметил, что обновление операции ORIGIN имеет три возможных пути, каждый с разными компромиссами. Феррин упомянул, что пути, предлагающие изменения в поведении операции, требуют тщательного обзора со стороны специалистов по безопасности и аудиторских фирм, поскольку разработчики протокола Ethereum не могут полностью оценить влияние таких изменений на существующие смарт-контракты и конечных пользователей. Бейко предложил, что в целях экономии времени разработчики продолжат обсуждение других EIP. EIP 7547, Список включения Бейко спросил разработчиков о их мнении относительно включения EIP 7547 в Праге. Исходя из ответа команды клиентов EL, не кажется, что существует широкая поддержка этого изменения кода. Бейко предложил исключить его из обновления. Не было возражений. Предложение по корректировке кривой эмиссии Дитрихс предложил снизить эмиссию Ethereum. Учитывая, что эта изменение в основном затрагивает исполнительный уровень Ethereum, Бейко предложил разработчикам дальше обсудить преимущества этого предложения на конференц-звонке ACDC. Повторное обсуждение EOF, EIP 7623 и 2935 для Праги Затем разработчики вернулись к EIP, предложенным для Праги, над которыми не было достигнуто согласие. Бейко узнавал, можно ли объединить EOF с обновлением Verkle. Балет настойчиво выступил против этой идеи, заявив, что оба изменения кода являются сложными, и их одновременная реализация была бы "слишком рискованной". Протолямбда подчеркнул, что EIP 7664 - еще один EIP, который следует рассмотреть для включения в Прагу. Гарнетт добавил, что EIP 7639, предложение о том, чтобы клиенты перестали предоставлять исторические данные до обновления слияния (сентябрь 2022 года), также следует учесть. Были высказаны опасения относительно дополнительной нагрузки, которую включение EOF наложит на команду клиентов, и разработчик Reth Георгиос Константопулос призвал разработчиков "пойти на всё". Однако по-прежнему не было достигнуто согласие относительно EOF. Разработчики в конечном итоге согласились продолжать работу над EOF, особенно над необходимым тестированием, и позже принять решение о его включении в Прагу. Они также согласились отложить решение относительно EIP 7623. Что касается EIP 2935, разработчики согласились включить его в Прагу. Подводя итоги всех принятых решений на конференц-звонке, Бейко заявил, что разработчики включат EIP 3074 и EIP 2935 в первую сеть разработки обновления Pectra. После этой сети разработки они согласились принять решение о включении EOF и/или EIP 7623 во вторую сеть разработки Pectra. [Ссылка на оригинальную статью] Добро пожаловать в официальное сообщество BlockBeats: Группа подписки в Telegram: https://t.me/theblockbeats Группа общения в Telegram: https://t.me/BlockBeats_App Официальный аккаунт в Twitter: https://twitter.com/BlockBeatsAsia