| Поле или событие | Что требуется | Что ломает вывод |
|---|---|---|
| Sender | Один и тот же адрес отправителя | Тот же Lease у другого отправителя |
| Lease | Одинаковые ненулевые 32 байта | Новый Lease или ошибка декодирования base64 |
| Окно | FirstValid и LastValid кандидатов не оставляют повтору хвост после защиты | У второго платежа более поздний LastValid |
| Первая транзакция | Она действительно вошла в подтверждённый раунд | Только pending или сообщение локального узла |
- Поле или событие
- Sender
- Что требуется
- Один и тот же адрес отправителя
- Что ломает вывод
- Тот же Lease у другого отправителя
- Поле или событие
- Lease
- Что требуется
- Одинаковые ненулевые 32 байта
- Что ломает вывод
- Новый Lease или ошибка декодирования base64
- Поле или событие
- Окно
- Что требуется
- FirstValid и LastValid кандидатов не оставляют повтору хвост после защиты
- Что ломает вывод
- У второго платежа более поздний LastValid
- Поле или событие
- Первая транзакция
- Что требуется
- Она действительно вошла в подтверждённый раунд
- Что ломает вывод
- Только pending или сообщение локального узла
Lease привязан к отправителю, а не к назначению платежа
В протокольном Header поле Lease имеет тип [32]byte и кодируется как lx. Нулевое значение не создаёт защиту. После включения транзакции сеть удерживает пару Sender–Lease до тех пор, пока не пройдёт LastValid этой подтверждённой транзакции. Такой же набор байтов у другого Sender — другая пара, а одинаковые получатель и сумма без Lease вообще не дают этой гарантии.
Не смешивайте Lease с обычным transaction ID. Изменение fee, FirstValid, LastValid или любого другого поля меняет подписанные байты и обычно txID, но одинаковая ненулевая пара Sender–Lease всё ещё связывает кандидатов. Общая инструкция по проверке перевода полезна для сети, суммы и получателя; Lease отвечает только за взаимное исключение.
Окна кандидатов проверяют целиком, а не по одному LastValid
FirstValid задаёт первый допустимый раунд, LastValid — последний. Если первый кандидат подтвердился, его Lease блокирует ту же пару до прохождения собственного LastValid. Но второй кандидат с более поздним LastValid может остаться валидным после снятия защиты. Поэтому официальный пример повышения fee сохраняет Lease, FirstValid и LastValid без изменений, меняя только комиссию.
Как собрать доказательство одного платежа
- 1Декодируйте обе транзакции
Сохраните сеть и genesis hash, Sender, Receiver, Amount, Fee, FirstValid, LastValid, Lease и txID. Сравнивайте исходные 32 байта Lease, а не укороченную строку интерфейса.
- 2Найдите подтверждённого победителя
Через синхронизированный algod или Indexer установите раунд включения одной транзакции. Карточка pending, успешный broadcast и наличие в локальном пуле не подходят.
- 3Проверьте область взаимного исключения
Убедитесь, что Sender и Lease совпадают. Сверьте, что конкурирующий кандидат не имеет допустимого хвоста после LastValid подтверждённой транзакции.
- 4Дождитесь исхода второго txID
Зафиксируйте его отказ либо отсутствие в подтверждённых раундах до завершения собственного окна. Ошибка конкретного SDK полезна для диагностики, но доказательством остаётся состояние сети.
- 5Сверьте конечное состояние
Проверьте баланс и платёж получателя после подтверждённого раунда. Одного Lease недостаточно, если первая транзакция сама завершилась не тем действием, которое ожидалось.
Atomic group решает другую задачу: либо включается вся группа, либо ни один её элемент. Rekey меняет адрес, который вправе подписывать за Sender. Эти механики нельзя подменять Lease при разборе повторного платежа.
После LastValid защиту нельзя считать постоянной
| Наблюдение | Вывод | Следующее действие |
|---|---|---|
| Первый tx подтверждён, второй имеет то же окно | Второй не может подтвердиться в этом окне | Сохранить оба payload и раунд результата |
| Второй имеет более поздний LastValid | После снятия Lease у него может остаться время | Не ждать молча: отслеживать его txID до конца собственного окна |
| Первый так и не подтвердился | Lease не был приобретён | После всех LastValid доказать отсутствие и только затем строить новый платёж |
| Окна закончились и платежа нет | Старая защита завершилась | Собрать новый intent с актуальными раундами и новой подписью |
| Платёж уже подтверждён | Повтор не нужен | Не переиспользовать старый подписанный payload |
- Наблюдение
- Первый tx подтверждён, второй имеет то же окно
- Вывод
- Второй не может подтвердиться в этом окне
- Следующее действие
- Сохранить оба payload и раунд результата
- Наблюдение
- Второй имеет более поздний LastValid
- Вывод
- После снятия Lease у него может остаться время
- Следующее действие
- Не ждать молча: отслеживать его txID до конца собственного окна
- Наблюдение
- Первый так и не подтвердился
- Вывод
- Lease не был приобретён
- Следующее действие
- После всех LastValid доказать отсутствие и только затем строить новый платёж
- Наблюдение
- Окна закончились и платежа нет
- Вывод
- Старая защита завершилась
- Следующее действие
- Собрать новый intent с актуальными раундами и новой подписью
- Наблюдение
- Платёж уже подтверждён
- Вывод
- Повтор не нужен
- Следующее действие
- Не переиспользовать старый подписанный payload
Когда все известные окна закончились, не отправляйте старый blob повторно. Возьмите свежие suggested parameters, заново проверьте получателя и сумму, выберите осмысленный Lease и подпишите новый payload. Число подтверждений и история раундов помогают отделить локальный отказ от результата сети.
Стоп-сигналы
- интерфейс не показывает полный Sender, Lease и оба окна;
- для второго кандидата незаметно изменили FirstValid или LastValid;
- успех объявляют по broadcast без подтверждённого раунда;
- одинаковый Lease называют глобальным запретом для всех отправителей;
- после LastValid обещают постоянную защиту от повтора.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Algorand Developer Portal — Leases Algorand Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
- Algorand Developer Portal — Transaction Reference Algorand Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
- Algorand Developer Portal — Transaction Types Algorand Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5