TON frozen account: как восстановить контракт через StateInit

Frozen хранит проверку прошлого, а не само прошлое

По текущей TON Documentation ранее active account с изменявшимся state переходит в frozen, когда непогашенный storage debt превышает 0.1 GRAM. В frozen остаётся state hash последнего account state, а code и persistent data уже не доступны для исполнения. Порог и переход относятся к текущим протокольным правилам на дату проверки; их надо перечитать при изменении конфигурации или документации.

Адрес TON вычисляется из StateInit, но одной формы адреса недостаточно. Для unfreeze нужен valid last state: StateInit последней успешной транзакции до заморозки, чей hash совпадает с сохранённым frozen state. Форматы адресов TON помогают не перепутать workchain и account ID, но bounceable-представление не восстанавливает code/data и не доказывает совпадение state.

StateInit надо воспроизвести байт-в-байт

StateInit включает code, data, optional library и другие сериализованные поля. Совпадение исходников или версии компилятора не гарантирует тот же cell tree: constructor data, public keys, salts, library references и layout могли отличаться. Надёжный путь — извлечь последний подтверждённый BOC из собственного deployment archive или воспроизводимой сборки и локально сравнить вычисленный hash с frozen state до любой отправки.

Value должен погасить storage debt, но универсальной суммы нет

Storage fee зависит от bits, cells, прошедшего времени и config parameter 18; к сообщению добавляются другие фазы и комиссии. Для рассматриваемого здесь documented non-bounceable internal path frozen account возвращается в active, когда передан valid last StateInit и storage_fees_due после Storage phase становится нулём. Считайте текущий debt непосредственно перед отправкой и добавляйте проверяемый запас по симуляции, а не копируйте старую сумму из чужого кейса.

Active — ещё не доказательство целевого действия

Recovery считается подтверждённым, когда transaction показывает orig_status frozen и end_status active, восстановленные code/data соответствуют ожидаемому state, а storage debt закрыт. Затем отдельно проверяют compute/action и исходящие сообщения: фазы транзакции TON могут показать ошибку body даже после корректного state transition. Не повторяйте message, пока не установлен точный результат первой попытки.

Если exact StateInit не воспроизводится, безопасного on-chain обхода hash-проверки нет: сохраните доказательства и остановите переводы на адрес. Для стандартного wallet дополнительно зафиксируйте его версию и seqno и valid_until только как данные отправителя следующего message, а не как способ восстановить state. Архивные чтения сверяйте через независимый RPC-узел; расхождение endpoint — причина отложить подпись, а не выбрать удобный ответ.