Тест Hoodi, запланированный на 26 октября, был отменён, включая запланированный лимит газа в 200 миллионов. Разработчики изучают предложение о пересмотре цен на фоне контрактов, уже работающих в основной сети.
Краткое содержание
- Разработчики Ethereum отложили активацию Glamsterdam в Hoodi, запланированную на 26 октября на эпохе 132 352, не назначив дату замены.
- Задержка последовала за вопросами о том, как EIP-8037, повышающий стоимость создания состояния цепочки, взаимодействует с существующими смарт-контрактами основной сети.
- Активации исполнения Amsterdam и консенсуса Gloas были обе удалены из расписания Hoodi, вместе с запланированным переходом на лимит газа в 200 миллионов.
- Проведённый ранее в Ethereum повтор транзакций показал, что большинство контрактов не затронуто, но выявил небольшую группу, полагающуюся на фиксированные газовые стипендии, жёстко заданные лимиты или логику остаточного газа.
- Операторам Hoodi необходимо проверить инструкции для клиентов исполнения и консенсуса, чтобы их программное обеспечение не активировало старый форк 26 октября.
Ethereum отменил тест, который должен был состояться в следующий понедельник. Уведомление Ethereum Foundation от 22 октября сообщает, что Glamsterdam не будет активирован в Hoodi в 17:42:48 UTC 26 октября, и новая эпоха не назначена. Сопутствующее увеличение лимита газа до 200 миллионов также снято с расписания тестовой сети. Это отсрочка будущей конфигурации, а не отмена блоков, уже записанных Hoodi.
Разработчики приняли решение изучить, как EIP-8037 — изменение цены создания нового состояния Ethereum — взаимодействует с контрактами в основной сети. Фонд не заявлял, что обновление сломало основную сеть. Он также не назначил дату производственного форка. Непосредственный операционный риск касается Hoodi: клиенты или пользовательские конфигурации, всё ещё содержащие старое время активации, могут не согласоваться с пересмотренным расписанием. Более глубокий вопрос заключается в том, как изменить стоимость работы внутри транзакции, не нарушая приложения, которые встроили старые числа в код.
Форк Hoodi от 26 октября снят с календаря
Объявление Hoodi от 16 октября указывало эпоху 132 352 и слот 4 235 264. Оно сочеталось с изменениями уровня исполнения Amsterdam, изменениями уровня консенсуса Gloas и лимитом газа в 200 миллионов. Новое уведомление полностью заменяет эти инструкции. Операторам следует прочитать последние примечания к выпуску для обоих типов клиентов; более ранний выпуск, описанный как совместимый с Glamsterdam, может всё ещё содержать теперь отменённую активацию Hoodi.
Это больше, чем сноска в расписании. Валидатор должен следовать тем же сетевым правилам, что и его пиры. Если часть его программного обеспечения ожидает новые правила исполнения или обязанности консенсуса на старой эпохе, тогда как сеть этого не делает, он может потерять способность следовать канонической цепочке. Инфраструктура билдеров и валидаторов может иметь собственную конфигурацию. Поэтому Фонд предписывает операторам проверить пересмотренные версии клиентов и удалить устаревшие пользовательские настройки до 26 октября, а не предполагать, что бездействие безопасно из-за задержки форка.
Sepolia активировала Glamsterdam 6 октября и протестировала лимит газа в 200 миллионов, как зафиксировало освещение этой активации. Успешная активация в одной тестовой сети полезна, но не является окончательной для другой. Оставшаяся репетиция Hoodi была отложена именно потому, что расследование контрактов требует времени. Опубликованной даты замены, которую можно было бы экстраполировать в дату основной сети, нет.
Glamsterdam активирована в Sepolia 6 октября, где разработчики протестировали лимит газа в 200 миллионов. Успешный тест не решает вопрос о том, как EIP-8037 повлияет на контракты, уже работающие в основной сети. Репетиция Hoodi отложена, пока разработчики исследуют эти взаимодействия, и дата замены не объявлена.
Последовательность в этом году менялась не раз. Сентябрьский отчет о плане Sepolia описывал проблемы devnet и проблему реализации EIP-8037 до того, как публичное тестирование продолжилось. Эти более ранние проблемы не являются доказательством той же причины, что и октябрьский запрос по контрактам от 22 октября. Они показывают, почему даты были условными, поскольку команды клиентов переходят от частных испытаний к публичным сетям. Отдельные опасения по поводу поведения билдеров в тестовых сетях касаются другой части Glamsterdam и не должны смешиваться с переоценкой стоимости. Последнее уведомление приводит одну конкретную причину паузы в Hoodi: дальнейшее исследование взаимодействия EIP-8037 с контрактами основной сети.
Почему создание состояния стоит дороже в предложении
Транзакция может выполнять вычисления и может оставлять данные, которые сеть должна хранить и к которым должна обращаться позже. Создание нового аккаунта, открытие нового слота хранения или развертывание байт-кода контракта увеличивает это постоянное состояние. EIP-8037 предлагает взимать больше за эти операции и учитывать часть, связанную с созданием состояния, отдельно. Цель — приблизить цену к более долговременной нагрузке на узлы, особенно если блокам будет разрешено нести больше работы.
Иллюстративная таблица предложения устанавливает компонент создания состояния для нового аккаунта в 183 600 газа по сравнению с текущими 25 000; для нового слота хранения — 97 920 по сравнению с 20 000; а для развертывания объемом 24 килобайта — 37 784 880 по сравнению с 4 947 200. Таблица не является универсальным прогнозом комиссии в ETH, которую заплатит пользователь. Она изолирует компонент при предлагаемой константе, с другими расходами на выполнение сверху, а итоговая стоимость в валюте зависит от цены газа в тот момент. Масштаб изменения объясняет, почему контракты с жесткими лимитами заслуживают более внимательного изучения.
Связанное предложение о доступе к состоянию, EIP-8038, переоценивает некоторые операции чтения и записи. Руководство по влиянию на разработчиков Фонда говорит, что эти затраты газа в последний раз существенно корректировались в форке Berlin в 2021 году, тогда как состояние выросло. Планируемая переоценка была разработана вместе с работой по повышению пропускной способности; увеличение блоков без учета дорогостоящих операций с состоянием могло бы усложнить валидацию для операторов узлов. Таким образом, пауза затрагивает как совместимость приложений, так и план масштабирования, хотя объявленным триггером является взаимодействие с EIP-8037.
Внешний вызов показывает, почему это может быть трудно заметить заранее. Вызывающий может намеренно передать только достаточно газа, чтобы получатель выполнил ограниченное действие, предполагая, что любая дальнейшая работа безопасно завершится неудачей. Если переоцененный доступ к аккаунту или хранилищу теперь потребляет это разрешение, получатель может потерпеть неудачу во время обычного платежа, даже если пользователь предоставил достаточно газа для внешней транзакции. Изменение оценки в кошельке не переписывает внутреннее разрешение. Разработчикам необходимо изучить путь кода и обработку сбоев вокруг него, поскольку некоторые приложения считают неудачный внешний вызов причиной для отката, тогда как другие продолжают и фиксируют иной результат.
Паттерны transfer и send в Solidity исторически передают стипендию в 2 300 газа. Многие команды уже отошли от reliance на эту стипендию, но развернутые контракты могут оставаться в использовании годами. Фонд определяет фиксированные стипендии как одну из категорий риска; он не утверждает, что каждый вызов, использующий их, потерпит неудачу. Получатель, выполняющий мало работы, может остаться в пределах разрешения, тогда как контракт, который обращается к недавно переоцененному состоянию, может его превысить. Тестирование реальных контрагентов важнее, чем рассмотрение самого наличия имени функции как доказательства поломки.
Второй класс проблем заключается в автоматизации. Кошельки, релееры и кастодианы могут хранить лимиты газа по умолчанию для регулярных задач. Операция, которая успешно выполнялась годами, может начать исчерпывать газ, даже если сам контракт приложения исправен. Повышение оценки на фронтенде может исправить этот маршрут, но запланированный агент или клиент, использующий старый кошелек, может продолжать отправлять предыдущий лимит. Поэтому разработчикам приходится определять не только затронутый код, но и сервисы, которые формируют для него транзакции.
Какие контракты могут столкнуться с проблемами?
Фонд воспроизвёл исторические транзакции основной сети в соответствии с предлагаемым графиком. У большинства не возникло существенных проблем. Из числа отмеченных случаев многие завершились после повышения лимита газа; меньшая группа могла бы завершиться неудачей даже при существенно большем количестве газа. Фиксированная надбавка, жёстко заданное количество газа, отправляемого в другой контракт, или ветвление на основе результата gasleft() могут изменить путь, по которому проходит транзакция. Более раннее предупреждение о контрактах описывало эти категории ещё до того, как Hoodi получил свою октябрьскую дату. Текущая отсрочка делает нерешённые случаи срочными, но она не показывает, что все контракты Ethereum уязвимы.
Рассмотрим приложение, которое отправляет средства в другой контракт, предоставляя фиксированную надбавку газа. Принимающему контракту может потребоваться больше газа по новому графику для обращения к хранилищу. Если надбавка вызывающей стороны встроена в развёрнутый код, простое повышение лимита транзакции верхнего уровня может не дать принимающему вызову больше пространства. Тогда сбой может потребовать исправления на уровне контракта или другого маршрута для пользователей. Напротив, если единственная проблема заключается в том, что кошелёк оценил транзакцию по старым ценам, обновлённая оценка и более высокий предоставляемый лимит могут оказаться достаточными. Эти два случая операционно различны.
Особенно необычная проблема EIP-8037 связана с кодом, который измеряет работу путём вычитания двух показаний оставшегося газа. Предложение объясняет, что резервуар state-gas может заставить gasleft() расти при некоторых обстоятельствах. Расчёт, ожидающий неотрицательного уменьшения, может вести себя иначе, а неизменяемые развёрнутые контракты невозможно исправить на месте. Точное влияние зависит от кода и пути транзакции, поэтому воспроизведение реальных исторических транзакций важнее, чем общее предупреждение о более высоких комиссиях.
Инструмент поиска Фонда позволяет разработчикам изучать затронутые адреса контрактов и причину отмеченного расхождения. Он рекомендует тестировать в devnet с использованием нового графика и проверять код, который предполагает фиксированные лимиты, даже если контракт не appears в списке. Историческое воспроизведение — это скрининг, а не полная инвентаризация будущего поведения: маршрут, который ни один пользователь не вызывал в течение выборки, всё ещё может содержать уязвимое допущение. Командам нужны собственные тесты для ветвей, которые они эксплуатируют.
Результат воспроизведения также зависит от выборки транзакций. Контракт может содержать фиксированную надбавку газа в функции, которая вызывалась редко; если этот маршрут отсутствует в воспроизведённой истории, инструмент не может продемонстрировать его сбой. Фонд советует сопровождающим проверять код, даже если его адрес не указан в списке затронутых. Крупное приложение может иметь несколько контрактов, обновляемые фронтенды и автоматизированных агентов, каждый из которых предоставляет различный лимит газа. Команде необходимо тестировать операцию так, как её фактически вызывают пользователи, включая кошелёк или бота, который может хранить старую оценку в кэше.
Для контракта, поведение которого меняется, исправления интерфейса, отправляющего транзакции, не всегда достаточно. Если надбавка газа внутреннего вызова была скомпилирована в неизменяемый код, его владельцу может потребоваться миграция на новый контракт. Такая миграция может включать перемещение балансов, одобрений или разрешений пользователей, а также информирование о новом адресе. Сложность зависит от дизайна продукта; нет доказательств того, что каждый отмеченный контракт требует такой работы. Именно поэтому различие между сбоем, исправимым лимитом, и потенциально сломанным контрактом важно как для команды, так и для её клиентов.
Руководство по тестированию особенно актуально для приложений, которые используют абстракцию аккаунта или множественные вызовы контрактов для завершения одного действия пользователя. Оформление заказа может одобрить актив, направить своп и рассчитаться с продавцом в одной последовательности. Если внутренний шаг использует жёстко заданную надбавку, клиент может увидеть неудачный платёж, не зная, какой контракт достиг лимита. Воспроизведение всей последовательности по предлагаемым правилам более информативно, чем проверка публичного метода каждого контракта по отдельности. Сопровождающим следует фиксировать первый неудачный шаг и то, действительно ли больший внешний лимит газа меняет результат.
Контракты также могут вести себя иначе после неудачного вызова, а не просто останавливаться. Резервная функция, которая регистрирует событие, зачисляет внутренний баланс или пытается использовать второй маршрут, может продолжить работу в условиях, которых её изначальные авторы никогда не ожидали. Именно из-за такого расхождения результат теста, описанный только как «транзакция успешна», может быть недостаточным. Выходное состояние и события необходимо сравнивать со старым выполнением. Категория Фонда «успешное выполнение с изменениями» отражает эту возможность, не объявляя её автоматически вредной.
Кошельки, RPC и фабрики сталкиваются с разными задачами
Кошельки и провайдеры удалённых вызовов процедур оценивают газ, необходимый транзакции, до того, как пользователь подпишет её. EIP-8037 утверждает, что eth_estimateGas и программное обеспечение узлов должны учитывать как газ выполнения, так и новое измерение газа состояния. Старая кэшированная константа может недооценить транзакцию с высокой нагрузкой на состояние. Пользователи могут затем увидеть неудачные транзакции, даже если контракт работал бы с правильно оценённым лимитом. Обновления инфраструктуры, таким образом, являются частью совместимости, а не просто удобством, надстроенным над протоколом.
Детерминированные фабрики развёртывания представляют собой ещё один узкий случай. EIP-8037 обсуждает фабрики, изначально размещённые по стандартным адресам с использованием предварительно подписанных транзакций с жёстко заданными лимитами газа. В новой сети, которая принимает новый график до существования фабрики, старое предварительно подписанное развёртывание может исчерпать газ. Предложение явно указывает, что уже развёрнутые экземпляры в существующей основной сети и сетях второго уровня не затронуты этим конкретным сценарием генезиса. Сообщение об этой оговорке важно: было бы вводить в заблуждение утверждать, что каждая фабрика, уже используемая в Ethereum, вот-вот исчезнет.
Разработчикам также необходимо отличать неизменный контракт от неизменных затрат. Транзакция может быть успешной, но потреблять иное количество газа. Бизнес, который пакетирует развёртывания или создаёт множество слотов хранения, может столкнуться с существенно иной структурой затрат, даже если ни одна функция не завершается ошибкой. Его продукту могут потребоваться иные расценки на комиссии, пересмотренная политика субсидирования или изменение способа хранения информации. Категории воспроизведения Фонда разделяют идентичное выполнение, изменённое, но успешное выполнение, сбои, устранимые лимитом, и потенциально сломанные контракты именно по этой причине.
Цифры в EIP-8037 заслуживают ещё одной оговорки. В его примере предлагаемый газ конвертируется в ETH с использованием предполагаемой базовой комиссии 0,08 gwei. Если базовая комиссия изменится, то и ETH, уплачиваемый за тот же газ, тоже изменится. Разработчик, сравнивающий таблицу с существующим счётом, должен добавить расходы на выполнение и фактические условия транзакции, а не представлять семикратное изменение стоимости состояния как семикратное увеличение полной оплаты пользователя. Цель предложения — назначить затраты ресурсам; окончательная комиссия человека зависит от сочетания этих ресурсов в транзакции.
Масштаб предлагаемого пересмотра цен следует читать вместе с целью по пропускной способности. Больше места для транзакций в блоке может сделать сеть дорогой для валидации, если эти транзакции непропорционально создают постоянное состояние. EIP-8037 выделяет отдельный счётчик для этого роста, чтобы стоимость не исчезала внутри большего заявленного лимита газа. EIP-8038 касается доступа к существующему состоянию. Они решают разные части вопроса о ресурсах, и один работающий сборщик блоков не может установить, что приложения правильно обрабатывают пересмотр цен.
Списки доступа к блокам в Ethereum имеют отдельную задачу. Они сообщают клиентам, к каким счетам и местам хранения обращается блок, помогая организовать часть работы по валидации параллельно. Это может позволить большую пропускную способность при благоприятных условиях, но не устраняет постоянное хранилище, добавляемое новыми счетами и слотами. Тестовой сети необходимо запустить комбинированное обновление в условиях реалистичной активности, потому что улучшение в одном измерении может выявить ограничение в другом. Отсрочка оставляет это комбинированное упражнение в Hoodi невыполненным на данный момент.
Многие пользователи впервые столкнутся с этими изменениями косвенно, через указанный кошельком лимит газа или оценку комиссии приложением. Транзакция, которая не создаёт нового состояния, может иметь иной эффект, чем транзакция, развёртывающая значительный контракт. Торговый интерфейс, который обещает фиксированную стоимость транзакции, должен проверить, покрывает ли его обещание по-прежнему выполняемые им операции. Обобщения о том, что все комиссии Ethereum движутся в одном направлении, были бы преждевременными без окончательного графика основной сети, наблюдаемого спроса и окончательных параметров.
Цифра в 200 миллионов была настройкой тестовой сети
Glamsterdam объединяет не только пересмотр цен. Закреплённое разделение предлагающего и строителя блоков меняет передачу полезной нагрузки блока, в то время как списки доступа на уровне блока помогают клиентам определить счета и хранилище, к которым будет обращаться блок. Разработчики планировали протестировать эти изменения с лимитом газа Hoodi в 200 миллионов, соответствующим Sepolia. Эта цифра была параметром тестовой сети. Она никогда не была обещанием, что основная сеть Ethereum немедленно примет тот же лимит или что пользовательские комиссии упадут на определённый процент.
Удаление графика лимита газа Hoodi сохраняет компоненты отложенного форка вместе. Операторы не будут тестировать предполагаемую повышенную пропускную способность в рамках Glamsterdam в этой сети в следующий понедельник. Разработчики по-прежнему могут использовать Sepolia и специально созданные devnet для исследования эффектов пересмотра цен. Пропущенная репетиция на Hoodi влияет на последовательность, в которой команды клиентов могут обрести уверенность перед выбором времени для основной сети, но Фонд не опубликовал пересмотренный график производства.
Экономика здесь менее прямолинейна, чем лозунг о более дешёвом газе. Взимание более высокой платы за создание долговременного состояния может сделать конкретную транзакцию более дорогой при той же цене газа. Большая безопасная пропускная способность, если она будет позже принята и использована, могла бы облегчить перегрузку в других условиях. Спрос определяет, сколько места в блоке пользователи готовы оплачивать, а окончательные настройки протокола определяют, какие операции становятся дороже или дешевле. Ни пауза, ни успешный тест сами по себе не решат эти рыночные переменные.
Публичная координация имеет издержки, но продолжение при известной неопределённости может иметь большие. Операторы подготовили программное обеспечение для старой эпохи и теперь должны удалить этот график; разработчики приложений должны продолжать тестирование против предложения, окончательная форма которого может измениться. Цена этого сброса очевидна. Правило основной сети, которое привело бы к сбою широко используемого контракта, было бы труднее отменить, а последствия могли бы затронуть средства или зависимые приложения. Уведомление от 22 октября не количественно оценивает такой риск, но ясно показывает, что разработчики сочли взаимодействие достаточно важным, чтобы остановить репетицию на Hoodi.
Пересмотренное предложение могло бы сохранить цель взимания платы за состояние, изменив способ работы газового резервуара или правила перехода для существующих контрактов. Вместо этого оно могло бы сохранить спецификацию и потребовать целевых исправлений приложений. Никакого публичного решения между этими путями в уведомлении об отсрочке не появляется. Читателям следует воздержаться от трактовки исследования как окончательного выбора дизайна. Точные поправки, если они будут, будут важнее, чем то, сколько дней ждёт Hoodi.
Почему разработчики решили подождать
Процесс Ethereum позволяет командам клиентов скорректировать план до активации в публичной тестовой сети. Решение от 22 октября на звонке All Core Devs Execution 248 следует за более ранними предупреждениями и обращением к затронутым разработчикам. Публичное уведомление определяет область исследования, но не публикует окончательное количество контрактов под угрозой, новую версию EIP-8037 или дату окончания расследования. Называть задержку подтверждённым дефектом во всех развёрнутых контрактах означало бы выйти за рамки релиза; называть её рутинной перестановкой календаря означало бы упустить указанную причину.
Старая конфигурация должна быть отозвана на обоих уровнях. Клиенты исполнения обрабатывают транзакции и состояние, тогда как консенсусные клиенты координируют валидаторов и график форка. Сеть может тестировать обновление только в том случае, если эти клиенты согласны насчёт правил и сроков. Операторы Hoodi, установившие релизы специально для 26 октября, должны искать пересмотренные примечания к выпуску. Фонд заявляет, что будет добавлять ссылки на новые версии клиентов по мере их подтверждения, вместо того чтобы считать свою первоначальную таблицу совместимости актуальной.
Есть также урок в порядке доказательств. Воспроизведение истории выявило небольшую затронутую группу; публичные тестовые сети выявляют поведение клиентов и приложений в живой среде; основная сеть подвергает окончательные правила экономическому использованию в масштабе. Каждый этап отвечает на что-то, на что не может ответить предыдущий. Короткая задержка на Hoodi может выиграть время для работы над контрактами, но сама по себе не доказывает, что окончательные правила безопасны. Решение о продолжении должно следовать за результатами тестов и чёткими инструкциями для операторов.
Стоит уточнить объём уведомления для операторов. Обычному держателю в основной сети не нужно менять кошелёк из-за того, что график Hoodi был отозван. Оператору узла Hoodi, который готовился к форку, действительно нужно пересмотреть примечания к выпуску. Инженеру протокола, исследующему EIP, нужно определить, является ли поведение контракта, обнаруженное при воспроизведении, приемлемым, исправимым с помощью инструментов или причиной для изменения предложения. Команде приложения нужно протестировать свои собственные маршруты исполнения. Это разные аудитории с разными сроками, и одно оповещение «обновление отложено» не даёт каждой из них правильной инструкции.
Следующий пост Фонда также может определить, как разработчики будут общаться с затронутыми командами. В его августовском руководстве говорилось, что прямое обращение уже началось, но одного количества обращений было бы недостаточно, чтобы установить, что контракт исправлен. Проверяемым доказательством является обновлённый контракт, пересмотренная конфигурация газа или документированный запасной вариант для конкретного продукта. Некоторые неизменяемые контракты могут потребовать миграции пользователей, что поднимает отдельную проблему коммуникации и безопасности: клиенты должны знать, где находится легитимная замена, и избегать мошеннических адресов. Массовая миграция не объявлена, поэтому это остаётся contingency для команд, чей код не может быть изменён на месте.
Что предшествует другой дате
Пересмотренный график должен указывать, какие правила EIP-8037 будут протестированы, что изменилось, если предложение будет изменено, и какие версии клиентов согласны относительно новой эпохи Hoodi. Сопровождающим приложений нужно время, чтобы выполнить поиск затронутых контрактов, обновить оценщики, поднять лимиты там, где этого достаточно, и изучить жестко закодированные внутренние разрешения на вызовы там, где этого недостаточно. Если потенциально сломанный развернутый контракт не имеет прямого пути обновления, его команде может потребоваться объяснить, как пользователи смогут получить доступ к замене до любого форка основной сети.
Публичные доказательства должны включать методологию воспроизведения и обновленные результаты по затронутым контрактам, результаты devnet с окончательным графиком газа, активацию Hoodi с согласием разнообразных клиентов и отдельное объявление для основной сети. Даже чистая активация Hoodi будет репетицией, а не гарантией конкретной цены ETH или окончательной комиссии за транзакцию. Практическая история для пользователей заключается в том, что никаких действий в основной сети 26 октября объявлено не было. Непосредственные действия принадлежат операторам Hoodi и командам, чьи приложения делают предположения о газе.
На что обратить внимание
- Релизы клиентов: Обновления исполнения и консенсуса, которые явно удаляют старую активацию Hoodi 26 октября.
- Результаты EIP-8037: Новые результаты повторного воспроизведения, изменения в предлагаемых правилах газа и обработка контрактов с жёстко заданными лимитами или логикой gasleft().
- Замена эпохи: Датированный план Hoodi, который восстанавливает тестируемую конфигурацию после расследования.
- Исправления приложений: Отчёты затронутых разработчиков, объясняющие, достаточно ли более высоких лимитов или развёрнутому коду нужен другой путь.
- Уведомление о мейннете: Отдельный производственный график от Фонда после последовательности тестнета и координации клиентов.
Часто задаваемые вопросы
Активируется ли Glamsterdam в Hoodi 26 октября?
Нет. Ethereum Foundation отложил активацию 26 октября и не установил заменяющую эпоху или время.
Изменился ли мейннет Ethereum 22 октября?
Нет. Уведомление изменяет будущий график тестнета Hoodi. Оно не отменяет существующую историю Hoodi и не активирует Glamsterdam в мейннете.
Почему тест был отложен?
По данным Фонда, основным разработчикам нужно больше времени для изучения взаимодействия EIP-8037 с существующими смарт-контрактами мейннета.
Что такое EIP-8037?
Он повышает и отдельно учитывает газ, взимаемый за создание постоянного состояния, включая аккаунты, слоты хранения и развёрнутый код. Его точное влияние на комиссии зависит от транзакции и цены газа.
Нужно ли менять каждый смарт-контракт?
Нет. Фонд утверждает, что подавляющее большинство в его историческом воспроизведении не было затронуто. Небольшой набор с фиксированными допущениями о газе заслуживает прямого тестирования и, в некоторых случаях, исправления.
Вырастет ли лимит газа Hoodi до 200 миллионов 26 октября?
Нет. Запланированное увеличение было удалено вместе с обеими частями активации Glamsterdam в Hoodi.
Что должен сделать оператор валидатора Hoodi?
Проверить обновлённые инструкции для клиентов исполнения, консенсуса и валидатора. Старое программное обеспечение или пользовательские конфигурации могут по-прежнему содержать отменённое время активации.
Есть ли новая дата для мейннета?
Нет. После тестирования и согласования графика командами клиентов потребуется отдельное производственное объявление.






