Атаки на прокси в этом году замыкают TOP 10 OWASP, при этом являясь новинкой сезона. Какие-то уязвимости попроще, например использование коллизии storage, какие-то достаточно изощренные, как CPIMP, про который я писал ранее
В любом случае, для дальнейшего разбора хорошо иметь обзорный пост про виды прокси, без глубокого погружения в то, как именно они функционируют
Смарт-контракты по своей природе неизменяемы, поэтому их код нельзя обновить после деплоя. Прокси позволяют обойти это ограничение, давая возможность обновлять логику, сохраняя при этом тот же адрес контракта и все накопленные данные. Они работают за счет разделения контракта на две части: хранилище/прокси (Storage/Proxy Contract) и логику/имплементацию (Implementation/Logic Contract)
Существуют 5 видов прокси-схем:
1) Clones/Minimal Proxy, они же ERC-1167. Самая минималистичная и простая версия прокси. Необновляемые контракты, где адрес имплементации вшит в байткод контракта, а еще вшита логика DELEGATECALL и возврат результата. И это в общем-то всё содержимое клона, 45 байт совершенства. Стандарт существует в виде библиотеки, суть в том, чтобы выпускать множество клонов контрактом Фабрикой (Factory). Пользователь -> клон -> имплементация
2) Transparent Proxy Pattern (TPP). Схема простая: пользователь отправляет запрос на прокси контракт, а тот делает переадресацию на текущую имплементацию. Здесь код последней на данный момент версии от OZ, существует в виде контракта. Рекомендуется делать так, чтобы владельцем прокси контракта был контракт ProxyAdmin, а не EOA. При каждом вызове прокси проверяет, является ли вызывающий админом, а это стоит 2100 газа. Администратор не имеет права вызывать бизнес-логику. Обновление имплементации контролируется прокси контрактом. Пользователь -> прокси -> имплементация
3) Universal Upgradeable Proxy Standard (UUPS). Ровно та же схема пользователь -> прокси -> имплементация, но функционал обновления имплементации находится в самой имплементации, отсутствие необходимости проверки администратора при каждом вызове экономит газ. Каждая новая имплементация обязана содержать функцию upgradeTo(). Стандарт существует в виде абстрактного контракта
4) Beacon Proxy. Пользователь обращается к своему beacon proxy, тот посылает запрос на Маяк (UpgradeableBeacon), который хранит адрес имплементации, то есть получается пользователь -> Beacon Proxy -> UpgradeableBeacon -> имплементация. Этот промежуточный Маяк позволяет обновлять адрес имплементации для множества пользователей одновременно
5) Diamond proxy. Стандарт EIP-2535. Единственный в списке без реализации от OpenZeppellin. Придуман как решение обхода ограничения размера контракта, по сути служит другим целям нежели остальные, является сложным и нишевым (как будто остальные просты). Суть в том, что прокси контракт перенаправляет вызовы в зависимости от приходящего селектора функции, то есть фактически один большой контракт разбивается на модули и увязывается с помощью прокси-оркестратора. Позволяет менять логику частично. В ноябре 2025 выходил гайд от QuickNode.
- Clones и Beacon используются для связи один ко многим
- Transparent и UUPS используются для связи один к одному
- Transparent и UUPS наследуются от ERC1967Proxy
- Beacon и ERC1967Proxy наследуется от Proxy
- Beacon при этом использует библиотеку ERC1967Utils, как и ERC1967Proxy
- Proxy просто кайфует
Стандарт EIP1967 отвечает за хранение адреса имплементации и другой прокси специфичной информации
Ставь лайк, если стало немного понятнее кто есть кто
https://t.me/web3securityresearch