Сначала определите слой отказа
| Наблюдение | Что не прошло | Что проверять первым |
|---|---|---|
| TAPOS_ERROR | Пара полей опорного блока не совпала с недавним блоком узла | ref_block_bytes, ref_block_hash и синхронизацию узла |
| TRANSACTION_EXPIRATION_ERROR | Истёк жёсткий срок raw_data.expiration | expiration в миллисекундах и время блока |
| SIGERROR | Подпись не соответствует raw_data или разрешению аккаунта | Точные байты подписываемых данных и разрешение подписанта |
| FAILED / OUT_OF_ENERGY в квитанции | Транзакция дошла до исполнения в цепочке | Квитанцию, результат и расход ресурсов |
- Наблюдение
- TAPOS_ERROR
- Что не прошло
- Пара полей опорного блока не совпала с недавним блоком узла
- Что проверять первым
- ref_block_bytes, ref_block_hash и синхронизацию узла
- Наблюдение
- TRANSACTION_EXPIRATION_ERROR
- Что не прошло
- Истёк жёсткий срок raw_data.expiration
- Что проверять первым
- expiration в миллисекундах и время блока
- Наблюдение
- SIGERROR
- Что не прошло
- Подпись не соответствует raw_data или разрешению аккаунта
- Что проверять первым
- Точные байты подписываемых данных и разрешение подписанта
- Наблюдение
- FAILED / OUT_OF_ENERGY в квитанции
- Что не прошло
- Транзакция дошла до исполнения в цепочке
- Что проверять первым
- Квитанцию, результат и расход ресурсов
Reference block — это два фрагмента одного блока
В `raw_data` поле `ref_block_bytes` хранит двухбайтовый интервал [6, 8) номера опорного блока. Поле `ref_block_hash` хранит восьмибайтовый интервал [8, 16) идентификатора того же блока. Валидатор ищет запись по первому фрагменту в `RecentBlockStore`, а затем сравнивает второй. Если записи нет или хеш не совпал, `java-tron` выбрасывает `TaposException`. Самого совпадения двух байт номера недостаточно.
Двухбайтовое пространство охватывает 65 536 значений, поэтому TRON принимает только недавнюю ссылку, которую узел ещё хранит. Официальная документация рекомендует брать свежий подтверждённый блок со статусом `solidified`. Он немного старше вершины, зато уже относится к подтверждённому участку цепочки. Ссылка может перестать подходить после долгого офлайн-подписания, рассинхронизации узла или смены ветки.
| Поле | Как зафиксировать | Что доказывает |
|---|---|---|
| txID и сериализованные байты | Сохранить до любых изменений | Какой именно подписанный объект диагностируется |
| ref_block_bytes | Два байта из raw_data | Ключ поиска недавнего номера, но не полный номер |
| ref_block_hash | Восемь байт из raw_data | Фрагмент идентификатора блока, который должен совпасть с найденным блоком |
| expiration | Миллисекунды Unix из raw_data | До какого момента транзакция может быть включена |
| Код и сообщение отправки | Исходный ответ конкретного узла | На каком этапе предварительной проверки произошёл отказ |
- Поле
- txID и сериализованные байты
- Как зафиксировать
- Сохранить до любых изменений
- Что доказывает
- Какой именно подписанный объект диагностируется
- Поле
- ref_block_bytes
- Как зафиксировать
- Два байта из raw_data
- Что доказывает
- Ключ поиска недавнего номера, но не полный номер
- Поле
- ref_block_hash
- Как зафиксировать
- Восемь байт из raw_data
- Что доказывает
- Фрагмент идентификатора блока, который должен совпасть с найденным блоком
- Поле
- expiration
- Как зафиксировать
- Миллисекунды Unix из raw_data
- Что доказывает
- До какого момента транзакция может быть включена
- Поле
- Код и сообщение отправки
- Как зафиксировать
- Исходный ответ конкретного узла
- Что доказывает
- На каком этапе предварительной проверки произошёл отказ
Проверка до новой подписи
Диагностический алгоритм
- 1Зафиксировать исходник
Сохраните `raw_data`, подписи, `txID`, адрес узла и полный ответ на отправку. Снимок короткой ошибки не позволяет сравнить пару опорных полей.
- 2Проверить узел
Сверьте его вершину и подтверждённое состояние с независимым синхронизированным источником. Сильно отставший или оказавшийся на другой ветке узел может отвергать набор данных, построенный для иной вершины.
- 3Восстановить reference block
Найдите недавний блок с тем же интервалом номера и сравните байты [8, 16) его идентификатора с `ref_block_hash`. Не подставляйте похожую высоту без проверки хеша.
- 4Отделить срок
Сравните `expiration` со временем цепочки. `Timestamp` — запись о сборке, а не разрешение на включение; его исправление без нового срока не оживляет транзакцию.
- 5Исключить уже состоявшийся перевод
Поищите прежний `txID` и квитанцию через узел, который отдаёт подтверждённые данные. Это особенно нужно, если подписанный набор до ошибки отправлялся другому узлу.
Публичный хеш помогает установить наличие транзакции и квитанции, но не заменяет исходный ответ узла на отправку. Сначала примените общий порядок проверки транзакции, а затем разбирайте поля TRON.
Пересобрать можно только после проверки намерения
| Состояние | Безопасное действие | Контроль результата |
|---|---|---|
| Опорная пара не совпала; txID нигде не найден | Получить свежий подтверждённый блок, пересобрать raw_data и ещё раз проверить получателя и сумму | Новая подпись, новый txID, успешная отправка и подтверждённая квитанция |
| Опорная пара совпадает, но expiration истёк | Не отправлять старые байты; после проверки намерения собрать новый срок и опорную пару | Убедиться, что прежний txID отсутствует, а новый включён |
| Исходный txID найден | Не создавать замену | Разобрать квитанцию и подтверждение именно найденной транзакции |
| Узел заметно отстаёт или расходится с независимым | Не доверять ему сборку и отправку до синхронизации | Повторить проверку опорных полей на исправном узле |
| Отправка принята, квитанции пока нет | Пока срок жив, можно повторно доставить только те же подписанные байты | Не пересобирать до истечения и подтверждённого отсутствия в цепочке |
- Состояние
- Опорная пара не совпала; txID нигде не найден
- Безопасное действие
- Получить свежий подтверждённый блок, пересобрать raw_data и ещё раз проверить получателя и сумму
- Контроль результата
- Новая подпись, новый txID, успешная отправка и подтверждённая квитанция
- Состояние
- Опорная пара совпадает, но expiration истёк
- Безопасное действие
- Не отправлять старые байты; после проверки намерения собрать новый срок и опорную пару
- Контроль результата
- Убедиться, что прежний txID отсутствует, а новый включён
- Состояние
- Исходный txID найден
- Безопасное действие
- Не создавать замену
- Контроль результата
- Разобрать квитанцию и подтверждение именно найденной транзакции
- Состояние
- Узел заметно отстаёт или расходится с независимым
- Безопасное действие
- Не доверять ему сборку и отправку до синхронизации
- Контроль результата
- Повторить проверку опорных полей на исправном узле
- Состояние
- Отправка принята, квитанции пока нет
- Безопасное действие
- Пока срок жив, можно повторно доставить только те же подписанные байты
- Контроль результата
- Не пересобирать до истечения и подтверждённого отсутствия в цепочке
Перед новой подписью снова проверьте, что именно подписывает кошелёк: адрес получателя, сумму, данные вызова контракта и разрешения. Смена опорного блока не переносит старое доверие на изменённый набор данных. После включения TAPOS уже не объясняет итог исполнения. `FAILED` и `OUT_OF_ENERGY` разбирают по квитанции, а доставку подтверждают по хешу, статусу и подтверждённому блоку.
В журнале разбора должны остаться исходный и новый `txID`, обе опорные пары, `expiration`, состояние узла и подтверждённая квитанция. Если новой квитанции нет, зафиксируйте точную причину остановки и не пересобирайте транзакцию до следующей проверки.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- TRON Developers — Transactions and TAPOS TRON DAO · Проверено 28 августа 2026 г. в 00:04 GMT+5
- TRON Developers — Broadcast and RPC errors TRON DAO · Проверено 28 августа 2026 г. в 00:04 GMT+5
- java-tron — pinned TAPOS validation implementation TRON Protocol · Проверено 28 августа 2026 г. в 00:04 GMT+5