Diario de desarrollo de contratos inteligentes en Rust (11): Análisis del mecanismo de propuestas de Sputnik DAO
Sputnik-DAO como infraestructura del Protocolo NEAR, está impulsando la evolución del ecosistema NEAR hacia una dirección descentralizada. Actualmente, esta plataforma ha facilitado numerosas comunidades autónomas de proyectos NEAR, al mismo tiempo que ofrece soluciones de gobernanza de decisiones comunitarias completas, flexibles y eficientes.
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 este contrato: la propuesta (Proposal), y explicará los modelos de gobernanza de la comunidad DAO relacionados con la propuesta (Policy).
1. Inicio de la propuesta
Cada miembro de la comunidad Sputnik-DAO puede expresar su opinión o presentar propuestas sobre la gobernanza o gestión del proyecto. Luego, cada miembro de la comunidad que posee 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.
Desde el nivel del contrato, los miembros de la comunidad DAO pueden llamar al método add_proposal() del contrato sputnikdaov2 para iniciar una nueva propuesta.
En este momento, el proponente debe proporcionar los detalles de la propuesta (ProposalInput):
Descripción del texto de la propuesta (. Esta información se mostrará públicamente en el front-end de la página principal 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 el tipo correspondiente según el tipo de opinión presentada sobre la gestión del proyecto ), como si se necesita llamar a una función clave de privilegio del contrato, se debe seleccionar el tipo FunctionCall, y si se requiere la transferencia de fondos del proyecto del contrato, se debe seleccionar el tipo Transfer, etc. (.
Esta información de ProposalInput se pasará como parámetros al método add_proposal)(, el cual realizará las verificaciones y procesamientos correspondientes, y generará una propuesta )Proposal( con información de inicialización completa. Finalmente, esta propuesta se vinculará con un único proposal_id y se añadirá al mapeo Contract.proposals, mantenido globalmente por el contrato Sputnik-DAO, en forma de <key, value=""> en el grupo de propuestas ).
Es importante tener en cuenta que existe el concepto de depósito de propuesta (proposal_bond) en Sputnik-DAO, el cual será administrado de acuerdo con el modelo de gobernanza de la comunidad específica de Sputnik-DAO (Policy). El contrato requiere que el proponente de la propuesta deposite una cierta cantidad de tokens NEAR como garantía para la nueva propuesta al llamar al método add_proposal(). Este depósito se devolverá al proponente al finalizar normalmente la propuesta ( con una votación de la comunidad a favor o en contra ), mediante la llamada a la función interna del contrato internal_return_bonds().
2. Estado de la propuesta
Cualquier propuesta estándar en Sputnik-DAO puede experimentar múltiples estados ( el nuevo estado de la propuesta se inicializa como InProgress ):
InProgress: votación en curso
Aprobado: la propuesta ha sido aprobada
Rechazado: la propuesta fue rechazada
Eliminado: la propuesta ha sido eliminada
Fallido: ejecución de la propuesta fallida
Expirado: la propuesta ha expirado
El cambio de estado de las propuestas en el fondo de propuestas es impulsado por el método act_proposal() del contrato. Los miembros de Sputnik-DAO pueden llamar al método act_proposal() para ejecutar operaciones en una propuesta específica identificada por el id (.
Para las propuestas en estado InProgress, los miembros de la comunidad DAO pueden llamar a act_proposal)( para ejecutar operaciones de votación específicas:
Action::VoteApprove:表赞成
Action::VoteReject:表反对
Action::VoteRemove: considera que esta propuesta no tiene sentido práctico y debe ser eliminada
Según la implementación, después de llamar internamente a la función update_votes)(, el programa llamará activamente a policy.proposal_status)( para realizar el conteo de votos. Para las propuestas que cumplen con el umbral de votación, el estado de la propuesta será cambiado en consecuencia.
Después de la modificación:
Si el estado de la propuesta es Aprobada, la propuesta se ejecutará llamando a internal_execute_proposal)(;
Si el estado de la propuesta es Rechazada o Eliminada, la propuesta realizará las operaciones de cierre posteriores llamando a internal_reject_proposal)(.
Cabe mencionar que la diferencia entre los estados Rechazado y Eliminado es que las propuestas que se determinan como Eliminadas se eliminarán directamente del fondo de propuestas y no se reembolsará el depósito inicialmente apostado al proponente. En cambio, las propuestas en estado Rechazado seguirán permaneciendo en el fondo de propuestas y se reembolsará el depósito correspondiente.
Si una propuesta tiene el estado de Aprobada después de que finaliza la votación, en ese 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 incluyen: ChangeConfig, ChangePolicy, AddMemberToRole, RemoveMemberFromRole, FunctionCall, UpgradeSelf, UpgradeRemote, Transfer, SetStakingContract, AddBounty, BountyDone, Vote, FactoryInfoUpdate, ChangePolicyAddOrUpdateRole, ChangePolicyRemoveRole, ChangePolicyUpdateDefaultVotePolicy, ChangePolicyUpdateParameters, etc.
A continuación, se presentan dos tipos típicos de procesos de manejo de propuestas:
) 3.1 Ejecución de funciones de contrato Propuesta(ProposalKind::FunctionCall)
Las propuestas de tipo FunctionCall se pasan como parámetros a la función add_proposal###( cuando el proponente la llama, y se ha proporcionado a través del parámetro ProposalInput la operación de función específica que esta propuesta debe ejecutar )actions(. El contrato de NEAR permite vincular múltiples llamadas a funciones en una Promesa. Por lo tanto, las acciones internas establecidas inicialmente por el proponente pueden contener múltiples objetos ActionCall, cada uno de los cuales puede especificar el nombre del método del contrato correspondiente y los parámetros del método, entre otros.
Sputnik-DAO adoptó la forma de Acciones por Lote de Promesas para llevar a cabo la ejecución de propuestas de tipo de función de contrato.
) 3.2 Propuesta de transferencia de fondos del contrato ( ProposalKind::Transfer )
Cuando el proyecto de contratos inteligentes NEAR ha estado en funcionamiento durante un tiempo, la cuenta del contrato en sí puede haber acumulado una cantidad considerable de Tokens Fungibles ###, incluidos los tokens nativos de 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 especificada receiver_id mediante la presentación de una propuesta de transferencia de fondos del contrato. internal_execute_proposal)( también implementó un punto de entrada correspondiente para las propuestas que coinciden con ProposalKind como Transfer.
La rama de procesamiento subyacente llamará a la función internal_payout)(, para llevar a cabo operaciones de transferencia para diferentes tipos de Fungible Token y diferentes tipos de receiver_id) EOA o cuentas de contrato(.
Este artículo presenta los conceptos clave del contrato Sputnik DAO: la propuesta )Proposal(, y también explica 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(.
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.
Explicación del mecanismo de propuestas de Sputnik DAO: un análisis del proceso completo desde la iniciación hasta la ejecución.
Diario de desarrollo de contratos inteligentes en Rust (11): Análisis del mecanismo de propuestas de Sputnik DAO
Sputnik-DAO como infraestructura del Protocolo NEAR, está impulsando la evolución del ecosistema NEAR hacia una dirección descentralizada. Actualmente, esta plataforma ha facilitado numerosas comunidades autónomas de proyectos NEAR, al mismo tiempo que ofrece soluciones de gobernanza de decisiones comunitarias completas, flexibles y eficientes.
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 este contrato: la propuesta (Proposal), y explicará los modelos de gobernanza de la comunidad DAO relacionados con la propuesta (Policy).
1. Inicio de la propuesta
Cada miembro de la comunidad Sputnik-DAO puede expresar su opinión o presentar propuestas sobre la gobernanza o gestión del proyecto. Luego, cada miembro de la comunidad que posee 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.
Desde el nivel del contrato, los miembros de la comunidad DAO pueden llamar al método add_proposal() del contrato sputnikdaov2 para iniciar una nueva propuesta.
En este momento, el proponente debe proporcionar los detalles de la propuesta (ProposalInput):
Descripción del texto de la propuesta (. Esta información se mostrará públicamente en el front-end de la página principal 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 el tipo correspondiente según el tipo de opinión presentada sobre la gestión del proyecto ), como si se necesita llamar a una función clave de privilegio del contrato, se debe seleccionar el tipo FunctionCall, y si se requiere la transferencia de fondos del proyecto del contrato, se debe seleccionar el tipo Transfer, etc. (.
Esta información de ProposalInput se pasará como parámetros al método add_proposal)(, el cual realizará las verificaciones y procesamientos correspondientes, y generará una propuesta )Proposal( con información de inicialización completa. Finalmente, esta propuesta se vinculará con un único proposal_id y se añadirá al mapeo Contract.proposals, mantenido globalmente por el contrato Sputnik-DAO, en forma de <key, value=""> en el grupo de propuestas ).
Es importante tener en cuenta que existe el concepto de depósito de propuesta (proposal_bond) en Sputnik-DAO, el cual será administrado de acuerdo con el modelo de gobernanza de la comunidad específica de Sputnik-DAO (Policy). El contrato requiere que el proponente de la propuesta deposite una cierta cantidad de tokens NEAR como garantía para la nueva propuesta al llamar al método add_proposal(). Este depósito se devolverá al proponente al finalizar normalmente la propuesta ( con una votación de la comunidad a favor o en contra ), mediante la llamada a la función interna del contrato internal_return_bonds().
2. Estado de la propuesta
Cualquier propuesta estándar en Sputnik-DAO puede experimentar múltiples estados ( el nuevo estado de la propuesta se inicializa como InProgress ):
El cambio de estado de las propuestas en el fondo de propuestas es impulsado por el método act_proposal() del contrato. Los miembros de Sputnik-DAO pueden llamar al método act_proposal() para ejecutar operaciones en una propuesta específica identificada por el id (.
Para las propuestas en estado InProgress, los miembros de la comunidad DAO pueden llamar a act_proposal)( para ejecutar operaciones de votación específicas:
Según la implementación, después de llamar internamente a la función update_votes)(, el programa llamará activamente a policy.proposal_status)( para realizar el conteo de votos. Para las propuestas que cumplen con el umbral de votación, el estado de la propuesta será cambiado en consecuencia.
Después de la modificación:
Cabe mencionar que la diferencia entre los estados Rechazado y Eliminado es que las propuestas que se determinan como Eliminadas se eliminarán directamente del fondo de propuestas y no se reembolsará el depósito inicialmente apostado al proponente. En cambio, las propuestas en estado Rechazado seguirán permaneciendo en el fondo de propuestas y se reembolsará el depósito correspondiente.
![])https://img-cdn.gateio.im/webp-social/moments-427716593b21fa32b47855ceb5e101fc.webp(
3. Ejecución de propuestas
Si una propuesta tiene el estado de Aprobada después de que finaliza la votación, en ese 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 incluyen: ChangeConfig, ChangePolicy, AddMemberToRole, RemoveMemberFromRole, FunctionCall, UpgradeSelf, UpgradeRemote, Transfer, SetStakingContract, AddBounty, BountyDone, Vote, FactoryInfoUpdate, ChangePolicyAddOrUpdateRole, ChangePolicyRemoveRole, ChangePolicyUpdateDefaultVotePolicy, ChangePolicyUpdateParameters, etc.
A continuación, se presentan dos tipos típicos de procesos de manejo de propuestas:
) 3.1 Ejecución de funciones de contrato Propuesta(ProposalKind::FunctionCall)
Las propuestas de tipo FunctionCall se pasan como parámetros a la función add_proposal###( cuando el proponente la llama, y se ha proporcionado a través del parámetro ProposalInput la operación de función específica que esta propuesta debe ejecutar )actions(. El contrato de NEAR permite vincular múltiples llamadas a funciones en una Promesa. Por lo tanto, las acciones internas establecidas inicialmente por el proponente pueden contener múltiples objetos ActionCall, cada uno de los cuales puede especificar el nombre del método del contrato correspondiente y los parámetros del método, entre otros.
Sputnik-DAO adoptó la forma de Acciones por Lote de Promesas para llevar a cabo la ejecución de propuestas de tipo de función de contrato.
) 3.2 Propuesta de transferencia de fondos del contrato ( ProposalKind::Transfer )
Cuando el proyecto de contratos inteligentes NEAR ha estado en funcionamiento durante un tiempo, la cuenta del contrato en sí puede haber acumulado una cantidad considerable de Tokens Fungibles ###, incluidos los tokens nativos de 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 especificada receiver_id mediante la presentación de una propuesta de transferencia de fondos del contrato. internal_execute_proposal)( también implementó un punto de entrada correspondiente para las propuestas que coinciden con ProposalKind como Transfer.
La rama de procesamiento subyacente llamará a la función internal_payout)(, para llevar a cabo 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
Este artículo presenta los conceptos clave del contrato Sputnik DAO: la propuesta )Proposal(, y también explica 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(.
![])https://img-cdn.gateio.im/webp-social/moments-eb73d5e15f6161f0a4b442cd4b99a91e.webp(</key,>