Апгрейд кода контракта (set_code)

Заложишь безопасный апгрейд через setCode: проверка owner, смена code/data и защита от двойной записи storage.

set_code

Адрес контракта считается от initial code+data, но текущий код аккаунта можно заменить инструкцией SETCODE. В Tact это setCode(cell) — обычно только из admin-receiver и только после явной валидации.

Upgradable-контракт

// @tact-lang/compiler 1.6.13
import "@stdlib/ownable";

message Upgrade {
    code: Cell?; // null = не трогать код
    data: Cell?; // null = не трогать данные
}

contract Vault(
    owner: Address,
    version: Int as uint32,
    locked: Bool,
) with Ownable {
    receive() {
        cashback(sender());
    }

    receive(msg: Upgrade) {
        self.requireOwner();

        if (msg.code != null) {
            // Применится в конце транзакции
            setCode(msg.code!!);
        }
        if (msg.data != null) {
            setData(msg.data!!);
            // Компилятор в конце сам вызовет setData(storage) —
            // прерываем транзакцию, чтобы не затереть новый data старым snapshot
            throw(0);
        }

        self.version += 1;
    }

    get fun version(): Int {
        return self.version;
    }

    get fun locked(): Bool {
        return self.locked;
    }
}

asm fun setCode(code: Cell) { SETCODE }

Как это работает

• setCode меняет код аккаунта; адрес остаётся прежним.
• Смена data через setData + throw(0) — паттерн из Tact cookbook: успешный exit без повторной записи storage компилятором.
• Ownable / requireOwner() — без этого апгрейд открыт любому отправителю.
• Новая версия кода должна уметь прочитать старый layout data (или ты сразу шлёшь совместимый data).
• Для отложенного апгрейда используй двухфазный timeout (см. DelayedUpgradable в docs Tact) или proxy.

Частые ошибки

Апгрейд без миграции storage → новый код читает поля не в том порядке и сразу ломается.

setData без throw(0) → конец транзакции перезапишет data обратно из in-memory state старого кода.

Нет timelock / multisig на owner → компрометация одного ключа = мгновенная подмена логики.

Что дальше

• Паттерн Proxy/Upgradable на TON — когда код лучше вынести за proxy
• Деплой контракта в mainnet: чеклист — заложи upgrade path до первого деплоя
• Таймауты и отложенные сообщения — delayed confirm для апгрейда

Материалы gramdocs.tech носят образовательный характер и не являются финансовой, юридической или инвестиционной рекомендацией. Работа с блокчейном TON и токеном Gram связана с рисками потери средств. Правовая информация