На нашем первом сеансе обзора кода участник Mars @larry0x рассказал о предстоящем контракте Airdrop для новых токенов $MARS. В нем он обсудил дизайн контракта Airdrop, типы монет, доказательства меркла, а также функции и запросы контракта. На нашем втором сеансе @larry0x вернулся, чтобы рассказать о последних изменениях, внесенных в контракт Airdrop, и показать нам контракт «в действии». Наконец, он рассказывает о введении в договор вестинга. Мы рекомендуем пройти первую сессию обзора кода перед началом второй.
Эта статья послужит кратким обзором тем, которые обсуждались на второй сессии. Для более подробного анализа вы можете просмотреть записи:
Предыдущие разбивки проверки кода:
Изменения в контракте Airdrop
(Время записи: 0:20–4:40)
В нашем предыдущем сеансе мы описали clawbackфункцию в контракте Airdrop, которая может быть запущена после истечения периода подачи заявок для отправки невостребованных токенов airdrop в пул сообщества. С тех пор контракт был обновлен, чтобы больше не указывать дату истечения срока действия заявок на раздачу. Вместо этого clawbackфункция была зарезервирована для управления и срабатывает после успешного голосования. В этот момент оставшиеся токены $MARS будут отправлены в пул сообщества Mars.
Чтобы реализовать это изменение, claim_periodиз контракта был удален параметр InstantiateMsg:
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct InstantiateMsg {
pub merkle_root: String,
}
Кроме того, clawback ExecuteMsgбыл заменен на SudoMsg. SudoMsg похож на ExecuteMsg, но эти типы функций могут вызываться только модулями SDK, такими как модуль управления, а не пользователями или другими контрактами:
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum SudoMsg {
Clawback {},
}
Контракт Airdrop в действии
(Время записи: 4:40–44:10)
До сих пор на обеих сессиях мы говорили о структуре и дизайне контракта Airdrop, но еще не видели его в действии. В основе этого сеанса мы сосредоточимся на взаимодействии с развернутой версией контракта, чтобы проверить, работает ли контракт должным образом.
Процесс тестирования контракта Airdrop выглядит следующим образом:
1. Скомпилируйте код блокчейна. В этом разделе мы работаем с демоном marsd. marsdИнтерфейс командной строки (CLI) демона marsd ( ) запускает полный узел marsприложения (что позволяет нам напрямую запрашивать контракты и отправлять транзакции в сеть). Для компиляции marsdмы загружаем исходный код Mars Hub и проверяем последнюю стабильную версию:
git clone https://github.com/mars-protocol/hub
cd hub
git checkout <версия>
Команда для компиляции приложения определена в Makefile. Для большинства приложений Cosmos это make installсоздаст исполняемый файл в вашей $GOBINпапке:
сделать установку
Для получения дополнительной информации по этой теме посетите семинар @0xLarry по настройке узла Cosmos (и валидатора).
2. Инициализируйте состояние генезиса и начальные узлы . Файл genesis.json определяет состояние генезиса для всех космических модулей, таких как authмодуль, в котором хранятся все учетные записи, и bankмодуль, в котором хранятся балансы. Файл genesis.json также будет включать наш InstantiateMsg для нашего контракта Airdrop, который содержит доказательство Меркла, которое мы используем для проверки подписей. Для предстоящей основной сети и общедоступной тестовой сети файлы генезиса будут выпущены участниками Mars. Чтобы настроить локальную тестовую сеть, используйте следующую команду для создания пустого генезис-файла:
marsd init мое имя --chain-id my-testnet-1
Затем используйте marsd genesis add-wasm-messageподкоманду для добавления сообщений о развертывании контрактов. Бегите marsd genesis add-wasm-message — helpза подробностями.
3. Запустите цепочку. После того, как у нас будет файл genesis.json и мы настроим наш узел, мы можем запустить блокчейн:
Марсд Старт
Если мы начинаем видеть, что блоки создаются, мы успешно настроили marsdдемона и можем начать взаимодействовать с нашими развернутыми контрактами.
4. Запросите адрес контракта Airdrop. Прежде чем мы сможем взаимодействовать с контрактом Airdrop, мы должны получить адрес контракта. В нашем случае мы знаем, что идентификатор контракта равен 2, так как это второй контракт, который будет развернут в состоянии генезиса. С помощью этой информации мы можем найти соответствующий адрес:
marsd запрос wasm list-contracts 2
Получив адрес контракта, мы можем использовать интеллектуальный запрос для указания параметров wasm:
marsd query wasm contract-state smart <contract_address> smart '{<query>}'
5. Получите аирдроп. Здесь мы, наконец, можем взаимодействовать с нашим развернутым контрактом. Чтобы вызвать функцию претензии, нам нужны следующие параметры:
terra_acct_pk: Открытый ключ держателя токенов Mars Classic в шестнадцатеричном кодировании.mars_acct: адрес Mars, на который должны быть отправлены заявленные токены.amount: Количество заявленных токенов Marsproof: Доказательство{terra-acct}:{amount}существования листа в дереве Меркла в шестнадцатеричном кодировании .signature: Подпись, созданная путем подписания сообщенияairdrop for {terra-acct} of {amount} umars shall be released to {mars-acct}закрытым ключом учетной записи Terra в шестнадцатеричном кодировании.
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum ExecuteMsg {
Claim {
terra_acct_pk: String,
mars_acct: String,
сумма: Uint128,
доказательство: Vec< Строка>,
подпись: Строка,
},
}
На предыдущем занятии мы обсудили концепцию доказательства Меркла, которое позволяет нам загружать упрощенное представление «отпечатков пальцев» нашего набора данных распределения раздачи и проверять, является ли конкретная точка данных частью набора. Если мы знаем данные об аирдропе, мы можем сами сгенерировать доказательство. В этом сеансе мы рассмотрим некоторые вспомогательные модули, которые помогут нам построить само доказательство. Но в целом это работа для фронтенда веб-приложения.
6. Отправьте предложение активировать clawbackфункцию . Как описано в первом разделе этой статьи, мы заменили на clawback ExecuteMsgSudoMsg, который срабатывает при успешном голосовании управления. В этот момент оставшиеся токены $MARS будут отправлены в пул сообщества. В этом разделе мы отправляем предложение через демона marsd:
marsd tx gov submit-proposal sudo-contract <contract_address> '{"clawback":{}}' --deposit 1 1000000umars --gas auto --gas-adjustment 1.4 --gas-prices 0umars
Мы можем запросить модуль управления для получения дополнительной информации о нашем предложении:
marsd запрос gov предложение 1
7. Проголосуйте за наше clawbackпредложение . Теперь, когда наше предложение опубликовано, мы можем проголосовать:
marsd tx gov voice 1 yes --from myname --gas auto --gas-adjustment 1.4
Наконец, ничто не заменит увидеть контракт в действии, кроме самой записи. Теперь, когда вы знаете шаги, которые вы обычно ищете, вы можете следить за записью и заполнять важные детали.
Обзор договора вестинга
(Время записи: 39:15–50:13)
Контракт вестинга создается с помощью объекта, ownerкоторый может устанавливать позиции вестинга и график разблокировки. Это может быть конкретная внешняя учетная запись, мультиподпись, контролируемая командой разработчиков, или смарт-контракт DAO:
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct InstantiateMsg {
владелец паба: String,
pub unlock_schedule: Schedule,
}
В отличие от графика наделения (который персонализируется для каждого участника Mars), график разблокировки определяется при заключении контракта и одинаков для всех. Количество токенов $MARS, которое может вывести вкладчик, зависит как от графика наделения правами, так и от графика разблокировки (в зависимости от того, что меньше, за вычетом уже снятой суммы). Объект unlock_scheduleсостоит из 3 параметров:
start_time: Время начала наделения/разблокировкиcliff: время, предшествующее тому, что токен не будет передан/разблокированduration: продолжительность процесса наделения/разблокировки. В момент времениstart_time+durationтокены наделяются/разблокируются полностью
#[derive(Serialize, Deserialize, Copy, Clone, Debug, PartialEq, JsonSchema)]
pub struct Schedule {
pub start_time: u64,
pub patch: u64,
pub duration: u64,
}
Время окончания контракта определяется временем начала плюс продолжительность. Затем вознаграждения линейно инвестируются в течение этого периода времени, но не могут быть востребованы до окончания периода обрыва. На изображении ниже мы видим, что до периода обрыва никакие награды не могут быть получены. Как только период обрыва закончится, все награды, которые были бы линейно начислены до этого момента, могут быть запрошены сразу. Будущие вознаграждения будут продолжать начисляться линейно в соответствии с графиком наделения правами.
После создания экземпляра контракта владелец может создавать позиции для каждого вкладчика Mars, а по мере разблокировки токенов, наделенных полномочиями, вкладчики Mars могут вызывать withdrawфункцию для получения вознаграждения. Владелец также имеет исключительное право передавать право собственности на контракт, что обычно делается после создания всех позиций:
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum ExecuteMsg {
CreatePosition {
user: String,
vest_schedule: Schedule,
},
Withdraw {},
TransferOwnership( Строка),
}
Краткое примечание о запросах. На нашем последнем занятии мы обсуждали перечислительные запросы. Вместо отслеживания одного элемента мы перечисляем все элементы карты. Для договора вестинга мы реализуем это предложение для наших запросов VotingPowersи . PositionsВместо того, чтобы возвращать состояние одной учетной записи, запрос возвращает результаты с разбивкой на страницы:
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)] #[serde(rename_all = "snake_case")] pub enum QueryMsg { VotingPower { user: String, }, VotingPowers { start_after: Option<String>, limit : Опция <u32>, }, Позиция { пользователь: String, }, Positions { start_after: Option<String>, limit: Option<u32>, }, }
Наконец, важной особенностью договора вестинга является то, как определяется право голоса для закрепленных токенов. Для того, чтобы наделенные полномочиями токены могли участвовать в голосовании, нам пришлось внести некоторые изменения в модуль управления Cosmos SDK. Эта тема выходит за рамки этой сессии и станет предметом следующего обзора кода!
Что дальше
Разбивка третьего сеанса проверки кода будет доступна в ближайшее время. Четвертая сессия обзора кода будет посвящена пользовательской логике подсчета голосов управления. Слушайте, задавайте вопросы и помогайте выявлять ошибки в этой прямой видеотрансляции. Детали события:
- 30 июля 2022 г.
- 11:00 по восточному поясному времени | 15:00 по всемирному координированному времени
- http://Discord.gg/марспротокол
Имейте в виду, что все вышеперечисленное отражает текущее мышление Центра управления полетами, но не гарантируется и не обещается. Настоящим не подразумевается никаких договоров или обязательств. Не принимайте никаких финансовых решений на основании этого объявления.
- Управление полетами
🔴
Следите за новостями Mars в Твиттере и подписывайтесь на электронную рассылку новостей Mars, чтобы быть в курсе последних обновлений от Центра управления полетами.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ
Эта статья не является рекомендацией по инвестициям и полностью регулируется приведенными здесь заявлениями об отказе от ответственности Mars .