3 cпособа реализации смарт-контракта для вестинга
ℹ️Контракт вестинга — это контракт, который позволяет владельцам проектов выделять токены для своих пользователей, но заставляет самих пользователей брать токены из контракта вестинга. Такая операция называется «claim».
Чтобы заклеймить токены, пользователи должны доказать смарт-контракту, что они имеют на это право. Для этого владелец проекта должен создать какое-то условие для проверки, что конкретный пользователь действительно может претендовать на токены.
Есть три способа сделать это:
1️⃣Ончейн-решение — заполнить связку (адрес => uint256), которая вернет сумму uint256, на которую может клеймить пользователь с определенным адресом.
Плюсы:
🔸Простота. Это очень легко реализовать.
🔸Все хранится в сети, поэтому прозрачность и безопасность немного выше.
Минусы:
🔸VestTokensMany не оптимизирован для большого количества данных (например, 1000 адресов). Инициализация большого количества адресов может стоить до $10000 в цепочке Ethereum.
🔸Отсутствие прозрачности: Если объем данных велик и мы не можем инициализировать отображение с одной транзакции, это означает, что мы всегда можем изменить суммы/адреса, и это непрозрачно для пользователей.
2️⃣Решение с оптимизированным газом — использовать корневой хэш дерева Меркла в качестве хранилища (сжатое поле bytes32) и предоставлять доказательство того, что адрес содержится в хэшированной переменной bytes32 каждый раз, когда пользователь пытается заклеймить.
Плюсы:
🔸Быстрая скорость: сложность составляет O(1) для vestTokens, O(logN) для claimTokens, где N - количество vested адресов.
🔸Безопасность: Корневые деревья Меркла можно использовать с кошельком с несколькими подписями, и это будет означать высокую безопасность, как и в случае с решением on-chain.
🔸Быстрое аннулирование наделенных сумм и адресов. Чтобы изменить наделенные правами адреса или суммы, мы можем легко изменить только одно поле (в отличие от итерации всех ключей в связке).
🔸Децентрализация / прозрачность — мы можем запретить изменять адреса/суммы если захотим.
Минусы:
🔸 Это потребует хранения где-то вне чейна.
🔸Обычно пользователям сложнее клеймить со смарт-контракта напрямую.
3️⃣Еще одно решение вне сети — использовать подписи владельца, чтобы контракт мог убедиться в легитимности клейма. Сообщения типа "Address 0x....11 can claim 100 tokens" будут подписаны закрытым ключом владельца, и контракт сможет проверить это, если и подпись, и сообщение будут предоставлены пользователем во время клейма.
Плюсы:
🔸Не нужно тратить свои средства для инициализации контракта, это делают только юзеры, и они платят только за свою запись в мэппинге.
Минусы:
🔸Подписи могут быть использованы пользователем многократно (это можно решить костылями)
🔸Централизация. Для создания подписи нужен закрытый ключ, которым будет владеть один человек. Gnosis safe здесь не поможет (даже если бы в нем был реализован EIP 1271), потому что подпись в конце концов производится одним закрытым ключом одного человека. Если он будет украден, то хакер сможет сгенерировать любую подпись, какую захочет, и забрать все токены.
🔸Все подписи существуют вне цепи. Владелец может создать больше подписей и слить вес баланс контракта.
Резюме
Merkle Trees кажется наиболее хорошим способом. Он имеют низкую вычислительную сложность, высокую степень децентрализации, простоту аннулирования данных, прозрачность для пользователей, низкие риски безопасности и может содержать большое количество адресов. Единственный случай, когда он не применим: у вас ограниченное время разработки или набор скилов в проекте, и вы не хотите заморачиваться, потому что количество адресов юзеров небольшое.
На картинке к посту таблица со сравнением всех способов.
