Onchain number — это следующий свободный слот
Для обычной транзакции sender подписывает sequence_number. После commit Aptos увеличивает sequence number аккаунта. Поэтому onchain 42 означает, что 0–41 уже разрешены состоянием аккаунта, а следующая ожидаемая обычная транзакция использует 42. Подпись связывает номер с payload, gas, expiration, chain ID и authenticator.
| Signed number | Типичное состояние | Что доказать |
|---|---|---|
| Меньше onchain | Слишком старый или уже committed slot | Hash предыдущей транзакции и отсутствие нового commit |
| Равен onchain | Следующий кандидат | Pending hash, expiration, gas и приём конкретным fullnode |
| Выше onchain | Пропуск в очереди | Наличие всех промежуточных номеров или причина их отсутствия |
| u64::MAX + replay nonce | Возможный orderless формат | ReplayProtector и feature/version, а не account queue |
- Signed number
- Меньше onchain
- Типичное состояние
- Слишком старый или уже committed slot
- Что доказать
- Hash предыдущей транзакции и отсутствие нового commit
- Signed number
- Равен onchain
- Типичное состояние
- Следующий кандидат
- Что доказать
- Pending hash, expiration, gas и приём конкретным fullnode
- Signed number
- Выше onchain
- Типичное состояние
- Пропуск в очереди
- Что доказать
- Наличие всех промежуточных номеров или причина их отсутствия
- Signed number
- u64::MAX + replay nonce
- Типичное состояние
- Возможный orderless формат
- Что доказать
- ReplayProtector и feature/version, а не account queue
Это похоже на nonce Ethereum только общей идеей защиты от replay. Правила mempool, replacement и committed API различаются, поэтому Ethereum-инструкцию нельзя переносить на Aptos.
Высокий номер ждёт закрытия пропуска
Runbook для одной sender account
- 1Прочитать committed state
Получите account sequence_number с двух синхронизированных fullnodes и зафиксируйте ledger version/time.
- 2Инвентаризировать локальные подписи
Для каждого номера сохраните transaction hash, payload digest, gas settings, expiration, submit time и endpoint. Не подписывайте новый intent на занятом номере.
- 3Проверить hash
Различите PendingTransaction без ledger version и committed UserTransaction с success/vm_status. 404 одного узла не доказывает глобальное отсутствие.
- 4Найти первый пропуск
Если signed number выше onchain, проверьте каждый номер начиная с onchain. Очередь не починится повтором самого высокого номера.
- 5Проверить expiration
Истёкшая неподтверждённая транзакция не должна считаться будущим commit; после обновления состояния пересоберите нужный слот.
- 6Сверить результат
После commit перечитайте account number и бизнес-state. Увеличение sequence number не означает, что любой ожидаемый эффект понят без success/vm_status.
seqno TON тоже задаёт порядок внешних сообщений кошелька, а blockhash Solana ограничивает свежесть подписи, но это отдельные протоколы. Для Aptos источником решения остаются signed request, REST response и committed account state одной сети. Не смешивайте очереди разных sender accounts: sequence number принадлежит аккаунту, а не dApp или получателю.
Пересобрать можно только после классификации первого номера
| Сигнал | Интерпретация | Действие |
|---|---|---|
| SEQUENCE_NUMBER_TOO_OLD | Slot уже позади committed state | Найти committed tx; не повторять старую подпись |
| SEQUENCE_NUMBER_TOO_NEW | Есть пропуск или node state отстаёт | Сверить fullnode и заполнить/дождаться первого номера |
| Hash pending до expiration | Транзакция принята одним mempool, но не committed | Не создавать конфликтующий intent; проверить peers/endpoints |
| TRANSACTION_EXPIRED | Подписанный request больше невалиден | Обновить sequence state, expiration и gas, подписать заново |
| ReplayProtector=nonce | Это orderless transaction | Перейти к nonce/expiration workflow AIP-123 |
- Сигнал
- SEQUENCE_NUMBER_TOO_OLD
- Интерпретация
- Slot уже позади committed state
- Действие
- Найти committed tx; не повторять старую подпись
- Сигнал
- SEQUENCE_NUMBER_TOO_NEW
- Интерпретация
- Есть пропуск или node state отстаёт
- Действие
- Сверить fullnode и заполнить/дождаться первого номера
- Сигнал
- Hash pending до expiration
- Интерпретация
- Транзакция принята одним mempool, но не committed
- Действие
- Не создавать конфликтующий intent; проверить peers/endpoints
- Сигнал
- TRANSACTION_EXPIRED
- Интерпретация
- Подписанный request больше невалиден
- Действие
- Обновить sequence state, expiration и gas, подписать заново
- Сигнал
- ReplayProtector=nonce
- Интерпретация
- Это orderless transaction
- Действие
- Перейти к nonce/expiration workflow AIP-123
Recovery record должен включать sender, chain ID, ledger version, committed sequence number, все затронутые signed numbers/hashes, payload digests, expiration, endpoints и финальные success/vm_status. Если два разных intent подписаны на одном slot, не пытайтесь «ускорить оба»: сначала определите единственный нужный payload и наблюдайте его commit либо expiration. Новый body всегда требует новой проверки gas и expiration. Чтобы не спутать приём в mempool с исполнением, отдельно проверьте статус транзакции и целевой state.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Aptos Core — REST transaction types Aptos Labs · Проверено 23 августа 2026 г. в 20:00 GMT+5
- Aptos Core — VM validation status Aptos Labs · Проверено 23 августа 2026 г. в 20:00 GMT+5
- Aptos Framework — account sequence number Aptos Labs · Проверено 23 августа 2026 г. в 20:00 GMT+5
- Aptos AIP-123 — orderless transactions Aptos Foundation · Проверено 23 августа 2026 г. в 20:00 GMT+5