Перейти к содержанию
Financial Context Wiki

Замена транзакций в мемпуле Ethereum

Руководство по зависящей от клиента замене транзакций Ethereum от одного отправителя с одинаковым nonce: повышение лимитов комиссии, гонка отмены, blob-транзакции, частные каналы, квитанции и финальность.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Замена транзакции Ethereum — локальная политика пула транзакций, по которой узел может предпочесть новую подписанную транзакцию другому кандидату от того же отправителя с тем же nonce. Это не глобальный переключатель Replace-by-Fee на уровне консенсуса. Принятие узлом нового хеша не удаляет старую подписанную транзакцию из других узлов, частных ретрансляторов или входных данных сборщиков блоков. Только включение в каноническую цепь определяет, какой кандидат израсходует nonce счета.

Функция кошелька «Ускорить» обычно сохраняет исходные адрес назначения, сумму и calldata, повышая поля комиссии. Публичная функция «Отменить» обычно создает перевод самому себе с нулевой суммой, тем же отправителем и nonce. Это конкурирующая транзакция, а не откат: если первой включат исходную, ее перевод или вызов контракта не отменится. У частных каналов могут быть собственные API отмены; например, Flashbots Protect описывает аутентификационную отмену, которая не попадает в блокчейн. Ее нельзя обобщать на публичную замену транзакций Ethereum.

Как это работает

  1. Зафиксируйте точную цепочку кандидатов: идентификатор сети, клиент и версию, головной блок и базовую комиссию, канал отправки, отправителя, канонический nonce счета, исходные подписанные байты, хеш и тип транзакции. Сверьте несколько релевантных публичных или частных представлений: метка кошелька и один ответ RPC не являются глобальным состоянием.
  2. Точно классифицируйте исходную транзакцию: отклонена, локально ожидает, стоит в очереди из-за разрыва nonce, удалена или вытеснена, отправлена приватно, включена успешно, включена с status = 0, удалена реорганизацией либо финализирована. После канонического расходования nonce замена уже невозможна, хотя реорганизация может снова открыть гонку.
  3. Определите новый замысел. Ускорение должно воспроизводить все смысловые поля; публичная попытка отмены обычно использует того же отправителя и nonce с to = sender, value = 0 и пустым calldata. Перед подписью сравните идентификатор сети, тип, назначение, сумму, calldata, список доступа, лимит газа, хеши blob и авторизации.
  4. Прочитайте фактическую политику целевого узла. У старых транзакций и типа 1 есть gasPrice; у типа 2 — maxFeePerGas и maxPriorityFeePerGas; у типа 3 также есть maxFeePerBlobGas и обязательные сопутствующие данные. Текущие значения Geth txpool.pricebump = 10 и blobpool.pricebump = 100 — примеры конфигурации Geth, а не общеэфириумные константы.
  5. Отдельно рассчитайте повышение, право на включение и финансирование. Для типа 2 эффективная цена равна min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas). Кандидату все равно нужны корректная кодировка, достаточный внутренний газ и баланс на сумму плюс максимальную комиссию. Высокий лимит не исправляет неверные calldata и не гарантирует успешное исполнение EVM.
  6. Отправляйте осознанно и сохраняйте каждый ответ. Публичная повторная трансляция раскрывает намерение и риск MEV; у частных ретрансляторов свои видимость, отмена, охват сборщиков и доступность. Отслеживайте старые и новые хеши по каждому каналу, не считая, что локальное принятие удалило конкурента, и не отправляйте вслепую третью транзакцию с суммой.
  7. Сверьте победителя с канонической цепью. Проверьте блок и хеш квитанции, индекс транзакции, status, использованный газ, эффективную цену, журналы, nonce отправителя, балансы и состояние контракта на требуемом уровне финальности. Хеши проигравших отмечайте как замененные, удаленные либо еще наблюдаемые только по доказательствам; после реорганизации начинайте анализ заново.

Разобранные примеры

  • Учебное повышение для обычного типа 2. Старый кандидат имеет maxFeePerGas = 40 gwei и maxPriorityFeePerGas = 2 gwei. При учебной конфигурации Geth с повышением 10% арифметические пороги равны 44 gwei и 2.2 gwei. Кандидат 44/2.1 gwei не достигает порога чаевых, а 44/2.2 gwei достигает обоих. При базовой комиссии 32 gwei и расходе газа 21,000 эффективная цена равна 34.2 gwei, комиссия — 718,200 gwei = 0.0007182 ETH, сжигание — 0.000672 ETH, чаевые — 0.0000462 ETH. Реальное принятие зависит от реализации, версии и округления целых wei.
  • Чувствительность к базовой комиссии. Лимиты замены — 66/4.4 gwei. При базе 60 gwei эффективная цена равна min(66, 60 + 4.4) = 64.4 gwei. При базе 65 gwei она равна 66 gwei, а эффективные чаевые — лишь 1 gwei. При базе 67 gwei выполняется 66 < 67, поэтому кандидат непригоден для блока, даже если прошел локальный тест повышения.
  • Гонка отмены. Исходная транзакция с nonce 20 переводит продавцу 5 ETH. Если она выигрывает с комиссией 21,000 * 42 gwei = 0.000882 ETH, продавец получает 5 ETH, а отмена становится транзакцией со слишком низким nonce. Если выигрывает нулевой перевод себе с комиссией 21,000 * 45 gwei = 0.000945 ETH, он расходует nonce 20 и не позволяет исходной транзакции позже войти в ту же каноническую историю. Нажатие кнопки «Отменить» само по себе не определяет исход.
  • Граница blob-пула. Старый кандидат типа 3 имеет лимит комиссии исполнения 100 gwei, лимит чаевых 3 gwei и лимит blob-комиссии 20 gwei. В учебной конфигурации blob-пула Geth с повышением 100% арифметические пороги равны 200/6/40 gwei. Кандидат 200/6/39 gwei не достигает blob-порога; 200/6/40 gwei достигает всех трех, но ему еще нужны корректные сопутствующие данные, nonce, баланс и прием в пул. Эти значения не являются правилами для обычных транзакций или других клиентов.

Риски

  • Неверный идентификатор сети или сеть.
  • Неверный отправитель или nonce счета.
  • Устаревшие головной блок, базовая комиссия или канонический nonce.
  • Попытка замены после включения или финализации исходной транзакции.
  • Применение правил обычного txpool к ERC-4337 UserOperation.
  • Предположение об одинаковой политике у иного клиента, провайдера, версии или конфигурации.
  • Недостижение порога из-за округления целых wei.
  • Повышение лишь одного обязательного поля комиссии EIP-1559.
  • maxFeePerGas ниже базовой комиссии блока-кандидата.
  • Игнорирование blob-лимита, сопутствующих данных или особого правила blob-пула.
  • Недостаточный баланс на сумму и максимальные разрешенные комиссии.
  • Недействительные подпись, тип, кодировка, внутренний газ или домен сети.
  • Случайное изменение назначения, суммы, calldata, списка доступа или blob-хешей.
  • Проигрыш публичной отмены в гонке включения.
  • Сохранение старой транзакции у других узлов или сборщиков.
  • Утечка, цензура, удаление или неудачная отмена частным ретранслятором.
  • Раскрытие намерения публичной трансляцией для фронтраннинга, сэндвича или другого MEV.
  • Блокировка последующих транзакций разрывом nonce или повторный перевод.
  • Включение замены с откатом исполнения либо исчерпанием газа и расходованием nonce и комиссии.
  • Ошибки реорганизации, финальности или цепочки квитанций, возрождающие либо неверно классифицирующие кандидатов.

Распространенные заблуждения

  • Кандидат с большей комиссией глобально удаляет старую транзакцию.
  • Любые транзакции с одинаковым числовым nonce заменяют друг друга, даже от разных отправителей.
  • Кнопка отмены обращает уже включенную транзакцию.
  • Принятие замены одним узлом доказывает ее включение сборщиками.
  • Универсальное повышение 10% подходит каждому клиенту, blob-транзакции, частному ретранслятору и UserOperation.

Похожие темы

Источники

Навигация

Поиск по вики...