Сначала докажите, что это P-Chain
У Avalanche несколько цепочек с разными API. C-Chain использует хеши и квитанции EVM. P-Chain через PlatformVM обслуживает валидаторов, стейкинг и операции L1. Строка, похожая на txID, сама не выбирает нужный API. Сохраните идентификатор сети, базовый адрес узла, метод и полный txID. Затем вызовите `platform.getTxStatus` на `/ext/bc/P`.
Если публичный RPC и ваш узел отвечают по-разному, сравните их состояние синхронизации и высоту. Разница может быть обычной задержкой. Материал о блокчейн-узле и RPC объясняет, почему ответ одной точки доступа не равен мнению всей сети.
Таблица статусов — это набор улик
| Статус | Что известно | Что делать |
|---|---|---|
| `Committed` | Транзакция принята или будет принята каждым узлом по описанию метода | Проверить, произошло ли нужное изменение в P-Chain |
| `Processing` | Этот узел участвует в голосовании по транзакции | Ждать и снова спросить о том же txID на том же узле |
| `Dropped` | Транзакция окончательно отклонена; ответ содержит поле `reason` | Сохранить причину, исправить входные данные и только потом собрать новую транзакцию |
| `Unknown` | Этот узел транзакцию не видел | Сверить исходный маршрут и второй узел; не считать ответ финалом |
- Статус
- `Committed`
- Что известно
- Транзакция принята или будет принята каждым узлом по описанию метода
- Что делать
- Проверить, произошло ли нужное изменение в P-Chain
- Статус
- `Processing`
- Что известно
- Этот узел участвует в голосовании по транзакции
- Что делать
- Ждать и снова спросить о том же txID на том же узле
- Статус
- `Dropped`
- Что известно
- Транзакция окончательно отклонена; ответ содержит поле `reason`
- Что делать
- Сохранить причину, исправить входные данные и только потом собрать новую транзакцию
- Статус
- `Unknown`
- Что известно
- Этот узел транзакцию не видел
- Что делать
- Сверить исходный маршрут и второй узел; не считать ответ финалом
Сопоставьте три свидетельства об одном txID
Первое свидетельство — txID из ответа `platform.issueTx` и, если они сохранились, байты подписанной транзакции. Второе — ответ того же адреса `/ext/bc/P`, куда её отправляли, с временем запроса. Третье — ответ другого синхронизированного узла той же сети. Для принятой транзакции `platform.getTx` даёт ещё одну проверку: полученные данные должны относиться к тому же txID и той же операции.
Финальность и полезный результат — не одно и то же. После `Committed` отдельно проверьте валидатора, делегирование, баланс или другое изменение, ради которого создавалась операция. Уровни подтверждения и реорганизации разобраны в отдельном материале.
Действие выбирают после сопоставления улик
При `Dropped` сохраните поле `reason`, байты подписанной транзакции, сеть, версию узла и время. Причина может относиться к UTXO, подписи, синтаксической проверке, состоянию валидатора или правилам конкретного вида операции. Повторная отправка тех же байтов ничего в них не исправляет.
| Что найдено | Следующее действие | Чего не делать |
|---|---|---|
| `Processing` | Ждать и опрашивать тот же txID | Не выпускать конкурирующую операцию с теми же входами |
| `Dropped` с понятной исправимой причиной | Обновить состояние, входы или параметры, заново собрать и подписать; получится новый txID | Не терять прежнее значение `reason` |
| `Unknown` только у одного узла, исходные байты есть | После проверки сети можно снова передать те же байты исходному или другому P-Chain RPC | Не собирать одновременно вторую экономическую операцию |
| `Unknown` у всех, исходные байты потеряны | Сначала проверить текущее состояние P-Chain и отсутствие нужного результата | Не отправлять «замену» по памяти |
| `Committed` | Проверить целевое изменение и сохранить доказательства | Не повторять ту же операцию |
- Что найдено
- `Processing`
- Следующее действие
- Ждать и опрашивать тот же txID
- Чего не делать
- Не выпускать конкурирующую операцию с теми же входами
- Что найдено
- `Dropped` с понятной исправимой причиной
- Следующее действие
- Обновить состояние, входы или параметры, заново собрать и подписать; получится новый txID
- Чего не делать
- Не терять прежнее значение `reason`
- Что найдено
- `Unknown` только у одного узла, исходные байты есть
- Следующее действие
- После проверки сети можно снова передать те же байты исходному или другому P-Chain RPC
- Чего не делать
- Не собирать одновременно вторую экономическую операцию
- Что найдено
- `Unknown` у всех, исходные байты потеряны
- Следующее действие
- Сначала проверить текущее состояние P-Chain и отсутствие нужного результата
- Чего не делать
- Не отправлять «замену» по памяти
- Что найдено
- `Committed`
- Следующее действие
- Проверить целевое изменение и сохранить доказательства
- Чего не делать
- Не повторять ту же операцию
Когда инцидент можно закрыть
- для `Dropped` сохранена причина отказа, а новая транзакция исправляет именно её;
- для `Unknown` ответы узлов и наличие исходных байтов объясняют, почему выбрано ожидание или повтор тех же байтов;
- для `Committed` подтверждено нужное изменение P-Chain, а не только сам статус.
К записи об инциденте приложите сеть, полный txID, адреса опрошенных RPC, время и исходные ответы. Это даёт проверяемое подтверждение операции без снимка экрана, который нельзя воспроизвести.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Avalanche Builder Hub — P-Chain RPC Avalanche · Проверено 25 августа 2026 г. в 00:12 GMT+5
- Avalanche Builder Hub — platform.getTxStatus API reference Avalanche · Проверено 25 августа 2026 г. в 00:12 GMT+5
- Avalanche Builder Hub — P-Chain SDK methods Avalanche · Проверено 25 августа 2026 г. в 00:12 GMT+5
- Avalanche Builder Hub — PlatformVM architecture Avalanche · Проверено 25 августа 2026 г. в 00:12 GMT+5