Дневник разработки смарт-контрактов 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, для создания нового предложения.

ржавчина pub fn add_proposal(&mut self, предложение: ProposalInput) -> U64

Предложитель должен предоставить подробную информацию о предложении (ProposalInput):

• Текстовое описание предложения ( Описание ). Эта информация будет публично отображаться на фронтенде главной страницы Sputnik-DAO, чтобы помочь членам сообщества понять цели и значение предложения.

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

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

Предложения, определенные Sputnik-DAO, имеют следующую полную информацию о свойствах:

ржавчина pub struct Предложение { ID паба: U64, pub proposer: AccountId, pub описание: Строка, вид паба: ProposalKind, статус паба: ProposalStatus, паб vote_period_end: BlockHeight, pub vote_counts: HashMap<votepolicy, hashmap<accountid,="" balance="">>, Голоса паба: HashMap<accountid, vote="">, паб submission_time: Временная метка, }

В этом предложении содержание атрибутов description и kind будет извлечено из информации ProposalInput, предоставленной proposером при создании предложения. В частности, этот контракт использует реализацию трейта From языка Rust для преобразования типа ProposalInput в Proposal.

Этот процесс преобразования привязывает больше информации о состоянии предложений:

• В новом предложении атрибут предложителя )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() для добавления нового предложения, он может добавить к этой транзакции сумму, превышающую ту, что определена стратегией управления DAO (Policy), в виде токенов NEAR policy.bounty_bond. Это приведет к избыточной части депозита, которая не будет возвращена инициатору предложения во время выполнения последующей функции 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 { AddProposal, УдалитьПредложение, ПроголосоватьУтвердить, VoteReject, VoteRemove, Завершить, MoveToHub, }

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

• Действие::VoteApprove: ГолосуйтеОдобряйте;
• Действие::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::ChangeConfig
• ProposalKind::ChangePolicy
• ProposalKind::ДобавитьУчастникаВРоль
• ProposalKind::УдалитьЧленаИзРоли
• ProposalKind::FunctionCall
• ProposalKind::UpgradeSelf
• ProposalKind::UpgradeRemote
• ProposalKind::Перевод
• ProposalKind::УстановитьСтавочныйКонтракт
• ProposalKind::AddBounty
• ProposalKind::BountyDone
• ProposalKind::Голосование
• ProposalKind::FactoryInfoUpdate
• ProposalKind::ИзменениеПолитикиДобавитьИлиОбновитьРоль
• ProposalKind::ChangePolicyRemoveRole
• ProposalKind::ИзменитьПолитикуОбновленияПолитикиГолосованияПоУмолчанию
• ProposalKind::ИзменитьПараметрыОбновленияПолитики

Каждый из вышеуказанных типов предложений реализует соответствующую ветвь обработки в функции internal_execute_proposal(). В этом разделе мы подробно представим два типичных процесса обработки типов предложений:

• ProposalKind::FunctionCall
• ProposalKind::Перевод

( 3.1 Исполнение предложений функций смарт-контрактов)ProposalKind::FunctionCall###

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

ржавчина ProposalKind::FunctionCall { receiver_id, actions } => { let mut promise = Promise::new(receiver_id.clone)(928374656574839201; для действия в действиях { Обещание = promise.function_call( action.method_name, action.args, action.deposit, action.gas, ) } promise.into)( }

Предложения типа FunctionCall уже передали конкретную функцию, которую нужно выполнить )actions( через параметр ProposalInput в момент, когда инициатор вызвал метод add_proposal)(.

Контракты NEAR позволяют связывать несколько последовательных function_call в одном Promise. Поэтому внутри actions, установленных первоначальным инициатором, могут быть следующие объекты ActionCall:

ржавчина pub struct ActionCall { pub метод_имя: String, паб аргументы: 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,>