Journal de développement des smart contracts Rust (10-3) : Concepts clés du Sputnik DAO - Proposition ( Analyse
Sputnik-DAO, en tant qu'infrastructure fournie par le protocole NEAR, contribue de manière significative à l'évolution de l'écosystème NEAR vers une direction "décentralisée". Actuellement, cette plateforme a facilité la création de nombreuses communautés autonomes "décentralisées" pour les projets NEAR, tout en offrant des solutions complètes, flexibles et efficaces pour la gouvernance des décisions communautaires.
Le Sputnikdaov2 est un smart contract utilisé pour le vote de gouvernance de la communauté Sputnik-DAO. Cet article présentera les concepts clés de ce contrat : la proposition )Proposal(, des articles ultérieurs aborderont les modes de gouvernance de la communauté DAO liés à "la proposition" )Policy(.
1. Lancement de la proposition ) Ajouter une proposition (
Chaque membre de la communauté Sputnik-DAO peut exprimer son opinion ou soumettre une proposition concernant la gouvernance ou la gestion du projet. Ensuite, chaque membre de la communauté détenant des actions dans le DAO peut examiner et voter sur cette proposition. En d'autres termes, chaque membre de Sputnik-DAO peut influencer l'avenir du projet en votant sur les propositions des autres ou en initiant de nouvelles propositions de gestion.
Au niveau des contrats, les membres de la communauté DAO peuvent appeler la méthode add_proposal)( fournie par le contrat sputnikdaov2 pour soumettre une nouvelle proposition.
rouille
u64
Le proposeur doit fournir des détails sur la proposition )ProposalInput(:
Texte de la proposition )Description(. Cette information sera affichée publiquement sur l'interface de la page d'accueil de Sputnik-DAO, aidant les membres de la communauté à comprendre l'objectif et la signification de la proposition.
Type de proposition )kind(. Le proposeur doit choisir en fonction du type d'opinion sur la gestion de projet ) par exemple, si l'appel de fonction de privilège clé du contrat est nécessaire, il faut choisir le type FunctionCall, si le transfert de fonds du projet de contrat est nécessaire, il faut choisir le type Transfer, si la configuration/changement du niveau de contrôle de l'autorité de gouvernance du contrat est nécessaire, il faut choisir le type ChangePolicyAddOrUpdateRole, etc. (
Ces informations ProposalInput seront passées en tant que paramètres à la méthode add_proposal)(, qui effectuera des vérifications et un traitement supplémentaires, et générera une proposition avec des informations d'initialisation complètes )Proposal(. En fin de compte, cette proposition sera liée à un unique proposal_id et sera ajoutée sous la forme <key, value=""> dans la carte Contract.proposals, maintenue globalement par le contrat Sputnik-DAO, au sein de la piscine de propositions ).
Les propositions définies par le Sputnik-DAO possèdent les informations complètes suivantes :
Dans cette proposition, les contenus des attributs description et kind seront extraits des informations ProposalInput fournies par le proposeur lors de la création de la proposition. Plus précisément, ce contrat utilise le trait From en Rust pour réaliser la conversion de type de ProposalInput en Proposal.
Ce processus de conversion est lié à plus d'informations sur l'état des propositions :
Le champ "proposer" du proposeur dans la proposition nouvellement ajoutée ( sera automatiquement attribué à l'appelant de la méthode add_proposal)(, c'est-à-dire env::predecessor_account_id)(, ce champ est réel et n'est pas sous le contrôle de l'utilisateur;
Le nouvel état de proposition )status( est initialisé par défaut à ProposalStatus::InProgress, c'est-à-dire qu'il est encore en phase de vote;
Le temps de soumission de la proposition nouvellement ajoutée )submission_time( est défini comme l'horodatage de ce bloc env::block_timestamp)(;
En raison de l'absence de votes lors de la soumission de la nouvelle proposition, l'état de vote )vote_counts, votes( est initialisé comme un HashMap::default)(.
Il est important de noter qu'il existe dans le Sputnik-DAO le concept de dépôt de proposition )proposal_bond(, ce dépôt sera géré selon le mode de gouvernance communautaire spécifique du Sputnik-DAO )Policy(.
La lecture du code pertinent révèle que le contrat exige que le proposeur mise un certain montant de tokens NEAR en tant que garantie pour la nouvelle proposition lors de l'appel de la méthode add_proposal)(. Ce dépôt sera remboursé au proposeur en appelant la fonction interne du contrat internal_return_bonds)( lorsque le vote de la communauté sur la proposition se termine normalement) avec un vote favorable ProposalStatus::Approved | un vote défavorable ProposalStatus::Rejected(.
Cependant, BlockSec a précédemment découvert en interprétant le code de contrat à cet endroit :
Sputnik-DAO ne maintient pas l'historique des montants de dépôt de proposition pour chaque utilisateur lors du traitement des dépôts de propositions. Lorsque l'utilisateur initie une transaction en appelant la méthode de contrat add_proposal)( pour ajouter une nouvelle proposition, il est possible d'ajouter à cette transaction un montant supérieur au montant de policy.bounty_bond en NEAR défini par la stratégie de gouvernance de ce DAO )Policy(. Cela entraînera un dépôt excédentaire qui ne sera pas remboursé au proposant lors de l'exécution de la fonction interne internal_return_bonds.
Après que l'équipe de BlockSec a pris contact avec le projet en temps utile, le problème )160 a finalement été corrigé.
Plus de stratégies de vérification et de traitement des propositions exécutées par Sputnik-DAO seront détaillées dans le prochain "Journal de développement des smart contracts Rust (10-4) Analyse du modèle de gouvernance communautaire de Sputnik DAO".
2. Statut de la proposition ( Proposal Status )
Toute proposition standard dans le Sputnik-DAO pourrait passer par plusieurs états différents #158被确认并及时在PR# le nouvel état de la proposition est initialisé comme : InProgress (
Le changement d'état des propositions dans le pool de propositions est piloté par une autre méthode du contrat act_proposal)(.
Les membres de Sputnik-DAO peuvent appeler la méthode act_proposal)( pour exécuter les opérations suivantes sur la proposition spécifique ) en spécifiant l'id ( :
Typiquement, pour les propositions en état InProgress, les membres de la communauté DAO peuvent appeler act_proposal)( pour effectuer des opérations de vote spécifiques:
Action::VoteApprove:表赞成;
Action::VoteReject:表反对;
Action::VoteRemove: considère que cette proposition n'a pas de sens pratique, doit être supprimée;
Selon la mise en œuvre ci-dessus, après l'appel interne de la fonction update_votes)(, le programme appellera activement policy.proposal_status)( pour le travail de vote. Pour les propositions qui satisfont le seuil de vote, l'état de la proposition sera modifié en conséquence.
Changement après :
Si l'état de la proposition est Approuvé, alors la proposition sera exécutée en appelant internal_execute_proposal)(;
Si l'état de la proposition est Rejeté ou Retiré, la proposition effectuera des opérations de clôture ultérieures en appelant internal_reject_proposal)(.
Il convient de noter que la différence entre les états Rejected et Removed est la suivante : les propositions finalement déterminées comme étant dans l'état Removed seront directement supprimées du pool de propositions, ) comme pénalité ( ne remboursera pas le dépôt initialement misé au propositaire. En revanche, pour les propositions dans l'état Rejected, celles-ci resteront dans le pool de propositions et le dépôt correspondant sera remboursé.
3. Exécution de la proposition ) Execute Proposal (
Si une proposition est approuvée à la fin du vote, la méthode de contrat act_proposal)( continuera d'appeler la fonction internal_execute_proposal)( pour exécuter le contenu décisionnel inclus dans la proposition.
Les types de propositions soutenues par Sputnik-DAO sont énumérés ci-dessous ) La plupart des types de propositions concernent la mise à jour de la configuration du modèle de gouvernance DAO ( :
ProposalKind::ChangeConfig
ProposalKind::ChangePolicy
ProposalKind::AddMemberToRole
ProposalKind::RemoveMemberFromRole
ProposalKind::FunctionCall
ProposalKind::UpgradeSelf
ProposalKind::UpgradeRemote
ProposalKind::Transfer
ProposalKind::SetStakingContract
ProposalKind::AddBounty
ProposalKind::BountyDone
ProposalKind::Vote
ProposalKind::FactoryInfoUpdate
ProposalKind::ChangePolicyAddOrUpdateRole
ProposalKind::ChangePolicyRemoveRole
ProposalKind::ChangePolicyUpdateDefaultVotePolicy
ProposalKind::ChangePolicyUpdateParameters
Chaque type de proposition ci-dessus a mis en œuvre une branche de traitement correspondante dans la fonction internal_execute_proposal)(.
Cette section présentera en profondeur deux types typiques de processus de traitement des propositions :
ProposalKind::FunctionCall
ProposalKind::Transfer
) 3.1 Exécution de la fonction du contrat Proposition d'exécution(ProposalKind::FunctionCall)
La fonction internal_execute_proposal() a implémenté le point d'entrée suivant pour traiter les propositions dont le ProposalKind est FunctionCall :
rouille
ProposalKind::FunctionCall { receiver_id, actions } => {
let mut promise = Promise::new###receiver_id.clone()(;
pour action dans actions {
promise = promise.function_call)
action.method_name,
action.args,
action.deposit,
action.gas,
(
}
promise.into()
}
Le type de proposition FunctionCall est déjà passé par le paramètre ProposalInput lorsque le proposeur appelle la méthode add_proposal)(, spécifiant ainsi les opérations de fonction à exécuter )actions(.
Le contrat NEAR permet de lier plusieurs appels de fonction consécutifs dans une seule promesse. Ainsi, les objets ActionCall suivants peuvent être présents à l'intérieur des actions définies par le proposeur initial :
) 3.2 Exécution de la proposition de transfert de fonds de contrat ( ProposalKind::Transfer )
Lorsque le projet de smart contracts NEAR déployé et mis en ligne fonctionne pendant une longue période, le compte du contrat lui-même peut avoir accumulé un nombre important de Fungible Token(, y compris le jeton natif NEAR ou d'autres jetons conformes à la norme NEP-141).
À ce moment-là, les membres de la communauté Sputnik-DAO peuvent regrouper ces jetons dans le compte receiver_id spécifié en soumettant une proposition de transfert de fonds du contrat.
Le même internal_execute_proposal###( met également en œuvre un point d'entrée de traitement correspondant pour les propositions dont le ProposalKind est Transfer :
La branche de traitement sous-jacente appellera la fonction internal_payout)(, permettant d'effectuer des opérations de transfert pour différents types de Fungible Token ainsi que pour différents types de receiver_id) EOA ou comptes de contrats(.
Cet article a présenté le concept central du contrat Sputnik DAO - la proposition )Proposal(, tout en expliquant brièvement comment créer de nouvelles propositions et voter pour leur exécution dans le Sputnik DAO, ainsi que les règles de variation de l'état de base des propositions )Status(.
Le journal de développement des smart contracts Rust à venir fournira une description plus détaillée de la mise en œuvre et de la configuration du modèle de gouvernance dans Sputnik-DAO basé sur la proposition )Policy(, restez à l'écoute!
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
6
Reposter
Partager
Commentaire
0/400
GraphGuru
· 08-12 20:42
Bull, encore en train de travailler sur le mécanisme de propositions.
Voir l'originalRépondre0
HashBrownies
· 08-12 19:04
Ce contrat est vraiment difficile à gérer...
Voir l'originalRépondre0
AirdropHunter007
· 08-12 19:04
near j'ai compris cette question
Voir l'originalRépondre0
TokenTaxonomist
· 08-12 19:01
hum... d'un point de vue statistique, le mécanisme de proposition de sputnik présente une entropie inférieure de 47,3 % par rapport aux cadres de dao optimaux. j'ai cartographié l'ensemble de l'arbre taxonomique dans ma feuille de calcul
Voir l'originalRépondre0
BTCBeliefStation
· 08-12 18:59
Les joueurs de dao ne peuvent vraiment plus supporter.
Voir l'originalRépondre0
BrokenYield
· 08-12 18:55
un autre dao ne résoudra pas les risques systémiques... j'ai déjà vu ce film auparavant smh
NEAR écosystème nouveau chapitre : analyse approfondie du mécanisme de proposition du Sputnik DAO
Journal de développement des smart contracts Rust (10-3) : Concepts clés du Sputnik DAO - Proposition ( Analyse
Sputnik-DAO, en tant qu'infrastructure fournie par le protocole NEAR, contribue de manière significative à l'évolution de l'écosystème NEAR vers une direction "décentralisée". Actuellement, cette plateforme a facilité la création de nombreuses communautés autonomes "décentralisées" pour les projets NEAR, tout en offrant des solutions complètes, flexibles et efficaces pour la gouvernance des décisions communautaires.
Le Sputnikdaov2 est un smart contract utilisé pour le vote de gouvernance de la communauté Sputnik-DAO. Cet article présentera les concepts clés de ce contrat : la proposition )Proposal(, des articles ultérieurs aborderont les modes de gouvernance de la communauté DAO liés à "la proposition" )Policy(.
1. Lancement de la proposition ) Ajouter une proposition (
Chaque membre de la communauté Sputnik-DAO peut exprimer son opinion ou soumettre une proposition concernant la gouvernance ou la gestion du projet. Ensuite, chaque membre de la communauté détenant des actions dans le DAO peut examiner et voter sur cette proposition. En d'autres termes, chaque membre de Sputnik-DAO peut influencer l'avenir du projet en votant sur les propositions des autres ou en initiant de nouvelles propositions de gestion.
Au niveau des contrats, les membres de la communauté DAO peuvent appeler la méthode add_proposal)( fournie par le contrat sputnikdaov2 pour soumettre une nouvelle proposition.
rouille u64
Le proposeur doit fournir des détails sur la proposition )ProposalInput(:
Texte de la proposition )Description(. Cette information sera affichée publiquement sur l'interface de la page d'accueil de Sputnik-DAO, aidant les membres de la communauté à comprendre l'objectif et la signification de la proposition.
Type de proposition )kind(. Le proposeur doit choisir en fonction du type d'opinion sur la gestion de projet ) par exemple, si l'appel de fonction de privilège clé du contrat est nécessaire, il faut choisir le type FunctionCall, si le transfert de fonds du projet de contrat est nécessaire, il faut choisir le type Transfer, si la configuration/changement du niveau de contrôle de l'autorité de gouvernance du contrat est nécessaire, il faut choisir le type ChangePolicyAddOrUpdateRole, etc. (
Ces informations ProposalInput seront passées en tant que paramètres à la méthode add_proposal)(, qui effectuera des vérifications et un traitement supplémentaires, et générera une proposition avec des informations d'initialisation complètes )Proposal(. En fin de compte, cette proposition sera liée à un unique proposal_id et sera ajoutée sous la forme <key, value=""> dans la carte Contract.proposals, maintenue globalement par le contrat Sputnik-DAO, au sein de la piscine de propositions ).
Les propositions définies par le Sputnik-DAO possèdent les informations complètes suivantes :
rouille pub struct Proposal { pub id: u64, pub proposer: AccountId, pub description: String, pub kind: ProposalKind, pub status: ProposalStatus, pub vote_period_end: BlockHeight, pub vote_counts: HashMap<votePolicy, hashmap<accountId,="" balance="">>, pub votes: HashMap\u003caccountid, vote=""\u003e, pub submission_time: Timestamp, }
Dans cette proposition, les contenus des attributs description et kind seront extraits des informations ProposalInput fournies par le proposeur lors de la création de la proposition. Plus précisément, ce contrat utilise le trait From en Rust pour réaliser la conversion de type de ProposalInput en Proposal.
Ce processus de conversion est lié à plus d'informations sur l'état des propositions :
Le champ "proposer" du proposeur dans la proposition nouvellement ajoutée ( sera automatiquement attribué à l'appelant de la méthode add_proposal)(, c'est-à-dire env::predecessor_account_id)(, ce champ est réel et n'est pas sous le contrôle de l'utilisateur;
Le nouvel état de proposition )status( est initialisé par défaut à ProposalStatus::InProgress, c'est-à-dire qu'il est encore en phase de vote;
Le temps de soumission de la proposition nouvellement ajoutée )submission_time( est défini comme l'horodatage de ce bloc env::block_timestamp)(;
En raison de l'absence de votes lors de la soumission de la nouvelle proposition, l'état de vote )vote_counts, votes( est initialisé comme un HashMap::default)(.
Il est important de noter qu'il existe dans le Sputnik-DAO le concept de dépôt de proposition )proposal_bond(, ce dépôt sera géré selon le mode de gouvernance communautaire spécifique du Sputnik-DAO )Policy(.
La lecture du code pertinent révèle que le contrat exige que le proposeur mise un certain montant de tokens NEAR en tant que garantie pour la nouvelle proposition lors de l'appel de la méthode add_proposal)(. Ce dépôt sera remboursé au proposeur en appelant la fonction interne du contrat internal_return_bonds)( lorsque le vote de la communauté sur la proposition se termine normalement) avec un vote favorable ProposalStatus::Approved | un vote défavorable ProposalStatus::Rejected(.
Cependant, BlockSec a précédemment découvert en interprétant le code de contrat à cet endroit :
Sputnik-DAO ne maintient pas l'historique des montants de dépôt de proposition pour chaque utilisateur lors du traitement des dépôts de propositions. Lorsque l'utilisateur initie une transaction en appelant la méthode de contrat add_proposal)( pour ajouter une nouvelle proposition, il est possible d'ajouter à cette transaction un montant supérieur au montant de policy.bounty_bond en NEAR défini par la stratégie de gouvernance de ce DAO )Policy(. Cela entraînera un dépôt excédentaire qui ne sera pas remboursé au proposant lors de l'exécution de la fonction interne internal_return_bonds.
Après que l'équipe de BlockSec a pris contact avec le projet en temps utile, le problème )160 a finalement été corrigé.
Plus de stratégies de vérification et de traitement des propositions exécutées par Sputnik-DAO seront détaillées dans le prochain "Journal de développement des smart contracts Rust (10-4) Analyse du modèle de gouvernance communautaire de Sputnik DAO".
2. Statut de la proposition ( Proposal Status )
Toute proposition standard dans le Sputnik-DAO pourrait passer par plusieurs états différents #158被确认并及时在PR# le nouvel état de la proposition est initialisé comme : InProgress (
rouille pub enum ProposalStatus { En cours, Approuvé, Rejeté, Supprimé, Expiré, Ému, Échoué, }
Le changement d'état des propositions dans le pool de propositions est piloté par une autre méthode du contrat act_proposal)(.
Les membres de Sputnik-DAO peuvent appeler la méthode act_proposal)( pour exécuter les opérations suivantes sur la proposition spécifique ) en spécifiant l'id ( :
rouille pub enum Action { AddProposal, RemoveProposal, VoteApprove, VoteReject, VoteRemove, Finaliser, MoveToHub, }
Typiquement, pour les propositions en état InProgress, les membres de la communauté DAO peuvent appeler act_proposal)( pour effectuer des opérations de vote spécifiques:
Selon la mise en œuvre ci-dessus, après l'appel interne de la fonction update_votes)(, le programme appellera activement policy.proposal_status)( pour le travail de vote. Pour les propositions qui satisfont le seuil de vote, l'état de la proposition sera modifié en conséquence.
Changement après :
Si l'état de la proposition est Approuvé, alors la proposition sera exécutée en appelant internal_execute_proposal)(;
Si l'état de la proposition est Rejeté ou Retiré, la proposition effectuera des opérations de clôture ultérieures en appelant internal_reject_proposal)(.
Il convient de noter que la différence entre les états Rejected et Removed est la suivante : les propositions finalement déterminées comme étant dans l'état Removed seront directement supprimées du pool de propositions, ) comme pénalité ( ne remboursera pas le dépôt initialement misé au propositaire. En revanche, pour les propositions dans l'état Rejected, celles-ci resteront dans le pool de propositions et le dépôt correspondant sera remboursé.
![])https://img-cdn.gateio.im/webp-social/moments-84ee9ca630a4cdcdb0d2eb63450a7cf4.webp(
3. Exécution de la proposition ) Execute Proposal (
Si une proposition est approuvée à la fin du vote, la méthode de contrat act_proposal)( continuera d'appeler la fonction internal_execute_proposal)( pour exécuter le contenu décisionnel inclus dans la proposition.
Les types de propositions soutenues par Sputnik-DAO sont énumérés ci-dessous ) La plupart des types de propositions concernent la mise à jour de la configuration du modèle de gouvernance DAO ( :
Chaque type de proposition ci-dessus a mis en œuvre une branche de traitement correspondante dans la fonction internal_execute_proposal)(. Cette section présentera en profondeur deux types typiques de processus de traitement des propositions :
) 3.1 Exécution de la fonction du contrat Proposition d'exécution(ProposalKind::FunctionCall)
La fonction internal_execute_proposal() a implémenté le point d'entrée suivant pour traiter les propositions dont le ProposalKind est FunctionCall :
rouille ProposalKind::FunctionCall { receiver_id, actions } => { let mut promise = Promise::new###receiver_id.clone()(; pour action dans actions { promise = promise.function_call) action.method_name, action.args, action.deposit, action.gas, ( } promise.into() }
Le type de proposition FunctionCall est déjà passé par le paramètre ProposalInput lorsque le proposeur appelle la méthode add_proposal)(, spécifiant ainsi les opérations de fonction à exécuter )actions(.
Le contrat NEAR permet de lier plusieurs appels de fonction consécutifs dans une seule promesse. Ainsi, les objets ActionCall suivants peuvent être présents à l'intérieur des actions définies par le proposeur initial :
rouille pub struct ActionCall { pub method_name: String, pub args: Vec, pub deposit: Balance, pub gas: Gas, }
Chaque ActionCall peut spécifier le nom de la méthode du contrat correspondant ainsi que les paramètres de la méthode, etc.
Ainsi, le Sputnik-DAO a utilisé la forme des Promise Batch Actions pour réaliser l'exécution de la proposition de type fonction du contrat.
![])https://img-cdn.gateio.im/webp-social/moments-427716593b21fa32b47855ceb5e101fc.webp(
) 3.2 Exécution de la proposition de transfert de fonds de contrat ( ProposalKind::Transfer )
Lorsque le projet de smart contracts NEAR déployé et mis en ligne fonctionne pendant une longue période, le compte du contrat lui-même peut avoir accumulé un nombre important de Fungible Token(, y compris le jeton natif NEAR ou d'autres jetons conformes à la norme NEP-141).
À ce moment-là, les membres de la communauté Sputnik-DAO peuvent regrouper ces jetons dans le compte receiver_id spécifié en soumettant une proposition de transfert de fonds du contrat.
Le même internal_execute_proposal###( met également en œuvre un point d'entrée de traitement correspondant pour les propositions dont le ProposalKind est Transfer :
rouille ProposalKind::Transfer { token_id, receiver_id, amount } =\u003e { self.internal_payout)token_id, receiver_id, amount( .into)( }
La branche de traitement sous-jacente appellera la fonction internal_payout)(, permettant d'effectuer des opérations de transfert pour différents types de Fungible Token ainsi que pour différents types de receiver_id) EOA ou comptes de contrats(.
![])https://img-cdn.gateio.im/webp-social/moments-ef0b959c42e1f5fc6263cd4a86fd078e.webp(
4. Résumé et prévisions
Cet article a présenté le concept central du contrat Sputnik DAO - la proposition )Proposal(, tout en expliquant brièvement comment créer de nouvelles propositions et voter pour leur exécution dans le Sputnik DAO, ainsi que les règles de variation de l'état de base des propositions )Status(.
Le journal de développement des smart contracts Rust à venir fournira une description plus détaillée de la mise en œuvre et de la configuration du modèle de gouvernance dans Sputnik-DAO basé sur la proposition )Policy(, restez à l'écoute!
![])https://img-cdn.gateio.im/webp-social/moments-eb73d5e15f6161f0a4b442cd4b99a91e.webp(<accountid,><votepolicy,><key,>