Архивация состояния Soroban: TTL и восстановление

Сначала убедитесь, что проверяете именно ту запись

TTL — число реестров, в течение которых запись остаётся доступной. Для проверки нужен не читаемый фрагмент, а полный `LedgerKey`: сеть, идентификатор контракта (`contract ID`), класс хранения (`durability`: `Temporary` или `Persistent`) и точное значение ключа в формате `ScVal`. `Instance` хранится в записи экземпляра контракта и делит с ним TTL. Одно имя может существовать в разных классах хранения и означать разные данные.

Запросите этот ключ через `getLedgerEntries` и сохраните `latestLedger`, `lastModifiedLedgerSeq`, значение и `liveUntilLedgerSeq`. RPC показывает только доступное сейчас состояние, а не всю историю. Если источники расходятся, сначала сравните сеть, номер последнего реестра и полноту данных. Устройство RPC объясняет, почему ответ одного провайдера нельзя выдавать за состояние всей сети.

Решение по типу и состоянию записи
Наблюдение	Состояние	Допустимое действие	Проверка результата
Текущий номер реестра не больше `liveUntilLedger`	Запись жива	Продлить TTL заранее, если срок слишком близок	Тот же `LedgerKey` возвращает прежнее значение и не меньший целевой TTL
TTL закончился, тип `Persistent`	Запись в архиве	Симулировать исходный вызов для списка восстановления; отдельное ручное восстановление нужно лишь в редких случаях	Запись снова читается, затем успешно выполняется исходный вызов
TTL закончился у `Instance` или кода контракта	Экземпляр или код в архиве	Подготовить восстановление связанных записей через симуляцию	Записи экземпляра и кода читаются, а вызов завершён в реестре
TTL закончился, тип `Temporary`	Запись удалена	Восстановления нет; только заново получить данные из доверенного источника, если логика это разрешает	Появилась новая запись, а источник нового значения зафиксирован
Ключ не найден, тип неизвестен	Вывод ещё не определён	Проверить идентификатор контракта, кодирование `ScVal`, класс хранения, сеть и RPC	Тип и состояние записи установлены

Решение по типу и состоянию записи

Наблюдение: Текущий номер реестра не больше `liveUntilLedger`
Состояние: Запись жива
Допустимое действие: Продлить TTL заранее, если срок слишком близок
Проверка результата: Тот же `LedgerKey` возвращает прежнее значение и не меньший целевой TTL

Наблюдение: TTL закончился, тип `Persistent`
Состояние: Запись в архиве
Допустимое действие: Симулировать исходный вызов для списка восстановления; отдельное ручное восстановление нужно лишь в редких случаях
Проверка результата: Запись снова читается, затем успешно выполняется исходный вызов

Наблюдение: TTL закончился у `Instance` или кода контракта
Состояние: Экземпляр или код в архиве
Допустимое действие: Подготовить восстановление связанных записей через симуляцию
Проверка результата: Записи экземпляра и кода читаются, а вызов завершён в реестре

Наблюдение: TTL закончился, тип `Temporary`
Состояние: Запись удалена
Допустимое действие: Восстановления нет; только заново получить данные из доверенного источника, если логика это разрешает
Проверка результата: Появилась новая запись, а источник нового значения зафиксирован

Наблюдение: Ключ не найден, тип неизвестен
Состояние: Вывод ещё не определён
Допустимое действие: Проверить идентификатор контракта, кодирование `ScVal`, класс хранения, сеть и RPC
Проверка результата: Тип и состояние записи установлены

Продлевайте живую запись до истечения TTL

`ExtendFootprintTTLOp` использует часть набора ресурсов только для чтения (`readOnly`) и должен быть единственной операцией в транзакции. Значение `extendTo` задаёт нижнюю границу оставшегося TTL. Если запись уже живёт дольше, сеть не сокращает срок и может ничего не менять. Максимальный TTL задаёт сеть; не переносите число из примера в рабочую конфигурацию.

Данные для операции продления

точные `LedgerKey` и их типы, без смешения Temporary, Persistent и Instance;
текущий номер реестра и `liveUntilLedger` каждого объекта;
набор ресурсов только для чтения (`readOnly`) без тех же записей в наборе чтения и записи (`readWrite`);
целевой остаток TTL внутри текущего максимума сети;
результат подготовки или симуляции с рассчитанными ресурсами и комиссией.

Protocol 23 обычно восстанавливает запись вместе с вызовом

Для архивного `Persistent` или `Instance` соберите исходный `InvokeHostFunction` и запустите симуляцию на свежем состоянии. Если симуляция обнаружит обращение к архивной записи, она добавит её в список восстановления. Подготовленная транзакция сначала вернёт перечисленные записи, затем выполнит функцию. Арендная плата и комиссия за ресурсы при этом сохраняются.

Транзакция, собранная без симуляции и полного списка восстановления, остановится до доступа к архивным данным. `RestoreFootprintOp` после Protocol 23 нужен редко: например, когда автоматическое восстановление делает вызов слишком большим или разработчик хочет оплатить восстановление отдельно. Архивные ключи помещают в набор чтения и записи (`readWrite`), а набор только для чтения (`readOnly`) оставляют пустым.

Успешная симуляция ещё не доказывает включение. Между реестром, на котором она выполнена, и будущим блоком состояние и стоимость ресурсов могут измениться. Дождитесь записи транзакции в реестре и только затем сравнивайте состояние. Граница между ожиданием и подтверждением описана в гайде о финальности.

Удалённую Temporary можно только создать заново

После окончания TTL `Temporary` удалён. Если контракт допускает новую запись, её значение надо получить предусмотренным способом: из нового обновления оракула, повторяемого вычисления или подписанного прикладного сообщения. Снимок неизвестного RPC, скриншот интерфейса и слова пользователя не восстанавливают происхождение, подтверждённое сетью.

Выбор типа хранилища относится к архитектуре контракта. Балансы и другие незаменимые данные не должны зависеть от ветки, которая после TTL исчезает навсегда. Перед изменением контракта полезно вернуться к базовой модели смарт-контракта: код выполняет заданные переходы, но не угадывает утраченное состояние.

После операции снова прочитайте ту же запись

получите окончательный статус транзакции и номер реестра для продления, восстановления или исходного вызова контракта;
повторите `getLedgerEntries` для тех же `LedgerKey` и сохраните новый `liveUntilLedgerSeq`;
сравните значение с ожидаемым, а не только наличие записи;
проверьте прикладной результат исходной функции: баланс, счётчик, владельца или другую конкретную величину;
зафиксируйте версии протокола и RPC, номер реестра симуляции, хеш транзакции и параметры сети без секретов.

Если транзакция успешна, но нужное значение не изменилось, восстановление могло пройти без требуемого прикладного действия. Другая причина — проверен неверный `LedgerKey`. Сопоставьте хеш и статус со снимком состояния так же, как при независимом подтверждении перевода.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

Stellar Docs — Smart contract state archival Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
Stellar Docs — Manual restoration footprint Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
Stellar Docs — Extend a persistent entry Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
Stellar RPC — getLedgerEntries Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
Stellar RPC — simulateTransaction Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5

Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.