Diário de Desenvolvimento de Contratos Inteligentes Rust (10-3): Conceitos Centrais da DAO Sputnik - Proposta ( Análise

O Sputnik-DAO, como infraestrutura fornecida pelo NEAR Protocol, está efetivamente promovendo o desenvolvimento da ecologia NEAR na direção da "descentralização". Atualmente, a plataforma já facilitou a criação de numerosas comunidades autônomas "descentralizadas" de projetos NEAR, ao mesmo tempo que oferece uma solução completa, flexível e eficiente para a governança das decisões comunitárias.

Sputnikdaov2 é um contrato inteligente usado para a votação de governança da comunidade Sputnik-DAO. Este artigo irá apresentar os conceitos centrais desse contrato: proposta )Proposal(, artigos subsequentes irão abordar os "projetos" e introduzir os modos de governança da comunidade DAO )Policy(.

1. Início da proposta ) Adicionar Proposta (

Cada membro da comunidade Sputnik-DAO pode expressar opiniões ou submeter propostas sobre a governança ou gestão do projeto. Em seguida, cada membro da comunidade que possui ações no DAO pode revisar e votar sobre a proposta. Em outras palavras, cada membro do Sputnik-DAO pode influenciar o futuro do projeto votando em propostas de outros ou iniciando novas propostas de gestão.

No nível do contrato, os membros da comunidade DAO podem chamar o método add_proposal)( fornecido pelo contrato sputnikdaov2 para iniciar uma nova proposta.

ferrugem u64

Os proponentes devem fornecer detalhes sobre a proposta )ProposalInput(:

• Descrição do texto da proposta )Description(. Esta informação será exibida publicamente na parte frontal da página inicial do Sputnik-DAO, ajudando os membros da comunidade a entenderem o objetivo e o significado da proposta.

• Tipo de proposta )kind(. O proponente deve escolher o tipo de comentário sobre a gestão do projeto ), como, se a chamada de função de privilégio crítico do contrato, deve escolher o tipo FunctionCall, se a transferência de fundos do projeto do contrato, deve escolher o tipo Transfer, se a configuração/alteração do nível de controle de direitos de governança do contrato, deve escolher o tipo ChangePolicyAddOrUpdateRole, etc. (

Estas informações ProposalInput serão passadas como parâmetros para o método add_proposal)(, que executará validações e processamentos relevantes, gerando uma proposta )Proposal( com informações de inicialização completas. No final, essa proposta será vinculada a um único proposal_id e adicionada ao mapeamento Contract.proposals mantido globalmente pelo contrato Sputnik-DAO na forma <key, value=""> na piscina de propostas ).

As propostas definidas pelo Sputnik-DAO possuem as seguintes informações completas de atributos:

ferrugem pub struct Proposta { pub id: u64, pub proposer: AccountId, pub descrição: 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, }

Na proposta, o conteúdo dos atributos description e kind será extraído das informações ProposalInput fornecidas pelo proponente ao criar a proposta. Especificamente, o contrato utiliza a trait From da linguagem Rust para realizar a conversão de tipo de ProposalInput para Proposal.

Este processo de conversão está vinculado a mais informações sobre o estado das propostas:

• O proponente no novo pedido adicionado (proposer) terá o atributo automaticamente atribuído ao chamador do método add_proposal(), ou seja, env::predecessor_account_id(), este atributo é verdadeiro e não está sob o controle do usuário;

• O estado da proposta adicionada recentemente (status) é inicializado por padrão como ProposalStatus::InProgress, ou seja, ainda está na fase de votação;

• O tempo de início da proposta adicionada foi definido como o timestamp deste bloco env::block_timestamp().

• Devido à ausência de votos na submissão da nova proposta, o estado da votação (vote_counts, votes) estão ambos inicializados como HashMap::default().

É importante notar que existe o conceito de depósito de proposta (proposal_bond) no Sputnik-DAO, que será gerido de acordo com o modelo de governança da comunidade Sputnik-DAO (Policy).

A leitura do código relevante revela que o contrato exige que o proponente deposite uma certa quantia de tokens NEAR ao chamar o método add_proposal() como garantia para a nova proposta. Este depósito será devolvido ao proponente chamando a função interna internal_return_bonds() do contrato, após o término normal da proposta( com a votação da comunidade a favor ProposalStatus::Approved | a votação da comunidade contra ProposalStatus::Rejected).

No entanto, a BlockSec anteriormente descobriu ao interpretar o código do contrato nesse ponto:

O Sputnik-DAO, ao lidar com depósitos de propostas, não mantém o montante histórico de depósitos de propostas para cada usuário de forma separada. E quando um usuário inicia uma transação, chamando o método do contrato add_proposal() para adicionar uma nova proposta, pode anexar a essa transação um valor superior ao definido pela política de governança do DAO (Policy), que é o policy.bounty_bond em tokens NEAR. Isso resultará em uma parte excessiva do depósito, que não será devolvida ao proponente durante a execução da função internal_return_bonds.

Após a equipe BlockSec entrar em contato com a equipe do projeto, a questão (160 foi finalmente resolvida.

Mais estratégias de verificação e tratamento relacionadas às propostas executadas internamente pelo Sputnik-DAO serão detalhadas no próximo lançamento do "Diário de Desenvolvimento de Contratos Inteligentes Rust )10-4( Análise do Modelo de Governança da Comunidade Sputnik DAO".

2. Estado da Proposta)Proposal Status(

Qualquer proposta padrão no Sputnik-DAO pode passar por diversos estados, sendo que o estado da nova proposta é inicializado como: InProgress.

ferrugem pub enum ProposalStatus { Em Andamento, Aprovado, Rejeitado, Removido, Expirado, Mudado, Falhou, }

A alteração do estado das propostas no pool de propostas é acionada por outro método do contrato act_proposal)#158被确认并及时在PR#.

Os membros do Sputnik-DAO podem chamar o método act_proposal() para executar as seguintes operações na proposta específica (, especificando o id ):

ferrugem pub enum Ação { AddProposal, RemoveProposal, VoteApprove, VoteReject, VoteRemove, Finalizar, MoveToHub, }

Típico, para propostas que estão no estado InProgress, os membros da comunidade DAO podem chamar act_proposal() para executar operações de votação específicas:

• Ação::VoteApprove:表赞成;
• Ação::VoteReject:表反对;
• Ação::VotarRemover: considera que esta proposta não tem significado prático, deve ser removida;

De acordo com a implementação acima, após a chamada interna da função update_votes(), o programa chamará proativamente policy.proposal_status() para realizar o trabalho de contagem de votos. Para as propostas que atendem ao limite de votos, o estado da proposta será alterado de acordo.

Após a alteração:

• Se o estado da proposta for Aprovado, a proposta será executada chamando internal_execute_proposal();

• Se o estado da proposta for Rejeitada ou Removida, então a proposta será finalizada através da chamada internal_reject_proposal().

Vale a pena mencionar que a diferença entre os estados Rejected e Removed é que: as propostas que são finalmente classificadas como Removed serão removidas diretamente do pool de propostas, e (, como penalização, ) não devolverá o depósito inicialmente apostado ao proponente. Quanto às propostas com o estado Rejected, essas continuarão a ser mantidas no pool de propostas e o depósito correspondente será devolvido.

3. Execução da Proposta ( Execute Proposal )

Se uma proposta tiver o status de Aprovada após o término da votação, neste momento, o método do contrato act_proposal() continuará a chamar a função internal_execute_proposal() para executar o conteúdo da decisão contido na proposta.

Os tipos de propostas suportadas pelo Sputnik-DAO são os seguintes ( A maioria dos tipos de propostas envolve atualizações na configuração do modelo de governança DAO ):

• ProposalKind::ChangeConfig
• ProposalKind::ChangePolicy
• ProposalKind::AdicionarMembroAoCargo
• ProposalKind::RemoverMembroDoPapel
• ProposalKind::FunctionCall
• ProposalKind::UpgradeSelf
• ProposalKind::UpgradeRemote
• ProposalKind::Transfer
• ProposalKind::SetStakingContract
• ProposalKind::AddBounty
• ProposalKind::BountyDone
• ProposalKind::Vote
• ProposalKind::AtualizaçãoDeInformaçõesDaFábrica
• ProposalKind::AlterarPolíticaAdicionarOuAtualizarFunção
• ProposalKind::ChangePolicyRemoveRole
• ProposalKind::AlterarPoliticaAtualizarPoliticaDeVotoPadrão
• ProposalKind::AlterarParâmetrosDeAtualizaçãoDePolítica

Cada um dos tipos de proposta acima implementou um ramo de tratamento correspondente na função internal_execute_proposal(). Nesta seção, vamos apresentar em profundidade dois tipos típicos de processos de tratamento de propostas:

• ProposalKind::FunctionCall
• ProposalKind::Transfer

( 3.1 execução de proposta de função de contrato ) ProposalKind::FunctionCall (

A função internal_execute_proposal)( implementou o seguinte ponto de entrada para tratar propostas cujo ProposalKind é FunctionCall:

ferrugem ProposalKind::FunctionCall { receiver_id, actions } => { let mut promise = Promise::new)receiver_id.clone()###; para ação em ações { promise = promise.function_call( action.method_name, action.args, ação.deposito, action.gas, ) } promise.into() }

O tipo de proposta FunctionCall já tinha passado a operação de função específica que a proposta deve executar ( actions ( quando o proponente chamou o método add_proposal)) através do parâmetro ProposalInput.

Os contratos NEAR permitem vincular várias chamadas de função consecutivas em uma Promise. Assim, dentro das ações definidas inicialmente pelo proponente, podem existir os seguintes objetos ActionCall:

ferrugem pub struct ActionCall { pub method_name: String, pub args: Vec, pub deposit: Saldo, pub gas: Gas, }

Cada ActionCall pode especificar o nome do método do contrato correspondente e os parâmetros do método, entre outros.

Assim, o Sputnik-DAO completou a execução da proposta do tipo de função de contrato na forma de Ações em Lote de Promessa.

( 3.2 Proposta de execução de transferência de fundos do contrato ) ProposalKind::Transfer (

Após um projeto de contratos inteligentes NEAR ser implantado e estar em funcionamento por um longo período, a conta do contrato em si pode ter acumulado uma quantidade significativa de Tokens Fungíveis ), incluindo o token nativo NEAR, ou outros tokens que atendem ao padrão NEP-141 (.

Neste momento, os membros da comunidade Sputnik-DAO podem agrupar esses tokens na conta receiver_id designada, submetendo uma proposta de transferência de fundos do contrato.

A mesma internal_execute_proposal)( implementou uma entrada de processamento correspondente para propostas com ProposalKind igual a Transfer:

ferrugem ProposalKind::Transfer { token_id, receiver_id, amount } => { self.internal_payout)token_id, receiver_id, amount### .into() }

O ramo de tratamento subjacente chamará a função internal_payout(), para realizar operações de transferência para diferentes tipos de Fungible Token e diferentes tipos de receiver_id( EOA ou contas de contrato).

4. Resumo e Previsão

Este artigo apresentou os conceitos centrais do contrato Sputnik DAO - Proposta (Proposal), e também explicou brevemente como criar novas propostas e votar na execução no Sputnik DAO, bem como as regras de alteração do estado básico das propostas relacionadas (Status).

O diário de desenvolvimento de contratos inteligentes Rust a seguir irá apresentar uma descrição mais detalhada da implementação e configuração do modelo de governança (Policy) no Sputnik-DAO, fiquem atentos!

</accountid,></votepolicy,></key,>