Ethereum приостановил форк Hoodi в рамках Glamsterdam: что выявили аудиторы?

Разработчики Ethereum приостановили форк тестовой сети Hoodi для Glamsterdam, пока они разбираются с выводами о том, как ведут себя приложения, когда транзакции не хватает газа. Обновление меняет способ, которым сеть взимает плату за некоторые операции, затрагивающие или расширяющие её состояние, и аудиторы обнаружили, что даже контракты, написанные до обновления, могут вести себя иначе в соответствии с предлагаемыми правилами.

Разработчики Ethereum должны были форкнуть Hoodi 26 октября. Они отложили этот тест, и 6 ноября разработчик Ethereum Foundation Мариус ван дер Вейден сообщил, что он остаётся на паузе, пока разработчики разбираются с проблемами, выявленными в ходе проверки газа.

Проблема сосредоточена на детали, с которой большинство людей сталкиваются только тогда, когда транзакция завершается неудачей. Контракты могут вызывать другие контракты и решать, что делать, если эти вызовы возвращаются безуспешно. Код, принимающий это решение, может выглядеть точно так же после обновления, но пойти по другому пути, потому что сеть теперь взимает плату за части операции иначе.

Вот почему обновление, направленное на то, как Ethereum учитывает состояние, стало вопросом для разработчиков приложений, а также для команд, которые пишут клиенты Ethereum. Обеим сторонам нужно знать, какие старые предположения переживут изменение.

Что Glamsterdam меняет в газе

EIP-8037 меняет то, как протокол учитывает операции, создающие состояние. Состояние Ethereum включает записи, такие как хранилище контрактов. Изменение может сохраняться между транзакциями, поэтому его стоимость имеет последствия для узлов, поддерживающих цепочку после завершения исходной транзакции. Предложение отделяет учёт некоторых операций создания состояния от обычного газа выполнения, с резервуаром, который можно использовать для подходящих операций.

EIP-8038 переоценивает операции, обращающиеся к состоянию. Два предложения влияют на разные части пути выполнения. Контракт может прочитать значение, совершить внешний вызов и записать результат. Проверка только предлагаемой цены финальной записи упускает влияние более ранних чтений и вызовов на бюджет, доступный при достижении выполнения этой записи.

Знакомое приложение, таким образом, может дать иной результат, даже когда пользователь предоставляет те же входные данные транзакции. Важный вопрос заключается в том, какие различия отражают предполагаемое переоценивание, а какие выявляют предположение, на которое полагается клиент или контракт.

Как неудачный вызов может изменить конечный результат

Рассмотрим контракт, который вызывает второй контракт для выполнения одного шага в более крупной операции. Если второй контракт завершается неудачей, вызывающий контракт может остановить всё или обработать сбой и продолжить. Пакетный обработчик может записать неуспешный элемент и продолжить работу. Другое приложение может ожидать, что вся операция будет отменена, если неудачный вызов израсходует достаточно газа.

Анализ ChainSecurity описывает, как новый учёт может повлиять на это различие. Ethereum уже ограничивает объём газа, который вызывающий может передать вперёд в соответствии с правилом EIP-150. В соответствующем случае у вызывающего может остаться примерно одна шестьдесят четвёртая. Проблема в том, сколько у вызывающего фактически остаётся в наличии после возврата выполнения и сколько стоит завершение инструкций на этом пути.

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

Аудитор также изучил проверки на основе gasleft(). Контракт может использовать эту инструкцию для сравнения своего оставшегося бюджета выполнения с жёстко заданным минимумом. Порог, откалиброванный при одном расписании, может стать плохим предиктором при другом, особенно когда контракт сталкивается с операциями состояния или пересылает газ на другой адрес. У контракта нет автоматического способа пересмотреть число, которое разработчик встроил при его развёртывании.

Что должны установить аудиторы

Ноябрьское обновление Фонда описывает восемь предположений, находящихся на рассмотрении. Для тестирования есть как минимум два различных вопроса. Клиенты, реализующие новые правила, должны приходить к одинаковому результату для данной транзакции. Проверяющие приложения также должны выявлять случаи, когда этот общий результат отличается от того, что ожидают существующие контракты.

Тест для первого вопроса может выполнить одну и ту же транзакцию на нескольких клиентах и сравнить результаты состояния и газа. Тест для второго должен следовать собственной логике приложения. Важно, рассматривает ли контракт неудачный обратный вызов как сигнал к продолжению, записывает ли он изменение состояния перед вызовом и может ли он отличить бизнес-отказ от вызова, у которого никогда не было достаточно газа.

Эти пути могут быть легко упущены в обычном тесте развёртывания. Типичный бюджет транзакции может провести вызов и его обработчик через оба расписания. Намеренно жёсткий бюджет может выявить разницу. Поэтому граничные тесты должны включать неудачные вызовы и случаи, близкие к объёму газа, необходимому для входа в обработчик сбоя или его завершения.

Что может показать Hoodi

Glamsterdam уже достиг тестовой сети Ethereum Sepolia, где разработчики протестировали лимит газа в 200 миллионов. Hoodi предоставил бы разработчикам ещё одно общее развёртывание для проверки пересмотренного обновления.

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

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

Работа над газом идёт параллельно с другими исправлениями. Разработчики Ethereum отдельно пересмотрели спецификацию депозита валидатора, пока шёл обзор газа Hoodi. Эти исправления нуждаются в собственных тестах, поскольку они затрагивают другую часть форка.

На данный момент последнее обновление для разработчиков о газовых рисках объясняет причину задержки и сообщает, что работа над Hegota продолжается. Оно оставляет сроки следующего теста Glamsterdam на последующее решение.

Как соотносятся лимиты газа и затраты на состояние

Более высокий лимит газа блока даёт Ethereum больше пространства для работы в рамках его системы учёта. Цена, назначенная отдельной операции, определяет, какую часть этого пространства операция занимает. Поэтому изменение лимита и изменение цен могут затрагивать разные части одной и той же транзакции.

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

EIP-8037 меняет способ учёта стоимости создания определённого состояния. EIP-8038 переоценивает доступ к состоянию, что может включать операции с уже существующими записями. Транзакция, которая читает значение, вызывает другой контракт и создаёт запись в хранилище, может столкнуться с обоими изменениями в ходе одного выполнения.

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

Это различие было актуально уже тогда, когда Sepolia начала тестировать Glamsterdam с лимитом газа в 200 миллионов. Тест показал, что разработчики запускали в этой сети. Приостановка на Hoodi касается того, готовы ли правила для следующей тестовой сети, включая поведение приложений, которые полагаются на более ранние допущения о газе.

Восемь допущений на рассмотрении

Репозиторий аудитора Фонда Ethereum группирует свои примеры по изменениям цен операций и изменениям способа отслеживания газа. Числа в репозитории взяты из зафиксированной версии предлагаемой спецификации и могут измениться, если предложения будут пересмотрены.

Первая группа проблем касается фиксированных лимитов и стоимости завершения работы после вызова. Разработчики могли установить лимит газа для операции, которая теперь стоит дороже. Резерв, предназначенный для оплаты финальной записи, может оказаться недостаточным. В другом случае небольшая доля, сохраняемая вызывающей стороной, может оказаться достаточной для завершения пути отказа, который приложение ранее ожидало откатить.

Изменения в учёте вводят другие возможности. Если отдельный резервуар всё ещё может финансировать допустимое создание состояния, вызывающая сторона может записать запись после неудачного вызова, даже когда её обычный бюджет выполнения ограничен. Итоговый результат вызывающей стороны тогда может зависеть от того, какие операции используют этот отдельный бюджет.

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

Пара измерений gasleft() также может дать неполное представление о стоимости работы. Контракт, который использует разницу для выставления счёта кому-либо или расчёта возврата, полагается на допущения о том, как газ меняется между двумя измерениями. Списания, взятые из отдельного пула, и газ состояния, возвращённый во время выполнения, могут изменить это соотношение.

Восьмой случай касается EIP-7702, который позволяет аккаунту авторизовать делегирование коду контракта. Транзакция может быть включена, даже если содержащаяся в ней авторизация не вступила в силу из-за нехватки газа. Кошелёк или сервис, который использует сам факт включения транзакции, чтобы сделать вывод о том, что делегирование сработало, может принять незавершённое действие за выполненное.

В репозитории говорится, что многие находки, полученные его авторами, касались фиксированных сумм или резервов. Он просит разработчиков и аудиторов проверить свои приложения на примерах и сообщать о проблемах. Перечень определяет шаблоны, требующие проверки. Он не подразумевает, что каждое приложение, использующее один из этих шаблонов, понесёт убытки.

Как неудачный вызов всё равно может оставить успешную транзакцию

Транзакция Ethereum может содержать несколько вызовов. Контракт может запросить у другого контракта выполнение шага, а затем решить, как реагировать на результат. Неудачный внутренний вызов и неудачная транзакция — это разные исходы.

Пакетный обработчик даёт полезный пример. Если один элемент завершается неудачей, обработчик может зафиксировать эту неудачу и перейти к следующему элементу. Если у него закончится газ до того, как он сможет зафиксировать результат, внешняя транзакция может откатиться и отменить более ранние изменения. Таким образом, одна и та же внутренняя неудача оставляет различное конечное состояние в зависимости от того, что вызывающий может сделать после неё.

Другое приложение может рассматривать неудачный вызов как причину изменить, кто может отправить запрос или разрешена ли повторная попытка. Если вызывающий может завершить путь, который приложение рассчитывало откатить, результирующее состояние может сохраниться. Последствия для безопасности зависят от того, что фактически фиксирует завершённый путь.

Участник может иметь возможность выбирать, сколько газа предоставляет транзакция. Если этот человек может оставить достаточно газа для того, чтобы внешний контракт вошёл в путь, но слишком мало для завершения внутреннего вызова, неудачу можно вызвать за счёт бюджета транзакции. Контракт, который действует на основе неудачи, должен отличать этот случай от вызова, который достиг вызываемого контракта и по-настоящему завершился неудачей.

Ограничение пересылки EIP-150 — одна из частей этого. Вызывающий, который пересылает столько газа, сколько разрешено, сохраняет примерно одну шестьдесят четвёртую в соответствии с применимым правилом. Сохранённая сумма всё ещё должна оплачивать инструкции, которые следуют далее. Завершатся ли эти инструкции, зависит от расписания и учёта, применяемого к ним.

Контракт может быть уязвим в узком диапазоне бюджетов. Дайте внутреннему вызову достаточно газа, и он работает нормально. Дайте всей транзакции слишком мало, и внешний путь откатится. Проблемный интервал — это когда внутренний вызов завершается неудачей, а у вызывающего всё ещё достаточно средств, чтобы выполнить действие, которое разработчик не предусматривал для этой неудачи.

Почему изменение фиксированного числа газа может не решить проблему

Жёстко заданный порог может дать контракту простой способ проверить, что у него достаточно газа перед выполнением вызова. Разработчик мог протестировать порог на обычных транзакциях и оставить запас для последующей работы. Число становится зависимостью от расписания, при котором оно было выбрано.

Операция также может стоить разных сумм в зависимости от того, обновляет ли приложение существующую запись или создаёт новую. Перевод кому-то, у кого уже есть баланс, может столкнуться с иным путём хранения, чем перевод, создающий первый баланс. Тест, который охватывает только повторных получателей, может упустить более дорогой путь.

Точка, в которой контракт измеряет газ, имеет значение. Показание непосредственно перед вызовом отличается от показания после нескольких обращений к состоянию и самого вызова. Контракт, который выводит причину неудачи из последнего показания, предполагает, что он понимает, что могло быть списано или возвращено в промежутке.

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

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

Что должно показать убедительное воспроизведение

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

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

Затем проверяющий должен спросить, кто может достичь этого пути. Изменение, воспроизведённое в тестовом контракте, устанавливает различие в исполнении. Реальное приложение может требовать авторизации, проверять отдельное условие или делать затронутую операцию повторяемой. Эти детали определяют, может ли кто-то вызвать нежелательный исход.

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

Набор тестов нуждается как в успешных путях, так и в неудачных. Принудительный откат каждого неудачного вызова может предотвратить одно нежелательное изменение состояния, но также лишить законной возможности завершить остальную часть пакета. Предполагаемое поведение приложения определяет, что должен сохранить исправление.

Хорошее воспроизведение должно делать конечное состояние легко проверяемым. Если запись о сбое остаётся после одного запуска и исчезает после другого, тест может показать точное различие, а не полагаться на общий отчёт об использовании газа. Это облегчает оценку как риска, так и предлагаемого изменения.

Что добавляют публичные тестовые сети после локального воспроизведения

Разработчик может протестировать граничный случай на локальном форке или в контролируемой клиентской среде. Публичная тестовая сеть затем позволяет нескольким операторам запустить одно и то же обновление и сравнить его поведение в общих условиях. Она также даёт командам кошельков и инфраструктуры место для тестирования своего программного обеспечения против действующих правил.

Sepolia и Hoodi служат разным этапам этого процесса. Активация в Sepolia показала, что разработчики могут запустить запланированный код в этой сети и изучить его работу при настроенном лимите газа. Hoodi даёт им дальнейшее развёртывание после устранения находок, которые стали важными в ходе проверки.

Приложения, трафик и историческое состояние в тестовой сети отличаются от основной сети. Гладкий форк может дать свидетельства о согласии клиентов и рутинных транзакциях, не задействуя каждый шаблон контрактов, на который полагаются пользователи. Целевое воспроизведение даёт свидетельства о граничном случае, который может отсутствовать в обычном трафике тестовой сети.

Инструкции по обновлению — ещё одна часть теста. Оператору нужен релиз, реализующий предполагаемую конфигурацию, и точная точка активации. Приложению нужно знать, когда его симуляции должны начать использовать пересмотренные правила. Новая дата полезна наряду с этими деталями.

Октябрьская отсрочка и ноябрьский отчёт о статусе описывают одну и ту же задержку в разное время. Первая отменила запланированную дату для Hoodi. Второй объяснил, что проблемы всё ещё нужно решить. Следующее уведомление о развёртывании может показать, какие изменения готовы для тестирования операторами.

Как кошельки могут сообщать об успехе, когда действие не выполняется

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

Транзакция, которая откатывается, всё равно может стоить отправителю газа. Внешняя транзакция, которая завершается после перехвата внутренней ошибки, может быть сложнее для интерпретации. Цепочка может записать общую транзакцию как успешную, хотя действие внутри неё не произошло. Кошельку могут понадобиться события или состояние приложения, чтобы объяснить пользователю разницу.

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

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

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

Что позволило бы снять задержку Hoodi

Фонд просит команды приложений определить допущения, которые они используют, и предоставить случаи, которые разработчики могут воспроизвести. Некоторые проблемы могут быть решены путём изменений в предлагаемых правилах газа. Другие могут потребовать от приложения или поставщика инфраструктуры пересмотреть то, как оно обрабатывает новое поведение.

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

Пересмотренная спецификация также должна дойти до клиентских сборок, которые запускают операторы. Сборка, поддерживавшая более раннюю конфигурацию Glamsterdam, может не содержать последующих изменений. Номера релизов в новом уведомлении Hoodi позволили бы определить, какие версии можно тестировать вместе.

Ноябрьское обновление Фонда сообщает, что работа над Hegota продолжается параллельно. Это означает, что приостановка более раннего форка не учитывает все решения по разработке следующего. Для Glamsterdam следующей значимой вехой является пересмотренный график Hoodi с конфигурацией, которую разработчики готовы запустить публично.

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

Что предложенные значения газа показывают о различных путях

Репозиторий Фонда приводит конкретный пример разницы между созданием состояния и его обновлением. Согласно его закреплённой спецификации Glamsterdam, холодная запись, создающая новый слот, разделяется между затратами на выполнение и существенно большей платой за состояние. Запись в существующий слот также переоценивается, но следует другому расчёту.

Разница может затронуть двух пользователей, делающих, по-видимому, один и тот же запрос приложения. Один пользователь мог ранее пользоваться сервисом, поэтому контракт обновляет существующую запись. Другому может потребоваться новая запись. Лимит газа, подходящий для первого пользователя, может не сработать для второго.

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

Код, который читает оставшийся газ, поэтому в некоторых случаях может наблюдать только часть ресурсов транзакции. Данные, которые он читает, по-прежнему значимы для бюджета, который предоставляет инструкция. Меняется вывод, который приложение может сделать об общем объёме потреблённых или оставшихся доступных ресурсов.

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

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

На что обратить внимание

• Расписание Hoodi: Пересмотренная дата форка должна определить версии клиентов и конфигурацию форка, которую операторы должны запускать.
• Согласованность клиентов: Кросс-клиентские тесты могут показать, достигают ли клиенты исполнения одного и того же состояния и результатов по газу вблизи новых границ.
• Поведение контрактов: Воспроизведения должны показать, когда неудачный внешний вызов оставляет вызывающему достаточно газа для завершения и что записывает внешняя транзакция.
• Пересмотр предложений: Изменения в EIP-8037 или EIP-8038 помогут показать, какие результаты проверки потребовали изменения протокола.
• Инструменты приложений: Результаты симуляции и оценки газа могут показать, правильно ли кошельки и инфраструктурные провайдеры отражают правила форка.

Часто задаваемые вопросы