Необычное использование прокси

В еще одном конкурсном аудите обнаружил для себя необычный подход к использованию прокси контрактов, которое немного перевернуло мое представление об этом паттерне.

Смотрите, в обычной реализации мы делаем как? Мы пишем прокси контракт, а затем добавляем к нему контракт Логики. Все данные хранятся в прокси, а Логику мы можем менять хоть каждый день.

В проекте Sparkn по-другому.

P.S. Репо, возможно, будет открыто только на время конкурса.

Здесь три контракта: proxy, distributor и proxyFactory.

Proxy - самая простая реализация прокси паттерна с одной лишь fallback функцией.

Distributor - контракт Логики для прокси с разными функциями, основная из которых это перечисление средств пользователям.

ProxyFactory - основной контракт для взаимодействия.

Смотрите, что получается. Контракты proxyFactory и distributor постоянные. Т.е. distributor хоть и является контрактом Логики для прокси, но в данном случае он не обновляемый, так как функционал для этого не заложен.

В proxyFactor есть функция для деплоя прокси контракта и определения его адреса наперед, основываясь на определенных параметрах, в том числе на адресе пользователя.

Итак, суть в том, что пользователь может заранее вычислить свой адрес прокси и отправить туда некоторую сумму для распределения пользователям. Затем он вызывает функцию деплоя proxy, сразу после чего идет туда вызов и с помощью delegatecall вызывается функция из distributor, которая делает рассылку активов для установленных пользователей.

Другими словами, каждый взятый пользователь может сделать деплой прокси, на котором будут лежать токены, и уже с него через фиксированный контракт distributor сделать рассылку.

Два контракта постоянных, и неограниченное количество индивидуальных контрактов для пользователей.

На мой взгляд сделано очень круто!

#proxy