Паттерн Proxy/Upgradable на TON
Спроектируешь proxy+implementation: стабильный адрес для клиентов и смена логики через admin.
Proxy / Upgradable
Прямой setCode меняет код того же адреса. Паттерн proxy разделяет роли: proxy держит адрес и storage (или маршрутизацию), implementation — логику. Клиенты всегда пишут в proxy; admin меняет ссылку на implementation или код proxy по жёстким правилам.
На TON нет «delegatecall как в EVM». Proxy обычно пересылает сообщения в implementation или сам хранит state и меняет только code.
Proxy с переключаемой логикой
Как это работает
- Клиент знает только адрес
Proxy— ABI/обёртки стабильны снаружи. SetImplementationпереключает целевой контракт; state в примере живёт в LogicV1 (при смене реализации миграция отдельная задача).- Альтернатива: state в Proxy, а implementation — библиотека/модуль, либо апгрейд через
setCodeна самом Proxy (проще, но сильнее связывает storage и код). require(sender() == self.proxy)на LogicV1 отсекает прямые вызовы в обход proxy.- Для прод-апгрейда добавь timelock/multisig на
owner(см. статьи про timeout и set_code).
Частые ошибки
Сменил implementation, забыв миграцию storage → новый код смотрит пустой/чужой state.
Implementation принимает сообщения от кого угодно → обход proxy и рассинхрон инвариантов.
Proxy глотает bounce без политики → клиент думает, что Exec прошёл; обрабатывай bounce или делай синхронный ack-протокол.
Что дальше
- Апгрейд кода контракта (set_code) — апгрейд без смены адреса implementation
- Таймауты и отложенные сообщения — timelock на смену implementation
- Деплой контракта в mainnet: чеклист — зафиксировать proxy-адрес до анонса
Материалы gramdocs.tech носят образовательный характер и не являются финансовой, юридической или инвестиционной рекомендацией. Работа с блокчейном TON и токеном Gram связана с рисками потери средств. Правовая информация