Rust Smart Contract 栽培日記 (11):スプートニクDAO提案メカニズムの分析

Sputnik-DAOはNEAR Protocolのインフラとして、NEARエコシステムの去中心化への発展を促進しています。現在、このプラットフォームは多くのNEARプロジェクトの自律コミュニティを促成しており、同時に完全で柔軟かつ効率的なコミュニティの意思決定ガバナンスソリューションを提供しています。

Sputnikdaov2はSputnik-DAOコミュニティのガバナンス投票に使用されるスマートコントラクトです。本記事では、この契約の核心概念である提案(Proposal)を紹介し、提案に基づいて関連するDAOコミュニティガバナンスモデル(Policy)について説明します。

1. 提案開始

Sputnik-DAOコミュニティの各メンバーは、プロジェクトのガバナンスや管理に関して意見を述べたり提案を提出したりすることができます。その後、DAO内で株を保有するコミュニティメンバーは、その提案を審議し投票することができます。言い換えれば、Sputnik-DAOにおける各メンバーは、他の人の提案に投票したり、自分自身で新しい管理提案を発起したりすることによってプロジェクトの将来の方向性に影響を与えることができます。

契約の観点から見ると、DAOコミュニティのメンバーはsputnikdaov2契約のadd_proposal()メソッドを呼び出して新しい提案を開始することができます。

この場合、提案者は提案の詳細(ProposalInput)を提供する必要があります。

• 提案の文字説明(Description)。この情報はSputnik-DAOのホームページのフロントエンドに公開表示され、コミュニティメンバーがこの提案の目的と意義を理解するのに役立ちます。

• 提案のタイプ(kind)。提案者はプロジェクト管理に対する意見のタイプに基づいて適切な選択を行う必要があります(。例えば、スマートコントラクトの重要な特権関数の呼び出しにはFunctionCallタイプを選択し、スマートコントラクトプロジェクトの資金の移転にはTransferタイプを選択する必要があります)。

これらのProposalInput情報は、add_proposal()メソッドにパラメータとして渡されます。このメソッドは関連する検証と処理を行い、完全な初期情報を持つ提案(Proposal)を生成します。最終的にこの提案は唯一のproposal_idにバインドされ、<key, value="">の形式でSputnik-DAOコントラクトが全体的に管理するContract.proposalsマッピングに(提案プール)として追加されます。

注意すべきは、Sputnik-DAOには提案押金(proposal_bond)の概念が存在し、この押金は具体的なSputnik-DAOコミュニティガバナンスモデル(Policy)に従って管理されるということです。契約は、提案者がadd_proposal()メソッドを呼び出す際に、新しい提案の保証金として一定量のNEARトークンをステークすることを要求します。この押金は、提案が正常に終了(し、コミュニティ投票で賛成または反対)された場合に、契約の内部関数internal_return_bonds()を呼び出すことで提案者に返還されます。

!

2. 提案状況

スプートニク-DAOの標準的な提案はどれも複数の状態を通過することができ(新しい提案の状態はInProgress)に初期化されます。

• InProgress: 投票が進行中です
• 承認済み:提案が通過しました
• 拒否された:提案が否決されました
• 削除されました:提案が移除されました
• 失敗:提案の実行に失敗しました
• 期限切れ: 提案の有効期限が切れています

提案プール内の提案の状態変化は、契約のact_proposal()メソッドによって駆動されます。Sputnik-DAOのメンバーは、特定の提案(に対してidを指定して)操作を実行するためにact_proposal()メソッドを呼び出すことができます。

InProgress状態にある提案について、DAOコミュニティメンバーはact_proposal()を呼び出して具体的な投票操作を実行できます:

• Action::VoteApprove: 投票承認
• Action::VoteReject: 反対のテーブル
• Action::VoteRemove:この提案には実際的な意義がないと考え、削除する必要があります。

実装に基づいて、内部でupdate_votes()関数を呼び出した後、プログラムは自動的にpolicy.proposal_status()を呼び出して投票作業を行います。投票閾値を満たす提案については、提案の状態が適切に変更されます。

後：

• 提案のステータスが [承認済み] の場合、提案は internal_execute_proposal() を呼び出して実行されます。
• プロポーザルが [却下] または [削除済み] の状態の場合、プロポーザルは呼び出されinternal_reject_proposal()後続の終了操作が実行されます。

值得一提的是、RejectedとRemoved状態の違いは、Removed状態に確定された提案は提案プールから直接削除され、当初質押されたデポジットは提案者に返還されないことです。一方、Rejected状態の提案は提案プールに残り、相応のデポジットが返還されます。

!

3. プロポーザルの実行

投票終了後に提案が承認済み状態の場合、コントラクト メソッドは引き続き内部で呼び出されますact_proposal() internal_execute_ proposal() 関数は、提案に含まれる決定を実行します。

Sputnik-DAOは、ChangeConfig、ChangePolicy、AddMemberToRole、RemoveMemberFromRole、FunctionCall、UpgradeSelf、UpgradeRemote、Transfer、SetStakingContract、AddBounty、 BountyDone、Vote、FactoryInfoUpdate、ChangePolicyAddOrUpdateRole、ChangePolicyRemoveRole、ChangePolicyUpdateDefaultVotePolicy、ChangePolicyUpdateParametersなど

以下重点紹介する2つの典型的な提案タイプの処理プロセス:

3.1 コントラクト関数実行の提案 (ProposalKind::FunctionCall)

FunctionCall型の提案は、提案者がadd_proposal()メソッドを呼び出す際に、ProposalInputパラメータを通じて具体的にこの提案が実行する関数操作(actions)を渡されました。NEARコントラクトは、1つのPromise内で複数の連続したfunction_callをバインドすることを許可します。したがって、最初の提案者が設定したactions内部には複数のActionCallオブジェクトが含まれる可能性があり、各ActionCallは対応するコントラクトメソッド名やメソッドパラメータなどを指定できます。

Sputnik-DAOは、Promise Batch Actionsという形でコントラクト機能実行型提案の実行を完了します。

3.2 契約資金移動提案書 (ProposalKind::Transfer)

NEARスマートコントラクトプロジェクトが一定期間運営されると、契約アカウント自体には多くのFungible Token(が蓄積されている可能性があります。これにはネイティブNEARトークンや、その他のNEP-141標準に準拠したトークン)が含まれます。

この時、Sputnik-DAOコミュニティのメンバーは、契約資金移転提案を提出することで、これらのトークンを指定されたreceiver_idアカウントに集めることができます。internal_execute_proposal()は、ProposalKindがTransferの提案に対しても対応する処理エントリを実装しています。

この処理ブランチの下層では、internal_payout()関数を呼び出し、異なるタイプのFungible Tokenおよび異なるタイプのreceiver_id(EOAまたはコントラクトアカウント)への送金操作を実現します。

!

4. まとめ

この記事では、Sputnik DAOのスマートコントラクトの核心概念である提案(Proposal)について紹介し、同時にSputnik DAO内で新しい提案を作成し、投票して実行する方法、および関連する提案の基本的な状態(Status)の変化ルールについて簡単に説明します。

! </key,>