Руководство Airdrop Claiming
В этой статье мы рассмотрим вымышленное решение для клейма, попытаемся выявить его проблемы с производительностью и решить их. Мы сосредоточимся на взаимодействии контрактов и их влиянии на общую производительность и не будем затрагивать код, аспекты безопасности и другие нюансы.
Claim Machine
Как работает практически любое решение для клейма? Давайте подумаем.
Пользователь отправляет некое доказательство, пруф того, что он имеет право на клейм. Разработанны й алгоритм решения осуществляет проверку доказательства и при ее успешности отправляет жетоны. В данном случае используется доказательство Меркла, но это вполне могут быть просто подписанные данные или любой другой метод авторизации. Отправка жетонов осуществляется с помощью Jetton wallet и Jetton minter. Также, нужно убедиться, что хитрые пользователи не смогут клеймить дважды – для этого необходим контракт с защитой от двойного списания. И, наверное, заработать немного денег, не так ли? Значит потребуется, по меньшей мере, один кошелек для клейма. Подведем итог:
Дистрибьютор
Принимает доказательство от пользователя, проверяет его, выпускает жетоны.
State init: (merkle_root, admin, fee_wallet_address)
.
Двойное списание
Получает входящее сообщение, возвращает отказ в случае попытки повторного использования. Если проверка пройдена, передает сообщение дальше
Jetton wallet
Jetton wallet, с которого токены будут отправлены дистрибьютором. Jetton minter выходит за рамки этой статьи.
Кошелек для комиссии
Любой тип контракта кошелька.
Архитектура
V1
Один из возможных вариантов реализации:
- Пользователь отправляет доказательство дистрибьютору
- Дистрибьютор проверяет доказательство и разворачивает смарт-контракт
двойного списания
- Дистрибьютор передает сообщение контракту двойного списания
- Контракт двойного списания отправляет
claim_ok
дистрибьютору, если он не был развернут ранее - Дистрибьютор отправляет комиссию за клейм на кошелек для оплаты комиссии
- Дистрибьютор отпускает жетоны пользователю
Что здесь не так? Похоже, что цикл избыточен.
V2
Линейная структура намного лучше:
- Пользователь разворачивает контракт
двойного списания
, который в свою очередь передает доказательство дистрибьютору - Дистрибьютор проверяет адрес отправки смарт-контракта
двойного списания
по state init(distributor_address, user_address?)
- Дистрибьютор проверяет доказательство и выпускает жетоны. В данном случае индекс пользователя должен быть частью доказательства.
- Дистрибьютор отправляет комиссию на кошелек для оплаты комиссии