Diario de desarrollo de contratos inteligentes en Rust (10-3): Conceptos clave del Sputnik DAO - Propuesta ( Análisis de la Propuesta )
Sputnik-DAO, como infraestructura proporcionada por NEAR Protocol, está impulsando con fuerza el desarrollo del ecosistema NEAR hacia una dirección de "descentralización". Actualmente, esta plataforma ha facilitado la creación de numerosas comunidades autónomas "descentralizadas" de proyectos NEAR, al mismo tiempo que ofrece soluciones completas, flexibles y eficientes para la gobernanza y toma de decisiones comunitarias.
Sputnikdaov2 es un contrato inteligente utilizado para la votación de gobernanza de la comunidad Sputnik-DAO. Este artículo presentará los conceptos clave de dicho contrato: propuesta (Proposal), los siguientes artículos se centrarán en la "propuesta" y presentarán los modelos de gobernanza de la comunidad DAO (Policy).
1. Iniciar propuesta ( Añadir propuesta )
Cada miembro de la comunidad Sputnik-DAO puede opinar o presentar propuestas sobre la gobernanza o gestión del proyecto. Luego, cada miembro de la comunidad que posea acciones en el DAO puede revisar y votar sobre la propuesta. En otras palabras, cada miembro en Sputnik-DAO puede influir en el futuro del proyecto votando sobre las propuestas de otros o iniciando nuevas propuestas de gestión.
A nivel de contratos, los miembros de la comunidad DAO pueden llamar al método add_proposal() proporcionado por el contrato sputnikdaov2 para iniciar nuevas propuestas.
óxido
u64
El proponente debe proporcionar los detalles de la propuesta (ProposalInput):
Descripción del texto de la propuesta ( Description ). Esta información se mostrará públicamente en la parte frontal de la página de inicio de Sputnik-DAO, ayudando a los miembros de la comunidad a entender el propósito y la importancia de la propuesta.
Tipo de propuesta ( kind ). El proponente debe seleccionar según el tipo de opinión sobre la gestión del proyecto (, como si la llamada a funciones clave del contrato requiere seleccionar el tipo FunctionCall, la transferencia de fondos del proyecto del contrato requiere seleccionar el tipo Transfer, y la configuración/cambio del nivel de control de permisos de gobernanza del contrato requiere seleccionar el tipo ChangePolicyAddOrUpdateRole, etc. )
Esta información de ProposalInput se pasará como parámetros al método add_proposal(), que realizará las verificaciones y procesos correspondientes, y generará la propuesta(Proposal) con toda la información de inicialización completa. Finalmente, la propuesta se vinculará con un único proposal_id y se añadirá en forma de <key, value=""> al mapeo Contract.proposals mantenido globalmente por el contrato Sputnik-DAO, en el pool de propuestas(.
Las propuestas definidas por Sputnik-DAO tienen la siguiente información de atributos completa:
En esta propuesta, la descripción y el contenido del atributo tipo se extraerán de la información ProposalInput proporcionada por el proponente al crear la propuesta. Específicamente, el contrato utiliza el rasgo From de Rust para implementar la conversión de tipo de ProposalInput a Proposal.
Este proceso de conversión está vinculado a más información sobre el estado de las propuestas:
El atributo del proponente ) en la propuesta añadida se asignará automáticamente al llamador del método add_proposal(), es decir, env::predecessor_account_id(), este atributo es verdadero y no está bajo el control del usuario;
El nuevo estado de propuesta (status) se inicializa por defecto como ProposalStatus::InProgress, es decir, todavía está en la fase de votación;
El tiempo de inicio de la propuesta recién añadida ( submission_time ) se asigna como la marca de tiempo de este bloque env::block_timestamp ( );
Debido a que no hubo votos al momento de presentar la nueva propuesta, el estado de votación (vote_counts, votes) se inicializa como un HashMap::default() vacío.
Es importante tener en cuenta que en Sputnik-DAO existe el concepto de depósito de propuesta (proposal_bond), el cual será gestionado de acuerdo con el modelo de gobernanza específica de la comunidad Sputnik-DAO (Policy).
Al leer el código relacionado, se puede ver que el contrato exige a los proponentes que, al llamar al método add_proposal(), pongan en garantía una cierta cantidad de tokens NEAR como depósito para la nueva propuesta. Este depósito se reembolsará al proponente al finalizar normalmente la propuesta(, mediante la votación de la comunidad a favor de ProposalStatus::Approved | la votación de la comunidad en contra de ProposalStatus::Rejected), llamando a la función interna del contrato internal_return_bonds().
Sin embargo, BlockSec anteriormente descubrió al interpretar el código del contrato en esa sección:
Sputnik-DAO al procesar el depósito de propuestas, no mantiene el monto del depósito histórico de propuestas de cada usuario de forma individual. Y cuando un usuario inicia una transacción, llamando al método del contrato add_proposal() para agregar una nueva propuesta, puede adjuntar a esta transacción más de los tokens NEAR policy.bounty_bond definidos por la estrategia de gobernanza del DAO (Policy). Esto resultará en un depósito adicional que no será devuelto al proponente al ejecutar la función interna internal_return_bonds.
Después de que el equipo de BlockSec se pusiera en contacto con el proyecto a tiempo, finalmente se resolvió el problema (160.
Más estrategias de verificación y procesamiento relacionadas con las propuestas ejecutadas internamente por Sputnik-DAO se detallarán en el próximo "Diario de Desarrollo de Contratos Inteligentes Rust )10-4( Análisis del Modelo de Gobernanza Comunitaria de Sputnik DAO".
2. Estado de la propuesta ) Proposal Status #158被确认并及时在PR#
Cualquier propuesta estándar en Sputnik-DAO puede experimentar las siguientes múltiples estados( El nuevo estado de la propuesta se inicializa como: InProgress)
El cambio de estado de las propuestas en el pool de propuestas es impulsado por otro método del contrato act_proposal().
Los miembros de Sputnik-DAO pueden llamar al método act_proposal() para llevar a cabo las siguientes operaciones en la propuesta específica (, especificando el id ):
Típicamente, para las propuestas en estado InProgress, los miembros de la comunidad DAO pueden llamar a act_proposal() para realizar operaciones de votación específicas:
Action::VoteApprove:表赞成;
Action::VoteReject:表反对;
Action::VoteRemove: considera que esta propuesta no tiene sentido práctico, debe ser eliminada;
Según la implementación anterior, después de llamar internamente a la función update_votes(), el programa llamará activamente a policy.proposal_status() para llevar a cabo el trabajo de conteo de votos. Para las propuestas que cumplan con el umbral de votación, el estado de la propuesta se modificará en consecuencia.
Cambio:
Si el estado de la propuesta es Aprobada, entonces la propuesta será ejecutada llamando a internal_execute_proposal();
Si el estado de la propuesta es Rechazada o Eliminada, la propuesta se llevará a cabo mediante la llamada internal_reject_proposal() para realizar las operaciones finales.
Vale la pena mencionar que la diferencia entre los estados Rejected y Removed es que: las propuestas que se determinan finalmente como Removed se eliminarán directamente del fondo de propuestas, ( como penalización ) no devolverá el depósito que se había apostado al proponente. En cuanto a las propuestas en estado Rejected, estas seguirán conservándose en el fondo de propuestas y se devolverá el depósito correspondiente.
3. Ejecución de la Propuesta ( Ejecutar Propuesta )
Si una propuesta tiene el estado de Approved después de que finalice la votación, en este momento el método del contrato act_proposal() continuará llamando a la función internal_execute_proposal() para ejecutar el contenido de la decisión incluida en la propuesta.
Los tipos de propuestas apoyadas por Sputnik-DAO se enumeran a continuación ( La mayoría de los tipos de propuestas implican actualizaciones en la configuración del modelo de gobernanza del DAO ):
ProposalKind::ChangeConfig
ProposalKind::ChangePolicy
ProposalKind::AgregarMiembroARol
ProposalKind::RemoveMemberFromRole
ProposalKind::FunctionCall
ProposalKind::UpgradeSelf
ProposalKind::UpgradeRemote
ProposalKind::Transfer
ProposalKind::SetStakingContract
ProposalKind::AddBounty
ProposalKind::BountyDone
ProposalKind::Vote
ProposalKind::FactoryInfoUpdate
ProposalKind::ChangePolicyAddOrUpdateRole
ProposalKind::CambiarPolíticaEliminarRol
ProposalKind::ChangePolicyUpdateDefaultVotePolicy
ProposalKind::ChangePolicyUpdateParameters
Cada uno de los tipos de propuesta anteriores implementa una rama de procesamiento correspondiente en la función internal_execute_proposal().
Esta sección presentará en profundidad dos tipos típicos de procesos de manejo de propuestas:
ProposalKind::FunctionCall
ProposalKind::Transfer
( 3.1 Ejecución de funciones de contrato Propuesta de ejecución ) ProposalKind::FunctionCall (
La función internal_execute_proposal)### implementa la siguiente entrada de procesamiento para las propuestas cuyo ProposalKind es FunctionCall:
óxido
ProposalKind::FunctionCall { receiver_id, actions } => {
let mut promise = Promise::new(receiver_id.clone)();
para acción en acciones {
promise = promise.function_call(
action.method_name,
action.args,
acción.depositar,
action.gas,
(
}
promise.into))
}
Las propuestas del tipo FunctionCall se introducen en el momento en que el proponente llama al método add_proposal(), a través del parámetro ProposalInput, que ya contiene las acciones( específicas que debe ejecutar dicha propuesta.
Los contratos de NEAR permiten vincular múltiples function_call consecutivos en una Promise. Por lo tanto, dentro de las acciones establecidas inicialmente por el proponente, pueden existir los siguientes objetos ActionCall:
) 3.2 ejecución de la propuesta de transferencia de fondos del contrato (ProposalKind::Transfer)
Después de que el proyecto de contratos inteligentes NEAR implementado en línea haya estado funcionando durante un período prolongado, la cuenta del contrato en sí puede haber acumulado una cantidad considerable de Fungible Token(, incluidos el token nativo NEAR o otros tokens que cumplen con el estándar NEP-141).
En este momento, los miembros de la comunidad Sputnik-DAO pueden agrupar estos tokens en la cuenta receiver_id designada mediante la presentación de una propuesta de transferencia de fondos del contrato.
La misma internal_execute_proposal###( también implementó un punto de entrada correspondiente para manejar propuestas cuyo ProposalKind sea Transfer:
La rama de procesamiento subyacente llamará a la función internal_payout)(, realizando operaciones de transferencia para diferentes tipos de Fungible Token y diferentes tipos de receiver_id) EOA o cuentas de contrato(.
Este artículo ha presentado a todos el concepto central del contrato de Sputnik DAO: la propuesta )Proposal(, al mismo tiempo que se explicó brevemente cómo crear nuevas propuestas y votar para ejecutarlas en Sputnik DAO, así como las reglas de cambio del estado básico de las propuestas relacionadas )Status(.
El diario de desarrollo de contratos inteligentes Rust a continuación se basará en la implementación y configuración del modelo de gobernanza de Sputnik-DAO en la propuesta )Policy(, ¡estén atentos!
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
13 me gusta
Recompensa
13
6
Republicar
Compartir
Comentar
0/400
GraphGuru
· 08-12 20:42
alcista ah, ya está trabajando en el mecanismo de propuestas nuevamente.
Ver originalesResponder0
HashBrownies
· 08-12 19:04
Este contrato es muy difícil de manejar...
Ver originalesResponder0
AirdropHunter007
· 08-12 19:04
cerca de esta pregunta la entendí
Ver originalesResponder0
TokenTaxonomist
· 08-12 19:01
hmm... estadísticamente hablando, el mecanismo de propuesta de sputnik muestra una entropía 47.3% menor que los marcos óptimos de dao. He mapeado todo el árbol taxonómico en mi hoja de cálculo
Ver originalesResponder0
BTCBeliefStation
· 08-12 18:59
Los jugadores de dao realmente no pueden soportarlo más.
Ver originalesResponder0
BrokenYield
· 08-12 18:55
otro dao no solucionará los riesgos sistémicos... he visto esta película antes smh
Nuevo capítulo del ecosistema NEAR: Análisis en profundidad del mecanismo de propuestas de Sputnik DAO
Diario de desarrollo de contratos inteligentes en Rust (10-3): Conceptos clave del Sputnik DAO - Propuesta ( Análisis de la Propuesta )
Sputnik-DAO, como infraestructura proporcionada por NEAR Protocol, está impulsando con fuerza el desarrollo del ecosistema NEAR hacia una dirección de "descentralización". Actualmente, esta plataforma ha facilitado la creación de numerosas comunidades autónomas "descentralizadas" de proyectos NEAR, al mismo tiempo que ofrece soluciones completas, flexibles y eficientes para la gobernanza y toma de decisiones comunitarias.
Sputnikdaov2 es un contrato inteligente utilizado para la votación de gobernanza de la comunidad Sputnik-DAO. Este artículo presentará los conceptos clave de dicho contrato: propuesta (Proposal), los siguientes artículos se centrarán en la "propuesta" y presentarán los modelos de gobernanza de la comunidad DAO (Policy).
1. Iniciar propuesta ( Añadir propuesta )
Cada miembro de la comunidad Sputnik-DAO puede opinar o presentar propuestas sobre la gobernanza o gestión del proyecto. Luego, cada miembro de la comunidad que posea acciones en el DAO puede revisar y votar sobre la propuesta. En otras palabras, cada miembro en Sputnik-DAO puede influir en el futuro del proyecto votando sobre las propuestas de otros o iniciando nuevas propuestas de gestión.
A nivel de contratos, los miembros de la comunidad DAO pueden llamar al método add_proposal() proporcionado por el contrato sputnikdaov2 para iniciar nuevas propuestas.
óxido u64
El proponente debe proporcionar los detalles de la propuesta (ProposalInput):
Descripción del texto de la propuesta ( Description ). Esta información se mostrará públicamente en la parte frontal de la página de inicio de Sputnik-DAO, ayudando a los miembros de la comunidad a entender el propósito y la importancia de la propuesta.
Tipo de propuesta ( kind ). El proponente debe seleccionar según el tipo de opinión sobre la gestión del proyecto (, como si la llamada a funciones clave del contrato requiere seleccionar el tipo FunctionCall, la transferencia de fondos del proyecto del contrato requiere seleccionar el tipo Transfer, y la configuración/cambio del nivel de control de permisos de gobernanza del contrato requiere seleccionar el tipo ChangePolicyAddOrUpdateRole, etc. )
Esta información de ProposalInput se pasará como parámetros al método add_proposal(), que realizará las verificaciones y procesos correspondientes, y generará la propuesta(Proposal) con toda la información de inicialización completa. Finalmente, la propuesta se vinculará con un único proposal_id y se añadirá en forma de <key, value=""> al mapeo Contract.proposals mantenido globalmente por el contrato Sputnik-DAO, en el pool de propuestas(.
Las propuestas definidas por Sputnik-DAO tienen la siguiente información de atributos completa:
óxido 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\u003cvotepolicy, hashmap\u003caccountid,="" balance=""\u003e\u003e, pub votes: HashMap\u003caccountid, vote=""\u003e, pub submission_time: Timestamp, }
En esta propuesta, la descripción y el contenido del atributo tipo se extraerán de la información ProposalInput proporcionada por el proponente al crear la propuesta. Específicamente, el contrato utiliza el rasgo From de Rust para implementar la conversión de tipo de ProposalInput a Proposal.
Este proceso de conversión está vinculado a más información sobre el estado de las propuestas:
El atributo del proponente ) en la propuesta añadida se asignará automáticamente al llamador del método add_proposal(), es decir, env::predecessor_account_id(), este atributo es verdadero y no está bajo el control del usuario;
El nuevo estado de propuesta (status) se inicializa por defecto como ProposalStatus::InProgress, es decir, todavía está en la fase de votación;
El tiempo de inicio de la propuesta recién añadida ( submission_time ) se asigna como la marca de tiempo de este bloque env::block_timestamp ( );
Debido a que no hubo votos al momento de presentar la nueva propuesta, el estado de votación (vote_counts, votes) se inicializa como un HashMap::default() vacío.
Es importante tener en cuenta que en Sputnik-DAO existe el concepto de depósito de propuesta (proposal_bond), el cual será gestionado de acuerdo con el modelo de gobernanza específica de la comunidad Sputnik-DAO (Policy).
Al leer el código relacionado, se puede ver que el contrato exige a los proponentes que, al llamar al método add_proposal(), pongan en garantía una cierta cantidad de tokens NEAR como depósito para la nueva propuesta. Este depósito se reembolsará al proponente al finalizar normalmente la propuesta(, mediante la votación de la comunidad a favor de ProposalStatus::Approved | la votación de la comunidad en contra de ProposalStatus::Rejected), llamando a la función interna del contrato internal_return_bonds().
Sin embargo, BlockSec anteriormente descubrió al interpretar el código del contrato en esa sección:
Sputnik-DAO al procesar el depósito de propuestas, no mantiene el monto del depósito histórico de propuestas de cada usuario de forma individual. Y cuando un usuario inicia una transacción, llamando al método del contrato add_proposal() para agregar una nueva propuesta, puede adjuntar a esta transacción más de los tokens NEAR policy.bounty_bond definidos por la estrategia de gobernanza del DAO (Policy). Esto resultará en un depósito adicional que no será devuelto al proponente al ejecutar la función interna internal_return_bonds.
Después de que el equipo de BlockSec se pusiera en contacto con el proyecto a tiempo, finalmente se resolvió el problema (160.
Más estrategias de verificación y procesamiento relacionadas con las propuestas ejecutadas internamente por Sputnik-DAO se detallarán en el próximo "Diario de Desarrollo de Contratos Inteligentes Rust )10-4( Análisis del Modelo de Gobernanza Comunitaria de Sputnik DAO".
2. Estado de la propuesta ) Proposal Status #158被确认并及时在PR#
Cualquier propuesta estándar en Sputnik-DAO puede experimentar las siguientes múltiples estados( El nuevo estado de la propuesta se inicializa como: InProgress)
óxido pub enum ProposalStatus { En progreso, Aprobado, Rechazado, Eliminado, Caducado, Movido, Fallido, }
El cambio de estado de las propuestas en el pool de propuestas es impulsado por otro método del contrato act_proposal().
Los miembros de Sputnik-DAO pueden llamar al método act_proposal() para llevar a cabo las siguientes operaciones en la propuesta específica (, especificando el id ):
óxido pub enum Acción { AddProposal, RemoveProposal, VoteApprove, VoteReject, VoteRemove, Finalizar, MoveToHub, }
Típicamente, para las propuestas en estado InProgress, los miembros de la comunidad DAO pueden llamar a act_proposal() para realizar operaciones de votación específicas:
Según la implementación anterior, después de llamar internamente a la función update_votes(), el programa llamará activamente a policy.proposal_status() para llevar a cabo el trabajo de conteo de votos. Para las propuestas que cumplan con el umbral de votación, el estado de la propuesta se modificará en consecuencia.
Cambio:
Si el estado de la propuesta es Aprobada, entonces la propuesta será ejecutada llamando a internal_execute_proposal();
Si el estado de la propuesta es Rechazada o Eliminada, la propuesta se llevará a cabo mediante la llamada internal_reject_proposal() para realizar las operaciones finales.
Vale la pena mencionar que la diferencia entre los estados Rejected y Removed es que: las propuestas que se determinan finalmente como Removed se eliminarán directamente del fondo de propuestas, ( como penalización ) no devolverá el depósito que se había apostado al proponente. En cuanto a las propuestas en estado Rejected, estas seguirán conservándose en el fondo de propuestas y se devolverá el depósito correspondiente.
3. Ejecución de la Propuesta ( Ejecutar Propuesta )
Si una propuesta tiene el estado de Approved después de que finalice la votación, en este momento el método del contrato act_proposal() continuará llamando a la función internal_execute_proposal() para ejecutar el contenido de la decisión incluida en la propuesta.
Los tipos de propuestas apoyadas por Sputnik-DAO se enumeran a continuación ( La mayoría de los tipos de propuestas implican actualizaciones en la configuración del modelo de gobernanza del DAO ):
Cada uno de los tipos de propuesta anteriores implementa una rama de procesamiento correspondiente en la función internal_execute_proposal(). Esta sección presentará en profundidad dos tipos típicos de procesos de manejo de propuestas:
( 3.1 Ejecución de funciones de contrato Propuesta de ejecución ) ProposalKind::FunctionCall (
La función internal_execute_proposal)### implementa la siguiente entrada de procesamiento para las propuestas cuyo ProposalKind es FunctionCall:
óxido ProposalKind::FunctionCall { receiver_id, actions } => { let mut promise = Promise::new(receiver_id.clone)(); para acción en acciones { promise = promise.function_call( action.method_name, action.args, acción.depositar, action.gas, ( } promise.into)) }
Las propuestas del tipo FunctionCall se introducen en el momento en que el proponente llama al método add_proposal(), a través del parámetro ProposalInput, que ya contiene las acciones( específicas que debe ejecutar dicha propuesta.
Los contratos de NEAR permiten vincular múltiples function_call consecutivos en una Promise. Por lo tanto, dentro de las acciones establecidas inicialmente por el proponente, pueden existir los siguientes objetos ActionCall:
óxido pub struct ActionCall { pub method_name: String, pub args: Vec, pub deposit: Balance, pub gas: Gas, }
Cada ActionCall puede especificar el nombre del método del contrato correspondiente y los parámetros del método, entre otros.
En resumen, el Sputnik-DAO completó la ejecución de la propuesta de tipo de función de contrato mediante acciones por lotes de promesas.
![])https://img-cdn.gateio.im/webp-social/moments-427716593b21fa32b47855ceb5e101fc.webp(
) 3.2 ejecución de la propuesta de transferencia de fondos del contrato (ProposalKind::Transfer)
Después de que el proyecto de contratos inteligentes NEAR implementado en línea haya estado funcionando durante un período prolongado, la cuenta del contrato en sí puede haber acumulado una cantidad considerable de Fungible Token(, incluidos el token nativo NEAR o otros tokens que cumplen con el estándar NEP-141).
En este momento, los miembros de la comunidad Sputnik-DAO pueden agrupar estos tokens en la cuenta receiver_id designada mediante la presentación de una propuesta de transferencia de fondos del contrato.
La misma internal_execute_proposal###( también implementó un punto de entrada correspondiente para manejar propuestas cuyo ProposalKind sea Transfer:
óxido ProposalKind::Transfer { token_id, receiver_id, amount } => { self.internal_payout)token_id, receiver_id, amount( .into)( }
La rama de procesamiento subyacente llamará a la función internal_payout)(, realizando operaciones de transferencia para diferentes tipos de Fungible Token y diferentes tipos de receiver_id) EOA o cuentas de contrato(.
![])https://img-cdn.gateio.im/webp-social/moments-ef0b959c42e1f5fc6263cd4a86fd078e.webp(
4. Resumen y previsión
Este artículo ha presentado a todos el concepto central del contrato de Sputnik DAO: la propuesta )Proposal(, al mismo tiempo que se explicó brevemente cómo crear nuevas propuestas y votar para ejecutarlas en Sputnik DAO, así como las reglas de cambio del estado básico de las propuestas relacionadas )Status(.
El diario de desarrollo de contratos inteligentes Rust a continuación se basará en la implementación y configuración del modelo de gobernanza de Sputnik-DAO en la propuesta )Policy(, ¡estén atentos!
![])https://img-cdn.gateio.im/webp-social/moments-eb73d5e15f6161f0a4b442cd4b99a91e.webp(</accountid,></votepolicy,></key,>