Отладка частного пакета: распространенные…

Краткий ответ — Частный пакет, который не попадает в следующий блок, пропустил включение. Промахи при включении бывают двух видов: отклонено ретранслятором (ретранслятор отказался переслать ваш пакет сборщикам) и отклонено сборщиком (ретранслятор переслал его, ни один сборщик его не включил). Первый тип имеет четкую реакцию на ошибку; второй вид молчит. Восемь наиболее распространенных причин, примерно в том порядке, в котором вы должны их проверять: устаревшая модель комиссий, несоответствие подсказок (например, забытый revertingTxHashes), дрейф симуляции между симуляцией и отправкой, проскальзывание целевого блока, задержка ретрансляции, ограничение скорости компоновщика, ошибка кодирования полезной нагрузки и явные пробелы в покрытии компоновщика. Каждый из них имеет отдельную подпись в ваших журналах. Приведенное ниже дерево диагностики подскажет вам, что следует подозревать, основываясь на том, что вы действительно видите, а не на предположениях.

Путь мастерства

• Что такое MEV?
• Бэкран против сэндвич-стратегии
• Вероятность включения 101
• Руководство по исправлению неудачных пакетов
• Отладка частного пакета (текущий)

О чем на самом деле говорит фраза «пакет не прошел»

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

1. Ваш клиент сериализует пакет и отправляет его на ретранслятор (relay.flashbots.net, rpc.titanbuilder.xyz и т. д.).
2. Релей проверяет схему, запускает моделирование и передает ее участвующим разработчикам.
3. Строители включают ваш пакет, если он повышает ценность их блока выше следующей лучшей альтернативы.
4. Предлагающий публикует тот строительный блок, за который ему заплатили больше всего.

Промах может произойти на шаге 2 (громко — релей возвращает ошибку), шаге 3 (в основном тихо — релей принят, строитель не включен) или шаге 4 (тихо — слот выиграл не тот строитель). Большинство операторов видят «пакет не доставлен» и предполагают, что причина едина. Этого почти никогда не бывает.

Восемь режимов отказа

1. Устаревшая модель комиссий

Симптом: симулятор показывает пакет как выгодный, релей принимает, ни один сборщик не включает.

Причина: между симуляцией и отправкой базовая комиссия сместилась настолько, что ваша приоритетная комиссия больше не является конкурентоспособной.

Исправление: повторно запросите eth_feeHistory непосредственно перед подписанием пакета; отклонить, если плата на момент подписания отличается от моделируемой более чем на настроенный порог. В часы Polygon и загруженной основной сети комиссии могут меняться на 20–30 % в пределах одного блока.

2. Несоответствие подсказки

Симптом: релей возвращает 400/"неверная подсказка"/"неподдерживаемый параметр".

Причина: вы отправили подсказку, которую релей не поддерживает, или забыли подсказку, которую требует релей. Типичные нарушения: revertingTxHashes для tx, которые могут быть отменены; minTimestamp / maxTimestamp; replacementUuid для повторной подачи.

Исправление: проверьте документированную схему релея для целевой версии. Большинство релее принимают дополнительные поля молча; некоторые отвергают. Перед развертыванием протестируйте пакет Canary на каждом релее.

3. Моделирование дрейфа

Симптом: симулятор зеленый, реальная отправка возобновляется при включении.

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

Исправление: имитируйте ожидаемое состояние целевого блока, а не текущей головы. Для 12-секундных слотов основной сети это означает получение текущего состояния, применение триггерной передачи в вашем симе, а затем наложение вашего бэкрана. Если ваш сим не моделирует триггер, ваш сим лжет.

4. Проскальзывание целевого блока

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

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

Исправление: установите targetBlockNumber и maxBlockNumber всего на один или два блока вперед. Лучше промахнуться, чем опоздать по худшей цене. Некоторые стратегии предназначены только для первого блока — это явно закодировано.

5. Задержка для ретрансляции

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

Причина: RTT к релею достаточно велико, поэтому ваш пакет прибудет после того, как строитель уже заблокировал блок.

Исправление: измерьте значение p95 RTT для каждого используемого релея. Все, что превышает ~150 мс в основной сети, сомнительно; более ~300 мс нарушено. Переместите отправителя ближе (другой регион, другой облачный провайдер) или переключите ретрансляторы. Периодически запускайте тест задержки WSS.

6. Ограничение ставки строителя

Симптом: 429 Too Many Requests, 503 Service Unavailable или бесшумное падение выше определенного уровня.

Причина: вы превысили предел скорости релея. Уровни бесплатного пользования жестко ограничены; даже платные уровни ограничивают скорость отправки пакетов в секунду.

Исправление: проверьте ограничения по уровням, выполните пакетную отправку, если ваша стратегия генерирует много кандидатов в секунду, и полностью отключитесь от 429. Если вам действительно нужно больше ставок, обновите или распределите несколько релеев для естественного распределения ставок.

7. Ошибка кодирования полезной нагрузки

Симптом: релей возвращает «недопустимый пакет», «неверную транзакцию» или 422.

Причина: неправильная кодировка RLP, отсутствует идентификатор ChainId, несоответствие EIP-1559 и устаревшей версии, неверный формат подписи.

Исправление: декодируйте сериализованный пакет с помощью нового инструмента (например, cast tx --decode) и сравните его с ожидаемым. Распространенная ошибка: подписание с неправильным идентификатором цепочки после копирования кода из руководства. Также: для некоторых релеев требуется только тип 2 (EIP-1559); устаревшие txs автоматически удаляются.

8. Дефицит покрытия билдера

Симптом: пакет принят ретранслятором, сборщик не включен, никаких особых ошибок.

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

Исправление: распределите как минимум четыре сборщика (Flashbots, Titan, beaverbuild, rsync-builder — современная версия по умолчанию). Отслеживайте, какой релей доставило каждый успешный пакет; со временем сосредоточьте свое внимание на победителях. Агент FRB автоматически выполняет это разветвление и регулировку веса.

Диагностический поток

Если пакет отсутствует, пройдите поток в следующем порядке:

1. Релей вернул ошибку? → проверьте код ошибки; сопоставить режим отказа 2, 6 или 7.
2. Нет ошибки релея, нет включения? → проверьте повторное моделирование eth_callBundle относительно фактического блока, который был добыт. Если сим теперь говорит: вернуться → режим 3 (дрейф). Если сим говорит прибыль, но вас не включили → режимы 1, 4 или 8.
3. Гистограмма задержки для неисправных пакетов. → если задержка p95 была увеличена → режим 5.
4. Скорость включения ретранслятором за последние N пакетов. → если скорость одного ретранслятора упала → режим 8 (покрытие этого ретранслятора пропало).

Что регистрировать, чтобы была возможна отладка

• Временная метка отправки пакета + ретрансляция + уровень
• Имитируемая прибыль (хеш сима + результат)
• Целевой блок + максимальный блок
• Ответ релея (код состояния + отрывок из тела)
• Результат включения: включено? в каком блоке? какой газ заплатил? реализованная прибыль?
• Задержка: время от локального «решения об отправке» → принятие релеи → добыча блока.

Этого состояния достаточно для заполнения ежедневной информационной панели с разбивкой по причинам включения. Большинство заявок «FRB не работает» разрешаются в одном запросе к завершенному набору журналов.

Когда исправлять стратегию или инфра

Постоянный разрыв между смоделированной и реализованной прибылью (> 10 %, сохраняющийся в течение нескольких дней) является проблемой стратегии — модель в чем-то неверна. Постоянный разрыв между отправленными и включенными пакетами (<60% включения в стратегии, которая ожидает 80%+) — это инфра проблема — покрытие ретрансляции, задержка или модель оплаты.

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

Связанный

• Руководство по исправлению неудачных пакетов
• Вероятность включения 101
• Лучшие частные RPC Ethereum