Proxy Contract (прокси-контракт)
Смарт-контракт, перенаправляющий вызовы на отдельный контракт-реализацию (implementation). Позволяет апгрейдить логику без смены адреса протокола, но добавляет административный риск — кто-то контролирует право заменить реализацию.
Синонимы: прокси-контракт, upgradeable contract, proxy pattern
Proxy contract — это смарт-контракт, который не содержит бизнес-логики сам по себе, а перенаправляет (delegate-call или эквивалент) все вызовы на отдельный контракт-реализацию. Адрес прокси остаётся неизменным, а команда может «подменить» implementation, чтобы обновить логику без миграции пользователей и ликвидности.
Зачем это нужно
- Bugfix. Если в логике нашли уязвимость, можно патчить без публикации нового контракта.
- Эволюция функционала. Добавлять features без принудительного апгрейда пользователей.
- Сохранение адреса. Все хардкод-интеграции и balances продолжают работать.
Риски
- Admin key risk. Если ключом апгрейда владеет одна команда — это центральная точка отказа. Атакующий с этим ключом может развернуть вредоносную реализацию и сдрейнить весь TVL.
- Storage collisions. Layout сторадж между версиями должен совпадать; ошибка ломает контракт.
- Скрытая логика. Пользователи могут не заметить апгрейд и продолжать использовать контракт после malicious-замены.
Mitigations
- Timelock. Между анонсом апгрейда и его исполнением — задержка (72 часа+), за которую пользователи успевают выйти.
- Multisig на админ-ключе — см. multisig-threshold.
- Renounce upgrades. В какой-то момент команда официально лочит апгрейды (записывает нулевой адрес в admin slot).
- DAO-управляемый upgrade. Решение об апгрейде принимает голосование держателей governance-токена.
Контекст в TON
В TON proxy-pattern менее распространён, чем в Ethereum: TON-контракты часто проектируются с встроенной апгрейдабельностью на уровне кода (отдельный opcode для обновления). Однако крупные DeFi-протоколы (EVAA, Tonco) используют похожие паттерны с явным админ-ключом или DAO-контролем.