Щоденник розробки смарт-контрактів Rust (10-3): Основні поняття Sputnik DAO - пропозиція (Proposal) аналіз

Sputnik-DAO як інфраструктура, що надається NEAR Protocol, активно сприяє розвитку екосистеми NEAR у напрямку «децентралізації». Наразі ця платформа вже сприяла створенню безлічі «децентралізованих» автономних спільнот NEAR, а також надає повноцінні, гнучкі та ефективні рішення для управління рішеннями спільноти.

Sputnikdaov2 є смартконтрактом для голосування з управління в спільноті Sputnik-DAO. У цій статті буде представлено основні концепції цього контракту: пропозиція (Proposal), подальші статті будуть зосереджені на "пропозиції" та пов'язаних моделях управління спільнотою DAO (Policy).

1. Ініціювання пропозиції ( Додати пропозицію )

Кожен член спільноти Sputnik-DAO може висловлювати свої думки або подавати пропозиції щодо управління або адміністрування проекту. Потім кожен член спільноти, який має акції в DAO, може переглядати та голосувати за цю пропозицію. Іншими словами, кожен член Sputnik-DAO може впливати на майбутній розвиток проекту, голосуючи за пропозиції інших або ініціюючи нові пропозиції щодо управління.

На рівні контракту, учасники спільноти DAO можуть викликати метод add_proposal(), наданий контрактом sputnikdaov2, для ініціювання нової пропозиції.

іржа Паб Fn add_proposal(&mut self, пропозиція: ProposalInput) -> U64

Автори пропозиції повинні надати детальну інформацію про цю пропозицію ( ProposalInput ):

• Текстове описання пропозиції (Description). Ця інформація буде публічно відображена на фронтенді домашньої сторінки Sputnik-DAO, щоб допомогти членам спільноти зрозуміти мету та значення пропозиції.

• Тип пропозиції ( kind ). Пропонент повинен вибрати тип відповідно до висловлених думок щодо управління проектом (, наприклад, якщо потрібно викликати критичні функції контракту, виберіть тип FunctionCall, якщо потрібно здійснити переказ коштів проекту, виберіть тип Transfer, якщо потрібно налаштувати/змінити рівень контролю повноважень управління контрактом, виберіть тип ChangePolicyAddOrUpdateRole тощо ).

Ця інформація ProposalInput буде передаватися як параметри в метод add_proposal(), який буде далі виконувати відповідні перевірки та обробку, і генерувати пропозицію з повною інформацією про ініціалізацію (Proposal). Врешті-решт, ця пропозиція буде прив'язана до єдиного proposal_id та буде додана в мапу Contract.proposals, що підтримується глобально в контракті Sputnik-DAO у формі <key, value=""> в пул пропозицій (.

Пропозиції, визначені Sputnik-DAO, мають таку повну інформацію про атрибути:

іржа pub struct Proposal { Ідентифікатор публікації: U64, ініціатор pub: AccountId, pub опис: Рядок, вид пабу: ProposalKind, статус пабу: ProposalStatus, vote_period_end пабу: BlockHeight, pub vote_counts: HashMap<політика голосування, HashMap<ідентифікатор рахунку,="" баланс=""}}> pub голосує: HashMap<accountid, vote="">, pub submission_time: Позначка часу, }

У цій пропозиції вміст атрибутів description та kind буде витягнуто з інформації ProposalInput, наданої proposer під час створення пропозиції. Конкретно, цей смартконтракт реалізує перетворення типу ProposalInput в Proposal за допомогою трейтів From на мові Rust.

Цей процес перетворення пов'язаний з більшою кількістю інформації про статус пропозицій:

• У нових доданих пропозиціях атрибут пропозиціонера )proposer( буде автоматично присвоєний виклику методу add_proposal)(, тобто env::predecessor_account_id)(, цей атрибут є реальним і не підлягає контролю з боку користувача;

• Новий доданий статус пропозиції )status( за замовчуванням ініціалізовано як ProposalStatus::InProgress, тобто ще перебуває на етапі голосування;

• Новий час ініціювання пропозиції )submission_time( було присвоєно відмітці часу цього блоку env::block_timestamp)(;

• Оскільки на момент подання нової пропозиції ніхто не голосував, тому статус голосування )vote_counts, votes( обидва ініціалізуються як пусті HashMap::default)(.

Потрібно звернути увагу на те, що в Sputnik-DAO існує концепція депозиту пропозицій )proposal_bond(, який буде управлятися відповідно до конкретної моделі управління спільнотою Sputnik-DAO )Policy(.

Читаючи відповідний код, можна зрозуміти, що контракт вимагає від пропонента внести певну кількість токенів NEAR як заставу для нової пропозиції під час виклику методу add_proposal)(. Ця застава буде повернута пропоненту через виклик внутрішньої функції контракту internal_return_bonds)( після завершення голосування в спільноті ProposalStatus::Approved | голосування в спільноті ProposalStatus::Rejected).

Проте, BlockSec раніше виявив під час інтерпретації коду контракту, що:

Sputnik-DAO не веде окремий облік історичних сум депозитів пропозицій для кожного користувача при обробці депозитів пропозицій. Коли користувач ініціює транзакцію, викликаючи метод контракту add_proposal() для додавання нової пропозиції, він може додати до цієї транзакції суму, що перевищує policy.bounty_bond токени NEAR, визначені управлінською політикою цього DAO (Policy). Це призведе до надмірної частини депозиту, яка не буде повернена пропоненту під час виконання наступної функції internal_return_bonds.

Після своєчасного зв'язку команди BlockSec з проектом, зрештою, це питання (160 було виправлено.

Більше перевірок та стратегій обробки, пов'язаних із пропозиціями, виконуваними всередині Sputnik-DAO, буде детально описано в наступному випуску "Щоденник розвитку Rust смартконтрактів )10-4#158被确认并及时在PR# Sputnik DAO::Аналіз моделі управління спільнотою".

2. Статус пропозиції ( Proposal Status )

Будь-яка стандартна пропозиція в Sputnik-DAO може пройти через такі кілька станів ( новий стан пропозиції ініціалізується як: InProgress )

іржа pub enum ProposalStatus { В процесі, Схвалено, Відхилено, Видалено, Прострочено, Переміщено, Не вдалося, }

Зміна стану пропозицій у пулі пропозицій керується іншим методом контракту act_proposal().

Члени Sputnik-DAO можуть викликати метод act_proposal() для конкретної пропозиції (, вказуючи id ), щоб виконати такі дії:

іржа pub enum Action { ДодатиПропозицію, ВидалитиПропозицію, Голосуйте, VoteReject, ГолосуватиВидалити, Завершити, MoveToHub, }

Типово, для пропозицій у стані InProgress члени спільноти DAO можуть викликати act_proposal() для виконання конкретних голосувань:

• Action::VoteApprove:голосувати "за";
• Action::VoteReject:висловити незгоду;
• Action::VoteRemove: вважає, що ця пропозиція не має практичного значення, потрібно видалити;

Згідно з вищезазначеним впровадженням, після внутрішнього виклику функції update_votes() програма активно викликатиме policy.proposal_status() для проведення голосування. Для пропозицій, що відповідають порогу голосування, статус пропозиції буде відповідно змінено.

Зміни після:

• Якщо статус пропозиції Approved, то ця пропозиція буде виконана шляхом виклику internal_execute_proposal();

• Якщо статус пропозиції є Rejected або Removed, то ця пропозиція буде завершена шляхом виклику internal_reject_proposal().

Варто зазначити, що статуси Rejected і Removed відрізняються тим, що остаточно визначені як статус Removed пропозиції будуть безпосередньо видалені з пулу пропозицій, ( як покарання ) не буде повернено первісно внесена застава пропозиціонеру. Що стосується пропозицій зі статусом Rejected, ці пропозиції залишаться в пулі пропозицій і відповідна застава буде повернена.

!

3. Виконання пропозиції ( Виконати пропозицію )

Якщо статус певної пропозиції після завершення голосування відповідає Approved, у цей момент метод контракту act_proposal() внутрішньо продовжить викликати функцію internal_execute_proposal() для виконання рішень, що містяться в пропозиції.

Типи пропозицій, підтримувані Sputnik-DAO, перераховані нижче ( Більшість типів пропозицій стосується оновлення конфігурації моделі управління DAO ):

• ProposalKind::ЗмінаКонфігурації
• ProposalKind::ChangePolicy
• ProposalKind::ДодатиЧленаДоРолі
• ProposalKind::ВидалитиЧленаЗРолі
• ProposalKind::FunctionCall
• ProposalKind::UpgradeSelf
• ProposalKind::UpgradeRemote
• ПропозиціяКінд::Переказ
• ProposalKind::SetStakingContract
• ProposalKind::ДодатиНагороду
• ProposalKind::BountyDone
• ProposalKind::Голосування
• ProposalKind::FactoryInfoUpdate
• ProposalKind::ЗмінаПолітикиДодаванняАбоОновленняРолі
• ProposalKind::ChangePolicyRemoveRole
• ProposalKind::ЗмінаПолітикиОновленняТиповогоГолосування
• ProposalKind::ЗмінитиПолітикуОновленняПараметрів

Кожен з типів пропозицій вище реалізує відповідну обробку в функції internal_execute_proposal(). У цьому розділі ми детально ознайомимо вас з двома типовими процесами обробки пропозицій:

• ProposalKind::FunctionCall
• ПропозиціяКінд::Переказ

( 3.1 Виконання функції контракту Пропозиція виконання ) ProposalKind::FunctionCall ###

Функція internal_execute_proposal() реалізує наступну точку входу для обробки пропозицій, де ProposalKind є FunctionCall:

іржа ProposalKind::FunctionCall { receiver_id, дії } => { let mut promise = Promise::new(receiver_id.clone019283746574839201)928374656574839201; для дії в actions { обіцянка = promise.function_call( action.method_name, action.args, action.deposit, action.gas, ( } promise.into019283746574839201) }

Пропозиції типу FunctionCall були передані через параметр ProposalInput у момент, коли ініціатор викликав метод add_proposal)(, що конкретно визначає функціональні дії, які має виконати ця пропозиція )actions(.

Контракт NEAR дозволяє в одному Promise зв'язувати кілька послідовних function_call. Тому в межах actions, визначених початковим пропозицією, можуть бути такі різні об'єкти ActionCall:

іржа pub struct ActionCall { pub method_name: Рядок, арги пабів: Vec, pub deposit: Баланс, газ для пабу: Газ, }

Кожен ActionCall може вказувати відповідну назву методу контракту, а також параметри методу тощо.

Отже, Sputnik-DAO реалізував виконання пропозицій типу виконання функцій контракту у формі Promise Batch Actions.

! [])https://img-cdn.gateio.im/webp-social/moments-427716593b21fa32b47855ceb5e101fc.webp(

) 3.2 Виконання пропозиції щодо переведення коштів за контрактом (ProposalKind::Transfer)

Коли розгорнутий проект смартконтрактів NEAR функціонує протягом тривалого часу, сам рахунок контракту може накопичити значну кількість Fungible Token(, включаючи рідні токени NEAR або інші токени, що відповідають стандарту NEP-141).

У цей час члени спільноти Sputnik-DAO можуть згрупувати ці токени на зазначений рахунок receiver_id, подавши пропозицію про переміщення коштів зі смартконтракту.

Той же internal_execute_proposal###( реалізує відповідний обробний вхід для пропозицій, де ProposalKind дорівнює Transfer:

іржа ProposalKind::Transfer { token_id, receiver_id, сума } => { self.internal_payout)token_id, receiver_id, amount( .into)( }

Ця обробка гілки на нижньому рівні викликатиме функцію internal_payout)( для виконання операцій переказу для різних типів Fungible Token та різних типів receiver_id)EOA або контрактних рахунків(.

! [])https://img-cdn.gateio.im/webp-social/moments-ef0b959c42e1f5fc6263cd4a86fd078e.webp(

4. Підсумок та прогноз

У цій статті ми представили основні концепції смартконтракту Sputnik DAO — пропозицію )Proposal(, а також коротко пояснили, як створювати нові пропозиції в Sputnik DAO та голосувати за їх виконання, а також правила зміни основного статусу пропозицій )Status(.

Наступні щоденники з вирощування смартконтрактів Rust будуть ґрунтуватися на реалізації та налаштуванні моделі управління в Sputnik-DAO відповідно до пропозиції )Policy(, чекайте з нетерпінням!

! [])https://img-cdn.gateio.im/webp-social/moments-eb73d5e15f6161f0a4b442cd4b99a91e.webp(</accountid,></votepolicy,></key,>