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

Мемпулы и пулы транзакций

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

Обновлено

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

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

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

В клиенте исполнения Ethereum исполнимая транзакция со следующим nonce счета обычно называется pending, а более поздний nonce, заблокированный разрывом, — queued. Это метки клиентского интерфейса, а не окончательные состояния протокола. Транзакция может быть отклонена до приема, распространена, заменена другой подписанной транзакцией того же отправителя с тем же nonce, вытеснена, отброшена, успешно включена, включена с откатом исполнения либо вновь рассмотрена после реорганизации.

1
Создавать

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

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

  1. Зафиксируйте среду: идентификатор цепи, клиент исполнения и версию, текущую вершину и базовую комиссию, тип транзакции, отправителя, nonce, сумму, calldata, лимит газа, пределы комиссий и маршрут отправки. Различайте публичный gossip, приватный ретранслятор или построитель и маршрут ERC-4337 UserOperation: общего универсального пула у них нет.
  2. Декодируйте подписанные байты и выполните проверки до приема. Проверьте подпись и отправителя, chain ID, тип и кодировку, intrinsic gas, соотношение nonce, достаточность баланса для суммы и максимальной комиссии, поля комиссий и необходимый blob sidecar. Такой отказ — не EVM REVERT; обычно он не создает квитанцию и комиссию в цепочке.
  3. Опишите локальную политику пула. Запишите классификацию pending или queued, емкость на счет и общую емкость, минимальные фильтры комиссий, срок хранения, исключения для локальных счетов, шаг замены и сохранение на диске. Флаги и значения по умолчанию Geth описывают Geth, а не консенсус Ethereum и не каждого провайдера.
  4. Наблюдайте распространение, не выдумывая глобального представления. Сверяйте хеш и подписанные байты на независимых узлах, но отсутствие неоднозначно: узел мог не получить транзакцию, отклонить ее своей политикой, вытеснить или не публиковать содержимое пула. Приватный маршрут может обходить публичный gossip, раскрывая транзакцию своим операторам и построителям.
  5. Моделируйте допустимость и порядок в конкретном блоке-кандидате. Для транзакции типа 2 цена газа исполнения равна min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas); если базовая комиссия превышает максимальную, транзакция не подходит под заданный предел. Зависимости nonce, лимиты газа и blob, валидность состояния, пакеты построителя и MEV могут быть важнее времени первого обнаружения.
  6. Управляйте жизненным циклом осознанно. Ждите либо отправляйте документированную замену с тем же nonce лишь после проверки активной цепи, отправителя и политики замены. Самоперевод с тем же nonce — еще один кандидат на замену, а не примитив отмены. Не повторяйте перевод ценности лишь потому, что один обозреватель перестал показывать исходную транзакцию.
  7. Сверяйте результат с состоянием консенсуса. Сохраните каждый подписанный хеш и цепочку замен, затем проверьте каноническую квитанцию, хеш блока, статус, использованный газ, журналы, израсходованный nonce и состояние счета или контракта на требуемом уровне подтверждения или финальности. Если реорганизация удалит блок, все еще валидная транзакция может вернуться в некоторые локальные пулы, но это зависит от клиента и состояния.

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

  • Допустимость по пределу комиссии. Перевод типа 2 имеет gasUsed = 21,000, baseFeePerGas = 32 gwei, maxPriorityFeePerGas = 3 gwei и maxFeePerGas = 34 gwei. Эффективная цена равна min(34, 32 + 3) = 34 gwei, поэтому фактические чаевые — 2 gwei. Комиссия составляет 21,000 * 34 = 714,000 gwei = 0.000714 ETH: сжигается 0.000672 ETH базовой комиссии и выплачивается 0.000042 ETH чаевых. Если базовая комиссия блока-кандидата вырастет до 35 gwei, предела 34 gwei для него недостаточно.
  • Разрыв nonce. Канонический nonce счета равен 10. Локальный пул получает транзакции с nonce 10 и 12, но без 11; он может пометить 10 как pending, а 12 как queued. После включения nonce 10 канонический nonce становится 11, и 12 остается заблокированным до включения валидной транзакции с nonce 11. Наличие nonce 12 в пуле не делает его независимо исполнимым.
  • Замена по конкретной политике. В учебной конфигурации Geth с txpool.pricebump = 10 старая транзакция имеет maxFeePerGas = 40 gwei и maxPriorityFeePerGas = 2 gwei. Рассчитанные пороги повышения на 10% равны 44 gwei и 2.2 gwei. Предложение с 43 gwei и 3 gwei все еще может быть отклонено, поскольку один предел не достиг порога; значения 44 gwei и 2.2 gwei достигают обоих учебных порогов. Точное целочисленное округление, тип транзакции и логика приема зависят от версии; другой узел может оставить иного кандидата.
  • Глобального пула нет. Узел A сообщает 120,000 разных хешей, узел B — 100,000, пересечение равно 80,000. Объединение равно 120,000 + 100,000 - 80,000 = 140,000; коэффициент Жаккара — 80,000 / 140,000 = 57.1428571429%. Только A видит 40,000 хешей, только B — 20,000. Ни одно число не доказывает, что видит построитель, приватный ретранслятор или остальная сеть.

Риски

  • Подпись или публикация в неверной сети либо с неверным chain ID.
  • Доверие вредоносному, устаревшему или неправильно настроенному RPC.
  • Неверная подпись, тип, кодировка или blob sidecar.
  • Недостаточный баланс для суммы и максимальной комиссии.
  • Отказ до приема из-за intrinsic gas или правил calldata.
  • Уже использованный или слишком низкий nonce.
  • Разрыв nonce оставляет последующие транзакции queued.
  • Замена с тем же nonce отклоняется локальной политикой как недооцененная.
  • Максимальная комиссия ниже базовой комиссии блока-кандидата.
  • Низкий эффективный приоритет или ограничения ресурсов задерживают включение.
  • Несовпадение политики клиента, провайдера, версии или конфигурации.
  • Емкость, истечение срока, перезапуск или вытеснение удаляет транзакцию.
  • Плохое распространение, eclipse-атака или выборочное поведение ретранслятора.
  • Утечка, цензура, сбой приватного ретранслятора или неучастие построителя.
  • Фронтраннинг, sandwich или иной MEV публичного потока заявок.
  • Изменение состояния из-за порядка построителя, пакетов или приватных транзакций.
  • Симуляция устаревает до включения.
  • Слепая повторная отправка или потеря цепочки замен.
  • Включенный REVERT, исчерпание газа или перехваченный сбой подвызова после приема пулом.
  • Реорганизация, путаница с финальностью или смешение альтернативного мемпула ERC-4337 с обычным txpool.

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

  • Мемпул — единая глобально синхронизированная очередь FIFO.
  • Хеш транзакции доказывает, что сеть приняла или распространила транзакцию.
  • Pending означает включение, успех, необратимость или получение платежа.
  • Достаточно высокая комиссия гарантирует включение и успешное исполнение.
  • Приватный маршрут автоматически конфиденциален, устойчив к цензуре и гарантирует включение.

Похожие темы

Источники

Навигация

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